2019-05-02 如何有效提交 Bug 报告？

花些时间，心里回想一下你电脑或手机上用的所有软件，有多少软件是付费的呢？50%？20%？0%？你可能像我一样，使用的多数软件都是免费的。我几乎是非开源软件不用的。我使用免费软件，但是这不代表软件就没有成本。我所用软件的每部分都投入了无数的开发工时。

无论免费与否，好的软件提高了生活质量，所以我们才会使用它们。那么我们能给这些为生活增值的开发者回报点什么呢？也许是一封感谢邮件？或者更好点，通过 PayPal 给开发者捐点款？成为软件的狂热粉，不停发 tweet 和 instagram 说它有多棒？

我认为支持喜爱软件的最好方式之一，是提交 bug 报告，关心软件的开发过程。所以下次遇到 bug 时，可以考虑采取更积极的方式，花点时间报 bug，而不是抱怨或把电脑扔到窗外。

什么是 bug？

每个用过软件的人都遇到过 bug。针对软件 bug，有人在 Wikipedia 的文章中写过：“软件 bug 是电脑程序或系统中，导致产生错误或意外结果、或非预期行为的 error、flaw、failure或 fault”。

多数情况下 bug 是一些小（或大）麻烦。有时 bug 很严重，会导致完全无法使用某些软件。在给 Lucid Software 做质量保证的最后一年，我意识到寻找和报告 bug 也不总是麻烦事；实际也可以很自主。我之所以相信每个人都应该报告 bug，是因为发现、报告 bug 可以让用户帮助改进他们每天使用的软件。

在开始报告错误之前，很乐意分享我的经验给大家做个引导，这样可以使报告 bug 有效，并增加 bug 实际修复的可能性。

如何报告 bug

Step 1：尝试重现 bug，确保它确实是个 bug，而不是用户或环境的 error。

可能看起来这很显然是第一步，但是我惊讶地发现，很多次自己本应在报告 bug 的阶段，然后半路试着重现 bug，却发现这是我这部分的用户错误或是环境问题。如果你不能重现找到的 bug，那么很有可能它实际不是个 bug。

Step 2：确认 bug 是否已报告过

一旦确定了你确实找到了个 bug，应该看看这个 bug 是否已经备案或上报了。对受欢迎的软件来说，很有可能你找到的 bug 已经上报过了。

除了直接在 Google 搜索你发现的 bug 外，还可以浏览所用软件的 bug 页面，看看这个 bug 是否已上报过。我们使用的多数软件都会有专门查找 bug 的页面。比如你在 Google 搜索“photoshop bugs”，出现的第一条链接就是 Adobe 的 bug 报告页面。如果有 bug 报告当然很好。你甚至可能在上面找到所遇 bug 的解决办法。如果没找到你的 bug，那就可以创建一条新的 bug 报告。

如果 bug 已上报，那么最好不要另外创建 bug 报告。但是可以浏览 bug 说明，留下附加的意见，或许能帮到开发者解决 bug。

Step 3：上报 bug（或在已有的 bug 报告上留言）

每个开发者都有体会：不是所有的 bug 报告都是一样的。好的 bug 报告增加了修复的可能性，而差的 bug 报告对每个相关人员来说都是浪费时间，并且可能会造成困惑和苦恼。

Bugzilla 有一份解析 bug 的详细清单，说明了 bug 报告中应包含的内容。我没有通读这些内容，但是可以分享下我个人认为有效 bug 报告应包含的内容清单。

• 具有描述性的标题
• 环境
• 预期响应
• 实际状态
• 重现步骤
• Bug 证明

注：下面的所有示例我都会列出一个实际的 bug，都是我使用 Google 的 Picasa 图片查看器（可惜现已停用）时频繁遇到。

具有描述性的标题

当搜索 bug 时（想想 step 2），你会输入什么单词？这些可能就是你的 bug 报告标题应该包含的单词，这样其他人就可能轻松地检索到这条 bug 报告。想想可能用到的同义词或短语，把这些词都写进标题中。避免使用像是“broken”或“not working”之类的模糊词语。是 bug 那肯定就是不好用了，要明确提及是如何不好用的。好的标题通常就足够修复 bug 了。

示例：Ubuntu 中的 Picasa 3.9 在点击“通过 Google 账户登录”时崩溃了。窗口关闭并且出现错误报告。

上例包含了 bug 环境并列出了发生的情况。“崩溃”和“窗口关闭”可能是同义的，纳入两个词是以防某些人只用一个短语搜素，而不是另一个。可能你不希望标题语句太长，但是还是描述性强点的好，这样 bug 是什么就一目了然了。

环境

通常 bug 只会在特定的环境下发生，所以环境描述越具体越好。确保列出所用的操作系统或浏览器，可以的话还有软件的版本和所用的硬件。如果条件允许，可以帮开发者在不同环境进行测试，验证 bug 是否在不同环境下都会出现。

示例：Ubuntu-Gnome 16.04.1 版本。在 PlayOnLinux 运行 Picasa

这里我明确了不是在 Windows 上面运行软件的。

预期响应

写 bug 是什么之前，先写下你所预期的行为很有用。如果只写了 bug，读者可能不清楚你是在描述 bug 还是预期响应。Bug 通常是“features”，有时可能是见解不同。除非清楚什么不是 bug，否则永远也不清楚什么是 bug。

示例：当点击“通过 Google 账户登录”链接时，应该打开一个可以让我登录的窗口。

实际状态

这是 bug 报告的重点，也通常是人们报 bug 时写下的唯一内容。它通常与之前写的预期响应相反的。写 bug 时，记得避免使用“broken”、“not working”之类的模糊词语。像雨果一样注重细节。读者可以快速浏览细节，但是没有写的内容就无能为力了。如果有很多东西都不像你预料的那样起效，可以考虑创建多个 bug（或是一个有子 bug 的父 bug）。

示例：当点击“通过 Google 账户登录”链接时，窗口关闭了，然后得重新打开 Picasa。并会收到错误报告说 PlayOnLinux 崩溃了。

重现步骤

如果一定要选出一项所有 bug 报告都应具备的，那就是重现步骤了。一步步地列出如何重现 bug 会让其它事情也清晰起来。列出重现 bug 的步骤能够更清晰你所使用的环境，所预期的响应以及实际发生的状况。在我看来，如果你没找到不断重现 bug 的方法，那么你实际并不是发现了 bug；只是发现了用户的错误操作。每一步都应该记录下来，这样所有人都可以轻松地重现你遇到的 bug 了。

示例

1. 在 Playonlinux 中双击 Picasa 图标打开 Picasa

2.在 Picasa 窗口右上角点击“通过 Google 账户登录”链接。

3.Picasa 主窗口关闭并且出现错误信息。

Bug 的证明或示范

我喜欢记录 bug 的证明，这样可以：1）要求我能够不断重现 bug。2）证明这真的是个 bug，而不是测试者的错误。3）展示清晰的情景以便开发者查看发生了什么。通常标有注释的截图就足够了，但是有用户输入或交互的情况下，我喜欢用 gif 展示全过程。我会尽力将 gif 控制在 30 秒之内。如果不能的话，我会练习重建 bug 直到可以更快地重现，或者将这个 gif 分为多个 gif。

示例：

image

帮助记录 gif 截屏视频的免费程序比较少。其中我最喜欢的软件是 ShareX（可惜的是只能在 Windows 下使用）。Linux 用户可以用 Peek。LiceCap 在 Windows 和 MacOS 下很好用，也可以通过 Wine 在 Linux 下使用。

报告 bug 时记住：bug 报告很可能不是给自己看的。注意可能的受众对象，比如：项目新成员、实习生、测试员、网上和你遇到相同问题的人等等。

报 bug 的额外建议：

• 报 bug 前找找已有的 bug 报告。
• 提交前校对 bug 报告。错误的语法或词语会令人困惑、沮丧。
• 尽可能多地提供相关信息。包括错误日志和 URL。
• 报 bug 前找找已有的 bug 报告。
• 尽可能的具体、简洁（但不能省略相关细节）。
• 如果你觉得是环境的问题，那么在不同环境中测试一下。
• 报 bug 前找找已有的 bug 报告。
• 避免主观意向。除非你提交的是功能需求，否则应该忠于事实，省略如果你是开发者会如何制作软件等内容。
• 报 bug 前找找已有的 bug 报告。对开发者或产品经理来说，看到重复的 bug 报告是很烦的，就像在这个列表上看到重复的要点一样。

Step 4：积极跟进

如果真的想某个 bug 得到解决，最好是跟进 bug 报告的状态（但是方式要友好、积极）。归档 bug 报告后，或在报告中，可以给开发者写段说明，表达你乐于帮助修复 bug 的想法。一种友好的方式是给开发者写些鼓励的话，表达你对软件的欣赏。还可以帮助在不同环境进行测试，甚至测试软件的 beta 版本。

与觉得被骚扰的开发者相比，感到工作被认可的开发者修复 bug 的可能性更大。写 bug 报告、跟进状态时要记住这句话。

大家都应该报告 bug 的原因

就像前面说的，报告 bug 让你可以作为用户去帮助改进软件；这可能是帮助改进软件的非开发者能做的最好的事情之一了。就是在 Lucid 任职之前，我也经常会给开发者发邮件提 bug。我总是会被收到的回复惊喜到。通常我都会受到回信，并且最终开发者会修复我的 bug，或者与我解释不会（或无法）修复的原因。

坐等修复 bug 的人最后很有可能会失望。报告 bug 的人展现了他们足够关心，也支持产品可能的最好成果。所以下次使用软件遇到 bug 时，投入点精力上报 bug 吧。积极点不仅长此以往对你有好处，也会让使用软件的所有人受益，最终 IT 界会变得更好。