模板
教程
環境
性能
功能
管理
圍繞自動化測試開展持續集成
本文不會介紹持續集成的概念、理論以及相關工具的用法，而是基于實際的項目案例，分享如何利用自動化測試保障持續集成的有效性，同時也借助持續集成提升自動化測試用例的價值。
在本系列的前幾篇文章中，首先分析了測試不夠敏捷的原因，然后從“降低測試腳本維護成本”和“優化斷言機制”兩方面分享了Web自動化測試的改善實踐。
前面幾篇文章其實都在講“如何成功實施Web自動化測試”，本文將要涉及一個很敏感，但不應該回避的話題“自動化測試的意義到底有多大?”。
基于京東云服務，使用京東宙斯開放平臺接口，大賽提供高額獎勵!
做過自動化測試的同仁都應該對“自動化測試用例能發現多少缺陷”這話題不陌生，業界也有很多支持“自動化測試用例主要不是用來發現缺陷，而是提高回歸測試效率”這個觀點的文章。即便這樣，“發現缺陷”也像是自動化測試人員“肉中的一根刺”，很多時候大家不愿意去觸碰它(不碰就不痛)。這樣時間久了，很可能會讓自動化測試人員喪失發現缺陷的斗志。筆者在這里就嘗試撥動一下這根“刺”，希望可以再次引發大家的思考。
“自動化測試主要不是用來發現缺陷”這一觀點的主要依據是“自動化測試是嚴格按照已有用例進行的自動回歸測試”。說白了就是“它每次做的事兒相同的”，所以不能像手工測試那樣依靠人的主觀能動性來發現新的缺陷。
“它每次做的事兒相同的”，這一點我們改變不了。
但我們能做的是在不同的場景中做“相同的事兒”!從而增加發現缺陷的幾率，降低軟件釋放后風險。
下面就通過實際案例分享筆者在提升自動化測試價值方面的經驗：“在持續集成中對每日構建的版本進行回歸測試”，并對一些里程碑版本進行“在各種環境組合下(應用服務器、數據庫、瀏覽器、操作系統)的兼容性測試”和“7*24小時的穩定性測試”。
對每日構建版本的回歸測試
本案例中的產品是面向云計算領域的通用云環境管理軟件，在云數據中心構建及運維過程中提供全方位、多層次的管理能力，基于云環境實現應用的快速部署及其資源的彈性供應，通過簡化管理極大地降低成本、提高效益。
產品的邏輯架構、主要技術路線及對應的自動化測試方案如下圖所示：
該產品大致可以分為三層：
最底層負責與各類虛擬化資源或物理資源的交互，比如，創建虛擬機、獲取CPU利用率;
中間層負責對底層返回的數據進行持久化及業務處理，并向外提供大量REST接口;
最頂層通過多個應用門戶向不同類型的用戶提供體驗一致的交互界面，它本身沒有太多業務邏輯和持久化操作，主要靠調用中間層的REST接口來實現。
持續集成方案選擇的CI工具是Jenkins，具體步驟如下圖：
對每個步驟的要點簡述如下：
更新編譯代碼
項目采用分布式開發，需要從不同的配置管理庫中更新各個模塊的功能代碼和自動化測試用例。
代碼質量檢查
項目要求開發人員使用Findbugs和PMD對自己的代碼進行質量檢查并修正相關問題。同樣也在持續集成過程中通過Sonar(集成Findbugs和PMD)使用相同的策略進行代碼檢查，以確保該要求的執行效果。
更新數據庫
在更新功能代碼和測試腳本之后，自動化測試還是可能出現大面積無法通過的情況。其中一個很常見的原因就是“當天開發庫中的數據庫結構發生了變化”，而持續集成所使用的數據庫并沒有更新。
所以我們執行自動化測試用例之前增加一個“檢查開發庫和持續集成庫的表結構是否一致，如果不一致就做增量同步”的任務。
執行單元測試
通過單元測試確保系統與虛擬化資源或物理資源的交互是沒問題的。如果這個環節出現嚴重問題，后面的持續集成任務就沒必要執行了。
部署后臺服務
單元測試通過之后，把后臺服務(即，上面說的中間層)發布到目標服務器并啟動服務。
執行REST接口測試
基于上面發布的后臺服務，對其提供的大量REST接口進行回歸測試。如果這個環節出現嚴重問題，就沒有必要再部署前臺應用并進行后續測試了。
部署前臺應用
REST接口測試通過之后，才把各個前臺門戶應用發布到目標服務器并啟動服務。
執行Web UI測試
基于上面發布的前臺應用，執行各自Web UI層面的自動化測試用例(采用本系列前面幾篇文章中介紹的方案)。
發布構建結果
通報每日構建結果(如下圖所示)，測試用例按照模塊進行分類，對不通過的用例進行分析然后提交相關缺陷。
上述持續集成案例的關鍵是“自動化測試”，而無論從技術還是從管理的角度，其難點也是“自動化測試”。
從技術角度來說，在上面三類自動化測試中最困難的是UI層面的自動化測試。筆者在本系列前面幾篇文章中主要分享的就是這方面的改善實踐。
從管理角度來說，要對自動化測試相關數據(比如，用例通過率、用例增長率、代碼覆蓋率等)實施公開、準確的度量，如下圖所示。
度量的最終目標不是為了考核，而是為了改善。
從度量結果中團隊能看出問題，才能有的放矢的改善;
從度量結果中團隊能看出進步，才能得到激勵和信心。
