文章目录

  • 前言
  • 基本信息
  • 1 基本内容
  • 2 idea来源
  • 3 亮点
  • 4 不足
  • 相关文章(待阅读)
  • 总结


标题:[FSE 19] Java修复工具的大规模实验:Empirical Review of Java Program Repair Tools: A Large-Scale Experiment on 2,141 Bugs and 23,551 Repair Attempts

前言

本文旨在阅读 FSE 2019 文章:Empirical Review of Java Program Repair Tools: A Large-Scale Experiment on 2,141 Bugs and 23,551 Repair Attempts

基本信息

文章地址:https://arxiv.org/abs/1905.11973

作者:
Durieux, T., Madeiral, F., Martinez, M., & Abreu, R. (2019). Empirical Review of Java Program Repair Tools: A Large-Scale Experiment on 2,141 Bugs and 23,551 Repair Attempts. arXiv preprint arXiv:1905.11973.

1 基本内容

作者的立足点:
1)基于测试用例集的软件自动修复越来越火了,每年都有相关文章发表到软工的顶级(或者说major,主要)会议期刊中;
2)尽管很多工具被开发出来了,但是他们都只在一个benchmark上做验证,而且极少被其他的研究者复现;

所以作者的工作:

In this paper, we present a large-scale experiment using 11 Java test-suite-based repair tools and 5 benchmarks of bugs.

动机:

Our inves- tigation is guided by the hypothesis that the repairability of repair tools might not be generalized across different benchmarks of bugs.

。。。没想到,这个意义这么大的吗?

作者有一些发现:

We found that the 11 tools 1) are able to generate patches for 21% of the bugs from the 5 benchmarks, and 2) have better performance on Defects4J compared to other benchmarks, by generating patches for 47% of the bugs from Defects4J compared to 10-30% of bugs from the other benchmarks.

These causes are reported in this paper, which can help repair tool designers to improve their techniques and tools. ACM

感觉更像一片ESEM偏实证的文章。
但是这篇文章写得是确实好,很清楚,也比较完整的展示了自己的工作量。


作者两个目标:
1)看当前的工具是不是过拟合了某个benchmark;
2)分析产生不了补丁的原因。

2 idea来源

1)估计是受 patch overfitting的启发,作者想出了 benchmark overfitting

2)APR领域要做的实证太多了,

我感觉随便选选可能都是idea。。。

(不过还是要认真揣摩的。此外文笔一定要过硬)

3 亮点

1)这篇文章的写法,很值得揣摩;
比如这标题就取得很猛:

A large-scale experiment of 11 repair tools on 2,141 bugs from 5 benchmarks: this is the largest study on automatic program repair ever (i.e. 11 x 2,141 = 23,551 repair attempts);

一开始不是这样取的:

command injection修复java javiewer修复_ide

可以看出来这应该是迭代过,不断修改过的。

确实很厉害。如果可以,我都觉得应该系统的分析一下写作手法,背诵一下。

2)这个实验室的特点就是:
Extensible 很多工具都是可以扩展的。

3)To gather repair tools, we searched the existing living review on automatic program repair [32] for test-suite-based repair tools for Java, which is the focus of this work: we found 24 repair tools that meet this criterion.

这个有点意思,用的是Martin Monperrus的 Living program repair。

4)不说别的,这个review就是一个亮点;

4)
万万没想到,

command injection修复java javiewer修复_ide_02

这也是一个亮点,原因在于,作者表述的真的好。

本来我没看这段之前,我觉得好像这种non-patch的原因分析,也没有什么大不了。

但是看了之后,作者对其分析的很清楚,论据很充分。

4 不足

1)似乎没有考虑 jfix,一个基于语义的java修复工具。

2)

command injection修复java javiewer修复_sed_03

这里感觉有点不严谨。

像jGenprog,或者NPEFix不能修复的缺陷类型,其他的修复工具(existing,现有的)是可以修的,比如Nopol,比如ARJA。

所以说:new repair approaches should be created 放在这里有点奇怪。

3)

command injection修复java javiewer修复_sed_04

这个确实是一个方向,但是这个也,,,
感觉很难实现啊,
除非大家在一个框架内做approach的代码实现

但是大家都不在一个实验室,这样感觉很难实现

路走窄了。。。

更多请见:我的印象笔记。

相关文章(待阅读)

  • Ultra-Large Repair Search Space with Automatically Mined Templates: the Cardumen Mode of Astor

总结

总结就是,写一篇文章真的花时间!!!

9点半开始把,可能,大概。

最少学了1个半小时。

现在时间:2019年6月18日11:03:30


光阴似箭哇

还不晓得珍惜时间

小火☞