如果大家刚刚开始接触bug追踪、问题管理以及Web开发等工作,那么bug报告绝对是各位避不开的一项任务。在今天的文章中,我们将尝试从多种视角回答这个问题。相信我,内容还是相当有趣的。


如果大家刚刚开始接触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报告是如何炼成的