基於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）