软件缺陷报告严重性属性分析

软件缺陷报告的严重性对缺陷的解决具有关键作用。随着软件规模的不断扩大,使用开源的软件缺陷跟踪系统成为海量缺陷信息数据的主要处理方法。分析缺陷报告严重性在数据仓库中的作用,是处理软件缺陷的重要内容。通过对Bugzilla缺陷跟踪系统数据的研究和分析,发现不同项目的属性特征差异较大,同时在修复率、解决时长、开发者、组件等属性上的统计特征具有一致性。对Mozilla项目和Eclipse项目的数据进行系统分析,并根据不同组件和项目中严重性程度分布情况,认为软件缺陷报告严重性程度的提升会导致缺陷修复率的提高,同时严重性程度为normal级别的缺陷解决时长最短,开发者持有缺陷的数量越高其修复率越低。     

面向软件安全性缺陷的开发者推荐方法

软件开发与维护过程中常会出现一些安全性缺陷,这些安全性缺陷会给软件和用户带来很大的风险.安全性缺陷在修复过程中,其修复级别和质量要求往往高于一般性的缺陷,因此,推荐出富有安全性经验的开发者及时有效地修复这些安全性缺陷非常重要.现有的开发者推荐技术在推荐开发者时仅仅考虑了开发者的历史开发内容,很少考虑到开发人员的安全性缺陷修复经验和修复质量等因素,所以这些技术不适用于安全性缺陷的开发者推荐.本文针对安全性缺陷的修复提出了一种有效的软件开发者推荐方法SecDR.SecDR在推荐开发者时不仅考虑了开发者的历史开发内容（与安全性相关）,还分析了开发者的修复质量和历史修复缺陷的复杂度等因素.此外,SecDR还实现了开发者的多经验级别推荐：推荐初级开发者修复简单的安全性缺陷,高级开发者修复复杂的安全性缺陷.本文在三个开源项目（Mozilla,Libgdx,ElasticSearch）上分别对SecDR推荐开发者进行有效性验证.通过对比实验证明,SecDR针对安全性缺陷推荐开发者相比于其他方法（如：DR_PSF）的推荐精度平均高出19%~42%.另外,实验对比了SecDR与实际开发人员的分配情况,结果显示SecDR可以更好地规避不合理的软件开发者的推荐.     

OSDR:一种开源软件的缺陷修复人推荐方法

对于大型开源软件项目来说,用户提交了海量缺陷报告,人工分发缺陷时会出现大量的错误分配。提出OSDR(Open Software Developer Recommendation)方法通过计算新缺陷报告和历史缺陷报告之间的文本相似度,基于K最近邻算法得到相似度最高的K个历史缺陷报告及其对应的修复人列表,再基于频率和社交网络图的各项指标对开发者专业能力进行评价。从Mozilla Firefox缺陷库中采集真实实验数据,比较不同社交网络指标在推荐修复人时的准确率与召回率。结果表明,推荐性能最高的指标是频率和出度,其准确率大约在0.6左右;Betweenness和Closeness的推荐效果最差;度、入度以及PageRank推荐效果良好。     

深度学习在缺陷修复者推荐中的应用

目前许多软件项目使用缺陷追踪系统来自动化管理用户或者开发人员提交的缺陷报告。随着缺陷报告和开发人员数量的增长,如何快速将缺陷报告分配给合适的缺陷修复者正在成为缺陷快速解决的一个重要问题。分别使用长短期记忆模型和卷积神经网络两种深度学习方法来构建缺陷修复者推荐模型。该模型能够有效地学习缺陷报告的特征,并且根据该特征推荐合适的修复者。通过与传统机器学习方法(如贝叶斯方法和支持向量机方法)进行对比,该方法可以比较有效地在众多开发者中找出合适的缺陷修复者。     

Mozilla项目缺陷修复追踪关系研究

软件可追踪性为软件工程的很多活动提供了非常重要的支持,如变更影响分析、回归测试、版本控制以及一致性检验等。在开源软件项目中,缺陷数据和版本数据之间的缺陷修复关联是一种重要的软件追踪关系。研究开源软件项目缺陷和版本两种制品间的缺陷修复关联,选取大型开源项目Mozilla作为研究对象,在深入了解所获得数据的整体分布情况后,针对Mozilla项目的产品Firefox浏览器,利用Fellegi-Sunter模型挖掘缺陷数据与commit数据之间的缺陷修复关联并建立二者之间的追踪关系,最后对挖掘出的缺陷修复追踪关系进行结果分析。该项工作为开源项目制品间追踪关系的研究提供了经验参考。     

基于循环神经网络的缺陷报告分派方法

随着开源软件项目规模的不断增大,人工为缺陷报告分派合适的开发人员（缺陷分派）变得越来越困难.而不合适的缺陷分派往往会严重影响缺陷修复的效率,为此迫切需要一种缺陷分派辅助技术帮助项目管理者更好地完成缺陷分派任务.当前,大部分研究工作都基于缺陷报告文本以及相关元数据信息分析来刻画开发者的特征,忽略了对开发者活跃度的考虑,使得对具有相似特征的开发者进行缺陷报告分派预测时表现较差.本文提出了一个基于循环神经网络的深度学习模型DeepTriage,一方面利用双向循环网络加池化方法提取缺陷报告的文本特征,一方面利用单向循环网络提取特定时刻的开发者活跃度特征,并融合两者,利用已修复的缺陷报告进行监督学习.在Eclipse等四个不同的开源项目数据集上的实验结果表明,DeepTriage较同类工作在缺陷分派预测准确率上有显著提升.     

方法级别的细粒度软件缺陷定位方法

当软件缺陷报告在跟踪系统中被指派给开发人员进行缺陷修复之后,缺陷修复人员就需要根据提交的缺陷报告来进行软件缺陷定位,并做出相应的代码变更,以修复该软件缺陷.在缺陷修复的整个过程中,软件缺陷定位占用了开发人员大量的时间.提出了一种方法级别的细粒度软件缺陷定位方法MethodLocator,以提高软件修复人员的工作效率.MethodLocator首先对缺陷报告和源代码方法体利用词向量（word2vec）和TF-IDF结合的方法进行向量表示;然后,根据源代码文件中方法体之间的相似度对方法体进行扩充;最后,通过对扩充后的方法体和缺陷报告计算其余弦距离并排序,来定位为修复软件缺陷所需做出变更的方法.在4个开源软件项目ArgoUML、Ant、Maven和Kylin上的实验结果表明,MethodLocator方法优于现有的缺陷定位方法,它能够有效地将软件缺陷定位到源代码的方法级别上.     

基于缺陷报告分析的软件缺陷定位方法

在软件开发过程中,软件缺陷是不可避免的。在缺陷跟踪系统中,一个重要的问题是如何根据用户所提交的缺陷报告,进行缺陷的自动定位。本文在综合考虑缺陷报告与源代码文件结构相似性的基础上,进一步分析已修复缺陷报告、缺陷报告中的异常堆栈(StackTrace)信息对软件缺陷定位的作用,从而提高定位的精度。在Eclipse、AspectJ和SWT开源项目数据程序集上进行相关实验,并与Buglocator、BRTracer和BLUiR缺陷定位方法进行了比较分析,实验结果表明,本文方法能显著提高软件缺陷定位的精度。     

面向用户的软件缺陷报告特征重要度分析

缺陷的及时反馈与修复是开源软件长久健康发展的基本保障, 面对每天提交的大量、包含多方面因素的开源软件缺陷报告, 很多缺陷报告因为描述遗漏或不准确, 而影响缺陷有效判定和缺陷修复进程; 而面对需要填报的复杂缺陷报告信息, 报告提交者也无法确定哪些属性是关键的、哪些需要重点描述致使提交缺陷报告质量不高. 综合文献对缺陷报告描述的5个维度28种特征进行分析, 按照维度间和维度内多特征两个角度对缺陷报告特征进行重要度排序对比, 结果显示按照维度分析: 文本特征和报告者经验特征两个维度的F1值和准确率指标最高, 而每个维度内特征也显示了不同重要度, 从而可以指导缺陷提交者规范缺陷报告提交, 也可以指导修复者进行缺陷判定和缺陷修复.     

重复软件缺陷报告检测方法综述

软件缺陷在软件的开发和维护过程中是不可避免的,软件缺陷报告是软件维护过程中重要的缺陷描述文档,高质量的软件缺陷报告可以有效提高软件缺陷修复的效率.然而,由于存在许多开发人员、测试人员和用户与缺陷跟踪系统交互并提交软件缺陷报告,同一个软件缺陷可能被不同的人员报告,导致了大量重复的软件缺陷报告.重复的软件缺陷报告势必加重人工检测重复缺陷报告的工作量,并造成人力物力的浪费,降低了软件缺陷修复的效率.以系统文献调研的方式,对近年来国内外学者在重复软件缺陷报告检测领域的研究工作进行了系统的分析.主要从研究方法、数据集的选取、性能评价等方面具体分析总结,并提出该领域在后续研究中存在的问题、挑战以及建议.     

Experience report: investigating bug fixes in machine learning frameworks/libraries

Machine learning (ML) techniques and algorithms have been successfully and widely used in various areas including software engineering tasks. Like other software projects, bugs are also common in ML projects and libraries. In order to more deeply understand the features related to bug fixing in ML projects, we conduct an empirical study with 939 bugs from five ML projects by manually examining the bug categories, fixing patterns, fixing scale, fixing duration, and types of maintenance. The results show that (1) there are commonly seven types of bugs in ML programs; (2) twelve fixing patterns are typically used to fix the bugs in ML programs; (3) 68.80% of the patches belong to micro-scale-fix and small-scale-fix; (4) 66.77% of the bugs in ML programs can be fixed within one month; (5) 45.90% of the bug fixes belong to corrective activity from the perspective of software maintenance. Moreover, we perform a questionnaire survey and send them to developers or users of ML projects to validate the results in our empirical study. The results of our empirical study are basically consistent with the feedback from developers. The findings from the empirical study provide useful guidance and insights for developers and users to effectively detect and fix bugs in MLprojects.     

基于高斯过程的缺陷定位方法

在软件系统中,缺陷定位是缺陷修复的一个关键环节,如果能将缺陷自动定位到很小的范围,将会极大地降低缺陷修复的难度.基于高斯过程提出了一种缺陷定位方法（GPBL）,即针对每个缺陷,向开发人员推荐这个缺陷可能存在于哪些源文件中,从而帮助开发人员快速修复缺陷.为了验证方法的有效性,采集了开源软件Eclipse 和Argouml 中的数据,实验结果表明,高斯过程缺陷定位的查全率和查准率平均分别为87.16%和78.90%.与基于LDA的缺陷定位方法进行比较,表明高斯过程更能准确定位缺陷的位置.     

BUTTER：一种基于主题模型和异构网络的缺陷分发方法

当软件缺陷被提交到缺陷跟踪系统并经过确认之后,它会被分发给开发人员进行缺陷修复．这个过程就叫做缺陷分发．随着被提交到系统的缺陷报告日益增多,手工分发缺陷报告会变得越来越困难．提出了一种自动分发缺陷的方法BUTTER．与其他方法不同的是,BUTTER不仅利用主题模型分析缺陷报告中的文本信息,而且创新性地建立了一个包含提交者、缺陷和开发者三种节点及其相互关系的异构网络,从该异构网络中抽取了更多的结构信息．实验证明,BUTTER进行自动缺陷分发较其他缺陷自动分发方法要好．     

Multi‐level reranking approach for bug localization

Bug fixing has a key role in software quality evaluation. Bug fixing starts with the bug localization step, in which developers use textual bug information to find location of source codes which have the bug. Bug localization is a tedious and time consuming process. Information retrieval requires understanding the programme's goal, coding structure, programming logic and the relevant attributes of bug. Information retrieval (IR) based bug localization is a retrieval task, where bug reports and source files represent the queries and documents, respectively. In this paper, we propose BugCatcher, a newly developed bug localization method based on multi‐level re‐ranking IR technique. We evaluate BugCatcher on three open source projects with approximately 3400 bugs. Our experiments show that multi‐level reranking approach to bug localization is promising. Retrieval performance and accuracy of BugCatcher are better than current bug localization tools, and BugCatcher has the best Top N, Mean Average Precision (MAP) and Mean Reciprocal Rank (MRR) values for all datasets.     

Understanding the triaging and fixing processes of long lived bugs

ContextBug fixing is an integral part of software development and maintenance. A large number of bugs often indicate poor software quality, since buggy behavior not only causes failures that may be costly but also has a detrimental effect on the user’s overall experience with the software product. The impact of long lived bugs can be even more critical since experiencing the same bug version after version can be particularly frustrating for user. While there are many studies that investigate factors affecting bug fixing time for entire bug repositories, to the best of our knowledge, none of these studies investigates the extent and reasons of long lived bugs.ObjectiveIn this paper, we investigate the triaging and fixing processes of long lived bugs so that we can identify the reasons for delay and improve the overall bug fixing process.MethodologyWe mine the bug repositories of popular open source projects, and analyze long lived bugs from five different perspectives: their proportion, severity, assignment, reasons, as well as the nature of fixes.ResultsOur study on seven open-source projects shows that there are a considerable number of long lived bugs in each system and over 90% of them adversely affect the user’s experience. The reasons for these long lived bugs are diverse including long assignment time, not understanding their importance in advance, etc. However, many bug-fixes were delayed without any specific reasons. Furthermore, 40% of long lived bugs need only small fixes.ConclusionOur overall results suggest that a significant number of long lived bugs may be minimized through careful triaging and prioritization if developers could predict their severity, change effort, and change impact in advance. We believe our results will help both developers and researchers better to understand factors behind delays, improve the overall bug fixing process, and investigate analytical approaches for prioritizing bugs based on bug severity as well as expected bug fixing effort.     

开源软件缺陷报告自动摘要研究综述

在开源软件开发的维护阶段, 开源软件缺陷报告为开发人员解决缺陷提供了大量帮助。然而, 开源软件缺陷报告通常是以用户对话的形式编写, 一个软件缺陷报告可能含有数十条评论和上千个句子, 导致开发人员难以阅读或理解软件缺陷报告。为了缓解这个问题, 人们提出了开源软件缺陷报告自动摘要, 缺陷报告自动摘要可以减少开发人员阅读冗长缺陷报告的时间。本文以综述的方式对开源软件缺陷报告自动摘要的研究做了系统的归纳总结。首先, 根据摘要的表现形式, 将开源软件缺陷报告摘要分类为固定缺陷报告摘要和可视化缺陷报告摘要, 再将固定缺陷报告摘要研究方法分类为基于监督学习方法和基于无监督学习方法, 之后总结了基于监督学习和无监督学习的开源软件缺陷报告摘要生成的工作框架, 并介绍了开源软件缺陷报告摘要领域常用数据集、预处理技术和摘要评估指标。其次, 本文以无监督学习为切入点, 分类阐述和归纳了无监督开源软件缺陷报告摘要方法, 将无监督开源软件缺陷报告摘要方法分类为: 基于特征评分方法、基于深度学习方法、基于图方法和基于启发式方法, 并对每类方法进行讨论与分析。再次, 从缺陷报告摘要的实用性出发, 对现有的缺陷报告可视化摘要研究成果进行总结,并对固定缺陷报告摘要和可视化缺陷报告摘要的实用性做出分析。最后, 对现有研究成果及综述进行讨论和分析, 指出了开源软件缺陷报告摘要领域在缺陷报告数据集、抽取式摘要和黄金标准摘要三个方面面临的挑战和对未来研究的展望。     

知识驱动的相似缺陷报告推荐方法

软件缺陷在软件开发过程中不可避免,提交的缺陷报告则是分析和修复缺陷的重要信息来源。开发人员常通过借鉴相似的历史缺陷报告和修复信息来辅助对当前新缺陷的分析和修复。文中提出了一种知识驱动的相似缺陷报告推荐方法。该方法首先利用信息检索和Word Embedding技术构建缺陷知识图谱;然后利用TF-IDF和Word Embedding技术计算缺陷报告之间的文本相似度,同时综合考虑缺陷的各项属性,从而得到缺陷报告之间的主次要属性相似度;最后将上述相似度融合成综合相似度,利用综合相似度推荐相似缺陷报告。实验结果表明,与基线方法相比,在Firefox数据集上所提方法的性能平均提高了12.7%。