What is a "bug"? On subjectivity, epistemic power, and implications for software research

在软件研究和实践中，相当大的精力都花费在了处理bug上。发现、报告、跟踪、分类、尝试自动修复、检测“bug气味”——这些都占据了大型项目相当大的时间和开发成本，并且对于软件工程、编程语言等领域的研究人员具有重要的意义。但是，到底什么是bug呢？尽管分段错误很少会引起喜悦，但大多数bug并不是那么清晰明了。根据《牛津英语词典》，自至少19世纪70年代以来，“bug”一词一直是工程“缺陷”的俚语。大多数现代软件导向的定义都表明，开发人员的意图与程序实际执行的操作之间存在差异。从一开始，形式验证就已经开发出了识别与正式规范有偏差的方法，这些规范被期望更多或更少地编码所需的行为。然而，软件很少附带完整和正式的规范，这个意图被视为隐含的，最多只有部分记录。国际软件测试资格认证委员会写道：“人类可能会犯错误（失误），这会在程序代码或文档中产生一个缺陷（错误、bug）。如果代码中存在缺陷，则系统可能无法执行应该执行的操作（或执行不应该执行的操作），从而导致故障。缺陷可能导致故障，但并非所有缺陷都会导致故障。”大多数来源都放弃了这种精度。有影响力的论文“发现bug很容易”开始时说“bug模式是常见错误的代码习惯”，但没有具体解释。其他工作则依赖于不完美的实际规范代理。例如，在自动程序修复研究中，bug对应于一个失败的测试用例：当测试通过时，bug被认为已经修复。然而，当我们对相当简单的定义进行询问时，它们开始崩溃……

定义bug是一个模糊的问题，本文试图探讨bug的本质并提出新的定义。

本文提出了一种新的定义方式，将bug视为程序的行为与开发者意图之间的偏差，以此作为判断bug的标准。

本文通过对已有定义的分析，提出了一种新的定义方式，并通过实验验证了这种定义方式的有效性。实验使用了多个数据集，并对比了不同定义方式的结果。本文的思路值得关注和深入研究。

近期的相关研究包括：1.《Finding and Understanding Bugs in C Programs》2.《Mining Bug Data Across GitHub and Stack Overflow》3.《Automated Whitebox Fuzz Testing》