缺陷報告是測試工程師與開發工程師交流溝通的重要橋梁，也是測試工程師日常工作的重要輸出。 作為優秀的測試工程師，最基本的一項技能就是，把發現的缺陷準確無歧義地表達清楚。

“準確無歧義地表達”意味著，開發工程師可以根據缺陷報告快速理解缺陷，并精確定位問題。同時，通過這個缺陷報告，開發經理可以準確預估缺陷修復的優先級、產品經理可以了解缺陷對用戶或業務的影響以及嚴重性。

可見，缺陷報告本身的質量將直接關系到缺陷被修復的速度以及開發工程師的效率，同時還會影響測試工程師的信用、測試與開發人員協作的有效性。

那么，如何才能寫出一份高效的缺陷報告呢？或者說，一份好的缺陷報告需要包括哪些具體內容呢？

你可能覺得這并不是什么難事兒，畢竟軟件企業通常都有缺陷管理系統，比如典型的ALM（以前的Quality Center）、JIRA、Bugzilla、BugFree和Mantis等。當使用這類系統遞交缺陷時，會自動生成模板，你只要按照其中的必填字段提供缺陷的詳細信息就可以了。

很多時候，你不用想應該提供些什么信息，系統會引導你提供相關的信息。但是，你有仔細想過為什么要填寫這些字段，這些字段都起什么作用，以及每個字段的內容具體應該怎么填寫嗎？

你必須牢牢記住的是，好的缺陷報告絕對不是大量信息的堆疊，而是以高效的方式提供準確有用的信息。

接下來，我就帶你一起去看一份高效的缺陷報告主要由哪些部分組成，以及每部分內容的關鍵點是什么。

● 缺陷標題 ●

缺陷標題通常是別人最先看到的部分，是對缺陷的概括性描述，通常采用“在什么情況下發生了什么問題”的模式。

首先，對“什么問題”的描述不僅要做到清晰簡潔，最關鍵是要足夠具體，切忌不能采用過于籠統的描述。描述“什么問題”的同時還必須清楚地表述發生問題時的上下文，也就是問題出現的場景。

“用戶不能正常登錄”“搜索功能有問題”和“用戶信息頁面的地址欄位置不正確”等，這樣的描述會給人“說了等于沒說”的感覺。這樣的描述，很容易引發開發工程師的反感和抵觸情緒，從而造成缺陷被拒絕修改（reject）。同時，還會造成缺陷管理上的困難以及過程的低效。

比如，當你發現了一個菜單欄上某個條目缺失的問題，在遞交缺陷報告前，通常會去缺陷管理系統搜索一下是否已經有人遞交過類似的缺陷。

當你以“菜單欄”為關鍵字搜索時，你可能會得到一堆“菜單欄有問題”的缺陷，如果缺陷標題的描述過于籠統，你就不得不點擊進入每個已知缺陷點去看細節描述，這就會大大降低你的工作效率。

所以，如果缺陷標題本身就能概括性地描述具體問題，你就可以通過閱讀標題判斷類似的缺陷是否被提交過，大大提高測試工程師提交缺陷報告的效率。

其次，標題應該盡可能描述問題本質，而避免只停留在問題的表面。

比如，“商品金額輸入框，可以輸入英文字母和其他字符”這個描述就只描述了問題的表面現象，而采用諸如“商品金額輸入框，沒有對輸入內容做校驗”的方式，就可以透過標題看到缺陷的本質，這樣可以幫助開發人員快速掌握問題的本質。

最后，缺陷標題不易過長，對缺陷更詳細的描述應該放在“缺陷概述”里。

● 缺陷概述 ●

缺陷概述通常會提供更多概括性的缺陷本質與現象的描述，是缺陷標題的細化。這部分內容通常是開發工程師打開缺陷報告后最先關注的內容，所以用清晰簡短的語句將問題的本質描述清楚是關鍵。

缺陷概述還會包括缺陷的其他延展部分，比如你可以在這部分列出同一類型的缺陷可能出現的所有場景；再比如，你還可以描述同樣的問題是否會在之前的版本中重現等。在這里，你應該盡量避免以缺陷重現步驟的形式來描述，而應該使用概括性的語句。

總之，缺陷概述的目的是，清晰簡潔地描述缺陷，使開發工程師能夠聚焦缺陷的本質。

● 缺陷影響 ●

缺陷影響描述的是，缺陷引起的問題對用戶或者對業務的影響范圍以及嚴重程度。

缺陷影響決定了缺陷的優先級（Priority）和嚴重程度（Severity），開發經理會以此為依據來決定修復該缺陷的優先級；而產品經理會以此為依據來衡量缺陷的嚴重程度，并決定是否要等該缺陷被修復后才能發布產品。

測試工程師準確描述缺陷影響的前提是，必須對軟件的應用場景以及需求有深入的理解，這也是對測試工程師業務基本功的考驗。

● 環境配置 ●

環境配置用以詳細描述測試環境的配置細節，為缺陷的重現提供必要的環境信息。 比如，操作系統的類型與版本、被測軟件版本、瀏覽器的種類和版本、被測軟件的配置信息、集群的配置參數、中間件的版本信息等等。

需要注意的是，環境配置的內容通常是按需描述，也就是說通常只描述那些重現缺陷的環境敏感信息。

比如，“菜單欄上某個條目缺失的問題”只會發生在Chrome瀏覽器，而其他瀏覽器都沒有類似問題。那么，Chrome瀏覽器就是環境敏感信息，必須予以描述，而至于Chrome瀏覽器是運行在什么操作系統上就無關緊要了，無需特意去描述了。

前置條件

前置條件是指測試步驟開始前系統應該處在的狀態，其目的是減少缺陷重現步驟的描述。合理地使用前置條件可以在描述缺陷重現步驟時排除不必要的干擾，使其更有針對性。

比如，某個業務操作需要先完成用戶登錄，你在缺陷重現步驟里就沒有必要描述登錄操作的步驟細節，可以直接使用 “前置條件：用戶已完成登錄”的描述方式；

再比如，用戶在執行登錄操作前，需要事先在被測系統準備好待登錄用戶，你在描述時也無需增加“用測試數據生成工具生成用戶”的步驟，可以直接使用 “前置條件：用戶已完成注冊”的描述方式。

● 缺陷重現步驟 ●

缺陷重現步驟是整個缺陷報告中最核心的內容，其目的在于用簡潔的語言向開發工程師展示缺陷重現的具體操作步驟。

這里需要注意的是，操作步驟通常是從用戶角度出發來描述的，每個步驟都應該是可操作并且是連貫的，所以往往會采用步驟列表的表現形式。

通常測試工程師在寫缺陷重現步驟前，需要反復執行這些步驟3次以上：

①確保缺陷的可重現性；

②找到最短的重現路徑，過濾掉那些非必要的步驟，避免產生不必要的干擾。

對于缺陷重現步驟的描述應該盡量避免以下3個常見問題：

1、籠統的描述，缺乏可操作的具體步驟。

2、出現與缺陷重現不相關的步驟。

3、缺乏對測試數據的相關描述。

● 期望結果和實際結果 ●

期望結果和實際結果通常和缺陷重現步驟綁定在一起，在描述重現步驟的過程中，需要明確說明期待結果和實際結果。期待結果來自于對需求的理解，而實際結果來自于測試執行的結果。

通常來講，當你描述期望結果時，需要說明應該發生什么，而不是什么不應該發生；而描述實際結果時，你應該說明發生了什么，而不是什么沒有發生。

● 優先級和嚴重程度 ●

我之所以將優先級和嚴重程度放在一起，是因為這兩個概念看起來有點類似，而本質卻完全不同。而且，很多入行不久的測試工程師，也很難搞清楚這兩者的差異到底在哪里。

根據百度百科的解釋，缺陷優先級是指缺陷必須被修復的緊急程度，而缺陷嚴重程度是指因缺陷引起的故障對軟件產品的影響程度。

可見，嚴重程度是缺陷本身的屬性，通常確定后就不再變化，而優先級是缺陷的工程屬性，會隨著項目進度、解決缺陷的成本等因素而變動。那么，缺陷的優先級和嚴重程度又有什么關系呢？

缺陷越嚴重，優先級就越高；

缺陷影響的范圍越大，優先級也會越高；

有些缺陷雖然從用戶影響角度來說不算嚴重，但是會妨礙測試或者是自動化測試的執行，這類缺陷屬于典型的嚴重程度低，但是優先級高；

有些缺陷雖然嚴重程度比較高，但是考慮到修復成本以及技術難度，也會出現優先級較低的情況。

● 變通方案 ●

變通方案是提供一種臨時繞開當前缺陷而不影響產品功能的方式，通常由測試工程師或者開發工程師完成，或者他們一同決定。

變通方案的有無以及實施的難易程度，是決定缺陷優先級和嚴重程度的重要依據。如果某個嚴重的缺陷沒有任何可行的變通方案，那么不管修復缺陷代價有多大，優先級一定會是最高的，但是如果該缺陷存在比較簡單的變通方案，那么優先級就不一定會是最高的了。

● 根原因分析 ●

根原因分析就是我們平時常說的RCA，如果你能在發現缺陷的同時，定位出問題的根本原因，清楚地描述缺陷產生的原因并反饋給開發工程師，那么開發工程師修復缺陷的效率就會大幅提升，而且你的技術影響力也會被開發認可。

可以做好根原因分析的測試工程師，通常都具有開發背景，或者至少有較好的代碼閱讀以及代碼調試的能力。

所以做為測試工程師，你很有必要去深入學習一門高級語言，這將幫助你體系化地建立起編程思想和方法，這樣在之后的工作中，無論你是面對開發的代碼，還是自動化測試代碼和腳本都能做到得心應手，應對自如。

● 附件 ●

附件通常是為缺陷的存在提供必要的證據支持，常見的附件有界面截圖、測試用例日志、服務器端日志、GUI測試的執行視頻等。

對于那些很難用文字描述清楚的GUI界面布局的缺陷，你可以采用截圖并高亮顯示應該關注的區域的方式去提交缺陷報告。

● 總結 ●

缺陷報告是測試工程師與開發工程師交流溝通的重要橋梁，也是測試工程師日常工作的重要輸出。

一份高效的軟件缺陷報告，應該包括缺陷標題、缺陷概述、缺陷影響、環境配置、前置條件、缺陷重現步驟、期望結果和實際結果、優先級和嚴重程度、變通方案、根原因分析，以及附件這幾大部分。

缺陷報告的每一部分內容，都會因為目的、表現形式有各自的側重點，所以想要寫出一份高效的軟件缺陷報告，需要對其組成有深入的理解。

看到這里，想必你對缺陷測試報告有了更全面的認知，這里再送你一份松勤獨家的【缺陷報告模板】，工作效率提升UP、UP、UP~~~~

總結

以上是生活随笔為你收集整理的如何高效填写软件测试缺陷报告？（送缺陷报告模板）的全部內容，希望文章能夠幫你解決所遇到的問題。

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