為什麼要求有效的缺陷報告
缺陷報告是測試過程中最重要的部分，對產品的質量有較大的影響，是測試人員價值的終極體現。好的缺陷報告可以減少研發部門的二次缺陷率、提高研發修改缺陷的速度、提高測試部門的信用度、增強測試和研發部門的協作。Bug寫的越好，在實際中為了修改這個bug花費的時間相對來說就會越少，測試人員的信譽度和產品的貢獻度也會很好的提升。
衡量優秀缺陷報告的質量指標
對於管理層來說，是清晰明瞭的，特別是在主題摘要這一級。
對於研發人員來說，是有用的。提供能夠讓研發人員高效的調試問題的相關信息，使其很快的將bug從“打開”狀態轉變成“關閉”狀態，提高測試和開發的工作效率。
對於後期的維護，能夠有效的從bug信息查詢出問題的描述和解決辦法
說來容易，在實踐中需要測試人員仔細用心。
如何編寫缺陷報告
缺陷報告作為測試和研發之間的溝通的橋樑，測試人員在報告bug的時候，有效的bug描述，會更加容易幫助開發解決問題。寫有效的缺陷報告不要求有較好的文字功底，關鍵是覆蓋了研發所關注的要點。作為一個優秀的缺陷報告，應該包括以下內容：
一、摘要
簡明扼要的對bug進行一個概述，目的是讓人看了就知道大概出了什麼問題。Bug標題必須簡短而且要求描述和傳達出準確的信息。這個摘要一般比較短，所以使用一些精煉的關鍵詞是很必要的。比如：用戶登錄時，密碼顯示為明文。
以下是一些較差的摘要：
1、摘要太模糊：在用戶登錄界面，在輸入框中能看到輸入的內容。
分析：這個摘要太模糊，沒有準確的描述出現了什麼問題，反而將問題出現時的狀態寫了上去。在一些標準中，密碼輸入框應顯示為密文，並且也沒有說明是在用戶名輸入框中還是密碼輸入框中顯示輸入的內容。
修正：用戶登錄時，密碼框中顯示輸入內容。
2、不足夠的信息：密碼框問題。
分析：這個bug摘要信息很不充足，不知道出了什麼問題
太長的摘要：在用戶登錄界面，在輸入框中，輸入正確的用戶名和密碼。在密碼框中，顯示密碼信息。
分析：此摘要有太多冗餘信息，把步驟添加到了摘要中。如“在輸入框中，輸入正確的用戶名和密碼”等這些完全可以放置到bug描述步驟中去，
修正：用戶登錄時，密碼框中顯示輸入內容。
備註：有些測試人員將其命名為“標題”，這裡以我們的QC為準，名為“摘要”
二、bug屬性
在編寫bug缺陷報告時應該儘可能全面的描述bug的屬性。以QC為例，bug屬性包含如下：
Ø 產品模塊：發現的bug所屬的模塊
Ø 測試版本：當前的測試版本
Ø 嚴重級別
Ø 所屬項目
Ø 是否可重現
三、負責人：負責解決此問題的研發人員
四、檢測者：發現此問題的測試人員
五、根據公司的實際情況，增加了“部門”和“迭代週期”兩項，“部門”是必填項，“迭代週期”可選。
六、Bug的詳細描述
Bug的詳細描述要達到讓研發人員清晰這是一個什麼問題，看了能夠自己復現的程度，所以要詳細但要避免冗餘。要包含以下幾點：
1、測試配置：主要是產品的相關配置，比如：使用用戶登錄某一個系統，前提條件是需要註冊或者管理員添加用戶。又或者是其他如交換機或路由器等的配置
2、測試環境：測試所搭建的網絡拓撲環境。對於不需要搭建網絡環境的測試，可省略，如升級安裝包等。
3、測試步驟：這是比較關鍵的，目的是幫助研發重現。在有多條步驟的情況下組號列出1、2、3等步驟
4、預期結果和實際結果：這兩個實際上都應該寫的描述中，不但能夠做對比，而且能夠有效的證明這確實是一個bug。例如這樣的bug描述：
1：使用瀏覽器訪問登陸界面。
2：輸入正確的用戶名和密碼。
3：在密碼輸入框顯示密碼信息。
上述bug的描述在很熟悉測試產品的情況下或許可以看懂，但都會猶豫一下他想表達什麼意思，正確的結果是什麼，錯誤的結果是什麼。
在這種情況下若加上“預期結果”和“實際結果”，會使意思表達的更加明確。第二個bug將步驟和結果混雜在一起，可以這樣修改一下：
1：使用瀏覽器訪問登陸界面。
2：輸入正確的用戶名和密碼。
3：然後點擊“登錄”按鈕。
預期結果：密碼輸入框，顯示信息為密文。
實際結果：密碼輸入框內容為明文。
其他注意事項
在報告缺陷的過程中，除了上述描述外還應注意如下：
1. 一個bug報告只能描述一個bug，如果將幾個問題都寫在一個bug報告中，開發人員很難發現自己的問題並解決，或者導致某些優先級高的bug沒有及時得到解決
2. Bug的唯一性：在提交bug報告之前，要確認這個bug是否已經被其他人發現並報告（搜索功能）
3. 重現：有些bug很容易就重現，有些就很難。如果你能重現一個bug，應該準確的解釋必須的條件。應該列出所有的步驟，包括精確的組合，文件名以及你碰到或重現這個問題的操作順序。如果你能夠確認這個問題在任何文件，任何的操作順序等條件下都會發生，那也做好能夠給出一個明確的示例來幫助開發重現。如果發現一個不能重新的bug，就儘可能多的提供有效的信息給你的開發人員。截圖、日誌，抓包等對捕獲這個bug有幫助的信息可以包含在你的bug報告中
4. 定位：對於一個測試人員來說，應該做一些有效的事情來幫助定位問題。要多想會不會是外部的什麼特殊原因引起的這個問題？會不會是因為網絡的問題導致數據不通？或者是應用軟件配置錯誤導致數據不通？如果實在不能定位問題原因，是否可以想辦法縮小出錯的範圍？儘量避免是由於測試人員的問題導致誤報了bug。測試人員定位bug的能力，一定程度上是測試人員附加值的體現，能夠節省項目組相關人員的時間，縮短了迴歸bug的時間。
5. 報告bug時要使用中性語言，不要帶有感情色彩。不要帶有幽默也不要帶有任何不滿情緒，儘量考慮一下研發的情緒。
閱讀更多 說說軟件測試那些事兒 的文章
