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

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

2、编译，发布，自动化测试）来验证，从而尽快地发现集成错误。持续集成可以帮助我们做到：软件构建自动化持续自动的构建检查持续自动的构建测试构件生成后续过程的自动化关于持续集成的更多概念和知识，本文不做深入阐述，有兴趣的读者可以参考以下链接：互联网行业应用持续集成实践持续集成相关术语解释关于没错，正是一个能帮助我们实现持续集成的平台。确切来说，是一个可扩展的持续集成引擎。，主要用于：，持，续1、.自，动地构建/测试软件项目，监，控2一.些，定时执行的任务，更多关于的介绍和说明，请参考以下链接：持续集成工具.串行执行测试一般，我们会在上配置三个任务，分别是编译任务、快速测试任务、慢速（完整）测试任务。这

3、三个任务一般是顺序串行执行的，上一个任务执行完毕了之后，下一个任务才能开始执行。.化整为零？串行执行测试，当需要运行的自动化测试用例较多时，任务执行的速度显然不会让我们满意，尤其是完整测试任务。如何加快执行速度呢？我们首先会想到的是，可以化整为零，把slowtest任务完整测试任务分成多个小任务，这样，就可以在多台机器上同时执行，然而，这样的做法，缺点也很明显测试结果也被拆分，而且维护成本较高：slowtest的测试结果被拆分到各个小任务里，测试结果不方便统一显示和分析。为达到最大速度，需要我们人工来把slowtest任务拆分成跟已有测试机器数量相等的测试任务，如果测试机器的数量新增或减少了，

4、就需要我们再次人工调整任务。需要我们人工来指定不同的测试用例，平均分给各个测试任务，如果测试用例数量发生变化，也需要我们再次调整设置。3.分布式执行！一般的任务，是不能并发调度执行的，有多个构建请求时，即使有多个测试机器是空闲的，也必须按时间顺序，一个接一个运行，典型的情况如下图所示。#9(p-e-nding-Build-#8薫alreadyinpragre&s(ETArZlsec)因此，上述化整为零的做法把slowtest任务拆分为多个子任务，从而达到多个任务同时可以同时执行的效果。实际上，要加快自动化测试的速度，不一定需要多个任务同时执行我们只需要多个构建同时执行。U任务设置里有一个选项J

5、Executecancurrentbuild百ifnecessarybeta)可以设置任务是否可以多个构建同时执行。我们把这个选项勾选上后，当同时有多个构建请求时，只要有个测试机器是空闲的，那就可以有个构建同时执行！14(paneling-WaitingfornextavailableaxeCLtornsi日g-winxp-t己三七-#13二ULI比-2弓Hl亍I亠#12201L-4-2孑4己0：丄已.远程控制U可以设置一个任务构建完成后自动触发另外的任务构建。这样，编译任务、快速测试任务、完整测试任务可以自动地有序执行。然而，这样的自动触发任务构建，上游任务只能对每个下游任务触发一次。那么，

6、当我们的Uickte任务构建完毕后，如何触发多个ote壬务构建呢？难道只能手工在网页页面上点击“立即构建”吗？当然不是。在u任务设置里，如下图，有这样的一个设置，勾选并填写”AuthenticationToken”上之后，我们就可以使用这个Token编写脚本或程序来随时触发一个任务的构建了。例如，用类似以下的th（代码，就可以触发一次”Your_Job”任务的一次构建。urXKUIlSH.URL+_/jctjYoBJbillId1!11ukeryoiu-Loknij-flliL.w1cpenl.wlJ如果”Your_Job”任务是带参数（见后文）的，可以用类似以下的代码触发一次构建。iurl=

7、Hl.IlELIH.URL+./jCiLjYoBy1bm1dili,1th?:辽ame+ere?+匚低紀匚yzir.七oksnAp：ir：ur匚p：=lt:hjti1m_l_iL-w1cpl.wlJ.测试用例分配任务的每一次构建能执行不同的自动化测试用例，我们需要指定该，一_,亠、”，一宀亠，一A,、r.EJThisbuildisparsme-terized任务为带参数的任务，在任务设置中勾选并指定相应的参数。例如，我们指定一个字符串参数名为行哪一个里的。这样，在具体的某一次构建中，当然，如果构建的时候没有指定为了让参数，那么i用于指定某一次构建是运会以环境变量的方式存在。就会默认为。This

8、buildisparameterizedStrfngNameParameter口efaultValueDescription这样，在一个任务的每次构建中，就可以根据环境变量的值去取不同的测试用例来运行了。测试结果回收当分布式测试执行完毕后，的测试结果仍然被拆分到了多个构建之中，如何把这些测试结果统一收集起来呢？例如，我们很可能需要把所有测试用例的运行生成的格式的测试结果报表合并在一起，即我们需要收集任务每一次构建所产生的测试结果文件。解决办法是,我们在任务里设置把我们需要的一些文件在构建完成后打包存档起来。例如下图这样设置，则在每一次构建完成后，会将文件夹下的所有文件上传至服务器保存下来。Pu

9、blishJLInittestre&uItreportTestreportXML各test_reportX-xrnI这样，我们也就可以自己编写脚本或程序去获取这些文件了。例如，类似如下代码，可以获得任务第次构建所生成的所有文件，打包保存为irrl2=Hl.fllEUN_l.rF!L+r1jobr1test-slowtest/1671：=Lft1f：ct.i+eet_report/*zip*丿tnip.zipiles=3trip.zipm-lliE-ui-lretrizfe(url,.des)测万事俱备至此，分布式执行自动化测试用例所需要的条件都已具备。一个具体的可行自动化测试分布式执行方案如下

10、。t亡5t-huilcl-cirilY馆或-口uiukt日吐tEmt-mlMtmst-dim口atuht亡st-slciwt已et-r亡port编译任务，可以设置轮询，每当提交代码至服务器后，此任务会自动触发。快速测试任务，在编译任务成功完成后，自动触发，快速执行一些最基本的自动化测试用例，确保新提交代码后，程序产品的基本功能没有问题。此任务在执行成功后自动触发，它所做的工作是把所有需要执行的自动化测试用例分配为多个，并为每个触发一次任务的构建。分布式执行的主要任务，可以多个构建同时执行，根据任务参数不同来执行不同的自动化测试用例。分布式测试汇总任务，当任务在一次分布式执行中的所有构建执行完毕

11、后，此任务负责将这些构建产生的测试结果收集在一起。8.分布式方案如下图。auildr?；tCiJickTestDispathDisrrihjzedR-epor:四、ip在什么时候，怎样触发p任务呢？可以为ii任务再设定一个参数，默认为空，在ipa任务执行的脚本或程序里，触发最后一个ii任务的构建时，才指定该构建的为。在ii任务执行的时候，如果为，再去触发p任务，触发方式当然也是用脚本或程序触发。p任务如何知道该收集ii任务的哪几次构建的测试结果呢？可以由ii任务通过传递参数的方式告诉p应该收集哪几次构建的测试结果。到底该如何确定是哪几次构建呢？定义了一些环境变量，我们在任务执行的或批处理中可以使用到。例如，可以在最后一次构建的时候，读取环境变量，再设法确定本次分布式执行共有多少次构建，即可以知道哪些构建是p应该收集测试结果文件的了p任务收集到的测试结果文件，由于不对，不承认怎么办呢？TOC o 1-5 h z实际上，只需要一个批处理命令即可以修改文件的创建时间：pp任务构建时，怎样知道ii任务所有的构建都已完成呢？打开网页，试试在网