隨著自動化測試在軟件行業的不斷深化以及持續集成的興起，幾乎所有的軟件都在不同程度上采用了自動化測試的方法，并且越來越多的軟件公司在軟件開發上引入了持續集成的方法，然而，隨著軟件迭代的次數的不斷增多，軟件質 量要求的不斷提高，傳統的自動化測試已經不能滿足項目開發過程中對自動化測試效率的要求，所以中培偉業就該問題探討了一種解決方案，即將持續集成引入自動化測試。中培期望通過這樣的結合，能夠很好地提高現今軟件行業中的測試效率。
一、什么是持續集成（Continuous Integration）？
　　這個概念到底是怎么定義，說實話很多不同的版本。這里我就把我理解的什么叫持續集成說下，其實持續集成是為了配合敏捷開發的速度和效率而產生的一個用于編譯、測試、發布、部署的工具。為什么叫持續呢？其實就是編碼人員提交了源碼，那么該工具就可以進行編譯，測試等一系列運作。怎么能夠讓編碼人員很快的知道編碼的異常。
二、工具的選擇 ：Maven2、 Hudson（CruiseControl可以考慮）、SVN
　　首先我們來看看這個環境是怎么運作的吧！ 編碼人員將代碼提交到SVN，那么Hudson就監控到SVN有更新，那么Hudson就去SVN取出更新的源碼。取出后就交給Maven去編譯、測試、發布等操作。
　　所謂的持續集成通俗一點兒說：就是指對于開發人員的每一次代碼提交，都自動地把Repository中所有代碼Check out到一個空目錄，并且自動運行所有Test Case。如果成功則接受這次提交，否則告訴所有人，這是一個失敗的Revision。
　　更具體的解釋可以參考Martin fowler的Continuous Integration  。
二、持續集成的價值與成本
　　有句時髦的話，叫做“存在即為合理”。既然持續集成已經存在了這么長的時間，而且沒有消失的跡象，那就是有價值的東西。
那么它的價值何在？有人概括如下：
　　(1) 減小風險；(2) 減少手動過程；(3) 生成構建結果；(4) 安全感。
　　而持續集成的成本在于對持續集成代碼的維護成本和集成的時間成本。因為隨著項目進行，軟硬件環境會越來越復雜，成品代碼也會不斷膨脹。此時，需要團隊而修改或增加原有的測試代碼，以適應這些變化，同時，每次集成所需時間也會變長，這就是持續集成的成本。
　　某個blog中提道：“這種集成是如此的頻繁，多少次的代碼Commit就有多少次持續集成。前提是集成的成本很低，或者說是完全自動化的。”
三、持續集成應該自動化什么呢？
　　我們要以盡可能少的成本來獲得盡可能多的價值。這就要考慮哪些自動化是必要的啦。
　　Jez Humble提到至少有六點要做到自動化，
　　它們分別是(1)自動化的運行測試；
　　(2) 自動產生可部署的二進制成品；
       (3) 自動將成品自動部署到近似生產環境；
       (4) 自動為CodeBase打上標簽；
       (5) 自動運行回歸測試；
       (6)自動生成度量報告。
四、持續集成服務器的選擇
　　在進行持續集成實踐前，應當正確的選擇并配置持續集成服務器。比較成熟的持續集成服務器包括：CruiseControl, Anthill, Bamboo, TeamCity, Continuum 等。CruiseControl作為開源產品，以其對于各種SCM（源碼管理，制造業上是供應鏈關系管理）以及構建工具的廣泛支持而被許多開發團隊所接受。而開發自動化專家 Duvall 采用一致的評估標準和很多說明性示例，介紹了一些開源 CI 服務器，包括 Continuum、CruiseControl 和 Luntbuild。并指出“要根據 自己的 具體技術和政策需求對工具進行分析”。并用以下五個指標來評估CI工具，它們分別是：(1)  特性；(2)  可靠性；(3)  壽命；(4) 目標環境；(5) 易用性。結果如下表：
五、只有持續集成服務器是遠遠不夠的
　　正如Jez Humble所說，CruiseControl和其它的CI工具本質上只不過是一個定時器，時間一到，做你讓它做的事情。所以，必然要有其它工具與其結合，方顯持續集成的本色。這些工具又是什么呢？
　　想測試的話，你就要用一些測試工具，如JUnit，JWebUnit，Selenium等等；
　　想檢查代碼標準的話，你就要用checkstyle等代碼規范檢查工具；
　　想要了解測試覆蓋率的話，你可能就要用到JCoverage。
　　當然，想得到二進制文件，就要用到Ant，Make之類的工具啦。
六、最重要的事：實踐與反思
　　也許這些東西大家都知道，而且有些人可能已經實踐過啦。無論這些實踐的結果是怎樣的，一定不要忘記總結和反思。如果這些實踐成功了，不要把它歸功于這個工具，而是要總結一下為什么會成功，如果你愿意的話，還可以和大家分享一下。如果這些實踐失敗了，也不要把它歸功于這個工具，而是要反思一下，是否正確地使用了這個工具，團隊成員是否都喜歡這個工具，為什么？