持續集成:軟件質量改進和風險降低之道
問題
在軟件行業發展的初期,軟件項目中最棘手、最緊張的時刻就是集成。單獨能工作的一些模塊被組裝在一起,系統整體卻常常失敗,而且很難找到失敗的原因。
解決辦法
解決辦法的關鍵在于更為頻繁地進行集成。
它給項目帶來了完全不同的感覺。項目的可見性變得好了很多,因為問題能夠更快地檢測出來。引入缺陷和發現缺陷之間的時間間隔變短,就更容易發現缺陷,您可以很容易地看見改變了什么,以方便找到問題的根源。當它與良好的測試程序配合時,可以大大減少缺陷的數量。結果是,開發者在調試上花的時間減少了,在增加功能上花的時間更多了,他們相信自己是在一個堅實的基礎上開發軟件。
持續集成意味著:
● 所有開發者都先在他們自己的工作站上執行私有構建,然后再將他們的代碼提交到版本控制庫中,從而確保他們的變更不會導致集成構建失敗。
● 開發者每天至少向版本控制庫提交一次代碼。
● 集成構建每天在一臺獨立的計算機上進行多次。
● 每次構建都必須 100%通過測試。
● 生成可以進行功能測試的產品(如 WA R、配件、可執行程序等)。
● 修復失敗的構建是優先級最高的事情。
● 某些開發者復查構建生成的報告,如編碼標準報告和依賴分析報告,尋找可以改進的地方。
最佳實踐
為缺陷編寫測試
當缺陷被發現時,找出并隔離有問題的代碼,為了修復缺陷,我們基本上需要破壞測試,先編寫一個會失敗的測試用例,然后不斷執行這個測試(在修復缺陷的過程中),直到測試不再失敗為止。
讓組件測試可重復
數據庫對于測試來說是相當沉重的依賴關系,所以您有兩種選擇:要么盡量地進行模擬,在盡可能長的時間內完全避免使用數據庫,要么使用數據庫并承受其開銷。實現這種測試最容易的方法是使用某種xDbUnit 這樣的數據庫填充框架(如
針對.NET 的NDbUnit、針對 Java 的DbUnit 、針對 Python 的PDbSeed )。這些框架將數據庫的數據集抽象到 XML 文件中,然后為開發者提供細粒度的控制,即在測試過程中如何將這些數據填充到數據庫中。