一、概述
目前，持續內建已成為目前許多軟體開發團隊在整個軟體開發生命周期内側重于保證代碼品質的常見做法。随着測試的自動化率逐漸提高，每天要需要自動執行的測試用例也就越來越多了，當我們發現，跑一次完整的測試需要幾個小時，測試的速度已遠遠跟不上編譯的速度的時候，我們自然要考慮如何加快測試的速度了——分布式執行測試用例，顯然是一個不錯的辦法，本文正是講述如何利用Hudson來實作自動化測試的分布式執行。
二、基本概念
1.什麼是持續內建
簡而言之，持續內建（Continuous Integration）是一種軟體開發實踐，即團隊開發成員經常內建它們的工作，通常每個成員每天至少內建一次，也就意味着每天可能會發生多次內建。每次內建都通過自動化的建構（包括編譯，釋出，自動化測試)來驗證，進而盡快地發現內建錯誤。
持續內建可以幫助我們做到：
1. 軟體建構自動化
2. 持續自動的建構檢查
3. 持續自動的建構測試
4. 構件生成後續過程的自動化
關于持續內建的更多概念和知識，本文不做深入闡述，有興趣的讀者可以參考以下連結：
沒錯，Hudson正是一個能幫助我們實作持續內建的平台。确切來說，Hudson是一個可擴充的持續內建引擎。 主要用于：
1. 持續、自動地建構/測試軟體項目
2. 監控一些定時執行的任務
更多關于Hudson的介紹和說明，請參考以下連結：
1.串行執行測試
一般，我們會在Hudson上配置三個任務，分别是編譯任務、快速測試任務、慢速（完整）測試任務。這三個任務一般是順序串行執行的，上一個任務執行完畢了之後，下一個任務才能開始執行。
2.化整為零？
串行執行測試，當需要運作的自動化測試用例較多時，任務執行的速度顯然不會讓我們滿意，尤其是完整測試任務。如何加快執行速度呢？我們首先會想到的是，可以化整為零，把slowtest任務(完整測試任務)分成多個小任務，這樣，就可以在多台機器上同時執行，進而加快執行速度了。
然而，這樣的做法，缺點也很明顯——測試結果也被拆分，而且維護成本較高：
①slowtest的測試結果被拆分到各個小任務裡，測試結果不友善統一顯示和分析。
②為達到最大速度，需要我們人工來把slowtest任務拆分成跟已有測試機器數量相等的測試任務，如果測試機器的數量新增或減少了，就需要我們再次人工調整任務。
③需要我們人工來指定不同的測試用例，平均分給各個測試任務，如果測試用例數量發生變化，也需要我們再次調整設定。
3.分布式執行！
一般的任務，是不能并發排程執行的，有多個建構請求時，即使有多個測試機器是空閑的，也必須按時間順序，一個接一個運作，典型的情況如下圖所示。
是以，上述化整為零的做法把slowtest任務拆分為多個子任務，進而達到多個任務同時可以同時執行的效果。
實際上，要加快自動化測試的速度，不一定需要多個任務同時執行——我們隻需要多個建構同時執行。Hudson任務設定裡有一個選項
可以設定任務是否可以多個建構同時執行。我們把這個選項勾選上後，當同時有多個建構請求時，隻要有N個測試機器是空閑的，那就可以有N個建構同時執行！
4.遠端控制
Hudson可以設定一個任務建構完成後自動觸發另外的任務建構。這樣，編譯任務、快速測試任務、完整測試任務可以自動地有序執行。然而，這樣的自動觸發任務建構，上遊任務隻能對每個下遊任務觸發一次。那麼，當我們的quicktest任務建構完畢後，如何觸發多個slowtest任務建構呢？難道隻能手工在網頁頁面上點選“立即建構”嗎？
當然不是。在Hudson任務設定裡，如下圖，有這樣的一個設定，勾選并填寫”Authentication Token”上之後，我們就可以使用這個Token編寫腳本或程式來随時觸發一個任務的建構了。
例如，用類似以下的Python代碼，就可以觸發一次”Your_Job”任務的一次建構。
如果”Your_Job”任務是帶參數（見後文）的，可以用類似以下的代碼觸發一次建構。
5.測試用例配置設定
為了讓slowtest任務的每一次建構能執行不同的自動化測試用例，我們需要指定該任務為帶參數的任務，在任務設定中勾選
并指定相應的參數。例如，我們指定一個字元串參數名為suite，用于指定某一次建構是運作哪一個suite裡的case。這樣，在具體的某一次建構中，suite會以環境變量的方式存在。當然，如果建構的時候沒有指定suite參數，那麼suite就會預設為None。
這樣，在一個任務的每次建構中，就可以根據環境變量suite的值去取不同的測試用例來運作了。
6.測試結果回收
當分布式測試執行完畢後，slowtest的測試結果仍然被拆分到了多個建構之中，如何把這些測試結果統一收集起來呢？
例如，我們很可能需要把所有測試用例的運作生成的JUnit格式的測試結果報表合并在一起，即我們需要收集slowtest任務每一次建構所産生的xml測試結果檔案。
解決辦法是，我們在slowtest任務裡設定Hudson把我們需要的一些檔案在建構完成後打包存檔起來。例如下圖這樣設定，則Hudson在每一次建構完成後，會将test_report檔案夾下的所有xml檔案上傳至伺服器儲存下來。
這樣，我們也就可以自己編寫腳本或程式去擷取這些檔案了。例如，類似如下Python代碼，可以獲得test-slowtest任務第67次建構所生成的所有檔案，打包儲存為tmp.zip。
7.萬事俱備
至此，分布式執行自動化測試用例所需要的條件都已具備。一個具體的可行自動化測試分布式執行方案如下。
1) test-build-only
o 編譯任務，可以設定Hudson輪詢SCM，每當送出代碼至伺服器後，此任務會自動觸發。
2) test-quicktest
o 快速測試任務，在編譯任務成功完成後，自動觸發，快速執行一些最基本的自動化測試用例，確定新送出代碼後，程式産品的基本功能沒有問題。
3) test-slowtest-dispatch
o 此任務在test-quicktest執行成功後自動觸發，它所做的工作是把所有需要執行的自動化測試用例配置設定為多個suite，并為每個suite觸發一次test-slowtest-distributed任務的建構。
4) test-slowtest-distributed
o 分布式執行的主要任務，可以多個建構同時執行，根據任務參數不同來執行不同的自動化測試用例。
5) test-slowtest-report
o 分布式測試彙總任務，當test-slowtest-distributed任務在一次分布式執行中的所有建構執行完畢後，此任務負責将這些建構産生的測試結果收集在一起。
8.分布式方案
如下圖。
四、FAQ & Tips
在什麼時候，怎樣觸發report任務呢？
o 可以為distributed任務再設定一個end參數，預設為空，在dispatch任務執行的腳本或程式裡，觸發最後一個distributed任務的建構時，才指定該建構的end為True。在distributed任務執行的時候，如果end為True，再去觸發report任務，觸發方式當然也是用腳本或程式觸發。
report任務如何知道該收集distributed任務的哪幾次建構的測試結果呢？
o 可以由distributed任務通過傳遞參數的方式告訴report應該收集哪幾次建構的測試結果。到底該如何确定是哪幾次建構呢？Hudson定義了一些環境變量，我們在任務執行的shell或批進行中可以使用到。例如，可以在最後一次建構的時候，讀取環境變量BUILD_NUMBER，再設法确定本次分布式執行共有多少次建構，即可以知道哪些建構是report應該收集測試結果檔案的了~
report任務收集到的測試結果檔案，由于不對，Hudson不承認怎麼辦呢？
o 實際上，隻需要一個批處理指令即可以修改檔案的建立時間：copy *.xml+,,
report任務建構時，怎樣知道distributed任務所有的建構都已完成呢？
o 打開Hudson網頁，試試在網址後面加上“api”，如http://HUDSON/job/test/63/api，然後重新整理一下頁面，你将知道更多如何遠端操作Hudson的方法。
在環境變量中添加WinRAR的安裝路徑，即可以在批進行中使用WinRAR指令來解壓archive
Hudson會通過等待的方式來保證BUILD_NUMBER較小的建構會先完成。是以，妥善安排suite的順序和suite包含的自動化測試用例數可以提高測試速度哦~
可以限制一個任務隻能在某些機器上運作，也可以限制它隻能在具有某些Label的機器上執行~
五、參考資料
本文轉自 小強測試幫 51CTO部落格，原文連結：http://blog.51cto.com/xqtesting/1658859，如需轉載請自行聯系原作者