基于机器学习的文本错误报告故障类型预测方法的研究

try to provide an abstraction that encapsulates the different challengesdevelopers face when dealing with a specific bug type including thedifferent tools and approaches for reproduction and localization. Toleverage on such a classification schema for practical debugging sup-port, e.g., for tool recommendation, a priori knowledge about a bug’stype is required.In this paper, we propose a machine learning (ML) based classifierthat predicts the fault type of a bug based on its textual bug report.This ML based approach tries to encapsulate a small aspect of whatwould commonly be considered developer knowledge and experiencein debugging. A priori information about the underlying fault typecan support inexperienced developers in their choice of debuggingapproaches and tools.This article extends previous work [5] presented at the 4th Interna-tional Workshop on Software Faults in the following ways: (1) We extendthe employed classification schema by the Other category. (2) Weenlarge the training set by 127 bug tickets and we quantify the qualityof the training set with internal and external verification methods.(3) We perform a user survey to establish a baseline of human clas-sifier performance on this task. (4) We introduce preprocessing stepstailored specifically for bug reports and we apply ensemble learningmethodologies on the classification problem. (5) We evaluate the classi-fication performance of various classical ML algorithms, preprocessingsteps, and ensemble approaches. (6) We evaluate the performance forinter-project application. Our main findings of this Journal version are:0Array 15（2022）1001890章（http://creativecommons.org/licenses/by/4.0/）。0ScienceDirect提供的内容列表0Array0期刊主页：www.elsevier.com/locate/array0使用文本错误报告预测软件错误类别0Thomas Hirsch，Birgit Hofer �0奥地利格拉茨理工大学软件技术研究所0文章信息0关键词：错误报告，错误基准，故障类型预测0摘要0调试是一项耗时且昂贵的过程。开发人员必须选择适当的工具、方法和方法，以便有效地重现、定位和修复错误。这些选择基于开发人员对给定错误报告的故障类型的评估。本文提出了一种基于机器学习（ML）的方法，用于预测给定文本错误报告的故障类型。我们从70多个项目中构建了一个数据集，用于训练和评估我们的方法。此外，我们进行了一项用户研究，以建立非专家人员在此任务上的基线。我们的模型，结合我们的自定义预处理方法，在这个错误分类问题上达到了高达0.69%的宏平均F1分数。我们展示了我们方法的跨项目可转移性。此外，我们确定并讨论了在文本错误报告上应用ML分类方法的问题和局限性。我们的模型可以支持研究人员进行数据收集工作，例如错误基准的创建。未来，这样的模型可以帮助经验不足的开发人员选择调试工具，帮助节省时间和资源。01. 引言0软件错误消耗了大量软件开发人员的资源，导致财务损失[1]。因此，围绕软件错误发展出了规模庞大的研究领域，提供了新颖和先进的工具和方法。在现实世界的软件开发中，这一进展在应用于预防引入错误的术后方法方面最为普遍，例如错误预测、静态检查和自动化测试。然而，一旦错误出现并报告，开发人员大多使用经典的调试工具和技术来重现、定位和修复错误[2-4]。开发人员可以使用各种调试工具和技术，例如断点、条件断点、内存分析器和泄漏检测工具。虽然其中一些工具针对特定的故障类型和调试过程的步骤，但其他方法则涵盖了调试过程中可能的广泛应用。然而，并没有一种适合所有情况的解决方案。开发人员的调试方法和工具选择因此对他们在修复错误方面的成功和速度产生很大影响。在大多数情况下，这种选择取决于从文本错误报告中获得的信息，以及开发人员的经验和知识。为了封装和离散化部分这些知识，我们在高抽象级别上创建了一个错误分类模式。我们根据其潜在故障将错误分类为并发、内存、语义和其他错误。通过这些类别，我们试图提供一个概括，概括开发人员在处理特定错误类型时面临的不同挑战，包括用于重现和定位的不同工具和方法。为了利用这样的分类模式来提供实际调试支持，例如工具推荐，需要关于错误类型的先验知识。在本文中，我们提出了一种基于机器学习（ML）的分类器，根据其文本错误报告预测错误的故障类型。这种基于ML的方法试图封装通常被认为是开发人员在调试中的知识和经验的一小部分。关于潜在故障类型的先验信息可以支持经验不足的开发人员选择调试方法和工具。本文扩展了先前在第4届国际软件故障研讨会上发表的工作[5]，扩展了所采用的分类模式，增加了“其他”类别。我们通过127个错误票证扩大了训练集，并用内部和外部验证方法量化了训练集的质量。我们进行了用户调查，以建立人类分类器在此任务上的基线。我们引入了专门针对错误报告的预处理步骤，并在分类问题上应用了集成学习方法。我们评估了各种经典ML算法、预处理步骤和集成方法的分类性能。我们评估了跨项目应用的性能。本期刊版本的主要发现是：0� 通讯作者。电子邮件地址：thirsch@ist.tugraz.at（T. Hirsch），bhofer@ist.tugraz.at（B.Hofer）。0https://doi.org/10.1016/j.array.2022.1001892022年3月8日收到；2022年5月11日修订后收到；2022年5月13日接受20Array 15 (2022) 1001890T. Hirsch和B. Hofer0•  非专家人类分类器的性能平均为0.620加权平均F1。0•  不同的ML算法显示出显著不同的性能0在特定类别上（例如，使用Multinomial Naive Bayes和RandomForrest分类器的Memory bug，宏平均F1分别为0.72和0.79。）0•  集成方法表现更好（0.69宏平均F1）0比最佳表现的单一分类器模型（逻辑回归分类器的0.66宏平均F1）更好，集成大小只起到了次要作用。0本文的其余部分结构如下：第2节0描述了使用bug报告进行故障类型预测的问题。在第3节中，我们讨论了相关工作和类似的分类努力。在第4节中，我们讨论了本工作的背景，包括现有的bug分类模式、基于ML的分类和自然语言处理（NLP）。在第5节中，我们介绍了我们的实验设置和方法，随后在第6节中提出了我们的研究问题和结果。在第7节中，我们讨论了内部和外部的有效性威胁。第8节总结了我们的工作并讨论了未来的研究。所有数据集和实现都是公开可用的（见第8节）。02. 问题0情感分析的经典NLP示例是基于0假设“情感”信息是人类书面文本固有的，并且假设输入只包含人类书面文本。Bug报告与这类展示性NLP问题非常不同。正确分类所需的信息可能不包含在bug报告中：Bug报告是描述复杂系统中的问题的文本描述。这些报告是由在项目中担任不同角色、职能和职位的人员撰写的。这些角色范围从不熟悉软件开发的最终用户到在项目中拥有多年经验的高度经验丰富的开发人员。由于这个原因，作者的技术专长和项目特定的专业知识可能存在显著差异。此外，不同的角色在bug报告中具有固有的不同观点和范围。例如，bug报告可能仅以非技术术语描述bug的影响，而其他bug报告可能详细描述问题而不提及可能的影响。0此外，由于各种模板和格式规则，或其缺乏，bug报告的形式多种多样，长度不一，内容各0模板和格式规则的使用，或者缺乏使用，以及对这些规则的不遵守。这导致了嘈杂的，有时是不完整的bug报告，长度不等，内容各异，词汇也不同。0在某些情况下，从这样的bug中推导出前述的故障类型0报告可能是琐碎的，就像这个Memory bug一样：0本地（java）进程内存泄漏在JVM中使用GarbageCollectorMXBean#getLastGcInfo时的内部内存泄漏。禁用使用它...0然而，往往情况并非如此，读者可能会感到挑战0领域和项目特定的知识和专业知识，例如，这个源自Spring Boot的语义bug：0Gradle插件仍然包括带有Layout.NONE的*Launcher类  未提供描述。0在某些情况下，甚至是不可能的，例如，这个bug报告的产生0来自文档错误的5：01  例如，orientdbissue2121。 2例如，elasticsearchissue4960。 3elasticsearchissue1118。 4spring-bootissue139。 5nettyissue1508。0CR7中的ResourceLeakException在我们的基准测试中，我们发现了一个泄漏，根据我们和诺曼的看法是没有意义的。0这些问题使得错误报告成为NLP应用的一个具有挑战性的目标0方法。由于这些错误票据中缺乏信息或误导性信息，我们不指望能看到从经典NLP展示问题中所知的高分类性能得分。03.相关工作0多个研究人员已经研究了ML和0文本错误报告上的NLP方法用于分类问题。Lopes等人[6]根据正交缺陷分类（ODC）模式自动对来自三个开源数据库应用程序收集的4000多个错误报告进行分类。他们进行了欠采样以避免不平衡的数据集。Thung等人[7]使用半监督学习执行自动ODC缺陷类型分类。我们的工作与Lopes等人和Thung等人的工作在所使用的模式上有所不同。而ODC模式旨在分析和优化软件开发过程，我们的模式旨在帮助开发人员选择最适合当前错误的调试工具。0Tan等人[8]根据根本原因、影响和受影响组件对错误进行了分类。0影响和受影响组件。他们在数据挖掘工作中应用了机器学习分类器的支持。虽然Tan等人将错误分类为并发、内存和语义错误，我们引入了第四个类别（其他），涵盖文档、构建系统、配置和UI资源故障。由于他们手动标记的数据集中只有很小一部分包含并发错误，他们在文本错误报告上执行了关键字搜索，使用诸如'race'和'lock'之类的关键字。与他们的工作相反，我们在提交消息而不是错误报告上执行关键字搜索，以减少信息泄漏。0Li等人[9]使用ML分类器研究了开源软件中的错误特征。0开源软件中的错误根本原因。与Tan等人类似，他们将错误的根本原因分类为内存、并发和语义错误。0Ray等人[10]使用ML分类器研究了编程0开源项目中的语言和代码质量度量。他们应用了五种不同的根本原因类别：算法、并发、内存、通用编程和未知。由于他们的方法侧重于对已修复错误的分析，他们在提交消息上训练了他们的机器学习方法（事后方法）。然而，我们有兴趣在开发人员修复错误之前为他们提供信息。因此，我们的分类器是在文本错误报告上训练的，而不是在提交消息上（先验方法）。0Ni等人[11]从代码更改中预测了根本原因类型0通过将代码更改转换为抽象语法树（ASTs），然后使用基于树的卷积神经网络（TBCNN）。他们区分了六个主要的根本原因类别（功能、接口、逻辑、计算、赋值和其他）和21个子类别。与我们的工作相反，这种分类是在错误修复后进行的。0以下方法侧重于预测其他类别0比根本原因更重要：Goseva等人[12]使用监督和无监督学习算法来标记安全和非安全问题。Wu等人[13]结合交互式机器学习和主动学习来预测高影响的错误。Xia等人[14]提出了一种新颖的特征选择算法，用于基于机器学习的bug报告分类为mandelbugs和bohrbugs。之后，Du等人[15]提出了一个跨项目迁移学习框架，用于相同目的。CaPBug[16]使用不同的分类器预测错误报告的类别（例如程序异常、GUI、性能、测试代码）和优先级，同时提供了一个很好的概述论文，用于对错误进行分类和优先级排序。0ML已被用于自动区分错误报告和0特征请求[17]，预测严重性[18]或优先级[19]30数组15（2022）1001890T. Hirsch和B. Hofer0给定错误报告，并从大型代码库中提取模式[20]。最近的一项调查[21]很好地概述了深度学习方法在软件工程研究中的应用，包括缺陷和漏洞预测和错误定位。0在故障定位的背景下特别有趣的是0方案由Fang等人提出[22]，将错误报告分类为信息性或非信息性。这种方法可以作为信息检索（IR）方法中的预处理步骤，以过滤掉IR对提供少量见解的错误报告。0Huang等人[23]手动标记了超过5400个意图0问题报告中的句子分为七类，例如“信息提供”和“问题发现”。之后，他们训练了一个深度神经网络来预测这些意图。04. 背景0首先，我们提供了现有错误分类方案的概述0（第4.1节）。之后，我们简要解释了所使用的分类器和统计方法（第4.2节），以及自然语言处理方面最重要的术语（第4.3节）。最后，我们提供了所使用性能指标的正式定义（第4.4节）。04.1. 错误分类方案0已经提出了大量的错误、故障和缺陷分类方案0过去由研究人员和从业者提出的。这样的分类模式可以涵盖一个或多个缺陷的维度，例如严重性、影响和根本原因。所有分类模式当然都旨在实现某种目的，它们的维度、深度和细节的选择是为了实现设定的目标。这些目的范围从调查过程优化到实现自动分类和优先级排序，再到对软件开发过程不同领域的研究，以及支持自动修复等技术。0Polski等人[24]讨论了现有故障分类的应用0故障注入的分类模式和错误分布，并提供了故障分类模式的概述。Endres[25]进行了最早的一次错误分类尝试，以调查更高级别的原因（例如技术、组织、历史）。0Gray [26]引入了Bohrbugs和Heisenbugs类别。Grot-0tke和Trivedi [27]通过引入Mandelbugs和aging-relatedbugs扩展了Gray的类别。0Chillarege等人[28]设计了正交缺陷分类0（ODC）模式形成了软件开发过程分析和优化的基础。《IEEE软件异常分类标准（IEEE标准1044-2009）》[29]建立了软件异常的词汇表，以及缺陷和故障的分类模式和属性。0只有少数分类方案针对调试过程0旨在支持软件开发人员。Li等人[9]和Tan等人[8]研究了开源软件中错误的特性，以实现更有效的调试工具设计和更好地理解实际世界中发生的错误。鉴于对调试工具和调试过程的关注，他们沿着三个轴对错误进行了分类：影响、软件组件和根本原因。影响包括六个类别（例如，不正确的功能、崩溃或挂起）。他们的根本原因维度包括三个类别：内存错误源于不当的内存处理，并发错误发生在多线程程序中，由于同步问题，包括竞争条件和死锁，语义错误是需求或程序员意图与实际软件功能之间的不一致。04.2. 机器学习0在这项工作中，应用了监督机器学习方法0执行自动分类。手头的问题是一个多类分类问题，其中每个输入数据实例属于特定的类。04.2.1. 分类器0多项式朴素贝叶斯（MNB）是基于贝叶斯定理的概率分类器0在这里，朴素表示特征的概率是独立的假设。MNB分类器快速易用，可以提供性能基准，用来比较其他分类器。0支持向量机（SVM）是一种非概率方法0可用于回归和二元分类。SVM在特征空间中构建一个超平面来分隔类别。对于多类分类问题，同时训练多个SVM，以一对全部或一对一的方式。0随机森林（RF）是一种集成学习方法0可用于回归和分类。RF分类器构建一系列不同的决策树，然后将它们组合成一个集成来进行分类。0逻辑回归（LR）是用于二元分类的线性分类器0逻辑回归以及线性回归都是基于线性模型。LR使用逻辑（S型）函数来离散化它们的输出，因此得名逻辑回归。对于多类问题，多个LR以一对全部或一对一的方式组合。04.2.2. 评估策略和平衡0K折交叉验证（K-fold CV）是一种统计方法0选择参数和评估机器学习模型。数据被切割成�个大小相等的部分。模型的训练是用�-1部分进行的，得到的模型在剩余的部分上进行验证。这个过程重复�次，以便每个切片都被用作验证集一次。分层k折交叉验证以保留原始类别分布的方式创建切片。0通过反复生成训练集和测试集来进行ML分类的自举法0使用均匀随机抽样生成训练和测试拆分。因此，一个项目可以在一个拆分中出现多次，但不能同时出现在测试和训练中。生成的性能分数用于计算置信水平�的置信区间，作为（1-�）/2和�+(1-�)/2的百分位数。0在分类问题的背景下，不平衡数据意味着0每个类别的项目数量并不相等。虽然有一些机器学习算法对不平衡数据不敏感，但上述所有描述的分类器都对这种不平衡敏感。基本上有两种平衡训练集的策略，上采样和下采样。上采样为少数类创建合成实例，使其规模与多数类相匹配。下采样从多数类中删除实例，使其规模与少数类相匹配。04.3. 自然语言处理（NLP）0以下我们提供了预处理和0在文本文档上应用机器学习算法的准备步骤。0在标记化步骤中，输入文档被分割成标记。0本文描述的模型通过单词进行标记化。0矢量化从一个标记化的文档中创建一个特征向量。0本文中的模型利用简单的计数向量化器，其中特征向量表示文档中各个标记的出现次数。0词袋是一种常见的方法，其中文档被分割为单词标记，然后进行矢量化。单词的顺序以及它0非人类语言工件的去除，例如堆栈跟踪、代码片段、配置文件、文件列表、日志输出和线程转储。0词频-逆文档频率（Tf-idf）是一种基于语料库中术语常见程度的加权转换方法。给定术语  �  和文档 。0依赖术语在整个文档语料库中的常见程度应用权重的一种转换方法。给定术语  �和文档  �  的Tf-idf转换是术语频率  ��，即该术语在该文档中的出现次数，乘以该术语的逆文档频率  ��� 。Array 15 (2022) 1001894T. Hirsch and B. Hofer𝑇 𝑓 − 𝑖𝑑𝑓(𝑡, 𝑑) = 𝑡𝑓(𝑡, 𝑑) ∗ 𝑖𝑑𝑓(𝑡)(1)𝑖𝑑𝑓(𝑡) = 𝑙𝑜𝑔𝑛 + 1𝑑𝑓(𝑡) + 1+ 1(2)amenable inter-classifier comparison, and their weighted average F1-score(waF1) and macro average F1-score (maF1) to compare multi-classperformance. These metrics can be calculated from the classifiers’confusion matrices. True Positives (TP) is the number of instances inthe predicted class that match the actual class. False Positives (FP) ex-presses the number of instances in predicted class that do not match theactual class. True Negatives (TN) is the number of instances correctlyidentified as not belonging to the class, and False Negatives (FN) is thenu(3)(5)0该文档中该术语的出现次数乘以该术语的逆文档频率  ��� 。0文档频率  �� ( � )  是语料库中包含该术语  �的文档数量。因此，Tf-idf加权向量的欧几里得范数。上述的  ���公式描述了本文中使用的ML软件库中的实现，与教科书中的定义略有不同[30]（详细解释请参阅[31]）。0词干处理将单词替换为它们的词干。例如，单词‘crash’和‘crashing’的词干为‘cras0单词‘crash’和‘crashing’的词干为‘crash’。生成的词干本身不一定是一个单词。在进行词干处理之前，‘crash’和‘crashing’被视为不同的标记，因此在词袋方法中会生成不同的特征；而经过词干处理后，这两个单词将被表示为相同的特征。0大小写折叠是为了使文档中的所有字母都是小写。0相同的情况。矢量化器基于字符串比较，以大写字母开头的相同单词的出现将被表示为与小写字母开头的相同单词不同的特征。0驼峰式拆分将驼峰式单词拆分为多个单词，这些单词0允许对这些词进行标记化和词干处理。0停用词去除会删除非常常见的单词（例如‘the’、‘and’、0‘is’）对于手头的任务没有增加价值的输入文本。0广泛的不同格式的工件构成了一个重要的挑战。0从错误报告中提取堆栈跟踪、代码片段、配置文件、文件列表、日志输出和线程转储。我们数据集中的一些错误报告因此包含多达80kb的文本，因为包含了这些工件。其中最大的工件之一是堆栈跟踪。虽然这些跟踪支持开发人员进行调试，但用于分类目的的信息大多仅限于发生异常的名称和类型。04.4. 性能指标0问题，使用正则表达式[32]进行自动移除，因此我们采用自定义的基于ML的工件移除过程[33]。基础ML模型是在软件项目的文档文件和问题票据上进行训练，并利用GitHubmarkdown进行自动训练集创建。生成的分类器模型是基于逐行操作，并保留工件中出现的异常名称。0我们在单类别的Precision（P）、Recall（R）、F1-score（F1）中使用0类的精确度是TP除以实例的总数0分类为属于该类的（� = ��0��+��）。精确度为1.0意味着所有标记为都是正确的；0所有标记为类别X的实例都是正确的；0单个类别的召回是TP除以实际属于该类别的实例总数（� = ��0��+��）。召回率为1.0意味着0所有实际类别X的实例都被正确标记为属于类别X。0单个类别的F1是类别精确度和0召回（�1 = 2*�*�0�+�）。0加权平均F1是所有类别的F1分数的平均值，其中每个类别的实例数作为该类别的权重。0每个类别的实例数作为该类别的权重。0���1 =∑������������������1�����∑����������������0多类问题中的宏平均F1是未加权的0所有类别的F1分数的平均值。在平衡输入的情况下，宏平均和加权平均F1分数产生相同的结果。0���1=∑������1�����0|�����|（4）0Cohens kappa校正的评分者一致性。0机会。它是基于两个评分者都同意的项目比例（�0）和预期机会一致的比例（��）计算的[34]。 0.41 <� <0.60被认为是中等的，0.61 <� <0.80是实质性的，0.81 <�<1.00是几乎完美的一致[35]。0�=�0−��01-��05.实验设置0首先，我们解释了使用的分类模式（第5.1节）。0接下来，我们描述了底层数据集（第5.2节）和训练集的创建过程（第5.3节）。最后，我们介绍了ML建模方法（第5.4节）。05.1.分类模式0我们的分类模式应该帮助开发人员调试0过程。我们基于Tan等人的分类模式[8]的根本原因维度。这个根本原因分类旨在概括每个类别的最有前途的调试方法和特定的调试工具。我们的分类模式的顶层由四个主要类别组成，并发，内存，其他和语义。对于并发错误的一组有用的调试工具将不同于对其他类别中错误有用的工具的组。0表1提供了我们分类模式的概述。0详细的文档，包括示例和越来越详细的子组，可以在我们的在线附录中找到。我们分类模式的这些详细级别有两个目的：作为手动分类的文档和教育工具，并提供额外信息，推断故障和修复模式，为读者提供更清晰的图片。本文的后续实验中使用顶层类别并发，内存，其他和语义。05.2.数据集0为了收集合理数量的问题票，我们挖掘了101个开放的-0GitHub上托管的源Java项目。这些项目涵盖了各种不同的软件领域，从服务器端应用程序，数据库应用程序，ML框架，测试框架到移动应用程序。我们添加了所有这些项目的关闭问题票，这些问题票的标签包含字符串'bug'，'defect'，'breaking'或'regression'，即54,755个问题票。由于GitHubAPI中的怪癖，项目维护者手动进行的错误分类以及不同项目中的工作流程的变化，导致的结果数据集相当嘈杂。由于GitHubAPI不区分问题和拉取请求，初始数据集包含两者。此外，问题可以由于各种原因关闭，包括重复，不愿修复或被拒绝为“不是bug”，尽管有标签。为了清理数据集，我们删除了所有问题票0• 是拉取请求，• 链接了零个或多个提交，50数组15（2022）1001890T. Hirsch and B. Hofer0表1故障类型分类模式，一级类别使用粗体字，二级类别使用普通字体。0故障类型描述0并发不当或不正确的同步和对原子性的错误假设。顺序违规由于缺少或不正确的同步或线程处理而导致的错误顺序。竞争条件两个或更多线程同时访问同一资源，其中至少有一个是写访问。原子违规错误地假设了操作的原子性，或者不正确使用不是线程安全的数据类型和结构。死锁两个或更多线程陷入等待对方释放资源的状态。并行化缺少并行化导致滞后，或者为满足约束而删除并行化。其他不属于上述任何类别的与并发相关的故障。0内存和资源不当或不正确的内存和资源处理。溢出缓冲区溢出，不包括溢出的数值类型。空指针解引用空指针解引用。未初始化内存读取未初始化的内存读取，不包括空指针解引用。泄漏内存和资源泄漏。悬空指针指向无效数据的指针。双重释放多次释放相同的内存。其他不属于上述任何类别的与内存相关的故障。0无法通过更改Java代码解决的其他错误。文档不正确或缺失的文档。构建系统缺少或不正确的构建配置和构建脚本中的错误。UI资源缺少或不正确的UI资源。配置缺少或不正确的配置文件，不包括构建配置和UI配置。0需求、程序员意图和实际实现的语义不一致，不属于上述类别。异常处理不正确、缺失或过度异常处理。缺失情况代码缺失。缺少实现、缺少程序流程或由于对某个情况的无意识而导致其他代码部分缺失。处理代码不正确。不正确的实现，从错误计算到不正确的库使用。拼写错误简单的排版错误。依赖由外部库或系统更改引入的错误，导致可以构建但行为意外或不正确的软件。其他不属于上述任何类别的故障。0• 每次提交更改超过250行或超过20个文件，•链接至少一个已不可用的提交，• 具有具有多个父级的提交，或•具有提及多个问题票据的提交消息0包含多个修复的ID或包含指示多个修复的短语（例如'also fixes'）。0这个缩减后的数据集包括11,621个错误报告，是我们实验的基础。05.3. 训练集创建0管理不平衡。这些原始的问题票据集是0预计在我们的分类目标方面存在严重的不平衡。其他研究人员确定了内存和并发错误作为少数类，仅占所有错误的2%-16% [ 8 – 10]。由于我们选择的机器学习算法对这种不平衡很敏感，我们将采用降采样来平衡我们的数据集。然而，少数类别的一定数量的数据点是必需的，因为这些少数类别的大小决定了最终的训练集大小。我们估计我们的包含11,621个错误票据的数据集只包含几百个内存和并发错误。由于认为对所有问题进行彻底检查是不可行的，我们需要对问题进行过滤和预先选择以进行手动检查。0因此，我们对提交消息进行了关键字搜索0选择关键词进行手动分类。我们使用了Ray等人的关键词的修改版本来识别手动分类的候选项[10]。我们的关键词集包含29个关键词和正则表达式，例如'overflow'，'\sleak'，'deadlock'，'\shangs\s'，'\sstarves\s'。关键词的完整列表可在在线附录中找到（见第8节）。提交消息是由执行bug修复的开发人员编写的。这些开发人员具有对潜在问题的理解，同时也具有一定水平的技术专业知识和相关词汇。此外，提交消息的语料库与构成我们模型输入的文本bug报告的语料库是不同的。这减少了我们的机器学习实验中对某些关键词的不必要偏见。0进行了两组分：包含Java代码更改的问题（10,146个问题）和不包含Java代码更改的问题（1,475个问题）。对于第一组问题，我们应用了关键词搜索，得到了756个结果，其中我们手动分析了514个。此外，我们从这个组中随机选择并分析了158个问题，以充分采样主要类别（语义）。从第二组中，我们随机选择并分析了508个问题，以充分采样我们的其他类别。总共，我们从86个软件项目中手动分析了1180个问题。在这个手动检查过程中，我们删除了数据集中的418个问题，原因0Java，如果它们不属于“其他”类别。0•不被视为bug的报告。•相应的修复是使用其他编程语言的0时间。0•非英文bug报告•在合理的时间内无法确定故障类型0无法确定故障类型的最常见原因是重构、增强和链接提交中的其他重大代码更改，这使得在没有深入的项目知识的情况下无法隔离导致bug的代码。0数组15（2022）1001890不同的软件项目。其中包含155个并发bug，132个内存bug，142个其他bug和333个语义bug。60数据集质量和验证。研究人员1进行了手动0T. Hirsch和B. Hofer0外部验证。研究人员2对246个随机0如上所述的分类。六个月后，研究人员1重新对从该集合中随机抽样和盲化的100个问题进行了内部验证。在这个内部验证步骤中，研究人员1的CohensKappa得分为0.95，表明有“几乎完美的一致性”[35]，以及0.96的加权平均F1分数。0最终数据集。在初步的机器学习实验中，我们确定了三0抽样和盲化问题。这种外部验证导致了0.69的CohensKappa分数，表明有“实质性一致性”[35]，以及0.80的加权平均F1分数。0不适合我们的故障类型分类方法的项目。这些项目包括：LeakCanary，一个Java内存泄漏检测库，Bazel，一个构建自动化框架，以及JHipster，一个Web应用程序生成器。它们的领域使得仅基于bug报告的自然语言处理方法无法正确识别某些bug类型，而需要对项目的领域和目的有所了解。例如，来自内存泄漏检测库的bug报告利用了与内存泄漏直接相关的词汇，进一步由这些软件项目中的类名和函数名加强了对所有类别bug的关联。类似地，构建框架的bug报告具有与一般软件项目中的其他bug相关的词汇。因此，我们从训练/测试集和调查答案中删除了这些项目的所有内容。0我们使用研究人员1的初始手动分类作为0实验的基础，并通过对多数类别进行欠采样来平衡生成的数据集，从而得到了包含每个124个bug报告的等大小类别。我们实验中使用的最终数据集共包含来自71个不同软件项目的496个bug报告。05.4. ML分类器0朴素贝叶斯（MNB），随机森林（RF）和支持向量机（SVM），这是基于其他研究人员在类似努力中的工作[6,8,9,17,36]，以及它们的易用性。此外，我们采用基于LR的堆叠分类器集成学习方法来结合表现最佳的模型。0实验设置。我们的模型管道包括去除工件，0和解驼式命名，然后进行词干处理和计数向量化，通过Tf-idf，最终到分类器算法。我们进行了嵌套CV，每个都有五个折叠进行超参数调整和模型选择。内部 �-fold CV用于模型的超参数调整。所选的超参数空间仅涉及预处理步骤的启用或禁用，包括停用词去除，解驼式命名，词干处理，工件去除和Tf-idf的使用。分类器算法的参数未经调整，保持其默认值（scikit-learn 0.24.2）。外部 � -fold用于模型选择。我们实验中使用的所有k-foldCV拆分都是以分层方式进行的，以保持输入数据集的平衡性。0为了评估生成的模型，我们使用分层Bootstrap080-20的训练-测试拆分， �  = 100 重复和置信水平 � =0.95。我们计算所有性能得分的平均值0Bootstrap重复。为了比较两个模型，我们对两个模型的Bootstrap重复的分数进行单侧T检验，� 0  =  ����� � �� ��� ������ ���� ������。此外，我们通过聚合Bootstrap迭代的混淆矩阵来构建混淆矩阵。06. 实验结果06.1. RQ1：人类分类bug报告的性能如何？0动机：通过回答RQ1，我们建立了一个基准来比较0ML方法对比。0图1.调查F1 Bootstrap置信区间。0方法：我们进行了一项在线用户调查，要求参与者对文本bug报告进行分类0以便根据其故障类型对文本bug报告进行分类。该调查通过电子邮件和直接消息向驻地软件公司的专业开发人员和计算机科学专业的硕士学生进行推广。可以假设大多数调查参与者是学生。允许匿名参与，同时披露联系电子邮件地址的参与者可以赢得知名在线商店的代金券。允许同一人多次提交。对于每次提交，我们跟踪IP地址，电子邮件地址（可选），在每个bug报告上花费的时间以及每个bug报告的相应答案。0从平衡的500个bug报告中随机抽取了一组样本0已由研究人员1调查的762个bug报告（见5.3）。参与者从500个bug报告中随机选择了十个bug报告。bug报告的格式与GitHub上的原始格式相同，并且每个bug报告都有单选答案。虽然我们没有提供指向GitHub上原始bug工单的链接，但内联图像（例如截图）和bug报告文本中的链接得以保留。参与者在调查入口页面上得到了我们分类模式的简短介绍。在参与过程中，每个页面内联提供了四种故障类型的简短解释。此外，还提供了我们分类模式的详细解释和示例的链接。没有时间限制。0结果：我们收到了51份提交。我们仔细调查了0花费的时间和IP地址，并没有发现任何表明恶意意图的提交。这些提交为我们提供了510个手动分类的错误报告，用于我们的分析。根据讨论，删除了来自三个项目的错误报告，留下了483个分类的错误作为下面讨论的基础。0图1显示了调查提交的Bootstrap区间（�=01000，�=0.95）。所有分类的错误报告的加权平均F1的平均性能为0.62。参与者在Memory错误方面表现最佳，平均F1得分为0.63，在Semantic错误方面表现最差，平均F1得分为0.47。0图2显示了所有收到答案的归一化混淆矩阵0其他错误最常被参与者误分类为Se