今天開始和大家分享缺陷報告的內(nèi)容，在這部分會講一下缺陷的基本屬性，缺陷的處理過程和如何書寫缺陷報告。
一、什么是缺陷
在第一章我們說過了什么事缺陷，一切不滿足用戶需求的都是缺陷。
下面我們對缺陷的概念在詳細(xì)的介紹一下。
佩騰在《軟件測試》一書中說符合下面5個規(guī)則的就可以成為軟件缺陷：
1、軟件未達(dá)到產(chǎn)品說明書標(biāo)明的功能。
2、軟件出現(xiàn)了產(chǎn)品說明書中指明不會出現(xiàn)的錯誤。
3、軟件功能超出了產(chǎn)品說明書指明的范圍。
4、軟件未達(dá)到產(chǎn)品說明書中雖未指出但應(yīng)達(dá)到的目標(biāo)。
5、軟件測試員認(rèn)為軟件難以理解、不易使用、運行速度緩慢，或最終用戶認(rèn)為不好。
關(guān)于這 5點我們舉例來說明一下。第一點，比如說我們開發(fā)一個記事本的軟件，說明書中明確說了可以輸入文字，結(jié)果開發(fā)的軟件不具備輸入文本的功能，肯定就是一個 defect了。第二點，說明書中明確說了在記事本軟件中輸入“聯(lián)通”可以正確的保存并打開瀏覽，結(jié)果我們的記事本軟件打開保存了的輸入“聯(lián)通”的文件出 現(xiàn)了亂碼，這也是一個defect了。第三點，比如說我們的說明書中沒有定義記事本會自動的對關(guān)鍵字高亮顯示（這個主要是針對編程語言），結(jié)果我們的記事本程序自動對關(guān)鍵字高亮顯示了，這也是defect，盡管這樣對用戶使用會更好，但是他超出了產(chǎn)品說明書中指明的功能范圍，所以還是defect。第四點 不太好說，所以就不用記事本舉例了，原諒我，呵呵。比如在我國開發(fā)財務(wù)管理軟件必須要符合財政部的規(guī)定，盡管說明書中一般不會指出，但是軟件必須要符合這個規(guī)定，不然是不能發(fā)行使用的??！第五點就好理解，因為測試員是第一個使用軟件的，必須要從客戶的角度來對待，盡管這里會有主觀感覺，但還是要盡量客觀 （就是多參考一些標(biāo)準(zhǔn)，例如定義界面的，檢察易用性的標(biāo)準(zhǔn)），比如在Windows下的程序?qū)υ捒蛑小笆恰卑粹o都是在左邊，“否”按鈕在右邊，如果發(fā)現(xiàn)在 我們的記事本程序中，提示是否保存文件的對話框里“是”按鈕在右邊了，這就是一個defect了，因為它不符合Windows下用戶的使用習(xí)慣。知道了什么是缺陷，我們就再來看看怎么去描述一個缺陷吧，看看缺陷都有哪些屬性。
二、缺陷的屬性
(1)、缺陷標(biāo)識：就是缺陷的編號了，每個缺陷有一個唯一的編號。
(2)、缺陷類型：這是一個功能性還是性能的bug，是文檔的還是界面的bug，還是本地化的bug。
(3)、缺陷的嚴(yán)重程度：
a、致命Fatal：系統(tǒng)崩潰、數(shù)據(jù)丟失、數(shù)據(jù)毀壞。無法進(jìn)行后續(xù)的測試。
b、嚴(yán)重Critical：操作性錯誤、功能遺漏、影響用戶使用。
c、一般Major：UI方面的，一些小的錯誤，不影響使用。
d、較小Minor：建議性的問題，可以不做修改。
(4)、缺陷的修復(fù)優(yōu)先級：
a、立即修復(fù)：影響后續(xù)測試的問題。
b、高優(yōu)先級：在產(chǎn)品發(fā)布前必須修復(fù)。
c、中優(yōu)先級：嚴(yán)重程度一般的缺陷。
d、低優(yōu)先級：有時間就要修復(fù)的。
(5)、缺陷的狀態(tài)
a、open：新提交的bug
b、fixed：已修復(fù)等待測試人員驗證的bug
c、reopen：測試人員驗證發(fā)現(xiàn)沒有修復(fù)的bug
d、closed：測試人員驗證已修復(fù)的bug
(6)、缺陷的頻率---是指缺陷出現(xiàn)的概率
a、總是：可以100%重現(xiàn)
b、通常：出現(xiàn)的概率為80%--90%
c、有時：出現(xiàn)的概率為30%--50%
d、較少：出現(xiàn)頻率比較低，2%左右
這里要注意一下缺陷的嚴(yán)重程度和優(yōu)先級并不是一回事，嚴(yán)重程度說明的是缺陷產(chǎn)生的后果，優(yōu)先級是修復(fù)的優(yōu)先級。通常嚴(yán)重程度和優(yōu)先級是一一對應(yīng)的，但不絕對是。缺陷的嚴(yán)重程度、頻率、優(yōu)先級、狀態(tài)這些并不是只有這幾種情況，每個公司都有自己的定義的。
三、bug處理的流程：
這個是最簡單的方式了。
下面就是最重要的，我們發(fā)現(xiàn)了缺陷就要提交缺陷報告給開發(fā)人員，那么如何去寫缺陷報告呢？
四、缺陷報告
下面的是一個缺陷報告的基本結(jié)構(gòu)：
A、缺陷編號
B、OS、version、platform、projectname
C、缺陷類型
D、缺陷的嚴(yán)重程度
E、缺陷的頻率
F、缺陷的優(yōu)先級
H、缺陷的狀態(tài)
I、Summary
J、ReproduceSteps
K、ActualResult
L、ExpectedResult
M、AdditionalInformation
摘要要簡明扼要，盡量用執(zhí)行什么動作發(fā)生了什么來描述，比如It pops up an error dialog after clicking the "OK" button on XXX screen.
重現(xiàn)步驟要完整簡明，不要包含不必要的信息，每步盡量以動詞開頭，例如Click XXX button to go to XXX screen.
實際結(jié)果要如實的描述發(fā)生了什么，不要包含自己的猜想。如：The error dialog pops up about "……"。
期望結(jié)果盡量要有依據(jù)，比如是根據(jù)說明書啊，一般用should，例如：According to the spec page
120, It should ……。
注釋可以加上不方便出現(xiàn)在重現(xiàn)步驟中的內(nèi)容，也可以是圖片，log等信息。
寫缺陷的一些忠告：
1、要多讀優(yōu)秀的缺陷報告，學(xué)習(xí)他們是怎么寫的。
2、每個缺陷報告盡量的截取圖片和log，來幫助開發(fā)人員快速定位問題。
3、對重現(xiàn)步驟自己要多執(zhí)行幾遍，確保開發(fā)人員可以再現(xiàn)缺陷。
4、缺陷報告要客觀得體，不要包含自己的主觀情緒
最后和大家分享一下缺陷報告的5C準(zhǔn)則：
聯(lián)系客服
