一、缺陷常用字段說明
二、缺陷管理流程圖
三、開發人員修改缺陷填寫規范
四、項目經理決定延期修改缺陷
一、缺陷常用字段說明
1、摘要
對缺陷的簡單描述。摘要包括該缺陷所屬的模塊名稱-子模塊名稱，以及簡單說明缺陷情況。
2、描述
詳細描述重現該缺陷的步驟，錯誤現象和期待結果。必要時可以上傳附件輔助說明。
3、狀態
序號 | 缺陷狀態英文名稱 | 缺陷狀態中文名稱 | 缺陷狀態描述 | 備注 |
1 | New | 新建 | 測試中提出報告缺陷，普通開發人員無權修改狀態為“新建”的缺陷，只能修改狀態為“打開”或者“重新打開”的缺陷。“新建”的缺陷需要項目經理確認并將狀態置為“打開” | |
2 | Open | 打開 | 被確認并分配給相關人員處理 | |
3 | Fixed | 修復 | 開發人員已完成修正,等待測試人員驗證 | |
4 | Closed | 關閉 | 缺陷已被修復 | |
5 | Reopen | 重新打開 | 缺陷未被修復 | |
6 | Rejected | 否決 | 拒絕修改缺陷，該缺陷可能由于測試人員理解錯誤，或者項目經理認為不需要修改 | |
7 | 延期 | 延期 | 不在當前版本修復的錯誤,下一版本修復 | |
8 | 無法解決 | 無法解決 | 以目前的技術水平、經濟因素或修改此缺陷的代價過大等原因而不能解決的缺陷 | |
9 | Tester Agree | 測試同意 | 測試人員同意開發對缺陷做出的處理(這種處理可能是一種折衷的方法) | |
10 | Duplicate | 重復 | 由于測試重疊工作或者不同測試人員重復提交等原因,出現相同描述的缺陷重復報告. | |
4、分配給
記錄該缺陷分配給誰去修改。一般來說，登記時都是統一分配給項目經理，再由項目經理確認并分配給相關開發人員。
5、缺陷嚴重程度和優先級
缺陷嚴重級程度與優先級別原則上是有一一對應的關系，在填寫缺陷選擇這兩項時，可先參照該對照表：
缺陷嚴重程度中文名稱 | 缺陷嚴重程度描述 | 對應的缺陷優先級選項 | 缺陷優先級描述 |
5-緊急 | 阻礙流程、系統崩潰導致重大任務不能正常進行的缺陷,例如: 1. 由于程序所引起的死機,非法退出 2. 死循環 3. 數據庫發生死鎖 4. 錯誤操作導致的程序中斷 5. 嚴重的計算錯誤 6. 與數據庫連接錯誤 7. 數據通訊錯誤等 | 5-緊急 | 1 當缺陷所引發的問題沒有達到緊急的級別，但當該缺陷出現后，影響到了后續的測試工作進行 2 客戶無法容忍的頁面，如頁面上顯示其他公司名稱 3 當前操作方式與客戶使用習慣背道而馳。 4 嚴重不合理，核心功能完全違反軟件規范或業務規范，可能導致用戶強烈的反感 5系統響應時間過長(例如WEB響應時間超過10s) 6模塊提供的數據不合理，例如(查詢“錄入人”的下拉項提示為非用戶名字段) 7負載測試、壓力測試結果和用戶需求不符 |
4-非常高 | 缺陷導致失去系統主要功能,基本功能不能完整使用例如: 1. 功能不符 2. 程序接口錯誤 3. 數據流錯誤 4. 輕微數據計算錯誤等 | 4-非常高 | 1 快捷方式不正確，如能夠回車直接進入下一步的設計成了空格直接進入下一步 2 嚴重的邏輯錯誤 3常用操作平臺不能正常使用功能(WIN XP/WIN 2000/WIN VISTA) 4常用瀏覽器不能正常使用（IE6.0/IE7.0/FireFox） 5超時限制的時間設置不合理 6未登錄即可瀏覽頁面 7給客戶演示等過程中客戶重點指出的，嚴重級別卻不是很高的BUG,建議級別定義至少是非常高 |
3-高 | 操作性錯誤、錯誤結果、遺漏功能等影響系統要求或基本功能的實現,例如: 1. 界面錯誤（附詳細說明） 2. 打印內容、格式錯誤 3. 簡單的輸入限制未放在前臺進行控制 4. 刪除操作未給出提示 5. 數據輸入沒有邊界值限定或不合理 | 3-非常高 | 1 提示信息不明確，并且非常容易誤導用戶做出錯誤操作或判斷。 2 軟件功能的實現過程中彈出未控制的系統錯誤提示，導致流程中斷 3 Cookies沒有正常保存 4服務器和客戶端的腳本修改未被記錄和 5非法操作等Urgent程度的bug，如果不具有普遍性而是在極端環境下出現，例如特定的操作環境。建議級別定義為High。 |
2-中 | 錯別字、罕見故障等不影響執行工作或功能實現,例如: 1. 輔助說明描述不清楚 2. 系統處理未優化 3. 提示窗口文字未采用行業術語 | 2-中 | 1 提示信息不明確，不正確或不合理 2 界面設計存在缺陷、凌亂或不友好 3整體風格不統一 |
1-低 | 建議,不影響使用的瑕疵或更好的實現等 | 1-低 | 1 雖有不盡人意之處，但不影響用戶操作或用戶使用頻率較低，并且不會造成錯誤 2 局部界面不夠美觀 |
0-建議 | 對軟件各方面提出的更好的改進性的意見。 |
6、主題
記錄該缺陷屬于哪個模塊中。主題字段設置對應為用戶需求的各個模塊\子模塊下，方便將來統計各個模塊的缺陷密度。
7、檢測者
記錄該缺陷的登記者，系統會自動獲取當前用戶的帳號，不需要手工錄入。
8、檢測日期
記錄該缺陷的登記日期，通常系統會自動獲取當前時間，不需要手工錄入。
9、檢測于版本
記錄發現該缺陷軟件版本號，測試負責人員在每次獲取到新的測試程序包時，按照程序包上的版本標簽號，在QC的自定義管理中版本號一欄增加對應的版本號（注：程序包的版本號與QC中增加的版本號一致）。
10、缺陷類型
記錄缺陷的類型，暫時分為7類。
1）功能問題：軟件功能未實現或實現不完整、不正確等情況下的缺陷。
2）界面問題：用戶操作界面中存在的不合理、不正確、不美觀等方面的缺陷。
3）數據問題：錄入的數據錯誤。
4）易用性問題：用戶操作使用過程中存在的不符合使用習慣或操作復雜等方面的缺陷。
5）兼容性問題：系統在不同的測試環境中產生的缺陷。
6）性能問題：系統性能未達到性能需求所要求的各項指標。
7）安全性問題：系統存在安全方面的隱患一類的缺陷。
11、可重現
記錄缺陷是否可重現。根據缺陷描述操作，是否可以發現缺陷所描述的問題，Y表示可以重現，N表示無法重現。例如有些問題是在特定條件下才出現的，當條件改變后問題隨之消失，根據所描述的步驟操作，不會再出現缺陷所描述的問題，這類就是屬于無法重現的缺陷。
12、項目
記錄缺陷所屬的項目。
二、缺陷管理流程圖
字體: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿
三、開發人員修改缺陷填寫規范
1、不論是簡單還是復雜的缺陷，開發人員都要在修改了代碼并確保代碼提交到服務器后，再將缺陷狀態由“打開”置為“修復”。
2、對于非常簡單明了的缺陷（例如界面上的一個錯別字），可以在注釋中加簡單的注釋說明：（如：已修改）但對于復雜的缺陷，必須要注明以下幾點：
1）缺陷產生的原因
2）缺陷解決的方法：（該項描述主要是方便以后遇到同類問題的同事，可以查看當時的解決辦法，如果該缺陷的修改引發了其他的缺陷產生，則開發人員可以查看一下當 時的修改情況）
3）這個改動引起了哪些變動：（方便測試人員在進行回歸測試時，測試的深度和廣度的把握）
3、如果缺陷是由于測試人員理解錯誤導致，或者開發人員認為不需要修改的，開發人員可以將缺陷狀態設置為“否決”，但是必須在【注釋】欄中填寫拒絕修改的原因。
4、如果開發人員認為該缺陷與其他缺陷重復，也需要在【注釋】欄中填寫與之重復的缺陷ID，例如注釋內容可以填寫：與缺陷10重復。目的是讓開發人員再確認一下這兩個缺陷是否真的描述同一個問題。
小提示：在新增注釋說明時，可以直接點擊頁面右下方的（添加注釋）按鈕，QC可以直接添加你的登錄帳號在“注釋”中，省去自己填寫的麻煩！如圖12.請大家在填寫時養成加入自己信息的習慣，方便測試人員在回歸測試時可以看到是誰回復的，有問題方便直接溝通！
四、項目經理決定延期修改缺陷
1、項目經理決定延遲修改缺陷時，先在注釋中寫明延遲修改的原因，再將缺陷狀態置為“延期”。
2、項目經理需填寫如圖13中藍色框圈出的“計劃關閉的版本號”和“估計修復時間”兩項內容。（計劃關閉的版本號可以是正式版本，如Beta_v1.0，也可以是計劃在今后的一個候選版本中填寫，如Beta_v1.0.RC12）。由于目前版本管理還不完善，該項暫時可以不填寫。
