利用Hudson实现自动化测试的分布式执行

1、概述
目前，持续集成已成为当前许多软件开发团队在整个软件开发生命周期内侧重于保证代码质量的常见作法。随着测试的自动化率逐步提升，天天要须要自动执行的测试用例也就愈来愈多了，当咱们发现，跑一次完整的测试须要几个小时，测试的速度已远远跟不上编译的速度的时候，咱们天然要考虑如何加快测试的速度了——分布式执行测试用例，显然是一个不错的办法，本文正是讲述如何利用Hudson来实现自动化测试的分布式执行。
2、基本概念
1.什么是持续集成
简而言之，持续集成（Continuous Integration）是一种软件开发实践，即团队开发成员常常集成它们的工做，一般每一个成员天天至少集成一次，也就意味着天天可能会发生屡次集成。每次集成都经过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。
持续集成能够帮助咱们作到：
1. 软件构建自动化
2. 持续自动的构建检查
3. 持续自动的构建测试
4. 构件生成后续过程的自动化
关于持续集成的更多概念和知识，本文不作深刻阐述，有兴趣的读者能够参考如下连接：
互联网行业应用持续集成实践
持续集成相关术语解释
2.关于Hudson
没错，Hudson正是一个能帮助咱们实现持续集成的平台。确切来讲，Hudson是一个可扩展的持续集成引擎。 主要用于：
1. 持续、自动地构建/测试软件项目
2. 监控一些定时执行的任务
更多关于Hudson的介绍和说明，请参考如下连接：
持续集成工具Hudson
基于hudson的持续集成 FAQ
3、分布式测试
1.串行执行测试
通常，咱们会在Hudson上配置三个任务，分别是编译任务、快速测试任务、慢速（完整）测试任务。这三个任务通常是顺序串行执行的，上一个任务执行完毕了以后，下一个任务才能开始执行。
 

2.化整为零？
串行执行测试，当须要运行的自动化测试用例较多时，任务执行的速度显然不会让咱们满意，尤为是完整测试任务。如何加快执行速度呢？咱们首先会想到的是，能够化整为零，把slowtest任务(完整测试任务)分红多个小任务，这样，就能够在多台机器上同时执行，从而加快执行速度了。
 

然而，这样的作法，缺点也很明显——测试结果也被拆分，并且维护成本较高：
①slowtest的测试结果被拆分到各个小任务里，测试结果不方便统一显示和分析。
②为达到最大速度，须要咱们人工来把slowtest任务拆分红跟已有测试机器数量相等的测试任务，若是测试机器的数量新增或减小了，就须要咱们再次人工调整任务。
③须要咱们人工来指定不一样的测试用例，平均分给各个测试任务，若是测试用例数量发生变化，也须要咱们再次调整设置。
3.分布式执行！
通常的任务，是不能并发调度执行的，有多个构建请求时，即便有多个测试机器是空闲的，也必须按时间顺序，一个接一个运行，典型的状况以下图所示。
 

所以，上述化整为零的作法把slowtest任务拆分为多个子任务，从而达到多个任务同时能够同时执行的效果。
实际上，要加快自动化测试的速度，不必定须要多个任务同时执行——咱们只须要多个构建同时执行。Hudson任务设置里有一个选项

能够设置任务是否能够多个构建同时执行。咱们把这个选项勾选上后，当同时有多个构建请求时，只要有N个测试机器是空闲的，那就能够有N个构建同时执行！
 

4.远程控制
Hudson能够设置一个任务构建完成后自动触发另外的任务构建。这样，编译任务、快速测试任务、完整测试任务能够自动地有序执行。然而，这样的自动触发任务构建，上游任务只能对每一个下游任务触发一次。那么，当咱们的quicktest任务构建完毕后，如何触发多个slowtest任务构建呢？难道只能手工在网页页面上点击“当即构建”吗？
固然不是。在Hudson任务设置里，以下图，有这样的一个设置，勾选并填写”Authentication Token”上以后，咱们就可使用这个Token编写脚本或程序来随时触发一个任务的构建了。
 

例如，用相似如下的Python代码，就能够触发一次”Your_Job”任务的一次构建。

若是”Your_Job”任务是带参数（见后文）的，能够用相似如下的代码触发一次构建。

5.测试用例分配
为了让slowtest任务的每一次构建能执行不一样的自动化测试用例，咱们须要指定该任务为带参数的任务，在任务设置中勾选
并指定相应的参数。例如，咱们指定一个字符串参数名为suite，用于指定某一次构建是运行哪个suite里的case。这样，在具体的某一次构建中，suite会以环境变量的方式存在。固然，若是构建的时候没有指定suite参数，那么suite就会默认为None。
 

这样，在一个任务的每次构建中，就能够根据环境变量suite的值去取不一样的测试用例来运行了。
6.测试结果回收
当分布式测试执行完毕后，slowtest的测试结果仍然被拆分到了多个构建之中，如何把这些测试结果统一收集起来呢？
例如，咱们极可能须要把全部测试用例的运行生成的JUnit格式的测试结果报表合并在一块儿，即咱们须要收集slowtest任务每一次构建所产生的xml测试结果文件。
解决办法是，咱们在slowtest任务里设置Hudson把咱们须要的一些文件在构建完成后打包存档起来。例以下图这样设置，则Hudson在每一次构建完成后，会将test_report文件夹下的全部xml文件上传至服务器保存下来。
 

这样，咱们也就能够本身编写脚本或程序去获取这些文件了。例如，相似以下Python代码，能够得到test-slowtest任务第67次构建所生成的全部文件，打包保存为tmp.zip。

 

7.万事俱备
至此，分布式执行自动化测试用例所须要的条件都已具有。一个具体的可行自动化测试分布式执行方案以下。
 

1) test-build-only
o 编译任务，能够设置Hudson轮询SCM，每当提交代码至服务器后，此任务会自动触发。
2) test-quicktest
o 快速测试任务，在编译任务成功完成后，自动触发，快速执行一些最基本的自动化测试用例，确保新提交代码后，程序产品的基本功能没有问题。
3) test-slowtest-dispatch
o 此任务在test-quicktest执行成功后自动触发，它所作的工做是把全部须要执行的自动化测试用例分配为多个suite，并为每一个suite触发一次test-slowtest-distributed任务的构建。
4) test-slowtest-distributed
o 分布式执行的主要任务，能够多个构建同时执行，根据任务参数不一样来执行不一样的自动化测试用例。
5) test-slowtest-report
o 分布式测试汇总任务，当test-slowtest-distributed任务在一次分布式执行中的全部构建执行完毕后，此任务负责将这些构建产生的测试结果收集在一块儿。
8.分布式方案
以下图。

 

4、FAQ & Tips
• 在何时，怎样触发report任务呢？
o 能够为distributed任务再设定一个end参数，默认为空，在dispatch任务执行的脚本或程序里，触发最后一个distributed任务的构建时，才指定该构建的end为True。在distributed任务执行的时候，若是end为True，再去触发report任务，触发方式固然也是用脚本或程序触发。
• report任务如何知道该收集distributed任务的哪几回构建的测试结果呢？
o 能够由distributed任务经过传递参数的方式告诉report应该收集哪几回构建的测试结果。到底该如何肯定是哪几回构建呢？Hudson定义了一些环境变量，咱们在任务执行的shell或批处理中可使用到。例如，能够在最后一次构建的时候，读取环境变量BUILD_NUMBER，再设法肯定本次分布式执行共有多少次构建，便可以知道哪些构建是report应该收集测试结果文件的了~
• report任务收集到的测试结果文件，因为不对，Hudson不认可怎么办呢？
o 实际上，只须要一个批处理命令便可以修改文件的建立时间：copy *.xml+,,
• report任务构建时，怎样知道distributed任务全部的构建都已完成呢？
o 打开Hudson网页，试试在网址后面加上“api”，如http://HUDSON/job/test/63/api，而后刷新一下页面，你将知道更多如何远程操做Hudson的方法。
• 在环境变量中添加WinRAR的安装路径，便可以在批处理中使用WinRAR命令来解压archive
• Hudson会经过等待的方式来保证BUILD_NUMBER较小的构建会先完成。所以，妥善安排suite的顺序和suite包含的自动化测试用例数能够提升测试速度哦~
• 能够限制一个任务只能在某些机器上运行，也能够限制它只能在具备某些Label的机器上执行~
• 点击我能够查看关于Hudson预设的环境变量。
5、参考资料
【1】. Hudson官网 http://hudson-ci.org/

(做者：yejinxin)

 

【 本文首发于： 百度测试技术空间】 http://hi.baidu.com/baiduqa/blog/item/4d35629747f48c5cd1135eb3.html

【 关注百度技术沙龙】