文章目录
- 前言
- 基本信息
- 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);
一开始不是这样取的:
可以看出来这应该是迭代过,不断修改过的。
确实很厉害。如果可以,我都觉得应该系统的分析一下写作手法,背诵一下。
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)
万万没想到,
这也是一个亮点,原因在于,作者表述的真的好。
本来我没看这段之前,我觉得好像这种non-patch的原因分析,也没有什么大不了。
但是看了之后,作者对其分析的很清楚,论据很充分。
4 不足
1)似乎没有考虑 jfix,一个基于语义的java修复工具。
2)
这里感觉有点不严谨。
像jGenprog,或者NPEFix不能修复的缺陷类型,其他的修复工具(existing,现有的)是可以修的,比如Nopol,比如ARJA。
所以说:new repair approaches should be created 放在这里有点奇怪。
3)
这个确实是一个方向,但是这个也,,,
感觉很难实现啊,
除非大家在一个框架内做approach的代码实现
但是大家都不在一个实验室,这样感觉很难实现
路走窄了。。。
更多请见:我的印象笔记。
相关文章(待阅读)
- Ultra-Large Repair Search Space with Automatically Mined Templates: the Cardumen Mode of Astor
总结
总结就是,写一篇文章真的花时间!!!
9点半开始把,可能,大概。
最少学了1个半小时。
现在时间:2019年6月18日11:03:30
光阴似箭哇
还不晓得珍惜时间
小火☞