autohotkey自动选定文本_文本挖掘和数据挖掘技术结合的Bug报告分类方法

原文：Combining Text Mining and Data Mining for Bug Report Classification

摘要

分类错误的Bug报告不可避免地会影响Bug预测模型的性能。手工检查有助于减少噪音，但却给开发人员带来了沉重的负担。本文提出了一种将Bug报告的文本挖掘和数据挖掘技术相结合的混合方法，实现了Bug报告的自动预测过程。第一阶段利用文本挖掘技术来分析Bug报告的摘要部分，并将它们分为三个概率级别。在第二阶段中，将提取的特征和Bug报告的一些其他结构化特征输入机器学习器。数据嫁接技术被用来连接这两个阶段。为了与之前研究中的实现对比，我们在相同的数据集——三个大型开源项目上进行实验，在整体表现方面，始终在最佳结果的基础上取得了合理的提高(分别为77.4%~81.7%、73.9%~80.2%和87.4%~93.7%)。另外，本文还在另外两个流行的开放源代码存储库进行的比较实验证实了这一发现，并证明了我们的方法的优点。

1 引言

近年来,基于从存储库收集的数据预测软件缺陷的各个方面——例如数量、位置或严重性的兴趣越来越大[1]、[2]、[3]、[4]。为了有效地识别这些缺陷，从而降低整体维护成本，文献[5]中提出了许多统计模型。一般来说，这类模型依赖于历史信息来进行预测。在众多的信息源中，Bug追踪系统(BTS)由于拥有丰富的缺陷信息以及在实践中的广泛应用而显得尤为重要[6]。

然而，就像其一般意义上的那样，保存在BTS中的Bug报告除了真实的(纠正性的)Bug描述之外，还可以记录改善性或适应性等维护方面的内容。正如 Antoniol等人[7]以及[8]、[9]所观察到的，大量被标记为有Bug的文件实际上并未有Bug(假阳性)。由于准确/高质量的数据集始终是任何有效的实证分析的前提，错误分类的Bug报告不可避免地会引入偏差，从而影响预测性能，使得到的结果令人怀疑甚至产生误导[8]，[10]。仔细检查文档以确定真正的Bug报告不仅是必要的，而且是这些预测工作有效性的基础。手动分类有助于减少噪音，但是当报告数量增加时，相关的时间和额外的成本使其成为不切实际的选择。因此，一种自动机制来判断一个给定的Bug报告是否正确可以更好地提高生产力。

Antonio等人[7] 研究了利用传统文本挖掘技术实现Bug报告自动分类，证明了其可行性。然而，这项工作只考虑了报告的描述部分(自由文本)。典型的Bug报告实际上是由一组固定的属性和非正式的叙述组成的半结构化文档。描述(包括讨论)和摘要部分的内容实际上是用自然语言编写的非结构化自由文本，甚至会包括计算机生成的堆栈轨迹。然而，其他字段通常具有有限或定义良好的值，例如严重性、优先级、组件、关键字等，这些字段构成文档的结构化方面。因此，如图1所示，这些报告呈现出一个混合的特性。

Bug报告结构

令人惊讶的是，先前很少有工作正式将这些因素纳入分类结果的考虑范围。在某种程度上，诸如[3]、[11]、[12]、[13]、[14]等文章已经开始研究非结构化文本和一些选定字段之间的关系。我们认为这种结构化信息是一种有价值的资产，它的包含有助于改进Bug预测模型[15]，[16]。

本文通过文本挖掘和数据挖掘技术相结合的混合方法来回答给定的Bug报告是否是正确的Bug报告的问题。与单纯的文本描述挖掘相比[7]，我们还考虑了结构化信息以提高预测准确率。我们对从五个大型开源项目中随机选择的3200多个Bug报告进行了广泛的实证研究，以验证我们的方法。总的来说，我们的工作做出了以下贡献：

1. 我们证明了结合多个Bug报告字段以进行预测的好处。据我们所知，这是第一次将Bug报告中的普通文本信息(描述、讨论、摘要等)之外的几种不同的特征源进行组合，以预测Bug报告是否正确的实证研究。
2. 我们提出了一种混合方法，允许组合适合不同性质信息源的模型。它本质上是开放的，独立于任何特定的挖掘算法。本文研究了5个大型开源项目的Bug报告，其中3个与[7]中的相同，分别是Mozilla、Eclipse、JBoss。通过对比研究，证实了本文方法的有效性。
3. 我们使用我们的方法来分析另外两个知名的开源项目的Bug报告，即Firefox和OpenFOAM。一方面，检查结果证实了现有报告[8]、[9]中关于存在相当大一部分噪声的结论；另一方面，在所有五个案例中，实验结果再次表明，我们的方法在性能改进方面优于基本的单个分类模型。

2 背景

Bug报告由BTS管理，由软件测试人员或最终用户归档。一个好的Bug报告应该包含Bug的详细信息，以便重现它。通常，Bug报告包括一组固定的字段，如发现Bug的日期和时间、详细描述和一行摘要、报告者认为的Bug的严重性和优先级以及出现Bug的产品组件等。提交Bug报告时，测试者将检查内容并确定它是否有效以及应该由谁来处理它。基本上，如果一个报告已经被确认和验证，它的状态就变为NEW。一旦开发人员开始处理它，状态就变为ASSIGNED，并最终达到RESOLVED或CLOSED。由于报告者通常对底层软件有不同程度的经验和知识，因此提交的报告质量参差不齐。如[17]所述，编写良好的Bug报告比编写糟糕的更容易引起开发人员的注意。

文本分类涉及将预定义类别分配给文档的过程[18]。它可以看作是从一组类别C={，…，}，(m≥2)到一组文档D={，…，}的映射f，从而产生布尔决策矩阵。

在值矩阵中，如果允许每列中有多个值为真，则通常称为多标签分类；而每列中只有一个值可以指定为真的情况称为单标签分类。在单标签分类中，有一种特殊的情况，其中正好有两个类别，即C={，}，被定义为二进制分类，否则被定义为多分类[19]。在我们的研究中，我们需要判断一个给定的Bug报告是否是正确的，即Bug或Non-Bug，因此它属于二进制分类问题。

预处理是文本分类中的一个关键步骤，它产生了文本描述的相对规范表示。典型的预处理流程通常包括以下步骤：分词、删除停用词和词干化处理。分词是通过去掉所有标点符号，用单个空格替换制表符和其他非文本字符，将文本文档分割成词流的过程[20]。随后从原始文档中提取一组单词。然而，许多常用的词，如命题、连词、冠词，实际上是为了语法的正确性，而不是传递内容信息，这些词被称为停止词。由于停止词的出现频率太高，无法促进文档之间的差异，在大多数情况下，会将它们从分词后获得的词集中删除。词干化处理将相关词映射到它们相同的基本形式，从而可以大大减少词的索引大小。例如，单词“modifications”、“modifies”、“modified”和“modify”都可以简化为同一个根“modif”。

给定一组分类器，有些会产生比其他更好的结果，但每个分类器的错误分类模式集不一定会重叠。这表明不同的分类器可能提供关于要分类的模式的补充信息，可以利用这些信息来提高所选分类器的性能[21]。因此，分类器的组合可以获得比个体更好的性能。一般来说，分类器集成有两种应用场景。在第一个场景中，所有的分类器使用相同的输入模式表示；在第二个场景中，每个分类器使用不同的输入模式表示[21]。由于在我们的案例中，Bug报告在结构方面具有混合特征，因此我们的研究属于第二种情况。

3 方法

本文方法的步骤如下：

(1)第一阶段：使用每个Bug报告的摘要部分，并将其分类为作为纠正报告的离散级别。分类是通过特定的文本挖掘算法来实现的。在我们的研究中，我们使用多项式朴素贝叶斯分类器，定义了{high、middle、low}三个可能性级别。输出的级别被视为从这些非结构化文本中提取的特征。

(2)第二阶段：使用每个Bug报告中结构化特征的子集以及从第一阶段提取的特征。这些特征和它们的具体值被输入机器学习器来计算一个预测，然后可以进行分析。在我们的研究中，我们使用贝叶斯网络分类器作为机器学习器。

(3)数据嫁接：连接这两个阶段。它收集第一个文本分类器的输出，定位存储库中存档的相应Bug报告，并将其与来自同一报告的其他选定特征合并。数据嫁接的输出是机器学习器在第二阶段的输入。

我们在这两个阶段中的每一个阶段都使用监督学习，这意味着实例是手动预先标记的。图2概述了我们的方法，下面将详细说明每个阶段。

方法框架

3.1 第一阶段：对摘要部分进行分类

在这个阶段，主要关注的是对Bug报告的文本部分进行分类。通常以自由文本的形式的有两个主要的信息来源：摘要和描述。在[22]中，Ko等人对人们如何在Bug报告中描述软件问题进行语言分析并得出结论：一行摘要(title)的基本内容几乎与很长的描述相同，且摘要可以相对准确地解析。在随后的工作中，Lamkanfi等人[3] 通过广泛的实证研究来证实这些发现。事实上，摘要通过省略不必要的细节，将相同的信息提炼成一行句子。这种差异直接影响到自动化分析。由于描述往往要长得多，信息变得分散且更难提取。这导致依赖于它的自动预测模型的性能下降。因此，在我们的方法中只考虑摘要部分。

我们没有直接给出“yes”或“no”的答案，而是将摘要分为三个概率级别，即{hig、middle、low}。这样做是为了模拟人工检查过程。与手工检查一样，我们经常会遇到一些报告，根据摘要本身很难判断其类别。例如，在OpenFOAM BTS中，报告ID#249的摘要显示“solution of reactingFoam is strongly dependent on time step size”，而在Firefox BTS中，报告ID为#330061的摘要显示“Allow only one Places window”。在不依赖于其他信息时这些摘要是模棱两可的，因此在这两种情况下都可能是功能请求或缺陷。

为了对这些摘要进行手动分类，我们采用了[8]中提出的启发式分类法，但进行了适当更改。在[8]中，Herzig等人列出六类Bug报告，即{Bug，RFE，IMPR，DOC，REFAC，OTHER}，它们清楚地区分了解决任务所需的维护工作。由于Bug报告的细粒度分类超出了本文的范围，我们更感兴趣的是二进制分类，即Bug和Non-Bug。因此，我们将[8]中枚举的除BUG之外的其他类别归为一个单独的类别Non-Bug。此外，在本阶段我们仅将信息域限制在摘要部分。前三位作者检查了这些摘要，并对其可能性进行了独立评估。如果摘要明显符合Bug或Non-Bug的规则，则分别标记为high或low。如果它是模棱两可或很难决定，它被标记为middle。为了做出最终决定并解决冲突，采用了多数票机制[7]。一个罕见的情况是，每个检查者为同一个摘要分配不同的值。这种冲突将通过讨论解决，直到达成共识。尽管这些标签在文本分类的意义上只是毫无意义的符号，但它们可以作为最终分类的置信指数。

摘要的预处理包括分词、删除停用词和词干化处理。首先，这些摘要被拆分成由空格字符分隔的单词集。其次，删除无意义的停止词，如“an”或“the”，以减少索引空间。第三，这组词又被还原为词根形式。我们利用Lucene[3]中Analyzer组件的api来简化预处理。经过预处理步骤，剩下的单词都是小写的。

然后，可以将获得的词语加载到文本分类器中。在众多的概率分类器中，朴素贝叶斯(Naive Bayes)可能是最受欢迎的概率分类器模型[23]。假设文档向量的任意两个坐标在统计上相互独立，这使得它在分类的实际应用中是一个简单而有效的选择[20]。各种各样的研究[7]、[24]、[25]、[9]、[3]、[26]利用这种模型。在我们的方法中，我们在第一阶段使用多项式朴素贝叶斯分类器。

基于多项式朴素贝叶斯模型，在我们的研究中，一个摘要s在类别c∈{high，middle，low}中的概率计算如下：

朴素贝叶斯计算

P(|c)是在一个Bug报告属于类别c时词语出现的概率。是摘要s中有意义的词的总数，P(c)是一个Bug报告属于类别c的概率。

分类器将摘要赋予给结果在三个类别中最高的类别。我们使用WEKA[28]工具集自动化频率和概率的计算。

3.2 第二阶段：机器学习

摘要已经离散化为预定义的三个级别，并与Bug报告的其他选定字段相结合。在第二阶段，这些实例可以输入到针对结构化数据进行调整的普通机器学习器中。特别地，我们使用贝叶斯网络分类器，因为它能有效地捕捉潜在的因果关系。贝叶斯网络分类器不同于朴素贝叶斯模型的特征独立性假设，它通过条件概率来表示特征之间的依赖关系。这可以用来对文献中确定的Bug报告的特征相关性进行建模，例如[11]、[29]、[3]、[12]、[13]、[14]等。

贝叶斯网络有两个基本要素。一种是具有变量节点和关系弧的有向无环图形结构；另一个是与模型图中每个节点关联的条件概率表。该表表示关联图节点的条件概率分布。基于贝叶斯概率推理，可以从统计数据中估计出条件概率，并沿网络结构到目标标签的链路传播。给定一个类别集合C={，…，}和一组变量值E={，，…，}，可以如下计算最终概率并作为最终决策的指标。

贝叶斯网络1

根据基本的统计理论，可以通过产生具有父节点的局部分布来计算E的联合概率，即：

贝叶斯网络2

如果ei没有父节点，P(|ParentOf())等于P()。在我们的方法中，训练集的结构绘制和概率表生成可以通过WEKA实现自动化。特别地，我们使用内置的SimulatedAnnealing算法和SimpleEstimator算法作为阈值控制[28]。

3.3 数据嫁接

在第一阶段中，输入是摘要部分的预处理后的向量(带有监督学习的预标记可能性)，输出是可能性级别；而第二阶段的输入是其他字段和从上一阶段提取的特征组合成的集合。

第一阶段的输出和第二阶段的输入之间可能存在格式不匹配。我们提出了一种称为数据嫁接的技术来平滑这两个阶段之间的链接。在文本分类阶段，报告ID不包含在分类器中，唯一的输入是一系列词干和预标记级别(来自监督学习)。因此，我们需要跟踪WEKA中训练和预测实例的划分策略，并将结果与相应报告中的其他特征合并。我们假设划分是基于实践中常用的n折策略。算法1给出了嫁接技术。

数据嫁接算法

算法的输入是具有完整特征的实例集，其中摘要已经过预处理(带有用于训练的预定义“可能性”标签)，输出是预测的“可能性”更新后的实例集，即第二阶段所需的格式。

4 实验

为了评估我们的方法，我们从五个大型开源项目中随机收集了3200多个样本。在所有项目中，这些样本都是手动标记的。首先，对摘要部分单独进行分析，并由独立的检查员对其作为纠正缺陷报告的可能性进行评级。然后考虑其他字段，作出最后决定；对可能发生的冲突进行多数表决。根据10折交叉验证方法，将样本分为训练集和测试集。接下来，我们将依次描述实验设置、性能指标和评估结果。

4.1 实验设置

表一总结了我们实验中使用的Bug报告信息。由于基线工作的原始数据集[7]对我们来说是不可获得的，但为了保持一致，我们使用了相同的存储库，即Mozilla、Eclipse和JBoss。此外，我们的样本数量处于类似的数量水平(实际上，我们故意收集更多的样本，以使分类更加稳定，从而使比较更加可靠)。另外两个例子即Firefox和OpenFOAM，也证明了我们方法有广泛的可行性。五个项目中有四个使用Bugzilla(或其变体)，另一个使用Mantis。在这五个数据集中，我们只考虑那些处于RESOLVED或CLOSED状态的报告以避免重复，并排除那些自动生成和提交的Bug报告，这与[7]中使用的策略相同。

Bug报告信息

我们的分析考虑了给定Bug报告的多个字段，即文本摘要、严重性、优先级、组件、指派人、报告者。如前所述，文本摘要部分在第一阶段进行了处理，提取的特征与其他特征相结合并在第二阶段输入分类器。数据集的解析、提取和组合是通过程序自动完成的。第一阶段采用多项式朴素贝叶斯文本分类器，第二阶段采用贝叶斯网络分类器。我们实验中使用的WEKA版本是3.7.11。

4.2 度量指标

在[7]中，Antoniol等人使用信息检索度量指标中的评估标准。由于我们需要一种方法来衡量我们的方法的性能，并与以前的模型进行比较，所以我们对精确率和召回率感兴趣。精确率用于度量预测集的精确性，而召回率则用于评估预测集的完整性。精确率和召回率计算如下：

precision&recall

基于精确率和召回率，我们可以计算如下的f值，它表示精确率和召回率之间的平衡和差异。

f值

为了给出一个整体的性能评估，我们使用两个类别的f值的加权平均值。公式7描述了计算平均f值的公式，其中平均f值表示为f-，Bug类(Non-Bug类)的f值为f-(f-)，Bug类(Non-Bug类)的数目为()。

平均f值

4.3 性能分析

基于以上设置，我们进行了一组实验(包括三部分)来验证我们的方法。第一个实验是与基线工作[7]进行比较，在相同的三个项目上进行实验；第二个实验是为了与各个阶段的单个分类器及其相应的特征作为输入时的性能进行比较；第三个实验也是与单个分类器的性能进行比较，但输入时所有相关的特征。后两个实验是在所有五个项目上进行的。

(1)实验1：我们遵循Antoniol等人论文中描述的相同实验设置。为了使比较尽可能客观，我们使用相同的分类算法(Naive Bayes，ADTree，Logistic regression)，相同的预处理技术(分词和词干化处理，但没有删除停用词)，相同的特征选择策略(对称不确定性)和参数(20-50-100特征)，同样的验证方法(10折交叉验证)。

表二比较了文献[7]提出的方法和我们的方法的实验结果。[7]中的特征选择有两种情况。第一种情况下，Mozilla和Eclipse选择对称不确定性方法推荐的前20个特性，JBoss选择前50个特性；第二种情况下，Mozilla和Eclipse选择前50个特性，JBoss选择前100个特性。由于在第二种情况下包含了更多的特性，因此结果总体更好，但JBoss有一点例外。在基线工作中，逻辑回归模型的实验结果最好。我们忠实地重复了这些实验，但由于空间限制，这里只展示逻辑回归模型取得的结果。

实验1表

从表中我们可以看出，我们的方法在所有三个项目中的加权平均f值始终优于基线工作。图3展示了比较。尽管绝对增长的值并不显著，但如果我们考虑基线的结果比较高，因此增强结果仍然令人满意。特别是在JBoss中，我们将Bug的加权平均f值从0.898提高到0.952，将Non-Bug的加权平均f值从0.831提高到0.910。这些结果表明我们的方法在实践中是非常适用的。

实验1图

(2)实验2：我们的方法本质上是预测模型(或分类器)的结合，每个模型都适合不同性质的输入特征。我们需要回答这样一个问题：模型的组合是否比单个模型表现得更好。为了评估可行性和通用性性，我们在实验中还包括另外两个大型开源项目，即Firefox和OpenFOAM。由于我们将多项式朴素贝叶斯模型和贝叶斯网络模型相结合，我们需要用相应的输入特征来评估这两个单独模型的性能。具体地说，对于多项式朴素贝叶斯，输入是报告的摘要；对于贝叶斯网，输入是其余结构化特征。

表三的(b)部分给出了单独模型的性能结果，(a)部分则给出了我们方法的结果。从表中，我们可以看到，对于这些单独的模型在这五个数据集上的取得的加权平均f值，两种模型的表现都不一致。具体来说，我们已经将在Mozilla上的性能从73.8%提高到81.7%，在Eclipse上的性能从76.6%提高到80.2%，在Jboss上的性能从85.8%提高到93.7%，在Firefox上的性能从73.1%提高到79.5%，在OpenFOAM上的性能从82.9%提高到85.9%。此外，无论是对于Bug还是对于Non-Bug本身，我们的模型在任何情况下都优于其他模型。加权平均f值的比较如图4所示。

实验2&3表

实验2图

(3)实验3：在实验2中，我们根据特征的结构对其进行分割，并将其输入到相应的单个模型中。这可能导致单个模型的信息源不完整，从而可能导致性能下降。因此，与使用完整信息的其他模型进行比较是合理的。在实验3中，我们混合了Bug报告的所有相关特性，包括结构化和非结构化部分，并将它们视为单个分类器的整体文本输入。

为了与本文方法的文本分类阶段相一致，我们使用多项式朴素贝叶斯模型作为对比目标分类器，其参数与实验中所设置的参数相同。结果如表三(c)部分所示。从表中可以看出，我们的方法仍然表现得更好。具体来说，我们将在Mozilla上的加权平均f值从78.3%提高到81.7%，在Eclipse上的加权平均f值从76.7%提高到80.2%，在Jboss上的加权平均f值从84.6%提高到93.7%，在Firefox上的加权平均f值从72.8%提高到79.5%，在OpenFOAM上的加权平均f值从79.8%提高到85.9%。比较结果如图5所示。同样，无论是对于Bug还是对于Non-Bug，我们的方法在f值方面也优于具有整体文本输入的单个模型。

此外，结合表二的(b)部分，我们可以观察到，在Mozilla和Eclipse的情况下，将所有特性包含到一个单独的文本多项式贝叶斯分类器中比只包含摘要部分要好，但这在Jboss数据集下是不成立的。同样，比较表三的(c)部分和(b)部分，在Mozilla和Eclipse数据集下，具有所有特征的分类器比具有不完整特征的分类器具有优势。但在其余三个数据集下，这种优势并不存在。这就导致了这样一种假设，即包含所有特征并不一定会比使用特征的子集合产生更好的预测结果。原因可能是并不是所有的特征都是平等的，这表明在达到最佳分类性能之前，一些不太重要的特征可以被丢弃。这种“less is more”的现象在某种程度上与文献[30]中的研究结果相吻合，但详细的研究超出了本文的范围。

5 讨论

尽管这些报告以“Bug”为名，但这个词实际上被错误地广泛使用。最近的实证研究已经揭示了大量的Bug报告实际上与Bug无关[8]、[9]。作为本文的一个小贡献，我们用更多的案例来补充和证实他们的发现。这五个案件都不包括在他们的工作中。事实上，报告是随机选择的，其中Non-Bug报告占总报告的34%左右。因此，这些Bug报告都是关于软件缺陷的隐含假设是不正确的。如果这一假设无效，依赖它所提出的办法的有效性可能会受到影响。为了解决这个问题，我们提出了一种新的方法，通过组合分类器来自动识别给定报告是否与Bug相关。Bug报告通常有两部分，它们具有不同的性质。我们的方法允许组合预测模型，每个模型都针对底层数据的特性进行调整。一组对比实验证明了我们方法的可行性和有效性。尽管在第一阶段，文本部分的分类比单个模型带来了额外的成本，但是我们通过使用摘要部分来减少工作量，并使用数据嫁接算法来自动链接到第二阶段，从而缓解了这个问题。

在我们的方法中，我们遵循一般的文本预处理步骤，即分词、删除停用词和词干化处理。然而，在基线研究中，Antoniol等人明确指出省略了停止字删除步骤。因此，在第一个实验中，我们准备了相应的输入。但我们也测试了在去除停止词时他们的模型的性能。令我们惊讶的是，结果几乎相同。经过检验，发现其原因是他们了采用对称不确定性属性选择方法。包含停止词对前20或前50个特征列表影响不大。在评估部分，我们使用了三个实验的加权平均f值作为性能的综合指标，根据它们所占的比例考虑了Bug类报告和Non-Bug类报告的f值。

在这一部分中，我们根据文献[31]中提出的指导原则，讨论了一些对实验有效性的潜在威胁。

5.1 构建有效性

这一方面反映了操作措施在多大程度上代表了根据研究问题所调查的内容。在本文中，我们试图通过文本挖掘和数据挖掘技术相结合的混合方法来回答给定的Bug报告是否是正确的Bug报告的问题。我们只依赖于由结构化和非结构化文本字段组成的典型Bug报告中的信息源，而不依赖于其他信息，例如更改日志、源代码片段等。我们根据底层字段的不同特征组合了两个分类器，训练他们做出预测。尽管基线研究中的原始数据集不可用，但我们选择了相同的项目并重复了它们的实验。一方面，我们使用综合加权平均f值来评估我们的方法并进行比较；另一方面，我们也比较了Bug报告和Non-Bug报告的f值。

5.2 内部有效性

有效性的这一方面涉及因果关系是否得到适当的证明。在我们的方法中，Bug报告中包含的字段在文献中[26]、[3]、[11]、[12]、[13]经常被视为相关的，例如，文本部分、严重性字段、优先级等。这方面的另一个关注点是数据集中引入的潜在偏差。正如[32]所研究的，选择偏差是软件工程研究中的一个普遍问题。虽然我们遵循一般的启发式方法[8]对它们进行人工分类，并使用简单的多数投票来解决冲突，但是人工分类在我们的方法中引入一些主观性是不可避免的。但是，我们试图通过每个审查员采用独立的审查策略和多数票机制来解决冲突，从而缓解这一问题。

5.3 外部有效性

有效性的这一方面与数据集上结果的通用性问题有关，而不是实验中研究的结果。除了基线研究中的三个基本数据集外，我们还特意包括另外两个具有两种不同类型BTS的数据集。就这五个数据集上的情况而言，我们的方法确实优于实验中所示的其他单个分类器。但和其他实证研究一样，我们不能保证这种优势在其他项目中仍然存在。特别是，所研究的五个案例都属于开源软件范畴，开源数据与私有软件数据有很大的不同。因此，我们不知道其他专有的Bug报告是否具有类似的特性。尽管如此，我们可以说我们的混合模型实际上是一个框架，基本上是开放的，并且没有绑定到任何特定的分类器。尽管我们使用多项式朴素贝叶斯网络分类器和贝叶斯网络分类器来进行解释，但是对于每个阶段，性能更好的新模型可以集成到我们的方法中。另一个问题是从项目中收集的Bug报告的数量。更多的实例通常会保证更稳定的性能[3]。如基线研究中所述，600个问题的样本量足以确保研究背景下精确性和召回率的置信水平为95%，置信区间为10%。因此，我们将样本量控制在相似的数量水平，但有意在论文中加入更多样本。

5.4 可靠性

这一方面涉及到数据和分析在多大程度上依赖于特定的研究人员。在我们手工准备实验的过程中，我们需要收集一套黄金数据集来学习。由于Bug报告的提交者具有不同的水平，因此检查过程在很大程度上依赖于审阅者的专业知识。为了缓解这个问题，我们省略了计算机生成以及字段不一致报告的Bug报告。我们的工具支持主要来自WEKA—一个广泛使用的数据挖掘软件套件。数据嫁接算法已经根据手工合并结果进行了测试。

6 相关工作

Antoniol等人[7]最先讨论Bug报告的错误分类问题,并证明将文本描述分类以进行自动预测它们的可行性。Pingclasai等人[33]之后提出一种基于主题建模的Bug报告分类方法。这两者都只考虑文本部分。Kim等人[9]认识到当前数据收集过程中普遍存在噪声,并研究了这些噪声对预则模型的影响。Herzig等人手动检查了7000多个Bug报告并给出了细粒度的分类，并分析这些错误分类的报告对早期研究的影响，但他们没有提供自动分类支持。文本分类技术也被用来对软件日志分类[34]、标签推荐[35]。

除了对Bug报告进行二分类方面的工作外,还进行了一些预测其他特性的研究。例如 Lamkanfi等人[3]提出了ー种基于文本挖掘的方法来自动预测Bug报告的严重性。同样, Menzies等人[11]提出了一种名为SEVERIS的方法,用于帮助开发人员为Bug报告分配严重性级别。他们都只考虑Bug报告的文本描述。但他们的工作证明了这些部分之间的相关性。此外,文本描述还被用来检测重复的Bug报告[36]、[37]，Bug指派[26]、[38]，预测修复时间[1]、[39]或修复错误的成本[40]。但上述工作大多只考虑Bug报告文本部分中的信息。

一些工作还结合了除Bug报告之外的其他数据,以简化预测任务。例如,在[41]中,Wang等人利用执行信息查找最相似的Bug。在[42]中,Matter等人使用给定的Bug报告和源代码变更之间的相似性帮助错误分派。与我们的不同之处在于,我们只考虑Bug报告中的信息。

只有少数工作研究了在Bug报告中包含多个因素或Bug存储库中多个维度的含义。他们[12]、[43]、[16]的结果表明,在性能方面取得了积极的进展。在[12]中, Shihab等人结合了工作习惯、Bug报告、Bug修复和团队这些维度。他们基于这些维度创建了一个决策树来判断一个Bug是否会被重新打开。在[43]中，Sun等人充分使用Bug报告中的可用信息，不仅包括文本内容，还包括如产品、组件、版本等非文本字段，以检测重复Bug报告。在[16]中，田等人提取多个因素,如时间、文本、作者、相关报告、严重性和产品,并提出一种新的分类模型来预测给定Bug报告的优先级级别。虽然基本想法与我们相似,但我们在问题目标和方法上都有差异。据我们所知,很少有以前的工作提出组合模型来分类Bug报告。

7 总结与未来展望

本文提出了一种将Bug报告数据的文本挖掘和数据挖掘技术相结合来识别纠正性Bug报告的混合方法。这样我们就减少了错误分类的噪音以支持更好的错误预性能。我们的工作实质上是一种多阶段分类方法——一种特殊的集成学习技术[44]——由一组特定的学习算法组成，其目的是要超越所使用的单独学习算法。这也为今后将其他类似技术应用于分类问题带来了广阔的想法。我们通过对五个开源项目的实证研究验证了我们的方法，并将其与基线工作进行了比较，并在三个实验中与个体分类器进行了比较。

虽然更多的案例研究和更大的样本集肯定有助于证实我们的方法是否一直能够优于基本的个別分类算法,但我们的方法并不依赖于任何特定的算法。它本质上是开放的,因此这些新算法可以集成到我们的框架中。例如,更好的文本分类器可以替代在我们的方法中使用的多项朴素贝叶斯分类器。据我们所知,这是关于Bug报告预则中第一次使用分类器进行组合。在未来的工作中,我们计划研究每个阶段需要多少个训练实例才能给出稳定的预测结果,并从理论上分析单个模型的组合在多大程度上能够提高单个模型的整体性能,以及我们的方法的抗噪能力。