因為發現缺陷是測試目的之一，所以應該記錄測試過程中發現的缺陷。基於測試元件或系統的上下文、測試級別和軟體開發生命週期模型的不同，記錄缺陷的方式會有所不同。任何識別的缺陷都應該被調查，並跟蹤從發現和分類到解決問題的過程（例如：修復缺陷和成功驗證解決方案，推遲到後續的發布，接受為永久性產品限制等）。為了解決所有缺陷，組織應建立缺陷管理過程，其中包括工作流和分類規則。這個過程必須與參與缺陷管理的所有人達成一致，包括設計人員、開發人員、測試人員和產品所有者。在一些組織中，缺陷記錄和跟蹤可能是非常不正式的。
在缺陷管理過程中，有些報告可能被描述了假陽性（誤報缺陷），而不是由於缺陷造成的實際失效。例如：當網路連線中斷或超時時，測試可能失敗。這種行為不是由測試物件中的缺陷造成的，而是需要研究的異常。測試人員應儘量減少被報告為假陽性缺陷的數量。
在編碼、靜態分析、評審、動態測試或使用軟體產品時，都可以報告缺陷。**或工作系統，或任何型別的文件，包括需求、使用者故事和驗收準則、開發文件、測試文件、使用者手冊或安裝指南，都可以報告缺陷。為了構建有效和高效的缺陷管理過程，組織可以定義缺陷的屬性、分類和工作流的標準。
典型的缺陷報告有以下目標：
• 向開發人員和其他當事方提供關於所發生的任何不利事件的資訊，使他們能夠識別具體影響，用最小的重現測試步驟將問題分離出來，並糾正潛在的缺陷，根據需要或以其他方式解決問題
• 向測試管理人員提供一種手段，以跟蹤工作產品的質量及其對測試的影響（例如：如果報告了大量缺陷，測試人員將花費大量時間報告這些缺陷，而不是進行測試，同時需要更多的確認測試）
• 為改進開發和測試過程提供思路
在動態測試期間提交的缺陷報告通常包括：
• 識別符號
• 標題和所報告缺陷的簡短摘要
• 缺陷報告日期、發現的組織和作者
• 測試項(被測試的配置項)和環境的標識
• 發現缺陷的開發生命週期階段
• 缺陷描述以便能夠復現和修復，包括日誌、資料庫轉儲截圖或錄音(如果在測試執行期間發現)
• 預期和實際結果
• 缺陷對利益相關者的的影響範圍或程度(嚴重程度)
• 修復的緊急程度/優先順序
• 缺陷報告的狀態(例如：開啟、推遲、重複、等待修復、等待確認測試、重新開啟、關閉)
• 結論、建議和核准
• 全域性性問題，例如可能受到缺陷所引起的變更影響的其他領域
• 變更歷史，如專案小組成員採取的行動順序，從缺陷隔離、修復和到確認缺陷已修復
• 參考資料，包括發現問題的測試用例
在使用缺陷管理工具時，上述細節中的一些內容可以自動包含和/或得到管理，例如工作過程中自動分配識別符號、分配和更新缺陷報告狀態等。靜態測試中發現的缺陷，特別是評審，通常會以不同的方式記錄，例如在評審會議記錄中。
缺陷報告內容的示例可在iso標準（iso/iec/ieee 29119-3）中找到（該標準將缺陷報告稱為事件報告）。
缺陷跟蹤管理
缺陷跟蹤管理是測試工作的乙個重要部分，測試的目的是為了盡早發現軟體系統中的缺陷，因此，對缺陷進行跟蹤管理，確保每個被發現的缺陷都能夠及時得到處理是測試工作的一項重要內容。1 缺陷跟蹤管理的目標 缺陷能夠引起軟體執行時產生的一種不希望或不可接受的外部行為結果，軟體測試過程簡單說就是圍繞缺陷進行的，對缺...
五 缺陷管理
錯誤 靜態存在於文件說明中的表述或編寫錯誤。bug 存在 或硬體系統中的錯誤。debug就是尋找錯誤 缺陷 被測物件實際表現與使用者的顯性需求或隱性需求之間的差異，包含了錯誤和bug 1 功能實現的錯誤 2 功能實現的遺漏 3 功能實現的多餘 4 功能實現不好 失效 因缺陷激發或者導致的功能的異常，...
敏捷初識 缺陷管理
這段時間一直在師傅的指導下不斷嘗試，有些問題自己有了一定的心得，但有些問題還需進一步思考才能解決 而且我們部門的結構體系也在不斷優化調整中，敏捷管理需要不斷適應變化的新形勢，需要作出更多的努力和嘗試。一 所做事項 對接客服，跟進線上bug解決 意義 看起來好像是無關緊要的雜活 我一開始就是這麼想的 ...