這是鼎叔的第一百一十六篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本公眾號《敏捷測試轉型》，星標收藏，大量原創思考文章陸續推出。本人新書《無測試組織 - 測試團隊的敏捷轉型》已出版（機械工業出版社），文末有連結。
我們繼續聊聊在整個軟體生命週期中，以及各個主要階段，我們選取哪些關鍵拆解指標做好研發過程的提效治理。
一 需求分析階段
基於測試左移到需求階段的知識 ，聊聊測試左移到需求階段，https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484386&idx=1&sn=219bd680bdd83246517871b47da0a7a8&scene=21#wechat_redirect
我們如何透過度量手段，保障高效的需求分析措施能落地？
完成需求評審後，推薦在研發管理平臺錄入以下度量指標，方便團隊迭代回顧和改進。
需求評審的問題攔截數，或攔截率（需求評審階段發現的問題，佔整個研發週期發現問題的比重）：在需求研討階段發現的問題越多越好，這意味著大量的無效開發和測試會被節省下來，同時這也標誌著技術和產品的研討是非常高效的。
需求驗收測試用例數和覆蓋率：在需求評審階段，如果團隊將每個需求都明確了驗收標準和合適數量的驗收用例，就對驅動開發進行高質量的程式碼實踐提供了保障（這個保障是有團隊共識的），避免開發目標的跑偏，同時保障了交付的最基本質量。既然有驗收測試用例，證明需求的可測性就不是問題。
需求平均大小（顆粒度）：每個需求的平均大小（故事點）處於合適的值，按照經驗，小批次需求的平均開發量最好為 2-3 理想人日，測試驗證就會非常及時。
需求評審效率，即需求開發預估時長/需求評審時長。注意，效率太高或太低都不是好事，都值得改進。如果太高，可能反映了需求評審會的討論不充分，有悖於 “磨刀不誤砍柴工” 的質量左移原則。如果太低，可能反映了需求邏輯沒有經過事先的充分思考，需要先小範圍交流和打磨，再進入團隊集體評審，節約團隊時間。相似的指標還有需求評審透過率，我們同樣不追求需求評審要一次透過，而是更多地關注需求評審不透過是否因為缺乏可測性描述。
需求文件完整度。我們可以在需求規格文件（PRD）的模版中加入 “可測性分析” 需要的關鍵技術資訊（具體可以參考內容聊聊需求評審與驗收測試），這樣有利於開發和測試提高設計質量，儘可能減少後期返工和浪費。因此技術團隊可以針對哪些關鍵資訊的缺失來給出 PRD 的 “完整度” 分數，常見的關鍵資訊有：需求背景，市場和競品分析，業務目標/價值，業務流程圖，需求功能清單和描述，效能/安全/資料要求，對外依賴關係，需求限制說明等等。
注意，敏捷不追求重文件，對於大家都清楚的資訊，即使 PRD 文件沒有說明，也可以認為是完整的。
二 開發設計與編碼階段
開發團隊的管理者理應重視工程實踐中的質量和速度，儘可能降低工程師操作的繁瑣程度，提高編碼階段和單元測試階段的發現問題效率，儘可能讓工程師處於 “心流” 之中（即沉浸式研發）。那麼如下的指標就凸顯了其重要性。
開發中斷時長和次數：在整個開發週期，開發被迭代無關事項打擾的次數和時間。管理者或者教練應該儘可能讓開發有持續的思考和編碼時間，進入高效率的工作狀態。
需求測試驗收一次透過率：有多少個需求開發提測後，是一次性透過測試的？這個比例越高，說明開發和測試互相流轉缺陷狀態和迴歸任務的消耗成本是越低的，也說明開發側質量很靠譜。
單元測試程式碼覆蓋率：對於單測，應該追求核心程式碼的被覆蓋率到一定比例，新增和存量覆蓋率可以有一定差別，比如增量程式碼覆蓋率 80% 以上，存量程式碼覆蓋率 50% 以上（僅供參考）。此外，持續測試中的單測透過率應該要求 90% 以上甚至 100%。
程式碼評審透過率：預設提交主幹的程式碼都需要透過程式碼評審，有明確的簽署人，評審改進意見入庫。程式碼評審的基礎除了對業務要有深刻理解，也需要大家對程式碼規範的共識，這一塊 QA 可以做較多的推動培訓和審計工作。
程式碼掃描阻塞（Block）問題數量及解決率：針對有效的程式碼掃描問題（非誤報），開發團隊可以設定門禁規則，提高掃描出阻塞型問題的解決率，追求儘量短的處理時長，避免人員經常忽視，導致技術債越來越多。相似的指標還有程式碼掃描重要（Major）問題的數量及解決率。
程式碼圈複雜度和程式碼重複率：這兩項指標是有潛在高收益的可改進項，圈複雜度會帶來可測性的極速下降，以及邏輯理解難度的快速增加，相對於程式碼缺陷密度更有指向性。程式碼缺陷密度和測試能力及業務結構都有密切關係，難以橫向對比判斷。程式碼重複率說明程式碼重構方面有不足，可以藉此進行簡潔程式碼的改造。
Crash 率和 ANR（Application Not Responding 響應超時）率：挑選這兩個質量指標作為開發改進的重點，原因是它具有通用性（所有業務都不能容忍這個值過大），明示了程式碼質量的嚴重顯性問題（使用者的感知非常強烈），自動監控工具和分析定位工具也高度成熟。從經驗上說，開發團隊的基礎素養在對 crash 率的修復態度上可以體現出來。
聯調人力成本：如果介面定義和異常設計的水平高，聯調的成本就會大幅下降。對於複雜的軟體系統，呼叫鏈路的長度、跨域響應的數量、基礎服務的穩定性、單個微服務的質量，都會影響聯調的成本。因此，縮短該成本的努力，也是完善架構設計細節的過程，其回報也是值得的。
三 測試階段
測試管理者首先要關注測試環境的可用性，方便、穩定、隨時可以進入測試，其次是對自動化框架的強大整合能力，對於手工測試的提效和覆盤也不可或缺。敏捷測試需要的 “測試左移” 實踐則是管理者應該修煉的方向。下面這些關鍵指標有利於測試管理者始終把控關注重心。
測試環境準備時長和測試環境恢復時長：測試環境是阻礙測試效率提升的老大難問題，耗時多的地方在於：一、環境準備時間通常很煩人，耗時佔比驚人。二、環境不穩定，經常需要停下來重啟或者尋找故障所在。如果這塊度量資料總是不理想，技術團隊就需要停下來進行專項治理了。高效能的團隊，環境的分配、準備和恢復都應該是高度自動化的，無需使用者操心。
重複執行手工用例佔比：雖然我們並不追求測試自動化率越高越好，但是手工測試的 “完全” 重複執行是值得警惕的效能窪地。當我們識別出這一塊用例集，就需要思考自動化它們的成本是否值得，未來是否仍然會頻繁地執行它（比如用例場景是否高度確定）。
測試獨佔週期：有些公司把這個指標定義為從開發提測到收到首次測試完成報告的時間。還有些公司把它定義為從開發提測到測試階段徹底完成的時間。不管如何定義，這個時間都指示了測試階段應如何縮短給開發的 “反饋” 週期，也驅動測試人員儘量的 “左移” 質量準備工作，並充分利用好自動化工具。從經驗上判斷，如果迭代中的測試獨佔時間超過了開發獨佔時間的一半，那我們就需要關注哪些環節存在效率改進或 “左移” 的空間，比如測試設計耗時過長，或者多種測試任務可以並行。
系統測試缺陷佔比：系統測試是迭代使用者故事均完成測試後，整個產品進行的全面測試，以透過上線前的所有質量保障環節。如果每個使用者故事都提前進行了充分測試和修復，到系統測試階段能發現的問題就會大幅下降。顯然，這個比例越低，代表著產品釋出的風險越低，測試左移越成功。當然，我們也可以只度量嚴重級別以上的缺陷。我看到不少公司都拿系統測試缺陷總數來考核測試人員績效，發現缺陷越多代表績效越高，這顯然是違反敏捷價值觀的。
平均缺陷發現耗時：缺陷被發現的時間減去缺陷被引入的時間，缺陷發現時間越短，說明測試敏捷度越高，左移效果越佳。從這個耗時分析 “為什麼問題沒有被儘早發現”，可以提煉出不少針對性的敏捷改善動作。同理，還有平均缺陷解決耗時（從缺陷報告到缺陷確認修復的時間），可以用來推動開發提高解決問題的速度。缺陷的整個生命週期在研發管理系統中都有狀態變更的時間記錄，只要及時更新狀態，我們就可以審視這個最關鍵質量處理過程的效率。
版本遺留缺陷 DI 值：完成測試時，還有多少有效缺陷沒有被修復，DI 值是否可控（即缺陷按優先順序加權後的總數，比如阻塞缺陷算 10 分，嚴重缺陷 3 分，普通缺陷 1 分，輕微缺陷 0.1 分）。正常情況下，阻塞缺陷一定要修復，或者被緩解（即部分修復以致降低嚴重等級），才能進入待發布階段。
四 迭代整體指標
敏捷研發以迭代為週期進行，我們可以根據業務形態和釋出成本，決定是隻完成使用者故事，還是將其釋出上線。因此，從迭代的角度來看效能指標，可以重點關注下面這些。
迭代實際交付需求總點數和偏差率：迭代完成的所有需求的點數大小，與迭代計劃評審時估算的本迭代應完成故事點數進行對比，看看有多少需求沒能完成。分析沒有完成的原因，以及團隊估算在哪裡出現了誤判。
迭代無關活動時長佔比：回顧本迭代中，那些活動是和迭代計劃需求無關的，一定比例內是正常的，總有一些外部事件要處理，但是活動佔比高的話可以分析其 “干擾” 所在。敏捷研發的要求是每個人的工作應專注在特性團隊內。
迭代等待時長：可以拆解為，需求待評審時長，需求（已完成評審）待開發時長，需求（已完成單元測試）待聯調時長，需求（已完成聯調和開發自測）待測試時長，需求（已完成測試）待發布時長。如果能夠度量出各個階段的 “等待” 時長，就可以知道哪裡存在拖延的現象，進而能針對性的最佳化。
持續部署效率（耗時和成功率）。為了確保迭代成果能隨時可測或可釋出，就需要將其（聯同配置指令碼）自動化部署到測試環境，預釋出環境或正式環境。關注部署自動化流水線的效率，解決部署過程中出現的阻塞錯誤，可以保障研發迭代的交付效率。
五 釋出和運營階段
在釋出和運營階段，出現任何問題，應對法則都是 “唯快不破”，儘量預防故障，儘早識別故障，儘快恢復服務，降低損失。以下指標是關鍵的指示器。
MTBF（Mean Time Between Failures ）：讓連續穩定工作時間最大化。
MTTR（Mean Time To Recover）：讓故障恢復時間最小化。
釋出活動健康指標，包括：
釋出頻率是否健康，釋出成功的頻率應該符合應對市場競爭的預期。
釋出異常次數和釋出回滾次數，分析異常原因和改進措施，這個考核非常關鍵。
釋出過程耗時，這一塊可以儘可能縮短，降低釋出成本。
灰度釋出相關指標：是否滿足灰度計劃，及時釋出到了正確的灰度使用者範圍，採集到了反饋資料。
故障響應時間：針對線上故障的應急響應能力，是否達到標準要求。
業務線上監控指標。針對業務的每個核心服務，都可以監控呼叫總量，呼叫成功率，QPS。針對呼叫異常情況，可以進一步的監控錯誤碼 TopN，圍繞主要錯誤發生的數量和頻率發起告警和處理。圍繞業務健康度的核心指標，可以放到線上監控的實時儀表盤上，如訂單量和交易金額，以便團隊可以共同關注業務的異常波動。關鍵資料（尤其是資金資料）正確性監控，其重要性不亞於核心服務健康度的監控。
六 最後，全面覆盤
當需求真正釋出上線後，我們如何透過覆盤，度量需求是否達成設計預期？
我們可以定期組織對已上線需求進行復盤，在研發管理系統中及時填入相應度量資料，方便團隊對需求 “是否實現了預期目標（價值）” 進行反思和改進，SM、PO 和技術 leader 都應參加。參考聊聊需求的價值如何度量。https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484491&idx=1&sn=76f02238329258c22755eedf310c0482&scene=21#wechat_redirect