论文部分内容阅读
在软件开发过程中，每收到一个bug报告，开发人员通常需要花费大量的时间和精力来找出bug可能发生的位置。近年来，为了减轻开发人员的负担，学者们提出了一些自动化的基于信息检索或机器学习的bug定位方法。然而发现学者们在评价他们所提出的bug定位方法时使用的评价指标都是序列位置相关的，并没有考虑不同大小的源代码文件所需的审查工作量并不一样的问题，也即这些评价指标并不能说明bug定位方法是否能有效减少开发人员检测出与bug报告相关的源代码文件所需的工作量。 为探明利用bug报告进行bug定位的方法在工作量感知的评价指标下的性能，本文实现了包括近年来具有代表性的Learning to Rank(LR)和BugLocator方法、经典的Vector Space Model(VSM)方法以及朴素的Usual Suspects(US)方法在内的四种bug定位方法，并提出六个工作量感知的评价指标，最后在六个Java开源系统上进行实验，结果表明:(1)对于大多数系统，在对定位结果中的前k个文件进行审查时，LR方法所需的工作量比BugLocator方法和VSM方法更多，同时LR方法的工作量精度更低;(2)对于大多数系统，从定位结果中找出所有的或者第一个与bug报告相关的源代码文件时，LR方法所需的工作量比BugLocator和VSM方法多，同时尽管LR方法拥有较高的工作量精度，LR方法的性能仍有较大的提升空间;(3)LR和BugLocator等复杂的bug定位方法在工作量感知的评价指标上的表现并不优秀。 由于之前的研究表明在使用序列相关的评价指标对LR方法、BugLocator方法、VSM方法以及US方法进行评价时LR方法的性能比另外三个方法的性能都要优秀，因此本文的实验结果证实了基于序列位置的评价指标不能准确地反映一个bug定位方法的性能，在对基于信息检索或机器学习的bug定位方法进行评价时需要考虑源代码审查工作量对bug定位方法性能的影响。