從小白到菜鳥：持續集成說

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提供技術依據，做一個好的持續的項目最核心的是良好的單元測試編碼，集成測試編碼、系統測試編碼、webui層自動化等不同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可行性分析及需求提取：測試負責人評估項目是否適合UI自動化覆蓋，並確認UI自動化覆蓋範圍。

2計劃安排：測試負責人平台自動化腳本開發工作量，並且在測試計劃中加入

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！