研發過程中的質量度量

測試工程師，本質上就是產品的質量檢查員。我們把開發做好的產品拿過來進行檢測，從而發現問題，進而解決問題。作為測試，我們應該是比產品更懂技術，比開發更懂產品。測試人員，對於產品的業務邏輯，可能會比產品同學還要更為明白。這樣來說，測試對於產品質量的把控尤為重要。

在測試中，從底層的白盒測試，再到ui層的黑盒測試；從相關的介面測試，再到產品的效能測試。從不同的角度來對產品進行測試，檢查產品質量。

測試工作中，我們一般從兩個方面來進行質量度量：產品質量和測試質量

從產品質量角度出發，我們常常遇到下面的問題：

當前產品的版本跟以往版本相比，質量有變化嗎？變化在哪？

在我們qa做了很多的測試工作之後，產品質量上提公升了多少？

當前提測的版本如何，什麼情況下能夠達到上線的標準?

從測試質量角度出發，我們同樣也會遇到類似的問題：

1. 專案測試負責人，制定的測試計畫全面嗎？

2. 測試設計準確嗎？

3. 測試人員，對於測試的執行靠譜嗎？

意義：對於上述這些問題的**，我們能夠對於測試工作進行全面思索，更加完善自己的測試工作。

也能從中間找出自己的測試目標，對測試工作的重點進行合理安排。

同時，一些考量標準的制定和實施，能夠量化出每個產品的質量。

最後對於測試工作中的總結，能夠沉澱出自己團隊的一些質量保障體系。

下面給出一些核心度量指標供參考：

客戶端測試質量

研發流程和對應的測試型別

測試環境：

線上：

一是，使用sonar平台，進行掃瞄靜態**。sonar有自己的原生規則，也有不同的外掛程式，同時也可以根據具體的需求進行二次開發。目前是應用比較廣泛的通過量化的方式度量**質量變化的平台。

二是，千行**bug率。將bug和需求平台相關聯，將git和**平台相繫結。這樣能夠得到分子(bug數)和分母(**量)，相除就能得到。第一次使用這個量化資料可能沒有什麼參考意義。但是多個專案的bug率，就能會有比較明顯的比較。

千行**bug率的粒度，可以設定，可以根據審核緯度的設定來設定。

通過測試工作的總結，形成自己團隊的質量保障體系：

建立適合自己團隊業務的質量度量體系：

以上內容主要是來自美團測試經理鈕博彥分享的文章，加上了自己的理解和總結，寫了這樣一篇部落格。