1、 缺陷跟蹤管理的目標
缺陷能夠引起軟件運行時產生的一種不希望或不可接受的外部行為結果，軟件測試過程簡單說就是圍繞缺陷進行的，對缺陷的跟蹤管理一般而言需要達到以下的目標：
確保每個被發現的缺陷都能夠被解決;這里解決的意思不一定是被修正，也可能是其他處理方式(例如，在下一個版本中修正或是不修正)，總之，對每個被發現的BUG的處理方式必須能夠在開發組織中達到一致;
收集缺陷數據并根據缺陷趨勢曲線識別測試過程的階段;決定測試過程是否結束有很多種方式，通過缺陷趨勢曲線來確定測試過程是否結束是常用并且較為有效的一種方式。
收集缺陷數據并在其上進行數據分析，作為組織的過程財富。
上述的第一條是最受到重視的一點，在談到缺陷跟蹤管理時，一般人都會馬上想到這一條，然而對第二和第三條目標卻很容易忽視。其實，在一個運行良好的組織中，缺陷數據的收集和分析是很重要的，從缺陷數據中可以得到很多與軟件質量相關的數據。
2、 缺陷的描述
對缺陷的描述應該包含以下的內容：
|
可追蹤信息 |
缺陷ID |
唯一的缺陷ID，可以根據該ID追蹤缺陷 |
|
缺陷基本信息 |
缺陷狀態 |
缺陷的狀態，分為“待分配”、“待修正”、“待驗證”、“待評審”、“關閉” |
|
缺陷標題 |
描述缺陷的標題 | |
|
缺陷的嚴重程度 |
描述缺陷的嚴重程度，一般分為“致命”、“嚴重”、“一般”、“建議”四種 | |
|
缺陷的緊急程度 |
描述缺陷的緊急程度，從1－4，1是優先級最高的等級，4是優先級最低的等級 | |
|
缺陷提交人 |
缺陷提交人的名字（郵件地址） | |
|
缺陷提交時間 |
缺陷提交的時間 | |
|
缺陷所屬項目/模塊 |
缺陷所屬的項目和模塊，最好能較精確的定位至模塊 | |
|
缺陷指定解決人 |
缺陷指定的解決人，在缺陷“提交”狀態為空，在缺陷“分發”狀態下由項目經理指定相關開發人員修改 | |
|
缺陷指定解決時間 |
項目經理指定的開發人員修改此缺陷的deadline | |
|
缺陷處理人 |
最終處理缺陷的處理人 | |
|
缺陷處理結果描述 |
對處理結果的描述，如果對代碼進行了修改，要求在此處體現出修改 | |
|
缺陷處理時間 |
缺陷處理的時間 | |
|
缺陷驗證人 |
對被處理缺陷驗證的驗證人 | |
|
缺陷驗證結果描述 |
對驗證結果的描述（通過、不通過） | |
|
缺陷驗證時間 |
對缺陷驗證的時間 | |
|
缺陷的詳細描述 |
對缺陷的詳細描述；之所以把這項單獨列出來，是因為對缺陷描述的詳細程度直接影響開發人員對缺陷的修改，描述應該盡可能詳細 | |
|
測試環境說明 |
對測試環境的描述 | |
|
必要的附件 |
對于某些文字很難表達清楚的缺陷，使用圖片等附件是必要的 |
3、 缺陷管理的一般流程
文章來源于領測軟件測試網 http://www.k11sc111.com/
