後臺有同學留言問了這樣一個問題：想在團隊內推動質量度量落地，對每版本迭代的交付質量有更好的評估，但沒有太多的實踐經驗，有沒有什麼落地方法或者注意事項。
首先聊聊質量度量本身，即質量需不需要度量？
答案顯而易見：質量需要度量，而且需要持續的度量！為什麼呢？
我們所從事的軟體測試工作(隨著技術不斷髮展，現在也叫作質量保障)，工作物件就是軟體系統。經過需求設計、需求評審、技術設計、程式碼開發、測試驗證、上線釋出等多個環節，才能保障這些軟體的最終交付質量。
這一整套複雜的流程，實際上就是將不確定性(需求)轉化為確定性(具有嚴密邏輯的軟體系統)的過程。確定性，需要一定的衡量標準來評估它是否滿足預期的設計，因此需要一定的資料來進行度量。
而持續度量的原因，是業務和技術本身就處在一個不斷變化發展的狀態，需要持續的度量和評估，才能保障軟體系統的質量長期處在一定的水準之上，滿足使用者需要和保障業務目標達成。
質量度量的本質，是具體的定量，而非抽象的定性。
其次聊聊質量度量的注意事項，這些注意事項是我個人結合工作經歷和實踐總結的經驗教訓，僅供參考。
質量保障是一個體系化和長期建設的過程，而質量度量作為最重要的一環之一，在落地過程中需要持續跟進和最佳化。
- 質量保障不僅僅是QA同學的事情，因此質量度量也不能只關注測試維度。
- 度量指標需要根據團隊特性和業務具體情況來制定，並且需要評估是否合理，而不是強行制定強行執行。
- 質量度量是為了保障最終交付質量能更好的滿足使用者需要，進一步達成業務目標，而非為了度量而強行度量。
- 質量度量並非一蹴而就，在軟體不同的生命週期和團隊成熟度階段，度量的範圍和執行嚴格程度要靈活變通。
最後，分享一些我對於軟體質量度量的一些思考。
1、不要為了度量而度量，找到合適的度量物件很重要。
比如聽一些同學說他們的質量度量指標，就有首次測試用例執行透過率，以及累積測試用例執行透過率。
這兩個指標是為了解決什麼問題？如果只是看到別人有，那我也要做，只是浪費時間和資源。而且你花大力氣去做，大機率也得不到整個技術團隊的認可。
2、度量指標一定要和具體的問題掛鉤，否則指標沒有意義。
最常見的，測試用例覆蓋率，測試用例透過率。這個度量指標的作用是什麼，要解決什麼問題。
比如提測冒煙透過率必須100%，否則證明了主流程存在block，影響測試進度。這個度量指標要解決的是可測性和測試進度，提高從編碼到測試環節的交付產出物質量。
3、度量的指標和數值一定要和直接干係人達成一致。
還是以冒煙提測透過率為例，如果研發團隊不認可，怎麼辦？
很多時候測試團隊沒有太大話語權，沒辦法影響到研發團隊。這個時候要學會迂迴策略。即如果冒煙提測透過率不達標，導致了什麼結果，這個結果的風險是什麼，會帶來什麼不好的影響。然後向更上一層彙報，暴露風險。
4、度量指標和數值不能解決問題，只能證明發生了什麼。
設定度量指標和衡量的數值後，要明確一點：度量產生的資料不能直接解決問題，而是證明產生了什麼結果。
要分析資料背後的原因，什麼原因導致了這個結果，這個原因的風險和對交付質量有什麼不好的影響，然後才是拿著資料和分析的結果去推動改進。
5、落地質量度量有很多前置條件，質量度量不是單一存在的。
舉個例子，透過度量缺陷數量和用例數量以及對應的百分比，來評估每版本的編碼質量。
這個邏輯沒問題，但不是單單搞個對比資料就可以的。缺陷&用例需要和對應的程式碼分支關聯，程式碼又要和需求關聯。否則只有資料，沒有因果關係，證明不了問題，也解決不了最本質的需求不完善和程式碼質量不高的問題。
6、質量度量是一個複雜的技術工程，更需要大量的溝通和協作。
工作真正要解決的是人的問題，技術不存在難點，難點在於思路，以及說服其他人配合你行動。
想清楚再行動，先從小範圍試點，從最痛的點開始，這樣推進的動力更大。