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

【 關注百度技術沙龍】