如何简洁而有效地描述一个缺陷（Bug）？

只看该作者 · 2024-1-31 12:05

在日常工作中，软件和硬件工程师（Bug修复者）经常会碰到各种Bug，但很多时候我们的精力都浪费在了和测试人员（Bug提交者）反复沟通上，因为我们搞不懂测试人员想要表达啥？

当你的软件或硬件出现不符合预期的问题时，我们希望它能够尽快修复，而不希望时间浪费在无效沟通上。

作为软件或硬件开发者，我们以工作为荣，但就像开发的任何方面一样，沟通至关重要。描述出了什么问题可能有些困难，但如果你能在一开始提供一个详尽的问题描述，这会加快问题的解决。

行业内对于如何描述Bug有各种思考，本文的三句话法是其中一种。下面的Bug模板用三句话来描述一个Bug：

三句话模板

期望的结果模板：我预期 [这会发生] 是因为 [这些原因] 。

实际结果模板：然而 [发生了这种情况] ，我看到了 [具体的错误消息] ，我已经附上了截图。

1、复现步骤

说明你是如何遇到错误或问题的，即使对你来说似乎很明显（对别人不明显）。

为什么提供重现错误的步骤很重要？

如何提供重现错误的步骤？

2、你期望发生什么？

解释在按照第一部分中概述的步骤后，你期望发生什么。有时候测试人员在描述期望的结果时会觉得这很傻，但这是有必要的，请相信我！

为什么需要期望的结果？

很多时候，一个缺陷实际上并不是一个编程缺陷；也许这是一个被误解的规范，或者这个功能设计得很差，或者导致了意外的行为（例如，你期望在编辑产品描述后点击“保存”将带你进入产品页面，但实际上你返回到了首页）。
如果事实上并不是一个编程缺陷，这并不意味着这不是一个有效的缺陷报告！这只是意味着我们将以不同的方式解决这个问题，而我们能够快速进行分类，我们就能更快地修复它。

如何描述期望结果？

使用简洁而有意义的语言：“我希望看到匹配我的搜索的所有用户列表”可能听起来已经足够了，但“当我搜索‘sam’时，我期望在用户列表中看到‘Brian Samson’，但没有看到”，后一个描述更好，因为程序员是人不是机器人。
写上你为什么需要期望的结果？目的是啥？
不太好的描述：“我希望在查看‘active’用户时看到Janet的资料。”
比较好的描述：“我希望在查看‘active’用户时看到Janet的资料，因为她已经完成培训，我期望她被视为‘active’。”
最好的描述：“我希望在查看‘active’用户时看到Janet的资料，因为作为已经完成培训的人，我期望她被认为是‘active’。”

3、实际结果

为什么修复人员想要更多的细节？

在缺陷报告的第一部分，你描述了复现缺陷的步骤；在第二部分，你描述了你认为应该发生的情况；对于这最后一部分，我们想要了解实际发生的事情的具体细节：缺陷本身。
提供的细节越多，我们就能更好地确定缺陷的真实性质：是用户体验不清晰？是数据问题？用户错误？代码中的错误？我们能够快速进行错误分类，就能更快地进行修复。
这一部分还帮助修复者确定问题的范围，以及它是否特定于某个设备（如Android或iPhone）、浏览器（如Firefox或Chrome）或操作系统（如Windows或Mac）。

如何简洁而有效的描述实际结果？

包括：屏幕截图、URL或URL（如果错误发生在网站上）、确切的错误消息或消息（如果有的话）、你使用的设备/浏览器/操作系统，甚至可能是一天中的时间或星期几。
尽可能具体和详细。你不太可能提供过多的信息，一般都是过少了。
不太好的例子：“当我点击‘create’时，什么都没发生。”
更好的例子：“当我点击‘create’时，它没有起作用，并显示了一个错误消息。”
最佳例子：“当我点击‘create’时，它重新加载到‘new account’页面，并在页面顶部以红色显示此错误‘error saving Entity#{User}：在第32行发生数据库连接故障’。我附上了显示错误的屏幕截图。”

总结

缺陷报告模板如下：

重现步骤：

期望结果：

我期望这会为 Marta 创建一个新账户，并将我重定向到账户页面，页面顶部显示成功创建她的账户的通知，因为她的电子邮件尚未与当前账户关联，因此应该是一个全新的账户。

实际结果：

相反，它重新加载了“New Account”页面，并在页面顶部以红色显示此错误：“Your account could not be created。”