不管產品規模是大還是小，結構簡單還是復雜，質量評估都不是一件容易的事情。
盡管很難，但質量評估仍然是必需的，因為關系到版本是否能夠發布、測試工作是否有效、測試投入是否有價值等。
那么，如何把握軟件產品的質量？
發布之前
產品發布之前可以對如下指標進行評估
● Bug
Bug數量、Bug趨勢圖、Bug分布圖等，有利於我們對問題的歸納總結。
● 測試通過率
包括計划的測試用例執行進度、通過的測試用例數目、失敗的測試用例數目、被阻塞的測試用例數目等。一般要求達到95%以上。
我們還利用一次通過率去衡量開發的質量，這里不做詳細的闡述。還可以延伸到模塊通過率，來衡量系統某一具體功能模塊的穩定性。
● 測試覆蓋率
包括業務覆蓋率（核心業務場景）、測試類別（性能、安全測試等）。業務覆蓋率必須全部覆蓋，根據產品的性質，考慮性能指標、安全指標是否需要100%達標。
● 信心
測試負責人對所測版本及需求的主觀感受。作為需求及版本的第一手用戶，測試員對其有比較敏感的判斷。
延伸到我們經常提的：測試總結或者版本發布公告，應該包含但不限於上述提到的幾項指標。
發布之后
軟件產品發布之后一般面向的是項目（面向測試發布的制品進行一輪驗證），亦或者是客戶（直接部署到正式環境，面向客戶使用）。
針對發布后的評估，根據項目或者客戶現場發現的問題數量/(測試發布時發現的問題數量+客戶現場發現的問題數量)*100%
一般統計周期是三個月，一般控制在10%以內算正常，當然也要看問題的嚴重等級。
那么，又該如何更合理的度量產品質量呢？
常見的有千行代碼錯誤率，CMMI級別也定義了每一級的錯誤率：
有的公司也逐漸從CMM1升級到了CMM3，量化的指標比較能夠直觀的反應一些問題，不至於問起來質量好壞都是，我覺得應該可以。
但也有不少詬病：代碼冗余；為了CMMI定級而去沖指標。
所以，我們也不能完全依賴千行代碼錯誤率去評判和衡量產品質量的好壞，測試度量的目標還是提高產品質量。
從研發階段和效率價值金字塔看，自底向上，越早參與測試發現問題，后期的投入就越少，產品質量就越穩定。
自底向上，我們可以做哪些工作來保障產品質量呢：
1. 需求的評審：測試參與
2. 架構設計方案評審
3. 代碼模塊設計，包的依賴的規划，接口的設計的review
4. 代碼的review的機制
5. 測試用例評審
6. 使用代碼檢測工具，自動發現問題
7. 使用自動化測試，自動檢測歷史功能及模塊完整性
8. 完善測試流程，增加性能、安全等未涉及領域測試
9. 漏洞Review分析，測試總結
當然上述每項，單獨做起來都是需要耗時耗力的，前期還要有專人負責牽頭保障效果與執行監督。
產品質量不是測試出來的，需要上游產品設計、開發編碼、架構設計等環節以及下游運維、實施、維護等環節共同保障。
單純依賴測試去保障研發出來的產品，只是冰山一角，更多的問題需要大家共同去關注，協同保障產品質量。
個人認為
完全依賴一些量化的指標去評判產品質量的好壞、測試質量的好壞是不夠的，重點是數據背后的問題，管理者要重視起來，找到問題的根源並有意識的去提升。
這樣產品質量才能持續穩步的提升。