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

1、利用Hudson实现自动化测试的分布式执行2011年05月06日 下午03:48、概述目前，持续集成已成为当前许多软件开发团队在整个软件开发生命周期内侧重于保 证代码质量的常见做法。随着测试的自动化率逐步提高，每天要需要自动执行的测试用例也 就越来越多了，当我们发现，跑一次完整的测试需要几个小时，测试的速度已远远跟不上编 译的速度的时候，我们自然要考虑如何加快测试的速度了一一分布式执行测试用例，显然是一个不错的、；述如何利用Hudson来实现自动化测试的分布式执行。什么是持续集成简而言之，持续集成（Continuous Integration）是一种软件开发实践，即团队开 发成员经常集成它们的

2、工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生 多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽 快地发现集成错误。持续集成可以帮助我们做到：软件构建自动化持续自动的构建检查持续自动的构建测试构件生成后续过程的自动化关于持续集成的更多概念和知识，本文不做深入阐述，有兴趣的读者可以参考以下 链接：互联网行业应用持续集成实践持续集成相关术语解释关于 Hudson没错，Hudson正是一个能帮助我们实现持续集成的平台。确切来说，Hudson是一个 可扩展的持续集成引擎。主要用于：持续、自动地构建/测试软件项目监控一些定时执行的任务更多关于Hudson的介

3、绍和说明，请参考以下链接：持续集成工具Hudson基3分布式测试串行执行测试一般，我们会在Hudson上配置三个任务，分别是编译任务、快速测试任务、慢速（完 整）测试任务。这三个任务一般是顺序串行执行的，上一个任务执行完毕了之后，下一个任 务才能开始执行。化整为零？串行执行测试，当需要运行的自动化测试用例较多时，任务执行的速度显然不会让我 们满意，尤其是完整测试任务。如何加快执行速度呢？我们首先会想到的是，可以化整为零， 把slowtest任务（完整测试任务）分成多个小任务，这样，就可以在多台机器上同时执行， 从而加快执行速度了。tst-Build pngtest-Quicktettest-s

4、 lowtest 2、圮吕卜，1口砒成3然而，这样的做法，缺点也很明显一一测试结果也被拆分，而且维护成本较高：slowtest的测试结果被拆分到各个小任务里，测试结果不方便统一显示和分析。为达到最大速度，需要我们人工来把slowtest任务拆分成跟已有测试机器数量相等的测 试任务，如果测试机器的数量新增或减少了，就需要我们再次人工调整任务。需要我们人工来指定不同的测试用例，平均分给各个测试任务，如果测试用例数量发生变 化，也需要我们再次调整设置。分布式执行！一般的任务，是不能并发调度执行的，有多个构建请求时，即使有多个测试机器是空 闲的，也必须按时间顺序，一个接一个运行，典型的情况如下图所示。

5、(p-e-nding - Build #8 already in progress (ETA:2.1 sec)因此，上述化整为零的做法把slowtest任务拆分为多个子任务，从而达到多个任务 同时可以同时执行的效果。实际上，要加快自动化测试的速度，不一定需要多个任务同时执行一一我们只需要多 个构建同时执行。Hudson任务设置里有一个选项J. Execute concurrent builds if necessary beta)可以设置任务是否可以多个构建同时执行。我们把这个选项勾选上后，当同时有多个构建请 求时，只要有N个测试机器是空闲的，那就可以有N个构建同时执行！14 (p&nding

6、 - Waiting fornewt available executor n si 日 v吧-wi nxpi-l:已就-#13 空DLL-己-L： 312:25I q12理远程控制Hudson可以设置一个任务构建完成后自动触发另外的任务构建。这样，编译任务、 快速测试任务、完整测试任务可以自动地有序执行。然而，这样的自动触发任务构建，上游 任务只能对每个下游任务触发一次。那么，当我们的quicktest任务构建完毕后，如何触发 多个slowtest任务构建呢？难道只能手工在网页页面上点击“立即构建”吗？当然不是。在Hudson任务设置里，如下图，有这样的一个设置，勾选并填 写Authenti

7、cation Token”上之后，我们就可以使用这个Token编写脚本或程序来随时触 发一个任务的构建了。117 Trigger builds re motel/ (e.g., from scripts)Authentication Taken例如，用类似以下的Python代码，就可以触发一次” Your_Job”任务的一次构建。ijj_l=Hl.rl5LI N.URL + _/j cilij YU by1 bui 1 d? t ukt=rL=ycnii-_tu kenirrll 1L- w 1 cp en l.wl J如果” Your_Job”任务是带参数(见后文)的，可以用类似以下的代码触

8、发一次构建。ijj_l=Hl.rl5LI N.URL + _/j cilij YU Ly1 bui 1 dili, i 七HP ar ：=jti e + er e ? + 口虹口=注心-_七 cikenAp ：=lt ：=uri=p ：=cr ：=uti I -irrll 1 L- w 1 cp en l.wl J测试用例分配为了让slowtest任务的每一次构建能执行不同的自动化测试用例，我们需要指定该、.因 This build is param&terized任务为带参数的任务，在任务设置中勾选并指定相应的参数。例如，我们指定一个字符串参数名为suite，用于指定某一次构建是运 行哪一个

9、suite里的case。这样，在具体的某一次构建中，suite会以环境变量的方式存在。 当然，如果构建的时候没有指定suite参数，那么suite就会默认为None。This buid is parameterizedString ParameterName suiteDefault Value口日pti or要运行的即ite的名称这样，在一个任务的每次构建中，就可以根据环境变量suite的值去取不同的测试用例 来运行了。测试结果回收当分布式测试执行完毕后，slowtest的测试结果仍然被拆分到了多个构建之中，如何 把这些测试结果统一收集起来呢？例如，我们很可能需要把所有测试用例的运行生成的J

10、Unit格式的测试结果报表合并在 一起，即我们需要收集slowtest任务每一次构建所产生的xml测试结果文件。解决办法是，我们在slowtest任务里设置Hudson把我们需要的一些文件在构建完成后 打包存档起来。例如下图这样设置，则Hudson在每一次构建完成后，会将test_report文 件夹下的所有xml文件上传至服务器保存下来。I团 Publish JUnit test re-uIt reportTest report XMLs test repQrtV.xrnl这样，我们也就可以自己编写脚本或程序去获取这些文件了。例如，类似如下Python 代码，可以获得test-slowtes

11、t任务第67次构建所生成的所有文件，打包保存为tmp.zip。iurl2= HUIl E 匚IN.ICRL + J oti/ + est- slow 捉三 t/fiT;1 ：=： I tt/ + Hi E + _r ep or t/* zi p*/ trrip .zipileE= tnip. ziplUlLih- iniIre trilui-l,. dss)万事俱备至此，分布式执行自动化测试用例所需要的条件都已具备。一个具体的可行自动化测试分布式执行方案如下。tewt-huildprilwtest-guicktest博 mt - sl t wte&t- di 时 tuhX xt e t 1 w

12、t 巳号t- d itri b ut 巳 d足 stWuwt&s；t-repnrttest-build-onlyo编译任务，可以设置Hudson轮询SCM，每当提交代码至服务器后，此任务会自动触发。test-quicktesto快速测试任务，在编译任务成功完成后，自动触发，快速执行一些最基本的自动化测试用 例，确保新提交代码后，程序产品的基本功能没有问题。test-slowtest-dispatcho此任务在test-quicktest执行成功后自动触发，它所做的工作是把所有需要执行的自动 化测试用例分配为多个suite，并为每个suite触发一次test-slowtest-distribut

13、ed任务 的构建。test-slowtest-distributedo分布式执行的主要任务，可以多个构建同时执行，根据任务参数不同来执行不同的自动化 测试用例。test-slowtest-reporto分布式测试汇总任务，当test-slowtest-distributed任务在一次分布式执行中的所有构 建执行完毕后，此任务负责将这些构建产生的测试结果收集在一起。分布式方案如下图。BuildQuick TestFAQ & Tips在什么时候，怎样触发report任务呢？o可以为distributed任务再设定一个end参数，默认为空，在dispatch任务执行的脚本 或程序里，触发最后一个di

14、stributed任务的构建时，才指定该构建的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”，如 HYPERLINK http:/HUDSON/job/test/63/api%ef%bc%8c http:/HUDSON/job/test/6