一、概述
       目前，持续集成已成为当前许多软件开发团队在整个软件开发生命周期内侧重于保证代码质量的常见做法。随着测试的自动化率逐步提高，每天要需要自动执行的测试用例也就越来越多了，当我们发现，跑一次完整的测试需要几个小时，测试的速度已远远跟不上编译的速度的时候，我们自然要考虑如何加快测试的速度了——分布式执行测试用例，显然是一个不错的办法，本文正是讲述如何利用Hudson来实现自动化测试的分布式执行。
二、基本概念
1.什么是持续集成
       简而言之，持续集成（Continuous Integration）是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。
       持续集成可以帮助我们做到：
1. 软件构建自动化
2. 持续自动的构建检查
3. 持续自动的构建测试
4. 构件生成后续过程的自动化
关于持续集成的更多概念和知识，本文不做深入阐述，有兴趣的读者可以参考以下链接：
互联网行业应用持续集成实践

2.关于Hudson
      没错，Hudson正是一个能帮助我们实现持续集成的平台。确切来说，Hudson是一个可扩展的持续集成引擎。 主要用于：
1. 持续、自动地构建/测试软件项目
2. 监控一些定时执行的任务
更多关于Hudson的介绍和说明，请参考以下链接：
持续集成工具Hudson

三、分布式测试
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.分布式方案
    如下图。

四、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预设的环境变量。
五、参考资料
【1】. Hudson官网 http://hudson-ci.org/