When identifying the origin of software bugs, many studies assume that “a bug was introduced by the lines of code that were modified to fix it”. However, this assumption does not always hold and at least in some cases, these modified lines are not responsible for introducing the bug. For example, when the bug was caused by a change in an external API. The lack of empirical evidence makes it impossible to assess how important these cases are and therefore, to which extent the assumption is valid. To advance in this direction, and better understand how bugs “are born”, we propose a model for defining criteria to identify the first snapshot of an evolving software system that exhibits a bug. This model, based on the perfect test idea, decides whether a bug is observed after a change to the software. Furthermore, we studied the model’s criteria by carefully analyzing how 116 bugs were introduced in two different open source software projects. The manual analysis helped classify the root cause of those bugs and created manually curated datasets with bug-introducing changes and with bugs that were not introduced by any change in the source code. Finally, we used these datasets to evaluate the performance of four existing SZZ-based algorithms for detecting bug-introducing changes. We found that SZZ-based algorithms are not very accurate, especially when multiple commits are found; the F-Score varies from 0.44 to 0.77, while the percentage of true positives does not exceed 63%. Our results show empirical evidence that the prevalent assumption, “a bug was introduced by the lines of code that were modified to fix it”, is just one case of how bugs are introduced in a software system. Finding what introduced a bug is not trivial: bugs can be introduced by the developers and be in the code, or be created irrespective of the code. Thus, further research towards a better understanding of the origin of bugs in software projects could help to improve design integration tests and to design other procedures to make software development more robust.

中文翻译：

---

错误是如何产生的：一种识别错误如何在软件组件中引入的模型

在确定软件错误的来源时，许多研究假设“错误是由为修复它而修改的代码行引入的”。然而，这个假设并不总是成立，至少在某些情况下，这些修改后的行不负责引入错误。例如，当错误是由外部 API 中的更改引起时。由于缺乏经验证据，因此无法评估这些案例的重要性，因此无法评估该假设在多大程度上有效。为了朝着这个方向前进，并更好地了解错误是如何“产生”的，我们提出了一个定义标准的模型，以识别出现错误的不断发展的软件系统的第一个快照。该模型基于完美的测试思想，决定在更改软件后是否观察到错误。此外，我们通过仔细分析在两个不同的开源软件项目中如何引入 116 个错误来研究模型的标准。手动分析有助于对这些错误的根本原因进行分类，并创建手动策划的数据集，其中包含引入错误的更改和未由源代码中的任何更改引入的错误。最后，我们使用这些数据集来评估四种现有的基于 SZZ 的算法的性能，用于检测引入错误的更改。我们发现基于 SZZ 的算法不是很准确，尤其是在发现多次提交时；F-Score 从 0.44 到 0.77 不等，而真阳性的百分比不超过 63%。我们的结果显示经验证据表明普遍的假设，“一个错误是由被修改以修复它的代码行引入的”，只是在软件系统中引入错误的一种情况。找到引入 bug 的原因并非易事：bug 可以由开发人员引入并存在于代码中，或者在不考虑代码的情况下被创建。因此，进一步研究以更好地理解软件项目中错误的起源，可以帮助改进设计集成测试和设计其他程序，使软件开发更加健壮。