使用 Bugmon 分析 Bugzilla 测试用例

作为 Mozilla 模糊测试团队的一员,我们的工作不仅是发现 bug,还要尽力帮助尽快解决这些 bug。我们可以通过以下几种方式来实现这一点:

  • 确认新 bug 或停滞 bug 的有效性
  • 确定 bug 是何时引入的
  • 验证提出的修复方案是否真的解决了问题

为了进一步减少修复 bug 的延迟,我们希望尽可能地自动化这个过程。这项努力最终导致了 Bugmon 的开发;这是一个直接在 Bugzilla 中自动化 Firefox 和 SpiderMonkey bug 的基本分类任务的工具。

Bugmon 分析是选择加入的,并且仅适用于具有测试用例的崩溃或断言 bug。如果您参与 Firefox 开发并希望 Bugmon 分析您的 bug,只需添加“bugmon”关键词即可。

模糊测试生命周期

模糊测试,从最基本的层面上来说,就是向应用程序提供随机数据,希望触发意外行为的过程。在 Mozilla 和我们这些对 Firefox 进行模糊测试的人看来,这些随机数据通常以 JavaScript、HTML、CSS 等形式出现,而我们寻找的意外行为通常以应用程序崩溃或致命断言的形式出现。

当我们识别出这些问题时,我们的第一步是通过 Bugzilla 中的 bug 通知维护有问题的代码的团队。当我们提交这些 bug 时,我们会尽可能地包含所有相关数据,例如:

  • 问题描述
  • 崩溃或断言的堆栈跟踪
  • 包含用于触发问题的随机数据的测试用例
  • 以及任何其他信息,例如测试的修订版、任何构建或运行时标志,以及任何所需的環境变量

有关最近示例,请查看 bug 1682612

许多人可能会认为,到此为止,我们的工作就完成了。bug 已提交给开发者,我们可以继续破坏更多代码。不幸的是,情况并非如此。

bug 的生命周期

在 bug 的生命周期中,我们可能需要提供更多信息的很多原因。通常,bug 的确切原因可能并不明确。此外,有问题的代码的所有者也可能不清楚。为了将 bug 交付给最适合修复它的人员手中,我们需要提供更多信息。

二分查找

我们可以利用的一种有用技术是 二分查找。二分查找是识别引入问题行为(即崩溃或断言)的特定变更集的过程。通过识别引入 bug 的变更集,我们很可能不仅可以确定导致 bug 的区域,还可以确定最后修改该代码的个人。这两点都有助于我们更快地修复 bug。

但是,如果 bug 的优先级很低,并且几周或几个月后开发者才有机会查看该 bug,会发生什么?

确认

在这种情况下,确定 bug 是否仍然存在通常很有帮助。为了回答这个问题,我们将尝试使用附加到 bug 的原始测试用例触发相同的问题。如果 bug 无法重现,则该 bug 很可能已经被修复。我们可以再次利用二分查找来识别导致修复我们 bug 的特定变更集。

验证

在这个阶段,bug 已经修复了。成功了!或者,至少看起来是成功了。我们必须验证原始测试用例不再触发问题行为。在这种情况下,我们将再次尝试使用原始测试用例触发相同的问题。如果 bug 无法重现,我们就可以安全地将 bug 标记为已验证。

在手动重复了许多这些任务之后,我们很快意识到,我们可以将大部分过程自动化,从而为负责修复 bug 的开发人员提供更多支持。

介绍 Bugmon

Bugmon 专为自动化许多这些基本分类任务而设计。它最初由 Christian Holler 在近 8 年前构思,名为 JSBugMon,用于分析影响 SpiderMonkey 的 bug;Bugmon 是对 Christian 工作的全面重新设计。这种新方法利用了模糊测试团队开发的几个其他工具,例如 autobisectfuzzfetchgrizzly,快速有效地将此概念应用于 SpiderMonkey 和 Firefox bug。

Bugmon 处理 bug 的演示。

工作原理™

Bugmon 将根据 bug 的当前状态执行多个自动化任务。

确认

  • 对于状态为已分配、新建、未确认或重新打开的 bug,Bugmon 将自动确认其可重现性。
  • 确认开放的 bug 也会被二分查找。
  • 如果无法使用最新可用版本确认 bug,Bugmon 将尝试使用与原始修订版匹配或最接近 bug 创建时间日期的版本确认 bug。如果成功,Bugmon 将尝试二分查找引入修复的变更集。

验证

  • 对于状态为已解决且解决方法为已修复的 bug,Bugmon 将自动确认 bug 已经修复。
  • Bugmon 还会迭代跟踪标志,并尝试验证每个标记为已修复的分支。

触发事件

有时,您可能希望触发在上述时间表之外执行的特定操作。这可能是因为原始测试用例不再重现,或者您认为 bug 的状态自上次 Bugmon 分析后可能已经发生变化。

除了自动解析功能外,还可以通过 bug 白板请求立即处理 bugmon 操作。

后续步骤

虽然 Bugmon 提供的信息在更快地修复 bug 方面无疑很有帮助,但我们仍然希望实现一些功能。

改进二分查找分析阶段可以让我们识别到单个代码更改级别的回归。在这种情况下,我们可以自动更新 相关的回归字段,这些字段随后可以被其他 Mozilla 机器人(如 autonag)利用。此外,我们可以自动请求之前识别出的代码更改作者进行审查,因为他们很可能是修复该问题的最佳人选。

最后,一个经常被请求的功能是包含对使用 rr 记录 bug 的支持。对于那些不熟悉 rr 的人来说,它是一个永恒的调试器,它允许我们记录应用程序故障并确定性地重放它们。结合 pernosco(一个基于 Web 的 rr 会话浏览器),我们可以立即将这些记录交付给开发者,而无需他们进行任何设置。因此,减少了与难以重现或间歇性 bug 相关的开销。

结语

我们真诚地希望 Bugmon 有助于减少分类新 bug 所需的时间,并有效地更快地修复 bug。如果您有 Bugmon 目前不支持的特定用例,我们很乐意听取您的意见。

关于 Jason Kratzer

更多 Jason Kratzer 的文章...


2 条评论

  1. Jeanderson Candido

    感谢您分享这篇精彩的文章!
    我的问题与以下句子有关:“如果您参与 Firefox 开发并希望 Bugmon 分析您的 bug,只需添加“bugmon”关键词即可。”

    那么这是一个可选工具吗?如果是,为什么不将其默认启用?

    提前感谢!

    2021 年 1 月 23 日 03:00

    1. Jason Kratzer

      是的,至少目前而言,Bugmon 分析是选择加入的。主要原因是 Bugmon 仍处于开发初期。在无法分析 bug 或仅满足部分 bug 要求的情况下,Bugmon 可能很吵闹。在我们能够改进诸如测试用例识别或可靠性检测等功能之前,我们将继续将 Bugmon 作为选择加入功能。

      2021 年 1 月 25 日 08:42

本文的评论已关闭。