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

开源软件项目很难集中管理。对于存在缺陷的开源软件项目,人们倾向于使用自动化或半自动的工具来管理和维护整个系统,例如使用缺陷跟踪系统来报告、记录、管理和跟踪软件缺陷。随着软件项目的不断扩展,缺陷报告的数量也在不断增加。截至2014年12月,Eclipse开源社区有超过40万个缺陷报告,Mozilla开源社区有超过19万个缺陷报告。由于这些缺陷报告包含了大量的知识,分析和挖掘缺陷报告可以更好地帮助开发人员管理和理解缺陷,从而提高生产效率。但与此同时,提交给缺陷跟踪系统的大量缺陷报告也给缺陷分布带来了压力。例如,在2005年,Eclipse社区每天都会收到大约200个缺陷报告,如此多的缺陷报告增加了开发人员分发和处理这些报告的负担。在Mozilla社区中,管理人员平均每天需要为300个缺陷报告找到合适的开发人员。
典型的软件缺陷报告通常包括许多字段,如状态、摘要、描述、报告者、修复者、建立时间、修改时间、优先级、严重性、操作系统、缺陷版本、平台和注释列表。其中“摘要”和“描述”字段用自然语言描述,如缺陷是如何被发现的、缺陷抛出的异常、缺陷重现的步骤等。“修复者”字段指示当前缺陷报告的修复者;“严重性”和“优先级”从两个不同的方面解释了缺陷报告的重要性。“严重程度”主要由缺陷报告的提交者根据缺陷对软件系统的危害性来决定。“优先级”主要由修复缺陷的开发人员根据当前的工作量和缺陷的严重程度来决定。研究表明,高质量的缺陷报告可以帮助开发人员更好地修复缺陷。
此外,缺陷报告具有各种状态,如“新的”、“已解决”、“已修复”、“已关闭”、“无效”、“重复”、“已重新打开”等。这些状态构成了缺陷报告的生命周期。当提交缺陷报告时,其状态为“未确认”,这要求开发人员验证报告是否包含真实缺陷。如果报告中描述的缺陷不是真正的缺陷,则报告的状态变为“已解决”和“无效”;如果此缺陷报告与之前提交的缺陷报告之间存在重复关系,其状态将变为“已解决”和“重复”。如果不满足上述两个条件,可以确认缺陷报告中包含真实缺陷,报告状态将变为“新”。之后,系统人员将此缺陷分配给合适的开发人员,报告的状态将变为“已分配”。开发人员修复缺陷后,会将缺陷的状态更改为“已解决”和“已修复”。然后,其他开发人员评估缺陷并审查代码。如果缺陷被验证成功修复,缺陷报告的状态将变为“已验证”。最后,缺陷报告状态为“关闭”。有时,缺陷会在未来的某个时间重新出现,缺陷报告的状态会变为“重新打开”。项目经理需要重新分配缺陷,然后开发人员可以修复缺陷。
围绕缺陷报告的生命周期有几个研究点:当缺陷报告的状态从“新”变为“已分配”时,需要推荐合适的开发人员,并预测缺陷的严重程度和优先级。由于一个开源软件有成千上万的开发人员,及时将缺陷报告分发给合适的修复人员可以缩短缺陷修复的时间。此外,为了提高开发人员的工作效率,预测缺陷的严重性和优先级可以使开发人员更合理地安排工作,提高工作效率。
缺陷报告的状态由“已分配”变为“已解决”,需要:判断缺陷报告是否为重复缺陷报告;识别缺陷的类型;预测整个缺陷修复过程所需的时间;找到与此缺陷相关的源代码。此外,当缺陷报告的状态从“已解决”变为“已关闭”时,需要判断缺陷是否会“重新打开”。

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


文章图片

1.维修人员推荐的缺陷报告

推荐阅读