雷建胜,苏 晓,金明磊

(1.天津航天中为数据系统科技有限公司,天津 300301; 2.天津大学电气自动化与信息工程学院,天津 300072)

0 引 言

随着敏捷开发用户需求不断变化的需要，传统的瀑布模型已经逐渐被摒弃[1]，然而每当用户需求发生变化时，软件就需要进行全部功能的测试，由此产生了大量重复的测试任务[2-4]。而传统的人工测试不仅效率低下，且重复做同样的测试本身也会产生很多错误，因而有必要引入自动化测试，每添加一些新功能或修改旧功能时，测试人员都可通过调整测试脚本对软件进行自动化测试，保证修改后的产品可以在最短时间内发现问题并解决，大大地提高了开发效率，保证了软件质量，降低了后期的维护成本[5-7]。本文以Web网页端软件发开为例，说明基于Jenkins的分布式可持续集成自动化测试平台的设计与实现。

1 分布式可持续集成自动化测试的引入

Web软件测试的基本目的是尽可能全面地模拟被测软件需求的输入和点击操作，将其产生的结果与预期结果进行对比分析，寻找软件的bug。而通过自动化测试来实现各种输入和点击操作，修改功能的重复测试或添加后的回归测试可以大大地减少测试人力成本并且提高软件质量[8-10]。

然而传统的Web软件开发模式为开发人员和测试人员共用一套前后台服务，这样产生的问题是开发人员和测试人员无法同步开发，随着开发人员代码的不断提交，软件功能总是在变化，不利于自动化测试工作的开展，因此需要通过将代码分支线管理，每条支线建立一个服务，通过分布式持续集成的方式来解决该问题[11-15]。

将开发人员和测试人员使用的前后台服务分离开，定期自动进行代码更新构建，开发人员只关注代码的提交，而测试人员只需要关注当前软件版本的功能，无需考虑此时开发人员研发的新功能。这样可以大大地降低开发人员和测试人员之间的开发矛盾，提高软件开发效率[16-18]。

2 总体设计

2.1 系统总体架构

系统总体架构如图1所示,包括装有Jenkins服务的主节点、用于开发人员使用的开发节点服务器、为测试人员提供的测试服务节点、为测试节点提供前后台服务的测试节点服务器和测试通过后稳定运行的生产节点服务器[19]。

图1 系统架构图

1)开发节点服务器。为开发人员提供开发服务，是开发人员提交代码的唯一节点。该节点总是保持最新的软件版本。

2)提供测试服务节点。为测试人员的测试脚本提供前后台服务支撑，在测试人员编写完对应版本的自动化测试脚本后，将对应版本的代码从开发节点服务器合并至该节点，开发节点服务器是其代码的唯一来源。

3)测试节点服务器。保证测试人员开发完成的测试脚本按照设定的循环时间持续不断地重复运行，进行持续的自动化测试，用以寻找一些潜在的bug。

4)生产节点服务器。该节点的服务是为用户准备的，在功能开发和测试通过后，将对应通过测试的版本合并到该节点上，以供用户使用，并提出修改优化意见，更好地满足敏捷开发模式的需求。该服务器上运行的是通过测试后的稳定版本，为测试服务节点提供唯一的代码来源。

2.2 自动化测试流程

分布式可持续集成自动化测试的流程如图2所示：

1)开发人员进行软件业务开发，完成后向开发节点提交源代码，同时告知测试人员新的功能和旧的改动，之后开发人员继续进行下一步的开发。

2)测试人员根据新开发的功能进行自动化测试脚本的开发和调整，完成后将测试脚本提交到测试节点上，并从开发节点将对应版本的代码合并，并将代码提交到测试服务的节点上。

3)之后进行多次回归测试，并将发现的问题报告给开发人员进行修改，若没问题，则将代码合并到生产节点上供用户使用并提出修改意见，同时测试节点不断地进行回归测试并将所发现的问题报告给开发人员。

图2 分布式可持续集成自动化测试的测试流程

从图2可以看出，开发人员和测试人员互不干扰，并不会因为当前开发的新功能而影响测试人员的工作，而自动化测试脚本同时也可以持续不断地在测试节点服务器上使用测试服务节点提供的前后台服务并不断地进行回归测试，大大地降低了一些隐性bug的存在。

除此之外，相比于传统的手动测试来说，该模式下测试人员仅仅需要在代码版本库中控制系统代码版本的迭代更新和自动化测试脚本的开发即可，而不需要在版本迭代时人工处理各个服务节点的代码更新、打包和运行操作，对于前后台分离开发微服务的开发模式来说，优势是巨大的。将微服务中每个子服务的代码更新打包运行操作都交给Jenkins统一控制，减少了测试人力的消耗，将节省下来的测试人力投入到自动化测试脚本开发中，实现系统的自动化测试，提高系统测试次数和质量，大大减少系统的bug，提高软件质量。

2.3 总体原则

1)开发人员每天至少提交一次代码。

2)Jenkins每天对开发节点、提供测试服务的节点和生产节点进行一次集成构建，同时也支持人工手动构建。对测试节点进行轮询构建，运行测试脚本进行回归测试。在自动测试的基础上加上人工的一些辅助操作，可大大提高软件的测试效率，尽可能地减少软件bug。

3)开发节点向提供测试服务节点合并代码要在测试人员开发完测试脚本提交到测试节点之后，否则会因为新功能加入或者旧功能的修改无法匹配上一版本的自动化测试脚本而导致回归测试失败。

3 分布式可持续集成平台的搭建

3.1 创建节点

图3 分布式节点列表

项目的节点列表如图3所示,HSMB_DEV_BASE节点为开发节点，供开发人员使用，Katalon节点为测试节点，该节点轮询构建，不断地进行回归测试，HSMB_PER_UI_TEST节点为提供测试服务节点，供测试人员使用，为Katalon测试节点提供前后台服务支撑，HSMB_UI_TEST节点为生产节点供用户使用，用于提出优化意见和修改反馈。

3.2 配置节点

图4 节点配置

以开发节点为例，其他节点类似，如图4所示,将“用法”设置为“只允许绑定到这台机器的Job”，即只有在节点服务器中开启与Jenkins服务器的连接，该节点才可工作，对于Windows系统节点来说将“启动方式”设为“通过Java Web启动代理”。

图5 连接Jenkins服务器命令

如图5所示,Jenkins提供了2种方式使远端节点连接至Jenkins,分别为在浏览器中启动，或者在命令行中启动，本项目选取第二种方式，在图片最下方提供了一段命令：java-jar agent.jar-jnlpUrlhttp://10.0.4.151:9010/computer/HSMB-DEV-BASE/slave-agent.jnlp -secret 6ef578b5994772c6319be700bea9f-638610e2b7d7b1ae31bcd410617fa5748a0 -workDir "C://jenkins_workspace"。该命令是Jenkins提供的一段远程连接的命令，将该命令存储到.bat批处理文件中，并与Jenkins提供的agent.jar文件一起存放到节点服务器的同一路径下，先在节点服务器中运行批处理文件使节点连接到Jenkins服务器，然后Jenkins服务器便可对该节点进行代码更新并构建运行等操作。

3.3 创建任务并配置任务

创建4个新的构建任务,通过设置任务的Restrict where this project can be run属性将4个任务分别对应图3中的4个远端节点。Jenkins的构建周期采用了cron语法，包括5个字段(MINUTE HOUR、DOM MONTH、DOWHSMB_DEV_BASE、HSMB_PER_UI_TEST、HSMB_UI_TEST)的构建周期，采用H8***格式，即每天早上8点进行自动构建。而自动化测试需要持续地进行回归测试，因此Katalon节点设置为H8-17/2**1-5格式，即周一～周五从上午8点～下午5点每隔2 h进行一次自动化回归测试。

3.4 更新代码及构建

由于Katalon不支持集成到SVN上，因此采用Git作为测试人员和开发人员的版本控制工具，开发人员和测试人员分别将代码提交到代码版本库中，按照3.3节中设定的构建频率进行代码更新构建。

图6 部分构建命令

如图6所示,上半部分为HSMB_DEV_BASE、HSMB_PER_UI_TEST和HSMB_UI_TEST节点采用的构建方式，首先找到上一次构建的进程并结束，之后进入该服务的文件目录下。由于前后台服务采用的是微服务的架构，无法通过配置服务的Source Code Management属性进行代码更新，因此通过git pull命令进行代码更新[20-22]。同时采用mvn clean install进行打包编译形成最新的jar包后使用java -jar命令启动该jar包，图中完成了系统管理后台服务的启动，图6的下半部分为Katalon节点的构建命令，因为Katalon支持命令行运行脚本且只是一个服务，可以通过配置服务的Source Code Management属性来进行代码版本的更新，首先进入到项目的文件目录下，直接通过命令行运行不同的测试脚本来实现自动化测试，由命令“Test Suites/demo_test/AirportManage”可以看出图中运行的为机场管理模块的自动化测试脚本。

4 实施验证

本文的实施环境由1台运行Jenkins主节点的服务器和4台分别运行开发节点、测试节点、提供测试服务节点、生产节点的服务器组成。经验证，每天早上8点对开发节点、提供测试服务节点、生产节点自动构建。对测试节点每隔1 h进行自动构建，运行自动化测试脚本。构建成功的部分截图如图7所示。

图7 开发线构建成功图

图8 测试线构建成功图

图7和图8分别是系统开发线构建成功截图和回归测试线构建成功截图，从图中可以看出开发线每天上午8点21分进行代码的更新、打包，启动操作的构建。由于实际中并不会一直循环自动回归测试，对于项目测试来说也没必要，回归测试线设置在工作日每天从上午8点～下午5点之间每隔2 h进行一次自动回归测试即可。一天可回归测试4次，且这个时间是可以修改的，在项目后期如果需要可以随意调整测试次数。

以国家海洋局天空协同海上目标监测系统为例，该系统中的任务管理采用手动测试，之后在设备管理、数据管理和系统管理中引入了自动化测试技术，并将之前开发的任务管理也进行了自动化测试的开发。前后任务管理测试所需时间对比如表1所示。

表1 任务管理自动化测试及手动测试所需时间对比

由表1可知手动测试无需编写测试脚本。在编写测试用例和测试数据上，2种方法花费时间相同。在初次测试并分析结果时，自动化测试由于要调试测试脚本使其可正常运行，需要较长时间，而手动测试不需要编写测试脚本，只需手动测试一遍并记录分析测试结果，因此所需时间较少。但是在回归测试中，自动化测试只需要花费25 min的测试时间加平均5 min的分析记录结果总共30 min的时间，而手动回归测试和初次测试一样需要花费1天×1人的时间，可以看出在回归测试方面自动化测试速度相比手动测试在理想状态下快了48倍。

在当前敏捷开发的模式中回归测试是要经常进行的，对于手动测试来说也是消耗时间最多的工作，对于软件开发来说新添加的功能或者旧功能的改动总是会不经意间影响其他功能，因此想要保证软件质量，经常的回归测试是必不可少的，然而在项目后期由于资源时间有限，手动回归测试的次数是有限的，这时自动化测试的优势就很明显了，自动化测试只需要一次开发便可多次使用，在提高了测试次数的同时还减少了测试人员的重复工作量，在提升测试效率的同时还提高了bug发现率，大大提升了软件质量。

5 结束语

分布式可持续集成的自动化测试旨在尽可能地减少人力，减少开发者重复部署，减少测试人员重复测试，让更多的流程变得自动化，对于测试者来说更多的时间是投入到回归测试中，而本文通过Jenkins平台设计并实现了分布式可持续集成的自动化测试平台，在回归测试方面大大提高了测试效率，很好地满足了敏捷开发模式的需求，为项目开发的流程优化提供了新的思路。