場景一
應用場景
适用于： 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://hi.baidu.com/baiduqa/blog/item/d6a173315ef1f158ad4b5fec.html
【關注百度技術沙龍】