軟體測試：軟體缺陷管理

軟體測試： 軟體缺陷管理

軟體缺陷 - 概念

• 軟體缺陷 - 基本概念主要分為：缺陷、故障、失效 • 缺陷（ Defect ）：以靜態形式存在於軟體內部，相當於 BUG ； • 故障（ Fault ）：軟體執行中出現的狀態，不處理可能會失效，以動態形式存在； • 失效（ Failure ）：軟體執行時產生的外部異常行為結果，與使用者需求不一致。

缺陷不一定導致故障，故障也不一定會失效； 缺陷導致故障，有可能導致失效，也有可能不會導致失效

 

軟體缺陷 - 定義

   軟體缺陷 的定義

• 軟體未達到產品說明書中已標明的功能 • 軟體未達到產品說明書中雖未指出但應達到的目標 • 軟體出現產品說明書中指明不會出現的錯誤 • 軟體功能超出了產品說明書中指明的範圍 • 軟體測試人員認為軟體中難以理解、不易使用、執行速度緩慢，或者終端使用者認為不好 缺陷的幾種型別： • 設計不合理 ;   • 功能、特性沒有實現或部分實現 ;   • 執行出錯，包括執行中斷、系統崩潰、介面混亂等 ;   • 與需求不一致，在執行 TestCase 時則為實際結果和預期結果不一致 ; • 使用者不能接受的其他問題，如存取時間過長、介面不美觀 ;   • 軟體實現了需求未提到的功能。

 

軟體缺陷 - 產生的原因

• 人員溝通不到位，交流上有誤解或根本不交流 • 文件不完善 • 需求不斷的變化 • 參與人員過度自信 • 程式設計有誤 • 軟體複雜性 • 工期短、任務重、時間壓力大 • 軟體開發工具與軟硬體  

識別軟體缺陷

• 透過測試用例中的預期結果進行識別 • 透過需求規格說明書進行識別

• 透過使用者手冊及其他文件進行識別 • 透過同行業相類似成熟的商業軟體識別

• 透過與開發人員的溝通進行識別 • 透過與有經驗測試人員溝通進行識別

• 透過參照同行業隱式需求進行識別

 

軟體缺陷 - 組織架構

• 缺陷的標題（一句話簡單描述問題） • 缺陷的基本資訊 • 測試的軟體和硬體環境 • 測試的軟體版本 • 缺陷的型別 • 缺陷的嚴重程度 • 缺陷的處理優先順序 • 缺陷的操作步驟（測試步驟、預期結果、實測結果） • 備註 / 註釋文字和截圖  

軟體缺陷 - 相關屬性

• 缺陷相關屬性：提交人、提交日期、 BUG 狀態、嚴重程度、缺陷優先順序、缺陷版本、修復日期。

1 . 缺陷發現人：最直接的是測試人員，測試人員發現的 BUG 數是進行個人績效考核的依據。 2. 缺陷發現時間：發現 BUG 並提交的時間。 3. 缺陷優先順序：立即解決 P1 、高優先順序 P2 、正常排隊 P3 、低優先順序 P4 。立即解決是指缺陷導致系統幾乎不能使用或測試不能繼續，需立即修復；高優先順序是指缺陷嚴重影響測試，需優先考慮；正常排隊是指缺陷正常排隊等待修復；而低優先順序是指缺陷可最後修改。 4. 缺陷版本：執行測試並發現 BUG 的版本號。 5. 缺陷修復日期：開發人員修復 BUG 的日期。  

• 缺陷狀態

1 . 新建 New 缺陷的初始狀態

2 . 開啟 Open 測試人員提交 BUG

3 . 指派 Assigned 指派給相關開發人員進行修復

4 . 已修復 Fixed 開發人員已修復

5 . 已關閉 Closed 測試透過，關閉

6 . 重新開啟 Reopen 迴歸測試未透過，或關閉後又復現了

7 . 延期 Postpone 推遲修改

8 . 拒絕 Rejected 開發人員拒絕修改

9 . 重複 Duplicate 重複提交

10 . 已取消 / 終止 Abandon 被拒絕和重複提交的 BUG ，在確認不是問題後，置為此狀態

 

 

 

• 缺陷嚴重程度：致命、嚴重、一般、較小、改進建議；或 A 、 B 、 C 、 D 、 E  

1 . 致命：軟體當機、退出或崩潰、資料丟失，主要功能完全喪失，導致本模組以及相關模組異常等問題。如程式碼錯誤，死迴圈，資料庫發生死鎖、與資料庫連線錯誤或資料通訊錯誤，未考慮異常操作，功能錯誤等。 2. 嚴重：主要功能部分喪失、資料不能儲存，系統的次要功能完全喪失。如致命的錯誤宣告，程式介面錯誤，資料庫的表、業務規則、預設值未加完整性等約束條件。 3. 一般：次要功能沒有完全實現但不影響使用。如提示資訊不太準確，或使用者介面差，操作時間長，模組功能部分失效等，列印內容、格式錯誤，刪除操作未給出提示，資料庫表中有過多的空欄位等。 4. 較小的：使操作者不方便或遇到麻煩，但它不影響功能過的操作和執行，如錯別字、介面不規範，輔助說明描述不清楚。 5. 改進建議：由測試人員對軟體的改進意見、建議或質疑。  

軟體缺陷 - 填寫要求

1. 缺陷標識：必填，缺陷的標識編號。 2. 指派人：必填，新提交的問題分配給相應的開發人員。 3. 提交人：必填，問題提交者，預設為自己。 4. 測試版本：必填，問題最開始發現的軟體版本號，對應開發的版本號。 5. 測試日期：必填，問題最開始提交的時間，預設為當天。 6. 嚴重程度：必填，問題本身的嚴重級別，越高表示越嚴重 7. 缺陷發生機率：必填，出現機率為必現、機率性出現（出現幾次）、不可復現。 8. 優先順序：必填，缺陷要求解決的優先順序，越高表示開發儘快修復問題。 9. 缺陷狀態：必填，缺陷的狀態，新提交時預設為 “ 新建 ”。 10. 缺陷起源：在需求、架構、設計、編碼、測試、使用者哪階段發現的。 11. 缺陷來源：來源於需求規格說明書、設計文件、整合介面、程式碼。 12. 缺陷模組：必填，哪個功能模組的 BUG 。 13. 問題描述：必填，詳細描述問題，描述中必須包括預期結果和實際結果，儘量 附圖，如有建議，寫出修改建議。 14. 問題處理意見：專案人員對缺陷給出處理的建議，均可讀寫。

 

軟體缺陷 - 描述原則

缺陷描述原則：分類準確、敘述簡潔、步驟清楚、易再現、複雜問題有據可查（截圖或其它形式的附件）。具體為：

• 問題描述格式：問題描述時，建議分幾步描述：模組或功能點 => 測試步驟 => 期望結果 => 實 • 際結果 => 其它資訊，可依實際情況調整；   • 敘述簡潔：單一準確，一個缺陷一個報告；每步驟的描述儘量簡潔明瞭。 • 短小簡練：只解釋事實、演示和描述軟體缺陷必要的細節，不寫無關資訊； • 再現：可以再現（個別嚴重問題復現不了也可入庫，但需標明）； • 特定條件：缺陷是否在特定條件下才會出現； • 補充完善：複雜的問題應附上截圖、 LOG 等資訊作為補充說明；  

• 不使用抽象詞句：比如 “ 有錯誤 ”“ 是不是 ”“ 請確認 ” 等等；   • 不做評價：請勿在 BUG 描述中， 評價 BUG 缺陷加入個人主觀思想。

 

軟體缺陷 - 生命週期

簡單週期：發現、開啟、修復、關閉

• 測試員找到並登記軟體缺陷，軟體缺陷移交到程式設計師

• 程式設計師修復軟體缺陷，軟體缺陷移交到測試員     • 測試員確定軟體缺陷被修復，測試員關閉軟體缺陷。

複雜週期：

• 發現缺陷（測試員發現並登記缺陷，軟體缺陷轉到程式設計師）     • 軟體缺陷移交到專案管理員     • （以不修復形式解決）專案管理員認為軟體缺陷不重要，軟體缺陷移交到測試員     • 重新啟用缺陷（測試員不同意，找出通用失敗案例，軟體缺陷移交到專案管理員）     • 專案管理員同意缺陷需要修復，缺陷轉給程式設計師     • 以修復形式解決（測試員確認軟體缺陷得以修復，測試員關閉軟體缺陷）     • 缺陷關閉  

測試 / 開發角色職責

• 測試執行人員：缺陷發現者。對版本進行測試發現 BUG ，並對已修復的 BUG 進行驗證。 • 測試組長：缺陷管理者。負責對缺陷的稽核，跟蹤和彙報，針對有爭議的 BUG 進行各方協調。 • 開發負責人：缺陷解決者。接收 BUG ，並指派給具體開發人員進行修復，給出解決途徑或修復建議。 • 開發人員：缺陷修復者。執行開發負責人指派的 BUG 修復並自測是否修復透過。  

 

軟體缺陷管理流程

BUG 跟蹤流程： 1. 測試人員拿到最新軟體版本，執行測試； 2. 發現 BUG 並記錄到 BUG 管理平臺；提交 BUG 報告或測試報告，郵件抄送開發人員； 3. 開發人員得到最新 BUG 並修復 BUG （如複雜問題，進行專家評審如何處理） 4. 修復 BUG 後把新程式碼 Check in 到原始碼伺服器； 5.Buider 人員會進行版本編譯並提交到釋出版本伺服器； 6. 測試人員開始執行新的一輪測試任務。  

缺陷跟蹤目的： 1. 保證 BUG 得到有效的跟蹤和解決， 使每一環節都有相對應責任人負責。 2. 進行缺陷分析和產品度量。

 

 

軟體缺陷分析

• 缺陷分析就是分析缺陷在與缺陷關聯關係的一個或多個引數值上的分佈。缺陷分析提供了一個軟體可靠性指標  

• 主要引數 • 狀態：缺陷的當前狀態（開啟的、正在修復或關閉的等）。 • 優先順序：必須處理和解決缺陷的相對重要性。 • 嚴重性：缺陷的相關影響。對終端使用者、組織或第三方的影響等等。 • 起源：導致缺陷的起源故障及其位置，或排除該缺陷需要修復的構件  

• 建立缺陷趨勢圖或報告；為揭示軟體可靠性的缺陷趨勢或缺陷分佈提供判斷依據。

 

缺陷報告

• 缺陷報告 - 概念：

     測試執行過程中，發現缺陷故障 / 失效後，提出書面的報告。

 

• 缺陷報告 - 作用：

1. 記錄軟體缺陷 2. 進行缺陷分類 3. 用於缺陷分析 4. 跟蹤軟體缺陷 5. 度量軟體質量  

• 缺陷報告的 5C 準則：

Correct （準確） Clear （清晰） Concise （簡潔） Complete （完整） Consistent （一致）

 

BUG 管理工具

管理 BUG 的工具： Excel 、 Bugzilla 、 TestDirector （ TD ）、 ClearQuest （ CQ ）、 Bugfree 、 JIRA 等  

• TestDirector 商業、支援 Win 平臺、 B/S 架構、在廣泛的應用環境下自動執行軟體質量測試和管理

• ClearQuest 商業、支援 Unix/Win 平臺、 C/S 、 B/S 架構、提供了從開發到部署的完整的審計跟蹤，並擴充套件了跨生命週期的可追溯性

• Bugzilla 免費、支援 Unix/Win 平臺、 B/S 架構、 Bug 追蹤系統設計用來幫助管理軟體開發

• Bugfree 免費、借鑑微軟的研發流程和 Bug 管理理念，使用 PHP+MySQL 獨立寫出的一個 Bug 管理系統。簡單實用、免費並且開放原始碼

• JIRA 商業、是集專案計劃、任務分配、需求管理、錯誤跟蹤於一體的商業軟體