摘要：本文將介紹持續集成在互聯網軟件項目中的應用及案例分析，主要針對互聯網行業軟件項目過程中的軟件測試效率和質量的研究與實踐；在當前Web2.0時代，筆者抓住互聯網行業的軟件測試特性，在軟件項目的開發過程中運用持續集成構建的思想來統一規范、流程和管理，不僅提升項目在提測之前的軟件版本質量，也有利于軟件項目過程的效率和質量風險控制。在淺談持續集成及工具在項目中的應用同時，也結合筆者從事互聯網軟件測試的工作經驗，進一步闡述與總結在軟件測試過程的持續集成帶來的益處與不足。
筆者會先介紹當前互聯網的軟件測試與傳統的軟件測試區別與聯系，然后針對互聯網軟件測試的特性再結合持續集成工具思想的運用，最后將比較詳細的介紹Hudson持續集成構建平臺在項目中的實踐與分析，從而解決了在多個項目并行開發的軟件項目中應該如何應用持續集成以保持項目整理開發過程的高質量和高效率問題。
關鍵詞：軟件測試；持續集成；自動化測試；
一、引言
在互聯網信息時代，隨著Internet的快速增長及Web應用的不斷發展，使其快速滲透到商業、電子商務、軍事、工業、教育等領域和個人生活的各個方面，對我們的生活及工作產生了深遠的影響。在當今市場需求和Internet技術進步的不斷推動下，Web應用日益增加，互聯網的軟件規模不斷擴大，復雜性增加，操作易用性降低，面對互聯網的用戶也越來越多，因此軟件的質量越來越成為人們共同關注的問題，作為保證軟件質量和可靠性的重要手段，軟件測試已成為互聯網軟件項目開發過程的重要環節。
在整個軟件生命周期中每個環節都存在軟件測試的活動，軟件測試伴隨著軟件開發，以檢驗每一個階段性的成果是否符合質量要求和達到預先定義的目標，盡可能早的發現問題并修復問題已成為當前互聯網時代軟件開發與測試過程的目的，也就孕育了要提高上游軟件質量，發揮測試工程師在軟件項目需求、設計階段參與的重要性。互聯網的信息和產品更新速度較傳統軟件產品是非常之快的，保證好軟件系統的質量和穩定性，運用敏捷的測試思維、測試工具來改變傳統的測試方法和測試觀念，正是在互聯網軟件實施過程中必須面對的。針對互聯網軟件開發的特點，筆者結合多年的軟件測試經驗與測試策略、工具，總結一些比較適用的方法、流程和工具綜合運用到互聯網軟件開發與測試過程中，綜合運用持續集成構建的思想進一步保證軟件質量和提升開發效率。
二、 現狀分析
目前在互聯網軟件開發測試過程中，存在效率低下、質量不高的情況，具體可以總結成以下幾個方面：
第一、RD編寫的代碼質量不高
開發工程師在編碼階段，經常犯一些比較低級的錯誤，致使提測版本的代碼質量較低，如空指針異常、重復犯錯及違背編碼規范等，常常會被在冒煙測試階段退回而重新開發，增加提測版本質量和效率的風險，也影響到項目整體開發進度。
第二、單元測試流程不規范，質量和覆蓋率較低
為了提高上游代碼質量，在開發過程增加了單元測試流程和規范，各部門產品線統一推廣與執行，實施一段時間后發現流程在各產品線執行執行的比較混亂，存在一些流程和規范細節問題，執行出現脫節，導致單元測試的代碼質量與代碼覆蓋率下降，在某些項目過程中暴露的非常明顯，較嚴重地影響了項目進度和質量。
第三、測試方法單一，測試策略陳舊，測試過程的效率和質量低下
項目過程，測試工程師從立項前的需求討論到立項后的需求、DEMO、設計評審和TC編寫幾乎全程參與，一定程度提升測試工程師在項目研發過程的地方和影響力，另外也帶來了測試方法單一和測試策略陳舊的問題，全靠手工測試已成為項目測試過程的瓶頸，往往就導致項目、需求排隊現象，進一步分析說明了我們的測試產出比低下，效率不高。
必須改變整個項目過程的測試方法，引入新的測試工具和測試策略，必須發揮自動化的力量緩解手工測試的瓶頸和解決效率低下的問題。
第四、上線后出現故障頻繁，bugfix需求增多
項目和小需求在互聯網行業中更新非常快，如果過程沒有更好的控制軟件風險的話，上線后的需求就會出現很多故障，導致用戶大量投訴，后續修復的工作量將投入很多資源去支持，一定程度上浪費了精力和物力，降低了生成率。
尤其是在大項目和新增需求發布上線后，故障的頻繁讓開發、測試心驚膽戰，不僅要處理手中新的需求，還要跟進線上故障的bugfix需求，使工程師的精力分散，增加了質量的風險。如何把故障減少下來，如何提升測試階段和開發前期的質量，已擺在工程師及主管們面前。
第五、無數據支撐來度量和評估開發和測試人員的質量和效率
軟件過程度量目前實施的還不規范，無基本度量的數據來支撐說明存在的問題，只能通過某階段某現象說明有問題存在，但無法給一個標準去度量和評估，這樣給軟件開發和測試過程的質量和效率評估帶來很多不便，如何收集過程數據，如何制定度量標準，還需要進一步在軟件開發過程進行分析與梳理。軟件過程度量也是為保證軟件質量的紐帶，其實這個專題研究的內容也是比較廣的，從軟件工程上來講，測試過程改進有很多模型參考，這里不展開說明。
三、互聯網軟件測試特性
在基于互聯網軟件系統開發過程中，通常就是以Web系統為基礎，按照B/S的訪問方式為主，包含客戶端瀏覽器、Web應用服務器、數據庫服務器的軟件系統，首先從技術實現上來說，一般的Web系統結構，不論是.NET還是J2EE框架，都是多層框架設計，有用戶操作界面層、業務邏輯層、數據驅動層；其次從結構上來講，都是有客戶端部分、傳輸網絡部分和服務端部分。
1、系統架構
一個比較典型的互聯網軟件系統的結構示意圖如圖-1，前端的用戶瀏覽器，通過網絡訪問應用服務器及數據庫服務器傳回的數據。
圖-1
2、互聯網軟件測試特點
1）不斷創新，改變易用性，留住用戶
在互聯網軟件開發過程中，我們往往關注點會集中在用戶體驗、軟件的創新及能為用戶帶來的價值，所以必須建立在用戶體驗基礎上進行創新，留住用戶，改變易用性，是互聯網軟件開發與測試的首要特點。
2）采用敏捷的開發測試思維，快速實現新功能，快速修復線上bug
基于創新的思維決定了我們在互聯網行業的軟件開發過程中，必須采取小步快走、版本微創新和快速獲取用戶反饋，只有這樣才能體驗客戶第一，改變軟件服務的對象觀念。第二個互聯網軟件開發測試的特點就是快，行業覺得要快速實現新功能并快速發布，快速修復線上存在的問題。
在很多互聯網公司，開發和測試團隊往往是技術團隊的主力軍，信息更新快捷和項目需求發布的頻繁，很多程度上與傳統軟件開發和測試過程分離開來，組成比較小的團隊進行軟件開發與測試，這樣有利于處理需求的響應速度的提升，也有利軟件開發過程的風險和資源管理。
3）采用的工具協助敏捷開發測試過程，提出了自動化測試
大家知道，如果縮短軟件開發和測試過程的時間，在保證需求質量的前提下，我們必須提供我們的過程效率，那么如何提高呢？這里就引起在互聯網軟件項目中的自動化測試，尤其在軟件測試過程，自動化測試不僅僅是測試技能的提升，更是能給測試工程師乃至整個研發團隊帶來質的價值和創新，是真正提高了整個研發過程的效率。自提出自動化測試以后，工程師不斷研究與實踐，發現自動化腳本與更新維護成本非常大，久而久之維護的工作量已超出預期評估時間，這樣導致要花大量的資源投入自動化維護，增加成本，經過大量項目實踐與分析，在互聯網行業的自動化不能是單純的基于頁面UI功能自動化，必須基于架構進行分層設計自動化，深化自動化技術和平臺化的服務，做到持續集成才更有效。
3、敏捷測試思維
通過了解互聯網系統架構和軟件開發測試過程，我們必須改變以往的測試思維和測試策略，抓住Web軟件測試的特點綜合選取更適合的方法去運用，直到提出持續集成構建，才在項目中慢慢推廣應用起來，其實就是采用敏捷的開發過程和測試思維相結合，把軟件開發整個過程質量控制提到上游。
四、持續集成介紹
1、持續集成是什么
大師Martin Fowler對持續集成是這樣定義的： 持續集成是一種軟件開發實踐，即團隊開發成員經常集成它們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。
在敏捷開發與測試中，持續集成是極限編程十二實踐之一（1999年Kent Beck編寫的《解析極限編程》），最初被使用極限編程方法的開發人員所推捧，并在過去的幾年中得到廣泛應用，成為業界廣為人知的軟件開發實踐。該實踐用于解決軟件開發過程中一個具體且重要的問題，即“確保當某個開發人員完成新的功能或修改代碼后，整個軟件仍舊能正常工作。”
簡單來說，持續集成是頻繁、持續的在多個團隊成員的日常工作中進行集成、驗證并反饋。一個典型的持續集成周期基本包含如下幾個步驟：
1）持續集成服務器不斷從版本代碼庫的服務器上檢查代碼狀態，看代碼是否有更新；
2）若發現代碼有最新的提交，集成服務器就會從版本代碼庫服務器下載最新的代碼；
3）等代碼完成更新結束后，持續集成服務器調用自動化編譯腳本進行代碼編譯；
4）運行所有的自動化測試；
5）進行代碼分析
6）輸出可執行的軟件，提高給測試人員進行最后的測試與驗證
7）通過測試工程師的測試與驗證，最后發布集成到發布
通過上面的持續集成構建步驟我們不難知道，其實持續集成就是一個循環、多次運用、統一檢查的過程，如圖-2所示描述
圖-2
2、持續集成模式
根據持續集成在項目中的運用與分析，從基礎搭建模式到企業級的解決方案模式，基本可以分成下面三種模式，它們分別是遞增的關系，在軟件開發中隨著系統的復雜度和測試件的可測性不斷改進的過程，最理想的持續集成達到是統一化、流程化和服務化的過程。
1）基礎模式
目前，有很多種持續集成工具，其中不乏開源產品，如Maven、Hudson平臺。項目伊始，我們可以建立自己的持續集成服務器，整個項目的持續集成基礎結構如圖-3所示：
圖-3
并發多個工程師進行代碼開發，每個工程師有獨立的開發環境和開發分支，然后統一提交到中央代碼庫，最后進行統一集成編譯。
2）階段式模式
在基礎模式的框架基礎上，我們增加軟件開發過程單元測試、靜態代碼檢查、UI功能自動化檢查，如圖-4
階段模式的持續集成較集成提升了很多，在集成server中增加了很多構建套件，綜合利用持續集成的特點進行統一管理。
圖-4
3）管道模式
階段式持續集成重復任務多，而過程化集成的管理復雜性太高了，任何過程化上的變化都要修改已經寫好的腳本，而這些腳本維護比較困難。既然以上兩種模式都不靈了，所以就引出了高級模式就是管道式的持續集成模式。
管道式持續集成形式上與過程化持續集成相類似，但卻在概念上有顯著不同。在管道式持續集成中，所有的過程單元都運行在同一管道的上下文中，即各單元所使用的原材料都是完成相同的，即代碼基線相同。當持續集成服務器發現有新的代碼時，會創建新的一個管道，所有的過程單元都在這一個管道中運行，包含編譯打包、單元測試、功能測試、性能測試和自動化測試。而每個單元產生的產物也在該管道中有效。如圖-5所示：
圖-5
不難看出管道模式的持續集成綜合了基礎模式和階段模式的優點，在管道式中，每次構建都會試圖從管道的一端走到另一端。因此，你不會遺漏任何一個版本的成功產品代碼，基本上可以使項目研發過程全部自動化了。
3、持續集成流程
一般在互聯網軟件開發和測試過程中，增加了持續集成構建，在開發和測試環節會進行多次集成與構建，做的比較好的公司，如google，微軟等，可以集單元測試、功能自動化測試等集成在一起構建，做到分支代碼變更腳本通知一條龍智能流程化和服務化，可見下圖-6流程所示。
圖-6
4、持續集成優點
通過上述概念和模式的闡述，讓讀者很容易發現持續集成最大的優點就是降低風險，提高項目研發過程的效率和質量，迎合在互聯網時代信息快速更新的現象。持續集成本身并不能幫助開發工程師找到bug，它是通過不斷的測試和反饋來盡早的發現缺陷，問題發現的越早處理問題的成本就越小越容易解決，由于無法證明通過了測試的代碼是無bug存在的，所以持續集成中的測試非常重要，好的測試能夠更多更快的發現當前版本中的錯誤。
往往在開發和測試過程中，軟件的缺陷是累積性的，當缺陷很多時，就很難發現它們，利用持續集成構建的思想，在項目過程中可以盡早的發現缺陷，最大限度的降低了我們在項目后期發現缺陷的可能性和偶然性。
每成功構建運行一次就意味著之前做的代碼提交可以成功集成，沒有與他人提交的分支代碼發生沖突，沒有帶來新的缺陷，有利于開發人員對項目保持自信心和提高工程師的工作激情。
持續集成在項目中的頻繁部署將會使最終部署的難度降到最小，用戶能夠看到頻繁上線的軟件，并做及時的溝通反饋，有助于增強互聯網模式下用戶的信心和動力，也有助于Web產品化和服務化朝著正確的方向快速發展。
5、持續集成構建分析及工具
在敏捷的軟件開發和測試團隊中，我們所要做的只不過是：不斷的回顧、找出問題與瓶頸、不斷地重構。通過不斷重構持續集成基礎結構以及自動化構建腳本，使其達到我們對“反饋時間”和“判斷質量準確性”的要求。另外，我們已將“持續集成”擴展到整個軟件開發周期，涵蓋了持續部署及發布。在上面的配置文件中，不難看出在管道模式中的兩個Stage分別名為 “UAT”測試和交付的“Production”，它們一個用于部署新版本到我們自己的持續集成服務器，另一個用于部署新版本到一個公用的持續集成服務器。部署 ‘UAT’的頻率為兩天到一周之間，‘Production’的頻率基本都是一周。這樣，我們可以得到快速反饋，改進自己的產品，同時其它團隊可以盡早地使用我們開發的新功能。
目前業界主流的持續集成工具主要有：Apache Continuum，CruiseControl，Hudson，Maven，LuntBuild等等，開源工具使用的比較多是Hudson框架。
五、Hudson介紹
1、Hudson簡介
是一個功能強大的持續集成框架，可以持續構建和測試軟件項目，并監控持續集成中生成的報告，屬于開源框架，可以進行多元化插件開發與集成。
框架的優點是基于WAR包，安裝部署非常簡單，提供了功能完善的Web管理界面和強大的報告輸出功能，另外就是有豐富的插件支持，并支持自動化安裝，便于維護。
2、核心應用
由于是開源框架，在項目實踐中可以不斷完善我們持續集成過程存在的問題，可以集成更多的插件解決我們想要自助的集成模式。
目前在筆者參與的項目中的核心應用主要有幾個部分：
1）靜態代碼檢查（Findbugs工具）
2）單元測試（Junit）
3）代碼覆蓋率檢查（Cov）
3、安裝與配置
開源框架，有便利的安裝指南，安裝起來非常快捷，主要步驟有：
● 下載Hudson WAR包
● 部署到Jboss服務中
● 安裝Html Report Plugin插件
● 安裝Cobertura Plugin插件
● 安裝Findbugs Plugin插件
● 創建分組視圖和用戶權限
配置也比較簡單，主要配置插件和SVN代碼及環境相關的條件，我們先看下配置插件，見下圖所示：
Cobertura配置（圖-7）
圖-7
Findbugs的配置（圖-8）
圖-8
在Hudson持續集成平臺中創建一個Job（圖-9）
圖-9
下面是配置代碼庫，以Svn代碼庫代碼管理為例（圖-10）
圖-10
后續進行配置定制執行任務和執行shell腳本，然后完成生成單元測試報告和生成代碼覆蓋率報告的配置，最后完成生產bug掃描報告和自動發生郵件提醒的配置，當然也開源插件集成到自動發到手機提醒。都配置完成后就可以進行build 運行查看配置信息的報告，如果都通過自己在項目中需求的話，基本配置就完成了，后續在項目中就能發揮Hudson平臺進行持續集成帶給我們價值。
六、 Hudson在項目中的應用
可以看出，持續集成的關鍵在于完成的自動化、完成的流程化，需要借助相關工具和平臺才能完成，所以持續集成環境的搭建需要花費比較大的精力，但是環境一旦搞定后，只需要花費很短的時間去維護，而且可以給我們項目開發和測試的效率帶來很大的回報。根據持續集成的重要實踐，下面以筆者工作中的實例，主要是在Hudson平臺進行持續集成進行應用和分析，在項目中的持續集成流程，詳見下圖-11說明
圖-11
下面以當前正在開發的一個項目（項目名稱為Campaign）為例說明Hudson在項目中的應用及分析，如圖-12所示：
圖-12
從Hudson持續平臺上截圖中可以看到，目前這個項目并行有5條分支（應用）在開發，平臺上很清晰的記錄了每個應用開發過程構建集成的記錄信息，如成功、失敗和持續的Time，圖中s列顏色分別代表了：藍色-集成構建通過，黃色-集成構建（冒煙失敗）不通過，還有一種紅色-集成構建過程編譯失敗或發生錯誤。
下面分別拿不通過和通過的兩個應用分支來看（Campaign-Bss和Campaign-Settle）
（一）先看Campaign-Bss（圖-13）分支集成情況：
圖-13
圖-13中標紅圈起來的我們一一說明和分析下：
● 左側表示：持續集成的歷史記錄，可以看出有紅色編譯失敗或錯誤階段到黃色冒煙失敗的build history記錄
● 右側表示：插件集成后檢查，如Findbugs（靜態代碼）檢查、靜態代碼檢查，單元測試和UI自動化覆蓋率檢查。圖-13中覆蓋率的圖很明顯隨著Build次數覆蓋率是提高的，也就是說最后的Build覆蓋率肯定比前一次要好，質量要高，直到達到約定的提測條件時且主干無failed的情況下才通過（主干無failed是只單元測試腳本在研發過程中可能有變更，如添加、修改和刪除，有運行失敗的風險，所以要求研發工程師要保證單元測試腳本每次Build后必須是100%Pass）
圖-14
● 進一步查看Coverage Report 我們不難發現更詳細的信息展現在我們眼前，如圖-14所示，比較詳細的輸出了工程包摘要，如Lines（代碼行覆蓋）這里統計代碼行共計525行，完成覆蓋245行，所以結果統計是Lines為47%
● 分析下下面圈起的信息是顯示代碼框架中（接口）實現類、方法的名稱（如dao層和bo業務的接口實現類等信息），其中com.ali.bp.bss.activity.dao.impl 在Conditionals為N/A（說明開發還未提交代碼集成），可以通過下面名稱詳細查看代碼覆蓋率覆蓋的情況
（二）再看Campaign-Settle（圖-15）分支集成情況：
圖-15
圖-16
Campaign-Settle分支集成通過后，總體無Findbugs增加，Lines覆蓋率為63%，從圖-15和圖-16中不難看出比Campaign-Bss分支集成后的質量要好。
通過這個項目的案例我們來做個小結與分析，從上面（一）和（二）持續集成分析報告來看，（二）的結果最終是集成成功且冒煙通過，而（一）被測試退回重新修復問題再等待集成驗證。我們通過Hudson這樣的一個持續集成平臺，規范了研發過程的集成測試流程，讓測試協助開發一起提升整個研發過程的質量和效率，提高軟件系統的上游質量。
很明顯目前我們在項目中運用的持續集成還沒有到達管道模式的一體化平臺，像UI功能自動化當前是在另外一個系統上運行，如果沒有通過在Hudson平臺配置的話，在持續集成平臺中是看不到運行結果報告的，另外還有一些插件有待后續進一步研究與實踐，像在C++框架模式如何實現Hudson持續集成目前還是調試實踐中，當然業績也有很多好的關于持續集成的平臺與案例學習與借鑒，還是希望能通過項目實踐證明持續集成能真正解決當前互聯網行業軟件開發模式存在的一些問題。
七、結束語
結合筆者在互聯網行業工作經驗，淺談了在前端基于java應用的軟件測試過程中，我們運用敏捷的開發和測試思想，采用Hudson持續集成構建平臺，整體打破了傳統測試思維，經過多個項目的實踐證明，采用持續集成提升了軟件開發和測試過程的質量和效率，提高了互聯網軟件生產效能。
我們說持續集成并不是一蹴而就的工作，要想真正做到管道的持續集成構建模式，需要在項目過程中不斷積累經驗來提升與改進，當然實施持續集成也是需要根據團隊的實際情況來實施，但這并不能成會“偷賴”的另一個說法。俗語道“沒有做不到，只有想不到”，只要不斷反思、重構與實踐總結，在互聯網軟件測試過程中創新每天都會出現。