开发者反思：基于属性的测试工具真能高效找 Bug 吗

“发现 Bug 有害吗？”——这个问题我已经琢磨了一周，期间还在顺手开发一个新的基于属性的测试（PBT）工具，如果你懂得欣赏反讽的话。如你所知，标题带问号通常意味着答案是否定的；但我没想到在这个领域干了 6 年之后，自己会站到能问出这个问题的位置上，所以觉得值得讨论一下。不过让我先退一步说说背景。

基于属性的测试（PBT）是一种“高级”的软件测试方法；我们不再像经典做法那样测试某个具体行为，而是定义一个“蓝图”，传统上称为属性（property）。属性是关于被测系统的一个普遍事实，比如“用任意输入运行这个程序都不应导致崩溃”、“任意两个数相加都应满足交换律”，或者“我的物理模拟应始终守恒动量”。我们可以很容易地通过编写从状态或输入到布尔值的函数来表达这些属性；然后通过在这些函数输入所定义的输入空间中随机采样来进行测试。

测试研究者的工作，嗯，就是发现 bug、定位根因，并从本质上帮助维护者修复这些 bug。当然，这些只是我们的工作方式，而不是价值主张；在我看来，测试研究的价值主张是帮助构建可靠的软件系统。PBT 只是这里的其中一种方法，fuzzing、确定性模拟测试、形式化验证……都服务于同一目的，只是在不同的情境和领域中有不同的权衡。

测试研究的一个关键张力在于测试者与维护者之间的分离，测试者总是从外部接近系统，作为与维护者相分离的实体。测试者对系统的理解既不如维护者深入，也没有动力或能力做到那样。我认为随着 AI 时代的到来，这种张力正达到一个临界点，我很想弄清楚我们现在处于什么位置。

上个月我显然提交了 500 多个 bug 报告。老实说，我挺自豪的；在经过充分测试的系统中发现新 bug 是测试研究者的梦想。这就像运动员打破世界纪录，至少是一个更书呆子气、也远没那么令人印象深刻的版本。提交 bug 时我尽量表现得很有分寸，我没有让 agent 一股脑儿全部提交，而是尽可能亲自做了分类；但我无法摆脱这种感觉：如果数十亿用户都没碰到过这些情况，也许它们本来就没那么重要。

我可能要为 Postgres19 的延期负部分责任，这一事实相当令人不安；虽然“fuzzer 疲劳”的概念并不新鲜，Z3 prover 曾是 fuzzer 的热门目标，当时引发了一些激烈的讨论，SQLite 的维护者以惊人的速度修复一些 bug，有时 literally 20 分钟就能搞定，但我确信他们无疑已经精疲力竭了。

支持发现 bug 的最有力的单一论据是安全性：如果我们不发现这些 bug，攻击者就会发现，并会用它们做坏事；这对经典 fuzzing 尤其奏效。但特别是结合我参与的一些较新工作——我们测试系统的功能正确性属性——我认为价值主张发生了转变。

别误会，bug 就是 bug，在我提交的所有 bug 报告中，只有一次我们与维护者讨论过该行为是否真的是 bug；问题更实际：即使没有任何实际用户会因为这个问​​题而遭遇体验下降，是否值得修复软件中的所有 bug？

更进一步：是否值得花费宝贵的维护者时间，去修复一个十年来从未有人触发的旧 bug，而不是用来构建用户真正会使用的新能力？

我得出的结论——这对我自己在现有系统中寻找旧 bug 的努力来说可谓一种诅咒——是：测试在与开发携手并进时最有价值。事后测试对于安全漏洞和静默失败可能有价值；而且我们确实无法预知测试系统时会遇到什么类型的 bug，所以存疑时，我们必须测试。然而，我们应该对提交的 bug 有所选择；更进一步，维护者应该对他们选择修复的 bug 有所选择。那种我们必须修复每一个 bug 的意识形态立场，在目前看来对我并不可行。

我得出这个结论，是基于 bug 识别与 bug 解决之间的不对称性。我之所以能手动处理 500 多个 bug，是因为 bug 是相当容易验证的。给定一小段代码，我可以审查这段代码、预期行为和实际行为；并以很高的置信度向维护者提交报告。这些简单片段的修复不仅可能从一行到数百行不等，而且对于给定的 bug 存在许多可能的修复方式。有时会讨论软件中的 bug 数量是有限还是无限的，我认为这是个错误的问题。我相信对于给定的软件，要修复所有违反给定属性的 bug，存在一个有限的修复集合，然而我们实际应用的修复不太可能是那些。因此，如果采取贪心策略——对我们当前检查的测试用例的邻域内所有 bug 应用“最简单”的修复——我们实际上可能生活在一个不得不进行无限多次 bug 修复的世界里。因此，修复必须是精心设计的、向前看的，并且本质上远比 bug 本身难以验证。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）