三、持續集成及其自動化編譯
"持續集成（Continuous Integration）"的概念來自于XP（極限編程）的一個實踐, 我們的開發模式是建立在CMM的基礎之上,引入了某些XP的概念，所以我們的思想是取各方面的精華來適合自己。
持續集成是指能夠自動的集成已經提交(Check-in)的代碼，直至發布到測試服務器供測試的整個過程。
1、實現自動化日構建需要做以下幾部分的工作：
2、將所有的源代碼保存在單一的開發服務器，讓所有人都能從這里獲取最新的源代碼（需要用配置管理工具存放源代碼: 如VSS/CVS/ClearCase）。
3、使創建過程完全自動化，讓任何人都可以只輸入一條命令就完成系統的創建。
4、使測試完全自動化，讓任何人都可以只輸入一條命令就運行一套完整的系統測試。
5、確保所有人都可以得到最新、最好的可執行文件。
6、自動化編譯： 為了能夠提供自動化測試，所以所有的代碼必須能夠實現自動化編譯。其實很多在做持續集成的公司都實現了改功能：如java程序可以采用在Ant + Junit 的基礎之上添加自己的功能既可以實現持續集成―――我們把這個工具叫：日構建
但很多公司并沒有實現對JSP的自動編譯，對于采用jsp編寫的web頁面，它是編譯執行語言，由于第一次執行要先編譯，即第一次的速度稍慢，如果要采用自動化測試工具winrunner進行功能測試時，則會失敗。因為自動化測試工具最基本的要求是：進入條件和出口條件必須在錄制與回放時完全相同。 2、持續集成最的好處：
完全可以取代人工的發布， 在J2EE中有個角色叫deployer., 它的主要工作就是經常發布新的系統供開發、測試，一般每發布一次至少要一個小時，如遇到一些問題一個上午就耗費掉了， 但使用“日構建”后就可以完全實現自動化，時間幾乎只等于編譯時間。
它完全避免了開發者們的"除蟲會議"--以前開發者們經常需要開這樣的會，因為某個人在工作的時候踩進了別人的領域、影響了別人的代碼，而被影響的人還不知道發生了什么，于是bug就出現了。
這樣的bug絕大多數都可以在引入的同一天就被發現。由于一天之中發生變動的部分并不多，所以可以很快找到出錯的位置。
持續集成可以把發現的錯誤根據源代碼的作者，以郵件和日志的方式分發給作者，第二天一上班的第一件事就是先修改錯誤。
持續集成可以減少集成階段"捉蟲"消耗的時間、 頻繁發布新版本的時間，從而最終提高生產力和軟件質量。
3、理想的持續集成的實現方法：
A)、同一個軟件產品要有集中的同一臺開發服務器，即所有人的最新的、各自編譯通過的源代碼都在配置管理工具如VSS中。
B）、有一臺運行主創建的機器，有計劃的運行日構建, 日構建中有一個創建進程，該創建進程是在一個隨時保持運行的Java類中進行的，如果沒有創建任務，創建進程就一直循環等待。
C）、守護進程將全部代碼（包括原程序和配置文件，數據庫腳本等）提取到創建機器的一個目錄中。提取完成之后，守護進程就會在這個目錄里調用Ant腳本。
D）、Ant會接管整個創建過程，對所有源代碼做一次完整的創建。Ant腳本會負責整個編譯過程，并把得到的class文件放進六個jar包里，發布到EJB服務器上。
創建結束之后，創建守護進程會給所有向最新一次創建歸還了代碼的開發者發一個e-mail，匯報創建的情況。
E）、當Ant完成了編譯和發布的工作之后，創建守護進程就會在EJB服務器上開始運行新的jar，同時開始運行BVT測試套件：即利用Junit進行單元測試。
單元測試完成后，日構建會把單元測試報告發給有錯誤的開發人員。
F)、為了利用自動化工具（WINRUNNER）進行功能測試，必須對JSP編譯，利用jspc命令進行包裝一層，就可以自動的對所有的jsp文件進行編譯， 但由于編譯jsp的時間非常長（越比編譯java代碼時間長），所以一般利用單獨的編譯服務器進行編譯。 發布編譯好的jsp文件進行自動化測試的成功率高（因為第一次運行jsp文件非常慢，而自動化測試最忌諱運行時和錄制時等待得時間不一樣）。 而功能性自動化測試也需要按計劃有順序的執行，這需要TestDirector測試管理系統來調度Winrunner進行測試。
讓所有的重復的繁瑣的事情都完全自動化，并且要經常進行集成，讓重復的測試自動化。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
