缺陷管理

 

缺陷管理

一般在測試執行階段產生

 

1、缺陷的基本概念

 

關於 BUG

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

 

容易混淆的幾個概念

常見術語

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

 

 

缺陷定義

 

 

 

缺陷（Defect），經常又叫作Bug。

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

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

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

 

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

 

 

 

 

缺陷來源：

 

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

 

 

產生緣由：

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

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

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

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

 

缺陷的評價標準：

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

 

2、缺陷的屬性

 

缺陷報告的相關屬性：

 

• 缺陷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字體有問題。

• 詳細描述

  • 一、打開WordEdit。

  • 二、輸入一些文本。

  • 三、選擇Arial。

  • 四、文本被破壞

• 軟件缺陷初步分析：

  • N/A

 

 

冗餘混淆的缺陷報告

 

• 簡要描述

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

  像會破壞一些數據。

 

• 詳細描述

  • 一、在Windows 98上打開WordEdit，而後編輯兩個現有文件。這些文件包含

  一些字體的混合。

  • 二、文件正常打印。

  • 三、建立並打印一張圖表，工做正常。可是有些內容不是很清楚。

  • 四、以後，建立了一個新文件。

  • 五、而後，輸入了一大堆隨機文本。

  • 六、在輸入了文本以後，選中一些行。而後，拉下字體菜單並選擇Arial。

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

  • 八、重複三次，每次結果都同樣。

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

  • 十、我在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不單指軟件測試階段發現的軟件系統的功能性錯誤，還應包括軟件開發過程當中需求、設計、開發等階段評審過程發現的問題，以及軟件發佈後客戶發現並反饋的問題，同時還包括那些隱藏在軟件內部未被發現的問題。（總結經驗教訓，改進軟件開發過程）