原论文标题《Automatic Software Repair: a Bibliography》
原作者 Martin Monperrus，主页：https://www.monperrus.net/martin/
发表于 ACM Computing Surveys, 2017
原文链接：https://arxiv.org/pdf/1807.00515.pdf
感谢原文作者Martin Monperrus教授提供翻译授权。鉴于原文较长，该翻译将分为四次上传。第一次为原文开头至第二节结尾，第二次为原文第三节，第三次为原文第四节，最后一次为原文第五、六、七节。原文中的参考文献可至原文中查看，原文链接附在开头与结尾。
5. 修复的经验性知识
除了提出新的修复技术外，还有一系列经验性地研究自动修复的基础，影响和适用性，无论是行为修复还是状态修复。
软件存储库中有大量信息可用于修复。特别是，人们可以挖掘错误报告和代码提交来提取对自动修复有价值的知识。Martinez和Monperrus [114]研究了89 993次代码提交来挖掘出手动编写补丁中的修复措施。修复措施意味着对程序的抽象语法树的更改类型，例如修改if条件。他们后来研究了[115]自动修复中的冗余假设（redundancy assumption）（是否可以通过重新排列现有代码来修复bug），并发现这种方法可以运用于实践中：许多bug修复的提交只是对现有代码进行了重新排列，这一结果得到了Barr等人的证实[12]。Zhong和Su [196]对9000多个实例补丁进行了案例研究，发现了自动修复的一些重要事实：例如，他们的分析指出，通过更改配置文件可以修复一些bug。
关于合成补丁的优点，Fry等人[47]基于150个参与者和32个现实世界的缺陷对机器生成的补丁进行了研究。他们的研究表明，机器生成的补丁比人工编写的补丁的可维护性稍差。Tao等[176]进行了类似的研究，以研究机器生成的补丁是否有助于人工调试。Monperrus[124]进一步讨论了合成补丁的可接受性标准，并强调评估补丁可接受性可能需要高水平的专业知识，这一结果得到了[113]的证实。Qi等人[140]率先对Genprog生成的补丁进行了深入分析，发现大部分补丁都是错误的。其是否普遍适用于基于测试套件的修复是一个悬而未决的问题[113]。如果补丁不正确但通过了测试验证，那是因为它们利用了测试套件的特殊性和弱点，这可以看作是一种过拟合。当合成的补丁只对失败的输入起作用而不能进行泛化时，其修复技术就被认为是过拟合的。Smith等人[165]也研究了自动修复中的过拟合问题。在学生程序的数据集上，他们表明Genprog和相关技术确实存在过拟合问题。
Kong等人[82]的一项研究比较了不同的修复系统：GenProg[90]、RSRepair[139]和AE[189]。他们报告了针对西门子基准测试中119个种子bug和34个实际bug的修复结果，并表明不是所有的技术都是相同的。
最后，为了使修复相关的知识融为一体，需要一个公认的，定义明确且可公开的基准[124]。Le Goues等人[92]为C程序中的bug建立了这样的基准，收集了来自开源项目和学生代码中的总共1183个错误。
6. 相关技术
根据我们在第3节和第4节中给出的定义，我们现在介绍的是与自动修复相关的工作，而不是“自动修复”本身。尤其是，它们要么没有完全自动化，要么没有对现实中的程序进行实际修复。
6.1. 修复前工程
许多作者试图列出重要的原则，以使应用程序具有健壮性，弹性（如果不能自我修复）。这些原则可以作为框架和库中的首要概念来实现和实施，这就是所谓的“修复前工程（forward engineering for repair）”。
Somayaji等人描述了构建免疫计算机系统的原则[166]：分布性、多层次性、多样性、可处置性、自主性、适应性、行为自我意识、异常检测。Candea和Fox [18]为程序快速恢复定义了一组特征：有了这些特征，应用程序就变成了“仅崩溃软件（crash-only software）”。两个关键特征是组件之间的所有交互都具有超时并且所有资源都已租用。Sussmann[173]以及Gabriel和Goldmann[48]也对如何构建具有弹性和自修复的软件提供了深刻的见解。
也有支持修复的框架。Flora [168]是一个支持应用程序本地重启的框架。它主要由用于在组件之间丢弃或排队消息的通信管理器组成。Denaro等人[37]提出了一种架构，用来修复面向服务系统中的互操作性bug。服务变体之间的适配器是手动编写的，并在运行时进行选择以启用正确的通信。Levinson [96]定义了一个嵌入式DSL，以支持程序变体空间中的运行时搜索。Zhou等人[197]定义了操作系统C代码的注释，以便从Linux的驱动程序error中恢复。注释由类型系统检查，并推动不变恢复。Demsky和Dash[36]提出了一种具有内置健壮性功能的语言Bristlecone。Bristlecone基于任务和任务之间的依赖关系以及事务状态变化, 因此其错误处理是完全自动化的。
bug的一个已知特征是，同一类bug可以影响同一代码库中的许多不同位置。在这种情况下，需要编写一个特定的补丁，然后将其应用于所有这些位置。通用补丁可以从给定位置的具体实例推断，也可以抽象的方式编写。Meng等人[121]称其为“系统编辑（systematic editing）”。同样，Sun等人[171，172]提出了对补丁应用程序的工具支持。Coccinelle工具[133]也提供了此功能，可以从具体实例中自动推断出抽象补丁[4，120]。
6.2. 修复建议
有些系统会向开发人员提供“修复建议”。尽管这不是完全自动化的，但是如果建议正确，则可以将这样的系统视为提供部分自动修复，其中修复系统和开发人员协同工作。
Hartmann等人[60]设计了一个提出修复错误消息建议的系统，名为“ HelpMeout”。该系统针对编译器错误消息和运行时异常。它首先收集错误消息以及在受监视的开发人员计算机上发生的相关变更。然后，当另一个开发人员遇到相同的错误消息时，系统会将错误的源文件与数据库中最接近的已修复版本进行比较。该系统使用定制的距离度量来增加建议的相关性。
Jeffrey等人[66]提出了一种基于关联规则的修复建议方法。规则建议针对由多种特征（在机器学习的意义上）表示的可疑语句执行bug修复措施。这些特性（本文中称为“描述符”）是对语句标记的抽象。该预测还使用“有趣的值映射对（interesting value mapping pairs）”（IVMP），它们是使测试用例能够通过的具体值（又名值替换[67]和天使值[25，34]）。bug修复建议是典型的比较运算符更改、常量更改、添加或增加数值。
Kaleeswaran等人[73]提出了一种基于相关变量值和预期输出的修复建议方法。预期的输出是通过concillic执行获得的，修复提示包括更改单个赋值语句的RHS。
Abraham和Erwig [1]研究了Excel公式修复建议。Malik等人[112]将运行时数据结构修复（详见4.7.1）作为修复建议。Brodie等人[15]设计了跨调用堆栈（堆栈跟踪）的距离度量，以匹配问题报告和已知的修复。
6.3. 理论软件修复
一些作者在很强的假设下探索自动修复，而没有相关的实践程序。据我们所知，没有关于这一领域的综述性论文，但是Bodik和Jobstmann的文章中有专门的章节[14]。在此，简要介绍该领域最著名的论文，为读者提供入门指南。例如，Jobstmann等人[71]修复了以线性时间逻辑表示的程序。George[54]描述了一个简单的理论编程模型，该模型通过一种保持不变量的内稳态来支持自动恢复。Fisher等人[138]也对玩具形式语言（toy formal language）进行修复。Wang和Cheng[181]将修复声明为状态机上的编辑序列。Zhang和Ding [195]研究了修复计算树逻辑模型。
7. 总结
本文是一个关于自动软件修复的综述。该研究领域既古老又新颖。说它古老是因为我们可以在70 80年代关于容错的论文中找到与自动修复有关的技术，例如1973年的一篇论文《STAREX self-repair routines: software recovery in the JPL-STAR computer》[148]。说它新颖是因为2000年底才开始研究自动更改代码的想法，即行为修复。无论是古老的还是新颖的，这些技术必须扩展到现在的规模和复杂性或软件栈，而我们目前还没有做到。这意味着现在只是一个开始，在未来的几年里，我们将在自动软件修复领域获得很多乐趣、惊喜和赞美。
（完）
其余部分：（一）：https://blog.csdn.net/ClarkCC/article/details/106029615
（二）：https://blog.csdn.net/ClarkCC/article/details/106108728
（三）：https://blog.csdn.net/ClarkCC/article/details/106178275
若发现翻译问题，可直接评论或与我联系：cheng.yifan@qq.com
原论文标题《Automatic Software Repair: a Bibliography》
原作者 Martin Monperrus，主页https://www.monperrus.net/martin/
发表于 ACM Computing Surveys, 2017
扫一扫
639
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
