一、什么是缺陷 一切不滿足用戶需求的都是缺陷。 下面我們對缺陷的概念在詳細的介紹一下。 佩騰在《軟件測試》一書中說符合下面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（一致）

總結

以上是生活随笔為你收集整理的如何写好缺陷报告？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。