基于机器学习的文本错误报告故障类型预测方法及其应用

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]。因此，围绕软件中的错误发展出了大量的研究领域，提供了新颖和先进的工具和方法。在现实世界的软件开发中，这一进展在应用于预防错误引入的ante-mortem方法中最为普遍，例如错误预测、静态检查和自动化测试。然而，一旦错误出现并报告，开发人员大多利用经典的调试工具和技术来重现、定位和修复错误[2-4]。开发人员可以使用各种调试工具和技术，例如断点、条件断点、内存分析器和泄漏检测工具。虽然其中一些工具针对特定的故障类型和调试过程的步骤，但其他方法则涵盖了调试过程中可能的广泛应用。然而，并没有一种适合所有情况的解决方案。开发人员的调试方法和工具选择因此对他们在修复错误时的成功和速度产生很大影响。在大多数情况下，这种选择取决于从文本错误报告中获取的信息，以及开发人员的经验和知识。为了封装和离散化部分这些知识，我们在高抽象级别上创建了一个错误分类模式。我们根据其潜在故障将错误分类为并发、内存、语义和其他错误。通过这些类别，我们试图提供一个概括，概括开发人员在处理特定错误类型时面临的不同挑战，包括用于重现和定位的不同工具和方法。为了利用这样的分类模式来提供实际调试支持，例如工具推荐，需要有关错误类型的先验知识。在本文中，我们提出了一种基于机器学习（ML）的分类器，根据其文本错误报告预测错误的故障类型。这种基于ML的方法试图封装通常被认为是开发人员在调试中的知识和经验的一小部分。关于潜在故障类型的先验信息可以支持经验不足的开发人员选择调试方法和工具。本文扩展了先前在第4届国际软件故障研讨会上发表的工作[5]：（1）我们通过“其他”类别扩展了所采用的分类模式。（2）我们通过127个错误票证扩大了训练集，并用内部和外部验证方法量化了训练集的质量。 （3）我们进行了用户调查，以建立人类分类器在此任务上的基线。（4）我们引入了专门针对错误报告的预处理步骤，并在分类问题上应用了集成学习方法。（5）我们评估了各种经典ML算法、预处理步骤和集成方法的分类性能。（6）我们评估了不同项目应用的性能。本文的主要发现是：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在特定类上（例如，多项式朴素贝叶斯和随机森林分类器上的内存bug，分别为0.72和0.79的宏平均F1。）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报告可能是微不足道的，例如这个内存bug3：0本地（java）进程内存泄漏JVM中使用GarbageCollectorMXBean#getLastGcInfo时的内部内存泄漏。禁用使用它...0然而，往往情况并非如此，读者可能会感到挑战0领域和项目特定的知识和专业知识，例如，来自Spring Boot 4的这个语义bug0Gradle插件仍然包括带有Layout.NONE的*Launcher类 未提供描述。0在某些情况下，甚至是不可能的，例如，这个bug报告的产生0来自文档错误5：01  例如，orientdbissue2121。2例如，elasticsearchissue4960。3elasticsearchissue1118。4spring-bootissue139。5nettyissue1508。0CR7中的ResourceLeakException在我们的基准测试中，我们发现了一个泄漏，根据我们和诺曼的看法，这是没有意义的。0这些问题使得错误报告成为自然语言处理的挑战性目标。0方法。我们的故障类型分类任务受到这些错误票据中信息缺失或误导性信息的影响，因此我们不指望看到从经典自然语言处理展示问题中所知的高分类性能分数。03. 相关工作0多个研究人员已经调查了机器学习和自然语言处理方法在文本错误报告的应用。0NLP方法用于文本错误报告的分类问题。Lopes等人[6]根据正交缺陷分类（ODC）模式自动对来自三个开源数据库应用程序收集的4000多个错误报告进行分类。他们进行了欠采样以避免不平衡的数据集。Thung等人[7]使用半监督学习执行自动ODC缺陷类型分类。我们的工作与Lopes等人和Thung等人的工作在所使用的模式上有所不同。而ODC模式旨在分析和优化软件开发过程，我们的模式旨在帮助开发人员选择最佳的调试工具来处理手头的错误。0Tan等人[8]根据根本原因、影响和受影响组件对错误进行了分类。0影响和受影响组件。他们在数据挖掘工作中应用了机器学习分类器的支持。虽然Tan等人将错误分类为并发、内存和语义错误，我们引入了第四个类别（其他），涵盖文档、构建系统、配置和UI资源故障。由于他们手动标记的数据集中只有很小一部分包含并发错误，他们在文本错误报告上执行了关键字搜索，使用诸如“race”和“lock”之类的关键字。与他们的工作相反，我们在提交消息而不是错误报告上执行关键字搜索，以减少信息泄漏。0Li等人[9]使用机器学习分类器研究了开源软件中的错误特征。0类似于Tan等人，他们将错误的根本原因分类为内存、并发和语义错误。0Ray等人[10]使用机器学习分类器研究了编程语言和代码质量度量。0在开源项目中使用自然语言处理和代码质量度量。他们应用了五种不同的根本原因类别：算法、并发、内存、通用编程和未知。由于他们的方法侧重于对已修复错误的分析，他们在提交消息上训练了他们的机器学习方法（事后方法）。然而，我们的目标是在开发人员修复错误之前为他们提供信息。因此，我们的分类器是在文本错误报告上训练的，而不是在提交消息上（事前方法）。0Ni等人[11]从代码更改中预测了根本原因类型。0通过将代码更改转换为抽象语法树（ASTs），然后使用基于树的卷积神经网络（TBCNN）。他们区分了六个主要的根本原因类别（函数、接口、逻辑、计算、赋值和其他）和21个子类别。与我们的工作相反，这种分类是在bug修复后进行的。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）是一种根据术语在整个文档语料库中的常见程度应用权重的转换方法。给定术语  �) + 10into word-tokens followed by vectorization. The order of words and theirconnections to each other are lost; a document is represented as anunordered collection of words.Array 15 (2022) 1001894T. Hirsch and B. Hofer𝑇 𝑓 − 𝑖𝑑𝑓(𝑡, 𝑑) = 𝑡𝑓(𝑡, 𝑑) ∗ 𝑖𝑑𝑓(𝑡)(1)𝑖𝑑𝑓(𝑡) = 𝑙𝑜𝑔𝑛 + 1𝑑𝑓(𝑡) + 1+ 1(2)d’,4.4. Performance metricsamenable 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'的词干为'crash'。生成的词干本身不一定是一个单词。在进行词干处理之前，'crash'和'crashing'被视为不同的标记，因此在词袋方法中会产生不同的特征；而进行词干处理后，这两个单词将被表示为相同的特征。0相同的情况。矢量化器基于字符串比较，以大写字母开头的相同单词的出现将被表示为与小写字母开头的相同单词不同的特征。0允许对这些单词进行标记化和词干处理。0'is'）对于当前任务的输入文本没有增加价值。0从错误报告中提取堆栈跟踪、代码片段、配置文件、文件列表、日志输出和线程转储。我们数据集中的一些错误报告因为这些工件而达到80kb的文本大小。最大的工件之一是堆栈跟踪。虽然这些跟踪支持开发人员进行调试，但用于分类目的的信息大多仅限于发生异常的名称和类型。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个开放的-0源自GitHub的Java项目。这些项目涵盖了各种不同的软件领域，从服务器端应用，数据库应用，ML框架，测试框架到移动应用。我们添加了所有这些项目的已关闭问题票，其标签包含字符串'bug'，'defect'，'breaking'或'regression'的数据集，即54,755个问题票。由于GitHubAPI中的怪癖，项目维护者手动进行的错误分类以及不同项目中的工作流程的差异，导致得到的数据集相当嘈杂。由于GitHubAPI不区分问题和拉取请求，初始数据集包含两者。此外，问题可以由于各种原因关闭，包括重复，不愿修复，或者尽管有标签但被拒绝为'不是bug'。为了清理数据集，我们删除了所有问题票，其中0•是拉取请求，•链接了零个或多个提交，50数组15（2022）1001890T. Hirsch和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等人使用的关键词的修改版本。我们的关键词集包含29个关键词和正则表达式，例如'overflow'，'\sleak'，'deadlock'，'\shangs\s'，'\sstarves\s'。关键词的完整列表可在在线附录中找到（见第8节）。提交消息由执行bug修复的开发人员编写。这些开发人员具有对潜在问题的理解，同时具有一定水平的技术专业知识和相关词汇。此外，提交消息的语料库与构成我们模型输入的文本bug报告的语料库是不同的。这减少了我们的机器学习实验中对某些关键词的不良偏见。0进行了两组分析：包含Java代码更改的问题（10,146个问题）和不包含Java代码更改的问题（1,475个问题）。对于第一组，我们应用了关键词搜索，得到756个结果，其中我们手动分析了514个。此外，我们从该组中随机选择并分析了158个问题，以充分采样多数类别（语义）。从第二组中，我们随机选择并分析了508个问题，以充分采样我们的 其他类别。总共，我们从86个软件项目中手动分析了1180个问题。在这个手动检查过程0Java，如果它们不属于 其他  类别。0• 不被视为bug的报告。 • 相应的修复是使用其他编程语言编写的0时间。0• 非英文bug报告 • 合理范围内无法确定故障类型0无法确定故障类型的最常见原因是重构、增强和链接提交中的其他重大代码更改，这使得在没有深入项目知识的情况下无法隔离导致bug的代码。0数组15（2022）1001890不同的软件项目。其中包含155个并发bug，132个内存bug，142个其他bug和333个语义bug。6sided T-tests on the scores from both models’ Bootstrap repetitions with𝐻0 = 𝑀𝑜𝑑𝑒𝑙 𝐴 𝑖𝑠 𝑛𝑜𝑡 𝑏𝑒𝑡𝑡𝑒𝑟 𝑡ℎ𝑎𝑛 𝑀𝑜𝑑𝑒𝑙 𝐵. Further, we build confusionmatrices through aggregation of the Bootstrap iterations’ confusionmatrices.0数据集质量和验证。研究人员1进行了手动0T. Hirsch和B. Hofer0对于外部验证，研究人员2对246个随机抽样和盲化的问题进行了分类0如上所述的分类。六个月后，研究人员1重新对从该集合中随机抽样和盲化的100个问题进行了内部验证。在这个内部验证步骤中，研究人员1的CohensKappa得分为0.95，表明 几乎完美的一致性 ，加权平均F1为0.96。0最终数据集。在初步的ML实验中，我们确定了三个0抽样和盲化问题。这种外部验证导致Cohens Kappa得分为0.69，表明有重大一致性 ，加权平均F1为0.80。0不适合我们故障类型分类方法的项目。这些项目包括：LeakCanary，一个Java内存泄漏检测库，Bazel，一个构建自动化框架，以及JHipster，一个Web应用程序生成器。它们的领域使得仅基于故障报告的NLP方法无法正确识别某些bug类型，而没有关于项目领域和目的的知识。例如，来自内存泄漏检测库的bug报告利用了与内存泄漏直接相关的词汇，进一步通过软件项目中的类名和函数名加强了所有类别的bug，类似地，来自构建框架的bug报告具有与任何通用软件项目中的其他bug相关的词汇。因此，我们从训练/测试集和调查答案中删除了这些项目的所有内容。0我们使用研究人员1的初始手动分类作为0实验的基础，并通过对多数类别进行欠采样来平衡生成的数据集，从而得到了包含每个124个bug报告的等大小类别。我们实验中使用的最终数据集总共包含来自71个不同软件项目的496个bug报告。05.4. ML分类器0ML算法。我们选择了逻辑回归（LR），多诺-0朴素贝叶斯（MNB），随机森林（RF）和支持向量机（SVM）基于其他研究人员在类似努力中的工作[6,8,9,17,36]，以及它们的易用性。此外，我们采用基于LR的堆叠分类器集成学习方法来结合表现最佳的模型。0实验设置。我们的模型流水线包括去除工件，0和解驼式命名，然后进行词干处理和计数向量化，通过Tf-idf，最后进行分类器算法。我们对超参数调整和模型选择进行了五折嵌套CV。内部�-foldCV用于模型的超参数调整。所选的超参数空间仅涉及预处理步骤的启用或禁用，包括停用词去除，解驼式命名，词干处理，工件去除和Tf-idf的使用。分类器算法的参数未经调整，保持其默认值（scikit-learn0.24.2）。外部�-fold用于模型选择。我们实验中使用的所有k-foldCV拆分都是以分层方式进行的，以保持输入数据集的平衡性。0为了评估生成的模型，我们使用分层自举。080-20的训练-测试拆分，�=100次重复和置信水平�=0.95。我们计算所有的平均性能得分06. 实验结果06.1. RQ1：人类分类bug报告的性能如何？0动机：通过回答RQ1，我们建立了一个基准来比较0ML方法。0图1.调查F1自举置信区间。0方法：我们进行了一项在线用户调查，要求参与者0根据其故障类型对文本bug报告进行分类。调查通过电子邮件和直接消息向驻地软件公司的专业开发人员和计算机科学专业的硕士学生进行推广。可以假定大多数调查参与者是学生。允许匿名参与，同时披露联系电子邮件地址的参与者可以赢得知名在线商店的代金券。允许同一人多次提交。对于每次提交，我们跟踪IP地址，电子邮件地址（可选），在每个bug报告上花费的时间以及每个bug报告的相应答案。0从平衡的500个bug报告中随机抽取了一个平衡的样本0研究人员1已经调查了762个bug报告（见5.3）。参与者从500个bug报告中随机选择了十个bug报告。bug报告的格式与GitHub上的原始格式相同，并且每个bug报告都有单选答案。虽然我们没有提供指向GitHub上原始bug工单的链接，但内联图像（例如截图）和bug报告文本中的链接得以保留。参与者在调查入口页面上得到了我们分类模式的简短介绍。在参与过程中，每个页面内联提供了四种故障类型的简短解释。此外，提供了我们分类模式的详细解释和示例的链接。没有时间限制。0花费的时间和IP地址，并没有发现任何表明恶意意图的提交。这些提交为我们提供了510个手动分类的错误报告，供我们进行分析。根据讨论，删除了来自三个项目的错误报告，留下了483个分类错误作为下面讨论的基础。0图1显示了调查提交的Bootstrap区间(�=01000，�=0.95)。所有分类的错误报告的加权平均F1的平均性能为0.62。参与者在Memory错误上表现最佳，平均F1得分为0.63，在Semantic错误上表现最差，平均F1得分为0.47。0图2显示了所有接收到的混淆矩阵的归一化结果0其他错误最常被参与者误分类为Semantic错误。Concurrency错误的召回率最低(0.56)，Memory错误的最高(0.68)。Semantic错误的精确率最低(0