軟件測試之-軟件缺陷管理

一、軟件測試缺陷基本概念和相關術語

1）缺陷（Defect）：是指存在於軟件之中誤差，可被激活，以靜態形式存在於軟件內部，至關於Bug。
  2）故障（Fault）：當缺陷被激活後，軟件運行中出現的狀態，可引發意外狀況，若不加處理，可產生失效，是一個動態行爲。
  3）失效（Failure）：軟件運行時產生的外部異常行爲結果，表現與用戶需求不一致，功能能力終止，用戶沒法完成所須要的應用。
  4）Bug：電腦系統或者程序中存在的任何一種破壞正常運轉能力的問題或者缺陷，均可以稱之爲「Bug」；有時也泛指因軟件產品內部引發的軟件產品最終運行時和預期結果的偏離。
  5）缺陷報告單：指測試執行過程當中，發現缺陷失效後，提出書面的報告，提供給開發人員做爲定位缺陷的依據。

二、軟件缺陷管理基本流程

下圖是一個簡單的BUG跟蹤流程圖：

1）橢圓形中標示的都是角色（測試人員、BUILDER人員、開發人員、專家會診）
  2）柱狀圖1：發佈服務器，通常存放當前最新的軟件版本
     柱狀圖2：RAID/BMS，是Bug的管理系統，測試人員發現問題都要提交到這個系統上
     柱狀圖3：郵件服務器，測試人員、BUILDER人員、開發人員、專家之間發郵件進行交流。

三、軟件缺陷管理的目的

1）保證信息的一致性；
  2）保證缺陷獲得有效的跟蹤和解決，縮短溝通時間，解決問題更高效；
  3）獲取正確的Bug信息，利於缺陷分析、產品度量，使項目狀況可視化增強。

四、軟件缺陷的相關屬性

@一、缺陷發現人

在提交缺陷的時候，測試人員通常是測試的發現人，便於統計分析測試人員的能力，方便公司進行績效考覈。

@二、缺陷發現時間

缺陷發現時間是一個統計的計數點，或者數據點，便於企業負責人選擇合適的產品發佈時間。

@三、軟件缺陷的狀態

1）New：缺陷的初始狀態（發現問題，提交問題，提交問題後，這個缺陷就處於New的狀態）
  2）Open：開發人員開始修改缺陷（測試人員提交問題，開發人員接受並開始修改問題）
  3）Fixed：開發人員修改缺陷完畢
  4）Closed：迴歸測試經過（測試人員進行迴歸測試，迴歸測試經過，該問題改成Close狀態）
  5）Reopen：迴歸測試失敗（測試人員進行迴歸測試，迴歸測試不經過，該問題改成Reopen狀態）
  6）Postpone：推遲修改
  7）Rejected：開發人員認爲不是程序問題，拒絕缺陷
  8）Duplicate：與已經提交的Defect重複
  9）Abandon：被Reject和Duplicate的Defect，測試人員確認後的確不是問題，將Defect置爲此狀態

比較理想的缺陷流程：從new狀態——>open——>fixed——>closed狀態。

@/四、缺陷的嚴重程度(Severity)

是站在用戶的角度，指Bug出現後對用戶和系統的影響程度。

軟件缺陷的嚴重性指軟件缺陷對軟件質量的破壞程度，即軟件缺陷的存在對軟件的功能和性能產生怎樣的影響，咱們能夠簡單地將軟件缺陷的嚴重性劃分爲4個等級：致命、嚴重、通常、提示。

1）致命缺陷：例如軟件的意外退出甚至操做系統崩潰，形成數據丟失。
  2）嚴重缺陷：系統沒法知足基本的商業要求且沒有便捷可用的工做區。性能、功能或使用方面嚴重不達標，例如因爲單功能失效引發多個功能失效。
  3）通常缺陷：系統可以知足商業要求。有快捷方便的工做區可供使用。性能、功能或使用方面並非嚴重不達標，例如軟件單個功能失效。
  4）提示：微小修改，但願提出建議，最好可以修正，但不是必需的。在發佈準確性或實用性方面不會產生重大影響

@五、缺陷的優先級（Priority）

是站在開發/項目的角度，綜合權衡修改Bug的時間、成本、技術和風險，決定Bug修改的前後順序。

1）優先級0（Priority 0）
     這類軟件缺陷必須在24小時以內被解決
  2）優先級1（Priority 1）
     這類軟件缺陷必須修復而後才能發佈產品或者才能達到用戶體驗所包含的最主要目標，須要在1—2天內修改
  3）優先級2（Priority 2）
     軟件缺陷應該在2—4天內被修復
  4）優先級3（Priority 3）
     若是修復這個缺陷會比較好，最好在一週內修改
  5）優先級4（Priority 4）
     發佈週期內修改或者不修改

Severity（嚴重性）與Priority（優先級）之間的區別

1）軟件裏的Bug所產生的效果不會自動的與修復它的優先級相關聯。一個嚴重的Bug多是那種對1%的用戶來講也是不太會發生的使軟件崩潰的bug。那它的優先級也比那些誤操做致使的須要對每一個用戶每次須要從新鍵入一部分輸入的Bug的優先級要低。
  所以：須要分別跟蹤Bug優先級和嚴重性，而後進行適當的修復。Bug的重要性是由項目來決定的，不一樣於客戶對Bug的感知。某些狀況下，分別跟蹤急迫的或是按照客戶觀點定義的Bug也是頗有意義的。
  1）優先級與項目日程相關，嚴重性與標準相關。優先級表示須要優先考慮和注意的對象；由重要性順序構建成優先級；嚴重性暗示須要嚴格遵守標準或者是高層原則，好比，一個嚴重的代碼行爲。優先級和嚴重性這2個詞出如今Bug跟蹤裏。某種商業化的，問題跟蹤及管理的軟件工具是可行的。這些工具，隨着測試工程師們逐條的輸入，給予團隊完整的信息，以至開發人員能明白Bug，明白Bug的嚴重性，重現它，並修復它。修復創建在優先級和嚴重性的基礎上。嚴重性的問題按照客戶的風險評估來定義，並記錄於被選擇的跟蹤工具中。多Bug的軟件會「嚴重」影響項目進度，依次也能致使對「優先級」從新評估和商榷。

@六、缺陷的類型

1）從質量特性角度考慮有功能、性能、安全性、易用性、可靠性缺陷；
  2）從功能性角度考慮有：錯誤（Errors）、遺漏（Missing）、多餘的（Extra）、可優化的（Improvement/Enhancement/Suggestion）缺陷；
  3）從缺陷產生的緣由考慮有：需求規格說明書SRS、設計問題、編碼問題、需求變動、設計變動、配置問題、測試問題

@七、缺陷的版本

1）發現缺陷的版本（必須說明）
  2）修改bug的版本
  3）迴歸測試的版本（通常是最新版本）

@八、缺陷修改日期

是主要對開發人員進行考覈的參數。

五、缺陷報告單寫做

@一、完整缺陷報告單內容

一個完整的、高質量的缺陷報告單包括三個方面：簡單描述、詳細描述、相關附件。

1）簡單描述
     用一句簡單的，提攜綱領的描述清楚問題
  2）詳細描述
     *1*描述問題的基本環境，包括操做系統、硬件環境、網絡環境、被測試軟件的運行環境
     *2*用簡明扼要的語言描述清楚軟件出現異常時候的測試人員的操做步驟及使用的數據
     *3*若是從GUI上能夠反映出軟件的異常，採用拷屏的方式截取界面，粘貼在問題單中
     *4*被測試軟件運行時的相關日誌文件
     *5*測試人員根據上述信息能夠給出對問題簡單的分析
     *6*被測試軟件的版本
     *7*狀態、嚴重級別
     *8*提交日期、提交人
  3）相關附件
     *1*GUI的拷屏圖片
     *2*被測試軟件運行的相關日誌文件

@二、優秀缺陷跟蹤單範例及分析

1）簡單描述
     -Arial、Wingdings和Symbol字體會破壞新文件。
  2）詳細描述
     *1*軟件測試環境爲windows 2000 sp4
     *2*啓動WordEdit編輯器，而後建立新文件
     *3*輸入四行文本，重複輸入「The quick fox jumps over the lazy brown dog」
     *4*選中全部四行文本，而後選擇字體下拉菜單，並選擇Arial
     *5*全部文本被轉換成控制字符，數字和其餘明顯的隨機二進制數據
     *6*重複3次，結果都同樣
  3）相關附件
     *1*變換格式以前的文檔
     *2*變換格式以後的文檔

@三、缺陷報告的寫做要點

1）缺陷標題
  2）缺陷重現步驟（儘可能3次重現故障）
  3）缺陷類型
  4）缺陷優先級
  5）缺陷嚴重程度