持續集成之“測試三角形與分段構建策略原則”

　　在《戲說Checkin Dance》一文中，咱們說到：Joe的團隊實施了帶有令牌的持續集成提交流程紀律。由于每個人都做本地構建進行驗證后再提交，所以持續集成平臺上的構建結果比較穩定，每天持續集成服務器上的構建最多只有一兩次失敗(常見的原因是忘記提交某個文件而導致失敗，和因本地環境配置與平臺環境配置不一致而導致失敗)，但一般都能在30分鐘內修復。隨著項目的進 行，新功能不斷地增加，自動化測試用例也越積越多。由于不做任何修改，本地構建腳本就會運行所有自動化測試用例，所以本地構建的運行時間也越來越長。團隊里有人開始抱怨，“每次提交代碼前，運行本地構建都超過15分鐘，這樣太浪費時間。我們可否把那些不太重要的測試拿出去，不再運行了?”

　　一、自動化測試黃金三角形

　　作為團隊的技術負責人，Joe把大家叫到一起，就這個問題進行了專門的討論。

　　“我們不能放棄運行這些測試。”Alice說道，“在我前一個項目中，我們就是這么做的，結果，這些花精力寫的測試都作廢了。”

　　“那是為什么呢?”?Bob問道。

　　Alice回答道：“因為并不經常運行這些測試，隨著功能的修改，有些測試的邏輯就不再是正確的了。而當再次運行發現這類問題時，通常的結果就是把這個測試刪掉，因為修復這個測試的工作量太大了。”

　　“那持續運行所有測試的話，等待的時間太長了，也是一種浪費呀。”Bob說道。

　　此時，作為團隊技術負責人的Joe說話了。“讓我們先分析一下，到底有哪些什么原因讓我們的測試在這么短的時間里就變成需要這么長時間了呢?”

　　“功能增加的多了，測試自然就多了唄。”

　　“功能增加了，自動化測試數據的準備工作也多了，需要的時間當然就長了。”

　　“現在我們的測試中有很多地方需要測試在原地等待結果返回，所以等待時間也挺長的。”

　　“大家還有沒有其它原因?”Joe追問道。

　　大家沉默了一會兒，Bob說道：“好象主要就這些原因吧”。

　　“那好吧。功能多而導致測試多這是好事兒，說明我們大家都非常重視我們的自動化測試。對于‘測試準備時間變長’這個問題可以理解，因為我們的產品越來越復雜了。對于‘結果返回的等待問題‘嘛，需要具體問題，具體分析。前幾天，我看到一個‘測試黃金三角形’，講的就是自動化測試中各類測試的應具有的比例關系，對我很有啟發。我在白板上畫一下吧。”于是，Joe走到白板前，將這個測試黃金三角形畫了下來，如圖1所示。

　　然后，Joe將這個圖形解釋了一下。原來，這個三角形講的就是單元測試、集成測試和驗收測試的關系。首先，左邊向上的箭頭表示，越高層次的測試維護成本越高，運行時間越長。因此，對于單個測試來說，單元測試運行最快，維護最容易，而集成測試次之，驗收測試則最高。每類測試的面積代表著該測試的數量?，F在，業界有很多種工具支持單元測試，因此它的編寫及維護成本相對其它兩種測試來說較低，應使用單元測試對代碼做盡可能多的測試覆蓋。一般來說，單元測試覆蓋率達到70~80%是比較理想的狀態。

　　接著，Joe問了大家一個問題：“我們產品中的這些自動化測試屬于哪一類測試?”

　　Alice說道：“那要看你怎么定義單元測試中的這個單元。”

　　“根據WikiPedia上的定義，一個單元是指應用程序中最小可測試的部分。既然我們使用面向對象的開發語言C++，那么單元測試的粒度應該是類中的一個方法吧。而且，通常來說，如果一個測試包括以下任何一個情形，它就不是一個單元測試：(1) 需要連接數據庫;(2) 需要網絡通信;(3) 需要與文件系統打交道;(4) 不能和其它單元測試同時運行;(5) 需要對環境進行一些配置(如編輯配置文件)才能運行它。”Joe回答道。

　　“要是這么說的話，我們的測試中，一部分是模塊集成測試，一部分是驗收測試，只有一小部分算是單元測試。我們的測試集合正好是一個倒三角。”Bob邊說，邊在白板上畫了出來，如圖2所示。

　　“既然高層次上的測試(集成測試和驗收測試)維護量比較大，今后我們應該加入更多的低層次測試(單元測試)，對于關鍵功能進行集成測試和驗收測試。如果對于測試用例具有等價性的話，我們應該用低層次測試來實現。這樣我們就會達到自動化測試的黃金三角狀態啦。”Joe邊說邊在白板上筆劃著，如圖3 所示。

　　“我同意你說法，但是仍舊沒有解決我們目前遇到的問題。如何解決我們現在本地構建時間太長的問題呢?”Alice有點兒不耐煩地問道。

　　二、分階段構建?

　　“這還不容易，Martin Folwer(敏捷宣言的創造者之一)已經給出了一個解決方案，那就是兩階段構建(Secondary Build)。也就是說，我們可以把那些運行比較慢，時間比較長且基本上不會失敗的自動化測試用例挑選出來，組成一個新的測試集，在第二階段運行，可以叫做‘二級構建階段’。剩余的測試集仍舊放在第一個階段運行，我們可以把第一個階段叫做‘提交構建階段’。”Joe回答道。

　　“那什么時間運行這兩個階段的構建呢?”Bob問道。

　　“提交階段構建當然就是在我們每個人提交之后就運行啦。而且在我們提交之前，作為本地驗證集合，在我們開發環境上也要運行同樣的提交構建。一般來說，本地構建和提交構建最好都在五分鐘內完成，最長也不要超過十分鐘，否則開發人員就不愿意花時間做頻繁地代碼提交啦。另外，一旦提交階段構建成功以后，就馬上自動觸發第二階段構建。而我們開發人員在持續集成服務器上的提交階段構建成功以后，就可以繼續進行其它的工作啦。”Joe說道，“我們原來的六步提交圖就變成這個樣子了。”說著，Joe拿起白板筆就畫了出來，如圖4所示。

原文轉自：http://kb.cnblogs.com/page/91338/