[论文解读] Large-Scale Manual Validation of Bug Fixing Commits: A Fine-grained Analysis of Tangling.

Steffen Herbold, Alexander Trautsch+46 more|arXiv (Cornell University)|Nov 12, 2020

Software Engineering Research参考文献 4被引用 5

一句话总结

本研究通过众包方式对4,000多行错误修复提交中的代码行进行人工标注，发现17–32%的代码更改直接修复了错误，在生产代码中该比例上升至66–87%。研究发现错误纠缠现象普遍存在——多达47%的数据可能含有噪声，凸显了在经验性软件工程研究中进行人工验证的必要性，以避免得出误导性结论。

ABSTRACT

Context: Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of bugs. Objective: We want to improve our understanding of the prevalence of tangling and the types of changes that are tangled within bug fixing commits. Methods: We use a crowd sourcing approach for manual labeling to validate which changes contribute to bug fixes for each line in bug fixing commits. Each line is labeled by four participants. If at least three participants agree on the same label, we have consensus. Results: We estimate that between 17\% and 32\% of all changes in bug fixing commits modify the source code to fix the underlying problem. However, when we only consider changes to the production code files this ratio increases to 66\% to 87\%. We find that about 11\% of lines are hard to label leading to active disagreements between participants. Due to confirmed tangling and the uncertainty in our data, we estimate that 3\% to 47\% of data is noisy without manual untangling, depending on the use case. Conclusion: Tangled commits have a high prevalence in bug fixes and can lead to a large amount of noise in the data. Prior research indicates that this noise may alter results. As researchers, we should be skeptics and assume that unvalidated data is likely very noisy, until proven otherwise.

研究动机与目标

• 为了理解在错误修复提交中，多个关注点被同时处理时，错误纠缠的真实普遍程度。
• 为了评估错误修复提交中的代码更改有多少实际上与报告的错误修复相关，而非处理无关的关注点。
• 为了量化在将更改标记为错误修复时的不确定性与分歧程度，识别出难以分类的代码行。
• 为了估算在依赖自动化提交分析的现有经验性软件工程研究中，错误纠缠可能引入的噪声量。
• 倡导将人工验证作为减少噪声、提升经验性软件工程研究可靠性所必需的步骤。

提出的方法

• 采用众包方法，由四位独立参与者将每个错误修复提交中的代码行标记为“修复错误”、“不相关”或“模糊”。
• 使用共识标注：仅当至少三位参与者对同一标签达成一致时，才认为该行被可靠标注。
• 聚焦于生产代码文件中的代码行，以评估直接贡献于错误修复的更改比例。
• 将存在活跃分歧（参与者之间意见不一致）的代码行归类为“难以标注”，以评估标注的不确定性。
• 通过测量在不同使用场景下，由于错误纠缠可能导致误分类的数据比例，来计算噪声估计值。
• 在多个开源项目中分析超过4,000行代码，以确保研究结果的统计稳健性。

实验结果

研究问题

• RQ1 根据人工标注，错误修复提交中有多大比例的更改实际上修复了报告的错误？
• RQ2 错误纠缠在错误修复提交中有多普遍，特别是在生产代码文件中？
• RQ3 错误修复提交中有多少比例的代码行由于模糊性或评分者之间的分歧而难以标注？
• RQ4 错误纠缠在多大程度上会向经验性软件工程数据集中引入噪声，且这种影响在不同使用场景下如何变化？
• RQ5 在识别实际错误修复方面，人工共识标注与自动化提交分析相比，其可靠性如何？

主要发现

• 在错误修复提交中，所有代码更改中有17%至32%直接负责修复底层错误。
• 当限制在生产代码文件时，修复错误的更改比例显著提高，达到66%至87%。
• 约11%的错误修复提交中的代码行难以标注，表明评分者之间存在活跃分歧且模糊性较高。
• 由于确认存在的错误纠缠和标注不确定性，某些使用场景下高达47%的数据可能为噪声，保守下限为3%的噪声。
• 本研究证实，未经验证的提交数据极有可能因错误纠缠而包含显著噪声，从而挑战了以往自动化研究的有效性。
• 研究结果强调了在经验性软件工程研究中进行人工验证的必要性，以避免因未清理、未经验证的数据导致误导性结论。