WebUI自动化测试框架Demo(下)

发表于 2020-05-17 分类于搬砖那些事儿

本文字数： 5.2k 阅读时长 ≈ 17 分钟

利用Jenkins/GoCD和Github实现Demo Project的CI集成。

上篇博客我们已经完成了Demo Project的代码优化, 这篇文章我们就利用Jenkins和GoCD这两种工具来实现Demo Project的持续集成。

CI&CD介绍

是什么

持续集成CI(Continuous Integration)

持续集成指的是，频繁地（一天多次）将代码集成到主干。基本流程为：

提交代码
执行第一轮测试(单元/集成测试)
代码合到master

持续交付(Continuous Delivery)

持续交付指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，当前代码就是一个可以直接部署的版本。基本流程为：

代码集成完成
构建项目，将源码转换为可以运行的实际代码
执行第二轮测试(端到端/手工测试)

持续部署(Continuous Deployment)

持续部署是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。基本流程为：

持续交付流程完成
利用工具自动部署到生产环境

持续部署和持续交付的区别在于，前者可以自动化部署过程，后者只能手工部署。

怎么做

CI&CD的实现离不开自动化工具，比较流行的有关注持续集成的Jenkins/Travis CI/…, 关注持续交付/部署的GoCD等等。

使用Jenkins集成

Jenkins 是一个开源软件项目，是基于 Java 开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。

完成后的效果，小太阳标志：

首先把本地的DemoProject推送到Github，然后请直接按照这篇文章的Jenkins部分设置，已经写的很详细了，主要包括：

1. Jenkins安装：在本地8080端口运行Jenkins并设置管理员账号

小知识：WAR(Web应用程序归档，英語：Web application archive)，也是一种Java归档，存储XML文件、Java类、JSP和Web应用程序中的其他文件。

2. Jenkins配置：添加JDK和Maven
3. Jenkins添加GitHub server：Github生成token并在github的DemoProject项目里添加本地Webhook

这部分Payload URL里的Jenkins server IP就是你电脑的IP，可以通过ifconfig命令获得，在结果的最后一行。

4. Jenkins新建并配置Maven项目：绑定Github的DemoProject
5. Jenkins运行Maven项目并查看结果

使用GoCD集成

GoCD是一种开源工具，用于软件开发，可帮助团队和组织使软件的持续交付/部署(CD)自动化。

完成后的效果，绿色的pipeline：

下载GoCD Server&Agent

Server和Agent

GoCD的基础架构由Server和Agent组成，Server 负责配置和控制，Agent负责执行。

Server：控制一切配置，关联仓库，触发pipeline执行，配置每个Job对应的Agent，将Job分配给Agent去执行，整理信息判断该Stage的状态。
Agent：接收Server分配的Job，执行Job下的Task（运行命令、部署等），并将Job的状态报告给Server。

打开GoCD官网下载页面, 根据系统下载：

这里我们下载19.9.0版本，所以点击下方 show old releases按钮，下载Server&Agent:

解压后放在新建的Pipeline文件夹下，就安装完成了：

启动Server&Agent

首先确保自己安装了Java11, 然后切换到server目录执行：

1	./bin/go-server console

启动GoCD Server:

Server启动成功后，默认的端口号是 8153/8154 (HTTPS)，访问 https://localhost:8154 就可以看到GoCD Server页面啦：

打开一个新的终端窗口，同样切换到agent目录执行：

1	./bin/go-agent console

启动GoCD Agent:

创建Pipeline

回到Server页面，点击页面按钮，创建Pipeline。

Pipeline: 管道，在GoCD里，Pipeline就像是一个工作流水线。它的结构如下所示：

首先指定Pipeline的Material，就是Demo Project在Github上的仓库地址：

Material

用来触发Pipeline的条件，可以是代码的存储仓库，可以是其他Pipeline某个Stage执行成功后的产出。在这里，我们把Github仓库作为Material，如果有新的改动会触发Pipeline重新运行。

接着输入Pipeline名字，自定义就可以。这里我设为Auto:

输入Stage名字，这里我设为Test：

Stage

pipeline可以有多个Stage，每个Stage按照顺序执行，一个Stage Fail，则不会执行后边的Stage，pipeline也会是Fail状态。比如常见的这几个stage: Build，Package，Deploy，Smoke，FunctionTest

创建job和tasks，这里创建了一个名为run_tests的job, 并给它加上一个task，脚本命令:mvn test

Job

一个Stage可以有多个Job，多个Job之间是相互独立的，一个Job失败，不会影响其他Job的执行，但是一个Stage中的任何一个Job失败，则这个Stage失败

Task

一个Job由一个或多个Task组成，且Task按照顺序执行，一个Task fail，则后续的Task都不会被执行。Task就是Script，用命令行对代码进行进行编译，部署，或者运行测试。

点击”Save + Edit Full Config”按钮，保存pipeline并进入pipeline的设置界面，可以看到，它是按照 pipeline(Auto)-> stage(Test) -> job(run_tests)的结构展示的，在job的Tasks tab中，也已经加上了我们上边设置的mvn test：

首先打开Auto pipeline设置，在Materials Tab下，可以看到我们设置的远程仓库地址：

接着点击上边的Url, 进入Edit Material页面，给Material加上一个Destination Directory，然后保存。因为在运行pipeline的时候，Server会从远程仓库克隆代码到Agent上去运行，需要设置Destination Directory，Server就会把克隆的的代码放进这个Destination Directory里，所以它的名字一般就是代码库的名字：

接着进入job设置页面，点击右边的Tasks Tab：

点击Custom Command按钮，进入Edit Custom Command task页面。将Working Directory设为我们刚才添加的Destination Directory，然后保存：

到这里，Pipeline就已经创建好了。

运行pipeline

运行成功

回到Pipeline首页, 点击Pause按钮，取消pipeline的暂停状态，取消之后pipeline就会自动运行了：

如果我们的代码没有问题，前面的设置也做好了的话，在运行过程中应该会跳出chrome/firefox窗口测试。pipeline就会运行成功了(绿色的标志)：

console log和本地目录结构解读

点击绿色状态条进入运行结果界面，里面有当前代码库的版本号，作者，以及comment信息；还可以在右侧看到运行历史，以后多次运行的时候，也可以看到之前的运行结果：

点击上图中的job名称run_tests，可以看到本次运行的console log:

观察console log我们可以理解pipeline的运行流程：

1. Server开始准备并克隆代码到Agent

上图中，Agent会生成Auto/1/Test/1/run_tests文件夹记录本次运行信息，然后，Server克隆远程代码到Agent对应的Pipeline文件夹下：

第一次运行之后，Server将会持续check远程仓库中的代码更新，并自动运行Pipeline，这是它的默认机制。
2. 设置环境变量

3. 在Agent运行task
准备工作做好之后，Server就会把Job分配给Agent去执行，这里是build代码并执行命令 mvn test , 输出内容在本系列第一篇博客介绍Maven的时候已经给大家剖析过了 :

4. Agent将运行结果报告给Server

Agent将记录本次运行信息的文件夹Auto/1/Test/1/run_tests，上传到本地Server文件夹下：

Artifact

Artifact是运行Job的产出物，在Agent生成，由Server接收并保存。存放在上图的 artifact 文件夹下。
比如此次运行中Agent生成的Auto/1/Test/1/run_tests文件夹，就是由Server接收保存的。它有一个保存运行日志console.log的cruise-output文件夹：

运行结束之后，在页面上也可以看到它：

利用Custom Tabs展示测试报告

我们已经理解了Artifact的概念，知道它是在Agent生成，由Server接收并保存的。

还记得我们在本系列第二篇博客中提到的 TestNG测试报告吗？它也是在Agent生成的，这里我们就新建一个Artifact来让Server接收Agent生成的TestNG测试报告，并利用Custom Tabs将它展示在页面上。

回到首页，点击Auto的设置按钮：

进入Job run_tests的Artifacts Tab, 添加一个Test Artifact:

这里的Source就是指Artifact在Agent的生成路径，由于Agent的Working Directory是AutoTest文件夹，所以这里我们用Agent本地文件夹的绝对路径 AutoTest/target/surefire-reports 来获得测试报告。
没错，Maven的surefire插件会帮我们保存TestNG测试报告index.html:

Destination就是Server存放测试报告的路径，这里是相对路径。我们指定TestResult文件夹来保存测试报告，它比较完整的路径是 run_tests/TestResult，和上文中artifact文件夹下的run_tests/cruise-output是同一级。

保存之后，切换到Custom Tabs下，新建TestResult Tab，用来展示我们获取的index.html文件，路径 TestResult/surefire-reports/index.html ：

保存，然后再次运行Pipeline:

运行完成之后，在console log可以看到Agent上传测试报告的过程，首先是把surefire-reports文件夹下的内容上传到Server的TestResult文件夹，然后还上传了Agent自己生成的index.html测试报告到系统默认的testoutput文件夹：

在Artifacts Tab可以看到多了两个artifact文件夹，TestResult文件夹是我们添加的，testoutput文件夹是系统默认生成的，它们都是test artifact：

图中一共有3个index.html文件，图片下方的index.html和testoutput/result文件夹里的index.html是Agent自己生成的测试报告，内容一致，默认会放在名为testoutput的Test Artifact文件夹里。展示在Test Tab下：

TestResult Tab里展示的是我们指定的surefire文件夹下的index.html文件：

其它的pipeline设置

以上都是最基本的GoCD使用，它还有很多比较高端的设置，这里再举几个例子。
1. Label Template
pipeline的build number可以自己配置，默认是1/2/3。实际项目中，build number一般会表示特定的含义，比如版本号等等：

2. Timer Settings
可以设置触发Pipeline的运行时间，有固定的语法，比如 ‘0 0 10 ? * MON-FRI’ 就是让pipeline在周内每天早上10点整运行：

3. Agent的Resource标签
当有多个Agent时，可能每个Agent有不同的配置，不同的空间大小，根据Agent的不同，可以通过设置Resource标签指定Job在某一类的Agent上执行：

谁把钱丢了