基于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
优点
更省时间、提升机器利用率、负载均衡、并发度可控、任务数少

 

(做者：ymao）

 

【本文转自 百度测试技术空间】 http://hi.baidu.com/baiduqa/blog/item/d6a173315ef1f158ad4b5fec.html

【 关注百度技术沙龙】