如何有效提交 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。

示例:

帮助记录 gif 截屏视频的免费程序比较少。其中我最喜欢的软件是 ShareX(可惜的是只能在 Windows 下使用)。Linux 用户可以用 PeekLiceCap 在 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 界会变得更好。

打赏支持我翻译更多好文章,谢谢!

打赏译者

打赏支持我翻译更多好文章,谢谢!

任选一种支付方式

1 3 收藏 3 评论

关于作者:古鲁伊

立志做一名有格调的程序媛 个人主页 · 我的文章 · 34

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部