如何编写正确的 Bug 报告

  • 孙镜涛

2014 年 7 月 3 日

话题:语言 & 开发架构

世界上没有完美的程序,只有不断完善的程序。虽然所有的程序员都不希望自己编写的程序存在 bug,但是程序员也是人,是人就难免会犯错误,所以任何复杂的程序都会出现或多或少的 BUG。BUG 是预期之外的瑕疵、错误或者缺陷。

当一个 bug 出现的时候,我们就需要编写 bug 报告并将其提交给相应的技术团队进行处理,一份格式良好、内容表述清晰的 bug 报告不仅能够帮助开发团队快速有效地处理 bug,同时还能够帮助文档编写者编写正确的勘误表 / 发布说明,帮助非技术人员、产品或程序经理了解 bug,有效减少开发人员和测试工程师之间的信息往返。

那么我们该如何编写 bug 报告?它有哪些关键要素呢?

伯乐在线上有一篇题为“如何写一份良好的缺陷(Bug)报告”的文章,该文章表示缺陷报告首先应该包含一个清晰的标题,不应该使用“应用崩溃”这种不包含足够信息的标题,标题应该包含错误消息和消息码,或者是结果的名称以及失败时你正在做的事情。bug 报告还应该包含你使用的软件的版本运行平台。接下来是描述,用简洁的语言概括出 Bug 出现时你正在做的事情。从上下文开始,一步一步的描述出 bug 是怎样出现的,错误信息是什么。最后还要在 bug 报告中包含你的预期结果,如果方便的话提供截屏或者程序崩溃日志,并附上自己的联系方式以便于让自己提交的 bug 报告及时得到答复,同时当开发团队不理解问题描述的时候还能询问你。

程序员 Simon Tatham 在“如何有效地报告 Bug”一文中表示:bug 报告的首要目的是让程序员亲眼看到错误。如果不能亲自做给他们看,那么就提供给他们能使程序出错的详细的操作步骤。详细的描述每一件事情:你看到了什么,你想看到什么,把错误消息记下来,尤其是“错误消息号”。如果程序员需要,还要准备好额外的信息,例如程序的版本号,它很可能是必需品。最好就是表述要清楚,确保你的意思不能被曲解,要做到精确,因为程序员喜欢精确。

kashyapc则在自己的博客文章“谈论 bug”中这样写道:bug 报告应该包含一个简明的概要,需要清楚地描述问题以及按时间顺序出现的症状,需要包含版本信息实际的结果期望结果,并且需要告诉相关人员如何重现bug。此外还需要告知测试环境的详细信息,因为很多“云”软件测试非常依赖于测试环境,更详细的信息能够减少 bug 在开发人员、测试工程师等人员之间的往返。如果需要任何特定的硬件,或者修改了任何内容(例如配置文件)也需要在 bug 报告中说明。最后在适当的情况下还需要提供额外的调查信息,例如你对问题的探索、相关的日志片段、_stderr_ 的脚本等。

你所在的组织或者团队是如何编写 bug 报告的呢?如果你们有一些好的经验想要和大家分享,那么就联系我们吧


感谢杨赛对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

语言 & 开发架构