基于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.anti-gravitydesign.com