二元覆盖率的错误做法

背景

在软件测试与程序分析领域，代码覆盖率（Coverage）是衡量测试充分性的核心指标。传统方法包括行覆盖率、分支覆盖率等，而二进制覆盖率（Binary Coverage）是模糊测试（Fuzzing）中常用的一种轻量级度量手段。模糊测试器通过跟踪哪些代码路径被执行，来指导输入变异，从而提高漏洞挖掘效率。然而，关于覆盖率的选择一直存在争议，部分从业者甚至提出了通过形式化验证来完全避免测试的替代方案。本文所引用的 Hacker News 讨论中的一组脚注，揭示了这些方法背后的现实与误区。

核心内容

原文以脚注形式呈现了四个关键观点，完整翻译如下：

1. 有些人会告诉你存在第三种选择，即“对你的程序进行形式化证明”。但他们在骗你。
   （对应原文脚注 1）

2. 实际上情况要更复杂一些；目前大多数模糊测试器实际上使用的是 N-gram 覆盖率（N-gram Coverage），即结合最近的 N 个分支来计算要设置的位图条目，以便暴露更多依赖于路径的信息。尽管有一些奇怪的覆盖率度量指标，但粗略来说它们仍然在记录“哪些代码被执行了”，因此这种区别没那么重要——而且如果你有某种记录分支历史的方法，通常也可以计算 N-gram 覆盖率。
   （对应原文脚注 2）

3. 事实上，如果你在使用 Windows 11，那么你以为正在运行的“裸机” Windows 内核实际上一直是作为虚拟化Guest运行的。这难道不是很酷吗？
   （对应原文脚注 3）

4. 没错，就是那个 Varnish——HTTP 缓存。
   （对应原文脚注 4）

关键要点

• 形式化验证并非万能替代品：声称形式化证明可以完全替代覆盖率测试的说法是不切实际的。形式化验证在大型软件工程中难以大规模应用，且可能遗漏实际运行中的复杂交互，因此不应被视为“第三种选项”来绕过覆盖率测试。
• 现代模糊测试已进化到 N-gram 覆盖率：传统二进制覆盖率只记录单个分支是否被覆盖，而 N-gram 覆盖率通过追踪最近 N 个分支的历史，能捕捉路径依赖信息，从而更高效地发现深层漏洞。但本质上，它依然属于代码命中记录的一种变体，与原始二进制覆盖率的区别并不本质。
• 覆盖率度量的核心始终是“代码被命中”：无论使用哪种奇异度量指标，其最终目的都是记录哪些代码被执行了。分支历史记录只是增强手段，并不改变覆盖率的本质。如果你有能力记录分支历史，自然也可以计算 N-gram 覆盖率。
• 操作系统层面的虚拟化现象：Windows 11 的内核实际上运行在虚拟化层之上（例如基于 Hyper-V 的 VBS 安全功能），这对于测试和覆盖率分析意味着系统底层行为可能比预想的更复杂，例如内核代码的实际执行路径可能受虚拟化监控器影响。
• 上下文中的 Varnish 指代：脚注中提及的“Varnish”是指著名的 HTTP 缓存加速器软件，常用于反向代理。这里用于举例说明某些讨论中涉及的具体项目。

意义与影响

这组脚注虽然简短，但揭示了软件测试领域几个重要现实：首先，形式化验证在实用主义视角下并非银弹，过度依赖它可能导致忽视实际测试手段的价值；其次，模糊测试覆盖率度量在不断演进，但核心逻辑仍是记录代码执行轨迹，从业者不必被各种“花哨”名词迷惑；第三，现代操作系统的虚拟化结构（如 Windows 11 的 VBS）会改变内核代码的运行环境，测试工具需要意识到这种底层差异；最后，技术讨论中引用具体项目（如 Varnish）时，应明确上下文以避免混淆。整体上，这组脚注提醒测试人员保持务实态度，既不要盲目追求形式化证明，也不要被覆盖率的表面复杂度误导，而应聚焦于有效发现 bug 的测试策略。