資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理
化學
生物
數學
英語
經濟學
心理學
社會學
服裝設計
法律研究軟體測試中的缺陷管理流程
錯誤是程式碼錯誤的結果/後果。
軟體測試缺陷
軟體缺陷是指軟體程式與終端使用者或原始業務需求之間的差異或偏差。軟體缺陷是指導致軟體程式輸出不準確或意外，無法滿足其預期目的的編碼錯誤。在執行測試用例期間，測試人員可能會偶然發現此類缺陷。
這兩個名稱在行業中有著非常細微的區別；兩者都是必須糾正的缺陷，一些測試團隊可以互換使用它們。
當測試人員執行測試用例時，他們可能會遇到與他們預期不符的測試結果。軟體缺陷被定義為測試結果的差異。在不同的企業中，這些缺陷或偏差被稱為問題、故障、錯誤或事件。
本指南將教你如何
報告錯誤
缺陷管理流程
發現
分類
解決
驗證
關閉
報告
重要的缺陷指標
軟體測試錯誤報告
在軟體測試中，錯誤報告是詳細描述在軟體程式中發現的缺陷的文件。錯誤報告包含有關錯誤的所有資訊，例如描述、發現問題日期、發現問題的測試人員身份、糾正問題的開發人員姓名等等。錯誤報告有助於將來檢測類似的問題，從而避免它們。
向開發人員報告錯誤時，您的問題報告應包含以下詳細資訊。
缺陷 ID - 缺陷的唯一標識號。
缺陷描述 - 缺陷的詳細描述，包括髮現它的模組的詳細資訊。
版本 - 發現缺陷的程式版本。
步驟 - 開發人員可以用來複制缺陷的帶有螢幕截圖的詳細步驟集。
缺陷提出日期 - 缺陷提出日期
提供對文件（如規範、設計、架構，甚至錯誤的影像）的參考，以幫助理解錯誤。
發現者 - 報告缺陷的測試人員的姓名或 ID。
狀態 - 缺陷的當前狀態；稍後將詳細介紹。
進行修復的開發人員的姓名/ID
關閉日期 - 缺陷解決的日期。
缺陷的嚴重程度定義了它對應用程式的影響。
優先順序與缺陷糾正的緊迫性相關。根據問題應糾正的緊迫性，嚴重性優先順序可以是高、中或低。
作為測試經理，請考慮以下幾點
在測試電子商務專案時，您的團隊發現了問題。當測試人員發現 85 個問題時，通知了專案經理。之後，專案經理將專案移交給了開發團隊。
開發人員在一週後回覆，糾正了 65 個問題。然後，測試團隊檢查了專案，除了需要糾正的 65 個問題之外，又發現了 10 個問題。
如果缺陷溝通是口頭的，就像上面的例子一樣，事情很快就會變得非常困難。需要一個缺陷生命週期來成功控制和管理缺陷。
什麼是缺陷管理流程？
缺陷管理是一種識別和解決缺陷的方法。缺陷管理週期的步驟如下：1) 缺陷檢測，2) 缺陷分類 3) 開發人員修復缺陷 4) 測試人員驗證 5) 修復缺陷 6) 專案結束時的缺陷報告
本文將向您展示如何在電子商務網站專案中使用缺陷管理方法。要處理缺陷，請按照以下步驟操作。
發現
在發現階段，專案團隊必須盡最大努力找到儘可能多的缺陷，以防止最終客戶發現它們。當開發人員承認並接受缺陷時，則認為已檢測到該缺陷，並將其狀態更改為“已接受”。
在上述場景中，測試人員在網站中發現了 85 個缺陷 -
發現缺陷
識別缺陷
建立缺陷報告
接受缺陷
在這種情況下，應使用爭議解決方法，您應充當法官，以確定網站問題是否為缺陷。
分類
軟體工程師可以使用缺陷分類來確定工作優先順序。也就是說，具有高優先順序可以使工程師專注於首先糾正最關鍵的缺陷。
測試經理通常負責對缺陷進行分類 -
讓我們進行這樣的一個小練習。
為以下缺陷選擇優先順序
嚴重/高/中/低-
網站的響應時間非常長。
網站的登入機制無法正常工作。
網站的圖形使用者介面 (GUI) 在移動裝置上顯示不正確。
網站無法記住使用者的登入會話。
一些連結已損壞。
推薦答案
| 序號 | 描述 | 優先順序 | 解釋 |
|---|---|---|---|
| 1 | 網站的響應時間非常長。 | 高 | 效能缺陷可能會給使用者帶來很大的不便。 |
| 2 | 網站的登入機制無法正常工作。 | 嚴重 | 登入是銀行網站最重要的功能之一，如果它無法工作，則存在重大缺陷。 |
| 3 | 在移動裝置上，網站的使用者介面顯示不正確。 | 中 | 該缺陷影響使用智慧手機訪問網站的使用者。 |
| 4 | 網站無法記住使用者的登入會話。 | 高 | 這是一個嚴重的問題，因為使用者將能夠登入，但將無法進行任何進一步的交易。 |
| 5 | 一些連結已損壞。 | 低 | 這對開發人員來說是一個簡單的修復，使用者仍然可以在沒有這些連結的情況下瀏覽網站。 |
解決缺陷
在軟體測試中，缺陷解決是解決問題的逐步過程。缺陷解決過程從測試經理將缺陷分配給開發人員開始，然後開發人員根據優先順序安排解決缺陷的時間表。然後修復缺陷，開發人員向測試經理提供解決報告。此方法使糾正和跟蹤問題變得簡單。
分配給開發人員或其他技術人員以解決，並且狀態已更改為“響應”。
修復計劃：這是開發人員接管的地方。根據缺陷的優先順序，他們將設計一個時間表來解決這些問題。
修復缺陷：在開發團隊處理缺陷時，測試經理會跟蹤該過程並將其與上述時間表進行比較。
在解決錯誤後，從開發人員那裡獲取有關解決情況的報告。
驗證
一旦開發團隊修復並報告了錯誤，測試團隊會確保這些錯誤已得到修復。
例如，當開發團隊報告他們之前修復了 61 個問題時，您的團隊將再次進行測試以確保這些缺陷已解決。
關閉
修復並驗證缺陷後，其狀態將更改為“已關閉”。如果不是這種情況，您必須向開發人員提交通知以再次檢查缺陷。
缺陷報告
在軟體測試中，缺陷報告是指測試經理生成並向管理團隊傳送缺陷報告的過程，以獲取關於缺陷管理流程和問題狀態的反饋。然後，管理團隊審查問題報告並提供評論或根據需要提供進一步的幫助。缺陷報告有助於改進缺陷的溝通、跟蹤和解釋。
管理委員會有權瞭解缺陷的數量。為了幫助您完成此專案，他們必須瞭解缺陷管理流程。因此，您必須通知他們當前的缺陷情況以獲取反饋。
重要的缺陷指標
支援上面概述的情況。報告的缺陷已由開發和測試團隊審查。
如何衡量和評估測試執行的質量？
每個測試經理都想了解這個問題的答案。您應該考慮兩個引數 -
(拒絕的缺陷數量/提出的缺陷總數)* 100 = 缺陷拒絕率
(遺漏的缺陷數量/軟體的缺陷總數)*100 = 缺陷洩漏率
在上述案例中，您可以計算缺陷拒絕率 (DRR) 為 20/84 = 0.238。（23.8%）。
例如，假設 Guru99 銀行網站總共有 64 個缺陷，但您的測試團隊僅發現了 44 個，還有 20 個缺陷未被發現。因此，缺陷洩漏率 (DLR) 可以計算為 20/64 = 0.312（31.2%）。
最後，使用以下兩個引數來評估測試執行的質量
23.8% 缺陷拒絕率
31.2% 缺陷洩漏率
DRR 和 DLR 的值越低，測試執行質量越高。比率的可接受範圍是多少？此範圍可以根據專案的目標建立和批准，或者可以使用來自類似專案的測量值。
本專案中可接受的比率被認為在 5% 到 10% 之間。這表明測試執行質量較差。您應該制定一個降低這些比率的計劃，例如
提高成員的測試能力。
應投入更多精力進行測試執行，尤其要檢查測試執行結果。
5K+ 瀏覽量
