基于hudson持续集成的分布式测试解决方案

　　场景一

　　应用场景

　　适用于： quick任务(编译、单测)+ N个测试任务(每个测试任务执行部分的用例)。测试完成后只需要作xunit格式的报告的merger，不需要额外的汇总。如下图所示：

　　实现方法

　　※安装插件Copy+Artifact+Plugin

　　※设置机器Grid和任务Grid

　　※quick任务设置

※测试任务设置，每个任务执行前先设置获取上游任务产出

　　※每个测试任务的执行过程中，指定执行一部分的用例

　　※测试完成后，hudson会自动的在上游任务中把下游的任务的报告(例如xunit格式的报告)作merge。

　　注意

　　※上下游任务要Record fingerprints of files to track usage同一个文件。一般可设置为quick任务的编译产出

　　※下游任务失败时，通知上游任务的提交者，可使用插件Blame+Upstream+Committers+Plugin

　　场景二

　　应用场景

　　适用于： quick任务(编译、单测)+ N个测试任务(每个测试任务执行部分的用例)+ 汇总任务。测试完成后 不仅仅只需要作xunit格式的报告的merge，还需要有一个额外的汇总任务，这个汇总任务必须等所有的测试任务完成后才能执行。如下图所示：

　　实现方法

　　※安装插件 Join+Plugin

　　※quick任务设置

　　※其他设置同方案一

　　注意

　　如果汇总任务merge的报告还需要在quick任务中展现，则需要把报告传到quick任务的工作目录下。

　　场景三

　　应用场景

　　前面两个方案，有如下一些缺点：

　　※任务过多：包括quick任务+N个测试任务，不便于管理。

　　※用例数变化时需人工调整任务 ： 人工设置每个任务运行的哪些用例，那么在用例数发生了变化时，需要人工调整，很费时费力。

　　※任务并发度不可调 : 任务的并发度等于建立的子测试任务的数目，调整并发度，需要建立/删除任务，且要改quick任务的设置，很麻烦。

　　※任务时间差别大，形成短板 : 整个测试完成的时间实际上是等于执行时间最长的测试子任务的时间，时间不够优化。

　　針對上面的缺点，提出以下方案(quick任务+1个测试任务+动态挑选用例)，如下图所示

　　实现方法

　　※各个机器之间能相互发送拷贝文件(例如通过建立信任关系)，用于报告收集

※编译任务设置 设置报告 设置测试并发度

　　通过脚本访问URL触发 ${Test_Parallel} 次测试任务： HUDSON_URL/job/test/buildWithParameters?token=TOKEN_NAME&Upstream_path=work@host:~/path

　　※测试任务设置

　　设置构建参数(Upstream_path，测试完后发送报告到该路径汇总)，方法同上。

命令行触发构建 多次构建并行执行

　　每次构建执行先从用例库获取1个或部分用例，执行完后再次获取。

　　构建后将报告重命名为${BUILD_NUM}.xml，然后根据Upstream_path发送报告到编译任务所在机器 * 采用统一的方式管理所有的用例，根据请求返回1个或多个未执行的用例

　　※根据机器属性和任务执行要求，设置机器Grid和任务Grid

　　优势

　　更省时间、提高机器利用率、负载均衡、并发度可控、任务数少

原文转自：http://www.ltesting.net