缺陷追踪是软件项目管理的一个重要环节,是保证现代大规模开源软件开发顺利进行并持续提高软件质量的必要手段.目前,大部分开源软件都使用开放的缺陷跟踪系统进行软件缺陷的管理.它允许用户向开发者提交系统故障(即defect类型缺陷)以及系统改进建议(即enhancement类型缺陷),但是这些用户的反馈所起的作用尚未得到充分研究.针对这一问题,对Firefox的缺陷跟踪系统进行实证研究,收集了2018年和2019年提交的19 474份Firefox Desktop以及3 057份Firefox for Android缺陷报告.在此基础上,对比分析了普通用户和核心开发者提交的缺陷在数量、严重性、组件分布、修复率、修复速度以及修复者上的差别,并调查了缺陷报告的撰写质量与缺陷处理结果和修复时间的关系.主要发现包括:(1)当前缺陷追踪系统中普通用户人数众多,但参与程度较浅,86%的用户只提交过一个缺陷,其中,高严重等级的缺陷不超过3%;(2)普通用户提交的缺陷主要分布在和用户交互相关的UI组件上(例如地址栏、音频/视频等),然而还有43%的缺陷由于缺乏充分描述信息而难以准确地定位到具体的关联组件;(3)在缺陷处理结果上,由于查重系统以及缺陷填报系统在设计上过于简单,致使普通用户提交的大量缺陷被处理为“无用”缺陷,缺陷修复率低于10%;(4)在缺陷修复流程上,由于普通用户难以准确、充分地描述缺陷,导致系统对其重视程度不足,普通用户提交缺陷的处理流程也比核心开发者提交的复杂,平均需要多花至少8天的时间进行修复.上述研究结果揭示了当前缺陷追踪系统在用户参与激励机制、缺陷自动查重以及缺陷报告填写智能辅助等方面的不足,能够为缺陷跟踪系统开发者和管理者改进系统、提高普通用户对开源软件的贡献提供参考.
Bug tracking systems are a vital part of software project management. It is a necessary means to ensure the smooth development of modern large-scale open source software and continuously improve software quality. Most open source software ecosystems currently use open bug tracking systems to manage software bugs. It allows users to submit system failures (called defect bugs) and suggestions for system improvements (called enhancement bugs), but the role of feedback from these users has not been fully studied. Therefore, this work conducted an empirical study on the bug tracking system used by Firefox, and collected 19 474 and 3 057 bug reports submitted in 2018 and 2019 for Firefox Desktop and Firefox for Android, respectively. Based on this, it is compared and analyzed the differences between the number, severity, distribution on components, fixing rate, fixing efficiency and assignees of bugs submitted by ordinary users and core developers, and at the same time, the relationship between the quality of bug reports and the fixing rate and efficiency of bugs is investigated. The main findings are as follows. (1) There are a large number of ordinary users, but their participation is still superficial. 86% of ordinary users have only submitted one bug and no more than 3% of bugs are of high severity. (2) The bugs submitted by ordinary users mainly distributed on UI components related to user interaction (e.g., address bar, audio/video, etc.), but there are also 43% of bugs that are difficult to accurately locate due to lack of sufficient description information. (3) In terms of bug processing results, due to the simple design of the duplicate checking system and bug filling system, a large number of bugs are treated as "useless" ones, and the fixing rate is less than 10%. (4) In the bug fixing process, due to the difficulty of ordinary users to accurately and fully describe bugs, the system does not pay enough attention to them, thus the process of bugs submitted by ordinary users is more complicated than that of core developers, and it takes at least 8 more days on average to fix them. These results reveal the shortcomings of the current bug tracking system in terms of user participation incentive mechanism, automatic bug duplicate checking, and intelligent assistance in filling out bug reports, which can provide help for the system developers and managers to improve system and enhance the contributions of ordinary users to open source software.
现代软件系统在互联网的相互连接作用下, 正形成一种复杂的大规模软件生态, 群智化、生态化的软件开发方法正逐渐成为当前软件开发的主流选择[
软件缺陷伴随着软件开发, 未被发现的缺陷可能会造成巨大的经济甚至威胁人类生命安全[
目前, 开放性缺陷跟踪系统吸引了大量研究者的关注, 相关研究涵盖对缺陷修复时间影响因素的分析, 以及如何提高缺陷报告质量、如何提高缺陷管理的自动化等方面. 例如, Sasso等人[
虽然针对缺陷跟踪系统的研究众多, 但用户所提交的缺陷能否得到及时而有效的处理、它们对软件产品质量提升能起多大作用等问题尚未得到系统性地定量分析. 也就是开源软件的缺陷跟踪系统的“群智化”程度尚不清楚. 基于直接的观察, 张伟等人[
具体地, 本文从缺陷的数量、严重程度、组件分布、修复率、修复速度以及修复者等各方面对比分析两类不同缺陷报告者, 即普通用户和核心开发者所提交的缺陷, 评估他们在缺陷系统中的作用和地位. 这里, 普通用户指的是在缺陷管理系统中没有特权的用户, 他们只能进行缺陷的提交和评论, 通常为软件产品的使用者; 而核心开发者除了能够进行缺陷的提交和评论外, 还能进行缺陷确认或者编辑, 他们通常为开源组织的核心人员. 在本文中, 在不引起歧义的情况下, 普通用户也简称为用户. 本文的研究问题如下.
● RQ1: 普通用户与核心开发者在参与人数、提交缺陷个数以及提交缺陷的严重等级方面是否存在明显区别?
除了服务核心开发者之外, 开放缺陷追踪系统的一个重要特点是其能允许数量众多的软件产品使用者来参与软件缺陷的发现及报告活动, 普通用户人数越多, 提交的缺陷数量越多, 表明他们参与的积极性越高. 因此, 我们的第1个研究问题(RQ1)关注普通用户和核心开发者在缺陷修复活动中的参与情况, 其中, 参与人数能反映当前缺陷追踪系统是否能有效吸引不同的参与者, 提交缺陷个数能反映不同参与者在缺陷提交上的贡献情况, 而提交缺陷的严重等级能反映不同参与者参与程度的深浅(用户参与程度越深, 那么发现严重程度高的软件缺陷的概率就越大).
● RQ2: 普通用户与核心开发者提交的缺陷分别集中在哪些组件上? 这些组件在分布上是否存在明显区别?
每个软件产品通常都由若干个组件(或者模块)构成, 每个组件完成一定的功能, 但它们的地位和作用不完全相同, 出错的概率也不同. 在第2个研究问题(RQ2)中, 我们将缺陷按照与其关联的组件进行分类, 调查哪些组件更容易出错. 同时, 进一步分析普通用户和核心开发者所提交的缺陷在组件分布上的差异, 以了解不同参与者对提高软件产品不同组件质量的贡献.
● RQ3: 普通用户与核心开发者提交的缺陷, 在缺陷处理结果上是否存在明显区别?
修复缺陷报告中提及的缺陷是缺陷追踪系统运行的重要目的, 不同参与者提交的缺陷报告往往会具有不同的缺陷处理结果. 目前, 大多数缺陷跟踪系统如Bugzilla, JIRA都包含了多种缺陷处理方案, 如FIXED(已修复的)、INVALID(无效的)、DUPLICATE(重复的)等, 其中, 只有FIXED类型的缺陷才涉及源代码的修改, 对软件质量提升有帮助, 其他类型的缺陷可认为是“无用”的. 因此, 我们的第3个研究问题(RQ3)关注不同参与者提交的缺陷在最终缺陷处理结果上的差异, 该研究问题还有助于了解不同参与者提交的缺陷对软件质量的最终提升能起多大作用.
● RQ4: 在缺陷报告上, 哪些因素会对缺陷处理结果产生影响?
在对缺陷处理结果进行分析的基础上(RQ3), 还有必要对造成该结果的相关因素进行分析, 从而为缺陷跟踪系统的改进提供参考. 因此, 我们的第4个研究问题(RQ4)将进一步分析缺陷报告中哪些因素可能会对缺陷处理结果产生影响. 具体地, 我们将从缺陷标题(对缺陷的简要概括)、缺陷描述(包括发生问题的软件产品版本、复现步骤、预期结果以及实际结果)以及缺陷报告携带的附件这3个方面对普通用户提交的缺陷报告进行分析, 识别出影响缺陷处理结果的因素, 以帮助普通用户提高缺陷报告的撰写质量.
● RQ5: 普通用户与核心开发者提交的缺陷, 在缺陷处理的优先级以及缺陷修复时间上是否存在明显区别?
缺陷追踪系统中通常存在大量待处理的缺陷, 限于资源约束, 其中必有一部分缺陷得不到及时处理, 这会导致不同缺陷具有不同的缺陷修复时间. 因此, 我们的第5个研究问题(RQ5)主要关注不同参与者提交的缺陷在修复速度上的差异, 包括系统是否会优先处理核心开发者提交的缺陷以及普通用户提交的缺陷是否需要更多的时间才能得到修复这两个方面.
● RQ6: 普通用户与核心开发者提交的缺陷, 在缺陷修复者的指定以及缺陷修复流程上是否存在明显差别?
缺陷除了在处理优先级上的差异外, 不同缺陷往往还会被分配给不同的缺陷修复者来处理, 并具有不同的缺陷修复流程. 因此, 我们的第6个研究问题(RQ6)从缺陷修复者和修复流程的角度来对不同参与者提交缺陷的缺陷修复速度进行进一步分析. 其中, 一个缺陷从提交到修复完成需要经历若干个处理环节, 这些环节可能受多种因素如缺陷报告质量、报告者类型、缺陷类型等影响, 并且不同缺陷所经历的处理环节以及每个环节需要的处理时间也都可能不同.
● RQ7: 在缺陷报告上, 哪些因素会对缺陷修复速度产生影响?
在对缺陷修复速度进行分析的基础上(RQ5和RQ6), 我们的最后一个研究问题(RQ7)进一步从缺陷报告入手来对影响缺陷修复速度的相关因素进行分析. 具体地, 我们将从缺陷标题长度、缺陷描述的准确和充分程度以及缺陷报告是否携带附件这3个角度进行分析, 调查缺陷报告的撰写质量与缺陷修复速度之间的关系
为了回答以上问题, 本文选取了Mozilla的两个广泛流行且有代表性的软件产品Firefox Desktop和Firefox for Android进行实证研究. 具体地, 我们首先从缺陷跟踪系统Bugzilla中自动抓取2018年和2019年提交的这两个产品的全部缺陷的基础数据、缺陷处理历史记录、对应的报告人和修复者以及缺陷标题和评论等相关数据, 然后对这些数据进行整理、统计和分析. 另外, 在Bugzilla系统上, 用户既可以报告软件使用过程中出现的问题, 也可以提出软件需要改进的建议, 前者称为defect类型缺陷, 将后者称为enhancement类型缺陷. 与defect类型缺陷相比, enhancement类型缺陷的发现对用户参与程度要求更高. 也就是说, 只有用户充分了解软件产品已有功能或者特性并进行积极思考的条件下, 才能提出更好的改进建议. 本文将这两种缺陷分开讨论, 以考察用户的参与程度以及系统对他们的重视程度.
本文的主要发现总结如下:
(1) 在人员数量上, 普通用户占总人数75%以上. 在缺陷数量上, 普通用户提交的defect类型缺陷平均能达到该类型缺陷总数的44%; 但在enhancement类型缺陷上, 普通用户提交的只占该类型总数的17%. 普通用户提交的两种产品的缺陷的严重性为高等级的都不足3%. 虽然核心开发者提交的Firefox Desktop产品的缺陷的严重性为高等级的也不足5%, 但在他们提交的Firefox for Android产品的defect类型缺陷中, 仍有25%的缺陷严重性为高等级.
(2) 在普通用户提交的缺陷中, 不能准确定位组件的缺陷平均高达43%; 而在所有能够确定关联组件的缺陷中, 地址栏“Address Bar”和音频/视频“Audio/Video”组件上的缺陷分别占据普通用户提交的Firefox Desktop和Firefox for Android产品缺陷的第一位. 与普通用户相比, 核心开发者提交的缺陷除了与用户交互相关的UI组件相关外, 还存在与大量非UI的组件相关的缺陷(例如消息系统(messing system)和度量系统(metric)).
(3) 在已关闭的缺陷中, 普通用户提交的缺陷32%以上为重复的缺陷, 除此之外, 还有大量信息不全以及无效的缺陷, 缺陷总体修复率低于10%; 而核心开发者提交的缺陷50%以上都能得到修复.
(4) 普通用户提交的处理为重复的DUPLICATE缺陷的标题长度要明显短于已修复的FIXED, 在中值上前者比后者少7个字符; 另外, 处理为信息不全的INCOMPLETE的缺陷72%评论信息中出现“需要更多信息”、“缺陷无法复现”等字样, 而处理为FIXED的这一比例也达到23%. 最后, 携带附件的缺陷修复率为11%, 而不携带附件的修复为7%.
(5) 总体上, 普通用户和核心开发者提交的缺陷处于开放状态的为10%−20%, 但普通用户提交的Firefox Desktop产品的enhancement类型缺陷仍有40%左右处于开放状态. 在修复时间上, 普通用户的缺陷修复时间总体上为核心开发者的2−3倍.
(6) 通常, 普通用户提交的缺陷的修复流程比核心开发者提交的复杂. 例如, 前者提交的缺陷平均90%需要先经过系统管理员确认, 而后者需要被确认的不足2%; 此外, 普通用户提交的defect类型缺陷的修复者经验值与核心用户的没有明显差异. 但在enhancement类型缺陷上, 前者的经验值要显著低于后者.
(7) 在普通用户提交的已修复的缺陷中, 缺陷标题长度与缺陷修复时间之间没有直接关系; 而由于缺陷报告提供的信息不全导致出现无法复现的这类缺陷, 其修复时间要比不出现不可复现的多15天; 同时, 在缺陷提交时携带附件有助于提交缺陷修复效率, 在修复时间上较不带附件可以缩短7天.
本文工作的贡献点主要包括两个方面: 第一, 构建了一个详尽的缺陷跟踪系统数据集, 这些数据不仅包括缺陷基本信息, 还有缺陷的处理历史记录、相应的报告者和修复者信息以及缺陷标题和评论信息; 第二, 从缺陷的数量、严重程度、组件分布、修复率、修复速度以及修复者等多个方面, 系统性地研究了不同角色在缺陷追踪系统中的作用和地位. 本文的研究有助于缺陷跟踪系统开发者和管理者者更好地了解当前缺陷跟踪系统面临的问题; 同时, 我们也基于文中的发现给出一些改进建议, 能够为提高实际软件开发质量以及提升普通用户对开源软件的贡献提供参考. 特别地, 为了提高缺陷跟踪系统工作效率, 减轻相关人员工作压力, 需要改善当前系统自动组件定位和查重功能, 其中, 深度学习以及多种技术的组合将会是值得借鉴的方法; 而在提高普通用户提交缺陷报告的质量方面, 缺陷跟踪系统有必要增加缺陷报告的智能填报机制, 以有效地引导用户撰写缺陷报告, 并且允许用户在线编辑缺陷报告以及上传必要的附件信息, 从而提高缺陷修复率和降低缺陷修复时间.
本文第1节介绍缺陷跟踪系统Bugzilla. 第2节给出具体的实验设计. 第3节为实验结果及分析. 第4节分析影响本文结果有效性因素. 第5节介绍相关工作. 最后一节总结本文工作并指出未来的研究方向.
随着日益增多的软件缺陷, 现代软件特别是群智化软件的维护面临着越来越大的挑战. 为了协同合作以及避免重复劳动, 目前大多数开源软件项目都使用缺陷跟踪系统(bug tracking system)来对软件缺陷进行收集、跟踪和处理. 目前流行的缺陷跟踪系统有Bugzilla, JIRA, ITracker, FogBugz等. 另外, 一些项目托管平台, 如Google Code, GitHub以及FreeCode, 也提供了内置的缺陷跟踪系统.
Mozilla的所有项目都使用Bugzilla作为其官方缺陷跟踪系统并对外开放. 目前, Bugzilla已经由Mozilla的工具转化为一个通用型的缺陷跟踪系统[
Mozilla项目缺陷处理流程
一个典型的缺陷处理流程如下.
● 第1步, 用户提交缺陷, 缺陷进入UNCONFIRMED或者NEW状态.
● 第2步, 缺陷分配者为缺陷指定一位修复者, 缺陷进入ASSIGNED状态.
● 第3步, 修复者完成缺陷修复或者认为该缺陷不需要被修复, 缺陷进入RESOLVED状态.
● 第4步, 质量保证团队对缺陷处理结果进行验证: 如果验证通过, 则进入VERIFIED状态; 否则, 根据缺陷是否需求被重新确认, 分别进入REOPENED或UNCONFIRMED状态.
在以上6种状态中, RESOLVED和VERIFIED状态被称为关闭状态, 代表缺陷已解决, 在
另外, 根据缺陷性质, Bugzilla将缺陷分成3种类型: defect, enhancement以及task. defect类型缺陷主要是指软件产品功能受损、安全漏洞、崩溃、死机、挂起等问题; enhancement类型缺陷主要指新增功能需求、UI界面及性能的改进等建议; 而task类型缺陷主要指重构、移除、替换以及其他相关工程任务.
本文选取Mozilla两个产品Firefox Desktop以及Firefox for Android作为研究对象. Firefox是由Mozilla基金组织于2002年开发的一个可运行在多操作系统平台(如Windows, Mac OS, Linux)的开源Web浏览器. 目前, 除了桌面浏览器外, Mozilla自2010年起又先后发布多种移动端浏览器, 如“Firefox for Android”“Firefox for iOS”等. 如今, Firefox已被分成10多个模块[
本文选取Firefox Desktop以及Firefox for Android作为研究对象, 主要基于以下3个原因.
● 第一, Mozilla项目使用的缺陷跟踪系统Bugzilla是一个通用型系统, 具有一定的代表性, 众多开源和商业软件如Apache, Linux, Eclipse, NASA以及Facebook都使用它进行缺陷管理.
● 第二, Firefox是一个非常成功的项目, 有着悠久的发展历史, Bugzilla系统中存储了大量有关它的缺陷信息且可公开访问.
● 第三, Firefox Desktop以及Firefox for Android来自不同领域: 一个是桌面应用, 另一个是移动端应用. 这有利于本文结果的推广.
需要说明的是, 在Bugzilla系统中, Firefox桌面版名称直接为Firefox, 本文称其为Firefox Desktop, 以便区别与手机移动端Firefox for Android.
https://github.com/GIST-NJU/BUGS_FIREFOX_2018-2019). 为了能够比较准确地反映缺陷跟踪系统当前最新工作情况, 这里选取的是最近两年即2018年和2019年提交的缺陷; 我们不考虑2020年提交的缺陷, 主要考虑到这些缺陷在系统中存在的时间相对较短, 目前还处于不稳定状态, 对实验结果有效性会造成一定的影响.]]>
下面, 我们对研究问题涉及的数据及其收集方法进行简要介绍.
● 缺陷基本信息
本文涉及的缺陷基本信息有缺陷类型、创建时间、修复完成时间、严重性、所属组件、现有状态以及解决方案等. 在上述有关缺陷的基本信息中, 除缺陷修复完成时间外, 其他信息均可由Bugzilla提供的REST API获取, 结果为JSON格式, 缺陷修复完成时间确定方法稍后再做说明.
缺陷1471532的基本数据
● 缺陷状态转换过程
缺陷状态转换过程描述了缺陷处理过程中所经历的状态, 它可从缺陷处理历史记录中提取. 具体地, 将历史处理记录中的what字段限定为“Status”或者“Resolution”, 即可提取其中的状态转换信息. 而缺陷历史处理记录可根据缺陷id从Mozilla的Bugzilla官网页面爬取.
缺陷1471532的状态转换
有了缺陷状态转换信息就可以来确定缺陷修复完成时间. 通常情况下, 缺陷修复完成时间就是该缺陷的解决方案被修改为FIXED的时间, 但需要注意的是, 在修复过程中, 缺陷可能会被多次修复. 例如, 1471532#的缺陷曾先后两次分别在“2018/6/29”和“2018/7/3”被修复(
需要注意的是, 缺陷基本信息包含了一字段cf_last_resolved, 它仅表示缺陷状态最后一次被修改为RESOLVED的时间, 而不能作为缺陷修复完成的时间, 因为缺陷的解决还涉及解决方案, 只有FIXED类型的解决方案才表示缺陷被修复. 这里以1444845#缺陷为例进行说明. 从
缺陷1444845的状态转换
● 报告者信息
本文涉及报告者的信息包括报告者名称以及报告者权限. 报告者名称用于识别报告者, 从
用户395101的档案
● 修复者信息
本文涉及修复者的信息包括修复者名称以及修复者被指派修复任务的次数. 修复者名称用于识别修复者, 修复者被指派任务数用来衡量修复者经验值. 与缺陷报告者相同, 本文使用用户id作为缺陷修复者名称以识别缺陷修复者, 它可从缺陷基本信息的assigned_to_detail字段中获得. 另外, 无论是缺陷报告者还是缺陷修复者, 他们都是Bugzilla中已注册的用户, 因此修复者的个人档案也可以通过其id获取, 档案中的Assigned to字段就是该用户被指派修复任务的次数. 例如,
● 标题和评论信息
标题是对提交的缺陷的简要概述, 评论是缺陷报告者和缺陷修复者以及其他参与者在缺陷处理过程中交流产生的信息. 评论信息的第1条是缺陷报告者对缺陷的详细描述, 包括产生缺陷的软件版本、缺陷复现步骤、实际结果以及预期结果等内容.
1427924缺陷标题信息
1427924缺陷评论信息
本节给出RQ1−RQ7在Firefox缺陷跟踪系统上的调查结果以及对结果的分析和讨论.
在收集的19 474份Firefox Desktop缺陷和3 057份Firefox for Android缺陷中, 我们将它们的缺陷报告者按照个人档案中的Permission字段取值分为核心开发者和普通用户两类(划分标准参见第2.2节).
缺陷报告者数量
产品 | 报告者类型 | |
核心开发者 | 普通用户 | |
Firefox Desktop | 766 | 4 633 |
Firefox for Android | 240 | 777 |
从
(1) 缺陷数量
缺陷数量
从
(2) 缺陷严重程度
由
在Mozilla的Bugzilla系统中, defect类型缺陷的严重程度由高到低共分为6个等级: block, critical, major, normal, minor, trivial. 其中, block等级最高, 该等级缺陷会阻碍系统开发和测试; 而trivial等级最低, 该等级缺陷通常是UI展示上的细微问题(如单词拼写错误或者文本未对齐), 基本上不影响软件功能的使用. enhancement类型缺陷的严重程度除了以上6种等级外, 还有enhancement以及N/A (not application)两种, 其中, N/A表示目前已有的严重等级取值不适用, 它是enhancement类型缺陷严重程度的预留值.
在以上8种缺陷等级中, 通常将block, critical和major称为高严重等级, 其他几种称为低严重等级[
缺陷严重性分布
产品名称 | 报告者类型 | 缺陷类型 | 严重程度(%) | |||||||
高严重等级 | 低严重等级 | |||||||||
blocker | critical | major | normal | minor | trivial | enhancement | N/A | |||
Firefox |
普通用户 | defect | 0.20 | 1.30 | 1.32 | 1.25 | 0.38 | − | − | |
enhancement | 0.00 | 0.12 | 0.59 | 1.31 | 1.07 | 0.00 | 0.12 | |||
核心开发者 | defect | 0.61 | 1.96 | 1.51 | 2.46 | 0.22 | − | − | ||
enhancement | 0.00 | 0.11 | 0.29 | 0.55 | 0.13 | 0.07 | 0.18 | |||
Firefox for |
普通用户 | defect | 0.40 | 1.21 | 1.42 | 0.40 | 0.00 | − | − | |
enhancement | 0.00 | 0.72 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | |||
核心开发者 | defect | 0.33 | 1.77 | 0.39 | 0.07 | − | − | |||
enhancement | 0.58 | 0.58 | 1.73 | 0.87 | 0.29 | 0.00 | 0.00 |
从
● 首先, 对于Firefox Desktop, 普通用户和核心开发者提交的两种类型缺陷90%以上都是normal级别(表中加粗表示), 高严重等级的缺陷不超过5%. 这与Firefox Desktop是一个较成熟的软件产品、不易发现高严重缺陷相关. 即使如此, 两种不同类型报告者在高严重等级缺陷人均数量上还是存在一定差距. 例如, 普通用户提交的defect类型的高严重等级缺陷人均0.03个(156/4633), 而核心开发者提交的该类型的高严重等级的缺陷人均0.38个(294/766).
● 其次, 对于相对较新的Firefox for Android产品, 虽然普通用户和核心开发者提交的enhancement类型缺陷95%以上都为低严重等级, 但在defect类型缺陷上, 两者差异明显. 具体而言, 普通用户提交的defect缺陷只有3%左右为高严重等级, 但是核心开发者提交的高达25%, 其中, critical等级占23%.
缺陷提交到系统后, 缺陷分类人员需要为每个缺陷指定一个与其关联的组件, 以方便缺陷定位. 组件的个数及类别与软件产品相关, Mozilla的Bugzilla系统为Firefox Desktop产品定义了包括“about: logins” “Activity Stream: General”, …, “Web Payments UI”等在内的52个组件, 涉及安装、登录、迁移、地址栏、菜单、活动流、书签、分页、搜索、下载、安全、会话恢复以及消息系统等模块; 为Firefox for Android产品定义了包括“Activity Stream”“Add-on Manager”, …, “Web Apps (AWPs)”等在内的39个组件, 涉及安装、登录、插件管理、音频/视频、智能屏、键盘、文本输入、主题、工具栏、搜索、下载以及度量系统等若干模块.某些缺陷由于报告者提供的信息不全无法确定其确定组件, 此时, 组件属性被指定为“Untriaged”; 还有些缺陷由于分类到目前已有的组件都不合适, 此时, 组件属性被指定为“General”.
Firefox Desktop中缺陷数量排名前五的组件
Firefox for Android中缺陷数量排名前五的组件
从
在Firefox for Android产品中(如
进一步观察发现, 与用户交互的UI组件“Audio/Video”缺陷同时排在两类用户提交的Firefox for Android产品缺陷之前, 它是除了“General”和“Testing”之外, Firefox for Android产品缺陷最多的组件. 此外, 与Firefox Desktop相似, 与普通用户相比, 核心用户仍能发现一定比例非UI组件上的缺陷. 例如, “Metric”上的缺陷位列核心开发者提交的Firefox for Android产品缺陷的第5位, 但在普通用户提交的该产品缺陷中只排在第22位.
缺陷跟踪系统的一个重要作用是进行缺陷修复, 但由于多种原因, 如被报告的缺陷已经存在或者报告者给出的信息不充分, 因此并不是每个被报告的缺陷都能得到修复. 本节将分析在已关闭的缺陷中得到修复的缺陷的比例, 即缺陷修复率. 为此, 我们提取缺陷基本信息中的解决方案resolution字段值.
缺陷解决方案
产品 | 报告者类型 | 缺陷类型 | 解决方案(%) | |||
FIXED | DUPLICATE | INCOMPLETE | INVALID | |||
Firefox Desktop | 普通用户 | defect | 30.58 | 22.33 | 18.02 | |
enhancement | 40.39 | 8.04 | 11.57 | |||
核心开发者 | defect | 16.59 | 17.91 | 5.79 | ||
enhancement | 7.15 | 0.55 | 2.60 | |||
Firefox for Android | 普通用户 | defect | 38.10 | 9.11 | 17.72 | |
enhancement | 26.83 | 2.44 | 14.63 | |||
核心开发者 | defect | 19.88 | 33.14 | 4.14 | ||
enhancement | 11.02 | 0.79 | 3.15 | |||
产品 | 报告者类型 | 缺陷类型 | 解决方案(%) | |||
WONTFIX | WORKSFORM | INACTIVE | MOVED | |||
Firefox Desktop | 普通用户 | defect | 3.76 | 16.01 | 0.74 | 0.10 |
enhancement | 24.51 | 5.49 | 0.39 | 0.00 | ||
核心开发者 | defect | 3.79 | 4.36 | 0.17 | 0.03 | |
enhancement | 4.71 | 1.22 | 0.28 | 0.00 | ||
Firefox for Android | 普通用户 | defect | 4.56 | 13.67 | 7.47 | 0.89 |
enhancement | 37.80 | 6.10 | 3.66 | 1.22 | ||
核心开发者 | defect | 4.89 | 7.62 | 0.00 | 0.25 | |
enhancement | 5.91 | 2.76 | 0.39 | 0.79 |
进一步观察还可以发现: 在普通用户发布的缺陷中, DUPLICATE(重复的)缺陷比重很大, 在30%左右; 另外还有大量的INCOMPLETE(信息不全的), WONTFIX(不予修复的)缺陷, 可以最高可达38%.
从RQ3结果可以看出, 在普通用户提交的缺陷中存在大量“无用”缺陷, 如DUPLICATE, INCOMPLETE, WONTFIX等等, 本节将从缺陷报告的标题和描述以及是否携带附件等方面进行分析.
(1) 缺陷标题
RQ3结果表明: 在普通用户提交的缺陷中, 处理为DUPLICATE类型的缺陷占有非常大的比值, 可高达40%, 远高于核心开发者. 经调查, 在Mozilla产品的缺陷跟踪系统中, 用户发现缺陷后, 需要先进行查重, 查重界面如
查重界面
下面我们将对比普通用户提交的处理为重复的DUPLICATE和其他解决方案如FIXED缺陷的标题长度, 以确定重查结果是否与缺陷概述详细程度有关, 结果如
缺陷标题长度对比
由此可以得出: 缺陷标题描写详细程度对普通用户查重结果具有一定影响, 适当增加对缺陷的描述, 有利于提高查重准确率.
(2) 缺陷描述
在普通用户提交的缺陷中, 除了处理为DUPLICATE占有很大比例外, 还有一类INCOMPLETE缺陷也占有相当大的比例, 如在Firefox Desktop产品中, 普通用户提交的defect类型的缺陷中, 处理为INCOMPLETE约22%. 如果减少这种缺陷, 普通用户提交的缺陷修复率将会大大提高.
INCOMPLETE解决方案的缺陷是因为报告者对缺陷的描述不够详细, 导致缺陷修复者无法复现这些缺陷. 因此, 下面我们对缺陷的评论信息进行分析, 查看其是否包含“lack of information from the reporter”, “not reproducible”等关键词, 以确定报告者对缺陷描述的不够充分, 不能复现缺陷. 统计结果如
缺陷不能复现率对比
说明: 经初步调查, 我们从普通用户提交的缺陷评论信息中共选取了25个表达信息不充分导致缺陷不能复现的关键词, 如“not reproducible”“cannot reproduce”“unable to reproduce”“can you reproduce”等. 由于可能还存在其他表达方式, 因此
从
例如,
INVALID缺陷示例
WONTFIX缺陷示例
(3) 附件
在Firefox的缺陷跟踪系统中, 用户在提交缺陷时可以携带附件以辅助缺陷描述. 下面我们将调查携带附件是否有助于提高缺陷修复率, 具体方法为: 我们将普通用户提交的已处理完的缺陷按是否携带附件分成两类, 然后分别统计每类的缺陷修复率, 即处理为FIXED的在总体中占的比例. 统计结果为: 携带附件的缺陷修复率要略高于不带附件的, 两者分别为11%和7%.
Mozilla的Bugzilla系统是个大型开放性缺陷跟踪系统, 每天面对大量提交的缺陷, 必然有一部分缺陷得不到及时处理. 为了了解缺陷是否被处理完, 我们从缺陷的基本信息中提取字段status, 它反映了缺陷目前处于的状态, 其中, 处于UNCONFIRMED, NEW, ASSIGNED以及REOPED状态的缺陷表示该缺陷还未处理完, 它们仍处于开放状态; 而处于RESOLVED和VERIFIED状态的缺陷已处理完, 它们处于关闭状态.
开放缺陷百分比对比
从
接下来, 我们进一步分析普通用户提交的已得到修复的缺陷需要的修复时间与核心开发者的是否有明显区别.
本文将缺陷的修复时间(bug fixing time)定义为
其中,
缺陷修复时间对比
从
进一步地, Mann-Whitney U检验结果(
RQ5结果表明: 普通用户和核心开发者提交的缺陷需要的时间存在一定的差距, 特别是在enhancement类型缺陷上, 两者的差距能够达到10天以上. 那么这两类缺陷的修复者是否也不同? 具体来说, 不同的类型报告者提交的缺陷其修复者的修复经验是否不同? RQ6针对这一问题进行调查, 采用修复者被指派过的修复任务数来衡量修复者的经验值, 即用修复者个人档案中的Assigned to字段来表示修复者的经验.
需要说明的是, 一部分缺陷在指定具体修复者之前就完成了修复(即没经过ASSIGNED状态直接到达RESOLVED状态). 据观察, 这部分缺陷的修复者邮箱为“nobody@mozilla.org”, 用户id为1. 在RQ6问题中, 我们排除这部分缺陷, 也就是只在已修复的缺陷中选取用户id不为1的作为研究对象, 提取其中每条缺陷修复者的被指派的任务数, 即Assigned to字段值进行分析. 修复者被指派任务数统计结果如
缺陷修复者对比
进一步从统计意义上确认两类报告者提交的缺陷的修复者被指派的任务数是否存在明显差异. Mann- Whitney U的检验结果为: 对于defect类型缺陷,
上述结果表明: 在enhancement类型缺陷上, 系统更重视核心开发者提交的, 这与第3.5节中结论一致.
接下来对比分析普通用户和核心开发者提交的缺陷处理过程, 找出两者之间的差异.
本文从缺陷历史处理记录中提取已修复缺陷的状态转换信息, 并采用BFG (bug flow graphs)方法进行可视化[
在
defect类型缺陷修复过程中的状态转换
● 第一, 两种类型报告者提交的缺陷起始状态不同. 具体地, 核心开发者发布的缺陷90%及以上直接从NEW状态开始, 而普通用户发布的缺陷97%以上从UNCONFIRMED状态开始, 这反映了普通用户发布的缺陷在正式处理之前还需要经过系统管理人员的确认(即从UNCONFIRMED状态到NEW状态), 该过程通常需要1−2天时间.
● 第二, 两种类型报告者提交的缺陷状态之间转换的时间不同. 从NEW到ASSIGNED以及ASSIGNED到RESOLVED, 普通用户提交的缺陷比核心开发者的转换时间多1−2天. 而由NEW直接到RESOLVED, 两者之间的时间差增大到5天及以上.
● 第三, 普通用户发布的缺陷多次指定修复者和重新开放的概率均高于核心开发者提交的. 例如, 在Firefox for Android中, 普通用户提交的缺陷进入ASSIGNED状态后, 以7.4%的概率返回到NEW状态等待重新分配修复者; 另外, 缺陷被解决后还有15%的概率被重新开放需要重新修复. 这些结果进一步反映了, 普通用户提交的缺陷报告质量比较低. 这是因为缺陷报告对缺陷描述信息不全或者不够准确不仅会增加缺陷分配和修复的难度, 相应地增加修复的时间, 同时也会增加了错分和解决错误的概率.
在enhancement类型缺陷上, 普通用户提交的该类型缺陷大部分仍需要先经过管理人员的确认, 状态之间的转换时间总体上也大于核心开发者提交的, 缺陷的重开率也要高于后者. 但相比defect类型缺陷, 两种报告者提交的enhancement类型缺陷在状态转换时间上差距更大. 例如, 核心开发者发布的enhancement类型缺陷从ASSIGNED状态到RESOLVED状态需要4天时间, 而普通用户发布的则需要19天, 两者之差达到15天, 这远高于
在本研究问题中, 我们继续从缺陷报告入手来对影响缺陷修复速度的相关因素进行分析. 具体地, 我们将调查缺陷标题长度、缺陷描述的准确性和充分性以及是否携带附件是否会影响普通用户提交的缺陷的修复时间.
(1) 缺陷标题
缺陷修复时间和标题长度之间的关系
(2) 缺陷描述
本文用缺陷评论中是否出现过需要更多信息以及缺陷不能复现等信息来衡量缺陷描述是否准确、充分. 具体地, 我们将缺陷按照评论信息中是否出现过不能复现该缺陷分成两类, 对比两类缺陷的修复时间, 来分析缺陷描述充分性对缺陷修复时间的影响. 结果如
影响缺陷修复时间的因素
(3) 附件
Mozilla缺陷跟踪系统允许用户以附件形式提供更多缺陷相关信息, 我们下面调查缺陷报告中是否携带附件对缺陷修复时间的影响, 结果如
本节围绕提高实际软件开发质量这一目标, 对第3.1−3.7节中的调查结果进行讨论, 分析当前缺陷跟踪系统存在的问题, 并为缺陷跟踪系统开发者和管理者改进系统、提高普通用户贡献度提供进一步的优化方向.
● 第一, 普通用户参与程度较浅.
RQ1中的结果显示(见
● 第二, 缺陷组件定位和自动查重功能有待进一步改进.
RQ2和RQ3结果表明(如
实际上, 目前缺陷自动查重方面的相关研究非常多, 这些研究也取得了很好的效果. 例如, Sun等人[
然而在Mozilla的Bugzilla系统中, 目前普通用户提交的缺陷仍存在30%左右的重复率. 是这些技术难以应用到实践中、还是Bugzilla不愿意采用这些技术? 或者已采用了这些技术但效果并未达到研究论文中汇报的水平? 这些问题及其背后的原因都是缺陷追踪系统领域值得进一步探索的研究方向. 如果能够有效降低缺陷重复率, 那么系统管理人员可以集中精力处理更多有用缺陷, 这对提高整个系统工作效率具有重要意义.
● 第三, 缺乏缺陷报告填写的智能辅助机制.
缺陷报告是缺陷修复的第一手材料, 它对缺陷修复的重要性不言而喻. RQ2的结果表明(如
缺陷提交表单
为了提高缺陷报告质量, Just等人[
[
另外, RQ4和RQ7的调查结果表明(如
另外, 在普通用户提交的缺陷中, 还有很大一部分处理为INVALID和WONTFIX, 特别是enhancement类型缺陷, WONTFIX可高达38%左右(见
● 第四, 对普通用户提交的enhancement类型缺陷的关注度不够.
enhancement类型缺陷是一种针对软件产品不足而提出的建议, 包括新增功能需求、UI或者性能改进建议以及其他一些产品中面向用户部分的更改或者增强请求, 它在软件产品的演化中起着重要的作用. 例如, 对于Firefox Desktop产品, 核心开发者提交的缺陷中, 35%为enhancement类型缺陷.
除了开发者以外, 用户, 即软件产品的使用者, 他们对产品的改进意见或者需求能否得到满足, 也影响着产品在市场中的竞争力. 最近, Alsubaihin等人[
然而, RQ5及RQ6的结果显示(如
本文对开源软件Firefox缺陷跟踪系统进行了实证研究, 根据收集的缺陷数据, 分析了用户提交的缺陷报告在缺陷跟踪系统中的作用以及系统对它们的处理特点. 然而, 实证性研究通常都存在影响结果有效性的因素, 本文也不例外. 下面我们从数据可靠性、外部有效性和内部有效性这3个方面进行分析.
● 第一, 数据可靠性. 本文研究使用的数据都可从Mozilla的缺陷跟踪系统Bugzilla中获取, 文中第2节详细描述了这些数据的收集方法. 然而如前文所述, 缺陷修复是个长期过程, 即使已经完成修复的缺陷也可能重新开放. 这样, 随着时间的推移, 本文中使用的数据可能会发生变化. 为了尽可能地减少数据变化带来的影响, 文中选用了2018年和2019年提交的缺陷. 截至我们的数据爬取时间, 这些缺陷至少历时半年, 大多数已处于一个较稳定状态, 因此文中的实验结果变化不大.
● 第二, 外部有效性. 本文选取了Mozilla项目的两个软件产品Firefox Desktop和Firefox for Android作为研究对象, 虽然文中的某些结果只对这两个产品有效, 但Firefox以及其缺陷跟踪Bugzilla都具有一定的代表性, 它们也广泛应用于很多软件工程相关问题的研究. 因此, 本文中的某些结果虽然不能完全适用于其他开源软件, 但仍有很好的借鉴作用.
● 第三, 内部有效性. 本文采用用户id来标识用户. 虽然该方法较使用用户名、姓名、昵称等信息识别用户身份更有效, 但根据Zhou等人[
相关研究表明, 软件产品生命周期的70%用于软件维护[
● 第1类, 分析影响缺陷修复效率的因素. 这类工作旨在找出与缺陷修复时间相关的因素, 以提高缺陷修复效率. Saha等人[
● 第2类, 特征化各类缺陷. 这类工作主要通过实证研究分析某一类或者几类缺陷的特征. 例如, Joorabchi等人[
● 第3类, 探索开源项目中的潜在社会结构. 这类工作主要研究参与者个体行为以及个体之间的交互关系. Bissyande等人[
与分析影响缺陷修复效率因素的相关研究不同, 本文还对比分析了普通用户和核心开发者提交的缺陷的修复流程, 找出了两者之间的差异, 并分析原因; 与特征化各类缺陷的相关研究主要关注缺陷本身的特点不同, 本文主要关注缺陷的报告者(即普通普通用户和核心开发者)的参与和影响; 最后, 与第三类已有相关工作研究对象主要为软件产品的开发者不同, 本文的研究对象为缺陷报告者. 总之, 本文首次调查分析了用户提交的缺陷在系统中的地位和作用, 从缺陷的数量、严重性、修复率、处理流程等多个方面对比了普通用户和核心开发者提交的缺陷; 同时, 本文还将defect和enhancement类型缺陷分开讨论, 为学者和开发者进一步改进开源软件缺陷跟踪系统提供帮助.
缺陷管理是软件生命周期中一个重要组成部分. 为了提高缺陷管理的质量和效率, 大型开源软件都采用开放性缺陷跟踪系统进行缺陷管理. 在开放性缺陷跟踪系统中, 任何人都可以进行缺陷的发布、评论甚至修复, 他们通过协同合作共同构造出高质量的复杂软件系统.
本文对开源软件Firefox的缺陷跟踪系统进行了实证研究, 收集了2018年和2019年发布的22 531个Firefox Desktop和Firefox for Android缺陷. 通过对比分析由软件产品使用者构成的普通用户和具有缺陷编辑权限的核心开发者所提交的缺陷在数量、严重程度、组件分布、修复率、修复速度以及修复者等方面的差异, 同时还调查了普通用户提交的缺陷报告质量与缺陷修复率和修复时间之间的关系, 我们发现:
(1) 由于缺乏有效的激励机制, 普通用户无论是在数量上还是严重程度和组件分布上, 都体现出参与程度较浅. 目前, 众多研究者正就这一问题进行积极探索.
(2) 缺陷报告重复性检测性能不理想, 导致重复缺陷报告大量存在, 降低了系统的工作效率. 多种检测性技术的适当组合以及深度学习技术, 是提高缺陷重复性检测率值得借鉴的方法.
(3) 先天性经验不足加上缺乏有效的缺陷报告填写智能辅助机制, 普通用户提交的报告信息不充分, 总体质量不高, 大量组件无法定位, 无用缺陷比例高, 缺陷修复比例低, 修复时间长. 对普通用户辅以智能引导以及允许他们在线编辑缺陷报告, 是提高缺陷报告质量值得尝试的方法. 另外, 本文调查结果显示: 缺陷提交时携带附件, 也是一种有效地提高缺陷修复率和修复速度的方法.
(4) 普通用户提交的软件新功能请求或者改进建议还未受到充分重视, 系统为普通用户和核心开发者两者提交的该类型缺陷指定的修复者具有明显的差异. 建议适当提高普通用户所提交的该类型缺陷在系统中的地位, 这对增加软件产品在市场上的竞争力有一定积极作用.
在下一步工作中, 为了更为全面地了解用户在开源软件的软件维护中的作用, 我们计划将缺陷管理系统与其他类型信息管理系统, 如版本控制系统进行结合, 综合衡量用户在缺陷的发布、缺陷评论以及缺陷修复等全过程中的作用和地位.
Zhang W, Mei H. Software development based on collective intelligence on the Internet: Feasibility, state-of-the-practice, and challenges (in Chinese with English abstract). Scientia Sinica Informationis, 2017, 47(12): 1601-1622. [doi: 10.1360/N112017-00117]
张伟, 梅宏. 基于互联网群体智能的软件开发: 可行性、现状与挑战. 中国科学: 信息科学, 2017, 47(12): 1601-1622. [doi: 10.1360/N112017-00117]
Charette, RN. Why software fails[software failure]. IEEE Spectrum, 2005, 42(9): 42-49. [doi: 10.1109/MSPEC.2005.1502528]
Xuan JF, Jiang H, Zhang HY, Ren ZL. Developer recommendation on bug commenting: A ranking approach for the developer crowd. Science China (Information Sciences), 2017, 60(7): 159-176. [doi: 10.1007/s11432-015-0582-8]
Zhang T, Jiang H, Luo XP, Chan ATS. A literature review of research in bug resolution: Tasks, challenges and future directions. The Computer Journal, 2016, 59(5): 741-773. [doi: 10.1093/comjnl/bxv114]
doi: 10.1145/1117696.1117704]]]>
doi: 10.1109/ICSE.2013.6606645]]]>
doi: 10.1109/QRS.2016.28]]]>
Saha RK, Khurshid S, Perry DE. Understanding the triaging and fixing processes of long lived bugs. Information & Software Technology, 2015, 65: 114-128. [doi: 10.1016/j.infsof.2015.03.002]
Rastkar S, Murphy GC, Murray G. Automatic summarization of bug reports. IEEE Trans. on Software Engineering, 2014, 40(4): 366-380. [doi: 10.1109/TSE.2013.2297712]
doi: 10.1145/1595696.1595715]]]>
Xia X, Lo D, Shihab E, Wang XY, Zhou B. Automatic, high accuracy prediction of reopened bugs. Automated Software Engineering, 2015, 22(1): 75-109. [doi: 10.1007/s10515-014-0162-2]
doi: 10.1109/CSMR.2013.23]]]>
doi: 10.1145/2973839.2973844]]]>
doi: 10.1109/APSECW.2017.10]]]>
doi: 10.1145/1321631.1321639]]]>
doi: 10.1109/ICSM.2011.6080799]]]>
doi: 10.2139/ssrn.1507233]]]>
Catolino G, Palomba F, Zaidman A, Ferrucci F. Not all bugs are the same: Understanding, characterizing, and classifying bug types. Journal of Systems and Software, 2019, 152: 165-181. [doi: 10.1016/j.jss.2019.03.002]
Zhou M, Mockus A. Who will stay in the FLOSS community? Modeling participant's initial behavior. IEEE Trans. on Software Engineering, 2015, 41(1): 82-99. [doi: 10.1109/TSE.2014.2349496]
Mockus A, Fielding RT, Herbsleb JD. Two case studies of open source software development: Apache and Mozilla. ACM Trans. on Software Engineering & Methodology, 2002, 11(3): 309-346. [doi: 10.1145/567793.567795]
doi: 10.1109/WCRE.2012.32]]]>
doi: 10.1109/ASE.2011.6100061]]]>
doi: 10.1109/ICSE.2007.32]]]>
doi: 10.1145/1368088.1368151]]]>
doi: 10.1145/2351676.2351687]]]>
doi: 10.1145/3387904.3389263]]]>
doi: 10.1109/VLHCC.2008.4639063]]]>
Lotufo R. Towards next generation bug tracking systems[Ph. D. Thesis]. Ontario: University of Waterloo, 2013.
Bhatia A, Wang S, Asaduzzaman M, Hassan AE. A study of bug management using the stack exchange question and answering platform. IEEE Trans. on Software Engineering, 2022, 48(2): 502-518. [doi:10.1109/TSE.2020.2994006]
Al-Subaihin AA, Sarro F, Black S, Capra L, Harman M. App store effects on software engineering practices. IEEE Trans. on Software Engineering, 2021, 47(2): 300-319. [doi: 10.1109/TSE.2019.2891715]
doi: 10.1109/RE.2013.6636712]]]>
Boehm BW, Basili VR. Software defect reduction top 10 list. Computer, 2001, 34(1): 135-137. [doi: 10.1109/2.962984]
doi: 10.1145/1806799.1806871]]]>
Liu WJ, Jiang H. Analysis of software bug reports severity feature. Computer Engineering and Applications, 2019, 55(14): 48-53, 208 (in Chinese with English abstract). [doi: 10.3778/j.issn.1002-8331.1810-0360]
刘文杰, 江贺. 软件缺陷报告严重性属性分析. 计算机工程与应用, 2019, 55(14): 48-53, 208. [doi: 10.3778/j.issn.1002-8331. 1810-0360]
doi: 10.1145/1808920.1808933]]]>
doi: 10.1145/2597073.2597098]]]>
doi: 10.1109/ICSE.2012.6227112]]]>
doi: 10.1109/ISSRE.2013.6698918]]]>