缺陷管理

 

缺陷管理

通常在測試執行階段產生

 

一、缺陷的基本概念

 

關於 BUG

• Bug的由來
• Debug（調試bug的過程）
• Bug和Defect
• Bug：電腦系統或者程序中存在的任何一種破壞正常運轉能力的問題或者缺陷，都可以叫做“Bug”；有時也被泛指因軟件產品內部的缺陷引起的軟件產品最終運行時和預期屬性的偏離。
• Defect（缺陷）：既指靜態存在於軟件工作產品（文檔、代碼）中的錯誤，也指軟件運行時由於這些錯誤被激發引起的和軟件產品預期屬性的偏離現象。

 

容易混淆的幾個概念

常見術語

• 失誤（Mistake）：導致軟件包含故障的人的行為；
• 缺陷（Defect）：軟件的異常情況；（在實際工作中bug和缺陷可能存為缺陷）
• 故障（Fault）：引起一個功能組件不能完成所要求的功能的一種意外情況；
• 失效（Failure）：功能組件執行其規定功能的能力喪失；

 

 

 

缺陷定義

 

 

 

缺陷（Defect），常常又叫做Bug。

計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷。

從產品內部看，缺陷是軟件產品開發或維護過程中存在的錯誤、毛病等各種問題；

從產品外部看，缺陷是系統所需要實現的某種功能的失效或違背。

 

缺陷示例--導彈誤炸事件

 

 

 

 

 

缺陷來源：

 

缺陷來源於軟件生命周期各個階段。

 

 

 

產生原因：

1.產品說明書不全，不完整和不准確，修改頻繁，溝通不暢和理解不同；

2. 軟件設計過程中考慮不周到，片面，多變，理解和溝通不足；

3. 文檔不足，壓時間，趕進度，設計和編碼錯誤都會引入缺陷；

4. 測試和實施過程中安裝環境配置錯誤等。

 

缺陷的評價標准：

• 軟件未實現需求規格說明書（SRS）要求的功能
• 軟件未實現需求規格說明書（SRS）雖未明確提及但應該實現的目標
• 軟件出現了需求規格說明書（SRS）指明不應出現的錯誤
• 軟件實現了需求規格說明書（SRS）未提到的功能
• 軟件難以理解、不易使用、運行緩慢，或者從測試工程師的角度來看——最終用戶會認為不好

 

二、缺陷的屬性

 

缺陷報告的相關屬性：

 

• 缺陷ID
• 標題
• 產生的步驟
• 所屬模塊
• 發現人
• 發現的時間
• 嚴重程度
• 優先級
• 類型
• 狀態
• 可再現性
• 發現階段
• 責任人
• 所屬版本
• 修改日期
• 引入原因
• 備注信息
• 相關附件

 

 

缺陷類型

 

• 遺漏（Missing）
• 錯誤（Error）
• 額外的實現（Extra）
• 改進（Enhancement）

 

 

優先級的划分

 

表示處理和修正軟件缺陷的先后順序的指標，即哪些缺陷需要優先修正，哪些缺陷可以稍后修正。

 

 

 

嚴重程度的划分

 

指因缺陷引起的故障對軟件產品的影響程度

 

 

 

 

 

缺陷跟蹤的交付物

 

 缺陷報告單（Bug Report）：也叫缺陷跟蹤單。測試執行過程中，發現軟件失效后，提出書面的報告，提供給開發人員或者其他負責人員作為定位缺陷的依據，也作為日后缺陷度量的數據依據。（只有提交了報告單才能被記錄，方便以后提交報告給上級）

 

缺陷管理工具中的BUG Report

 

 

 

 

 

三 缺陷的生命周期

 

• 缺陷的生命周期
• 缺陷的生命周期就是指缺陷從開始提出到最后完全解決，並通過驗證和確認的過程。在這個過程中缺陷報告的狀態不斷發生着變化，記錄着缺陷被處理的過程。
• 缺陷的生命周期通過缺陷流程圖得以展現

 

bug的流程

 

 

 

 

狀態說明：

 

• 新建（new）：測試人員提交新問題標識的狀態
• 打開（open）：已經確認為是BUG的狀態
• 已修復（fixed）：為開發人員修改問題后所標志的狀態，等待測試驗證。
• 重新打開（reopen）：測試人員對修改問題進行驗證后沒有通過所標志的狀態或者已經修改正確的問題又重新出現錯誤，由測試人員改變。
• 已關閉（closed）：為測試人員對修改問題進行驗證后通過所標志的狀態。由測試人員改變。
• 拒絕（rejected）：開發人員認為不是BUG、描述不清、重復、不能復現、不采納所提意見建議、或雖然是個錯誤但還沒到非改不可的地步故可忽略不計、或者測試人員提錯，從而拒絕的問題。由BUG分配人或者開發人員來設置。
• 重復（duplicated）：表示該BUG已經被其他測試人員找出來了，或者開發認為原因是相同的（但從測試來看，認為出現的地方有所不同、表現有所不同等）
• 延期（postponed）：由於時間、進度、重要程度或者技術/需求等方面的原因，認為不能解決、須延期解決、或者本版不做留待到后續版本解決的BUG。

 

 

缺陷溝通：

 

 

 

 

 

 

一個簡單的bug跟蹤流程

 

 

 

 

 

BMS:缺陷管理工具

 

 

缺陷報告的狀態：

 

 

 

 

 

缺陷狀態遷移矩陣

 

 

 

 

 

rejected、duplicate 開發人員同意就跳轉到reopen

不同意就跳轉到abandon

 

軟件測試缺陷管理流程

 

 

 

缺陷管理中的常見問題

 

• 提交的缺陷開發人員不認可怎么辦？(給出提交缺陷的依據，如果還是不行，向上級或有經驗的人員尋求幫助）
• 如何處理不能重現的缺陷？(出現缺陷必須立馬截圖記錄，以防之后無法找到)
• 如何處理好與開發人員及其他相關人員的關系？(多溝通）
• 缺陷太多怎么辦？（先打回讓開發自己解決）
• 找不到缺陷怎么辦？（分析代碼質量真的太高還是用例設計不夠全面）
• 缺陷得不到及時修復怎么辦？（及時告知上級，與開發協調解決）
• 如何處理缺陷級別定義之爭？（根據客觀實際情況和項目組划分的范圍定義）
• 如何處理缺陷跟蹤中的扯皮現象？

 

 

四 缺陷報告的書寫

 

缺陷報告單書寫准則

 

• Correct（准確）

   每個組成部分的描述准確，不會引起誤解

• Clear（清晰）

   每個組成部分的描述清晰，易於理解

• Concise（簡潔）

   只包含必不可少的信息，不包括任何多余的內容

• Complete（完整）

   包含復現該缺陷的完整步驟和其他本質信息

• Consistent（一致）

   按照一致的格式書寫全部缺陷報告

 

缺陷報告的寫作要點

 

• 再現：一般是盡量三次再現故障，如果問題是間斷的，那要報告問題發生頻率。
• 初步定位：可能影響再現的變量，例如配置變化、工作流、數據庫，這些都可能改

        變錯誤的特征。

• 推廣：確定系統其他部分是否可能出現這種錯誤，以及使用不同的數據時是否存在

       着這種問題等等，特別是那些可能存在更加嚴重特征的部分。

• 壓縮：精簡任何不必要的信息，特別是冗余的測試步驟。
• 去除歧義：使用清晰的語言，尤其是避免使用那些有多個不同或相反含義的詞匯。
• 中立：公正的表達自己的意思，對錯誤及其特征的事實進行陳述，避免誇張、幽默或諷刺。
• 評審：至少有一個同行，最好是一個有經驗的測試工程師或測試經理，在遞交錯誤報告之前自己先閱讀一遍。

 

 

缺陷報告單基本內容

 

 

 

  Bug的摘要是要用一句話的形式簡明扼要地將Bug描述出來，要清晰指出Bug所在部位以及其錯誤類型，不能太籠統。如“頁面對非法輸入有問題”可以修改為“流量信息查詢頁面對於非法輸入沒有進行校驗”

 

 

缺陷描述舉例

 

• 簡單描述

  • Arial、Wingdings和Symbol字體會破壞新文件。

• 詳細描述

  • 軟件測試環境為windows 2000 sp4

  • 啟動WordEdit編輯器，然后創建新文件。

  • 輸入四行文本，重復輸入”The quick fox jumps over the lazy brown dog”。

  • 選中所有四行文本，然后選擇字體下拉菜單，並選擇Arial。

  • 所有文本被轉換成控制字符、數字和其它明顯的隨機二進制數據。

  • 重復三次，結果都一樣。

• 相關附件

  • 附件1：變換格式之前的文檔

  • 附件2：變換格式之后的文檔

• 軟件缺陷初步分析：

  • 粗略估計是格式問題，保存文件，關閉WordEdit並重新打開文件，但是數據仍

  然被破壞

  • 在改變字體前保存文件防止錯誤。

  • 對現存文件，錯誤不再發生。

  • 只在WINDOWS 2000下發生，而不出現在Solaris、Mac和其他Windows系

  統。

 

 

含糊不完整的缺陷描述

 

 

• 簡要描述

  • WordEdit處理Arial字體有問題。

• 詳細描述

  • 1、打開WordEdit。

  • 2、輸入一些文本。

  • 3、選擇Arial。

  • 4、文本被破壞

• 軟件缺陷初步分析：

  • N/A

 

 

冗余混淆的缺陷報告

 

• 簡要描述

  • 我在Solaris、Windows 98和Mac上運行WordEdit，當使用某些字體時，好

  像會破壞一些數據。

 

• 詳細描述

  • 1、在Windows 98上打開WordEdit，然后編輯兩個現有文件。這些文件包含

  一些字體的混合。

  • 2、文件正常打印。

  • 3、創建並打印一張圖表，工作正常。但是有些內容不是很清楚。

  • 4、之后，創建了一個新文件。

  • 5、然后，輸入了一大堆隨機文本。

  • 6、在輸入了文本之后，選中一些行。然后，拉下字體菜單並選擇Arial。

  • 7、改變的文本被破壞了。

  • 8、重復三次，每次結果都一樣。

  • 9、我在Solaris上重復步驟1-6，沒有發現任何問題。

  • 10、我在Mac上重復步驟1-6，沒有發現任何問題。

• 缺陷原因分析：

  • 我嘗試選擇其他字體，但是只有Arial出現這個錯誤。但是，其他沒有測試的字

  體仍然有可能出錯。

 

 

五 常用管理工具

 

缺陷管理的目的

 

• 保證信息的一致性

• 保證缺陷得到有效的跟蹤，縮短溝通時間，解決問題更高效

• 利於缺陷分析、產品度量，使項目情況可視化加強

 

 

 

 

 

常用的缺陷管理工具

 

1. QC（QC（quality control）是TD的升級版，QC的升級就是ALM）

2. 禪道(bugfree升級版）

3. Mantis

4. JIRA

5. TestLink

6. Bugzilla

7. Redmine（開源，基於敏捷開發模型）

 

常用工具說明

 

1. QC 商業購買 --基於Web的測試管理工具，可以組織和管理應用程序測試流程的所有階段，包括指定測試需求、計划測試、執行測試和跟蹤缺陷。此外，通過Quality Center還可以創建報告和圖來監控測試流程。

2. 禪道 國產開源 -- 本地化做的比較好。禪道是為研發類項目/團隊量身定制的一款管理軟件，覆蓋產品開發的整個生命周期，頁面簡潔、流程清晰。

3. Mantis 開源 -- 是一個基於PHP技術的輕量級的開源缺陷跟蹤系統，以Web操作的形式提供項目管理及缺陷跟蹤服務。

4. TestLink 開源，可以與Mantis集成；是sourceforge的開放源代碼項目之一，作為基於web的測試管理系統。

5. JIRA 開源，可二次開發，是Atlassian公司出品的項目與事務跟蹤工具。

6. Bugzilla 是Mozilla公司提供的一款開源的免費Bug（錯誤或是缺陷）追蹤系統，用來幫助你管理軟件開發，建立完善的BUG跟蹤體系

7. Redmine 是一個開源的、基於web的項目管理和缺陷跟蹤工具。它用日歷和甘特圖輔助項目及進度可視化顯示，同時它支持多項目管理。Redmine是一個自由開放源碼軟件的解決方案，它提供集成的項目管理功能，問題跟蹤，並為多個版本控制的選項的支持。

 

六  缺陷分析

 

識別BUG

 

• BUG是由於軟件開發者的疏忽和失誤造成的。

• BUG是軟件生命周期內發現和未被發現的所有問題總和。

• 全面質量管理和全程軟件測試：

BUG不單指軟件測試階段發現的軟件系統的功能性錯誤，還應包括軟件開發過程中需求、設計、開發等階段評審過程發現的問題，以及軟件發布后客戶發現並反饋的問題，同時還包括那些隱藏在軟件內部未被發現的問題。（總結經驗教訓，改進軟件開發過程）