軟體開發中的缺陷生命週期
在本課中,我們將學習缺陷的生命週期,幫助您瞭解測試人員在測試環境中必須處理的缺陷的各個階段。
在缺陷生命週期中,我們還包含了最常被問到的面試問題。理解缺陷的生命週期需要了解缺陷的各個階段。測試活動的主要目標是檢查產品是否存在任何缺陷或錯誤。
在現實情況下,錯誤/失誤/故障都稱為bug/缺陷,因此可以說,測試的基本目標是確保產品不太容易出現缺陷(沒有缺陷是不現實的情況)。
什麼是缺陷?
簡單來說,缺陷是應用程式中的錯誤或缺陷,它透過使預期行為與實際行為不匹配來阻止程式的正常流程。
當開發人員在應用程式的設計或開發過程中犯錯,並且該問題被測試人員發現時,則稱為缺陷。
測試人員的工作是徹底測試應用程式,以發現儘可能多的缺陷,以便高質量的產品能夠交付給消費者。在繼續討論缺陷的流程和各個階段之前,理解缺陷生命週期至關重要。
因此,讓我們進一步深入瞭解缺陷生命週期。
到目前為止,我們已經討論了什麼是缺陷以及它與測試過程的關係。現在讓我們來看一下缺陷的生命週期,並瞭解缺陷的過程以及缺陷的各個階段。
什麼是缺陷的生命週期?
在軟體測試中,生命週期指的是缺陷或bug在其整個生命週期中經歷的精確階段集合。缺陷生命週期的目標是透過方便地協調和溝通缺陷的當前狀態給多個被指派者,使缺陷修復過程更系統化和更高效。
缺陷的狀態
缺陷或bug的狀態是指缺陷或bug在缺陷生命週期中的當前狀態。缺陷狀態的目的是準確地表示缺陷或bug的當前狀態或進度,以便更好地跟蹤和理解缺陷生命週期。
從一個專案到另一個專案,缺陷所經歷的狀態數量各不相同。下面的生命週期圖描述了所有可能的狀態。
**新建 (New)** − 當一個新的缺陷最初被記錄和公佈時,它被稱為“新建”。它被賦予“新建”狀態。
**已分配 (Assigned)** − 測試人員提交缺陷後,測試主管接受並將其分配給程式設計團隊。
**開啟 (Open)** − 開發人員開始調查和修復缺陷。
**已修復 (Fixed)** − 開發人員在進行必要的程式碼修改並驗證後,可以將問題標記為“已修復”。
**等待複測 (Pending retest)** − 缺陷修復後,開發人員向測試人員提供特定的程式碼以進行重新測試。發出“等待複測”狀態是因為軟體測試仍在等待測試人員。
**複測 (Retest)** − 在此階段,測試人員重新測試程式碼以檢視開發人員是否已修復缺陷,並將狀態更改為“複測”。
**已驗證 (Verified)** − 開發人員修復缺陷後,測試人員重新測試該問題。如果在程式中沒有發現錯誤,則該問題已修復,狀態將更改為“已驗證”。
**重新開啟 (Reopen)** − 如果開發人員修復後問題仍然存在,測試人員會將狀態更新為“重新開啟”。該缺陷將再次經歷生命週期。
**關閉 (Closed)** − 當一個bug不再存在時,測試人員將其標記為“關閉”。
**重複 (Duplicate)** − 如果缺陷再次出現或缺陷與相同的bug想法相關,則狀態更改為“重複”。
**拒絕 (Rejected)** − 如果開發人員認為問題不真實,則缺陷標記為“拒絕”。
**延期 (Deferred)** − 如果當前問題不是優先順序最高的問題,並且預計將在將來的版本中解決,則將其賦予“延期”狀態。
**不是bug (Not a bug)** − 如果bug對應用程式的操作沒有影響,則bug的狀態設定為“不是bug”。
缺陷的生命週期
測試人員發現了缺陷。
缺陷已被賦予“新建”狀態。
缺陷被報告給專案經理,專案經理將對其進行調查。
專案經理確定缺陷是否有效。
由於缺陷無效,狀態設定為“拒絕”。
因此,專案經理將其標記為拒絕。如果問題未被拒絕,則下一步是確定它是否在專案的範圍內。假設我們有另一個功能,例如同一程式的電子郵件功能,並且您發現其中存在缺陷。但是,當此類缺陷被賦予推遲或延遲狀態時,它並不屬於當前版本。
然後,經理檢查是否之前提到過類似的問題。如果答案是肯定的,則該缺陷被標記為重複。
如果答案是否定的,則該問題將分配給開發人員,開發人員開始處理程式碼。此時,缺陷被賦予進行中狀態。
程式碼修復後。缺陷的狀態尚未修復。
然後,測試人員將重新測試程式碼。如果測試用例成功,則缺陷被關閉。如果測試用例再次失敗,則問題將重新開啟並分配給開發人員。
考慮這樣一種情況:在航班預訂的第一個版本中發現傳真訂單中的一個缺陷,該缺陷已修復並被賦予關閉狀態。相同的bug在第二次升級版本中再次出現。在這種情況下,一個已關閉的缺陷將被重新開啟。
實施缺陷生命週期:指導原則
在開始使用缺陷生命週期之前,應該遵循一些基本原則。
詳情如下:
在開始處理缺陷生命週期之前,整個團隊瞭解缺陷的各個階段(如上所述)至關重要。
為了減少未來的誤解,應該仔細記錄缺陷生命週期。
為了獲得更好的結果,請確保每個被分配了與缺陷生命週期相關的任務的人都完全理解他們的責任。
每個更改缺陷狀態的人都應該完全瞭解該狀態,並提供關於該狀態和設定該狀態的理由的充分資料,以便所有處理該缺陷的人都能夠輕鬆理解造成這種缺陷狀態的原因。
為了在缺陷之間保持一致性,從而在缺陷生命週期過程中保持一致性,應謹慎使用缺陷跟蹤工具。
錯誤、缺陷和故障的主要區別是什麼?
錯誤 − 當開發人員在開發過程中發現應用程式的實際行為和預期行為之間的差異時,他們將其標記為錯誤。
缺陷 − 當測試人員在測試過程中發現應用程式的實際行為和預期行為之間的差異時,則發生缺陷。
故障 − 當客戶或終端使用者在生產階段發現程式的實際行為和預期行為之間的差異時,則發生故障。
無效或重複的缺陷報告
當缺陷是由程式碼以外的因素(例如測試環境或誤解)引起的時,應將報告關閉為無效缺陷。
保留一份重複報告,另一份則標記為重複並關閉。管理人員會接受某些錯誤報告。
整體缺陷管理流程由測試經理負責,缺陷管理工具跨職能團隊負責處理報告。
與會人員包括測試經理、開發人員、專案經理、生產經理和其他相關人員。
缺陷管理委員會應評估每個缺陷的有效性,並決定是否應修復或推遲修復。做出此決定時,應考慮不修復任何問題的成本、風險和益處。
如果必須糾正缺陷,則必須確定其優先順序。
缺陷或錯誤的補充詳細資訊
在軟體開發生命週期的任何階段都可能引入缺陷。
越早發現和糾正缺陷,總質量成本就越低。
在引入缺陷的同一階段消除問題,可以降低質量成本。
靜態測試識別缺陷而不是故障。由於不需要除錯,因此成本保持在最低限度。
當缺陷在動態測試中產生故障時,問題的存在就會暴露出來。
編寫高質量的缺陷報告:一些技巧!
能夠編寫高質量的缺陷報告是測試人員工具箱中最關鍵的技能之一。發現缺陷只是成功的一半;如果開發人員無法重現您發現的問題,他們將很難糾正這些問題。為了確保測試人員能夠全面報告他們發現的缺陷,您的缺陷跟蹤軟體應包含一些必要的欄位。此外,測試人員應提高其描述能力。
資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP