文摘
软件缺陷的解决取决于缺陷报告的严重程度。开源软件缺陷跟踪解决方案已经在处理大量的缺陷信息的主要手段的数据由于软件规模持续增加。处理软件故障需要分析缺陷报告的影响严重程度的数据仓库。因此,作者提出了一个优化的系统方法,通过研究和分析Bugzilla缺陷跟踪系统数据在这项研究中,它在哪里发现不同项目的属性特点有很大的不同和修复率的统计特性,解决时间,开发商、组件和其他属性是一致的。这种技术,因此,假定软件缺陷报告的严重程度的上升将导致增加的缺陷修复率和严重程度通常是基于各种组件的严重程度分布和项目。根据研究结果,开发人员持有最缺陷修复率低的时候和缺陷解决时间是最短的。
1。介绍
确保软件质量的主要方法是软件缺陷的严重性分析报告,这也是评估的一个重要信号,排序和分配软件缺陷报告。软件错误与体积和软件开发的复杂性。因此,软件缺陷修正已经成为软件的创建和维护的关键。许多制造商,如Bugzilla JIRA,利用缺陷跟踪系统(比如Bugzilla和JIRA监控和修复软件缺陷的一种快速、准确、有效的方法。与此同时,软件用户和开发人员将利用软件缺陷报告解释软件故障的不同方面(1]。澳大利亚公司,Atlassian JIRA开发工具。用于项目管理以及bug和问题跟踪。Mozilla基金会开发了一个基于web的bug跟踪程序称为Bugzilla。跟踪Mozilla的举措,比如Firefox web浏览器,使用应用程序。缺陷跟踪系统(比如Bugzilla JIRA众多厂商利用快速,准确,有效地监控和修复软件缺陷。软件缺陷的发现是软件用户和开发者广泛使用来描述各部分的软件缺陷在同一时间。唯一的区别可能偏爱Bugzilla JIRA Bugzilla是更可取的小公司,启动预算很低,而JIRA是一个很大的船,满足每一个有用的功能所必需的软件跟踪系统,但它在本质上是复杂的,因此,用于复杂的项目。
错误在系统设置中设置配置错误。不正确的系统状态,如系统故障、性能下降,和其他意想不到的系统行为,经常表现的配置问题。
以下类别可用于组配置挑战应对错误根据他们的特点和缺乏工具支持故障排除和宽容:既复杂系统和配置,使它具有挑战性,保证准确性。日志消息经常丢失,用户缺乏故障排除帮助,传统容错和恢复方法的援助。软件缺陷报告的严重程度可能表明错误的程度影响软件开发和操作(2]。因此,故障的严重程度会直接影响缺陷修复和员工选择的优先级(3]。缺陷作业已成为一个必要的任务软件缺陷修复由于长期数据采集,导致了一个巨大的缺陷报告仓库。缺陷的分数,在调度步骤中,通常是由开发人员完成。固定器,然而,尽管发送缺陷报告软件缺陷的严重性应该用于建立缺陷的优先级,并对软件开发的影响程度和操作应声明(4]。因此,软件缺陷严重程度的预测是一个至关重要的问题在软件缺陷修正5]。
目前,人工方法用于预测软件缺陷的严重程度,还有以下核心问题:(一)数据量问题:有很多缺陷报告提交到缺陷跟踪系统。例如,Mozilla每天收到135缺陷报告(6]。因此,手工处理方法将极大地负担缺陷调度程序和处理人员。(b)精度问题:由于不同的专业水平和经验的缺陷记者,缺陷严重程度显著不同的选择在缺陷报告的提交过程;很多记者报告提交过程中选择默认的严重性。评级,或提交错误的严重性评级,影响缺陷的严重程度的预测报告。
因此,软件缺陷严重程度的预测软件缺陷修正,是一个关键问题,正如上面所讨论的核心问题主要包括数据量问题和精度的问题。因此,由于存在的主要问题,本文全面分析了软件缺陷的严重程度之间的关系报告和报告提交者,解决时间,修复率、组件和产品通过比较缺陷报告数据Bugzilla Mozilla产品和Eclipse的软件缺陷跟踪系统的关系。作为这项研究的结果,可以看出,通过使用机器学习分析数据从软件缺陷报告和评估其严重性,软件缺陷可以分类更准确,可以加速对严重缺陷的修理时间,和他们的修复率可以增加,以确保软件版本迭代的有效性。
2。相关的工作
现有研究中经常使用机器学习方法来预测新的故障报告的严重程度。协助开发人员确定一个特定故障的严重程度,孟席斯和马库斯创造了SEVERIS(问题严重性评估)技术(7]。预见到问题的严重性,SEVERIS开膛手方法使用文本挖掘,结合规则学习算法。这个发现揭示了文本挖掘和机器学习方法用于故障严重程度的预测。作者研究了问题的严重程度是否可以预测的评估缺陷报告使用文本挖掘的文本描述和验证它使用注方法8]。然后,在2011年,他们扩展了以前的工作进行测试,以检查四个机器学习算法的影响,包括NB, MNB,资讯,和SVM预测软件缺陷的严重程度(严重)(9]。调查结果显示,MNB算法优于其他算法的性能和效率。预测的严重性新鲜的缺陷报告,作者运用信息检索方法,特别是BM25-based文本相似度算法和资讯的算法。这种技术优于SEVERIS算法的预测精度作者创建和应用CP,小说文本分类的方法,估计2015年缺陷报告的严重程度(10]。
然后使用数据挖掘方法预测假阳性假阳性率较低。文献提出了一个正式的隐私分析方法基于静态污染分析简化的设计和审查过程高级隐私属性的软件架构11]。文学获得二级数据库访问信息流通过字符串分析数据库,文件名,和会话变量,可以检测出二阶SQLIA和multiorder漏洞该PHP(超文本预处理器)静态分析框架,它可以自动解析动态语言的标准特性,独立定义的价值和堆分析动态语言,并自动将他们找到实际的安全漏洞12]。积极率很低。文献开发了一种高度模块化SCALA-AM静态分析框架,实现了模块化的分离操作语义,可以扩展到支持多种语言,包括许多抽象机,可以实现在不同污染分析按需项目(13]。文学创新增长数据流分析框架为稀疏的形式。他们使用光无关的优化方法来消除污染传播在静态污染分析优化时间和空间开销和没有意识到之间的混叠别名:实质性的更新和准确计算守恒的子域(14]。文献已提出并实现了一个污点分析方法基于离线执行索引的痕迹。以字节为粒度,污染的问题造成的损失由即时翻译执行首次被描述和解决(15]。文学实现了一种新颖的方式准确和可伸缩的静态污染分析,处理污染分析作为一个需求驱动的问题,只有计算脆弱的信息流动,而不是计算完整的数据流解决方案。Requirement-driven弱信息的跟踪和计算流量提高分析的准确性和效率而扩展分析大型代码库(16]。
动态污点分析检测数据是否来自一个不可信的外部输入立即在执行程序时,看到的数据是否可以传播从污染源头污染收敛点通过监测污染的扩散数据在实时系统中程序的项目。文学建立了一个动态完整性污染分析模型为Java,这地址不完美的卫生处理的问题深入的方法,结合预期和回顾措施,这是一个前瞻性的认识卫生处理结果(17]。回顾污染的情况下完全消毒,避免了假阳性的外观,但模型可扩展性需要加强和发展。根据这项研究,作者开发了一种二进制动态污点分析工具,称为剑DTA最大化软件漏洞的检测。这个工具适用于硬件和软件。它发现漏洞通过脆弱性建模越来越难以检查。它有一个良好的效果在缓冲区溢出,整数溢出,除零,UAF(免费)后使用,和其他漏洞。不过,它有一个好的影响不同类型的漏洞(18]。此外,有许多方法可以确保软件质量在软件开发中,如质量管理方法,正式的技术分析,多测试策略,有效的软件工程技术,测量和报告机制。几个例子CloudQA, Akamai CloudTest AppPerfect, CloudSleuth, Nessus,钢丝鲨鱼,等。而且,软件质量保证提供了一些好处和局限性等生成标准的高质量的软件,节省时间和成本,低维护的时间更长,创造和改进过程,并限制包括将多个资源,雇佣更多的员工质量维护等。
曝光暂时无能为力,和路径覆盖率不高。文学提供了一个独立于平台的动态污点分析JavaScript编码污点传播过程抽象机器指令和执行这些指令得到污染流报告对申请人但没有跟踪隐式流;此外,污染传播策略是不够灵活,不支持用户定义的操作。
本文的贡献主要包括以下方面:(1)介绍和分析的统计特征错误报告数据仓库的Bugzilla Mozilla bug跟踪系统项目和Eclipse项目。(2)开发人员修复bug的概率随bug报告的数量增加。(3)通过分析缺陷的严重程度,这两个项目的报道,修复速度,修复时间,维修工,和其他因素,项目之间的相关性的数据。
3所示。Bugzilla的概述,开源Bug跟踪系统
Mozilla公司创建和维护Bugzilla,开源bug跟踪系统。该计划为用户创建一个全面的缺陷跟踪系统通过记录和跟踪软件缺陷,以及提供服务,如缺陷提交,任务,修复、闭包跨整个软件。Bugzilla bug跟踪工具使开发人员能够监测仍未解决的问题在他们的产品。它使用MySQL和perl代码。虽然Bugzilla是记录缺陷的工具,它也可以用来管理测试和因此可能容易与其他测试用例管理集成平台质量中心,等。它使用简单,Bugzilla。标准寻找bug非常有效。它有助于重命名并保存每个错误搜索线程。的用户界面清单问题,尤其是修改列的能力和编辑搜索,非常有帮助。导航到各种Bugzilla的屏幕可以缓慢,用更少的定制选项。此外,Bugzilla的UI和UX似乎过时,需要更新。 Furthermore, there are not many plugins available, which is a problem.
用户的软件缺陷报告有一个完整的生命周期,如图1。当用户确认并提交缺陷报告,该报告状态设置为无证状态(未经证实);当开发人员接受缺陷时,它就变成了认证状态(确认);如果开发人员可以直接解决故障,解决的缺陷报告将改变状态(解决);如果它不能决定,它将进入调度过程,和缺陷状态将调整修复(进展)。修理;修复完成后,确认达到验证状态(验证);当开发人员批准的解决缺陷报告是正确的,该报告状态成为解决,同时关闭和信息;当消息需要重复打开时,报告状态调整重新开放(19]。
在调度过程中,缺陷的严重性属性(严重性)主要用于确定缺陷修复序列和维修人员。假设直接进行数据流分析和简单的每一对源和下沉。在这种情况下,它将浪费计算资源,因为没有可执行路径之间的许多来源和下沉。
根据源和水槽的位置在Web应用程序和跨文件的传播的特点,提出了一种multimatching预处理方法,该方法首先排除了源和汇对之前不能有可执行路径执行复杂的数据流分析。这样可以减少不必要的资源消耗。
多个匹配预处理方法包括四个submethods,给出如下:(一)精确匹配方法(b)确切的请求信息匹配(c)会话信息匹配(d)方法参数匹配
所有这些方法都是独立分类如下:(1)精确匹配方法,相同的方法判断源和水槽是否位于相同的文件;(2)具体要求信息匹配,判断是否源和水槽可以根据get方法返回值的设置方法参数的精确请求信息匹配;(3)会话信息匹配,法官是否可以匹配的源和汇通过会话对象的属性;和(4)方法参数匹配,法官来源是否下沉的方法作为参数传递的方法调用语句。目前,匹配方法可以支持请求的不断传播和会话对象的属性。
此外,对于一对成功匹配的源和汇,如果源不是本地,本地源映射的源与水槽需要检查。
3.1。Mozilla项目缺陷跟踪系统
提交一个缺陷报告时,通常标志着必要的属性。例如,缺陷报告编号35包括地位、作者、时间、缺陷描述、严重级别后提交账户,和详细属性信息中包含的每个部分。报告ID是35,标题是“导航器无法自由退出时偏好哈希表。“报告编写和最后更新3月1日,2018年。MozillaClassic产品的目标信息,以组件是XFE和严重性级别是“小。“根据Bugzilla的解决日志,报告只被分配一次克里斯·迈克菲在1998年和2018年之间,谁修改了账户12月12日,1998年,与“验证”状态(20.]。
3.2。Eclipse项目缺陷跟踪系统
提交一个缺陷报告时,通常标志着必要的属性,例如,Eclipse的缺陷报告信息ID为30。该报告题为“CVS核心服务器。CVS忽略客户机文件应该考虑的。“jean - michel Lemieux撰写的一份报告,去年更新的5月6日,2009年。产品信息的目标是一个平台,组件是一个团队,和严重性是平均水平。根据Bugzilla的修复记录,报告由9人固定在2001年至2009年之间,该报告作者VCm-Inbox分配对象平台,和修复完成于2009年5月6日(21]。
4所示。项目属性对缺陷报告的严重程度的影响
在收集用户报道,Bugzilla缺陷报告处理系统将信息与严重性评级的内容,决定了这个词的处理优先级和影响缺陷处理时间和修复率,和其他特征。缺陷报告的严重程度分为7个水平,从高到低,封锁,关键,专业,标准,次要的,琐碎的,和增强,每一天都是默认级别时,提交缺陷报告。它也是最被用户呈现信息。Mozilla和Eclipse项目的属性分别占了73.92%和67.02%,。软件开发的生命周期不可避免地包括缺陷。没有代码编写有效的第一次尝试。是很重要的,注意,并修复bug,违规行为,和错误。因此,需要大量的测试和优化提供一个强大的软件产品。各种缺陷包括哪些可以篡改程序的功能称为功能性缺陷,或可以扰乱正常工作流程工作流bug,同样,他们可能包括逻辑错误,错误在单元级和系统级集成,等。根据其严重程度水平,可以看到,严重程度较高的缺陷报告有一个更大的对软件功能的影响。因此,开发者将更多关注这些软件的问题,因此,他们的整改速度会增加。 On the other hand, less serious software faults are less likely to be fixed and have little impact on performance.
4.1。Mozilla项目错误报告性质和严重程度的水平
以下4.4.1。关系分析
(1)缺陷严重程度的影响在缺陷修复的速度:缺陷报告的总数平均严重性级别记录在本研究在Mozilla项目是885328,占73%以上的缺陷报告。blocker-level缺陷报告最大的严重程度,另一方面,只有1.14%。表1显示的百分比与严重bug报告的水平。缺陷报告更高的严重程度有更大的影响力的软件功能,可以观察到。结果,开发人员会更加关注此类软件缺陷,及其校正率将会上升。软件缺陷的严重程度,另一方面,对软件性能的影响微乎其微,维修率低。(2)缺陷的严重程度的影响报告缺陷分辨率时间因为这项决议时间是缺陷报告的基本特征之一,国家采取的总时间软件解决错误/错误。因此,这个实验比较和分析不同严重程度的bug报告的平均解决时间在Mozilla项目中,和结果如图所示2与表2。所有缺陷报告的平均解决时间收集在实验中是772天;的决议时间blocker-level缺陷报告严重程度最高的是1083天;的决议时间enhancement-level缺陷严重程度最低的是1240天;缺陷的解决时间与一个普通的程度比平均解决时间短,因为普通的缺陷程度相比,可以快速解决缺陷严重程度越高;和非正态严重缺陷,解决时间比平均解决时间长。可以看出,软件缺陷平均水平严重程度将由开发人员解决;缺陷严重程度较高的水平更有挑战性的解决,导致长时间分辨率;缺陷严重程度较低的水平并没有给予太多的关注很高,导致更长的时间分辨率。(3)开发人员的支持缺陷修复率的影响通过分析Mozilla软件缺陷报告的产品,发现有密切关系的持有人报告(开发人员)和报告的修复率。有8497个开发者在这个项目中,其中3505持有超过5 bug修复。本文将这些开发人员分为6类,5∼10 0∼5日10∼50,50 - 100,100 - 500,500 - 1000年,超过1000的缺陷报告。由于开发商的修复率小于5缺陷修复工作不高,这部分数据没有这个实验相比。这个实验分析了固定利率的bug报告由Mozilla项目开发人员。如图3的表3数量,增加开发人员持有的缺陷报告,报告维修率从77.22%大幅下降到52.40%;解决重复率从5.05%上升到18.31%,而不能繁殖的速度上升,从5.81%上升至18.02%,和变化的属性,如非法的,无法弥补的,和不完整的信息都在10%以内;从的严重程度的角度报道,报道比开发人员持有的关键和重要的水平增加了1.16倍(从11.51%上升到24.91%),修复率不断降低,解决方案重复率和不能复制的速率略有增加,违法行为的属性,不可挽回,与整体曲线和不完整的信息也有所增加。在报告分配过程中,修复率越高,获得报告的概率越高,越高的报告的概率大的困难。因此,开发人员有更多的文字报告较低维修率。(4)缺陷报告的影响严重程度的修复率的软件组件通过分析16个成员国的严重性分布超过10000在Mozilla缺陷报告。发现在每个元素的缺陷报告,缺陷报告的数量和严重程度的标准是通过计算最大的分布的不同组件的Mozilla bug报告。1936个零件Mozilla bug报告。如图4表4,修复缺陷报告的各种特性千差万别。例如,服务器操作组件的维修率最高,达到85.94%;未经训练的元素的修复率是最低的,仅为0.84%。根据严重程度分布的缺陷报告相应的其他成员,严重程度有显著差异水平的各个部分的缺陷报告。主要原因是单词不同严重程度水平的比例在每个元素波动很大。例如,在服务器操作组件,拦截器级别报告占最重要的比例,导致修复率最高;在未经训练的一部分,平均水平报告占重要比例,导致修复率最低。此外,它表明,修复率与严重程度的增加会增加。
4.2。Eclipse项目缺陷报告属性和严重程度关系分析水平
(1)缺陷报告的影响严重程度在Eclipse项目的维修率,正常水平的数量报告违约严重性的缺陷报告报告占总数的67.02%。只有1.54%的blocker-level bug报告严重程度最高的报道。表5显示了缺陷报告的决议有不同程度的水平。拦截器的级别和临界水平缺陷严重程度最高的级别解决95%以上。软件缺陷的病例数不同程度的解决,从定量分布可以看出,事故的严重程度是一个增强固定的bug报告,比例最高的是固定低,约60%;缺陷报告无效的比例最高,达到了18%。可以看出,修复的缺陷报告率较高的严重性比软件产品的质量更小,更重要的影响,和修复率高于更严重的低,但报道修复率较低。(2)缺陷报告严重程度对缺陷分辨力的影响缺陷分辨率时间以来的一个主要缺陷报告的属性;分析解决时间和严重程度之间的关系水平根据Eclipse项目的具体情况。图5表6显示了平均解决时间的分布对应于不同严重程度的缺陷报告Eclipse项目中。总体趋势,事故的严重程度减少,缺陷报告的平均解决时间逐渐增加。例如,拦截器级别最高的严重性报告平均解决时间45天。增强水平最低的严重性表示平均解决时间为441天。可以看出缺陷平均水平严重程度会先解决,从而解决时间较短。另一方面,缺陷与高或低严重影响的困难和解决的重要性,导致了更高的分辨率。(3)开发人员对缺陷修复率的影响二千六百二十四年在Eclipse中开发人员参与缺陷修复在Bugzilla平台上。用户提供不到五缺陷报告是最,约占用户总数的35%。根据开发人员的数量的bug报告,开发人员分为6类。(4)缺陷报告严重程度对软件组件修复率的影响,因为项目组件是一个缺陷报告的基本属性之一,这个实验分析的分布为Eclipse的不同部分产品缺陷报告。组件一个Eclipse项目的总数是782。根据分配的缺陷报告,数据排名前十位的成员数量最重要的缺陷报告选择进行分析。如图6,报告的每个组件缺陷修复率高于80%,TPTP组件的修复率是最高的,达到了99.82%。此外,各种手段优化云服务器在这里详细的规划和战略,评估成本优化,优化现场实例和容器,云自动伸缩,集中管理情况下,切换到新的云部署模型。不要忘记使用云优化工具和服务,预测、建模和分析,以及优化云存储。
通过给予更多的资源比必要的工作负载,许多企业经常体验云中的超支。为你的云基础设施和公司整合云优化策略可以有很多意义,包括以下。
效率在云中:当工作负载,性能,合规,成本不断权衡最佳适合在实时基础设施。利用云优化技术将改善您的云环境的性能通过减少资源浪费的可行性。节约成本:尽管有许多其他类型的云优化,对于许多企业来说,成本优化是最重要的。成本降低的好处降低云浪费。
更大的可视性:分析用于云优化策略来增加您的云环境的可视性。提高生产率:实施云优化计划后,工作人员会花更少的时间试图解决问题,因为一个优化环境停止之前的问题开始。
经常组织创新和效率:实现云优化结果在公司文化转型,导致更好的团队协作和决策。
5。讨论和研究
开发人员的缺陷修复率与不同数量的缺陷数在这项研究中,如图7和表7。缺陷修复率从80.11%有少于五个缺陷49.75%有超过1000的缺陷。此外,该计划的重复率从3.87%上升到18.69%,其nonreproducibility率从2.43%上升到10.18%,和非法的,不可挽回的和不完整的信息增加了10%。上述现象演示了如何开发人员的问题报告将降低利率飙升的修正。
根据缺陷报告的严重程度对应不同的组件,可以看出,在成员中,缺陷报告与严重性级别平均水平占最重要的比例;在测试和性能工具平台(TPTP)组件如Bugzilla介绍了研究一个软件缺陷跟踪工具。TPTP组件用于拦截器级别缺陷报告最高的严重性级别占TPTP组件的最关键的平衡实验的结果分析,证明在图6。因此,把它修复率最高;最低程度增强水平缺陷报告最重要的比例在文本组件,导致修复率最低。可以看出,不同的组件的严重性级别的缺陷报告是一致的。缺陷修复率更高的严重性级别,和元素的缺陷修复率高安全性缺陷也更高。
6。结论
现在广泛的开源项目的维护需要一个准确、全面、有效评估的严重性缺陷报告。软件缺陷报告仓库可能迅速和统一管理使用缺陷报告管理解决方案。作者在本研究系统分析了缺陷报告为Mozilla产品库和Eclipse产品使用Bugzilla缺陷报告管理工具。预计发布一个新版本的产品将导致增加的数量软件缺陷报告;这些报告的严重程度将开发人员的软件缺陷,提高了缺陷修复率和减少所花费的时间修复软件缺陷的发展。用户的修复率是独立的bug报告的数量。上述规则受到各种产品组件的支持。根据上述统计发现,很明显,使用机器学习的方法,如随机森林方法,包装方法,支持向量机方法,贝叶斯分类技术和神经网络技术。评估软件缺陷的严重程度,报告和分类数据可以增加软件缺陷的分类精度,它出现在所有毫升方法,最有效的是随机森林和装袋的方法之一,因此,这些机器学习方法显著减少所需的时间修复严重缺陷,提高缺陷的速度是固定的,所有这些都将确保软件版本迭代的有效性。在未来,将进行更深入的研究来预测缺陷报告跨项目的严重程度。
数据可用性
获得的数据应当可以从相应的作者。
的利益冲突
作者宣称没有利益冲突。