1、軟件測試缺陷基本概念和相關術語
1）缺陷（Defect）：是指存在於軟件之中偏差，可被激活，以靜態形式存在於軟件內部，相當於Bug。
2）故障（Fault）：當缺陷被激活后，軟件運行中出現的狀態，可引起意外情況，若不加處理，可產生失效，是一個動態行為。
3）失效（Failure）：軟件運行時產生的外部異常行為結果，表現與用戶需求不一致，功能能力終止，用戶無法完成所需要的應用。
4）Bug：電腦系統或者程序中存在的任何一種破壞正常運轉能力的問題或者缺陷，都可以稱之為“Bug”；有時也泛指因軟件產品內部引起的軟件產品最終運行時和預期結果的偏離。
5）缺陷報告單：指測試執行過程中，發現缺陷失效后，提出書面的報告，提供給開發人員作為定位缺陷的依據。
2、軟件缺陷管理基本流程
下圖是一個簡單的BUG跟蹤流程圖：
1）橢圓形中標示的都是角色（測試人員、BUILDER人員、開發人員、專家會診）
2）柱狀圖1：發布服務器，一般存放當前最新的軟件版本
柱狀圖2：RAID/BMS，是Bug的管理系統，測試人員發現問題都要提交到這個系統上
柱狀圖3：郵件服務器，測試人員、BUILDER人員、開發人員、專家之間發郵件進行交流。
3、軟件缺陷管理的目的
1）保證信息的一致性；
2）保證缺陷得到有效的跟蹤和解決，縮短溝通時間，解決問題更高效；
3）獲取正確的Bug信息，利於缺陷分析、產品度量，使項目情況可視化加強。
4、軟件缺陷的相關屬性
@1、缺陷發現人
在提交缺陷的時候，測試人員一般是測試的發現人，便於統計分析測試人員的能力，方便公司進行績效考核。
@2、缺陷發現時間
缺陷發現時間是一個統計的計數點，或者數據點，便於企業負責人選擇合適的產品發布時間。
@3、軟件缺陷的狀態
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狀態。
@/4、缺陷的嚴重程度(Severity)
是站在用戶的角度，指Bug出現后對用戶和系統的影響程度。
軟件缺陷的嚴重性指軟件缺陷對軟件質量的破壞程度，即軟件缺陷的存在對軟件的功能和性能產生怎樣的影響，我們可以簡單地將軟件缺陷的嚴重性划分為4個等級：致命、嚴重、一般、提示。
1）致命缺陷：例如軟件的意外退出甚至操作系統崩潰，造成數據丟失。
2）嚴重缺陷：系統無法滿足基本的商業要求且沒有便捷可用的工作區。性能、功能或使用方面嚴重不達標，例如由於單功能失效引起多個功能失效。
3）一般缺陷：系統能夠滿足商業要求。有快捷方便的工作區可供使用。性能、功能或使用方面並不是嚴重不達標，例如軟件單個功能失效。
4）提示：微小修改，希望提出建議，最好能夠修正，但不是必需的。在發布准確性或實用性方面不會產生重大影響
@5、缺陷的優先級（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的軟件會“嚴重”影響項目進度，依次也能導致對“優先級”重新評估和商榷。
@6、缺陷的類型
1）從質量特性角度考慮有功能、性能、安全性、易用性、可靠性缺陷；
2）從功能性角度考慮有：錯誤（Errors）、遺漏（Missing）、多余的（Extra）、可優化的（Improvement/Enhancement/Suggestion）缺陷；
3）從缺陷產生的原因考慮有：需求規格說明書SRS、設計問題、編碼問題、需求變更、設計變更、配置問題、測試問題
@7、缺陷的版本
1）發現缺陷的版本（必須說明）
2）修改bug的版本
3）回歸測試的版本（一般是最新版本）
@8、缺陷修改日期
是主要對開發人員進行考核的參數。
5、缺陷報告單寫作
@1、完整缺陷報告單內容
一個完整的、高質量的缺陷報告單包括三個方面：簡單描述、詳細描述、相關附件。
1）簡單描述
用一句簡單的，提攜綱領的描述清楚問題
2）詳細描述
*1*描述問題的基本環境，包括操作系統、硬件環境、網絡環境、被測試軟件的運行環境
*2*用簡明扼要的語言描述清楚軟件出現異常時候的測試人員的操作步驟及使用的數據
*3*如果從GUI上可以反映出軟件的異常，采用拷屏的方式截取界面，粘貼在問題單中
*4*被測試軟件運行時的相關日志文件
*5*測試人員根據上述信息可以給出對問題簡單的分析
*6*被測試軟件的版本
*7*狀態、嚴重級別
*8*提交日期、提交人
3）相關附件
*1*GUI的拷屏圖片
*2*被測試軟件運行的相關日志文件
@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*變換格式之后的文檔
@3、缺陷報告的寫作要點
1）缺陷標題
2）缺陷重現步驟（盡量3次重現故障）
3）缺陷類型
4）缺陷優先級
5）缺陷嚴重程度
