圖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-8 bug分析及測試工作模型
2.未知bug
產品發布之前未發現的bug，發布後通過海量使用者反饋的問題或者通過統計埋點上報的問題。因為使用者的機型網路以及資料環境等因素可能觸發潛在bug（而這些bug是整個團隊研發過程中很難出現或者偶爾出現漏過的），借助海量使用者可以放大出現的概率，然後使用者主動反饋或者被動埋點上報可以收集到這類潛在bug。
一般產品裡都有使用者反饋意見的入口，通過這個入口可以收集使用者使用過程中的問題或者意見。同時有些產品會對某些關鍵邏輯路徑進行埋點，這樣，只要使用者使用過程中觸發這個埋點，就會自動上報到後台。主動上報的資料就可以進行統計分析，這類資料統計可能區別於使用者行為的統計，更多的是某個邏輯或者路徑的上報。針對這些上報的資料進行資料探勘，可以幫助發現某些問題最有可能出現的場景，進而可以再結合眾測使用者進行重現，最後解決這些問題。
3.預防bug
主要通過一些流程或者機制充分體驗產品，提前發現一些潛在bug，例如通過需求評審、showcase、dogfood等手段，全員積極參與各階段產品的體驗，就可能提前發現一些需求問題或者設計問題等。
需求評審：需要各方角色（產品、開發、測試、pm、設計等）都能投入精力討論pk，這樣可以提前把不合理的需求扼殺在搖籃中。
showcase：各個迭代完成後，pm可以組織各個角色參與體驗，盡早發現潛在問題，例如某些設計問題或者體驗上的問題，快速返工，避免後期返工帶來更大的人力消耗。
dogfood：通過持續整合編譯出版本後（有重點需求說明），傳送給團隊各成員體驗，及時快速發現問題。這裡更強調產品質量需要全員的參與。
質量工作涉及方方面面以及各個角色，同時必須考慮人力、時間等因素，還得考慮專案的市場競爭狀況，這樣才能平衡好以上各項措施的選擇。
《騰訊iOS測試實踐》一一1 4 測試分析
1.4.1 黑盒測試分析 黑盒測試是軟體測試的主要方法之一，也可以稱為功能測試 資料驅動測試或基於規格說明的測試。測試者無須了解程式的內部情況，無須掌握應用程式的 內部結構和程式語言的知識，只要知道程式的輸入 輸出和系統的功能即可。這是從使用者的角度針對軟體介面 功能及外部結構進行測試，而不考慮程式...
《騰訊iOS測試實踐》一一1 2 工程效率
總體來說，工程效率就是研發效率 包含測試效率 這裡我們會把測試效率單獨提出來進行說明，因為這是與測試工程師相關度最大的工作。研發效率，其實就是讓產品上線的時間更快 在品質有保障的前提下 大多數時候是說與研發流程相關的 不侷限於敏捷流程，feature team研發模型 例如包含但不侷限於以下活動。需...
《騰訊iOS測試實踐》一一1 6 資料反推
1.6.1 測試過程中的資料 測試資料反推 充分利用各類測試資料的優化流程，進一步保障產品的質量。在各階段的測試過程中會產生大量資料，例如bug資料 測試通過率 回歸通過率等。那麼如何充分利用這些資料呢？前面已對已知bug以及未知bug進行了討論。現在換個角度，從bug產生的階段來分析，圖1 12是...