引用
Mohsen A M, Hassan H, Wassif K, et al. Enhancing bug localization using phase-based approach[J]. IEEE Access, 2023.
论文：https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10097736
摘要
软件错误定位是软件维护过程中的一个重要步骤。自动错误定位可以减少定位过程中所消耗的时间。一些技术被应用于bug定位过程中，但这些技术在时间和准确性上受到限制。本文提出了一种基于相位的bug定位方法来克服这些限制。该方法由三个主要阶段组成，即原始数据准备、软件包分类和源代码推荐。我们的方法的主要输入是一个错误报告和针对感兴趣的目标系统的过去版本的源代码。从bug报告中，使用了各种信息：摘要、描述、堆栈跟踪和固定的源代码文件。原始数据准备阶段用于重组这些输入。包分类阶段的目的是定位包含要修改的源代码的包作为第一步，从而减少了由于源代码文件和错误报告数据之间的词汇不匹配而定位源代码文件所需的时间。来自变形金刚的双向编码器表示法（BERT）是一种句子嵌入技术，用于软件包分类和源代码推荐阶段。实验结果表明，根据TOP-N秩和平均倒数秩（MRR）评价指标，该方法优于现有的方法。
引言
构建软件的主要软件过程是软件规范、软件设计、实现、软件验证和软件演化。软件发展阶段包括适应新的需求以及修复发现的错误。这个阶段是软件生命周期中最长的阶段，并且消耗了高达70%的时间。错误定位是软件发展过程中最重要的任务之一。错误定位是指在操作过程中发现软件中出现的错误或错误的过程。手动定位错误是一个昂贵而耗时的过程。
许多自动错误定位技术被应用于查找软件中的错误。不同的软件工件被使用于将bug定位为源代码、过去的bug报告和测试用例。该错误报告是一个说明在软件中出现的错误的文档。错误报告由错误总结、描述、堆栈跟踪和错误元数据组成，比如谁报告了错误，谁解决了错误。一些技术直接利用错误报告的文本，以便使用信息检索技术找到错误的位置。这种技术利用了bug报告文本和不同源代码文件之间的相似性度量。计算出的源代码文件的相似度分数按降序排序，以找到与bug报告最相关的源代码文件。其他技术利用机器学习来查找错误，通过提供过去已解决的错误的信息来训练模型。
上述技术有三个主要的限制： (1)缺乏bug定位工件(2)上下文不匹配(3)增加了在大型代码库中定位bug的时间。我们将讨论上述这些限制。
限制1：（缺少bug定位构件），一些技术利用旧的bug报告来定位bug。如果所分析的项目是一个不包含任何历史错误报告的新项目，那么这种技术将无法工作。
限制2：（上下文不匹配），信息检索技术只考虑源代码文件的文本来计算相似性度量，而在分析过程中不考虑被分析文本的上下文。如果考虑到这样的上下文将提高分类精度。
限制3：（错误定位时间），一些信息检索技术使用新的错误报告文本和所有源代码文件文本之间的相似度度量，需要大量的时间来应用相似度为了克服上述过去技术的局限性，提出了一种基于阶段的方法。该方法包括三个主要阶段。原始数据准备阶段用于准备不同的软件构件，如bug报告文本和源代码文件。此外，如果可以结合源代码文件文本和旧的错误报告文本，从而克服了限制1。此外，如果旧的错误报告不可用，则只能使用可用的源代码文件来定位错误。利用BERT的软件包分类通过只推荐一个软件的软件包来解决限制3。推荐阶段通过缩小搜索空间，减少了查找有问题的源代码文件的搜索时间。源代码文件推荐阶段通过考虑源代码文件文本的上下文，输出特定的有错误的源代码文件，从而克服了限制2。
本文的主要贡献总结如下：
1) 改进了错误定位技术，通过一种新的错误定位方法适用于没有历史错误报告的项目。
2) 引入了一个包分类阶段来产生推荐的包，以克服时间问题。包分类阶段通过推荐bugg包减少了搜索空间。推荐的软件包由明确的源代码文件组成，而不是项目的所有源代码文件。
3) 我们评估了在两个不同数据集上的基于阶段的bug定位方法的准确性和bug定位所需时间方面的性能。我们的方法实现了一个考虑到时间和准确性的增强。
本文的其余部分将划分如下：第二节描述了所提出的方法。第三节介绍了用于验证所提出的方法的实验和评价。第四节提出了对有效性的威胁。第五节介绍了相关工作，第六节总结了论文。
1 提出的方法
图1 本文修复方法流程图
在本节中，我们将提出所提出的基于相位的bug定位（PBL）方法。如图1所示，该方法包括三个主要阶段： (1)原始数据准备、(2)软件包分类、(3)用于修复的源代码文件建议。
原始数据准备阶段包括准备感兴趣的项目的分析工件。对于任何项目，以下工件作为数据准备阶段的输入： (a)旧的解析错误报告，(b)该项目的源代码及其包的结构，(c)需要定位和修复的新错误报告。这些软件工件将从一些软件的错误跟踪系统和版本控制系统中提取出来。原始数据准备阶段的输出是一种结构化和有组织的错误报告和源代码文件的进一步处理形式。
软件包分类阶段是一个对不同特征进行了训练的分类器。此阶段的输出将是包含该bug的软件项目的推荐包。通过首先对bug源代码文件进行定位，需要减少定位源代码文件所需的时间。时间复杂度降低了，因为结果是一个很可能包含错误的推荐包。该阶段有助于源代码文件的下一阶段缩小要搜索的源代码文件的搜索空间。
源代码文件推荐适用于输入bug报告的推荐包和堆栈跟踪，如果可用来推荐包含bug的文件。
为了表述这个问题，我们使用符号NBR来表示新的错误报告。此外，符号RSF指的是由我们的方法产生的源代码文件的排序列表。每个软件项目都将用SP表示，它由一个软件包列表PSP∈SP组成。因此，PSP = {psp1，psp2...pspp}，其中P是软件包的数量。此外，一个源代码文件列表将得到符号PSF∈PSP∈SP，然后是PSF = {psf1，psf2...psfF }，其中F是源代码文件的数量。每个源代码文件都由术语PSFT组成，它表示类的名称、方法、变量和注释。另一种表示法是BRR，它表示从项目错误存储库中提取的旧错误报告的列表。此外，BRR由旧的错误报告组成，BRR={obr1，obr2…其中R是系统中错误报告的数量。位于错误报告中的非结构化自然文本，如错误摘要或错误描述，将用BRTN∈NBR表示新错误报告中的文本，用旧错误报告中的BRTO表示。STR将表示位于错误报告或旧错误报告中的堆栈跟踪。
因此我们的问题将被表述为找到一个排名源代码文件列表RSF为一个给定的新错误报告NBR包含文本NBR和可能堆栈跟踪STR给出软件PSP软件，PSF源代码文件及其术语PSFT。除此之外，一个旧错误列表报告BRR及其文本BRTO。
A.原始数据准备
在这个阶段，该方法的所有输入（bug报告和源代码文件）将被收集和预处理。第一个任务是错误报告数据的提取和准备工作，它将旧的错误报告作为来自发布错误报告的错误跟踪系统的输入。第二个任务是源代码文件的提取和准备，通过将来自版本控制系统的具有不同版本的源代码文件作为输入，将它们以结构化的形式呈现。然后，执行文本处理和文本组合任务，生成结构化的bug报告和结构化的源代码文件。这些结构化的信息将作为一揽子建议阶段的输入。我们分别解释这三个任务。
1) BUG报告的提取和非结构化文本信息
项目名称、项目版本、数据报告时间、错误报告状态和受让人都是错误报告的结构化元数据，这些元数据在错误报告中的特定字段中已经可用。图3展示了从JDT软件项目的Eclipse错误跟踪系统中提取的真实bug报告。bug报告描述不是有组织的形式，而是英文文本、源代码和堆栈跟踪的混合。结构化表单将把英语文本与堆栈跟踪和源代码分开。这样的步骤是必要的，因为bug报告中的每个项目都将对bug定位过程有特殊的预处理。非结构化数据将出现在错误摘要和错误描述中。这种用英语自然语言编写的文本数据需要有组织和分离。bug描述可能包含不同类型的信息，如英文文本、堆栈跟踪和源代码文件。这些信息都可以作为一个文本单元混合，而在输入错误报告中没有任何分离。
2) 源代码的提取和准备
首先，从软件项目的版本控制系统中提取不同的软件包及其不同版本的源代码文件。然后，通过浏览不同的文件并将它们放成有组织的形式来应用准备阶段。每个源代码文件的有组织形式由项目名称、文件名、项目版本、文件路径、文件的主包、提交号和源代码文本组成。之后，源代码项提取子任务将把源代码文件文本作为一个单元。然后，输出将以分隔的形式显示为（类名、方法名、标识符和代码注释）。组合子任务将通过添加引用到源代码或旧错误报告的文件和包来修改旧错误报告和源代码文件的结构化形式。
3) 文本预处理与组合
在应用错误报告和源代码提取和准备任务后，由错误报告和源代码文件同时应用的任务将被转换为结构化形式。对这些文件需要进行进一步的预处理。首先，bug报告中的文本通过自然语言处理步骤，如（令牌化、停止单词删除和词移）。由于这一步，我们有一袋用于错误报告和源代码文件的单词。另一个子任务在这里应用于源文本项，它是编程术语拆分。如果我们有一个方法名为“添加”的两个数字，它将被划分为[“add“”、“两个”、“数字”]。这一步将增强文本检索或匹配相似性的过程。此外，此子任务将应用于源代码项和注释。
B.包装分类阶段
这个阶段的输出将主要是包含该错误的软件包。这一阶段用于减少源代码文件推荐所需的时间，并提高推荐文件的准确性。为了减少推荐包含该bug的源代码文件所需的时间，我们需要减少将用来计算文本相似度的源代码文件的数量。例如，一种文本相似度方法必须对JDT数据集中的8000多个文件应用文本相似度，以定位要修复的源代码文件。为了减少这样的文件数量，我们的方法将从推荐一个源代码包开始，其中这样的包将在其文件中固定源代码文件。在找到推荐的包后，文本相似性将只应用于该包中的源代码文件。例如，如果我们的方法在JDT数据集中推荐包“ASTview”，我们将需要只对该包中的7个文件运行文本相似性分析，而不是对JDT数据集中的8000个文件运行。我们的方法有望提高推荐的准确性。一些源代码文件或方法可能在不同的包中使用相同的名称，因此限制了在推荐的包中的搜索，将从相似性匹配中丢弃这些文件，从而提高源代码文件推荐的准确性。
该方法的另一个重要优点是能够在不同的情况下工作。当一个软件项目的输入数据只是源代码文件时，我们的方法就可以工作了。此外，我们的方法也处理了旧的错误报告的存在。源代码文件和bug报告表示输入的训练记录，以便在此阶段首先对软件包进行分类。因此，如果旧的bug报告不可用，该方法将通过使用用其包标记的可用源代码文件来找到有问题的源代码文件。包分类阶段包括三个主要任务：对BERT模型的数据进行预处理、应用BERT模型，对BERT模型进行微调。
C.源代码推荐阶段
在包分类完成后，我们得到了将包含该bug的推荐包。如果新的bug报告包含一个堆栈跟踪，则也将考虑此堆栈跟踪中的文件。随后，将推荐的包源文件和过去的相关错误输入到特定的任务中。此外，一种文本相似性技术，即句子BERT，将采取新的bug报告结构化文本来获得最相似的源代码文件，如果附加了旧的bug。源代码推荐阶段的输出将是一个源代码文件的列表，根据它们与需要修复的新错误报告的相似性按降序排序。
句子嵌入的使用对于输入文本的句子编码具有重要意义。在这个任务中，另一个使用BERT的微调用于直接的文本相似性。错误报告的新文本与上一阶段推荐的软件包相关的所有文件之间的文本相似性。根据句子，应用BERT对BERT体系结构进行语义相似度的微调。来自源代码文件的输入和从软件包中的相关数据将被输入到预先训练过的BERT中。输入将是一对记录，以训练BERT获得它们之间的相似之处。之后，模型将使用文本进行训练，以进行嵌入。
下一步是利用位于BERT层顶部的最大池化层。池化的作用是组合一个输入记录的每个令牌向量。此外，它还为这两个输出的句子给出了一个固定的句子。将两个句子向量量化后，将使用余弦相似度计算这两个向量之间的相似度，余弦相似度作为度量，得到新错误报告与特定包相关的所有源代码文件和数据之间的角度。因此，这些结果的最高分数将代表与新的错误报告数据最近的源代码文件。
2 实验和评估
实验设计与程序
为了回答我们的研究问题，我们必须选择一个具有我们的方法所需输入的数据集：来自错误跟踪系统的旧bug报告，以及来自版本控制系统的不同版本的源代码文件及其包。
为了回答我们的研究问题，我们将把我们的方法应用于上面提到的JDT和月食数据集。对于每个数据集，我们将使用90%的数据集作为训练数据，其余的10%作为测试数据。因此，我们将使用一些以前修复的bug来评估我们的方法是否会正确地推荐需要修复的相关源代码文件。
为了评估该方法在所有研究问题上的准确性，每个数据集将被分成10倍交叉验证，如应用过去的一些实验。这10个折叠将被分成9个折叠用于训练，假设其中一个是不固定的用于测试。这个过程将重复10次，因为每次10次折叠中的一次将用于测试。，其余的折叠将用于训练。然后，计算Top-1、5、10、20测量的所有褶皱结果的平均值。
对于RQ1，我们的方法将应用于这两个数据集。对于RQ2，我们将应用我们的方法两次：一次带有堆栈跟踪，另一次不带有堆栈跟踪，并比较它们的准确性。对于RQ3，我们将应用我们的方法两次；一次在使用包推荐阶段，一次在不使用包推荐阶段，并比较它们的准确性和时间。对于RQ4，我们将把我们的方法的结果与其他使用相同数据集的最先进的方法，并使用相同的指标，我们报告的方法进行比较。
实验结果及讨论
回答RQ1：我们的方法对错误定位有什么影响？
我们将我们的方法应用于JDT和Eclipse平台数据集来衡量bug定位性能。MRR对JDT数据集的平均值为0.29，对日食平台的平均值为0.27。图2和图3显示了对JDT和Eclipse平台数据集的每个折叠的Top-N结果。如上所述，从10次折叠中提取的每个折叠将用于测试，其余的折叠将用于训练。每个折叠在x轴上显示，根据Top 1、Top15、Top 10和Top 20指标的精度结果在y轴上显示。图6和图7表明，在这10个文件中的结果很接近，这意味着我们的方法在两个数据集上的性能都是稳定的。
图2 JDT平台数据集的交叉验证的Top-N结果
图3 Eclipse平台数据集交叉验证的Top-N结果
回答RQ2：堆栈跟踪的使用会影响我们的方法结果吗？
我们在JDT和Eclipse平台数据集上利用堆栈跟踪数据时应用了我们的方法。MRR对JDT和月食平台的检测结果也分别为0.33和0.31。
为了评估使用堆栈跟踪是否会提高准确性，我们在两个数据集上不使用堆栈跟踪的情况下应用了我们的方法，并将这些结果与我们之前使用堆栈跟踪时的结果进行了比较。结果表明，使用堆栈跟踪提高了跨前n级和MRR指标的两个数据集的准确性。
回答RQ3：软件包推荐阶段是否会影响错误定位的时间和准确性？
为了回答这个问题，我们必须测试软件包推荐阶段的效果，我们比较了在应用软件包推荐阶段和不应用该阶段时，我们的方法的时间和准确性。
考虑到时间方面：实验结果显示了在我们考虑时间方面的方法中使用软件包推荐阶段的重要性和积极影响。
考虑到准确性方面：我们分别比较了对于JDT和Eclipse平台数据集，在应用软件包推荐阶段和删除该阶段时的准确性。与未删除软件包推荐阶段相比，前1、5、10、20之间的值（0.19、0.39、0.49、0.54和0.31）下降了约0.01。然而，MRR保持不变，这意味着不使用软件包推荐阶段对我们的方法产生了负面影响。结果显示，Top 1（0.25）精度度量降低了0.02，Top 5（0.49），MRR保持不变。所进行的实验表明，利用软件包推荐阶段在改善我们的方法的时间方面有很大的作用，并且不会妨碍性能。此外，据我们所知，没有其他研究在包分类层的工作。
回答RQ4：我们的方法是否优于其他bug定位方法？
(1) 为了评估我们的方法的有效性，我们必须根据两个重要的方面来评估我们的工作，即时间和准确性，与最先进的bug定位方法相比。
考虑到前5个评价指标，我们的方法优于上述所有最先进的方法，即5种方法。我们的方法和上述方法之间的前5名排名的比较，其中我们的方法在该度量中优于所有这些方法。
考虑到前10位的评价指标，我们的方法和上述方法在前10名中的排名。我们的基于阶段的方法优于其中的三种方法。此外，我们的方法得到0.57，cFlow得到0.77。然而，cFlow只对JDT数据集中的6274个错误报告中的5016个错误报告应用了他们的方法。
考虑到MRR评估度量，我们的方法优于所有提到的使用该评估度量的先进技术。我们基于阶段的方法将BugLocator（0.24）提高了10%，NP-CNN（0.23）提高了11%，Jingo（0.32）提高了2%。此外，我们的方法得到了0.34，cFlow得到了0.55。然而，cFlow只对JDT数据集中的6274个错误报告中的5016个错误报告应用了他们的方法。
考虑到时间评估度量，我们的工作超过了STMLocator ，因为这种技术提供了时间来找到一个包含错误的文件的源代码文件。我们的工作建议JDT数据集在50.4毫秒内定位错误的源代码文件，而STMLocator在800毫秒内定位错误的文件，因此，我们的方法减少了大约750毫秒的时间。
转述：沐燕舟
