开源软件系统缺陷报告如何管理和分析

开源软件项目很难做到集中管理。对有缺陷的开源软件项目，人们往往更倾向于使用自动化或半自动化工具来管理和维护整个系统，如使用缺陷追踪系统（Bugzilla和JIRA）进行软件缺陷的报告、记录、管理及追踪。随着软件项目规模的不断扩大，缺陷报告的数量也在不断增加。截至2014年12月，Eclipse开源社区有超过40万个缺陷报告，Mozilla开源社区有超过19万个缺陷报告。由于这些缺陷报告中包含着大量的知识，对缺陷报告进行分析和挖掘可以更好地帮助开发人员管理和理解缺陷，从而提高生产效率。但与此同时，大量提交到缺陷追踪系统的缺陷报告也给缺陷分配带来了压力。例如，在2005年，Eclipse社区每天收到约200个缺陷报告，如此多的缺陷报告增加了开发人员分配和处理这些报告的负担。在Mozilla社区，管理人员平均每天需要为300份缺陷报告寻找合适的开发人员。

一个典型的软件缺陷报告通常包括很多字段，比如状态（Status）、摘要（Summary）、描述（Description）、报告者（Reporter）、修复者（Assignee）、建立时间（Reported Date）、修改时间（Modified Date）、优先等级（Priority）、严重程度（Severity）、操作系统（OS）、缺陷版本（Version）、平台（Platform）以及评论列表（Comments）等等。其中，“摘要”和“描述”字段是通过自然语言来描述的，比如缺陷是如何发现的、缺陷抛出的异常、缺陷重现的步骤等；“修复者”字段表示当前缺陷报告的修复者；“严重程度”和“优先等级”从两个不同方面解释了一个缺陷报告的重要性，“严重程度”主要由缺陷报告的提交者根据缺陷对软件系统的危害性而决定；“优先等级”主要由修复缺陷的开发人员根据当前工作量以及缺陷严重程度而决定。研究表明，一份高质量的缺陷报告可以帮助开发人员更好地修复缺陷。

此外，缺陷报告还具有多种状态，比如“新的”、“已解决”、“已修复”、“关闭”、“无效”、“重复”、“重新打开”等。这些状态形成了缺陷报告的生命周期当一个缺陷报告被提交时，其状态是“未被确认”，需要开发人员去验证该报告是否包含一个真实的缺陷。如果报告中描述的不是一个真实的缺陷，那么该报告的状态变成“已解决”和“无效”；如果这个缺陷报告与之前提交的缺陷报告存在重复关系，那么其状态就变成“已解决”和“重复”。如果上述两个条件都不满足，那么可以确认这个缺陷报告包含一个真实的缺陷，此时报告的状态会变成“新的”。之后，系统人员将这个缺陷分配给一个合适的开发人员，则报告的状态会变成“已分配”。在该开发人员修复了这个缺陷后，他会将缺陷的状态改成“已解决”和“修复”。然后，另外一些开发人员对这个缺陷进行评估和代码审查，如果这个缺陷被验证是成功修复的，那么这个缺陷报告的状态变成“已验证”。最终，缺陷报告状态为“关闭”。有时，缺陷会在未来的某个时间再次出现，则该缺陷报告的状态会变成“重新打开”。项目管理人员需要对缺陷进行再分配，之后由开发人员对缺陷进行修复。

围绕缺陷报告的生命周期，有以下几个研究点：当缺陷报告的状态从“新的”变成“已分配”时，需要推荐合适的开发人员以及预测缺陷的严重程度和优先等级。由于一个开源软件具有上千名开发人员，因此将缺陷报告及时地分配给合适的修复人员可以缩短缺陷修复时间。此外，为了提高开发人员的工作效率，预测缺陷的严重程度和优先等级可以使开发人员更合理地安排工作，提高工作效率。

缺陷报告的状态从“已分配”到“已解决”，需要做到：（1）判断缺陷报告是否是一个重复的缺陷报告；（2）识别缺陷的类型；（3）预测整个缺陷修复过程需要的时间；（4）定位与这个缺陷相关的源代码。此外，当缺陷报告的状态从“已解决”变成“关闭”时，还需要判别这个缺陷是否会被“重新打开”。

1. 缺陷报告修复者推荐

修复者推荐是指寻找合适的开发人员来修复缺陷，缺陷报告修复者推荐可以减少相关人员的工作量，提高缺陷修复的效率。有人使用了机器学习技术（比如朴素贝叶斯、支持向量机及决策树）进行缺陷报告修复者推荐。该方法首先将缺陷报告的摘要和描述字段提取出来，通过提取词干、去除停用词等自然语言处理方法，将文本转化成词袋形式再采用机器学习相关算法进行修复者推荐。有人提出了一个基于模糊集的算法Bugzie，将每个开发人员最优的描述性词汇进行缓冲，然后用这些词汇来度量开发人员对缺陷报告的适合程度。有人探讨了在Mozilla和Eclipse两个开源社区上的缺陷报告修复者重置现象，通过建立修复者关系重置图，并在图上采用基于马尔科夫链的图模型来提高推荐缺陷报告修复者的准确率。

缺陷报告修复者推荐是缺陷管理与分析自动化的经典研究问题，目前已有大量相对成熟的工作。此类问题的一大难点是如何从大量的开发人员（比如1万名开发人员）中找到与缺陷相关的最合适的修复人员。为此，我们可以结合推荐系统、文本挖掘以及社会化网络挖掘来进一步提高预测准确率。

2. 缺陷严重程度和优先等级的预测

缺陷严重程度和优先等级预测可以帮助开发人员安排工作进度。通常严重程度高的缺陷具有较高的修复优先等级。有人通过分析美国国家航空航天局（National Aeronautics and Space Administration，NASA）相关系统缺陷报告，提出了预测缺陷报告的严重程度问题。在此基础上，有人预测了一个缺陷报告是否严重。有人使用不同的分类算法（包括朴素贝叶斯、多项式朴素贝叶斯、最近邻和支持向量机）预测了缺陷报告严重程度。实验结果表明多项式朴素贝叶斯的效果最好。有人通过整合最近邻搜索和扩展的BM25方法来预测缺陷报告严重程度。

目前缺陷优先等级预测方面的研究并不多。缺陷优先等级与缺陷严重程度有所不同，田（Tian）等人指出：“缺陷严重程度是由缺陷报告的提交者来决定的，而缺陷优先等级是由最终修复这个缺陷的开发人员来决定的”。因此，对于缺陷的优先等级预测需要采取不同的策略。田等人对缺陷报告优先等级进行了多特征的分析，并在此基础上建立了逻辑回归模型，以预测一个新的缺陷报告优先等级。

缺陷严重程度和优先等级预测的困难在于数据集的不平衡性，即只有少量的缺陷报告属于严重等级，这使得预测的准确率很难达到理想值，从而影响实际使用效果。未来解决这个问题的方案可集中在提取表达严重缺陷报告的特征以及研究先进的非平衡的数据处理机器学习的相关算法上。

3. 重复缺陷报告的发现

开源软件项目存有大量的历史缺陷报告，并且用户和开发人员还会不断地提交新的缺陷报告。新提交的缺陷报告很可能与历史缺陷报告重复。开发人员修复这些重复的缺陷报告会造成极大的资源浪费，导致那些真正的缺陷得不到及时修复，因此研究重复缺陷报告的发现具有重要意义。信息检索相关算法可以帮助解决重复缺陷报告发现问题。这类方法的基本思想是给定一个缺陷报告，推荐与它相似度最高的缺陷报告，将其作为可能的重复报告。有人使用向量空间模型对一个缺陷报告进行建模，将其转换成一个文本特征向量，每个文本向量的值是所对应单词的词频·逆向文件频率（Term Frequency-Inverse Document Frequency， TF-IDF）值。有人提出将向量空间模型与自然语言处理技术相结合以提高预测性能。有人利用执行痕迹（execution traces）上的信息来发掘重复的缺陷报告。有人通过将BM25与话题模型相结合来提高重复缺陷报告的发现效率。

机器学习相关算法也可用于解决重复缺陷报告发现问题。有人在缺陷报告的文本特征基础上，使用线性回归方法来形成一个二分类的分类器。有人提出了一个判别式模型，使用支持向量机来识别重复的缺陷报告。有人基于缺陷报告不同字段对重复缺陷报告发现的作用，扩展了BM25算法。目前已有大量关于重复缺陷报告发现方面的工作，该研究方向相对成熟。其中，国际会议ASE2013杰出论文奖提出的算法将话题模型与信息检索模型进行了很好的整合。未来，重复缺陷报告发现的研究需要更多地关注与深度学习技术的结合，从而提出更完善的解决方案。

4. 重新打开缺陷报告的预测

在软件缺陷生命周期中，有时一个“关闭”的缺陷会被“重新打开”。“重新打开”缺陷会造成缺陷修复时间的延长。希哈布（Shihab）等人研究了Eclipse社区缺陷重新打开的现象，提取了四种类型的特征（包括基于缺陷报告的特征、基于开发人员的特征、基于时间的特征和基于缺陷文本的特征），并在此基础上应用机器学习相关算法来预测缺陷是否会被重新打开。考虑到重新打开的缺陷数量比较少（也就是存在着类别不平衡的现象），希哈布等人提出了使用非平衡数据挖掘算法。之后，他们进一步研究了Apache Http和OpenOffice上的缺陷“重新打开”现象。有人将希哈布等人提出的特征与缺陷报告的文本特征相结合，开发了一个预测器ReopenPredictor。有人分析了微软Windows操作系统上的缺陷“重新打开”现象，提出采用逻辑方法来预测一个缺陷是否会被重新打开。这部分缺陷报告的难点在于如何提取出与重新打开缺陷报告相关的特征。当前的研究主要是基于缺陷报告本身的特征挖掘的。未来，重新打开缺陷报告的预测应更多地考虑每个缺陷报告对应的补丁文件以及其他素材，并从中提取出更多的特征，进一步提高预测准确率。

5. 缺陷修复时间预测

缺陷修复时间预测主要是预测给定的缺陷何时会被修复，这有助于项目经理把握项目进度和制定合适的项目计划。有人对ArgoUML和PostgresQL两个项目的缺陷生命周期进行了调研，发现项目缺陷修复时间的中位数为200天。为了有效预测缺陷的修复时间，有人使用了机器学习模型；有人在美国国家航空航天局数据集上使用了人工神经网络；有人将缺陷报告的修复时间分为两类（低和高的修复代价），并依此建立了分类器，该算法的预测准确率为65%；有人提出基于关联规则挖掘的算法；有人学习了缺陷的生命周期，利用k-最近邻（k-Nearest Neighbor，k-NN）算法在JBoss项目上预测缺陷的修复时间。有人使用马尔科夫模型来预测某一时间内缺陷的修复数提出了一个基于蒙特卡罗抽样的缺陷修复时间预测模型。目前缺陷修复时间预测方面的研究工作并不多，主要原因在于很难获取到缺陷修复真正花费的时间。如何自动识别缺陷修复参与者的行为以及这些行为所占据的时间，将是一个值得研究的问题。

6. 缺陷定位

缺陷定位是指对一个缺陷报告相关的源代码位置进行定位。缺陷定位是软件工程中的一个核心问题，准确的缺陷定位工具可极大地节省开发人员调试的时间，进而提高工作效率。当前采用的主要是基于信息检索和机器学习的相关算法。有人提出了PROMESIR算法，该算法通过使用隐语义索（Latent Semantic Indexing，LSI）和基于概率的排序技术对源代码文件进行排序。有人提出使用潜在狄利克雷分配 （Latent Dirichlet Allocation，LDA）算法来进行相关源代码文件的定位。有人使用不同的信息检索技术来验证缺陷定位的效果，发现UM和ⅤSM在iBUgs上的缺陷定位效果最佳。有人提出了BugLocator算法，主要考虑的是基于相似源代码文件的排序和基于相似缺陷报告的排序。有人使用缺陷报告和源代码文件的结构信息来帮助提升缺陷报告定位的性能。有人采用习排序（learning to rank）算法来提升缺陷定位算法的效果。

当前缺陷定位工作的算法准确率还有待进一步提高，而且相关算法只能定位到与缺陷相关的源代码文件层次，属于粗粒度定位，影响了相关算法的工程实用性。未来可以考虑与深度学习相结合，提出更高效的算法。此外，应考虑与程序语言分析和模型检验相关技术相结合，以便使缺陷定位技术可精确到代码片段粒度。

7. 缺陷分类

缺陷分类是指给定一个缺陷报告，自动地将类别甄别出来。通过分析项目中已有的缺陷类型，可以更好地理解和总结项目开发和测试中的问题，并对未来项目具有指导意义。但在实际中，由于开发团队资源有限，项目发布的时间又紧，致使很少有项目组对缺陷进行归纳总结，因此自动化缺陷分类技术就显得十分必要。有人使用机器学习算法将缺陷报告根据其影响进行分类；有人提出了一个基于文本挖掘的算法来识别与安全相关的缺陷报告；有人通过对缺陷报告摘要和描述字段的语言特征来实证缺陷报告与需求之间的不同；有人提出了一个自动化方法识别缺陷报告和需求的问题；有人基于正交缺陷分类（Orthogonal Defect Classification，ODC），定义了基于数据和控制流缺陷、结构缺陷和非功能缺陷类型，通过提取缺陷报告和源代码的特征，对缺陷报告进行自动分类；有人使用集成学习的相关算法，提出了一种自动识别定位的缺陷算法。

由于缺陷报告的分类标准并不统一，因此实际的研究需要更多地与应用场景具体需求相结合。未来的一个发展方向是建立多维度的缺陷分类技术，即给定一个缺陷报告，同时预测它所属的缺陷类别。