世界上没有完美的程序,只有不断完善的程序。虽然所有的程序员都不希望自己编写的程序存在 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 )关注我们,并与我们的编辑和其他读者朋友交流。
评论