1 相關說明
1.1 背景簡介
hadoop分布式測試執行方案正是為了解決以上問題而産生，通過分布式執行，可以達到并行運作，提高執行效率的目的；另外，hadoop提供排程，重試等機制功能，可以提供給使用者一個相對透明的計算資源池，減少使用者對機器運作環境的依賴。
1.2 分布式平台的選擇
本方案采用hadoop來作為分布式平台。首先是hadoop是一個開源項目，有非常好的技術支援，二就是hadoop有成熟的分布式排程算法，可以很好的利用每台機器的cpu和記憶體資源，達到計算資源最優配置設定，三就是hadoop程式易于編寫，便于維護。
1.3 名詞解釋
：apache基金會的開源分布式架構。
mapreduce ：hadoop的計算模型，由map任務和reduce任務組成。
jobtracker ：hadoop計算系統的總控。
tasktracker ：hadoop計算系統的子節點。
slot(槽位) ：tasktracker的最小計算配置設定單元，一個槽位可以對應一個map任務，一個機器啟動一個tasktracker，槽位的話按照機器的cpu核數來配置設定，一般是”核數-1”。
2.1 傳統的單機測試執行流程
一般的單機測試流程分為5步，如下圖所示：
1、lib庫安裝。包括測試架構的lib庫安裝以及基于該測試架構的産品業務層lib。
3、case下載下傳。從svn或者case庫擷取需要執行的case。
4、case運作。
5、發送報告。
單機測試執行的優點在于邏輯簡單，易于實作，缺點就是case要串行執行，無法有效裡有機器的cpu和記憶體資源。舉個例子，現在有一個8核16g的測試機，每個case的平均cpu使用率為10%，記憶體消耗1g，在這樣的情況，一般可以做到至少6個case并行化，優化效率是不言而喻的。
2.2 從單機測試到分布式測試執行的邏輯
有了以上的五個步驟及相關分析，我們考慮其中可以并行執行來進行優化的就是測試執行這塊了，其他lib庫安裝，測試環境安裝等都基本是最小單元，不易切分了。
是以從單機到分布式主要是case執行集合的一個拆分。是以簡單說，單機和分布式的差別就是case輸入集合有變“而已，其他單機的測試執行過程基本不變。對于測試工程師來說，這個過程是透明的，隻是執行case的環境從單機切換到多機。
下圖簡要的表示了case從單機到多機的變化(6位的數字是caseid)。
<a href="http://www.51testing.com/batch.download.php?aid=46196" target="_blank"></a>
2.4 分布式測試叢集架構設計
整個分布式測試執行依托于一個公共的計算叢集，這個計算叢集由兩部分組成，一部分是hadoop相關的，包括hadoop的總控，子節點的tasktracker服務。另外一部分就是公共環境，包括測試架構，公共工具例如valgrind等。前者通過jobtracker來管理，後者通過統一運維系統來管理，其功能基本就是公共環境的安裝和維護。
3 收益
經過我們的實際項目實踐，這部分的收益主要展現在如下兩點：
1、測試執行時間大幅優化。15台機器的情況，所有原測試執行時間要1-2小時的子產品，優化到10分鐘以内。
2、機器資源的節省。通過公共叢集的維護，保證所有機器cpu滿負荷運作，避免了以往單機測試執行的cpu浪費。
4 準入原則及發展方向
4.1 分布式改造的準入原則
并不是所有的測試執行都可以分布式化，在我們的實際操作過程中，總結出以下幾點準入原則，供參考：
1、空白機器可運作。通過一個總控腳本就可以做到依賴環境準備，lib庫安裝，測試case執行等。
2、測試架構允許case并行。
3、業務層case對外部不存在固定依賴，例如依賴于某個寫死的目錄。
4、業務層case依賴的server端口，最好是随機的。
5、不允許業務層去操作公共環境。
4.2 後續可能的技術方向
1、case按照執行時間切分。按照時間切分來替代按照case數切分。
2、從分布式測試執行過渡到雲測試服務。
最新内容請見作者的github頁：http://qaseven.github.io/