Page 225 - 《软件学报》2020年第9期

2846 Journal of Software 软件学报 Vol.31, No.9, September 2020

ChangeLocator [127] ,分别在方法级别和变更级别定位这种缺陷.2020 年,Guo 等人 [128] 在 ChangeLocator
的基础上对崩溃变更的特征进行选择,他们发现:过滤后的特征,能够用来构建更好的崩溃变更定位模
型;
• 对 Android 应用缺陷的定位.Android 应用与开源的桌面软件有所不同,它们运行在手机操作系统之上,
这类应用的历史缺陷报告较少,并且没有充足的详细描述信息.因此,很难将现有的 IRBL 方法直接用
于对 Android 应用进行缺陷定位.2019 年,Zhang 等人 [100] 基于提交信息,提出了一种适用于 Android 应
用的缺陷定位方法.
5.5 小 结
本节从程序频谱、变异分析、多模态和新型应用这 4 个方面简要介绍了缺陷定位领域中其他相关研究.
下面简述主要的发现:
(1) 程序频谱是主流的动态缺陷定位方法,其相关研究一直是缺陷定位领域的另一个热点;
(2) 变异分析是一种有效的动态缺陷定位方法,目前多数研究主要致力于降低这类方法的计算成本;
(3) 多模态的缺陷定位方法可以结合多种定位技术的优点,近年来也逐渐受到研究者的重视;
(4) 缺陷定位的应用已经开始逐步细分到研究具体类型的缺陷,这种趋势有利于更精细化地将缺陷定位
技术应用到实践中.
6 挑 战

从现有文献来看,IRBL 技术的相关研究已经取得了很好的成效,最新的定位方法已经能够将定位性能提升
到一个较高的层面.但是我们应当注意到,现有的研究技术在工业界中并没有被广泛应用 [39] ,因为它还难以满足
实际软件开发和维护过程的需求.本节从局限性、泛化性、准确性和实用性这 4 个角度来介绍 IRBL 领域的研
究面临着以下挑战.
(1) 局限性.目前,对 IRBL 方法的性能评估是基于该方法在一组缺陷报告上测试的平均性能值(例如
MRR).这类评估指标可以在整体上对某个方法进行评价,但是有一点需要注意:在整体上具有较高的
评估分数,不代表该方法在每个具体缺陷报告的推荐结果也令人满意 [73] .对任何 IRBL 方法来说,是不
可能对所有的缺陷报告都给出最优排序结果的.在应用一种方法时,可能会遇到以下情况:对某些(可
能仅仅一小部分)缺陷报告进行推荐时,该方法会将这些缺陷报告对应的源文件排在十分靠后的位
置.对这样的推荐结果,开发者按照列表顺序从头审查将会花费巨大的工作量.尽管这种推荐结果出
现的次数较少,但是由于开发者不知道何时会遇到这种推荐,他们会倾向于不使用该方法.上述情况
属于一个 IRBL 方法的应用局限性.能够准确分析每个 IRBL 方法的局限性十分关键,这可以在使用时
规避上述情况的发生.现有研究的一个问题是局限性分析较少,导致开发者不能够在恰当的场景下使
用这些 IRBL 方法,从而这些方法的最大优势不能被充分利用,同时在使用时不能及时避免其劣势;
(2) 泛化性.影响泛化性的因素有两点.
1) 测试数据集稀少.虽然现在已有多个公开数据集,最近两年提出的一部分 IRBL 方法 [41,64,65,79,94,99]
仍仅仅在很少的测试项目(Zhou 等人 [28] 在 2012 年提供的 4 个项目)上进行了验证.特别地,这些
项目数据大多是是由 Java 语言开发的,因此多数现有的实验结果是适用于 Java 项目的 [35] ,但是
在其他类型的项目上的性能表现未知,即 IRBL 方法的泛化性能未知.由于存在这种不确定性,目
前的方法很难受到开发人员的信任,并且他们也很难挑选出优秀的方法.因此,许多工作 [25,31,80]
指出,仍然需要在更多的项目上进行实验来测试 IRBL 方法的性能;
2) 人工设计特征.现有的 IRBL 方法的特征选取和挖掘都是人工根据某一部分的缺陷数据进行设
计的,用这种方式构建出的方法可以在可以一些数据上达到较好的效果.然而,遇到具有不同特
征的数据,这些方法的定位能力便会降低,从而就表现为泛化性低下 [68] ;
(3) 准确性.准确的实验数据集是保证定位方法质量的重要依据.现有的数据集虽然都是按照 Dallmeier