在執行過程中，如果我們發現缺陷，通常會將缺陷記錄到缺陷管理系統中，這樣方便對缺陷進行跟蹤和管理。但在缺陷分析過程中，僅僅對缺陷進行跟蹤和管理還是不夠的，還要對缺陷進行監控，監控缺陷的分佈、修復等相關的屬性。
通常對缺陷應該監控以下維度的內容：缺陷收斂趨勢、缺陷分佈、無效缺陷和缺陷修復這幾方面的數據。
一、缺陷收斂趨勢
在前面介紹了缺陷的一些特性，其中包括缺陷收斂性的概念，那麼在測試的整個過程中，就需要去分析缺陷是否收斂。分析缺陷收斂的方法很簡單，具體的步驟如下：
(1)按版本對每個版本的數據進行統計。
(2)然後將每個版本所發現的缺陷數據畫成一張曲線圖，類似於圖9-30。
分析這張曲線圖時，需要確定的每個版本所發現的缺陷數是否呈下降的趨勢，如果呈下降的趨勢，就說明缺陷呈收斂性，否則說明缺陷不是收斂的。如果缺陷不呈收斂性，則說明產品的研發過程存在很大的問題，主要可能表現在以下幾個方面：
(1)產品質量很不穩定，系統的不穩定可能導致缺陷呈波動狀態。
(2)缺陷在修復時，引入了過多的新問題。
(3)測試設計存在很多問題。
(4)測試執行的過程存在很多問題。
二、缺陷分佈
在缺陷監控過程中，還需要對所發現的缺陷的分佈情況進行分析。缺陷分佈應該至少從兩個方面進行分析：一是按功能模塊的分佈進行分析;二是按缺陷的嚴重等級的分佈進行分析。
(1)功能模塊分佈
按功能模塊分佈來分析缺陷，是指按功能模塊來統計每個模塊所發現的缺陷數。按功能模塊統計缺陷的對象主要是核心模塊發現缺陷的情況，當然也可以用來分析所有功能模塊的情況，但沒有必要，因為客戶只會使用一些核心的和基礎的功能。分析的目的主要包括兩個方面：一是核心模塊是否處於穩定狀態;二是核心模塊千行缺陷率。
關於分析核心模塊是否穩定，其實在四象限分析法中有詳細介紹，當然這要對核心模塊持續多個版本的分析才能確定，只能保證核心模塊的穩定性才能保證系統的穩定性。
核心模塊千行缺陷率是用來統計缺陷的密度的，這樣可以用來評估開發和測試的質量，當然這就需要一個參考值，如果沒有參考值，這個值本身就沒有意義了，而這個參考值來源於以前歷史版本或相類似功能模塊的數據。
(2)按嚴重等級分佈
按缺陷的嚴重等級劃分，缺陷是最常見的一種缺陷分佈分析方法。按嚴重等級劃分的目的是分析每類缺陷所佔的比例，項目中不同等級的缺陷應該是以一定比例來分佈的，如果在缺陷分佈中致命和嚴重的比例過高，那就必須分析具體的原因，正常我們希望一般的問題佔的比例更高，這樣說明系統發佈後其穩定性更高。
當然某類缺陷比例過高的原因可能會有很多情況，不過這與測試的方法或策略沒有關係，只與研發的過程中關係。如果需要詳細分析是什麼原因導致嚴重或致命的缺陷比例過高，那就必須對整個研發過程進行詳細的分析，這也是我們常說的通過對缺陷分析來找到研發做得不好的地方，進而改進研發流程。
三、無效缺陷
在測試過程中可能會發現一些無效的缺陷，無效缺陷也是缺陷監控分析的一部分，無效缺陷是指測試工程師提交的缺陷，但開發並不認為是缺陷，並且最終審核後也確定該缺陷不是真的缺陷，這種缺陷被稱之為無效缺陷。
在測試過程中發現的缺陷中，無效缺陷的比例不能過多，一般在一個項目測試過程中發現的無效缺陷應該都是低於5 個的。如果無效缺陷過多，則說明測試對需求的理解方面有問題，導致提交缺陷時出現過多無效缺陷。
那麼是什麼原因導致測試工程師對需求理解的偏差呢?那最主要的是在需求評審時，需求工程師在解釋需求時(也可以說是唱需求)並沒有表達得很清楚，導致對需求的理解出現問題。而目前很多公司在需求評審時，其實很多是沒有詳細解釋需求的過程，而只是在評審過程中，如果評審發現需求有問題，才對有問題的需求進行詳細的介紹。所以就可以發現對需求有著不一樣的理解，這樣就可能提交一些無效的缺陷。當提交的無效缺陷過多時，則說明我們的在解釋需求和評審需求時存在很多問題，需要找到一個有效的方法來完善需求評審的過程。
四、缺陷修復
在整個測試過程上，開發修改缺陷的過程也是必須要去監控和評估的，通常缺陷修復的分析需求包括以下幾個方面的內容：
(1)嚴重和致命類的缺陷修復的情況;
產品在發佈時，不能遺留嚴重和致命類的缺陷，所以在產品發佈之前一定要確保所有的致命和嚴重問題都得到解決。
(2)每個版本所修復缺陷的情況;
統計每個版所修復的缺陷趨勢圖，當然每個版本所修復的缺陷趨勢圖應該與所發現的缺陷趨勢圖是類似的，但主要需要分析以下問題，在所修復的缺陷中，有一些缺陷可能一次性沒有修復完成，或者修復後引入了新的缺陷。這類問題就是我們主要分析的對象，因為當出現這類問題時，就必然會導致修復的缺陷成本升高。當然很少有公司具體去討論這類未能被一次性修復的缺陷所佔的百分比。但如果這個比例超過一定比例時，就必須對研發修復缺陷的過程進行詳細的分析，以確定這類情況的具體原因。
閱讀更多 川石信息 的文章
