年底慣例，進行本年度工作內容、價值產出總結、彙報，同時明確下一年度的工作規劃。

作為一名測試開發攻城獅，單純的通過梳理產出了哪些工具、框架、平臺功能，似乎只能看到做的多或少，卻感知不到做的好不好，當然多不意味著好。

那麼如何度量測試開發角色的產出價值？本文圍繞測試開發價值產出度量的問題，談下我的一些思考和建議。

追本溯源

追其根本，首先需要搞清楚測試開發角色職責的是什麼，無論通過我們自身對其的認知，還是在各大廠的招聘信息中可以瞭解到其崗位職責要求——圍繞產品質量，提升測試效率，通過不斷的技術創新、應用，不斷提高測試整體流程能力（單位時間能夠提供多少服務）。這背後也有一個問題，效率提升的目的又是什麼？假如一個測試團隊的人數相對固定、測試時間充足，他提升效率的目的又是什麼呢？從這種角度來思考，個人認為測試效率提升的根本意義在於：

• 做更多的有價值的測試（更深入的需求分析、測試設計或者對測試右移的投入）
• 實現真正的縮減成本（減少或抽調人力投入）
• 適應開發模式的轉變，比如類敏捷、devops模式下的頻繁迭代/持續部署。

過去

過去，我們一直嘗試通過持續性的跟蹤自動化測試框架、工具的使用情況（發現缺陷數量、使用次數、實際節省（盈餘）時間等），來感知其發揮的價值（效率提升、質量保障）。但沒有較好的效果，總結了幾點：

1. 缺乏平臺化的統計、反饋媒介，相關數據過多的依賴測試人員的主動反饋，所以效果並不好。
2. 僅通過缺陷發現數量、實際節省時間並不能很好的體現其價值（沒有體現出上述的所提的效率提升背後的意義）

因此僅通過"發現缺陷數量"、"實際節省（盈餘）時間" 並不是可靠的度量方式。

現在

隨著測試流程能力（給定的單位時間能夠提供多少服務）建設在18年的推進和建設，通過平臺化建設提高測試流程能力，依託測試能力分層理念，優化測試服務模式，逐漸形成了

基於"3+N"的測試技術服務模式，如何更可靠、客觀的度量測試開發人員的產出價值，進而推進通過核心價值的發展和增長，顯得尤為重要。

如何對"3"進行價值度量

對於各測試平臺的建設價值的度量，我們採用用戶行為分析中的幾個常用指標，比如日均活躍用戶數、用戶覆蓋率、響應需求數來評估，並已每個大版本或每季度為評估週期，進行持續性的階段評估。

這樣選擇的初衷：若想提高日均活躍用戶數、用戶覆蓋率，測試平臺化公研團隊就需要更加的的關注產品、業務測試的痛點，使之平臺化建設從用戶痛點出發，不斷覆蓋痛點問題的解決，進而擴大用戶數量、群體，從而達到比較高的用戶覆蓋度和日活用戶數量，因此達到平臺化建設的良性循壞的目的。

如何對"N"進行價值度量

以自動化測試解決方案團隊為例，著重考慮自動化覆蓋率、效率提升率、效率轉換三個指標，按季度或版本為週期，進行持續性的評估，以便感知落地後的測試技術服務是否持續性的發揮著原定作用。

• 自動化覆蓋率 = 當前版本該項目自動化測試點/當前版本該項目所有測試點。
• 效率提升率 = 1- 單輪次自動化執行時間/單輪次手動執行時間（針對被自動化測試所覆蓋的用例而言）
• 標準盈餘時間 = （單輪次手工執行時間-單輪次自動化執行時間）*自動化執行次數
• 實際盈餘時間 = 結合標準盈餘時間估算
• 投入產出比 = （標準盈餘時間/自動化測試開發投入時間）*100%
• 效率轉換 = 對實際盈餘時間的分配及相關產出

隨著測試平臺（用例中心、自動化測試平臺）的建設，上述統計項獲取成本已遠低於之前的人工統計。

對應各項指標結合實際情況（如，原則上預期投入產出比小於150%，不開展或者降低優先級），進行整體評估，同時設置S/A/B/C考核級別。這樣不僅可以評估當季度或版本的開展情況，也可以通過長期的考核情況（價值曲線），來評估整體產出價值。

最後之所以做價值度量，不僅是為了體現自身價值，更是為優化價值、提升價值提供參考方向。

閱讀更多 測試開發技術棧 的文章

關鍵字: 測試 職場 追本溯源