1.1 引言
持續集成的價值是什么？對于開發和測試人員又意味著什么呢？
1.2 概念
“持續集成”一詞來源與極限編程（Extreme Programming）,作為它的12個實踐原則之一出現。
ThoughtWorks首席科學家、軟件開發領域大事Martin Fowler對持續集成是這樣定義的：持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味置頂每天可能發生多次集成。每次集成都是通過自動化的構建（包括編譯、發布、自動化測試）來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大的減少集成的問題，讓團隊能夠更快的開發內聚的軟件。
從上面的定義可以看出，一個典型的持續集成周期包括以下幾個步驟：
1版本控制服務器上有最新的代碼
2持續集成服務器從版本控制服務器下載最新的代碼
3等代碼完全更新以后，調用自動化編譯腳本，進行代碼編譯
4運行所有的自動化測試（單元測試、接口測試、系統級別的UI自動化測試等）
5將結果寫入報告文件中，反饋給團隊成員
6如果構建失敗，必須盡快修改確保下次構建成功
7產生可執行的軟件版本，提供給測試人員進行測試
持續集成框架是由代碼提交活定時來觸發的（項目級別的持續集成可以由開發每次代碼提交觸發，而產品級別的持續集成可以由定時來觸發），每次提交到版本控制服務器上的代碼都要經過自動化構建，確保每次的代碼變更都不會導致持續集成失敗。
1.3 目的和價值
持續集成的目的不是減少build失敗的次數，而是盡早發現問題，在最短的時間內解決問題，減少風險和浪費。從而讓產品開發流程更加敏捷，縮短產品開發周期，在產品上線后，讓用戶用得更加順暢。
在沒有應用持續集成之前，傳統的開發模式是項目一開始就劃分模塊，每個開發人員分別負責一個模塊，等所有的代碼都開發完成之后再集成到一起提交給測試人員，隨著軟件技術隊的發展，軟件已經不能簡單地通過劃分模塊的方式來開發，需要項目內部相互協作，劃分模塊這種傳統的模式的弊端也越來越明顯。由于很多bug在項目早期的設計、編碼階段就引入，到最后集成測試時才發現問題，開發人員需要花費大量的時間來定位bug，加上軟件的復雜性，bug的定位就更難了，甚至出現不得不調整底層架構的情況。這種情況的發生不僅僅對測試進度造成影響，而且會拖長整個項目周期。
而持續集成可以有效解決軟件開發過程中的許多問題，在集成測試階段之前就幫助開發人員發現問題，從而可以有效的確保軟件質量，減小項目的風險，使軟件開發團隊從容的面對各種變化。持續集成報告中可以體現目前項目進度，哪部分需要已經實現，哪些代碼已經通過自動化測試，代碼質量如何，讓開發團隊和項目組了解項目的真實狀況。
持續集成的價值有：
1易于定位錯誤。某一次集成失敗了，說明新加的代碼或修改的代碼引起了錯誤，很容易就可以知道誰負責的代碼出了問題，可以直接找相關人員來進行討論，分析。
2及早在項目里取得系統級成果。每次集成產生的版本都是一個可用的版本。
3改善對進度的控制。每次持續集成報告中可以體現目前項目進度，哪部分需求已實現，哪些還沒實現。
4改善客戶關系?？梢苑浅Ｃ鞔_的給演示項目進度（理由如上）
5更加充分地測試系統中的各個單元。每日構建和測試相結合帶來的好處
6能在更短的時間里構建整個系統
7有助于項目的開發數據的收集
8與其他工具結合的持續代碼質量改進。如與checkstyle，PMD、Findbugs等
9與測試工具或框架結合的持續測試。如LoadRunner等
10便于code review。每個build與前一個build之間有什么改動，針對這些改動可以有效的實現code review
1.4 持續集成流程圖
持續集成（Continuous Integration，CI）是一個長期而又敏捷的過程，在核心的CI可以分為兩大類，一類是產品級別的持續集成，產品級別的持續集成在發布日做到日構建。另一類也就是本文需重要描述的項目級別的持續集成。項目級別CI貫穿整個項目周期，從項目的FRD到發布后的跟進。下圖是項目級別的持續集成的流程圖，主要介紹項目使用CI的流程。
CI的介入是從立項的時候開始，前期是溝通和方案的定制，然后就是具體策略的執行，這里需要說明一下，CI不是獨立存在的個體，他會與測試范圍界定、缺陷分析等緊緊結合。
當拿到一個項目時，應該怎么做，在流程圖中已經說明了一切，首先是要做項目評估，如果項目適合做CI，然后就可以和項目組溝通，達成一直需指定方案計劃和資源評估方案，最后進行具體方案的實施。
圖中節點說明：
項目評估：
當我們參與一個項目的時候，需要評估下該項目是否適合做項目級別的持續集成，不是什么項目都可以做持續集成的。
根據業界的經驗，如何項目周期短，迭代次數少，這類的項目就不適合做持續集成，但還是要根據項目的特點進行評估。
溝通：
這是非常重要的一點，只有團隊達成一致，才能將CI持續下去，我們在達成一直的基礎上做約定和計劃，如果在溝通的過程中無法達成一致，那么個人建議不要進行CI，當然也要去分析為什么沒有達成一致。
計劃約定與資源評估：
在溝通達成一致的基礎上做出計劃約定和資源評估。
持續集成實施：
在溝通、計劃、約定的基礎上我們就可以運用工具和策略對起進行實施，具體的工具和實施在后面的章節會做說明。
2 持續集成方案與策略
在前面介紹了項目級別持續集成的流程，四個節點（項目評估、溝通、計劃與方案定制、持續集成實施）都非常的重要，項目評估、溝通、計劃與方案定制屬于前期的過程，也是基礎。本章重點介紹持續集成實施中持續集成的方案與策略、量化標準以及數據的采集。
2.1 持續集成策略
持續集成的實施肯定缺少不了策略，但我們應該使用什么樣的集成策略呢？如下圖所示：
持續集成的策略是采用技術手段為CI提供技術依據，做一個好的持續的項目最核心的是良好的單元測試編碼，集成測試編碼、系統測試編碼、web ui層自動化等不同level的自動化能力，安裝核心系統目前的情況來講，有些條件并不成熟。但我們可以反其道而行之，以項目持續集成為基礎，來推動某些條件（如單元測試、代碼規范）的良性循環，形成量的積累，使得持續集成條件逐步走上正軌。
2.2 單元測試集成
單元測試是持續集成中非常重要的組成部分。目前我們軟件質量部產品線的單元測試可以說是幾乎處于無的狀態。
目的與價值
單元測試（模塊測試）是開發者編寫的一小段代碼，用于檢驗被測代碼是否正確。通常而言，一個單元測試是用于判斷某個特定條件或場景下某個函數的行為是否按照預期結果進行。
單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程序員完成（TDD），也就是說，經過了單元測試的代碼才是已完成的代碼，提交產品代碼時也要同時提交測試代碼。持續集成中集成單元測試，每次迭代提交都保證單元測試的質量，那么產品的質量在一定程度上都得以保證。
所以單元測試在持續集成過程中是測試件中非常重要的組成部分。不可缺少，這也是CI過程要單元測試集成的目的和意義。
2.3 單元測試策略
集成測試項目中對單元測試策略采用如下：
1參與單元測試case設計
開發人員或測試人員進行單元測試編碼，測試設計人員參與case設計，因為我們設計case的角度和開發人員是不一樣的，測試人員的設計會更加全面。
2單元測試case的review
要進行單元測試case的review，如果發現不合適的case則要進行修訂。以保證單元測試的質量。
3單元測試的用例評審（單元測試完成階段）
與項目組成員或資深人員一起參與單元測試用例的評審，對不合適的用例需進行修改。
在持續集成過程中，如果發現單元測試的failed趨勢上升或failed達到某一標準時，需和開發人員溝通并修訂bug，從而保證每次迭代產品的質量。
2.4 適用范圍和階段
單元測試適合在開發人員進行單元測試編碼階段，一旦單元測試編碼完成，上述單元測試的測試都可以適用，貫穿于整個項目周期。
2.5 工具
既然有持續集成，那我們就需要用到一些持續集成的工具和平臺去分析每次的構建結果，在持續集成平臺（hudson）中集成了單元測試覆蓋率統計工具。參考后續內容。
2.6 量化指標
使用單元測試策略中我們會采集到一些數據指標，
3 接口測試集成
接口測試類似于單元測試，是分層自動化的重要組成部分，介于黑盒測試與白盒測試之間，在了解系統設計與接口定義對前提下，就可以在適當的時候運用mock來進行接口測試。
3.1 目的與價值
接口測試是質量的保證和效能的提升，所謂質量保證，就是深入到代碼的底層，可以對接口進行直接的參數注入，查看其返回結果，讓我們知道底層到底發生了什么。所謂效能的提升，就是程序的速度遠比手工的速度快，幾分鐘就可以跑完上百個用例。
接口測試不但可以提高測試效率，也不需要投入過多的精力去熟悉代碼邏輯，而且可以借助單元測試技術實現持續集成和每日構建。
3.2 接口測試策略
本文采用的接口測試主要是對系統提供的服務接口進行所有接口的覆蓋和集成，在覆蓋的過程中進行以業務為導向的codeReview。在持續集成運行的過程中發現bug，需與開發人員溝通后修訂bug，從而保證產品的質量。起測試方案如下：
1新增的接口進行case覆蓋和集成
2修改的接口進行case覆蓋和集成
3保證已有接口的正確
3.3 適用范圍和階段
接口測試和單元測試一樣，貫穿整個項目的周期。
1需求了解階段：了解項目中接口的功能，接口的輸入輸出參數及返回值，根據項目的情況決定是否做接口測試
2設計階段：了解接口的實現，并與開發溝通確定接口以怎么樣的形式進行暴露，從少先隊哪一層暴露。
3編碼階段：腳本編寫、數據準備、調試
4測試階段：
-接口參數完成和提交測試前，主要個工作就是：運行接口測試腳本進行測試，根據測試的結果與開發逐一過用例，以確定是代碼問題還是數據問題，直至所有的case均跑通。
-測試階段和分支回歸階段，利用集成測試平臺完成該接口的測試和部分的分支回歸工作，檢查測試結果
-發布回歸，利用持續集成平臺檢查測試結果
5 發布會
- 接口參數若有變化應及時維護腳本和數據
- 持續集成保證底層的質量
3.4 工具
- 接口測試涉及的工具主要是接口測試的開發和持續集成平臺。
- 開發工具例如eclipse
- 持續集成測試平臺hudson的配置和運行
4 UI 測試集成
4.1 目的和價值
UI自動化測試是通過直接操作指定的瀏覽器，對瀏覽器中的頁面對象、元素進行操作，完全模擬手工測試過程。項目中運行UI自動化測試的一個目的就是期望能利用自動化替代手工測試提升測試效率，通常在分支回歸階段使用，減少回歸投入時間；另一個目的是為了產品級UI自動化測試做基礎建設。產品級UI自動化測試在每日發布的回歸測試中使用，不僅能擴大回歸范圍，而且能幫我杜絕重要故障，保證產品重要業務流程的正確性。
2 UI測試集成策略
集成測試項目中對UI測試的策略采用如下：
1可行性分析及需求提?。簻y試負責人評估項目是否適合UI自動化覆蓋，并確認UI自動化覆蓋范圍。
2計劃安排：測試負責人平臺自動化腳本開發工作量，并且在測試計劃中加入
