An Upper Bound on the Probability That a User Encounters an Undiscovered Defect

伟大的找虫行动：为什么仅仅计数是不够的

想象你是一位正准备为数千名宾客提供巨型宴会的厨师。在开门迎客之前，你有一支品鉴员团队（你的测试人员），他们一直在品尝食物并大声喊道：“嘿，这汤太咸了！”或者“这蛋糕里有一块石头！”你修复了他们发现的问题。但这里有一个可怕的问题：如果你现在开门，一个随机走进来的宾客咬到你漏掉的石头的概率是多少？

这就是计算机科学中被称为“软件可靠性”的核心问题。几十年来，开发人员一直试图通过计数来回答这个问题。他们问：“厨房里还剩多少块石头？”他们使用复杂的数学来猜测隐藏缺陷的总数。但问题在于：知道还剩“十块”石头并不能告诉你这些石头是在储藏室的角落里（可能只有一个人会发现），还是有一块巨大的巨石就摆在正门口（每个人都会被它绊倒）。旧的方法往往纠结于如何数清石头的数量，却忽略了有些石头因为它们所处的“位置”而变得更加危险。

为了解决这个问题，我们需要停止数石头，开始数“人”。我们需要知道一个随机用户遇到问题的概率。这篇论文正是针对这一问题展开讨论的：它不再问“还剩多少个缺陷？”，而是问“用户遇到一个从未见过的缺陷的概率是多少？”事实证明，有一个非常简单的方法可以预测这一点，那就是观察测试人员重复发现同一个缺陷的频率。

---

论文的核心思想：“一次性奇迹”法则

作者卡洛斯·M·埃尔南德斯-苏亚雷斯（Carlos M. Hernández-Suárez）和卡拉·埃尔南德斯-库埃瓦斯（Karla Hernández-Cuevas）提出了一个聪明的捷径。他们建议，要预测用户撞上隐藏缺陷的风险，你不需要知道缺陷的总数、软件是如何构建的，甚至不需要知道有多少人在使用它。你只需要观察你的错误报告，并统计一件非常具体的事情：那些被恰好报告了一次的缺陷。

让我们用一个类比。想象你是一名侦探，试图弄清楚有多少种不同的外星物种正在造访你的小镇。你有一本观测日志。

• 如果你看到“佐格（Zog）”出现了 50 次，你知道佐格是一种常见的外星人。
• 如果你看到“希尔（Xyl）”出现了 3 次，希尔稍微罕见一点。
• 但如果你恰好只看到过一次“布洛普（Blorp）”，且再也没见过它，这说明了什么？

论文认为，这些“布洛普”——即被观察到仅一次的缺陷——才是关键。他们将这些单次观测次数（$s$）与总观测次数（$n$）的比值称为“保守上界”。用通俗的话说：那些被报告了恰好一次的缺陷所占的百分比，是对于用户撞上一个全新的、未见过的缺陷之比例的一个安全、“最坏情况”的猜测。

为什么这行得通（“闭门逻辑”）

你可能会怀疑：“如果缺陷隐藏在其他缺陷后面怎么办？就像锁着的门后面有一个秘密房间一样？”作者通过一段精妙的逻辑解决了这个问题。

想象软件是一座拥有许多房间的大豪宅。有些缺陷在走廊里（容易找到）。有些缺陷在锁着的门后的秘密房间里（难以找到）。

• 如果用户撞到了那扇锁着的门（一个缺陷），他们就无法进入它后面的秘密房间。
• 因此，能够到达秘密房间的人数，总是小于或等于撞到锁门的人数。

作者证明，由于这种“嵌套”结构，你不需要担心那些隐藏的房间。你确实发现的那些“单次报告”的缺陷，已经涵盖了隐藏缺陷带来的风险。如果一个缺陷被报告了一次，它就像一扇“门”，限制了其背后所有东西的风险。因此，统计单次报告的数量足以覆盖整个房子。

他们的做法与发现

作者不仅仅是在猜测；他们建立了一个名为“规范形式”（Canonical Form）的数学模型（可以把它想象成一个装满了彩色球的特殊瓮或罐子）。他们从数学上证明了，如果你把错误报告看作是从这个罐子里抽球，那么出现次数仅为一次的球的比例（$s/n$）就是“缺失质量”（即未见的缺陷）的最大似然估计。

至关重要的是，他们证明了这种估计是保守的。这意味着它倾向于高估风险，而不是低估风险。

• 为什么这很好： 如果你是一名决定是否发布软件的开发人员，你会希望保持安全。如果数学计算说“有 5% 的概率出现缺陷”，而实际概率是 3%，你是安全的。如果数学计算说是 3%，而实际概率是 5%，那你就会陷入麻烦。这种方法确保你始终站在谨慎的一方，倾向于采取预防措施。

他们使用计算机模拟（创建了已知答案的虚构缺陷群体）测试了这个想法。

• 在一个拥有 20 个缺陷的测试中，他们发现随着他们“测试”的用户增多（样本量从 25 增加到 400），他们的估计值（$s/n$）始终大于或等于真实的未见缺陷数量。
• 例如，在 100 个测试用户的情况下，真实的未见风险是 0.0059，而他们的估计值是 0.0063。估计值略高于实际值（保守），但从未低于实际值。

这不是什么（游戏规则）

论文非常明确地说明了这种方法不能做什么，准确理解这一点很重要：

1. 它不是用来计数缺陷的。 它不会告诉你“还剩 50 个缺陷”。它告诉你是“有 2% 的概率用户会撞上一个缺陷”。
2. 它不是用于公开的缺陷列表。 作者明确排除在标准的缺陷数据库（如互联网上的数据库）上使用此方法。为什么？因为在那些列表中，一个缺陷通常由一个人报告一次，即使有 1,000 人发现了它。在这种情况下，“计数”信息丢失了。要使用这种方法，你需要的数据必须说明：“这个缺陷被 50 个不同的用户触发了”，而不仅仅是“这个缺陷被报告了”。
3. 它不是预测未来的魔力水晶球。 它提供的是“此时此刻”的风险快照。如果你修复了缺陷并重新测试，你必须重新计算。

总结

这篇论文为发布决策提供了一个直接、务实的答案。它说：“不要担心有多少缺陷躲在黑暗中。只需看看你的测试人员恰好发现了多少次单次出现的缺陷。那个数字除以你的总测试次数，就是你对漏掉的缺陷可能导致用户受阻的风险的一个安全、上限估计。”

这是一个将复杂的、令人恐惧的不确定性转化为一个简单的、安全数字的工具，确保当软件交付时，开发人员对用户面临的风险有一个清晰且保守的认知。