每日構建和冒煙測試
談每日構建都會連帶談冒煙測試這個詞。每日構建不是簡單的指每日編譯,編譯和構建完成后必須對增加的新功能點進行系統測試,對已經測試過的功能點進行冒煙測試。每日構建是微軟比較推薦的最佳實踐,強調測試的早期介入和持續的版本集成。
每日構建和冒煙測試的優點主要有:
1、進度可見并可以控制到1-2天的細粒度,很容易看到進度的偏差
2、及早的發現開發BUG和缺陷并分析解決,對開發人員的一種監督和促進,提高軟件質量
3、由于將大集成分解到每日構建中的小集成,避免了傳統產品集成或集成測試時候出現的嚴重問題的可能。
4、在項目中宣灌質量意識,強調第一次就把事情做好,而不是等測試來幫你發現問題
每日構建和冒煙測試也存在一些風險和缺陷,具體主要有:
1、給開發人員太大壓力,開發每天都在較緊張環境中工作
2、需要額外的測試人力資源和每日構建硬件環境的投入
3、開發人員不能專注,既要分心去修改BUG,又要開發新的功能點
4、對開發負責人要求更好,需要將功能細化到1-2天的有明確輸出的功能點
5、開發需要投入額外的精力來保證每日構建順暢
適用場景:
1、對進度偏差控制和要求很高的項目
2、開發檢查點和里程碑制定的很細致的項目
3、采用增量和迭代開發的項目,快速和敏捷開發的項目
每日構建提前需要進行的準備工作:
1、對開發進度計劃的要求,需要細化出每1-2天的開發進度計劃,可以到一個很小的功能點。
2、對每日構建測試計劃的要求,需要根據開發進度計劃來安排冒煙測試和系統測試進度計劃。
3、需要提前準備好每日構建的環境(每日構建必須是獨立的環境)
每日構建和冒煙測試工作的實現可以人工來實現,但更多的需要借助些自動化的工具來完成。對于每日構建一般要提前編寫好每日夠建的腳本,可以借助Ant或NAnt構建工具來完成。每日構建腳本的復雜性跟項目或系統本身復雜性相關,對于簡單的只有一個項目的解決方案,可能構建腳本會很簡單,而對于較復雜的系統或項目構建腳本將會教復雜。NAnt是一個強大的通過構建腳本自動編譯的工具,像我現在的項目在NAnt里面會做如下事情,而這個即使打開解決方案來編譯也無法做到。
1、調用批文件重新自動生成數據訪問層組件
2、創建相關的部署需要的cs_client,bs_client,server,service相關目錄并拷貝公用文件
3、按照公用項目->邏輯層->界面層順序和項目間依賴關系對各個項目逐一編譯
4、調用外部工具soapsuds生成數據訪問dll的代理類文件,邏輯層重新引用代理類進行編譯(分布式部署需要)
5、引用3,4步需要的dll對Web項目進行編譯
6、拷貝編譯結果到相關的輸出目錄
每日構建和每日編譯的最大區別就在于是否進行了冒煙測試,系統必須通過了冒煙測試才能夠算每日構建成功。而測試人員人工介入的測試是基于冒煙測試通過的基礎上面的。這里很簡單一個例子,如我們NAnt配置文件忘記拷貝一個公共文件到server目錄了,這個時候每日編譯可能是通過的,但如果把這個版本部署出去測試無法進行測試的。或者說冒煙測試的一個重要作用就是要徹底解決由于構建自身原因引起的各種缺陷或Bug。
冒煙測試由于要驗證整個編譯的正確性,因此冒煙測試必須是針對整個系統進行冒煙測試。但冒煙測試只需要關注系統的主體功能即可,通過冒煙測試并不是說系統沒有BUG,只是說通過了冒煙測試后可以說系統是一個穩定的版本,說系統的每日構建是成功了,代表系統可以轉交專門的測試人員進行測試了。冒煙測試工作一般要采用自動化來進行,可以借助如LoadRunner等工具來錄制自動化測試腳本,冒煙測試的腳本應該由專門的測試人員來維護,而且隨著測試的進展冒煙測試腳本也應該是不斷增加和補充的。
對于每日構建失敗,直接責任的開發人員需要程度責任并付出代價。微軟顧問經常愛舉的一個例子就是凌晨2,3點開發人員被叫到公司解決每日構建失敗的問題的案例。實際操作可能很難,但對構建造成影響的必須要承擔應有的責任。
每日構建一般要配合使用源代碼管理工具,而構建時間一般安排在每天下班后或晚上進行。開發人員需要保證每天檢入的代碼是能夠順利編譯通過的,并保證在本機已經做了相關測試。每日構建并不是一定要要求每天都有新的功能點完成,如果今天開發完成的東西不是一個獨立的可以提交測試的功能點,這個時候當天的源代碼最好不要檢入。代碼的檢入周期一般要在2-3天內,如果周期再長基本上就達不到每日構建的作用了。
每日構建必須有獨立和專門的構建服務器和構建環境。構建服務器和構建環境與測試環境的最大區別在于構建環境是完全Copy開發環境,單獨出構建環境目的是保證構建過程不和開發環境和過程沖突。如果條件不允許的話可以將構建環境和測試環境合并,但構建環境必須和開發環境分離。
每日構建的成功要素:
1、每天都進行編譯和冒煙測試
2、冒煙測試腳本隨著測試的進度不斷完善和補充
3、構建成功在項目中擁有較高的優先級
4、通過過程的制定保證構建失敗更多的是因為異常因素而非規則不清
5、在壓力下不要拋棄過程
posted on 2012-07-06 09:50 順其自然EVO 閱讀(861) 評論(0) 編輯 收藏 所屬分類: 管理方向 、defalut managerment system 缺陷管理系統