本週我們的討論話題是關於測試質量管理：
討論話題
- 問題：產品研發流程中有哪些質量數據？如何利用這些質量數據？
- 問題描述：在產品研發流程中，其實不僅僅有我們提的bug數量這一質量數據。還有很多可以衡量產品質量的數據緯度，比如：產品需求變更次數。
我們的最終目標是保障產品質量，提升產品質量的穩定性。因此，在你的工作中有統計哪些質量數據呢？是怎麼利用這些質量數據的呢？
大家討論分享的結果
本週只有一位同學參與討論，不過我會詳細闡明下我的觀點。
某公司測試工程師—呂俊傑
其實個人不太建議單純的使用bug數量或者嚴重bug數量作爲質量好壞的依據甚至開發人員考覈。如果真的要看，還是有些重要的指標的，就是bug reopen的次數，冒煙測試的通過率，bug修復的時間效率，上線後反饋bug，bug燃盡圖(波峯時間，收斂時間，拐點等)。項目有大小，也要輕重緩急，項目和項目之間沒什麼好比較的，還是需要看在整個項目過程中，從立項到項目上線期間，這個流程是否合理，是否完成了每個階段的里程碑。
不過他的觀點主要還是圍繞着bug，其實我覺得應該有更多的緯度。
我的觀點
我覺得思考這個問題的出發點是產品質量，所有可能影響產品質量或者穩定性的因素都可以考慮進去。我覺得大致可以從以下幾個方面考慮：
- 產品需求評審通過率：以產品feature爲單位劃分，計算每次需求評審通過率。從項目週期角度來看，產品需求評審不通過，會影響產品的正常研發效率。
- 產品需求變更次數：所有的開發和測試同學，最痛恨的應該就是需求改改改了吧？！每次需求變更，都需要重新評估開發和測試時間，會影響產品正常上線。統計這個數據，也能一定程度給產品經理思想壓力，在設計需求時，做更多的考慮。
- 開發自測通過率：開發研發完成提測時，一定要統計它們自測通過情況。我們可以將測試用例中P0/P1級別的用例提供給開發，讓他們進行自測。這個數據很重要，可以直接衡量開發的研發質量和工作態度。
- 【可選】開發單元測試覆蓋率/通過率：如果你的公司，已經推行了單元測試，那麼可以在提測打包時，獲取單元測試的質量數據。當然這有個前提，開發的單元測試場景得足夠充分，建議測試同學能查看開發的單元測試代碼。
- 靜態代碼檢測數據：這個實現成本挺低的，可以在Jenkins裏做個持續集成項目，當開發提測時（一般是合代碼到qa分支），自動觸發進行代碼掃描，將常見的問題（比如：空指針）提前暴漏出來。衡量指標可以是：不能有P0、P1級別的問題，P2、P3級別的問題不能超過多少個。
- bug整體數據：我個人覺得，bug給出一個整體的數據即可，比如：總共有多少個bug、遺留了多少個bug、reopen bug的數量、P0級別bug數量、P1級別bug數量。假如想統計每個開發同學的bug數據，我建議統計兩個指標：P0級別bug數量（可以反映研發質量）、reopen bug數量（可以反映研發質量和工作態度）。
- 線上bug數量：產品上線後，要統計用戶反饋的問題，是否有P0級別的致命問題出現。強烈建議組織產品質量覆盤會，針對出現的問題，總結優化工作流程。
- 線上產品質量數據：這主要依賴各種監控平臺，比如移動端產品一般有crash率統計工具bugly、服務端產品有質量監控報警平臺或者接口自動化監控等，這些數據可以作爲產品質量的一個衡量緯度。
總結
上面列了一些質量數據可以參考的點，可能不全。大家如果有其他的建議，可以跟我聯繫，我再補充。
總之，我建議大家在平時的工作中，要善於利用各種質量數據，一來可以爲我們的軟件測試工作服務；二來這個數據一定程度可以提升測試在團隊中的地位。