今天開始和大家分享缺陷報告的內容，在這部分會講一下缺陷的基本屬性，缺陷的處理過程和如何書寫缺陷報告。

一、什麼是缺陷

在第一章我們說過了什麼事缺陷，一切不滿足使用者需求的都是缺陷。

下面我們對缺陷的概念在詳細的介紹一下。

佩騰在《軟體測試》一書中說符合下面5個規則的就可以成為軟體缺陷：

1、軟體未達到產品說明書標明的功能。

2、軟體出現了產品說明書中指明不會出現的錯誤。

3、軟體功能超出了產品說明書指明的範圍。

4、軟體未達到產品說明書中雖未指出但應達到的目標。

5、軟體測試員認為軟體難以理解、不易使用、執行速度緩慢，或終端使用者認為不好。

關於這 5點我們舉例來說明一下。第一點，比如說我們開發一個記事本的軟體，說明書中明確說了可以輸入文字，結果開發的軟體不具備輸入文字的功能，肯定就是一個 defect了。第二點，說明書中明確說了在記事本軟體中輸入“聯通”可以正確的儲存並開啟瀏覽，結果我們的記事本軟體開啟儲存了的輸入“聯通”的檔案出 現了亂碼，這也是一個defect了。第三點，比如說我們的說明書中沒有定義記事本會自動的對關鍵字高亮顯示（這個主要是針對程式語言），結果我們的記事本程式自動對關鍵字高亮顯示了，這也是defect，儘管這樣對使用者使用會更好，但是他超出了產品說明書中指明的功能範圍，所以還是defect。第四點 不太好說，所以就不用記事本舉例了，原諒我，呵呵。比如在我國開發財務管理軟體必須要符合財政部的規定，儘管說明書中一般不會指出，但是軟體必須要符合這個規定，不然是不能發行使用的啊！第五點就好理解，因為測試員是第一個使用軟體的，必須要從客戶的角度來對待，儘管這裡會有主觀感覺，但還是要儘量客觀 （就是多參考一些標準，例如定義介面的，檢察易用性的標準），比如在Windows下的程式對話方塊中“是”按鈕都是在左邊，“否”按鈕在右邊，如果發現在 我們的記事本程式中，提示是否儲存檔案的對話方塊裡“是”按鈕在右邊了，這就是一個defect了，因為它不符合Windows下使用者的使用習慣。 知道了什麼是缺陷，我們就再來看看怎麼去描述一個缺陷吧，看看缺陷都有哪些屬性。

二、缺陷的屬性

(1)、缺陷標識：就是缺陷的編號了，每個缺陷有一個唯一的編號。

(2)、缺陷型別：這是一個功能性還是效能的bug，是文件的還是介面的bug，還是本地化的bug。

(3)、缺陷的嚴重程度：

a、致命Fatal：系統崩潰、資料丟失、資料毀壞。無法進行後續的測試。

b、嚴重Critical：操作性錯誤、功能遺漏、影響使用者使用。

c、一般Major：UI方面的，一些小的錯誤，不影響使用。

d、較小Minor：建議性的問題，可以不做修改。

(4)、缺陷的修復優先順序：

a、立即修復：影響後續測試的問題。

b、高優先順序：在產品釋出前必須修復。

c、中優先順序：嚴重程度一般的缺陷。

d、低優先順序：有時間就要修復的。

(5)、缺陷的狀態

a、open：新提交的bug

b、fixed：已修復等待測試人員驗證的bug

c、reopen：測試人員驗證發現沒有修復的bug

d、closed：測試人員驗證已修復的bug

(6)、缺陷的頻率---是指缺陷出現的概率

a、總是：可以100%重現

b、通常：出現的概率為80%--90%

c、有時：出現的概率為30%--50%

d、較少：出現頻率比較低，2%左右

這裡要注意一下缺陷的嚴重程度和優先順序並不是一回事，嚴重程度說明的是缺陷產生的後果，優先順序是修復的優先順序。通常嚴重程度和優先順序是一一對應的，但不絕對是。缺陷的嚴重程度、頻率、優先順序、狀態這些並不是只有這幾種情況，每個公司都有自己的定義的。

三、bug處理的流程：

這個是最簡單的方式了。

下面就是最重要的，我們發現了缺陷就要提交缺陷報告給開發人員，那麼如何去寫缺陷報告呢？

四、缺陷報告

下面的是一個缺陷報告的基本結構：

          A、缺陷編號

       B、OS、version、platform、projectname

       C、缺陷型別

       D、缺陷的嚴重程度

       E、缺陷的頻率

       F、缺陷的優先順序

       H、缺陷的狀態

       I、Summary

       J、ReproduceSteps

       K、ActualResult

       L、ExpectedResult

       M、AdditionalInformation

摘要要簡明扼要，儘量用執行什麼動作發生了什麼來描述，比如It pops up an error dialog after clicking the "OK" button on XXX screen.

重現步驟要完整簡明，不要包含不必要的資訊，每步儘量以動詞開頭，例如Click XXX button to go to XXX screen.

實際結果要如實的描述發生了什麼，不要包含自己的猜想。如：The error dialog pops up about "……"。

期望結果儘量要有依據，比如是根據說明書啊，一般用should，例如：According to the spec page

120, It should ……。

註釋可以加上不方便出現在重現步驟中的內容，也可以是圖片，log等資訊。

寫缺陷的一些忠告：

1、要多讀優秀的缺陷報告，學習他們是怎麼寫的。

2、每個缺陷報告儘量的擷取圖片和log，來幫助開發人員快速定位問題。

3、對重現步驟自己要多執行幾遍，確保開發人員可以再現缺陷。

4、缺陷報告要客觀得體，不要包含自己的主觀情緒

最後和大家分享一下缺陷報告的5C準則：

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