一、前言

Bug報告是測試的重點，無論是口頭的還是書面的，都是測試最明顯的結果。

報告的質量可能是決定測試人員可信度的最重要的因素，一份好的Bug報告不僅可以體現測試人員的專業度，還可以方便開發人員或其他相關人員快速獲取Bug相關信息，有助於對Bug的重要程度進行評估和快速修復。

二、什麼是bug？

通俗意義上講，Bug就是影響產品正常使用或者友好使用，且對產品價值產生影響的缺陷。

Bug可以分為兩種：正常Bug和增強需求型Bug。

正常的Bug指的是產品未能實現自身功能；而增強需求型Bug是當你認為需求本身應該改進或優化時產生的問題。

換句話說，「產品沒有按照你的期望運行」是一個常見的Bug「，產品已經實現了你需求的功能，但是你覺得可以有更好的實現方式時，這就產生了增強需求型Bug。

舉個例子：

假設有一個web應用，點擊按鈕無響應，那麼這是一個正常Bug；

假如點擊按鈕有響應，但是按鈕圖標或形式你覺得可以更好時，這個時候你提出的Bug可以被稱作增強需求型Bug。

三、什麼是bug報告？

Bug報告是對可疑錯誤的描述。

最基本的Bug報告是這樣的陳述:「我認為產品可能存在一些問題。」在現實生活中，這可以表現為簡單地指著屏幕說:「哦，快看，那是個Bug。」

事實上，當你在為站在你身邊的朋友進行測試時，你所需要做的就是讓他們知道你的產品應該是什麼、應該做什麼。如果我們都是親密的朋友，或者我們有相同的認識，那麼Bug報告就會非常容易。

Bug報告可以是正式的或非正式的、書面的或口頭的。即使是最簡單的Bug報告，其基礎也是具有以下四個元素：

描述你所感知到的問題

你在測試過程中遇到了什麼問題，具體一點、說清楚一點。問問你自己，這是否是問題的根源，或者這是否是最終的問題，更或者是否有更大、更基本的問題存在。例如：你可以描述「我在點擊這個按鈕的時候無響應「。

你是如何遇到這個問題的

你所感知到的Bug該基於對產品本身的直接觀察。詳細說明你使用的步驟和數據。

例如：在什麼步驟輸入什麼樣的數據產生的這個Bug，這是一個偶現的Bug還是一個頻發的Bug，你有截屏或視頻嗎，你使用的數據是什麼，什麼文件，你到底輸入了什麼?

為什麼是一個問題

說明你識別問題的方法，可以是需求文檔，也可以是一些標準規範等。

例如：問題現象與需求不一致——功能Bug，或問題出現時資源消耗過大——性能Bug。

為什麼這是個重要的問題

你的客戶可能需要知道：這是一個大Bug還是一個小Bug？你應該準備好說明Bug可能有多重要，而重要性與它被發現的可能性以及它發生時可能造成的損害程度有關。

例如：你可以描述「這是個嚴重Bug，等級為L1，因為這個Bug的出現導致系統卡死無法正常運行」。

四、Bug報告中的關鍵內容

以下是正式Bug報告中最常見的欄位：

標題

描述Bug本質的簡短總結：

長度不宜過長

一般來說，標題以不超過12個字為佳。

標題具有獨特性

每個Bug標題都能與其他標題相區分。例如，不要寫「產品崩潰」這種通用性標題。

描述

任何關於特定故障模式和行為的其他信息：

描述儘量保持簡短

給出有關Bug的合理細節，但不要包含團隊中每個人都肯定知道的信息。如果問題很明顯，例如「公司名稱在主頁上拼錯了」，那麼你幾乎不需要寫描述。

描述儘量專業

不要在一個Bug報告中涉及多個問題。

非多個問題可能是產品中一個潛在故障的症狀，否則應該將它們劃分為不同的錯誤報告。這是因為開發人員很容易因為修復一個問題，而不小心忘記修復同一報告中列出的其他問題。

儘量描述重要的步驟

不要提供那些顯而易見的步驟，例如:

1.連接到Internet；

2.啟動瀏覽器。

描述你認為是Bug的原因

這意味著要說明你為什麼認為這是一個Bug，除非這很明顯。不要說「產品不應該崩潰」這樣的模糊不清的蠢話。這種描述毫無意義。

可以添加一點你知道的Bug的解決方法。

版本

注意附上你測試的版本信息。

注意：如果同一個Bug在多個版本中出現，將該Bug連結到最重要的版本。

例如：Bug A在開發版本Develop V1和發布版本Release V2中同時出現，請在描述中版本信息寫明Release V2。因為使用重要版本信息，可以極大地引起開發人員和管理人員對此Bug的關注。

環境

你測試的平台。例如：硬體、瀏覽器和作業系統等信息。

附件

能夠幫助理解和分析Bug的一些日誌、屏幕截圖、錄屏等。

除了上述基本欄位之外，Bug跟蹤系統（如jira）可能還有其他欄位。它將自動填充ID、Reporter和Date Reported欄位，以及狀態、嚴重性和優先級等。

五、如何判定一個Bug的重要性？

測試人員是判斷Bug「有多大」的第一個人。對於負責任的測試人員來說，這是你工作中非常重要的一部分。

那麼如何判定一個Bug的重要性呢？你可以參考這幾個方面：

Bug出現的頻率

在其他條件相同的情況下，一個經常被很多用戶看到的Bug將變得更加重要。是否有很多不同類型的事件可以觸發這個Bug？它是否極易受到觸發事件的影響？當它出現的時候有多明顯?

當它發生的時候會造成多大的損失

雖然對於哪些具體症狀構成「更嚴重的損害」沒有嚴格的規則，但請嘗試可視化問題，然後考慮受影響的用戶的重要性。

最重要的錯誤通常是那些阻礙項目本身的錯誤：就是所謂的阻塞錯誤，這些是妨礙你進行測試或者用戶正常使用的Bug。

例如」軟體崩潰不能正常使用「，此類現象的Bug可以稱為最重要的Bug，其次是會對用戶使用造成某些影響但不至於無法使用的Bug。

Bug具有潛在的其他風險

Bug可能特別重要，因為它意味著開發過程本身存在一個大問題，可能導致許多類似的Bug還沒有被發現。

Bug會給產品帶來什麼樣的負面影響

雖然一些Bug在客觀上沒有那麼嚴重，例如：並沒有阻礙產品的正常使用。但是，它會影響用戶對產品的好感度和信任度，那麼這個時候它也是一個嚴重Bug。

六、舉個例子

以jira工具為例，報告一個並發請求導致系統崩潰的Bug。關鍵信息如下圖1所示。

jira默認包含了版本、環境、優先級等信息供用戶選擇，因此在描述部分可以只關注於對Bug本身信息的描述，如：復現頻率、復現步驟等。

在復現步驟中，採用了Given——When——Then的描述方式，可以使得描述更加簡潔和具有邏輯性，推薦大家使用。

七、總結

本文主要是向大家介紹了在報告Bug時需要關注的一些重點和細節，希望能為大家帶來幫助。

一份好的Bug報告，可以讓我們測試人員顯得更為專業，也可以縮短開發人員排查Bug和修復Bug的時間，幸福你我他。希望對大家有所啟發~

怎麼寫軟體測試Bug報告？