如何编写正确的Bug报告

世界上没有完美的程序，只有不断完善的程序。虽然所有的程序员都不希望自己编写的程序存在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中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。