這是鼎叔的第九十六篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
如果在測試部門只能推行一個技術建設專案，那鼎叔就會選擇 “持續測試”。
持續測試（Continuous Test，CT），也有公司稱為每日測試（Daily Test），就是每天都有新版本生成並完成相應的測試活動，絕大部分測試都是自動化測試，但是也可以推送新生成的安裝包到成員的終端上進行人工 dogfood（內部探索測試）。儘可能在當天就發現是否有基本功能被新程式碼破壞掉，縮短解決問題的閉環，並讓大團隊對新程式碼提交保持信心，這樣的實踐契合 “頻繁測試”、“集體對質量負責” 的敏捷原則。
相關前文：聊聊測試左移到開發階段 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484498&idx=1&sn=82a4bf3f3680220f89bf12b02924211e&scene=21#wechat_redirect
持續測試的健康度指標
帶領團隊全力投入持續測試之前，鼎叔會不厭其煩地強調：持續測試不是普通的自動化測試，健康度比覆蓋率更重要。
以往測試團隊在設立自動化測試目標時，都把重心放在自動化覆蓋率上，比如所有測試用例被自動化的比率，或者介面/程式碼行的覆蓋率。只看這一類指標很容易帶來臨時抱佛腳，有不少 QA 會在考核末期把自動化率提上去，用例沒有透過也不去深究原因，整個自動化下來累計發現的問題非常有限。
鼎叔推薦以下幾個健康度指標：
1 持續測試卡點失敗的恢復時長（MTBF）
持續測試的卡點就像安燈繩，指定的基礎功能一失敗就應該停下來檢查。
為了保障持續測試能順利開啟，團隊首先要確保持續構建的成功率，必要時督促開發立刻處理失敗，建立對健康構建的重視態度比完善工具更重要。
有一部分不太穩定的，優先順序也不高的持續測試用例集可以不設定卡點，或者設定低閾值卡點，以免經常失敗導致人員精力的過度耗費。但這種用例集數量應該儘量控制，可以放在員工本地執行，穩定後再放在團隊流水線中。
2 測試還需要關注專案的構建和執行速度，通常應在幾分鐘以內。在實踐中發現，導致構建耗時太長的原因經常來自於測試，比如包含了遠端服務（如資料庫）。
3 度量團隊和專案持續測試的前置缺陷發現率，就是持續測試迴歸自動化過程中累計發現的所有有效問題。這個指標不管用什麼自動化框架，不管黑貓白貓，只要發現儘量多的問題就是好貓。
這個指標主要看遺留測試資產（迴歸自動化）的效果，包括利用各種無需 QA 人工投入的自動化能力，能在人工測試之前攔截多少有效問題。
持續測試人員可以用各種手段客觀記錄有效缺陷，不一定要錄入缺陷管理系統，更多是度量持續測試的產出價值。
持續測試實踐的成效是，後期的系統測試階段發現的缺陷數量大幅下降了。沒錯，在測試左移中，系統測試中發現的缺陷佔比越少，越有可能是件好事。
4 測試用例透過率。有的流水線卡點會設定為 100% 透過，也有設定為 90% 透過的。關鍵是隻要有失敗就要快速排查，是指令碼問題、產品溝通問題、環境問題，還是缺陷。
透過率的治理可以倒逼 QA 最佳化用例集，剔除不穩定的，或沒想清楚的用例，避免 “用例越多越好” 的誤區。
5 測試人員除了參與驗收標準和驗收用例的評審，還可以在開發完成單個需求（使用者故事）自測後，馬上開始針對性的驗收測試（如果產品經理能先行做使用者驗收測試則更佳），快速反饋該單個需求的質量情況（最好當天完成），降低迭代版本測試或系統級測試的風險。反饋週期越短，開發修復的效率越高，而傳統的等待版本提測模式，會拉長開發的等待時間，加大切換任務的注意力耗費。
持續測試的技術棧
產品和專案質量交付是一個整體，包括客戶端/前端，和後端的程式碼測試與釋出。但是從自動化技術層面，客戶端和服務端的測試框架和執行速度還是有很大差異。
所以持續測試建設團隊需要從兩套技術棧去分頭建設流水線，一套是客戶端，一套是服務端，分頭掌握不同的自動化能力，但最終的質量標準和指標看板要整合為一個結果，面向產品的整體來輸出。
客戶端持續測試流水線
客戶端的自動化測試成本在很多時候是高於服務端的，可以借用的行業技術成果也更加的豐富多彩。
一，因為客戶端面向使用者體驗視角，所以具備 AI 影像識別能力的 UI 自動化測試框架有不錯的潛力。
二，三端合一測試技術，即用一套指令碼在 Android，iOS，PC/Website 上同時完成自動化測試，這是客戶端測試的熱點，在持續測試中非常有價值潛力。
三，真機叢集適配自動化測試，這個將來有機會可以專題分享。不同機型的 APP 適配質量是很多開發團隊的噩夢，行業已經有很多針對性的解決方案。因為真機適配 UI 自動化通常速度慢，失敗率較高，所以更適合作為非卡點非同步任務。
服務端持續測試流水線
服務端持續測試肯定以協議測試/介面測試為主要形式，但是介面測試的框架也是五花八門。對於電商等複雜的線上流量業務，流量錄製回放工具佔據了越來越重要的比重。持續測試平臺可以同時接入流量錄製回放型自動化測試框架，和常規的人工建立型自動化測試框架。
持續測試看的是療效，不追求執行框架越單一越好，只要能顯著提升前面的健康指標，引入外部開源的或商業工具都行，甚至友商工具也可以拿來用。
持續測試流水線的分層（五層）
持續測試中的自動化測試是分層進行的，因為不同層次的自動化測試耗費的時間不同，修復成本不同。參考 HamVocke 的測試金字塔理論，自動化測試可以分為下面幾個主要層次。
1）靜態測試。即靜態程式碼掃描，包括程式碼普通質量問題和程式碼安全問題，針對掃描結果，我們會關注掃描出來 Block 問題和 Major 問題，設立修復率目標，推動開發把精力放在前期。
2）單元測試。之前文章已有介紹。
3）介面測試。
4）跨鏈路測試或整合測試。在很多公司，整合測試被稱之為聯調測試，通常由開發人員負責，但是測試人員也可以共同建設。
整合測試可以分為狹義整合測試和廣義整合測試。狹義整合測試聚焦被測物件的服務邊界，觸發本物件和外部（另一個服務，或資料庫，或檔案系統）的整合動作。而廣義整合測試則是透過網路和外部服務進行整合，但是速度更慢，測試更脆弱。依託測試環境穩定的基礎設施服務，整合測試通常按照從小到大的順序聯調，逐步提高服務的可用性。
從敏捷角度理解，聯調意味著跨特性團隊的協作，雖然難以避免，但也屬於浪費的成本，應該儘可能降低聯調的投入和時間。如果參與聯調的各方都有非常清晰完備的介面定義，充分考慮了可能的錯誤場景，那麼聯調就可以在最短時間完成，甚至藉助事先做好的自動化用例全自動完成。
因此，在微服務產品中，契約測試（作為一種特殊的整合測試）就流行開來，所有微服務的介面測試都根據定義好的介面契約，設計完整的穩定的測試用例套件，確保資料的生產者模組和消費者模組遵循契約。基於該套件的每天持續測試把關，研發團隊便向自治團隊邁出了一大步。
5）UI 測試/端到端測試。注意，UI 測試是端到端測試的一部分，即從互動介面上驗證結果。端到端測試還有不少其他層面的驗收標準，比如沒有介面的功能，系統效能，安全性檢查，日誌正確性，交付規範的文件等。對於微服務架構的產品，需要有人面向整個系統，跨越多個服務來編寫端到端測試用例。
這些自動化測試層次使用的測試框架各不相同，但持續整合平臺都可以納入，並行執行，根據團隊的效能度量要求進行任務配置和結果治理。
哪怕不完美的自動化測試，只要能夠頻繁執行，也比很少執行的完美測試更有價值。
而前文提到的驗收測試，和測試金字塔的各個層次是正交的，你可以依託單元測試來驗收，也可以從介面驗收，當然也可以在 UI 層驗收。
如果一個功能驗收可以同時在低層次和高層次自動化實現，那就應該保留低層次測試用例，而放棄高層次用例，以減少用例重複。但是，如果高層次的用例能夠提高我們對於產品釋出的信心，那就應該保留它。
這也就是我認為，單元測試及整合測試，不太可能完全替代端到端測試的原因。
持續測試與測試右移
持續測試貫穿產品研發生命週期，它的價值不僅限於左邊，也適用於右邊的質量活動。
持續測試就是要把前期積攢的測試資產在灰度、釋出、上線後反覆利用，測試框架設施不變，收益最大化。
具體實踐可以包括：
埋點驗證自動化測試。產品的關鍵指標埋點是一類對產品發展很重要的功能，除了在常規測試中驗證，也可以在預發環境和線上環境進行測試和監控。
線上巡檢自動化。出於商業目標的保障（如重大營銷時期的價格風險檢查），線上的關鍵頁面處於不斷變化中，老闆對此關注力度大，甚至還需要和競品對比，這就不是簡單的指標監控就能保障的。測試自動化可以梳理出 UI 層面巡檢的場景和指令碼，把它擴充到正式環境進行取樣巡檢。
業務邏輯撥測。普通的介面可用性監控，對於運營團隊和網路服務公司來說很容易，但是具體業務邏輯是否在現網保持正常，仍然沒有確定答案。既然測試團隊有各種核心業務場景的自動化指令碼，就可以挑選少量場景，用很小的流量進行撥測，儘早發現問題。
下一篇我們聊聊持續測試實踐的進階思考。