如果大家剛剛開始接觸bug追蹤、問題管理以及Web開發等工作，那么bug報告絕對是各位避不開的一項任務。在今天的文章中，我們將嘗試從多種視角回答這個問題。相信我，內容還是相當有趣的。

我們總在探討bug報告……

……但卻很少解釋bug報告究竟是什么。

關于這個問題，我通過谷歌在Usersnap上找到1000多個相關結果，發布在博客上的博文也有183篇，其中涉及大量bug追蹤工作中該做與不該做的內容。

[[164690]]

然而，我們仍然沒有回答最為核心的問題。不過關于bug報告的各類議題仍然相當豐富，毫無疑問。

總而言之，我們今天終于開始進入正題了……畢竟是個好消息，對吧？

究竟什么是bug報告？

那么我們首先回答這個問題，“究竟什么是bug報告？”

為了找到答案，我們需要了解幾項相關概念，包括什么是bug、什么是bug報告以及bug報告軟件。

什么是bug？

在軟件開發、工程或者Web構建過程當中，bug指的不是那種小小的昆蟲，而是另一種完全不同的概念。

根據維基百科的說法，軟件bug（或者直接說‘bug’）被定義為：

“軟件bug是指存在于計算機程序或者系統當中的一種錯誤、缺陷、故障或者瑕疵，其會導致軟件出現不正確或者預期之外的運行結果，又或者以不同于既定設計的方式運作。”

簡而言之，這意味著：

軟件bug是一種錯誤、缺陷、故障或者瑕疵，可能造成不正確或者預期之外的運行結果。

基本上，軟件bug就是那種與設計思路不符的元素。

為什么要稱其為“bug”？——bug名稱的起源

大家可能好奇，為什么要將軟件錯誤稱為bug？這是個好問題，因為用“bug”一詞形容軟件錯誤或者故障的作法可以追溯到1945年。1945年年末，哈佛大學的一個技術團隊發現Relay70設備當中存在一些故障點。他們最終發現引發問題的是一些蟲子（bug）尸體。

而在bug定義條目所指出，“這是歷史上首例被記錄在案的bug。”

因此，從理論上講，bug就是與設計思路不符的元素。

不過，如果設計本身就存在問題，那么又該如何看待？這屬于bug嗎？如大家所見，這個問題的答案還有很多探討空間。

無論大家屬于開發者、設計師還是軟件用戶，想必在實際生活中都多少遇到過bug，甚至可能親手造成過bug。

什么是bug報告？

那么新的問題來了：什么是bug報告？

當bug出現時，人們會發現并將其報告（記錄為文檔并發送）給負責修復錯誤或者故障的技術團隊。

根據Yegor的說明，bug報告“應當解釋產品所出現的具體問題。”

他進一步補充稱，bug報告應當遵循以下這一基本模式：

“我遇到的情況是這樣的，我希望實際情況是那樣的，因此請加以修復。”

聽起來很簡單，對吧？然而實際情況并非如此——很多bug報告并沒能說清需要表達的內容。

想象一下，如果我們自己遇到了bug并需要發送報告，那么會在其中包含哪些信息？答案恐怕將因人而異。

過去，bug報告屬于冗長的表格，包含大量字段與數據請求。錯誤的優先級是什么？怎樣描述問題？由哪些部分組成？使用的是哪個版本的瀏覽器？等等……

好的bug報告與差的bug報告

那么bug報告肯定也是有好壞的——二者區別何在？為什么會有這么多糟糕的bug報告？

我收集到了與此相關的一些說法，幫助大家更明確地進行區分：

· 好的bug報告包含重現及修復問題的必要信息

· 差的bug報告不包含重現及修復問題的必要信息

· 好的bug報告能夠有效幫助bug報告者與bug接收者進行溝通

· 差的bug報告冗長且很難完成二者間的溝通

· 好的bug報告能夠盡快得到解決

· 差的bug報告根本得不到解決

· 好的bug報告會被直接發送至相關負責人

· 差的bug報告根本無法指向相關負責人

· 好的bug報告言簡意賅

· 差的報告缺少必要信息

· 好的bug報告符合提交規范

· 差的bug報告可能采取多種提交方式，但就是不符合既有規范（小提示：請盡量別用微博發送bug報告）

· 好的bug報告能夠確立協作共同點

· 差的bug報告無法實現協作

那么***，我們要匯總以上內容來回答今天的主題：“究竟什么是bug報告？”

所謂bug報告，需要存儲全部記錄、報告及修復軟件內或者網站上問題的信息。而且在理想場景下，其應盡可能以更為有效的方式實現。

總結陳詞

總而言之，我們已經了解了關于bug、bug報告以及bug報告系統的相關知識。不過這還僅僅是基礎，從有bug到無bug的道路仍然漫長而坎坷——同志們，加油！

原文鏈接：一篇好的BUG報告是如何煉成的

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】