What Makes Software Bugs Escape Testing? Evidence from a Large-Scale Empirical Study
这项针对 C/C++ 和 Java 系统中超过 14,000 个缺陷的大规模实证研究表明，发布后的缺陷主要由旧有且频繁修改组件中的演化与流程动态所驱动，而非单纯由代码结构决定，这表明可靠性工作应优先针对这些成熟且高变更区域开展定向测试。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象你是一名侦探，试图解开一个谜团：为什么有些软件漏洞会溜过安全卫士（测试人员）的视线，直到软件向公众发布后才暴露出来？
以往的大多数研究都集中在守卫们在“大门开启前”抓获的漏洞上。本文认为，这就像只研究那些在机场被抓获的罪犯，而忽略了那些成功潜逃的人。为了理解这些“逃脱艺术家”，研究人员建立了一个包含超过 14,000 个来自现实世界 C/C++ 和 Java 软件漏洞的巨大数据库。他们比较了“被抓获”的漏洞（发布前）与“逃脱”的漏洞（发布后），以观察它们有何不同。
以下是他们的发现，通过简单的类比进行解释：
1. 关键不在于代码的“长相”，而在于它的“历史”
想象两座房子。
- A 房是一座崭新的、简单的小棚屋。
- B 房是一座古老的大宅，由 20 位不同的承包商翻新了 50 次，其中一些墙壁被拆除，另一些则被加建。
研究人员发现，那些逃过测试的漏洞通常并不藏在“简单的小棚屋”（复杂、混乱的代码）里。相反，它们几乎总是藏在**“古老的大宅”**（那些被频繁修改的旧代码）中。
- 类比：把代码想象成一条繁忙的高速公路。那些逃脱的漏洞通常不在崭新、空旷的车道上。它们位于老旧、车流量巨大的车道上，施工队在那里工作了数年，不断更改标志和路面。一段代码被修改的次数越多、历史越久远、经手的人越多，那里就越可能藏着一个“幽灵漏洞”，等待特定的交通模式来触发它。
2. “逃脱艺术家”更难被抓获（也更难修复）
当一个漏洞在发布前（测试阶段）被发现时，通常就像在草稿中发现了一个拼写错误。你可以迅速修复它，然后它就消失了。
但当漏洞逃脱并在发布后出现时，就像在桥梁中发现了一道结构性裂缝，只有当一辆特定的重型卡车在一天中的特定时间驶过时才会显现。
- 发现：在 C/C++（用于操作系统和游戏引擎等系统的语言）中，修复这些逃脱的漏洞所需的时间要长得多，且需要更复杂的更改，远超修复发布前漏洞的工作量。
- 类比：修复发布前的漏洞就像更换厨房里的碎瓷砖。而在 C/C++ 中修复发布后的漏洞，则像是在大楼里还有人居住的情况下，试图更换承重梁。这需要更多的时间、更高的技能以及更周密的计划。
- Java 的差异：有趣的是，在 Java（常用于商业应用）中，修复时间的差异并没有那么大。这就像 Java 中的“大楼”更容易维修，也许是因为其工具和安全网（如自动内存管理）使得这项工作比在 C/C++ 中不那么危险和混乱。
3. “团队规模”不变，但“脑力”变了
你可能会认为，修复一个可怕的、逃脱的漏洞需要一大群人来解决。但研究人员发现事实并非如此。
- 发现：无论是早期还是晚期被发现的漏洞，参与修复的人数大致相同。
- 类比：无论你是修理漏水的龙头（发布前）还是地下室爆裂的管道（发布后），你仍然只需要一两个水管工。区别不在于你需要更多的人；而在于对于同样的人选来说，这项工作本身更困难、耗时更长。那些“逃脱”的漏洞只是更加令人困惑，更难诊断。
4. 代码的“气质”发生了变化
研究人员利用数学方法分析了代码的“个性”。
- 发现：在发布前，代码的“个性”（其大小、复杂度和结构）相当可预测。但对于逃脱的漏洞，代码则呈现出一种混乱、混杂的个性。
- 类比：想象一个图书馆。
- 发布前的漏洞出现在书籍按大小和颜色整齐排列的区域。
- 发布后的漏洞则出现在那些书籍被翻乱、堆叠在一起、并在多年间被许多人移动过的区域。是历史的“混乱”隐藏了漏洞，而不是书籍本身的大小。
结论
本文总结道，我们不应仅仅通过观察一段代码当前的“复杂程度”来寻找漏洞。相反，我们需要关注它的历史。
如果一段代码很旧、被频繁修改，并且被许多不同的人触碰过，那么它就是那些会逃过测试的漏洞的首要藏身之处。为了抓住这些“逃脱艺术家”，测试人员需要将精力集中在代码中这些“古老、繁忙的街区”，而不仅仅是检查那些最新、看起来最复杂的部分。
简而言之：那些逃过测试的漏洞通常不是因为代码太难读懂而躲藏；它们躲藏是因为代码拥有一段漫长而混乱的历史，而测试人员未能完全模拟出这段历史。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。