1.1 引言
持續(xù)集成的價值是什么？對于開發(fā)和測試人員又意味著什么呢廉羔？
1.2 概念
“持續(xù)集成”一詞來源與極限編程（Extreme Programming）,作為它的12個實踐原則之一出現(xiàn)妙色。
ThoughtWorks首席科學家、軟件開發(fā)領(lǐng)域大事Martin Fowler對持續(xù)集成是這樣定義的：持續(xù)集成是一種軟件開發(fā)實踐成艘，即團隊開發(fā)成員經(jīng)常集成他們的工作梧喷，通常每個成員每天至少集成一次，也就意味置頂每天可能發(fā)生多次集成拉背。每次集成都是通過自動化的構(gòu)建（包括編譯师崎、發(fā)布、自動化測試）來驗證椅棺，從而盡快地發(fā)現(xiàn)集成錯誤犁罩。許多團隊發(fā)現(xiàn)這個過程可以大大的減少集成的問題，讓團隊能夠更快的開發(fā)內(nèi)聚的軟件土陪。
從上面的定義可以看出昼汗，一個典型的持續(xù)集成周期包括以下幾個步驟：
1版本控制服務器上有最新的代碼
2持續(xù)集成服務器從版本控制服務器下載最新的代碼
3等代碼完全更新以后肴熏，調(diào)用自動化編譯腳本鬼雀，進行代碼編譯
4運行所有的自動化測試（單元測試、接口測試蛙吏、系統(tǒng)級別的UI自動化測試等）
5將結(jié)果寫入報告文件中源哩，反饋給團隊成員
6如果構(gòu)建失敗，必須盡快修改確保下次構(gòu)建成功
7產(chǎn)生可執(zhí)行的軟件版本鸦做，提供給測試人員進行測試
持續(xù)集成框架是由代碼提交活定時來觸發(fā)的（項目級別的持續(xù)集成可以由開發(fā)每次代碼提交觸發(fā)励烦，而產(chǎn)品級別的持續(xù)集成可以由定時來觸發(fā)），每次提交到版本控制服務器上的代碼都要經(jīng)過自動化構(gòu)建泼诱，確保每次的代碼變更都不會導致持續(xù)集成失敗坛掠。
1.3 目的和價值
持續(xù)集成的目的不是減少build失敗的次數(shù)，而是盡早發(fā)現(xiàn)問題治筒，在最短的時間內(nèi)解決問題屉栓，減少風險和浪費。從而讓產(chǎn)品開發(fā)流程更加敏捷耸袜，縮短產(chǎn)品開發(fā)周期友多，在產(chǎn)品上線后，讓用戶用得更加順暢堤框。
在沒有應用持續(xù)集成之前域滥，傳統(tǒng)的開發(fā)模式是項目一開始就劃分模塊，每個開發(fā)人員分別負責一個模塊蜈抓，等所有的代碼都開發(fā)完成之后再集成到一起提交給測試人員启绰，隨著軟件技術(shù)隊的發(fā)展，軟件已經(jīng)不能簡單地通過劃分模塊的方式來開發(fā)沟使，需要項目內(nèi)部相互協(xié)作委可，劃分模塊這種傳統(tǒng)的模式的弊端也越來越明顯。由于很多bug在項目早期的設計格带、編碼階段就引入撤缴，到最后集成測試時才發(fā)現(xiàn)問題刹枉，開發(fā)人員需要花費大量的時間來定位bug，加上軟件的復雜性屈呕，bug的定位就更難了微宝，甚至出現(xiàn)不得不調(diào)整底層架構(gòu)的情況。這種情況的發(fā)生不僅僅對測試進度造成影響虎眨，而且會拖長整個項目周期蟋软。
而持續(xù)集成可以有效解決軟件開發(fā)過程中的許多問題，在集成測試階段之前就幫助開發(fā)人員發(fā)現(xiàn)問題嗽桩，從而可以有效的確保軟件質(zhì)量岳守，減小項目的風險，使軟件開發(fā)團隊從容的面對各種變化碌冶。持續(xù)集成報告中可以體現(xiàn)目前項目進度湿痢，哪部分需要已經(jīng)實現(xiàn)，哪些代碼已經(jīng)通過自動化測試扑庞，代碼質(zhì)量如何譬重，讓開發(fā)團隊和項目組了解項目的真實狀況。
持續(xù)集成的價值有：
1易于定位錯誤罐氨。某一次集成失敗了臀规，說明新加的代碼或修改的代碼引起了錯誤，很容易就可以知道誰負責的代碼出了問題栅隐，可以直接找相關(guān)人員來進行討論塔嬉，分析。
2及早在項目里取得系統(tǒng)級成果租悄。每次集成產(chǎn)生的版本都是一個可用的版本谨究。
3改善對進度的控制。每次持續(xù)集成報告中可以體現(xiàn)目前項目進度恰矩，哪部分需求已實現(xiàn)记盒，哪些還沒實現(xiàn)。
4改善客戶關(guān)系外傅〖退保可以非常明確的給演示項目進度（理由如上）
5更加充分地測試系統(tǒng)中的各個單元。每日構(gòu)建和測試相結(jié)合帶來的好處
6能在更短的時間里構(gòu)建整個系統(tǒng)
7有助于項目的開發(fā)數(shù)據(jù)的收集
8與其他工具結(jié)合的持續(xù)代碼質(zhì)量改進萎胰。如與checkstyle碾盟，PMD、Findbugs等
9與測試工具或框架結(jié)合的持續(xù)測試技竟。如LoadRunner等
10便于code review冰肴。每個build與前一個build之間有什么改動，針對這些改動可以有效的實現(xiàn)code review
1.4 持續(xù)集成流程圖
持續(xù)集成（Continuous Integration，CI）是一個長期而又敏捷的過程熙尉，在核心的CI可以分為兩大類联逻，一類是產(chǎn)品級別的持續(xù)集成，產(chǎn)品級別的持續(xù)集成在發(fā)布日做到日構(gòu)建检痰。另一類也就是本文需重要描述的項目級別的持續(xù)集成包归。項目級別CI貫穿整個項目周期，從項目的FRD到發(fā)布后的跟進铅歼。下圖是項目級別的持續(xù)集成的流程圖公壤，主要介紹項目使用CI的流程。
CI的介入是從立項的時候開始椎椰，前期是溝通和方案的定制厦幅，然后就是具體策略的執(zhí)行，這里需要說明一下慨飘，CI不是獨立存在的個體确憨，他會與測試范圍界定、缺陷分析等緊緊結(jié)合套媚。
當拿到一個項目時缚态，應該怎么做磁椒，在流程圖中已經(jīng)說明了一切堤瘤，首先是要做項目評估，如果項目適合做CI浆熔，然后就可以和項目組溝通本辐，達成一直需指定方案計劃和資源評估方案，最后進行具體方案的實施医增。
圖中節(jié)點說明：
項目評估：
當我們參與一個項目的時候，需要評估下該項目是否適合做項目級別的持續(xù)集成，不是什么項目都可以做持續(xù)集成的更鲁。
根據(jù)業(yè)界的經(jīng)驗绷耍，如何項目周期短，迭代次數(shù)少忽刽，這類的項目就不適合做持續(xù)集成天揖，但還是要根據(jù)項目的特點進行評估。
溝通：
這是非常重要的一點跪帝，只有團隊達成一致今膊，才能將CI持續(xù)下去，我們在達成一直的基礎(chǔ)上做約定和計劃伞剑，如果在溝通的過程中無法達成一致斑唬，那么個人建議不要進行CI，當然也要去分析為什么沒有達成一致。
計劃約定與資源評估：
在溝通達成一致的基礎(chǔ)上做出計劃約定和資源評估恕刘。
持續(xù)集成實施：
在溝通缤谎、計劃、約定的基礎(chǔ)上我們就可以運用工具和策略對起進行實施褐着，具體的工具和實施在后面的章節(jié)會做說明弓千。
2 持續(xù)集成方案與策略
在前面介紹了項目級別持續(xù)集成的流程，四個節(jié)點（項目評估献起、溝通洋访、計劃與方案定制、持續(xù)集成實施）都非常的重要谴餐，項目評估姻政、溝通、計劃與方案定制屬于前期的過程岂嗓，也是基礎(chǔ)汁展。本章重點介紹持續(xù)集成實施中持續(xù)集成的方案與策略、量化標準以及數(shù)據(jù)的采集厌殉。
2.1 持續(xù)集成策略
持續(xù)集成的實施肯定缺少不了策略食绿，但我們應該使用什么樣的集成策略呢？如下圖所示：
持續(xù)集成的策略是采用技術(shù)手段為CI提供技術(shù)依據(jù)公罕，做一個好的持續(xù)的項目最核心的是良好的單元測試編碼器紧，集成測試編碼、系統(tǒng)測試編碼楼眷、web ui層自動化等不同level的自動化能力铲汪，安裝核心系統(tǒng)目前的情況來講，有些條件并不成熟罐柳。但我們可以反其道而行之掌腰，以項目持續(xù)集成為基礎(chǔ)，來推動某些條件（如單元測試张吉、代碼規(guī)范）的良性循環(huán)齿梁，形成量的積累，使得持續(xù)集成條件逐步走上正軌肮蛹。
2.2 單元測試集成
單元測試是持續(xù)集成中非常重要的組成部分勺择。目前我們軟件質(zhì)量部產(chǎn)品線的單元測試可以說是幾乎處于無的狀態(tài)。
目的與價值
單元測試（模塊測試）是開發(fā)者編寫的一小段代碼蔗崎，用于檢驗被測代碼是否正確酵幕。通常而言，一個單元測試是用于判斷某個特定條件或場景下某個函數(shù)的行為是否按照預期結(jié)果進行缓苛。
單元測試與其他測試不同芳撒，單元測試可看作是編碼工作的一部分邓深，應該由程序員完成（TDD），也就是說笔刹，經(jīng)過了單元測試的代碼才是已完成的代碼芥备，提交產(chǎn)品代碼時也要同時提交測試代碼。持續(xù)集成中集成單元測試舌菜，每次迭代提交都保證單元測試的質(zhì)量萌壳，那么產(chǎn)品的質(zhì)量在一定程度上都得以保證。
所以單元測試在持續(xù)集成過程中是測試件中非常重要的組成部分日月。不可缺少袱瓮，這也是CI過程要單元測試集成的目的和意義。
2.3 單元測試策略
集成測試項目中對單元測試策略采用如下：
1參與單元測試case設計
開發(fā)人員或測試人員進行單元測試編碼爱咬，測試設計人員參與case設計尺借，因為我們設計case的角度和開發(fā)人員是不一樣的，測試人員的設計會更加全面精拟。
2單元測試case的review
要進行單元測試case的review燎斩，如果發(fā)現(xiàn)不合適的case則要進行修訂。以保證單元測試的質(zhì)量蜂绎。
3單元測試的用例評審（單元測試完成階段）
與項目組成員或資深人員一起參與單元測試用例的評審栅表，對不合適的用例需進行修改。
在持續(xù)集成過程中师枣，如果發(fā)現(xiàn)單元測試的failed趨勢上升或failed達到某一標準時怪瓶，需和開發(fā)人員溝通并修訂bug，從而保證每次迭代產(chǎn)品的質(zhì)量坛吁。
2.4 適用范圍和階段
單元測試適合在開發(fā)人員進行單元測試編碼階段劳殖，一旦單元測試編碼完成，上述單元測試的測試都可以適用拨脉，貫穿于整個項目周期。
2.5 工具
既然有持續(xù)集成宣增，那我們就需要用到一些持續(xù)集成的工具和平臺去分析每次的構(gòu)建結(jié)果玫膀，在持續(xù)集成平臺（hudson）中集成了單元測試覆蓋率統(tǒng)計工具。參考后續(xù)內(nèi)容爹脾。
2.6 量化指標
使用單元測試策略中我們會采集到一些數(shù)據(jù)指標帖旨，
3 接口測試集成
接口測試類似于單元測試，是分層自動化的重要組成部分灵妨，介于黑盒測試與白盒測試之間解阅，在了解系統(tǒng)設計與接口定義對前提下，就可以在適當?shù)臅r候運用mock來進行接口測試泌霍。
3.1 目的與價值
接口測試是質(zhì)量的保證和效能的提升货抄，所謂質(zhì)量保證，就是深入到代碼的底層，可以對接口進行直接的參數(shù)注入蟹地，查看其返回結(jié)果积暖，讓我們知道底層到底發(fā)生了什么。所謂效能的提升怪与，就是程序的速度遠比手工的速度快夺刑，幾分鐘就可以跑完上百個用例。
接口測試不但可以提高測試效率分别，也不需要投入過多的精力去熟悉代碼邏輯遍愿，而且可以借助單元測試技術(shù)實現(xiàn)持續(xù)集成和每日構(gòu)建。
3.2 接口測試策略
本文采用的接口測試主要是對系統(tǒng)提供的服務接口進行所有接口的覆蓋和集成耘斩，在覆蓋的過程中進行以業(yè)務為導向的codeReview错览。在持續(xù)集成運行的過程中發(fā)現(xiàn)bug，需與開發(fā)人員溝通后修訂bug煌往，從而保證產(chǎn)品的質(zhì)量倾哺。起測試方案如下：
1新增的接口進行case覆蓋和集成
2修改的接口進行case覆蓋和集成
3保證已有接口的正確
3.3 適用范圍和階段
接口測試和單元測試一樣，貫穿整個項目的周期刽脖。
1需求了解階段：了解項目中接口的功能羞海，接口的輸入輸出參數(shù)及返回值，根據(jù)項目的情況決定是否做接口測試
2設計階段：了解接口的實現(xiàn)曲管，并與開發(fā)溝通確定接口以怎么樣的形式進行暴露却邓，從少先隊哪一層暴露。
3編碼階段：腳本編寫院水、數(shù)據(jù)準備腊徙、調(diào)試
4測試階段：
-接口參數(shù)完成和提交測試前，主要個工作就是：運行接口測試腳本進行測試檬某，根據(jù)測試的結(jié)果與開發(fā)逐一過用例撬腾，以確定是代碼問題還是數(shù)據(jù)問題，直至所有的case均跑通恢恼。
-測試階段和分支回歸階段民傻，利用集成測試平臺完成該接口的測試和部分的分支回歸工作，檢查測試結(jié)果
-發(fā)布回歸场斑，利用持續(xù)集成平臺檢查測試結(jié)果
5 發(fā)布會
- 接口參數(shù)若有變化應及時維護腳本和數(shù)據(jù)
- 持續(xù)集成保證底層的質(zhì)量
3.4 工具
- 接口測試涉及的工具主要是接口測試的開發(fā)和持續(xù)集成平臺漓踢。
- 開發(fā)工具例如eclipse
- 持續(xù)集成測試平臺hudson的配置和運行
4 UI 測試集成
4.1 目的和價值
UI自動化測試是通過直接操作指定的瀏覽器，對瀏覽器中的頁面對象漏隐、元素進行操作喧半，完全模擬手工測試過程。項目中運行UI自動化測試的一個目的就是期望能利用自動化替代手工測試提升測試效率青责，通常在分支回歸階段使用挺据，減少回歸投入時間取具；另一個目的是為了產(chǎn)品級UI自動化測試做基礎(chǔ)建設。產(chǎn)品級UI自動化測試在每日發(fā)布的回歸測試中使用吴菠，不僅能擴大回歸范圍者填，而且能幫我杜絕重要故障，保證產(chǎn)品重要業(yè)務流程的正確性做葵。
2 UI測試集成策略
集成測試項目中對UI測試的策略采用如下：
1可行性分析及需求提日加础：測試負責人評估項目是否適合UI自動化覆蓋，并確認UI自動化覆蓋范圍酿矢。
2計劃安排：測試負責人平臺自動化腳本開發(fā)工作量榨乎，并且在測試計劃中加入
