软件缺陷在软件的开发和维护过程中是不可避免的, 软件缺陷报告是软件维护过程中重要的缺陷描述文档, 高质量的软件缺陷报告可以有效提高软件缺陷修复的效率. 然而, 由于存在许多开发人员、测试人员和用户与缺陷跟踪系统交互并提交软件缺陷报告, 同一个软件缺陷可能被不同的人员报告, 导致了大量重复的软件缺陷报告. 重复的软件缺陷报告势必加重人工检测重复缺陷报告的工作量, 并造成人力物力的浪费, 降低了软件缺陷修复的效率. 以系统文献调研的方式, 对近年来国内外学者在重复软件缺陷报告检测领域的研究工作进行了系统的分析. 主要从研究方法、数据集的选取、性能评价等方面具体分析总结, 并提出该领域在后续研究中存在的问题、挑战以及建议.
Software bugs are inevitable in the process of software development and maintenance. Software bug reports are an important bug description documents in the software maintenance process. A high-quality software bug report can effectively improve the efficiency of software bug repair. Nevertheless, due to the existence of many developers, testers, and users interact with the bug tracking system and submit bug reports, the same bug may be reported by different parties, resulting in a large number of duplicate software bug reports. Duplicate software bug reports will inevitably increase the workload of manual detection of duplicate bug reports, cause waste of manpower and material resources, and reduce the efficiency of bug repair. This study systematically analyzes the research work of worldwide scholars in the field of duplicated detection of bug reports in recent years by means of literature research. It mainly analyzes and summarizes the research methods, data set selection, performance evaluation, etc, and puts forward the problems and challenges in the follow-up work in this field, and the correspondent's suggestions.
随着信息产业的快速迅猛发展、软件产业规模的不断扩大以及软件开发流程的愈加复杂, 软件缺陷无法避免[
[
过去已有大量的研究工作聚集在重复软件缺陷报告的自动检测方法上, 为了更好地理解重复检测方法面临的主要问题以及目前的研究进展, 对这一领域的研究进行系统的分析、总结和比较是十分必要的. 本文的参考文献尽力覆盖近20年来与重复软件缺陷报告检测方法相关的研究工作, 同时包含与重复软件缺陷报告检测方法研究的其他相关的主要文献. 通过系统性地研究相关的文献资料来尝试回答以下问题: (1) 调研文献主要实现了哪些研究方法以检测重复的软件缺陷报告? (2) 调研文献的研究方法的分类方式有哪些? (3) 不同的研究方法采用的评价指标有哪些? (4) 在已有的研究方法中, 数据集的来源以及数据规模如何? (5) 不同研究方法之间的效果和性能如何?
基于以上提出的问题, 首先搜索了近20年来重复软件缺陷报告检测相关的研究工作, 通过人工审查的方式, 筛选出近20年来的36篇高质量论文作为研究对象; 然后, 以重复软件缺陷报告检测为研究主题, 从研究方法、数据集和性能评价等方面提取研究文献数据进行总结分析. 本文通过以上过程调研了重复软件缺陷报告检测领域的研究现状, 提出了一些重要的发现, 最后总结了该领域面临的问题与挑战.
综述框架
● 首先, 确定综述研究的搜索关键词以及文献检索来源, 进行初步的文献检索工作;
● 接着, 对检索得到的文献进行人工审查和评估, 剔除与重复软件缺陷报告检测研究无关的文献;
● 随后, 对筛选出来的文献进行归纳总结和分类, 从重复软件缺陷报告检测研究的新技术、新理论和实证研究两大类展开深入的讨论. 对于提出新技术、新理论的文献, 本文根据文献采用的具体技术进行分类总结, 总结出以下3种主要技术方法: 自然语言处理(natural language processing, NLP)、机器学习(machine learning, ML)、深度学习(deep learning, DL). 对文献采用的数据集来源进行分析、比较和总结. 此外, 总结了此类文献常用的性能评价指标, 从性能评价指标角度比较不同文献方法的有效性.
本文采用以下流程来完成相关文献的检索和筛选.
● 首先定义文献的选取标准: 该文献针对重复软件缺陷报告检测提出了新理论、新技术, 或者该文献对重复软件缺陷报告检测方法的相关理论提供了实证研究支持, 或者对其应用进行了实证研究讨论;
● 此外, 检索到的文献必须是公开发表的期刊、会议、技术报告或书籍.
依据以上标准, 本文通过以下4个步骤对文献进行检索和筛选.
(1) 检索来源: 本文文献检索主要考虑了DBLP Computer Science Bibliography、ACM Digital Library、IEEE Xplore Digital Library论文搜索引擎和论文数据库;
(2) 检索关键字: 文献检索的关键字包括Duplicate Bug Report、Bug Report、Error Report、Similar Bug Report、Bug Report Duplicate Detection、Bug Report Analysis、Duplicate Detection、Software Bug Report、Duplicate Software Bug Report;
(3) 文献审查: 通过人工审查的方式移除掉与综述主题无关的文献, 并通过查阅相关论文的参考文献和相关研究人员发表的论文列表, 以进一步识别出遗漏的文献;
(4) 文献评估: 对于筛选出来的文献, 我们遵循Kitchenham和Charters[
设置问题如下.
● QA1: 研究问题——重复软件缺陷报告的检测. 从文献标题、摘要、关键字以及简介中获取研究方向的信息, 是否有明确研究为重复软件缺陷报告的检测. 当文献对QA1问题描述为0分值时, 则该文献的总分值为0, 不再进行其他问题的验证; 1分值代表此文献除了对此问题有部分描述以外, 还对其他研究方向有所涉猎; 2分值代表有明确的描述;
● QA2: 对于提出新技术、新理论的文献, 文中应当具有清晰的重复软件缺陷报告检测方法的具体描述. 对于实证研究类的文献, 应当明确指明重现的重复软件缺陷报告的检测方法是什么. 当QA2问题描述为0分值时, 表示在提出新技术、新理论的文献中没有针对重复软件缺陷报告检测的具体方法描述, 或实证研究文献中没有指明重现的重复软件缺陷报告检测方法; 1分值表示在提出新方法的文献中方法描述不足; 2分值表示在提出新方法的文献中有清晰的方法描述和逻辑, 或实证研究文献中明确指明了重现的重复软件缺陷报告检测方法;
● QA3: 是否有详细的实验设置和结果?
● QA4: 是否包含对实验结果的性能分析评价?
对于文献的评估工作, 我们邀请了华为西安研究所的3位从事相关领域的高级软件工程师来完成. 当出现分值评估不一样的情况时, 按照少数服从多数的原则进行最终的分值确定, 按照上述策略对检索得到的论文进行质量评估排序: 高(分值=8)、中(4≤分值≤7)、低(0≤分值≤3).
通过以上步骤进行文献的检索与筛选, 我们累计得到具有中高评分的36篇文献, 其中, 提出新方法的文献34篇, 实证研究类文献2篇, 并将这些文献纳入到综述的后续文献分析中, 见
最终的文献列表及对应质量评分
研究编号 | 对应参考文献编号 | 质量评分 | 研究编号 | 对应参考文献编号 | 质量评分 | |
S1 | [ |
7 | S19 | [ |
8 | |
S2 | [ |
8 | S20 | [ |
8 | |
S3 | [ |
8 | S21 | [ |
8 | |
S4 | [ |
8 | S22 | [ |
8 | |
S5 | [ |
4 | S23 | [ |
5 | |
S6 | [ |
8 | S24 | [ |
8 | |
S7 | [ |
4 | S25 | [ |
8 | |
S8 | [ |
8 | S26 | [ |
8 | |
S9 | [ |
8 | S27 | [ |
8 | |
S10 | [ |
6 | S28 | [ |
8 | |
S11 | [ |
8 | S29 | [ |
8 | |
S12 | [ |
6 | S30 | [ |
8 | |
S13 | [ |
8 | S31 | [ |
8 | |
S14 | [ |
8 | S32 | [ |
8 | |
S15 | [ |
4 | S33 | [ |
8 | |
S16 | [ |
6 | S34 | [ |
8 | |
S17 | [ |
8 | S35 | [ |
6 | |
S18 | [ |
6 | S36 | [ |
8 |
我们对调研文献的发表源进行了分析, 最终结果见
论文发表源统计
类别 | CCF级别 | 会议/期刊源 | 文献编号 | 数量 |
会议文献 | A | ICSE | {S1, S3, S4, S5, S6, S27, S28, S31} | 8 |
ASE | {S7, S8, S9} | 3 | ||
B | SANER | {S10, S14} | 2 | |
ICPC | {S11} | 1 | ||
ISSRE | {S22, S26, S29} | 3 | ||
ICSME | {S24} | 1 | ||
C | QRS | {S15, S20} | 2 | |
MSR | {S16, S17, S18} | 3 | ||
APSEC | {S19, S21, S23} | 3 | ||
− | ASWEC | {S34} | 1 | |
IS | {S35} | 1 | ||
CSMR | {S33} | 1 | ||
期刊文献 | A | TSE | {S32} | 1 |
B | IST | {S12, S13, S25, S30} | 4 | |
JSS | {S2} | 1 | ||
− | IEEE ACCESS | {S36} | 1 |
为了保证文献的权威性, 筛选所得的文献中绝大部分(累计32篇)发表在CCF推荐的期刊和会议上, 也有一些(累计4篇)发表在非CCF推荐的期刊和会议上.
我们对每年发表的相关论文的数量进行统计, 结果如
研究文献按年份的分布情况
本文第1节介绍重复软件缺陷报告的例子, 然后总结使用自然语言处理方法检测重复软件缺陷报告的通用步骤. 第2节研究总结重复软件缺陷报告检测方法的分类方法以及调研文献中使用到的技术方法. 第3节讨论文献中使用到的数据集来源、规模和特征字段的选取. 第4节总结文献采用的性能评价指标及其有效性评价. 第5节对系统文献调研的有效性影响因素进行分析. 第6节对已有研究进行总结, 提出该领域面临的问题和我们的建议. 第7节总结全文.
本节介绍关于重复软件缺陷报告检测技术方法的预备知识. 其中, 第1.1节介绍重复软件缺陷报告的例子, 以辅助理解重复软件缺陷报告检测问题. 第1.2节介绍重复软件缺陷报告检测方法的通用步骤.
重复缺陷报告的示例
Tag名称 | 内容 | |
Bug ID | 481543 | 481545 |
Product | CFT | CFT |
Component | General | General |
Summary | Refactor client requests so that different versions |
Refactor client requests so that different versions |
Description | PWS/Diego requires changes to the underlying client to address issues like 503 on fetching application stats, as well as different mechanism to fetch files. However, this may not be compatible or applicable to other CF server definitions like BlueMix. On possibility is to define a request factory that is associated with a server definition that gets used by the server behaviour, and allows server definitions to use a default version or specify their own via | PWS/Diego requires changes to the underlying client to address issues like 503 on fetching application stats, as well as different mechanism to fetch files. However, this may not be compatible or applicable to other CF, server definitions like BlueMix. On possibility is to define a request factory that is associated with a server definition that gets used by the server behaviour, and allows server definitions to use a default version or specify their own via |
基于NLP的重复软件缺陷报告检测流程
这一节调研不同文献采用的重复软件缺陷报告检测方法, 对其研究方法进行分类, 以研究不同的重复软件缺陷报告检测方法的研究情况.
为了更好地对文献进行系统化的分析和结构化研究, 我们在本小节进行重复软件缺陷报告检测方法分类方式的研究.
2016年, Lin等人[
(1) 基于排名的方法. 主要思想是: 将新的软件缺陷报告作为查询条件, 从现有的软件缺陷报告中构造可能重复的软件缺陷报告的排序列表;
(2) 基于二进制的方法. 主要思想是: 将软件缺陷报告作为输入, 输出为此软件缺陷报告的标记(重复或者不重复);
(3) 基于决策的方法. 输入为一对软件缺陷报告, 输出为确定它们是否是彼此的重复软件缺陷报告.
根据Lin策略, 我们将筛选出的文献进行了分类, 具体分类见
基于Lin策略对已有文献的分类结果
分类策略 | 研究编号 | 数量 |
排名方法 | {S1, S2, S4, S5, S6, S7, S8, S10, S13, S15, S20, S21, |
22 |
二进制的方法 | {S12, S14, S24} | 3 |
决策的方法 | {S3, S9, S11, S16, S17, S18, S19, S25, S34, S35, S36} | 11 |
2020年, Behzad等人[
(1) 文本: 文本是利用自然语言处理和信息检索技术提取软件缺陷报告文本字段相似性的一种特征;
(2) 时态: 时态是一种特征, 它显示两个软件缺陷报告之间的间隔时间;
(3) 结构: 结构是一种基于运行时信息和软件缺陷报告中的堆栈跟踪计算的特征类型;
(4) 分类: 分类是一种使用等式比较字段分析两个软件缺陷报告相关性的特征类型;
(5) 主题和上下文: 主题和上下文是一种用于将软件缺陷报告的文本字段与包含独立内容的单词列表进行比较的特征.
根据Behzad策略, 我们将筛选出的文献进行了分类, 具体分类见
基于Behzad策略对已有文献的分类结果
分类策略 | 研究编号 | 数量 | ||||
文本 | 时态 | 结构 | 分类 | 主题和上下文 | ||
− | − | {S1, S3, S14, S17} | 4 | |||
− | − | − | − | {S2, S4, S6, S7, S21, S22, S23, S24, S28, S30, S32} | 11 | |
− | − | − | {S5, S27} | 2 | ||
− | − | − | {S8, S18, S19} | 3 | ||
− | − | − | {S9, S15, S34, S35, S36} | 5 | ||
− | − | {S10} | 1 | |||
− | − | − | − | {S11, S26} | 2 | |
− | − | {S12} | 1 | |||
− | − | − | − | {S13, S31, S33} | 3 | |
− | − | {S16, S25} | 2 | |||
− | − | {S20} | 1 | |||
− | − | − | − | {S29} | 1 |
其中, 使用到基于文本特征的策略方法共计有29篇文献, 基于分类特征的策略方法共计15篇, 基于主题和上下文特征的策略方法共计9篇, 基于结构特征的策略方法共计7篇, 基于时态特征的策略方法共计4篇.
在研究总结前人分类策略的基础上, 本文提出了一种基于技术研究的分类策略, 具体思想是: 根据研究文献中使用到的具体的技术手段进行分类. 对于研究的文献的分类可以分为3类.
(1) 基于自然语言技术(natural language processing, NLP)的方法;
(2) 基于机器学习(machine learning, ML)的方法;
(3) 基于深度学习(deep learning, DL)的方法.
从
文献使用的研究方法及对应文献
技术方法所属分类 | 技术方法 | 文献编号 | 数量 |
NLP | 词(文档)嵌入模型 | {S3, S4, S19, S22, S23, S24, S29, S30} | 8 |
余弦相似性 | {S20, S25, S30, S26, S34} | 5 | |
TF-IDF算法 | {S2, S10, S22, S23, S30, S15, S33} | 7 | |
VSM模型 | {S2, S5, S7, S15, S27, S28} | 6 | |
BM25F模型 | {S2, S8, S9, S14, S17, S32} | 6 | |
隐马尔可夫模型 | {S13} | 1 | |
{S21} | 1 | ||
word2vec | {S2} | 1 | |
其他 | {S31} | 1 | |
ML | 主题模型LDA | {S3, S8, S18, S35} | 4 |
支持向量机(support vector machine, SVM) | {S2, S6, S16} | 3 | |
贝叶斯算法 | {S35} | 1 | |
聚类算法 | {S34} | 1 | |
其他 | {S1} | 1 | |
DL | 深度神经网络(deep neural network, DNN) | {S4, S29} | 2 |
卷积神经网络(convolutional neural network, CNN) | {S11, S24, S19, S36} | 4 | |
长短期记忆网络(long short-term memory, LSTM) | {S24} | 1 |
重复软件缺陷报告的检测一直是软件维护中的关键问题之一, 其主要目的是为避免将同一缺陷再分配给不同的开发人员.
(1) 词嵌入模型的应用
Budhiraja等人[
Budhiraja等人[
词嵌入模型注重单词间的关系, 考虑单词出现的上下文; TF-IDF方法则更注重的是不同文档在整个语料库中的关系. Yang等人[
Wang等人[
(2) VSM模型、TF-IDF算法、余弦相似度的应用
Sabor等人[
Chaparro等人[
Runeson等人[
设VSM中的两个向量:
向量空间模型示意图
任意两个软件缺陷报告
[
(3) BM25F模型
BM25F是结构化文档检索有效的文本相似性函数, 是专门为短文本查询设计的. 给定
Sun等人[
(4) 其他
Ebrahimi等人[
Nguyen等人[
Su等人[
Akilan等人[
Xiao等人[
本节首先识别调研文献中的研究方法并对其归类, 总结了基于NLP技术、ML技术、DL技术在重复软件缺陷报告检测方法应用的现状. 我们对3种技术在重复软件缺陷报告检测的表现进行总结分析. 基于NLP技术进行重复软件缺陷报告检测工作时需要依赖大量的数据集进行语言模型的训练, 语言模型的选择在很大程度上决定了方法的有效性. 基于ML技术需要依赖大量的训练数据, 需要人工进行标注训练集, 降低了训练效率; 再者, 基于ML技术在处理更高阶、更抽象的自然语言时只能够学习预先制定的规则, 而对于规则之外的语言特征无法进行有效的表示. 基于DL技术, 如卷积神经网络、循环神经网络等, 通过对生成的词向量进行学习, 自动地学习更高阶的自然语言. 总体来说, 基于DL技术与其他两种技术相比, 在重复软件缺陷报告检测上具有更好的性能.
本节主要讨论调研文献的研究对象, 包括数据集来源、数据集规模以及数据提取分析. 其中, 数据集来源主要为开源数据集. 在此, 我们提出一个判断数据集规模的准则, 即根据软件缺陷报告的数量级将数据集规模分为以下3类.
(1) 小型数据集(S): 软件缺陷报告数量 < 10K;
(2) 中型数据集(M): 10K≤软件缺陷报告数量 < 100K;
(3) 大型数据集(L): 软件缺陷报告数量 > 100K.
在案例研究/实验中, 数据集是评估方法有效性的重要因素. 本文调研了已有研究的数据集使用情况, 包括数据集来源和数据集规模.
已有研究在重复软件缺陷报告检测方法的研究中, 使用的数据集来源通常为大型开源项目公开的数据集.
研究文献使用的数据集情况汇总
文献编号 | 数据集(格式: 来源名称时间周期, 如Eclipse 2001.10-2014.12) |
S14 | (1) Mozilla 2010, (2) Eclipse 2008, (3) OpenOffice 2008-2010, (4) Android 2007.11-2012.09 |
S16, S8, S32 | (1) Mozilla 2010, (2) Eclipse 2008, (3) OpenOffice 2008-2010 |
S9 | (1) Mozilla 2010, (2) Eclipse 2008, (3) OpenOffice 2008-2010, (4) Eclipse 2001-2007 |
S6 | (1) Firefox至2007.06, (2) Eclipse 2008, (3) OpenOffice 2008 |
S2 | (1) Apache 2009-2013, (2) ArgoUML 2000-2013, (3) SVN 2001-2013 |
S3 | (1) Mozilla 2006-2013 |
S4 | (1) Mozilla 1998.04-2014.12, (2) OpenOffice 2000.10-2014.12 |
S11, S24 | (1) OpenOffice 2000.10-2014.12, (2) Eclipse 2001.10-2014.12, (3) NetBeans 1998.08-2014.12 |
S10 | (1) Firefox 2010, (2) OpenOffice 2008-2010, (3) Eclipse 2001-2007, ...(20) |
S12 | (1) Android 2008-2017, (2) Mozilla 2010-2013, (3) Eclipse 2008-2013, (4) OpenOffice 2008-2013 |
S13 | (1) Firefox至2016年, (2) GNOME至2016年 |
S15 | (1) 软件测试竞赛2016-2018 |
S17, S18 | (1) Android 2007.11-2012.09 |
S19 | (1) Hadoop 2005.07-2018.12, (2) Hdfs 2006.04-2018.01, |
S20 | (1) Eclipse 2001.10-2015.02 |
S22 | (1) Eclipse 2001.10-2013.02, (2) Mozilla 2001.09-2007.10 |
S25 | (1) OpenOffice至2014.03, (2) Eclipse至2011.12, (3) Firefox至2012.06(每个数据集时间周期 > 10年) |
S26 | (1) Firefox启动至2012 |
S27 | (1) Eclipse 2004.06, (2) Firefox 2004.01-2001.04 |
S29 | (1) Eclipse 2001.10-2018.09, (2) GCC 1999.08-2018.09, (3) LLVM 2003.10-2018.09, |
S30 | (1) Baidu CrowdTest crowdtesting platform 2017.06.01-2017.06.10 |
S33 | (1) Eclipse 2001.10-2007.12 |
S34 | (1) Eclipse 2008.1-2008.12, (2) Mozilla 2010.1-2010.12, (3) Open office 2010.1-2010.12 |
S35 | (1) Apache 1998.5-2013.10, (2) Mozilla 2001.5-2013.10, (3) Eclipse 2001.7-2013.10 |
我们对调研文献中使用的来自开源项目的数据集进行统计分析,
开源数据集的来源
在调研文献中, 研究人员在使用数据集进行验证实验时可能会使用来自不同开源项目的数据集, 即联合数据集. 我们对调研文献的数据集来源的个数进行统计分析, 其中有2篇文献(约占6%)只提出了研究方法, 没有明确方法是否在数据集上进行验证, 如
调研文献使用数据集个数情况
● 文档管理系统: OpenOffice、LibreOffice、SVN;
● 开发工具: Eclipse、NetBeans、Groovy、Maven、ArgoUML、GCC、LLVM;
● 桌面应用程序: GNOME、Freedesktop、KDE;
● 浏览器: Firefox、Mozilla;
● 框架/库: Struts、PDFBox、MapReduce、Cassandra、Hive;
● 系统/组件: Oracle、Hadoop、Spark、Hdfs;
● 服务器: Apache;
● 操作系统: Android、Linux kernl.
调研文献数据集软件项目类型分布情况
软件项目类型 | 文献编号 |
文档管理系统 | {S2, S4, S6, S8, S9, S10, S11, S12, S14, S16, S24, S25, S29, S34, S36} |
开发工具 | {S6, S8, S9, S10, S11, S12, S14, S16, S20, S21, S22, S23, S24, S25, S27, S29, S33, S34, S35, S36} |
桌面应用程序 | {S13, S29} |
浏览器 | {S3, S4, S6, S8, S9, S10, S12, S13, S14, S16, S22, S25, S26, S27, S34, S35, S36} |
框架/库 | {S10, S19} |
系统/组件 | {S1, S10, S19} |
服务器 | {S2, S35, S36} |
操作系统 | {S12, S14, S17, S18, S29} |
根据前面定义的数据集规模, 我们对调研文献使用的数据集规模进行统计分析, 结果如
调研文献的数据集规模分布情况
调研文献中约53%的研究使用大型数据集, 约25%为中型数据集, 约14%为小型数据集规模, 文献S1、S15、S28以及S31使用的数据集来自特定软件项目. 例如: 文献S15使用的是软件测试竞赛的数据集, 该研究与人工评审方法进行对比, 从时间和评估率两个方面证实该研究方法的优越性. 因此, 这些数据集具有特定的软件项目场景要求.
本节分析了调研文献中研究所使用的数据集来源和规模, 下面简述主要发现.
(1) 调研文献中, 重复软件缺陷报告检测方法主要使用主流的缺陷跟踪系统中公开的数据进行实验评估. 在选取数据集时, 存在选取数据集时间周期过短而导致选取的软件缺陷报告不全面, 造成遗漏重复软件缺陷报告的问题;
(2) 数据集的大小会影响重复软件缺陷报告检测方法的准确性, 随着缺陷跟踪系统中软件缺陷报告的数量越来越多, 重复软件缺陷报告检测方法的精度会降低. 因此, 为了研究方法性能评估的可信赖性, 研究人员倾向于使用主流的大型开源项目的数据集, 或是多个数据集联合使用. 当然, 不同类型的研究方法选择的数据集规模也会存在不同的偏好, 如果研究方法在多种场景都适用, 那么选择多个开源项目的数据集进行评估更有利于性能评价;
(3) 调研文献中, 对于数据集选取都经过细致的比较与斟酌, 由此可见数据集对于研究方法性能评估的重要性. 仅使用单个数据集进行方法验证, 不能表明该方法在其他数据集上的性能, 无法证实其泛化能力.
数据提取是指在重复软件缺陷报告检测方法的研究案例中, 研究者基于软件缺陷报告提取其中的描述文本和元数据字段的文本信息. 本节调研文献中研究采用的软件缺陷报告的字段, 我们称其为特征字段, 然后对其进行分类总结.
软件缺陷报告是描述软件潜在问题的文档, 其主要目的是为开发人员提供缺陷的详细信息, 以便开发人员可以快速地完成对软件缺陷的严重程度的预测、分配对应的缺陷修复人员、定位和修复软件缺陷等软件活动, 又称为软件Bug报告、软件错误报告、软件故障报告等. 本文中使用的名称是软件缺陷报告. 一个典型的软件缺陷报告如
Eclipse中570494软件缺陷报告示例
软件缺陷报告包含的内容可以分为描述文本和元数据两类, 其中, 描述文本包括标题、描述和评论. 其他的特征字段属于元数据. 如
Eclipse中软件缺陷报告的主要字段展示
特征 | 描述 |
Bug ID(软件缺陷编号) | 软件缺陷报告的唯一表示, Bug 570494表示Eclipse编号为570494的唯一软件缺陷报告 |
Summary(标题) | 软件缺陷的简要描述 |
Description(描述) | 软件缺陷的详细描述, 缺陷产生的详细信息 |
Status(状态) | 软件缺陷目前所属的处理状态, 如: 打开、已修复、关闭等 |
Product(产品) | 软件缺陷所属的产品 |
Component(模块) | 软件缺陷所属的模块 |
Importance(重要性) | 软件缺陷的重要程度, 包括优先级和严重程度两个方面 |
Hardware(硬件) | 软件缺陷发生的硬件环境 |
Assignee(分配人员) | 软件缺陷分配的维护人员 |
URL(链接地址) | 软件缺陷相关的链接地址 |
Keywords(关键字) | 软件缺陷的主要特点 |
Duplicates(重复缺陷报告) | 重复软件缺陷报告的标识 |
Depends on(依赖) | 软件缺陷依赖于其他缺陷的解决 |
Blocks(阻塞) | 软件缺陷影响到的其他缺陷 |
Reported(报告) | 软件缺陷的上报时间和上报人员 |
Attachments(附件) | 软件缺陷相关的其他信息(如缺陷故障的截图、视频、执行信息等) |
Comment(评论) | 其他人员对于软件缺陷的看法或建议, 或是对于描述信息的补充 |
本节调研各文献研究方法使用缺陷报告中哪些关键特征字段进行重复软件缺陷报告的检测工作, 探讨特征字段的选取对于重复软件缺陷报告的检测工作性能的影响.
文献S1方法中使用产品和组件的关系作为限制条件对潜在重复软件缺陷报告进行检测时获得了较好的性能, 但在增加版本作为限制条件的时候, 检测结果会错过部分重复软件缺陷报告. 文献S3、S4、S6、S7、S8、S10、S21、S25、S35、S36只考虑使用软件缺陷报告中的描述文本标题和描述部分. 文献S5使用软件缺陷报告的特征字段标题、描述以及执行信息作为检测重复软件缺陷报告的检测内容. 文献S9、S17、S34检测方法不仅检测摘要和描述字段中文本内容的相似性, 还包括产品、组件、版本、优先级等特征字段的相似性检测. 文献S11、S22、S26将产品和组件这两种软件缺陷报告的元数据与描述文本的标题和描述一起进行处理, 仍然以标题和描述为重复分类标准的主要依据, 可以提高重复软件缺陷报告分类的准确性. 文献S23同样是选取描述文本标题和描述以及元数据产品和组件4个特征字段作为重复检测标准的依据, 然而, S23是将产品和组件作为一组特征计算该组的相似性分数, 我们认为, 产品和组件的组合特征能够很好地反映软件缺陷报告之间的结构关系.
文献S14使用缺陷报告中产品、组件、优先级和版本字段, 在提取新的软件缺陷报告的描述文本/元数据字段特征时, 以软件缺陷报告对的方式比较软件缺陷报告的相似性, 并生成每对检测的软件缺陷报告中每个基于字段的相似性分数. 文献S15提取软件缺陷报告中的缺陷编号、描述和标题作为重复检测的特征字段, 缺陷编号对于每个缺陷报告具有唯一的标识作用. 文献S16选取缺陷报告编号、标题、描述、产品、组件、类型、优先级、版本、打开日期作为重复软件缺陷报告检测分类特征的基础, 然后将描述文本标题和描述与其他的元数据串联在一起用于生成联合特征计算其相关性. 文献S18选取缺陷报告编号、打开日期、状态、标题、描述、组件、优先级和版本特征字段最为文本检测的重点, 与文献S16中字段的选取相比, 舍弃了版本字段. 文献S18认为, 软件缺陷报告中很少有指定版本字段, 因此在检测的过程中忽略版本字段特征的相似度检测. 文献S24在特征字段的选取工作中, 也将缺陷编号作为一个缺陷报告的唯一标识, 选取组件、标题、描述作为相似性检测工作主要的特征依据. 文献S19认为: 随着软件系统频繁更新版本, 同一应用程序的多个版本的软件系统可能会共存. 用户使用的版本更新并不是马上进行的, 在其他较低版本中可能会再次遇到较高版本中已解决的问题. 因此, S19选取元数据组件、版本、创建时间和优先级等和描述文本串联起来, 将串联向量放入输出层进行逻辑回归分类判断是否为重复的软件缺陷报告. 文献S32选取缺陷报告编号、描述、标题、组件、优先级、类型、版本和报告日期字段特征作为重复软件缺陷表达检测的检测依据.
文献S20选取的特征字段与其他调研文献有较大的差别, 在特征字段的选取上并没有选取描述文本的字段作为重复检测的依据, 而是选取堆栈跟踪信息与元数据组件和严重程度的线性组合测量一对软件缺陷报告的相似性, 因此方法存在一定的局限性, 对于不包含堆栈跟踪信息的软件缺陷报告将不能进行重复检测工作, 只能用来检测特定的包含堆栈跟踪信息的软件缺陷报告, 对于当前主流的缺陷跟踪系统不具备普遍的适用性. 而文献S31、S33仅仅选取了堆栈跟踪信息作为软件缺陷报告重复检测的依据, 与其他文献中特征字段的选取相比更加单一, 也不具备普遍的适用性.
文献S27选取堆栈跟踪信息以及描述文本标题和描述作为重复检测工作的主要依据, 并设置了一系列的策略, 在不同的情况下, 只选取堆栈跟踪信息的相似性、描述文本标题和描述字段的相似性或者是两者相似性之间的结合分数来判断两个缺陷报告的相似性. 文献S28指出: 53%的重复缺陷报告是在20天内提交的, 90%的重复缺陷报告是在20−60天之间提交的. 因此, 在重复检测工作的过程中选取软件缺陷报告开始时间字段可以在一定程度上缩小软件缺陷报告的查找空间, 文献S28也选取描述文本标题和描述特征字段作为重复检测工作的主要检测依据. 文献S29选取产品、组件、版本、严重性、优先级和标题, 选取的特征字段具有以下关系连接: 标题和组件、标题和版本、标题和优先级、标题和严重性以及产品和组件, 因此, 文献S29制定了这5个组合相似性特征来表示两个软件缺陷报告之间的相似性. 文献S30在考虑文本相似性的基础上增加了屏幕截图的相似性计算来表示两个软件缺陷报告之间的相似性.
软件缺陷报告的字段值通常会随着状态的变化或时间的推进而更改[
通过以上调研文献特征字段选取的研究总结, 我们知道, 目前的研究方法主要依靠描述文本的特征字段标题和描述作为重复软件缺陷报告检测工作的检测重点. 通过元数据字段和描述文本字段的结合, 可以实现很好的相似性测量, 在检测工作中应该尽量全面地考虑有用的检测字段, 提高检测的准确性和可靠性. 执行信息(堆栈跟踪信息)也是一个检测重复软件缺陷报告标准很好的衡量指标. 在字段选取和方法策略的执行上, 应尽量考虑方法对于目前缺陷跟踪系统中重复软件缺陷报告检测的普适性和实用性, 从多角度衡量每个特征字段对于重复软件缺陷报告检测工作的作用.
本节主要研究总结已有的研究文献中的性能评价指标, 对其分类并分析已有研究方法的性能和效果.
我们提取出各文献中的评价指标并对其进行分类, 评价指标是评价文献研究方法的性能和效率的关键特性, 我们据此得出不同的研究方法之间的性能差异.
(1) Recall at Top
该指标又被称为Accuracy@
(2) MAP (mean average precision)
MAP具有良好的稳定性, 对于衡量评估排序技术性能, 在每个相关的重复软件缺陷报告被检索到之前, 该标量返回的是前
其中,
(3)
该指标是重复软件缺陷报告的查准率和查全率的调和平均数, 可以对查准率和查全率这两个指标进行有效的平衡. 其计算公式如下:
Recall与Precision的定义见后文公式(9)、公式(10).
(4) kappa系数
这是一种衡量分类精度的指标.
则其kappa系数计算公式如下:
(5) Accuracy(准确率)
其计算公式如下:
混淆矩阵
真实值
Positive
Negative
预测值
Positive
TP
FP
Negative
FN
TN
TP (true positive): 表示的是正确识别出来的重复软件缺陷报告. TN (true negative): 表示正确识别的不是重复的软件缺陷报告. FN (false negative): 表示的是把不是重复的软件缺陷报告错误的识别成重复的软件缺陷报告. FP (false positive): 表示的是把重复的软件缺陷报告错误地识别为非重复的软件缺陷报告.
(6) Precision(精准率)
其计算公式如下:
(7) Recall(召回率)
其计算公式如下:
(8) MRR (mean reciprocal rank)
该指标返回的是一系列查询的倒数排名的平均, 其计算公式如下:
(9) AUC (area under the curve)
ROC曲线下方的面积. ROC曲线的横坐标是FP, 纵坐标是TP, AUC量化了ROC曲线表达的分类能力; 分类能力越好, AUC越大, 输出概率越合理, 排序的结果也越合理.
我们对研究文献的性能评测指标的使用进行统计, 统计结果显示, 采用次数最多的评价指标是Recall at Top
调研文献评价指标及分类
评价指标 | 文献 | 数量 |
Recall at Top |
{S2, S3, S4, S6, S8, S9, S10, S13, S20, S21, S22, S23, S26, S27, S28, S30, S32, S33} | 17 |
MAP | {S9, S10, S13, S22, S23, S30, S32} | 7 |
{S11, S12, S19, S29, S31, S34, S36} | 7 | |
kappa | {S14, S17, S18} | 3 |
Accuracy | {S11, S12, S14, S15, S17, S18, S19, S29, S35, S36} | 10 |
Precision | {S11, S12, S15, S16, S25, S29, S31, S34, S36} | 9 |
Recall | {S1, S11, S12, S15, S16, S25, S29, S31, S34, S36} | 10 |
MRR | {S10, S20, S22, S23, S30, S33} | 6 |
AUC | {S11, S16, S17, S18, S25} | 5 |
未知 | {S5, S7} | 2 |
本节我们对调研文献的检测方法的检测效果进行系统性的分析与总结. 我们以研究方法的实验结果的性能评价为依据, 分析文献实验方法的有效性. 我们将实验结果的性能评价指标分为5个度量值. 具体见
评价文献方法有效性的度量
性能评价指标值 | 性能等级 |
0.00−0.20 | 极低的有效性(low) |
0.20−0.40 | 一般的有效性(fair) |
0.40−0.60 | 中等的有效性(moderate) |
0.60−0.80 | 较高的一致性(substantial) |
0.80−1.00 | 高度的一致性(perfect) |
我们依据文献中使用了相同的性能评价指标来比较不同文献提出的方法的有效性. 因为不同的方法采用不同的数据集, 以及数据集规模的大小不同都会造成实验结果的不一致, 我们这里统计的是调研文献中评价指标的数值为其最好情况下的平均值, 忽略不同数据集之间的差异. 这里, 我们仅依据Recall at Top
(1) 基于Recall at Top
为方便统计分析比较不同方法之间的差异, 我们只统计
基于Recall at Top
Recall at Top |
文献编号 | 性能等级 |
0.91 | S2 | 高度的一致性(perfect) |
0.50 | S3 | 中等的有效性(moderate) |
0.70 | S4 | 较高的一致性(substantial) |
0.57 | S6 | 中等的有效性(moderate) |
0.82 | S8 | 高度的一致性(perfect) |
0.63 | S9 | 较高的一致性(substantial) |
0.64 | S10 | 较高的一致性(substantial) |
0.91 | S13 | 高度的一致性(perfect) |
0.85 | S20 | 高度的一致性(perfect) |
0.40 | S21 | 中等的有效性(moderate) |
0.54 | S22 | 中等的有效性(moderate) |
0.28 | S23 | 一般的有效性(fair) |
0.85 | S26 | 高度的一致性(perfect) |
0.92 | S27 | 高度的一致性(perfect) |
0.38 | S28 | 一般的有效性(fair) |
0.92 | S30 | 高度的一致性(perfect) |
0.62 | S32 | 较高的一致性(substantial) |
0.81 | S33 | 高度的一致性(perfect) |
(2) 基于Accuracy调研文献方法性能等级情况
基于Accuracy评价指标调研文献方法性能等级情况见
基于Accuracy评价文献方法性能等级表
Accuracy评价指标值 | 文献编号 | 性能等级 |
0.96 | S11 | 高度的一致性(perfect) |
0.97 | S12 | 高度的一致性(perfect) |
0.93 | S14 | 高度的一致性(perfect) |
0.61 | S15 | 较高的一致性(substantial) |
0.84 | S17 | 高度的一致性(perfect) |
0.95 | S18 | 高度的一致性(perfect) |
0.91 | S19 | 高度的一致性(perfect) |
0.94 | S29 | 高度的一致性(perfect) |
0.89 | S35 | 高度的一致性(perfect) |
0.97 | S36 | 高度的一致性(perfect) |
(3) 基于Recall调研文献方法性能等级情况
基于Recall评价指标调研文献方法性能等级情况见
基于Recall评价文献方法性能等级表
Recall评价指标值 | 文献编号 | 性能等级 |
0.62 | S1 | 较高的一致性(substantial) |
0.94 | S11 | 高度的一致性(perfect) |
0.96 | S12 | 高度的一致性(perfect) |
0.43 | S15 | 中等的有效性(moderate) |
0.99 | S16 | 高度的一致性(perfect) |
0.74 | S25 | 较高的一致性(substantial) |
0.83 | S29 | 高度的一致性(perfect) |
0.96 | S31 | 高度的一致性(perfect) |
0.723 | S34 | 较高的一致性(substantial) |
0.97 | S36 | 高度的一致性(perfect) |
在分析总结文献的不同方法对于重复软件缺陷报告的检测效果的过程中, 我们发现, 基于卷积神经网络的方法相比较传统的NLP的方法和传统的主题模型的方法在效果上更加优越. 然而, 我们在文献的调研过程中发现, 基于深度学习方法检测重复软件缺陷报告的研究相对较少. 这可以是我们今后研究工作的一个方向.
本文对近20年来重复软件缺陷报告检测方法的研究进行了系统性的调研, 经过分析, 发现调研过程存在两方面的不足: (1) 调研文献不够全面; (2) 数据提取可能不够准确.
首先, 为了保证调研文献的系统性, 我们制定了研究的搜索策略, 包括搜索术语、检索来源、搜索过程等一系列过程. 在搜索的过程中, 我们根据收集的搜索术语, 通过人工搜索的方式对文献进行筛选. 因此, 检索关键词可能存在不能覆盖该领域所有相关文献的情况; 另外, 还存在人工操作的不确定性导致相关文献遗漏的情况.
其次, 我们在提取数据的过程中可能存在一些不准确的情况. 根据研究问题的制定, 我们从调研文献中提取相关的信息. 在该过程中, 我们几个合著作者一起讨论以确保数据的统一. 但一方面, 可能由于部分信息的缺失导致数据的不完整; 另一方面, 可能由于讨论交流不到位导致数据不够全面. 更具体地表现为: 验证方法没有充分地加以介绍、性能评价的对比没有直观的说明、研究方法的优势没有很好地解释等, 这些因素都可能影响数据提取的准确性.
目前, 针对重复软件缺陷报告检测问题的研究已进行了多年且取得了一定的进展. 但该问题仍然具有一定的研究价值和研究意义: 一方面, 现有研究方法检测重复软件缺陷报告的准确度和可靠性还有待提高, 这也是大多数研究成果未能成功运用到企业软件质量保障流程的原因之一; 另一方面, 随着深度学习的不断发展, 其涌现出的新技术和新思想可以引入到重复缺陷报告检测问题的研究上, 例如, 基于Transformer的双向深度语言模型BERT. 本文通过系统文献调研的方式, 分析了重复软件缺陷报告检测方法的研究进展, 希望为该领域未来的工作提供一些有用的参考. 通过前面的分析与总结, 我们发现了该领域发展过程中面临的一些问题与挑战. 本节从深度学习的研究方法、研究方法的实用性以及数据源的局限性这3个角度来介绍重复软件缺陷报告检测领域研究所面临的问题与挑战, 并提出相关建议.
(1) 深度学习的研究方法
近年来, 由于深度学习技术的快速发展以及它在自然语言处理中的应用, 深度学习技术也逐渐应用到重复软件缺陷报告检测的研究中. Deshmukh等人[
对于未来深度学习在重复软件缺陷报告检测的研究方法, 建议首先对已有工作进行实证研究, 验证在开源和工业项目中的有效性. 在实际应用中验证方法的价值, 同时也能够发现需要改进的地方, 以提出新的研究方法. 其次, 把深度学习技术与现有其他技术进行融合, 譬如: 深度学习技术优化自然语言处理的文本分类方法结合主题模型进行建模, 也可能是一个值得研究的方向. 另一方面, 深度学习的方法需要大量的训练数据支撑对模型进行训练, 在语料库充足并且融合了多种数据来源时, 其检测效果和普适性要优于其他模型, 其优势是可以更加准确地表示文本语义关系, 对于文本的结构和顺序可以更加准确地表达. 就未来的重复软件缺陷报告检测方法的研究, 能否结合小样本学习的方法通过少量的样本对深度学习相关模型进行训练, 以达到目前深度学习方法应用的检测效果, 是一个值得探讨和研究的话题, 这将可以对于前期数据的准备和模型的训练工作节约大量的时间成本.
对于深度学习模型在深度方面的研究, 在调研文献中涉及使用到的单通道卷积神经网络和双通道卷积神经网络模型展现的结果显示, 层数结构越深、越复杂的模型在文本表示的表达上就会拥有更好的效果. 后续工作可以尝试对深度学习模型的深度进行多层深度学习模型在重复软件缺陷报告检测问题上的探索, 这一方面仍然有很大的实验空间.
(2) 研究方法的实用性
重复软件缺陷报告检测的工作已研究多年, 已有工作提出了许多技术来解决它. 然而, 很少有研究成果应用到工程实践中. 大部分研究先提出自己的研究方法, 并在数据集上进行性能评估以证明该方法比已有方法性能更好, 但没有落实到实际开发环境中. Sun等人[
在实际开发环境中, 缺陷跟踪系统中多数数据集来自开源软件项目Eclipse, 根据前面的数据提取分析也表明, 已有研究使用最多的数据集是Eclipse. 研究人员选择不同的数据集进行性能评估结果也不同. Ebrahimi等人[
另一方面, 通过比较缺陷跟踪系统中所有现有的软件缺陷报告来确定新的软件缺陷报告是否重复需要花费很长时间. 使用启发式或元启发式的方法缩小搜索空间, 这对于实时应用和连续查询任务的应用尤其重要.
在提出研究方法的同时, 考虑把研究方法应用到实际开发环境中, 譬如把研究方法作为一个工具以便研究人员使用. 其次, 进行实证研究, 关注研究方法最适用的应用场景, 使研究方法发挥更大的价值.
目前, 主流的缺陷追踪系统(例如Bugzilla)已增加了重复软件缺陷报告检测的功能. 在用户创建新的软件缺陷报告时, 会根据Summary字段中的信息实时地显示系统推荐的重复软件缺陷报告列表, 以避免用户提交重复软件缺陷报告. 但该功能与用户预期仍有一定的距离, 例如近5年来, Bugzilla中的Eclipse项目平均每年仍然会出现2 311个重复软件缺陷报告.
(3) 数据源的局限性
准确的实验数据集是保证重复软件缺陷报告检测方法质量的重要依据. 在第3.1节通过分析调研文献的数据集来源与规模, 我们发现: 已有研究使用的数据集仅限于一定时间段内的软件缺陷报告, 在这个时间段外的软件缺陷报告将被忽略. 如果被测试的软件缺陷报告存在该时间段外的重复软件缺陷报告, 则不能被检测到. 此外, 大多数研究方法使用的不同数据集之间的实验彼此独立, 并不能完全认为这些方法是普遍适用的. 研究人员应尽量将不同来源的数据集组合在一起进行实验, 以形成更大的数据集集合, 增强方法对不同数据集之间的普遍适用性. 在进行数据预处理工作时, 寻找合适的停止词列表是其中关键的工作内容之一, 以此确保相似性计算的准确性, 保持软件缺陷报告的语义[
研究人员可以使用不同开源项目的公开数据集, 其次关注数据集的质量, 选取合适的实验数据集. 此外, 选取的数据集的时间周期应当尽可能地长, 尽可能地扩大单个开源项目数据集的范围, 降低数据集对性能评估准确性的影响. 正如Rakha等人[
(4) 特征字段的选取
在第3.2节的研究总结中, 我们已经知道了特征字段的选取对于重复软件缺陷报告的检测工作存在一定精度的影响. 缺陷跟踪系统中, 软件缺陷报告的质量并不能得到有效的保证, 缺陷跟踪系统中存在大量的字段不完整、关键特征字段缺失的软件缺陷报告. 在第3.2节的研究总结中我们已经提到: 在不同时间内, 软件缺陷报告的字段值可能有所变化. 因此, 选取的软件缺陷报告数据集是最初提交的软件缺陷报告还是在其生命周期内字段值进行过更改的软件缺陷报告, 这对于重复软件缺陷报告检测结果也会存在一定的影响. 因此, 在检测方法中设置相关缺失字段的检测是否对检测性能会有一定的影响, 都是值得探讨的问题. 对于字段的选取, 较好的做法是将描述文本和元数据字段结合起来对相似度进行加权, 得到最终的相似性分数. 描述文本标题和描述字段是研究人员普遍都会考虑的特征字段. 对于元数据的选取, 则没有一个统一的标准, 元数据字段对于重复软件缺陷报告检测工作的性能提升有多大作用? 哪些元数据字段的检测可以明显改善重复软件缺陷报告检测方法的精度? 都是未来值得我们进一步研究的课题.
本文以文献调研的形式分析了近20年的重复软件缺陷报告检测的研究进展, 从研究方法、数据集和性能评价这3个方面提取数据分析重复软件缺陷报告的研究现状. 其次, 从深度学习的研究方法、研究方法的实用性、数据源的局限性以及特征字段的选取这4个角度, 总结了当前重复软件缺陷报告检测领域研究的问题和挑战, 并提出建议. 虽然重复软件缺陷报告检测的已有研究工作已经积累了较多的研究成果, 但仍存在一些问题与挑战, 这也成为该领域未来的研究方向.
Moran K, Linares-Vásquez M, Bernal-Cárdenas C, Poshyvanyk D. FUSION: A tool for facilitating and augmenting android bug reporting. In: Proc. of the 38th Int'l Conf. on Software Engineering Companion (ICSE 2016). New York: Association for Computing Machinery, 2016. 609-612.
IEEE Standard Classification for Software Anomalies. IEEE Std 1044-2009 (Revision of IEEE Std 1044-1993), 2010. 1-23.
Serrano N, Ciordia I. Bugzilla, ITracker, and other bug trackers. IEEE Software, 2005, 22(2): 11-13.
Wang S, Chen TH, Hassan AE. How do users revise answers on technical Q & A Websites? A case study on stack overflow. IEEE Trans. on Software Engineering, 2020, 46(9): 1024-1038.
Shah M, Pujara N. A review on software defects prediction methods. CoRR abs/2011.00998, 2020.
Bettenburg N, Premraj R, Zimmermann T, Kim SH. Duplicate bug reports considered harmful … really? In: Proc. of the 2008 IEEE Int'l Conf. on Software Maintenance. Beijing, 2008. 337-345.
Fan Y, Xia X, Lo D, Hassan AE. Chaff from the wheat: Characterizing and determining valid bug reports. IEEE Trans. on Software Engineering, 2020, 46(5): 495-525.
Zhang J, Wang X, Hao D,
Kitchenham BA, Charters S. Guidelines for performing systematic literature reviews in software engineering. EBSE Technical Report, EBSE-2007-01. ICSE IEEE Computer Society, 2007. 1051-1052.
Su E, Joshi S. Leveraging product relationships to generate candidate bugs for duplicate bug prediction. In: Proc. of the 40th Int'l Conf. on Software Engineering: Companion Proc. (ICSE 2018). New York: Association for Computing Machinery, 2018. 210-211.
Lin MJ, Yang CZ, Lee CY, Chen CC. Enhancements for duplication detection in bug reports with manifold correlation features. The Journal of Systems & Software, 2016, 121.
Budhiraja A, Reddy R, Shrivastava M. LWE: LDA refined word embeddings for duplicate bug report detection. In: Proc. of the 40th Int'l Conf. on Software Engineering: Companion Proc. (ICSE 2018). New York: Association for Computing Machinery, 2018. 165-166.
Budhiraja A, Dutta K, Reddy R, Shrivastava M. DWEN: Deep word embedding network for duplicate bug report detection in software repositories. In: Proc. of the 40th Int'l Conf. on Software Engineering: Companion Proc. (ICSE 2018). New York: Association for Computing Machinery, 2018. 193-194.
Song YK, Wang XY, Xie T, Zhang L, Mei H. JDF: Detecting duplicate bug reports in Jazz. In: Proc. of the 32nd ACM/IEEE Int'l Conf. on Software Engineering (ICSE 2010). Vol. 2. New York: Association for Computing Machinery, 2010. 315-316.
Sun CN, Lo D, Wang XY, Jiang J, Khoo SC. A discriminative model approach for accurate duplicate bug report retrieval. In: Proc. of the 32nd ACM/IEEE Int'l Conf. on Software Engineering (ICSE 2010). Vol. 1. New York: Association for Computing Machinery, 2010. 45-54.
Thung F, Kochhar PC, Lo D. DupFinder: Integrated tool support for duplicate bug report detection. In: Proc. of the 29th ACM/IEEE Int'l Conf. on Automated Software Engineering (ASE 2014). New York: Association for Computing Machinery, 2014. 871-874.
Nguyen AT, Nguyen TT, Nguyen TN, Lo D, Sun CN. Duplicate bug report detection with a combination of information retrieval and topic modeling. In: Proc. of the 27th IEEE/ACM Int'l Conf. on Automated Software Engineering (ASE 2012). New York: Association for Computing Machinery, 2012. 70-79.
Sun CN, Lo D, Khoo SC, Jiang J. Towards more accurate retrieval of duplicate bug reports. In: Proc. of the 2011 26th IEEE/ACM Int'l Conf. on Automated Software Engineering (ASE 2011). Lawrence, 2011. 253-262.
Chaparro O, Florez JM, Singh U, Marcus A. Reformulating queries for duplicate bug report detection. In: Proc. of the 2019 IEEE 26th Int'l Conf. on Software Analysis, Evolution and Reengineering (SANER). Hangzhou, 2019. 218-229.
He JJ, Xu L, Yan M, Xia X, Lei Y. Duplicate bug report detection using dual-channel convolutional neural networks. In: Proc. of the 28th Int'l Conf. on Program Comprehension (ICPC 2020). New York: Association for Computing Machinery, 2020. 117-127.
Neysiani BS, Babamir SM, Aritsugi M. Efficient feature extraction model for validation performance improvement of duplicate bug report detection in software bug triage systems. Information and Software Technology, 2020, 126.
Ebrahimi N, Trabelsi A, Islam MS, Hamou-Lhadj A, Khanmohammadi K. An HMM-based approach for automatic detection and classification of duplicate bug reports. Information and Software Technology, 2019.
Aggarwal K, Rutgers T, Timbers F, Hindle A, Greiner R, Stroulia E. Detecting duplicate bug reports with software engineering domain knowledge. In: Proc. of the 2015 IEEE 22nd Int'l Conf. on Software Analysis, Evolution, and Reengineering (SANER). Montreal, 2015. 211-220.
Huang S, Chen L, Hui Z, Liu J, Yang S, Chen Q. A method of bug report quality detection based on vector space model. In: Proc. of the 2019 IEEE 19th Int'l Conf. on Software Quality, Reliability and Security Companion (QRS-C). Sofia, 2019. 510-511.
Lazar A, Ritchey S, Sharif B. Improving the accuracy of duplicate bug report detection using textual similarity measures. In: Proc. of the 11th Working Conf. on Mining Software Repositories (MSR 2014). New York: Association for Computing Machinery, 2014. 308-311.
Alipour A, Hindle A, Stroulia E. A contextual approach towards more accurate duplicate bug report detection. In: Proc. of the 10th Working Conf. on Mining Software Repositories (MSR). San Francisco, 2013. 183-192.
Klein N, Corley CS, Kraft NA. New features for duplicate bug detection. In: Proc. of the 11th Working Conf. on Mining Software Repositories (MSR 2014). New York: Association for Computing Machinery, 2014. 324-327.
Xie Q, Wen Z, Zhu J, Gao C, Zheng Z. Detecting duplicate bug reports with convolutional neural networks. In: Proc. of the 2018 25th Asia-Pacific Software Engineering Conf. (APSEC). Nara, 2018. 416-425.
Sabor KK, Hamou-Lhadj A, Larsson A. DURFEX: A feature extraction technique for efficient detection of duplicate bug reports. In: Proc. of the 2017 IEEE Int'l Conf. on Software Quality, Reliability and Security (QRS). Prague, 2017. 240-250.
Sureka A, Jalote P. Detecting duplicate bug report using character
Yang X, Lo D, Xia X, Bao L, Sun J. Combining word embedding with information retrieval to recommend similar bug reports. In: Proc. of the 2016 IEEE 27th Int'l Symp. on Software Reliability Engineering (ISSRE). Ottawa, 2016. 127-137.
Hu D,
Deshmukh J, Annervaz KM, Podder S, Sengupta S, Dubash N. Towards accurate duplicate bug retrieval using deep learning techniques. In: Proc. of the 2017 IEEE Int'l Conf. on Software Maintenance and Evolution (ICSME). Shanghai, 2017. 115-124.
Banerjee S, Syed Z, Helmick J, Culp M, Ryan K, Cukic B. Automated triaging of very large bug repositories. Information and Software Technology, 2017: 89.
doi: 10.1109/ISSRE.2013.6698920]]]>
Wang XY, Zhang L, Xie T, Anvik J, Sun JS. An approach to detecting duplicate bug reports using natural language and execution information. In: Proc. of the 30th Int'l Conf. on Software engineering (ICSE 2008). New York: Association for Computing Machinery, 2008. 461-470.
Runeson P, Alexandersson M, Nyholm O. Detection of duplicate defect reports using natural language processing. In: Proc. of the 29th Int'l Conf. on Software Engineering (ICSE 2007). Minneapolis, 2007. 499-510.
Xiao G, Du X, Sui Y, Yue T. HINDBR: Heterogeneous information network based duplicate bug report prediction. In: Proc. of the 2020 IEEE 31st Int'l Symp. on Software Reliability Engineering (ISSRE). Coimbra, 2020. 195-206.
Wang JJ, Li MY, Wang S, Menzies T, Wang Q. Images don't lie: Duplicate crowdtesting reports detection with screenshot information. Information and Software Technology, 2019, 110.
Dang Y, Wu R, Zhang H, Zhang D, Nobel P. ReBucket: A method for clustering duplicate crash reports based on call stack similarity. In: Proc. of the 2012 34th Int'l Conf. on Software Engineering (ICSE). Zurich, 2012. 1084-1093.
Rakha MS, Bezemer C, Hassan AE. Revisiting the performance evaluation of automated approaches for the retrieval of duplicate issue reports. IEEE Trans. on Software Engineering, 2018, 44(12): 1245-1268.
Lerch J, Mezini M. Finding duplicates of your yet unwritten bug report. In: Proc. of the 2013 17th European Conf. on Software Maintenance and Reengineering. Genova 2013. 69-78.
Gopalan RP, Krishna A. Duplicate bug report detection using clustering. In: Proc. of the 2014 23rd Australian Software Engineering Conf. Milsons Point, 2014. 104-109.
C. Jingliang, M. Zhe, S. Jun. A data-driven approach based on LDA for identifying duplicate bug report. In: Proc. of the 2016 IEEE 8th Int'l Conf. on Intelligent Systems (IS). Sofia, 2016. 686-691.
Akilan T, Shah D, Patel N, Mehta R. Fast detection of duplicate bug reports using LDA-based topic modeling and classification. In: Proc. of the 2020 IEEE Int'l Conf. on Systems, Man, and Cybernetics (SMC). Toronto, 2020. 1622-1629.
Lazar A, Ritchey S, Sharif B. Generating duplicate bug datasets. In: Proc. of the 11th Working Conf. on Mining Software Repositories (MSR 2014). New York: Association for Computing Machinery, 2014. 392-395.
Mikolov T,
Hiew L. Assisted detection of duplicate bug reports[MS. Thesis]. British Columbia: Department of Computer Science, the University of British Columbia, 2003.
Li YR, Gopalan RP. Clustering high dimensional sparse transactional data with constraints. In: Proc. of the 2006 IEEE Int'l Conf. on Granular Computing. Atlanta, 2006. 692-695.
Tu FF, Zhu JX, Zheng QM, Zhou MH. Be careful of when: an empirical study on time-related misuse of issue tracking data. In: Proc. of the 2018 26th ACM Joint Meeting on European Software Engineering Conf. and Symp. on the Foundations of Software Engineering (ESEC/FSE 2018). New York: Association for Computing Machinery, 2018. 307-318.