本篇文章的撰写的起因是我对近期读过的一篇国外科研文献Automatic Software Repair: A Survey（2019.1）产生了兴趣，因此写下这篇关于此软件工程科研成果的综述。

 

摘要：这是一篇刊载在IEEE Transactions on Software Engineering (TSE)（2019.1.1）上的文章：Automatic Software Repair: A Survey。我将从“1.报告简述；2.调试困境&研究立意&文章综述方向；3.两种修复策略的比较；4.错误定位；5.修订算法；6.未来研究方向与挑战；7.综述结论” 这七步骤来讲解这篇综述。

 

 

 

目录

0 前沿 

1 科研综述选用介绍 

1.1 IEEE Transactions on Software Engineering汇刊介绍【2】 

2 报告简述 

3 调试困境&研究立意&文章综述方向 

3.1 调试困境 

3.2 研究立意 &文章综述方向 

4两种修复策略的比较 

5 错误定位（localization） 

5.1故障定位技术（ fault localization） 

5.2固定场所定位技术（ fix locus localization） 

6 修订算法 

6.1 生成和验证 

6.2 语义驱动的修复 

7 未来研究方向与挑战 

7.1 修复正确性挑战 

7.2 流程挑战 

7.3技术挑战 

8 综述结论 

9 我的结语 

10.文献引用 

 

 

 

 

0 前沿

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能运行的软件才具有的，实际上，几乎所有的软件都不同程度地存在这些问题,其包含两方面的问题∶①如何开发软件，以满足对软件日益增长的需求;②如何维护数量不断膨胀的已有软件。产生软件危机的原因包括主观原因和客观原因，正因为有软件危机这种威胁的出现，软件工程这门新兴学科应运而生，他们负责解决此类问题，且不限于只是解决此类问题！因此软件工程是是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。

 

1 科研综述选用介绍

 

此篇Automatic Software Repair: A Survey选自期刊IEEE Transactions on Software Engineering (TSE)。由于此期刊上的2020年最近最新的报告都需要付费才能观看，因此我挑选了这篇发布在第45卷上的（2019.1.1）而且内容上我也十分感兴趣的可研报告。（目前此期刊最新发布的一卷是第46卷）。

 

1.1 IEEE Transactions on Software Engineering汇刊介绍【2】

 

 IEEE Transactions on Software Engineering (IEEE T SOFTWARE ENG, 简称TSE)

中文名：IEEE软件工程汇刊

出版社：IEEE，1975*

     TSE是公认的软件工程领域最权威的国际学术期刊，从2013年起，TSE恢复月刊，每年一卷，12期（2008年-2012年为双月刊，每年6期，2008年之前为月刊），每期6-10篇论文，一年约80-100篇论文。

     TSE既有一些软件工程的理论性研究论文，也有一些经验性研究论文，这些研究对于软件系统的构造、分析和管理具有一定的意义，其范围覆盖整个软件工程研究领域。

     TSE论文的具体主题涵盖如下领域：

     (1) 软件开发和维护方法和模型，例如：软件需求、设计和实现相关技术和原理，包括形式化和过程模型等；

     (2) 评价方法，例如：软件测试和验证，软件可靠性模型，测试和调试流程，软件差错控制中的冗余设计，软件度量，评估不同领域的软件产品和过程等；

     (3) 软件项目管理，例如：生产率系数，成本模型，项目进度控制和组织架构，相关标准制定等；

     (4) 工具和环境，例如：特定工具的介绍，集成开发环境，包括软件架构、数据库以及并行和分布式处理等相关主题；

     (5) 与系统相关的主题，例如软件和硬件的权衡等；

     (6) 高水平的调查工作以及综述，例如与一个特定研究领域的历史发展情况相关的全面性综述。

     TSE每期文章不多，改为月刊后每期文章一般在10篇以内，录用率较低，近年来不断有国内学者在TSE上发表论文（2012年北京大学、北京理工大学、大连理工大学、香港科技大学；2013年中山大学、北京大学、北京理工大学、暨南大学、香港科技大学均有第一作者TSE论文，2014年最新录用的论文中有微软亚洲研究院、中国科学院自动化所、香港中文大学等国内高校和研究机构的第一作者论文），可见我国软件工程领域的研究水平在逐步提高。

     通常，TSE从投稿到见刊周期为两年左右（投稿到录用差不多需要1年-1年半的时间），大部分文章长度在10-20页之间（双栏排版），也有极少数文章的长度少于10页，论文要求有较强的创新性，发表难度较大。

 

2 报告简述

 

尽管现代软件应用程序的复杂度越来越高，规模也越来越大，但它们必须满足严格的发布要求，这就给负责及时生产高质量软件的开发人员带来了巨大的压力。为了减少开发人员的工作量，在过去几年中，修复和愈合技术作为高效修复和维护软件的解决方案被广泛研究。特别是，修复解决方案已经能够对软件程序中可能存在的几类错误自动产生有用的修复。一系列的算法、技术和启发式方法已经被整合、实验和研究，产生了一个异构的、衔接的研究框架，自动修复技术在这个框架中层出不穷。

本文通过调查108篇关于软件自动修复技术的论文，对该领域的知识进行整理，说明算法和方法，在有代表性的例子上进行比较，并讨论公开的挑战和目前报道的经验证据。

 

 

3 调试困境&研究立意&文章综述方向

3.1 调试困境

 

调试软件故障仍然是一个痛苦、耗时和昂贵的过程。例如，最近的研究表明，调试活动往往占软件产品总开发成本的 50%左右。造成调试成本的因素有很多，但影响最大的因素是在识别和排除故障时仍需要大量的人工工作。特别是在 调试过程中，需要分析和了解失败的执行情况，找出故障的原因，实施修复，并验证修复后的程序是否正常工作，即问题已经修复，而没有引入任何副作用。这些活动大多是人工执行或在部分工具支持下执行的。

     目前常见的调试方案有隔离、识别、异常检测技术，所有这些技术都提供了关于故障的可能位置、导致故障的输入和状态以及故障期间执行的异常操作的有用 见解。然而，开发人员仍然必须在故障执行的分析上投入相关的精力，以准确识别必须修复的故障。此外， 这些技术并不能帮助开发人员综合出合适的修复方法。

 

3.2 研究立意 &文章综述方向

 

研究者们关注了一类新的方法，即程序修复技术。这些技术的主要思想是试图通过产生一个实际的修复方法来自动修复软件系统，这个修复方 法在最终被接受之前可以被测试人员验证，或者可以被调整以适当地适合系统。使用这些技术的好处是， 修复的结果既解释了故障的原因，又提供了解决问题的可能方案，从而减轻了识别和纠正故障所需的努力。

由于程序修复技术具有极大地减少调试工作的潜力，因此吸引了许多研究人员的兴趣，他们提出了多种方法来修复不同条件和假设下的不同类别的故障。已经取得了重要成果，但同时这些成果也揭示了必须面对的相关挑战的存在。

本文对现有的方法进行了全面的回顾，对修复技术的能力进行了批判性的分析，对目前取得的成果进行了调查，并指出了未来研究界应该面临的关键性的开放性挑战，为程序修复技术的研究做出了贡献。

 

  

4两种修复策略的比较

 

自动处理程序故障的两种经典方法是软件愈合技术（software healing）和软件修复技术（software repairing）。虽然原理相似，但它们的目的不同，使用不同的解决方案来处理故障。

软件愈合（healing）解决方案能够在现场检测软件故障，并通过进行必要的调整来恢复系统的正常运行。这些调整不是部署在源代码层面，而是在运行时应用在已部署的应用程序上，以防止或减轻故障。在软件的同一实例上多次出现类似的故障，可能会多次触发同一个愈合过程。

软件修复（repairing）解决方案检测软件故障，定位可以修复的地方，并进行必要的调整以修复故障，从而防止同一故障引起的进一步故障。这些调整是在内部产生的，比如在测试和设计时产生，并在源代码

层面部署。

软件愈合和修复可能涉及也可能不涉及人工干预。在自动软件愈合和修复中，人类只是监督这个过程。而当人完全不参与其中时，这些技术分别称为软件自愈和软件自修。

（本文探讨的是其中的repairing技术，此处是两种技术的说明与比较。）

 

 

 

如图，如果我们将修复过程与愈合过程进行比较，可以发现修复过程包括一个额外的步骤。愈合过程直接对故障 作出反应，而修复过程则需要首先确定适合修复的位置。 与旨在防止故障的修复过程不同，软件修复技术利用通过多次运行收集到的观察结果，包括故障和无故障 执行，来生成修复。例如，许多修复技术通过使用从包括许多通过和失败测试的大型测试套件的执行中获 得的信息来生成修复。 修复过程可能产生两种结果。(一) 执行失败/固定程序，即执行失败，但程序已被固定，因此固定的故障 不会再产生故障；(二) 执行失败/故障程序，即执行失败，程序仍有故障。第一种结果对应的是修复成功， 而第二种结果对应的是修复不成功。

在下面的内容中，我们将介绍自动程序修复方案 ：重点介绍错误定位、错误修复和验证的策略。

 

5 错误定位（localization）

 

在本节中，将讨论程序修复技术所使用的算法，以标识应将修复程序应用于的程序位置。这是程序修复过程中的重要步骤，因为修复的成功可能不仅取决于修复程序本身，还取决于修复程序的位置。

这里有两种重要的定位技术：故障定位技术（ fault localization）和固定场所定位技术（ fix locus localization）

 

5.1故障定位技术（ fault localization）

 

故障定位技术旨在识别故障语句。在这种情况下，修复有望将发现的错误语句转换为正确的语句。

在这种方案中，程序修复技术广泛使用基于频谱的故障定位（Spectrum-Based Fault Localization，SBFL）作为一般机制，对可能出现故障的语句进行定位。

SBFL 利用在测试过程中收集到的软件行为信息来识别可能有问题的程序元素。特别是，SBFL 根据对通过测试和失败测试所覆盖的程序实体的分析，产生一个程序元素列表，并根据其出现故障的可能性进行排序。一般的感觉上像是，很多失败测试用例执行的程序元素和很少的通过测试用例执行的程序元素很可能是有问题的，反之，很多通过测试用例执行的程序元素和很少或没有失败测试用例执行的程序元素很可能是正确的。可能会考虑不同种类、不同粒度的程序实体进行定位，如语句、分支、路径等。故障定位和程序修复通常在同一粒度级别上工作，即如果程序修复技术在程序语句级别上工作，那么用于故障定位的 SBFL 算法也在语句级别上工作。

 

5.2固定场所定位技术（ fix locus localization）

 

固定场所定位技术的目的是确定适合合成修复的程序位置，而不管故障的位置如何。其想法是，一个可以识别故障影响的程序位置也可以被利用来补偿其影响。在下文中，我们将介绍基于模型的修复定位，它可以识别出面向对象软件中非法使用对象的语句，以及天使修复定位，它可以定位与缺失或错误的 if 条件故障相关的语句。

文中主要讲了两类分支：基于模型的修复定位方法（Model-Based Fix Locus Localization）和天使修复定位（Angelic Fix Localization）。

 

6 修订算法

 

本节讨论自动生成程序修正的算法及相应的验证策略。

所有的算法都是以一个待解决的问题（Prepair）来近似生成去修复的问题。这意味着 Prepair 的解决方案有可能解决产生修复的原始问题，但不能保证在实践中一定会发生这样的情况。为此，对 Prepair 的解 Srepair 称为“貌似可行的解”（pausible）。 根据 Prepair 的定义和处理方式，我们区分了两大类方法：生成-验证和语义驱动的方法。

生成和验证方法通过定义和探索 Prepair 的潜在解的空间 Srepair（注意 Srepair 可能包含解和不解 Prepair 的元素）产生修复。 语义驱动的方法（也称为正确的构造方法）对问题 Prepair 进行形式上的编码，可以是显式的，也可以是隐 式的，一旦找到解，就保证解能解决 Prepair。 无论使用哪一类方法，任何解决方案的修复都会被报告给开发人员，他们会交叉检查其质量和正确性，如 果必要的话，会进一步详细说明以获得一个完全令人满意和正确的修复。无论是否需要编辑自动生成的修复，自动修复的存在已经可以帮助开发人员理解代码中的错误，并简化实际修复的实施。 修理技术可以设计成一般的，也可以设计成特定的故障。 一般技术不是针对某一类故障而设计的，有可能修复程序中的任何一类故障。 针对故障的技术只针对某些类别的故障，如条件语句中的错误条件和缓冲区溢出。 原则上，故障专项技术应在其较窄的应用范围与较高的维修效率之间取得平衡。

 

6.1 生成和验证 

 

生成-验证方法执行一个迭代过程，如图1 所示。该过程由两个主要活动组成，即生成活动和验证活动，前者产生 Prepair 问题的候选解（可能性解Srepair），后者检查生成解的正确性。

 

 

Fig-1

 

 生成活动使用一组变化运算符(a set of change operators)修改原始程序 P，并产生 k 个新程序，这些新程序被添加到候选解的集合中。 这些修改是以较高的概率对定位技术识别的可疑位置进行的。变更运算符可能是不同性质的。 原子变化运算符在一个点上修改 P。

预先定义的模板运算符根据潜在的复杂预设模式改变 P。 基于示例的模板操作者的工作原理与预先定义的模板相同，但模板是手动或自动从历史数据（例如，版本系统）中提取的。 有些技术不仅对 P 应用变化运算符，而且对候选解也应用变化运算符。这样，修改后的程序可以逐步积累应用多个变化运算符所产生的变化。一个技术可以产生的 所有候选解的总体集合代表其搜索空间 Srepair。当 Srepair 中的每一个可能的元素都被考虑过，或者分配给修复过程的时间已经过期，这个过程就结束了，没有产生 Prepair 的解。

验证活动检查候选解的正确性。到目前为止，大多数生成和验证技术都是通过运行可用的测试用例来确定 解的正确性，也就是说，如果候选解集合中的程序 s 通过了所有可用的测试用例，那么程序 s 就会被返回 给开发者，作为 P 的一个可能的修正。作为验证的结果，候选解集合中的一些或所有元素可能会被丢弃， 例如，由于没有通过许多测试而基本不满意的候选解通常会被丢弃。

生成和验证活动可以按照两种主要策略执行：基于搜索策略(search-based)和蛮力策略(brute-force)。这些策略在处理变更操作者和候选解决方案的方式上有所不同。

 

6.2 语义驱动的修复 

 

 

语义驱动技术对问题 Prepair 进行正式编码，可以是显式的，例如作为一个公式，其解对应于被修复程序的 可能修复，也可以是隐式的，作为一个分析过程，其结果是修复。因此，当能找到一个解 srepair 时，就保 证能解决问题 Prepair，因此不需要对 Prepair 进行验证。

需要注意的是，虽然一个解决方案 srepair 可以保证解决 Prepair，但 srepair 并不能保证完全让开发者满意。 Prepair 是对要解决的实际修复问题的近似表示，根据 Prepair 中没有表示的方面，解决方案可能存在问题。 例如，Prepair 可能代表了程序中存在的并发问题，而 Prepair 的实际解决方案可能在解决了并发问题的同时 引入了其他问题，如性能或功能问题。因此，自动生成的解决方案仍然需要经过人工或自动验证，以决定是否可以最终接受。

 

 

Fig-2

 

语义驱动技术的一般流程如图2所示。该过程主要包括三个连续的活动。行为分析活动对被修复的程序进 行分析，以提取程序正确和错误行为的语义信息。为此，行为分析可以利用一些来源，如可用的测试用例、 规范和被分析程序的源代码。行为分析通常利用这些源的一个子集。例如，它可以专注于通过运行测试套 件提取的动态信息或通过静态分析程序的源代码获得的信息。在前一种情况下，提取的信息可以是输入- 输出对的形式，这些输入-输出对编码了一个可能有问题的程序代码片段应该如何行为才能正确运行。在后 一种情况下，提取的信息可以代表应该从被修复的程序中消除或修改的行为，以使其正确运行。

 

7 未来研究方向与挑战

 

自动程序修复技术已经在许多非平凡的环境中证明了它们的有效性，但是仍然必须证明它们的一般适用性以及在工业环境中利用该技术的可能性。在我们的分析中，我们确定了许多重要挑战以及研究趋势，这些趋势表明该领域的未来工作可能集中在哪里。在本节中，我们将这些挑战分为三个部分进行报告：修复正确性挑战（fix correctness challenges），过程挑战（process challenges）和技术挑战（technical challenges）。

 

7.1 修复正确性挑战

 

需要合理与正确的解决方案。大多数技术都可以产生合理的修复，例如，可以通过现有测试套件中所有测试案例的修复。相比之下，开发人员需要的是正确的修复，即满足被修复程序的所有要求的修复。虽然使用测试套件无疑是验证自动生成的修复的主要方法，但也有其他方法，如使用规范和代码合同。然而，同样在这些情况下，生成的修复只是可信的，即根据所使用的具体验证标准（如规范或合同）是正确的，而对于开发者来说，它们不一定是正确的。

为了缓解这个问题，一些方法研究了从开发者编写的实际修复信息中得到启发的修复操作符的定义，其他方法认为手动检查修复信息是最有用的验证方法。然而，如何根据开发人员的判断，确定产生正确和可理解的修复方法，仍然是一个普遍存在的挑战。虽然要产生"保证"满足开发者期望的修复程序可能是不可行的，但找到生成和评估可能被开发者接受的修复程序的方法是一个重要的研究方向。

 

7.2 流程挑战 

 

在特定情况下选择合适的技术。如何在特定情况下选择适当的程序修复方案是一个重要的开放性问题。需要在多个层面上进行选择。首先，开发者可能更喜欢全自动修复技术来修复推荐器，反之亦然。这种选择可能取决于开发者的偏好，也取决于修复任务的性质。例如，有些任务可能很难完全自动化，在这些情况下，修复推荐器可能代表一个有效的选择。遗憾的是，对于什么时候应该选择一类方法而不是另一类方法，仍然没有什么了解。

另一个变数是选择特定故障技术还是一般技术。一个好的策略可能是在适用的情况下优先选择故障专用技术，否则就使用一般技术。遗憾的是，可能很难先入为主地猜测要修复的故障是什么，因此可能极难选择正确的故障专用技术，除非故障已经说明了故障的性质，例如对于无限循环故障。

另一个层面的决策是选择变化模型的类型和修复故障应采用的算法策略。能够做出这些选择，可能会大大促进修复技术的选择。但是，由于故障在修复之前是未知的，所以在实践中做出这些决定是非常困难的。

 

7.3技术挑战

 

目前有许多软件修复技术和许多研究，但研究结果仍然是分散的，难以综合成一幅清晰的画面。这往往是由于该领域的每项工作所引入的创新（如提出一种新的程序修复综合策略）、优化（如对测试用例进行优先验证）的混合。由于这些因素的重叠效应，有时很难确定影响更多结果的因素是什么。是策略吗？是一个特定的启发式方法吗？是执行的质量吗？在比较和研究同一领域的解决方案时，所有这些因素可能会相互干扰。

重要的是提高该领域的成熟度，并更好地了解重要和有用的策略和启发式方法，这些策略和方法应该存在于每一个自动程序修复技术中，例如，增加对等价性检查、候选解的优化表示和测试优先级模式的影响的独立研究。

 

8 综述结论

 

自动程序修复技术解决了自动修复有缺陷软件的宏大挑战。在过去的十年中，程序修复技术已经产生了相关的、有影响的成果，证明了其对测试、验证和调试实践产生长期重大影响的潜力。

本篇综述整理了该领域的知识，调查了现有的工作，并讨论了主要成果和挑战。特别是，本文表明，程序修复方法主要按照两种策略来解决软件的修复问题。生成和验证方法生成一个可能修复的搜索空间，然后探索这个搜索空间寻找一个正确的修复方法。语义驱动方法产生修复程序问题的表示，并解决这个问题以获得实际的修复结果。

然后，我们从多项不同研究中收集到的经验证据整合并总结为一套关键事实，显示了影响这些方法有效性的权衡和因素。最后，我们讨论了我们认为最重要的挑战，这些挑战可以影响该领域的未来研究。

 

9 我的结语

 

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能运行的软件才具有的，实际上，几乎所有的软件都不同程度地存在这些问题,其包含两方面的问题∶①如何开发软件，以满足对软件日益增长的需求;②如何维护数量不断膨胀的已有软件。产生软件危机的原因包括主观原因和客观原因，正因为有软件危机这种威胁的出现，软件工程这门新兴学科应运而生，他们负责解决此类问题，且不限于只是解决此类问题！因此软件工程是是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。

我的软工导论课堂由这句话开始，我从此大致明白了软件工程的意义，做好了接触软件工程的准备。

我讲述的是一篇我读完后很感兴趣的论文Automatic Software Repair: A Survey。写完后，它更加让我深刻明白了，软件工程这门大类学科，不止是仅仅在解决那些“制作项目过程的方法”的效率问题，不仅仅只是去研究那些更高级高效的协作模式；它更是有大量的研究人员，去研究解决那些编写代码过程（或者其他开发或维护计算机软件的行为）中的，让人头疼、会大量消耗时间精力的硬骨头问题（就比如这篇去研究的就是“时间、精力杀手——代码调试”的问题）。这是一门不断想去更高效、更安全、更便捷的优化“开发和维护计算机软件”这一行为的伟大的新兴学科！

 

10.文献引用

 

【1】

https://ieeexplore.ieee.org/document/8089448

【2】

https://blog.csdn.net/ggjrtg/article/details/83926856?ops_request_misc=%25257B%252522request%25255Fid%252522%25253A%252522160802250919726891199530%252522%25252C%252522scm%252522%25253A%25252220140713.130102334.pc%25255Fall.%252522%25257D&request_id=160802250919726891199530&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_v2~rank_v29-5-83926856.nonecase&utm_term=%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E7%A7%91%E7%A0%94%E6%88%90%E6%9E%9C