背景介紹
按照組織上的安排，咱游擊到了s產品（乙個快速成長中的web產品）開搞
持續整合。
考慮到s產品核心業務單一明確，前端功能簡單，業務邏輯主要在後端的特點，制定了持續整合的實施策略：
ui自動化為輔，用例少一點，精一點，降低維護成本，
用例設計以冒煙和頁面跳轉，走通業務流程為主，目的是保障乙個高可測性的
測試環境；
單元測試重點跟進，自頂向下逐步覆蓋各層介面，多覆蓋各種分支路徑，與ui自動化形成互補。
這裡有個小插曲，我和s產品的測試負責人關於ui自動化用例的粒度和覆蓋度有一些歧義，測試負責人堅持ui自動化要盡量覆蓋大大小小各種流程與細節，接近於手工測試。最後，咱還是堅持了己見
雖然，實施策略中設計了以單元測試（這裡必須澄清一下，此處的單元測試實為整合測試/介面測試，沒有完善的mock，仍有一些外部依賴；但是考慮到使用了junit/testng，一般也就籠統地稱之為單元測試了）為主，後續
工作中確實也在這方面寄予厚望，投入較多，但由於種種原因，頗有雞肋之感，此處暫時按下不表。
框架選擇
網易杭州研究院開源的，簡單易用的，結實耐操的dagger框架
用例建模
考慮到ui自動化在s產品中的預定角色，我們將用例分成三大類：
userstory，產品的核心業務流程，乙個用例包括一系列步驟，模擬使用者在s產品**的真實運動；這些用例如果失敗將明顯干擾qa正常測試，一旦上線，將是嚴重故障；
topic，包括一些冗長的特定業務（例如，下圖所示的topic 1：**超市卡），以及對ui自動化所依賴的外部環境的檢測（例如，topic 2：與**商保持聯絡）；
bugcover，出現過線上
bug的功能點補充用例。
step 1
step 2
step 3
step 4
step 5
userstory 1
從車庫進超市
取手推車
買水果買牛奶
現金結賬
userstory 2
從正門進超市
取購物籃
啥都不買就逛逛
離開userstory 3
選購牛奶
選購麵包
購物卡充值
購物卡結賬
topic 1
**超市卡
topic 2
與x供貨方保持實時聯絡
bugcover 1
央視報道y牛奶 沒有及時下架 導致使用者投訴
這裡必須要特別指出的是，不同userstory的步驟之間 盡量正交，減少重複 ，這樣一來：
在實際編寫用例**時，基本不必考慮是否須要把哪些操作抽象成api，哪些xpath封裝起來，完全指令碼化寫用例；
相應的，由於用例與用例之間重複**少，也鮮有共同依賴的api，就可以很放心地將用例責任到人，實現真正的誰寫誰負責；
而對於持續整合來講，責任到人，及時響應是其能否成功的關鍵之一。
另外，我認為這種用例模型僅適合小規模的ui自動化用例，用例數量上去以後，很難實現用例之間的正交。所以，其背後必須有充分的其它型別測試，例如：單元測試/介面測試，作為依託。
典型的用例結構如下所示（基於testng與dagger）
public class demo
@test(description = "從車庫進入超市")
public void step_1()
@test(description = "買牛奶", dependsonmethods = "step_1")
public void step_2()
@test(description = "買水果", dependsonmethods = "step_2")
public void step_3()
@test(description = "現金付款", dependsonmethods = "step_3")
public void step_4()
@test(description = "開車離開", dependsonmethods = "step_4")
public void step_5()
@afterclass(alwaysrun = true)
public void doafterclass()
}
實戰與效果
由於對ui自動化及jenkins輕車熟路，在極短的時間內就完成了一套簡易的ui自動化持續整合，整套流程的執行時間嚴格控制在 15分鐘 以內（可開啟用例併發執行模式），並且每隔30分鐘執行一次：
工程**構建 -> 測試環境部署 -> 執行ui自動化
最初，一共只有10個左右的ui自動化用例，但已經基本覆蓋了產品的核心功能點（沒考慮各種流程的排列組合），正是這只有區區幾個ui自動化用例的持續整合卻發揮了不小的作用：
不少的各種低階錯誤（低階，不解釋！）在構建階段被攔截，並以郵件形式知會開發團隊；
引起qa測試工作block的嚴重問題（不一定是bug，也可能是環境配置，髒資料，等）被及時發現；
用例數量確實不多，大家都樂意在第一時間去處理失敗用例。
所以，正如古人云： 銀子鈔票，多多益善；持續整合，愈早愈好 ，還是盡早寫幾個ui自動化，配置持續整合跑起來吧，它能夠發現和預防的問題比你預計的多得多！而且，只要這套持續整合跑起來了，往裡面添磚加瓦就輕鬆得多了，不再會有畏懼感，信心也會逐步增強。
現在，每次產品迭代結束之後，測試團隊就會及時整理乙份類似上述的**，大家一起參詳下，分工下，補充用例，逐步完善。
一些結論
s產品的ui自動化是 小而美 的典型：
用例不多，維護/補充很及時；
**冗餘度很小，結構清晰；
執行穩定且快速，深合持續整合的快字訣。
UI自動化測試之jenkins持續整合
1 持續整合簡稱ci 2 持續整合的目的 讓產品快速交付，並保證高質量的交付。3 網際網路產品的特點是 a 小步快跑 快速迭代 b 網際網路產品研發標準化的核心流程是 將 整合到主幹分支後 必須要經過自動化的測試 如果自動化測試執行失敗，就不能整合到主幹分支上，持續整合指的是，頻繁的往主幹分支提交 ...
持續整合 自動化
一 什麼是持續整合 continuous integration 這個名詞已經在軟體開發領域持續了n年，乙個比較簡單的定義如下 持續整合 ci 是一種實踐，可以讓團隊在持續的基礎 上收到反饋並進行改進，不必等到開發周期後期才尋找和修復缺陷。通俗一點兒說，就是指 對於開發人員的每一次 提交，都自動地把...
自動化持續整合Jenkins
自動化持續整合jenkins 使用jenkins配置自動化構建 jenkins入門總結 jenkins sonar 的系統，用來執行自動構建 自動部署 自動測試，質量評估的整套平台，用來做敏捷。持續整合是個簡單重複勞動，人來操作費時費力，使用自動化構建工具完成是最好不過的了。後期應該搞單元測試，自動...