0%

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

上篇博客我们已经完成了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上执行:

参考资料

打个赏嘛小主~