從缺陷率到質效工作的本質

來源：圓小豆的美夢工場

作者：於曉南

討論來自一個社群朋友。

一、缺陷率迷思

1.1 千行程式碼缺陷率被廢棄

千行程式碼缺陷率 = Bug數量 / 千行程式碼數

這是一個經典指標，以前在研發側經常用來衡量程式碼質量，近年被逐漸棄用。

原因是這個指標有負面的引導，似乎不鼓勵寫高質量的簡潔程式碼，而稀釋程式碼或造輪子則能帶來比較好看的資料，這與指標設定的初衷“提升程式碼質量”相悖。

因此，該指標不建議橫向比較，不建議作為績效指標。但可以作為程式碼質量指導基線，或作為工程師的自我修養，用於自我評估和改進。

附上在CMMI裡對千行程式碼缺陷率的標準，不難看出缺陷率還是以一個滿足該等級的基線值存在的，也就是說它不能用來衡量程式碼質量有多好，但可以用來衡量程式碼質量最差不能低於什麼水平。

1.2 缺陷率無法體現軟體質量

缺陷率 = 失敗的用例數 / 執行的用例總數

從字面意義上理解，這個指標看著像是衡量軟體質量的。但放入研發體系內思考，通常在不同版本間，執行的用例總數是變化的，失敗的用例數也取決於用例執行者的判斷，而失敗的用例又不一定會以缺陷的形式來跟蹤。所以這個指標很難有確定的標準，那麼它還是有意義的嗎？

我認為是有意義的，意義在於它揭示了測試設計的質量，即經過設計的測試用例能否有效發現缺陷。從這個維度上講，這個指標恐怕叫“用例有效率”更恰當一點。

不管是千行程式碼缺陷率，還是測試統計的缺陷率，統計時難免會陷入資料的迷思。片面追求資料好看，對團隊的副作用很大，結果可能是既不經濟、也沒成效，平白做了很多無用功。思考質效工作如何經濟又高效，有助於避開區域性最佳化的泥沼。

二、質效管理投資回報

2.1 不是指標的鍋，而是思路偏差

由上面的討論容易得出以下結論：

• 第一，從度量引導團隊改進的意義角度來看：指標數量絕對值 < 指標的環比（無任何時間間隔，連續週期內的變化），應更多關注團隊指標的變化趨勢，以及思考是什麼原因引起的變化，該如何改進；
• 第二，團隊內的任何投資，都需要考慮投入產出比 ROI，為了得到結果而付出巨大的代價，本身就是一種失效。尤其當資源被投入到“質效提升或管理”這類成本高見效慢的活動時，考慮是否經濟尤為重要。

• 在定義階段發力，成本低、見效期長，但治理效果最好，問題根因也往往會追溯到此；
• 在實施階段發力，成本高、見效期短，但治理效率偏低，資料好看但治標不治本。

三、質效工作本質是打造高效高響應系統

• 軟體本身的可測性：當軟體可測性較低時，自動化成本就會飛昇，甚至根本不具備可自動化的條件。而這個因素的可控性受制於軟體的架構設計，在軟體成熟期不具備可改進的靈活性。因此建議在做架構設計時就充分考慮軟體可測性，否則後續的自動化測試會難以開展。
• 人員能力：這裡不僅僅指自動化測試的編碼能力，更要求測試人員具備一定的測試設計能力。能夠充分理解測試分層，不同層的測試服務於什麼目標，解決什麼問題，以及測試的框架選型等能力。
• 資源配置：指團隊的研發節奏，能否有餘力進行充分的自動化測試。
• 環境依賴：自動化測試如果不能持續執行，就會失去儘早暴露缺陷的時機，而持續執行依賴於能排除干擾的穩定環境。
• 工具鏈割裂：指團隊的工具鏈體系是否支援自動化測試持續整合，或者不同層級的自動化測試工具是否具備一致性。這在一定程度上影響自動化測試的可維護性。