1.6.1 測試過程中的資料
測試資料反推—充分利用各類測試資料的優化流程，進一步保障產品的質量。在各階段的測試過程中會產生大量資料，例如bug資料、測試通過率、回歸通過率等。那麼如何充分利用這些資料呢？前面已對已知bug以及未知bug進行了討論。現在換個角度，從bug產生的階段來分析，圖1-12是不同階段bug修復成本曲線。
圖1-12 不同階段bug的修復成本[3]
針對bug各階段的分析，根據圖1-12中bug越早發現解決成本越低的結論，需要盡可能在最早引入的階段發現bug。針對某些階段漏過的bug分析，要盡可能完善測試設計覆蓋，避免bug都留到整合階段發現，降低版本延期發布風險，從而開發出更高效的發布版本。
例如某個專案，整合測試發現的bug佔比只有整個版本（所有各分支版本）發現bug的3%～6%，這些bug大多是分支合流跟主幹耦合的問題，還有一些是機型覆蓋或者運營配置問題。大多數bug都已經在各ft（feature team，特性模組）分支上發現了，這樣整合後的發布風險就會大大降低，加快了發布速度。圖1-13是ft分支的合流模型，各個分支ft都能充分保證質量，這樣合流後整合測試問題就很少了。
圖1-13 分支合流研發模式
也許有人會說3%～6%並不算少，確實，不同專案有不同要求。這裡介紹的思路就是充分利用這些資料去思考與分析，推動團隊採取動作，逐步降低該比例，逐步降低發布風險，提公升發布效率。 分支合流模型的測試如何開展是另外乙個話題，不過大體思路都差不多，除了基本持續整合外，還需要自動化測試（bvt、介面測試、終端效能測試等）的支援，才能快速支援分支合流的快速研發模型。
再舉乙個例子，bug各模組分布，有些模組bug問題比較多，可能需要特別關注測試，因為根據測試的二八法則—80%的缺陷出現在20%的**中，所以對這些模組需要多分析多做測試，這樣可以更大可能發現潛在問題。一般來說，不同模組會對應不同的開發團隊或者ft，也可以通過bug來評估開發團隊（或者ft）的成熟度，根據不同的開發團隊（ft）制定相應的改善措施，用資料說話，這樣更好地推動團隊的正向優化。
表1-1所示的是另外乙個專案團隊某個版本的各個ft存在的缺陷佔比，從表中可以看出模組a是缺陷高發區，出現這種情況需要和對應模組的負責人進行溝通，細查原因，以利於改進。
以上僅僅是從bug模組分布來分析bug資料，其實還可以從很多維度（從開發人員的維度、使用者行為的維度等）去挖掘bug資料，充分利用bug資料來優化測試設計，提公升測試效率。
1.6.2 線上資料
《騰訊iOS測試實踐》一一1 4 測試分析
1.4.1 黑盒測試分析 黑盒測試是軟體測試的主要方法之一，也可以稱為功能測試 資料驅動測試或基於規格說明的測試。測試者無須了解程式的內部情況，無須掌握應用程式的 內部結構和程式語言的知識，只要知道程式的輸入 輸出和系統的功能即可。這是從使用者的角度針對軟體介面 功能及外部結構進行測試，而不考慮程式...
《騰訊iOS測試實踐》一一1 2 工程效率
總體來說，工程效率就是研發效率 包含測試效率 這裡我們會把測試效率單獨提出來進行說明，因為這是與測試工程師相關度最大的工作。研發效率，其實就是讓產品上線的時間更快 在品質有保障的前提下 大多數時候是說與研發流程相關的 不侷限於敏捷流程，feature team研發模型 例如包含但不侷限於以下活動。需...
《騰訊iOS測試實踐》一一1 3 品質管理
圖1 4 瀏覽器品質體系 部分 關於產品品質的衡量，不少公司還是以bug來衡量的，下面先重點介紹bug維度。引用elisabeth hendrickson在文章 better testing worse quality?中的圖來說明 質量 的相關概念，如圖1 5所示。圖1 5 bug分析模型 圖1 ...