# 軟件測試中的缺陷管理流程（錯誤報告模板） > 原文： [https://www.guru99.com/defect-management-process.html](https://www.guru99.com/defect-management-process.html) ### 什么是 Bug？ 錯誤是編碼錯誤的結果/結果 ## 什么是缺陷？ 缺陷是與原始業務需求的變化或偏差 這兩個術語之間的差異非常小。在行業中，這兩個都是需要修復的故障，因此某些[測試](/software-testing.html)小組會互換使用。 當測試人員執行測試用例時，他可能會遇到與預期結果相矛盾的測試結果。 測試結果的這種變化稱為**軟件缺陷**。 這些缺陷或變化以不同的名稱在不同的組織中引用，例如**問題，問題，錯誤或事件**。 在本教程中，您將學習- * [錯誤報告](#2) * [缺陷管理流程](#3) * [發現](#4) * [分類](#5) * [分辨率](#6) * [驗證](#7) * [關閉](#8) * [報表](#9) * [重要缺陷指標](#10) ## 錯誤報告 向開發人員報告錯誤時，您的錯誤報告應包含以下信息 * **Defect_ID** -缺陷的唯一標識號。 * **缺陷描述**-缺陷的詳細描述，包括有關在其中找到缺陷的模塊的信息。 * **版本**-在其中發現缺陷的應用程序版本。 * **步驟**-詳細的步驟以及屏幕截圖，開發人員可以使用這些截圖重現缺陷。 * **提起日期**-提起缺陷的日期 * **參考**-在其中提供對諸如此類文檔的參考。 需求，設計，架構甚至是錯誤的屏幕截圖，以幫助理解缺陷 * 檢測到的**-提出缺陷的測試人員的姓名/ ID** * **狀態**-缺陷的狀態，稍后會詳細介紹 * 修復的**-修復它的開發人員的名稱/ ID** * **關閉日期**-缺陷關閉的日期 * **嚴重性**，它描述缺陷對應用程序的影響 * **優先級**與缺陷修復的緊迫性有關。 嚴重性優先級可以是高/中/低，具體取決于應分別修復缺陷的緊急程度 資源資源 [下載示例缺陷報告模板](https://drive.google.com/uc?export=download&id=0B_vqvT0ovzHcZllqY2Q0TVpwaDQ) ## 考慮以下作為測試經理 您的團隊在測試 Guru99 Banking 項目時發現了錯誤。  一周后，開發人員回應-  下星期測試員回應  與上述情況一樣，如果以口頭形式進行缺陷溝通，很快情況就會變得非常復雜。 要控制和有效管理錯誤，您需要一個缺陷生命周期。 ## 什么是缺陷管理流程？ 缺陷管理是識別和修復錯誤的系統過程。 缺陷管理周期包括以下階段 1）發現缺陷，2）缺陷分類 3）開發人員修復缺陷 4）測試人員進行驗證，5）缺陷關閉 6）項目結束時的缺陷報告 本主題將指導您如何將缺陷管理過程應用于項目 Guru99 Bank 網站。 您可以按照以下步驟管理缺陷。  ## 發現 在發現階段，項目團隊必須在最終客戶發現之前盡可能多地發現**，**作為**缺陷。 當開發人員確認并接受缺陷后，就可以發現缺陷并將其更改為**接受狀態**** 在上述情況下，測試人員在 Guru99 網站中發現了 84 個缺陷。  讓我們看一下以下情況； 您的測試團隊在 Guru99 Bank 網站上發現了一些問題。 他們將其視為缺陷并報告給開發團隊，但存在沖突-  **In such case, as a Test Manager, what will you do?** <input class="eb" name="eb" type="checkbox" value="11"> A) Agree With the test team that its a defect <input class="ebno2" name="ebno2" type="checkbox" value="1"> B) Test Manager takes the role of judge to decide whether the problem is defect or not <input class="ebno" name="ebno" type="checkbox" value="111"> C) Agree with the development team that is not a defect **Correct****InCorrect** 在這種情況下，應采用解決方案來解決沖突，您將充當法官的角色來決定網站問題是否是缺陷。 ## 分類 缺陷分類可幫助軟件開發人員確定其任務的優先級。 這意味著這種優先級可以幫助開發人員首先修復那些至關重要的缺陷。  缺陷通常由測試經理進行分類– 讓我們做一個小練習，如下所示**拖動&將缺陷優先級降低到**以下 * [嚴重](#) * [高](#) * [中](#) * [低](#) | 1）網站性能太慢 | | | 2）網站的登錄功能無法正常使用 | | | 3）網站的 GUI 在[移動](/mobile-testing.html)設備上無法正確顯示 | | | 4）網站不記得用戶登錄會話 | | | 5）某些鏈接無效 | | <input id="text1" name="text1" type="text">[](#) 這是推薦的答案 | **否** | **說明** | **優先級** | **解釋** | | 1 | 網站性能太慢 | 高 | 性能錯誤會給用戶帶來極大的不便。 | | 2 | 網站的登錄功能無法正常使用 | 危急 | 如果此功能不起作用，則登錄是銀行網站的主要功能之一，這是嚴重的錯誤 | | 3 | 網站的 GUI 在移動設備上無法正確顯示 | 中 | 該缺陷會影響使用智能手機查看網站的用戶。 | | 4 | 該網站不記得用戶登錄會話 | High | 這是一個嚴重的問題，因為用戶將能夠登錄但無法執行任何進一步的交易 | | 5 | 某些鏈接無效 | 低 | 對于開發人員來說，這是一個簡單的解決方法，用戶無需這些鏈接仍然可以訪問該網站 | ## 分辨率 缺陷被接受并分類后，您可以按照以下步驟修復缺陷。  * **分配**：分配給開發人員或其他技術人員進行修復，并將狀態更改為**響應**。 * **日程安排**：在此階段，顯影方負責。 他們將根據缺陷優先級創建修復這些缺陷的計劃。 * **修復缺陷**：在開發團隊修復缺陷的同時，測試經理將跟蹤修復缺陷的過程與上述時間表進行比較。 * **報告解決方案**：修復缺陷后，開發人員將提供解決方案報告。 ## 驗證 在開發團隊**修復**和**報告**缺陷之后，測試團隊**驗證**該缺陷已得到實際解決。 例如，在上述情況下，當開發團隊報告他們已經修復了 61 個缺陷時，您的團隊將再次進行測試以驗證這些缺陷是否已得到實際修復。 ## 關閉 解決并驗證缺陷后，將更改狀態為**關閉**。 如果沒有，您已經向開發人員發送了通知，以再次檢查缺陷。 ## 報表 管理委員會有權知道缺陷狀態。 他們必須了解缺陷管理過程以在此項目中為您提供支持。 因此，必須向他們報告當前的缺陷情況，以獲得他們的反饋。 ## 重要缺陷指標 返回上述情況。 開發人員和測試團隊已審查了報告的缺陷。 這是討論的結果  **如何衡量和評估測試執行的質量？** 每個測試經理都想知道這個問題。 您可以考慮以下 2 個參數  在上述情況下，您可以計算**缺陷拒絕率**（DRR）為 **20/84 = 0.238（23.8％）。** 再舉一個例子，假設 Guru99 銀行網站總共有 **64** 個缺陷，但是您的測試團隊僅檢測到 **44** 缺陷，即他們錯過了 **20** 缺陷。 因此，可以計算出缺陷泄漏率（DLR）為 20/64 = **0.312** （31.2％）。 結論，通過以下兩個參數評估測試執行的質量  DRR 和 DLR 的值越小，測試執行的質量越好。 **可接受的**比率范圍是多少？ 該范圍可以在項目目標中定義和接受，也可以參考類似項目的指標。 在本項目中，可接受比例的推薦值為 **5?10％。** 表示測試執行的質量低。 您應該找到降低這些比例的對策，例如 * **提高**成員的測試技能。 * **花更多時間**進行測試執行，尤其是檢查測試執行結果。