原文地址：http://blog.csdn.net/tony1130/article/details/4764085
測試
持續集成一直同自動化測試相關聯。這在馬丁福勒的文章或更早期Steven McConnell對日構建和冒煙測試的相關實踐描述中都有提及。而且在企業持續集成的領域中，我們會考慮很多種類型的自動化測試和手工測試。儘管如些，很多團隊在測試方面還是比較弱。很常見的一個版本發佈場景就是：某個團隊完成一個版本後，手工測試一下基本功能就發佈了。而其中的某一部分總是出錯，而新功能也只做了少量測試。如果團隊在測試方面比較成熟的話，他們能很快發現問題或缺陷，從而在生產率和信心方面都會有所增加。
目前，大多數團隊或多或少都會有某種形式的自動化測試。比如一小撮單元測試套件或一些腳本化的測試，用於確保軟件的基本功能是可以工作的。這些基本的自動化迴歸測試能夠較早及比較容易地發現那些基本功能性問題。入門級的團隊 通常剛剛開始習慣於做這種自動化測試。
爲了達到新手級成熟度 ，應該有一套快速測試在每次構建時都運行。這些測試給團隊增加了信心：軟件基本上在任何時間都能工作。測試一旦失敗，開發團隊會得到即時通知，從而在他們忘記這個問題的上下文之前就有機會去修復這些失敗的測試。因此，對於這一級別來說，對測試失敗通知的響應是非常重要的：如果一個團隊測試失敗卻不響應的話，那它應該低於測試成熟度的入門級。
中級成熟度 的團隊會在這些同快速構建同時執行的測試的基礎之上，擴大測試範圍。企業持續集成的成熟測試是以多種多樣的測試集合爲特性的。一箇中級團隊不僅有快速測試和手工測試，而且還有自動化的功能測試。中級團隊常常讓持續集成系統同時運行一些靜態源代碼分析。靜態分析可能不是每次都運行，但一定會週期性運行。而且一旦產生了某種嚴重的靜態質量問題的話，一定修復之後才能發佈。
進階級成熟度 是以“完整測試”爲標誌的。每種測試都提供其所能提供的最大價值。單元測試覆蓋了系統中所有複雜代碼與邏輯。功能測試覆蓋了系統中所有的重要功能。也會有邊界測試和隨機測試。同時，還要頻繁運行靜態代碼分析，並補充以工具支持的運行時分析和安全掃描來發現那些可能因測試不足或無法測試而遺漏的問題。測試可能被分配在多種系統下運行，以使能並行執行，從而提供快速的反饋。達到進階級需要相當大的投入，然而對於那些缺陷的成本很高且需要能夠保持高速前進的團隊來說，對是非常重要的。假如沒有這類需求的話，一般來說，中級可能是一個更適當的目標。
在極端的情況下（也就是瘋狂級成熟度 ），某些團隊追求100％的測試覆蓋率。儘管100%測試覆蓋率的定義在變化，但它反映出至少每行代碼都被測試覆蓋到。在某些軟件中，存在一個收益遞減的點，在這一點上，對某行代碼的自動化測試的價值要小對寫測試的成本。追求100%的測試覆蓋率意味着團隊會做一些浪費的測試，然而其目的有可能是阻止因某些測試很有價值但很難寫而不寫測試找藉口。滿足並保持100%的測試覆蓋率可能也是一個自豪感與動力的源泉。對於進階級團隊來說，如果曾經發現的確錯過了一些非常重要的測試的話，要求100%的測試覆蓋也未尚不可。但對於大多數團隊來說，簡直可以說是變態啦。