資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
Microsoft Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
JavaScript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法學缺陷生命週期中的不同參與者
什麼是缺陷？
應用程式中的故障或錯誤，它透過使應用程式的預期行為與實際行為不匹配來限制應用程式的正常流程，這被稱為缺陷。
當開發人員在開發或構建應用程式時犯錯時，就會發生缺陷。當測試人員發現此錯誤時，它被稱為缺陷。
測試人員必須徹底測試應用程式以識別儘可能多的缺陷，以確保高質量的產品交付給使用者。在繼續進行缺陷的工作流程和不同階段之前，掌握缺陷生命週期至關重要。
讓我們更深入地瞭解缺陷生命週期。
到目前為止，我們已經討論了什麼是缺陷以及它與測試過程的關係。讓我們來看看缺陷生命週期，瞭解缺陷過程以及缺陷的各個階段。
缺陷狀態
**新建** - 在缺陷生命週期中，這是缺陷的第一個狀態。當發現新的缺陷時，它被標記為“新建”，並在缺陷生命週期的後期階段對其進行驗證和測試。
**已分配** - 在此階段，新生成的缺陷被分配給開發團隊，他們將對其進行處理。專案經理或測試團隊的經理將此分配給開發人員。
**開啟** - 在這裡，開發人員開始評估問題，並在必要時著手解決問題。如果開發人員認為該缺陷不合適，則可能出於各種原因將其轉移到下面列出的四個狀態之一，即重複、延期、拒絕或非缺陷。我們稍後會討論這四個狀態。
**已修復** - 當開發人員透過實施必要的修改完成解決缺陷的工作時，他可以將缺陷的狀態指定為“已修復”。
**等待重新測試** - 解決問題後，開發人員將缺陷提交給測試人員，測試人員將在其端進行重新測試。在測試人員進行缺陷重新測試之前，缺陷的狀態保持為“等待重新測試”。
**重新測試** - 在此階段，測試人員開始重新測試缺陷，以確定開發人員是否根據要求正確地糾正了該缺陷。
**重新開啟** - 如果缺陷仍然存在問題，它將被送回給開發人員進行測試，並且缺陷的狀態將更改為“重新開啟”。
**已驗證** - 如果測試人員在缺陷被分配給開發人員進行重新測試後沒有發現任何問題，並且認為缺陷已正確修復，則缺陷的狀態將更改為“已驗證”。
**已關閉** - 當缺陷不再存在時，測試人員將缺陷的狀態更改為“已關閉”。
實施缺陷生命週期的指南
在開始使用缺陷生命週期之前，工作的開發人員應遵循某些關鍵標準。
以下是一些標準：
在開始缺陷生命週期工作之前，整個團隊必須瞭解缺陷的各個階段（如上所述）。
為了減少未來的誤解，缺陷生命週期應被充分記錄。
為了獲得更好的結果，請確保每個被分配了與缺陷生命週期相關的任務的員工都充分了解其職責。
每個更改缺陷狀態的人都應該充分了解該狀態，並應提供有關該狀態及其設定該狀態的原因的足夠資料，以便處理該特定缺陷的所有人都瞭解它處於該狀態的原因。
開發人員應謹慎使用缺陷跟蹤工具，以保持缺陷之間的一致性，並因此保持缺陷生命週期的工作流程一致性。
無效和重複缺陷報告
當發生不是由程式碼而是由測試環境或誤解引起的缺陷時，應將報告關閉為無效缺陷。
在重複報告的情況下，保留一個報告，並將另一個報告關閉為重複報告。經理接受一些不正確的報告。
整個缺陷管理和流程由測試經理負責，缺陷管理工具跨職能團隊通常負責處理報告。
參與者包括測試經理、開發人員、專案經理、生產經理和其他相關利益相關者。
缺陷管理委員會應評估每個缺陷的有效性，並決定是否修復或推遲修復。考慮不糾正任何問題的成本、風險和好處以得出此結論。
如果必須修復該缺陷，則必須確定其優先順序。
缺陷資料
- 人員姓名
- 測試型別
- 問題概要
- 詳細的缺陷描述
- 再現生命週期階段的步驟
- 引入缺陷的工作產品
- 優先順序和嚴重性
- 引入缺陷的子系統或元件。
- 引入缺陷時發生的專案活動。
- 識別方法
- 缺陷型別
- 存在問題的專案和產品
- 當前所有者
- 發生缺陷的工作產品的當前狀態。
- 對專案的影響
- 糾正或不糾正問題的風險、損失、機會和優勢
- 缺陷生命週期各個階段發生的日期。
- 對如何解決問題以及測試建議的描述
參考文獻
流程能力
介紹、檢測和移除資訊 -> 提高缺陷檢測和質量成本。
介紹 -> 對引入最多缺陷的流程進行預研，以減少缺陷總數。
缺陷根本原因資訊 -> 定位並突出缺陷的原因，以減少缺陷總數。
缺陷元件資訊 -> 缺陷聚類分析
缺陷生命週期通常因組織而異，並受組織或專案遵循的軟體測試方法或通常使用的缺陷跟蹤技術規範和控制。缺陷生命週期的各種參與者使該過程有效。這些參與者列在下面。
缺陷報告者
顧名思義，缺陷報告者是報告缺陷的人，即發現缺陷的人。缺陷報告者的主要功能是驗證，即確認缺陷的有效性或正確性。驗證後，報告者將所有與缺陷跟蹤工具相關的資料和資訊新增到其中。這些詳細資訊和資訊可能包括缺陷優先順序、缺陷嚴重性、缺陷影響、測試環境、缺陷描述、模組、缺陷型別、修復所需資源、複製階段等。測試人員有時必須提供相關的螢幕截圖以驗證和解釋問題的全部細節。
缺陷跟蹤工具
顧名思義，缺陷跟蹤工具是用於檢測或跟蹤問題的工具。它通常有助於記錄、報告、分配、識別、發現和監控軟體開發專案中存在的缺陷。簡單來說，我們可以說缺陷跟蹤工具越好，產品就越好。缺陷通常記錄在缺陷跟蹤工具中，該工具通常有助於報告。這些工具可能是 Jira、Assembla 等。
缺陷組
顧名思義，缺陷組是一組有權檢視與缺陷相關的完整資訊的個人。缺陷組通常負責與缺陷相關的任何操作，從檢測到解決。這些組可能包括髮現並驗證缺陷的測試人員、監督測試人員和缺陷報告的測試主管、終端使用者報告的缺陷、測試主管分配給開發人員的缺陷、專案經理、質量保證經理、質量保證團隊等。簡單來說，缺陷組是一組可以監控所有缺陷操作的個人。
缺陷所有者
顧名思義，缺陷所有者是負責評估和擁有缺陷的人。他們通常負責驗證、確認和保證提供與缺陷相關的完整且充分的資訊。如果提供的資訊不完整且不令人滿意，則將缺陷分配回報告缺陷的缺陷報告者，以向其提供更多資訊。根據每個缺陷的優先順序，缺陷所有者隨後在截止日期內進一步解決和修復問題。
常見問題
- 發現缺陷時的狀態是什麼？
答案 − 當發現新的缺陷時，它處於新狀態。這是新發現缺陷的初始狀態。
- 當開發人員批准並修復問題時，缺陷生命週期中缺陷的各個階段是什麼？
答案 − 在此示例中，錯誤的不同狀態為：新建、已分配、開啟、已修復、等待重新測試、重新測試、已驗證和已關閉。
- 如果測試人員發現開發人員已解決的缺陷存在問題會發生什麼？
答案 − 測試人員可能會將缺陷的狀態標記為……如果測試人員仍然發現修復的缺陷存在問題，則測試人員應重新開啟它，並將缺陷分配給開發人員進行重新測試。
- 什麼是可重現缺陷？
答案 − 在每次執行中經常出現並且其步驟可以在每次執行中捕獲的缺陷被稱為“可重現”缺陷。
240 次瀏覽
