每日構造與冒煙測試

每日構造與冒煙測試

文章出處： 作者：Steve McConnell 釋出時間：2005-11-12

      如果你想建立一個隻包含一個源程式檔案的簡單程式，那麼你隻需要編譯、連接配接那一個檔案就可以了。如果是一個團隊項目組，有着許多甚至上千個源程式檔案，那麼要建立一個可執行程式的過程就變得更複雜、更耗時。你必須用各種各樣的元件将程式逐漸建立起來。

在微軟或其它一些軟體公司中慣例是：每日構造并做“冒煙測試”。每天都對已完成的源程式進行編譯，然後連接配接組合成可執行的程式，并做“冒煙測試”，以簡單的檢查該執行程式在運作時是否會“冒煙”。

      帶來的好處

      雖然這是一個非常簡單的過程，但卻有非常重要的意義：

      1、能最小化內建風險

      項目組可能遇到的一個很大的風險是，項目組成員根據不同的系統功能各自開發不同的代碼，但是當這些代碼內建為一個系統的時候，也許系統完成不了預期的功能。這種風險的發生取決于項目中的這種不相容性多久才被發現，由于程式界面已經發生了變化，或者系統的主要部分已經被重新設計和重新實作了，相應的排錯工作将非常困難和耗時。極端情況下，內建的錯誤可能回導緻項目被取消掉。每日構造和冒煙測試可以使這種內建錯誤變得非常小，而且便于解決，防止了很多內建問題的産生。

      2、能減小産品低品質的風險

      這種風險是和內建不成功、內建出錯相關聯的。每天對內建的代碼做一些少量的冒煙測試，即可杜絕項目中那些基本的品質問題。通過這種方式，使系統達到一種周知的良好狀态，維護這樣的系統可以防止系統逐漸惡化到耗費大量時間排查品質問題的地步。

      3、能簡單化錯誤診斷

      當系統每天都進行build和測試時，系統任何一天發生的錯誤都能夠變得十分精細，便于排查。比如在17日系統還運作正常，18日就出錯了，那麼隻需要檢查這兩次build之間的代碼變化就可以了。

      4、能極大鼓舞項目組的士氣

      看到産品的不斷成長，能夠極大的鼓舞項目組的士氣，有時甚至不管這個産品到底用來做什麼。開發人員可能會為系統顯示了一個矩形而感到激動。通過每日構造，産品每天進步一點點，保證項目士氣的持續高漲。

      進行每日構造和冒煙測試

      雖然說這是一個簡單枯燥的活，每天進行build，每天進行測試，但也有着一些值得注意的細節：

      1、每天堅持

      每日構造，最重要的就是“每日”。如Jim McCarthy所說，把每日構造看作是項目的“心跳”，沒有“心跳”的話，項目也就死了(Dynamics of Software Development, Microsoft Press, 1995)。Michael Cusumano and Richard W. Selby描述了另外一種隐含的比喻，把每日構造比作項目的“同步脈沖”(Microsoft Secrets, The Free Press, 1995)。 不同開發人員寫的代碼在他們的“脈沖”之間肯定都會存在“同步”的差異，但是必須有這樣一個“同步脈沖”，使得這些代碼能夠組合為一個整體。當項目組堅持每天把這些不同的“脈沖”組合到一起的時候，開發人員脫離整體的情況就會得到極大程度的杜絕。

有些項目組把這一過程簡化為“每周build一次”。這樣帶來的問題是，某一次build失敗後，可能要回溯好幾周才能找到原因。如果這種情況發生的話，已經得不到經常build帶來的好處了。

      2、嚴格檢查每一次build

      要保證每一次build的成功，就必須保證build後的結果（也可稱為build）是可以正常運作的，如果build不可運作，那麼本次build被認為是不成功的，同時應該将修複此次build的工作提高到項目組最進階别來處理。

      對于如何衡量一個build，每一個項目組都會定義一些自己的标準，這些标準需要設定一個嚴格的品質級别來處理那些特别嚴重的缺陷，同時也需要具有一定的伸縮性來忽略掉那些微不足道的缺陷，一些不适當的關心也許會使整個過程舉步為艱。

      一個好的build起碼應該具備以下條件：

      ●能夠成功編譯所有的檔案、庫，以及其它相關元件；

      ●能夠成功連結所有的檔案、庫，以及其它相關元件；

      ●不能存在任何使得系統無法運作或者運作出錯的進階别故障；

      ●當然，必須通過冒煙測試

      3、每天進行冒煙測試

      冒煙測試應該是對整個系統流程從輸入到輸出的完整測試。測試不必是面面俱到的，但是應該能夠發現系統中較大的問題。冒煙測試應該是足夠充分的，通過了冒煙測試的build就可以認為是經過充分測試、足夠穩定的。

不進行冒煙測試的build是沒有太大價值的。冒煙測試就像一個哨兵，在阻止着産品品質惡化和內建問題的産生，不進行冒煙測試，每日構造可能會變成浪費時間的練習。

冒煙測試必須随着系統的擴充而擴充。最初，冒煙測試可能是非常簡單的，比如驗證系統是否會列印“Hello World”，随着系統功能的擴充，冒煙測試需要越來越充分。最初的冒煙測試也許隻需要幾秒鐘來執行，逐漸地，測試可能會花費30分鐘，1小時，甚至更長。

      4、建立一個專門的build小組

      在很多項目組，維護每日構造，并更新冒煙測試用例，會耗費一個人工作的大部分時間。是以在一些大的項目中，這項工作獨立成不止一個人來完成的全職工作。比如在 Windows NT 3.0的研發中，就有一個由四個全職人員組成的專門的build小組(Pascal Zachary, Showstopper!, The Free Press, 1994)。

      5、為build增加修訂，如果這樣做有意義的話

      一般開發人員不會每天都經常向系統中快速的增加實際的代碼，通常是每隔幾天，他們在開發好完成某個功能的一套代碼以後，然後內建到整個系統中。

      6、規定一些導緻build失敗的懲罰措施

      很多執行每日構造的項目組都會規定一些懲罰措施，來懲罰那些導緻build失敗的行為。從最開始，項目組成員就清楚的知道，build的正常執行是項目組的頭等大事。一個失敗的build是項目組的意外，無法成為項目組工作的準則。必須堅持：導緻build失敗的同僚，必須停下手中的工作，首先來解決build失敗的問題。如果一個項目組的build經常失敗的話，久而久之的，再來談build的正确性就沒有意義了。

      有種輕松的懲罰措施，能夠突出解決問題的優先性。Some groups give out lollipops to each "sucker" who breaks the build. This developer then has to tape the sucker to his office door until he fixes the problem. 有些項目組會懲罰犯錯的同僚戴上山羊角，或者向一個項目基金捐獻5塊錢。

      有些項目組對此的懲罰就有點殘酷了。微軟的開發人員，在一些知名度很高、很重要的産品如Windows NT，Windows 95，Excel等産品後期研發中，被要求随時帶着尋呼機，如果你的代碼導緻build失敗的話，即使是淩晨3點鐘，也會要求你立即來處理這個問題。

      7、即使在壓力下也需堅持每日構造和冒煙測試

      當項目進度的壓力越來越大時，維護每日構造的工作看起來有些浪費時間，但是恰恰相反。在壓力之下，開發人員丢掉一些平時的規定，會采用一些設計和實作的捷徑，這在平時壓力較小的環境下一般時不會用的。代碼的review和單元測試也可能會比平時粗心一些，這些代碼的狀态變化也會比平時快很多。

      為防止這種情況的出現，每日構造會堅持相關的規定，讓壓力下的項目保持在正軌上。代碼仍然每天在不斷變化，但是構造過程使得這種變化每天都可控。

      誰能夠從每日構造這種過程中得到好處呢？一些開發人員會抗議說，由于他們的項目太大，每天進行build是沒有實際意義的。但是為什麼現在最複雜的軟體項目組卻能夠成功的執行每日構造的制度呢？本文首發時，Windows NT包括了560萬行代碼、分布在4萬個源程式檔案中，項目組仍然可以堅持每日構造。

本文轉自 xkdcc 51CTO部落格，原文連結：http://blog.51cto.com/brantc/116417，如需轉載請自行聯系原作者