這是鼎叔的第九十七篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本專欄和微信公眾號《敏捷測試轉型》，星標收藏，大量原創思考文章陸續推出。
如果在測試部門只能推行一個技術建設專案，那鼎叔就會選擇“持續測試”。
這篇繼續聊聊持續測試建設的 ROI 分析，思考未來的成熟度進階，以及其他要注意的。
前一篇：聊聊持續測試 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484564&idx=1&sn=9d0267d51f5075bcd39f1fb7d0e58f3b&chksm=c24fb1f6f53838e0b2c91e9c8588edd04140a8109719761be75c05fe9dbceb3b096475a176a7&scene=21#wechat_redirect
持續測試的成熟度進階
鼎叔經常對團隊描繪持續測試建設發展的三大階段，看看怎麼和行業的高水平逐步對齊。
第一階段，跑起來，形成紀律。
只要有程式碼提交，必然觸發流水線測試的結果。團隊在第一階段實踐好了就能看到以往沒有的自動化收益。
有些工程師以往不願意投入自動化建設，理由就是業務需求安排的太滿，沒有時間搞自動化建設。
這裡有一個誤解，自動化測試不是額外的工作，它就是業務測試的一部分，如果自動化測試不能讓業務測試更高效，那就說明自動化選擇策略出了問題。
當我們要求全員把第一階段跑起來，那些業務測試壓力很大的同學很快就適應了，做得很不錯，甚至開始依賴持續測試的迴歸攔截網，它讓新需求的測試更加安心。
以往的業務測試壓力大，往往是怕大量的歷史業務邏輯沒有被驗證，所以測試計劃時間拖得很長，進一步增加了交付壓力。在持續測試背景下，員工只需要聚焦新功能驗證即可。
第二階段，成熟的流水線部署，能夠應對大團隊的持續測試需求，並做好精細化管理。支援常見的流水線構建機制，如併發構建（縮短大量用例執行時間），次級構建（讓耗時長的用例非同步處理，或者讓不太重要的用例集非同步處理）。
在這個階段，用例可以分為不同的批次，有些在程式碼變更時就觸發執行（執行時間短，維護成本低），有些在主幹發版前才觸發執行（執行時間長，維護成本高）。比如 APP 適配質量標準的測試屬於後者。
這個階段的持續測試看板建設也成熟起來了。各個團隊、各個專案的流水線執行健康情況和趨勢一目瞭然，低效指標會很快暴露出來。
第三階段，流水線的智慧化 + 精準化，以及不穩定測試集的隔離。
前者要達到的水平是，讓大量專案的海量自動化用例能夠被智慧的挑選，縮短執行的總時長，挑選出儘量少的用例集覆蓋儘量多的程式碼執行路徑；系統能主動識別出要汰換的過期或低效用例集，並提示應該補充的新用例。
後者要建設的目標是，把偶然失敗的用例（隨機性失敗）挑選出來，單獨在隔離區中集中執行，研究機率失敗模式，挖掘更有深度的質量缺陷。這塊的用例數量大約佔總用例數的 1%-2%。隔離區對於持續測試用例的整體執行穩定性也有很大助力。
第三階段能實現大規模團隊的持續測試管理，把演算法分析的價值在測試執行分析上發揮到最大，把最新的測試智慧工具進行中心化部署，讓業界的好東西快速傳播到所有一線團隊。這就是鼎叔心目中的行業一流水準。
DevOps 和持續測試實踐的 ROI
在持續交付 DevOps 實踐中，頻繁的持續測試自動化佔據著非常重要的一席之地。只有快速驗證每次程式碼提交的質量，持續整合才能健康地順利進行。理論上所有自動化測試建設成果都可以納入每日持續測試的範疇，但是出於快速響應及驗收的目的，持續測試中的自動化一定是小批次的精華測試用例，其產生的 ROI 理應也是最高的。
基於此邏輯，穩定的單元測試和主要鏈路的介面測試用例會成為每次程式碼提交的必測用例集，執行時間很短（幾秒到一分鐘以內）。
那麼，其他層次的自動化測試建設成果是否就應該隔絕於 DevOps 之外了？非也。以下是作者基於專案實踐總結的例子。
1 更多非主鏈路的介面測試用例，如邊界場景，超時場景，異常處理場景，可以安排並行構建佇列，同步執行，縮短等待介面測試結果的時間。
2 穩定的很少量 UI 層驗收自動化用例，可以作為可選測試集合，在版本提測給專職測試人員之前觸發執行，代表著基本的使用者視角場景驗收完成。
3 更為耗時的系統級測試，如效能測試，穩定性測試和系統相容測試，可以安排在次級構建佇列中，下班後自動執行，第二天上班看測試報告。次級構建不會影響白天的程式碼提交入庫門禁，但是發現問題也要儘快處理，必要的話需要回滾程式碼部署。
4 對於實踐持續整合的研發團隊，每日構建的健康度和團隊紀律至關重要，其相關紀律指標可以考慮下面這些。
1) 是否每天都有提交？如日構建次數，人均 checkin 程式碼次數，每日自動化測試的執行次數和範圍等。
2) 每天提交程式碼的測試質量如何？如每日測試自動化迴歸透過率，單元測試門禁 95% 以上透過率，其他自動化測試集透過率 90% 以上，發現 crash/ANR 次數等。
3) 程式碼健康度指標。如程式碼掃描透過率，圈複雜度，重複程式碼率，扇入扇出數量等。
4) 自動化缺陷前置率。有多少有效缺陷是在測試人工介入之前，由持續測試平臺已經發現的？在總共的有效缺陷中佔比多少？這個指標說明了持續自動化測試平臺的建設收益。
5) 關注構建成功率（主幹分支的構建成功次數/構建總次數），健康構建天數（每天都保障有可供嚐鮮和眾測的版本），構建平均時長（從程式碼拉取到所有任務完成，包含編譯，程式碼掃描，單測和自動化測試）和構建失敗的平均恢復時長。
所有流水線的平均構建時間應在 15 分鐘以內。平均構建失敗的恢復時間應小於 4 小時。
6) 關注版本釋出健康度。成功釋出成功率足夠高，灰度釋出次數符合預期，儘量減少不必要的緊急版本釋出。
如果要對持續整合和持續測試的成熟度進行評價，我們可以依據哪些團隊典型表現來判斷？以下這些問題可以供大家自評參考，進而錨定改進措施。
1) 團隊是否利用了靜態程式碼分析工具，對發現的不良問題立即進行修改，不遺留到正式提交程式碼前？不良問題包括嚴重級別以上的問題，高重複率和高複雜度的壞味道程式碼。越早關注壞味道程式碼並加以杜絕，評級越高。
2) 開發人員是否為新增或修改程式碼建立了單元測試，並透過流水線門禁來頻繁執行和保證持續生效？開發人員越能在實現程式碼的同期提交單元測試程式碼，評級越高。
3) 功能和介面自動化測試是否有效，且能夠透過持續整合頻繁執行？遵循金字塔原則，不同層級的自動化測試的覆蓋範圍（投入）是合理的。
4) 團隊能否基於單主幹開發，以便測試人員進行快速靈活的測試策略？基於單主幹開發，測試人員可以每天完成功能驗證，無須針對程式碼合併主幹再做集中驗證。
5) 非功能性測試能否在釋出前足夠短的時間完成？團隊可以利用工具模擬對被測系統的效能、安全、併發穩定性、系統適配性、版本相容性等質量情況進行自動化驗證，頻繁執行。因為有成熟的自動化基礎設施，大部分非功能性測試已經在迭代內驗證過了，釋出前很短時間（比如一天內）就可以集中完成。
6) 所有構建、測試和釋出是否都使用流水線自動完成且驗證內容完整：
流水線可以自動打通全部發布渠道（自由渠道，應用商店，內部灰度渠道等）。不同分支的流水線選用不同的覆蓋策略並行推進。特性分支只做快速驗證，釋出分支的流水線則進行全面掃描、測試和釋出打包。靜態掃描以及自動化測試如果耗時過長，則應該增加獨立流水線進行驗證。
7) 每個開發人員能夠及時將程式碼合併回主幹（從新的編碼開始計算，最好三天內合併回主幹）。
8) 構建/測試成功或者失敗能立刻通知團隊，團隊立刻關注並嘗試解決錯誤或者回滾程式碼，讓構建或測試透過。
9) 團隊是否利用了多種視覺化提醒方式，讓持續構建和持續測試的不健康狀態傳遞給責任人及影響團隊，比如 IM 彈窗、告警聲音、亮燈和監控羅盤。
最終，從 DevOps 平臺視角來看，能否視覺化地呈現整個研發過程中各階段的阻塞時間？包括待評審、待開發、待測試和待發布這四個主要階段，能從中看到 “被迫等待” 的嚴重情況，便於團隊得出下個迭代如何改進的建議。每一個 DevOps 工程的狀態扭轉都會作為研發過程的後設資料自動生成相關指標資料。
相應的，DevOps 平臺也應該顯示各個時間的 WIP（在製品數量），以便團隊及時停下來進行針對性干預，避免後面的整體交付效率下降。
此外，DevOps 本身作為一個 toB 的產品，它的視覺化看板和操作檯可以請產品經理進行易用性設計，不斷提高團隊的使用效能。
持續測試的文化建設
真正優秀的持續測試標杆員工，有哪些特點？鼎叔會點贊甚至廣泛傳播這樣的實踐效果。
一，非常複雜但是很穩定的大系統，基於持續測試，讓質量保障遊刃有餘，只需要一個 QA 員工輕鬆搞定。
二，讓開發依賴流水線的持續測試應用。開發每次提交程式碼後都關注持續測試的結果，沒問題才離開崗位。
三，讓外包積極參與持續測試流水線用例的建設，效果穩定。持續測試不應限制測試框架的選取，只看效果，總有適合本外包團隊的自動化測試框架，用心實踐會得到超出預期的效益。
還有什麼要聊的
持續測試想要健康執行的兩大基石，就是測試環境治理和測試資料構造，這兩塊可以作為專項建設來展開，值得深入挖掘。
持續測試的環境
首先要能透明化問題，不要停留在時常的團隊抱怨狀態中。
手段並不難，我們可以監控所有測試機器的線上率，並觸發告警，統計可用率。
針對頻繁掉線的服務和裝置，具體分析原因，定期廣而告之。
測試環境需要一整個鏈條的支援，包括伺服器、手機終端、配置平臺、閘道器證書、鑑權工具，批處理工具、恢復預設狀態的工具，均能正常工作。背後就是要耐心磕細節，收益有可能非常大，因為測試環境可能服務了數百上千的工程師，多投入治理精力是值得的。
測試資料構造市場
對於一個複雜大型業務，參與自動化測試的人員眾多，花費在構造測試資料的成本會顯得很龐大。
業務邏輯鏈條越長，測試資料的呼叫和驗證就更復雜。
封裝一個核心測試資料的自動構造工具（函式），對於縮短測試用例生成時間非常有幫助。我們把可能用上的核心資料工具列在工具市場上，供各團隊選用，使用熱度越高的工具越排在前面。