從上表可以看到，編碼過程的缺陷大部分依賴系統測試發現。單元測試和集成測試活動開展不夠深入。我們可以進一步分析這些統測試出來的測試缺陷，是不是可以被更前端的評審/測試/設計討論活動所替代。詳細見“四、利用泄漏的下游缺陷回溯過程有效性”
另外，我們看到，需求階段引入的缺陷絕大部分是在設計階段發現的。這可能是我們大部分項目的一個現實，需求不穩定、需求不明確，很多東西需要在設計過程中才能明確下來。也許從這個分析結果中給我們一個啟示，我們在設計評審時候，也需要重新審視我們的需求規格說明書，必要時候利用需求追蹤矩陣這樣的規矩方法來輔助我們發現上游需求的缺陷。把這樣的機制固化起來，作為我們標準研發過程的一個要素或者過程指導書。
當然，實際規劃“缺陷引入-發現矩陣”時，可以依據自己的管理要求，對缺陷的發現活動和引入階段進行細分或初分，并且在Bug系統中提交時，需要準確的填寫這些屬性字段。
- 利用缺陷的分布進行分析
- 可以選某個階段的測試缺陷進行分析，按照這些缺陷對應的產品組成部分來匯總這些數據。利用這樣的分布，可以找出我們產品/項目的高危模塊來。這些模塊導致了我們產品的主要缺陷。主要用到的分析手段是數據透視表和柏拉圖。讓我們看看下面的例子：
這是一個簡單的OA系統，它只有5個子系統。我們把這些子系統各有多少缺陷列出來，找到了改善質量的關鍵模塊是后臺交易模塊。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/