1.摘要
對缺陷的簡單描述。摘要包括該缺陷所屬的模組名稱-子模組名稱，以及簡單說明缺陷情況。
2.描述
詳細描述重現該缺陷的步驟，錯誤現象和期待結果。必要時可以上傳附件輔助說明。
3.狀態序號
缺陷狀態英文名稱
缺陷狀態中文名稱
缺陷狀態描述
備註new
新建測試中提出報告缺陷，普通開發人員無權修改狀態為「新建」的缺陷，只能修改狀態為「開啟」或者「重新開啟」的缺陷。「新建」的缺陷需要專案經理確認並將狀態置為「開啟」
open
開啟被確認並分配給相關人員處理
fixed
修復開發人員已完成修正,等待測試人員驗證
closed
關閉缺陷已被修復
reopen
重新開啟
缺陷未被修復
rejected
否決拒絕修改缺陷，該缺陷可能由於測試人員理解錯誤，或者專案經理認為不需要修改
延期延期
不在當前版本修復的錯誤,下一版本修復
無法解決
無法解決
以目前的技術水平、經濟因素或修改此缺陷的代價過大等原因而不能解決的缺陷
tester agree
測試同意
測試人員同意開發對缺陷做出的處理(這種處理可能是一種折衷的方法)
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重複。目的是讓開發人員再確認一下這兩個缺陷是否真的描述同乙個問題。
4.專案經理決定延期修改缺陷
1、專案經理決定延遲修改缺陷時，先在注釋中寫明延遲修改的原因，再將缺陷狀態置為「延期」。
2、專案經理需填寫如圖13中藍色框圈出的「計畫關閉的版本號」和「估計修復時間」兩項內容。（計畫關閉的版本號可以是正式版本，如beta_v1.0，也可以是計畫在今後的乙個候選版本中填寫，如beta_v1.0.rc12）。由於目前版本管理還不完善，該項暫時可以不填寫。
缺陷跟蹤管理
缺陷跟蹤管理是測試工作的乙個重要部分，測試的目的是為了盡早發現軟體系統中的缺陷，因此，對缺陷進行跟蹤管理，確保每個被發現的缺陷都能夠及時得到處理是測試工作的一項重要內容。1 缺陷跟蹤管理的目標 缺陷能夠引起軟體執行時產生的一種不希望或不可接受的外部行為結果，軟體測試過程簡單說就是圍繞缺陷進行的，對缺...
5 6缺陷管理
因為發現缺陷是測試目的之一，所以應該記錄測試過程中發現的缺陷。基於測試元件或系統的上下文 測試級別和軟體開發生命週期模型的不同，記錄缺陷的方式會有所不同。任何識別的缺陷都應該被調查，並跟蹤從發現和分類到解決問題的過程 例如 修復缺陷和成功驗證解決方案，推遲到後續的發布，接受為永久性產品限制等 為了解...
五 缺陷管理
錯誤 靜態存在於文件說明中的表述或編寫錯誤。bug 存在 或硬體系統中的錯誤。debug就是尋找錯誤 缺陷 被測物件實際表現與使用者的顯性需求或隱性需求之間的差異，包含了錯誤和bug 1 功能實現的錯誤 2 功能實現的遺漏 3 功能實現的多餘 4 功能實現不好 失效 因缺陷激發或者導致的功能的異常，...