本節書摘來自華章計算機《騰訊ios測試實踐》一書中的第1章，第1.3節,作者：丁如敏 王琳 等著
更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
品質管理分為兩大類，即研發品質和線上品質。
研發品質：包括品質體系（性能名額+使用者評測）、測試過程資料（bug、通過率）。
線上品質：包括線上資料、使用者回報、漏測率。
品質體系，除産品本身的特性功能外，還包含流暢度、記憶體、耗電量、啟動速度、弱網絡等功能，是使用者體驗能感覺或者影響使用者口碑的。同時需要思考各個名額的比重（主要考慮對使用者的影響程度），這樣可以更好地優化核心名額。
線上品質，研發品質的名額都可以通過預設在被測app裡的埋點上報上來，這樣就有了線上資料。使用者回報主要是通過各回報管道收集使用者的回報資訊。通過對使用者回報資訊的分析，可以得知哪些問題是應當提前發現而漏出去的。漏出去的問題有些可能是因為測試工程師測試設計覆寫不全導緻的，有些可能是因為開發直接修改沒經過測試引起的，有些可能是營運活動引起的。
上面提到了品質體系，那麼具體的産品品質如何衡量？很多公司都以bug來衡量，除bug外，還有一些名額大家會用到，例如代碼品質、代碼覆寫率、測試過程資料。性能名額、使用者評測、使用者回報和線上資料。具體解釋參考如下。
代碼品質：指靜态代碼掃描、架構評審、代碼規範、代碼評審。
代碼覆寫率：指行覆寫、類覆寫、條件覆寫、分支覆寫。
測試過程資料：指測試通過率、回歸通過率。
性能名額：指啟動時間、響應時間、記憶體、流暢度（fps）、cpu、耗電量。
使用者評測：指産品進行使用者調研、使用者體驗、使用者問卷調查等。
使用者回報：指使用者回報的問題或者建議。
線上資料：指上線後的産品資料，如啟動時間、使用者行為資料。
bug：指bug子產品分類（ft分布）、bug各研發階段資料、bug分析。
對于産品度量，騰訊各産品的度量方式也各有特色，圖1-4所示是浏覽器品質體系的一小部分，僅供參考。
圖1-4 浏覽器品質體系（部分）
關于産品品質的衡量，不少公司還是以bug來衡量的，下面先重點介紹bug次元。
引用elisabeth hendrickson在文章《better testing-worse quality?》中的圖來說明“品質”的相關概念，如圖1-5所示。
圖1-5 bug分析模型
圖1-5中左邊的三部分是跟bug相關的，分别是“已知bug”“未知bug”和“預防bug”，右邊兩部分分别是開發品質工作和測試品質工作。
開發品質工作：涉及架構評審、代碼規範、代碼評審、單元測試、開發自測等。
測試品質工作：需求評審、用例設計（利用測試模組化、測試分析等方法來提升測試設計覆寫度）、自動化測試（bvt或者接口測試等）、性能測試、精準測試、探索式測試、基于風險測試（rbt）、bug大掃除、bug分析、bug統計、衆測等。測試品質工作涉及的内容很多，可以考慮再抽練幾個分類，如圖1-6所示。
而這些測試品質工作的開展還需要借助一些平台和工具才可以更高效地完成，如圖1-7所示。
測試品質工作除品質體系外，還包含工程效率。對于工程效率，測試團隊一般圍繞兩個主題來開展：測試效率提升和可測性擴充。
測試效率提升：可以通過項目流程的規範、測試方法論應用、自動化測試的應用等工作，進而更高效地達到工作預期。
圖1-7 測試平台和工具
可測性擴充：可以聯合開發做一些可測性提升的工作，例如接口暴露、代碼解耦等。當然，也可以嘗試覆寫更多沒有覆寫的内容，例如有些項目終端類測試開展不錯，就可以考慮加強背景接口的覆寫；還有黑盒類測試，可以考慮白盒類測試或者灰盒類測試等。
總的來說，測試品質工作一方面是做得更快，另一方面是做得更多。
通過上面對各個子產品的分析，我們再把上面提到品質保證的各項工作映射到elisabeth hendrickson的圖上，如圖1-8所示。
1.已知bug
團隊成員在測試過程中發現的bug（包括但不局限于code review、show case、dogfood、測試發現的bug等）。這些bug一般都會記錄到bug系統中（例如騰訊的tapd），這樣就可以友善進行分析，例如bug分布子產品（浏覽子產品、支付子產品、個人中心等）、各ft的分布（有可能跟子產品有關聯）、各研發階段（疊代、內建、上線前等）、嚴重級别等。通過對bug系統性分析來評估待釋出産品的品質風險，這樣可以給予決策者更好的資料支援。當然，有些bug是可以挂起的，不一定所有都需要修複。
圖1-8 bug分析及測試工作模型
2.未知bug
産品釋出之前未發現的bug，釋出後通過海量使用者回報的問題或者通過統計埋點上報的問題。因為使用者的機型網絡以及資料環境等因素可能觸發潛在bug（而這些bug是整個團隊研發過程中很難出現或者偶爾出現漏過的），借助海量使用者可以放大出現的機率，然後使用者主動回報或者被動埋點上報可以收集到這類潛在bug。
一般産品裡都有使用者回報意見的入口，通過這個入口可以收集使用者使用過程中的問題或者意見。同時有些産品會對某些關鍵邏輯路徑進行埋點，這樣，隻要使用者使用過程中觸發這個埋點，就會自動上報到背景。主動上報的資料就可以進行統計分析，這類資料統計可能差別于使用者行為的統計，更多的是某個邏輯或者路徑的上報。針對這些上報的資料進行資料挖掘，可以幫助發現某些問題最有可能出現的場景，進而可以再結合衆測使用者進行重制，最後解決這些問題。
3.預防bug
主要通過一些流程或者機制充分體驗産品，提前發現一些潛在bug，例如通過需求評審、showcase、dogfood等手段，全員積極參與各階段産品的體驗，就可能提前發現一些需求問題或者設計問題等。
需求評審：需要各方角色（産品、開發、測試、pm、設計等）都能投入精力讨論pk，這樣可以提前把不合理的需求扼殺在搖籃中。
showcase：各個疊代完成後，pm可以組織各個角色參與體驗，盡早發現潛在問題，例如某些設計問題或者體驗上的問題，快速返工，避免後期返工帶來更大的人力消耗。
dogfood：通過持續內建編譯出版本後（有重點需求說明），發送給團隊各成員體驗，及時快速發現問題。這裡更強調産品品質需要全員的參與。
品質工作涉及方方面面以及各個角色，同時必須考慮人力、時間等因素，還得考慮項目的市場競争狀況，這樣才能平衡好以上各項措施的選擇。