如果大家刚刚开始接触bug追踪、问题管理以及Web开发等工作，那么bug报告绝对是各位避不开的一项任务。在今天的文章中，我们将尝试从多种视角回答这个问题。相信我，内容还是相当有趣的。
我们总在探讨bug报告……
……但却很少解释bug报告究竟是什么。
关于这个问题，我通过谷歌在Usersnap上找到1000多个相关结果，发布在博客上的博文也有183篇，其中涉及大量bug追踪工作中该做与不该做的内容。
然而，我们仍然没有回答最为核心的问题。不过关于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】
