热门标签:代写本科论文 写作发表 工程师论文 代写一篇论文多少钱
当前位置: 代写一篇论文多少钱 > 计算机论文 > 软件缺陷报告严重性相关因素探究

软件缺陷报告严重性相关因素探究

时间:2019-01-24 10:52作者:曼切
本文导读:这是一篇关于软件缺陷报告严重性相关因素探究的文章,使用机器学习的方法对软件缺陷报告的数据进行分析,判断其严重性程度,能够使软件缺陷的归类更准确,有效缩短重要缺陷的修复时间,提高软件缺陷修复率,保障软件版本迭代的效率。

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

  关键词: 计算机应用技术; 开源软件; 缺陷报告; 严重等级; 解决方案; 修复率;

  Abstract: The severity of software bug reporting is critical to the resolution of bugs. With the continuous expansion of software scale, using the open source software bug tracking system becomes the main processing method of mass bug information data. Analyzing the importance of bug reporting in data warehouse is an important part of dealing with software bug. In Bugzilla bug tracking system, the attribute features of different projects are quite different, and the statistical features are consistent in such attributes as repair rate, solution duration, developer, component, etc. The Mozilla project and Eclipse project data are systematically analyzed and distributed according to the severity of different components and projects. It is believed that the increase in the severity of software bug report will lead to the continuous increase in bug repair rate. Meanwhile, the bug with normal severity will be solved for the shortest time, and the higher the number of bugs, the lower the repair rate.

  Keyword: computer application technology; open-source software; bug report; severity; resolution; fix rate;

  1 引言

  软件缺陷报告严重性分析,是保障软件质量的主要方法,是对软件缺陷报告进行分析、排序、分派等工作的重要指标。随着软件开发规模及复杂性的逐渐提高,软件缺陷也随之增多。因此,软件缺陷修复成为软件开发过程以及维护过程中的重要工作。为了能够及时、准确、高效的追踪和修复软件缺陷,很多厂商都使用缺陷追踪系统,实现缺陷报告信息的维护和筛选,如Bugzilla、JIRA等。同时,软件使用者及开发者也会通过软件缺陷报告的形式,描述软件缺陷的各种属性[1]。

  软件缺陷报告的严重性程度,能够反映出缺陷对软件开发及运行的影响程度[2]。所以,缺陷严重性程度的等级划分,会直接影响缺陷修复的优先级及人员的确定[3]。由于长期的数据积累形成了海量缺陷报告仓库,导致缺陷分派成为软件缺陷修复的重要工作。缺陷分派的过程一般由开发者完成,在向修复者分派的同时,要通过软件缺陷报告的严重性程度,来确定缺陷的优先级[2],并表现出缺陷对软件开发及运行的影响程度[4]。所以,软件缺陷报告的严重性预测,是软件缺陷修复的关键问题[5]。

  目前采用人工方式进行软件缺陷严重性程度预测,存在以下几个核心问题:

  (1)报告提交者问题:在软件缺陷报告向缺陷追踪系统提交的过程中,通常会要求报告提供者提交缺陷报告严重性。该项属性要求缺陷报告者具有较强的专业知识,并且对缺陷对应的软件有足够的了解,从而做出缺陷严重性的准确判断。

  (2)数据量问题:通过缺陷追踪系统提交的缺陷报告数量众多,如Mozilla日均收到135个缺陷报告[5],人工处理方法将会给缺陷分派人员及处理人员带来巨大的工作量。

  (3)准确度问题:由于缺陷报告者的专业程度和经验差异,导致在缺陷报告提交过程中,缺陷严重性选择的差异性较大,从而出现很多报告者在报告提交过程中选择默认严重性等级[6,7],或者提交了错误的严重性等级[8],从而影响缺陷报告的严重性预测。

  本文针对以上问题,通过对Bugzilla软件缺陷跟踪系统中Mozilla产品、Eclipse产品缺陷报告数据的对比,全面分析了软件缺陷报告严重性与报告提交者、解决时长、修复率、组件以及产品等数据之间的关系。

软件缺陷报告严重性相关因素探究

  2 相关工作

  已有研究通常使用机器学习算法来预测新的缺陷报告的严重性。Menzies和Marcus等人提出SEVERIS(SEVERity Issue assessment)方法来帮助开发者确定给定缺陷的严重性[9],SEVERIS算法是在文本挖掘的基础上,结合规则学习算法RIPPER来预测缺陷严重性。结果表明文本挖掘和机器学习算法在缺陷严重性预测中是适用的。Lamkanfi等人研究了是否能够通过基于文本挖掘分析缺陷报告的文本描述来预测缺陷严重性[10],并结合NB算法进行验证。随后在2011年,他们又对以上工作就行拓展,通过实验研究了四种机器学习算法预测软件缺陷严重性(严重或者不严重)的效果,包括NB、MNB、KNN、SVM[11],结果表明MNB算法比其他算法有更好的性能和更高的效率。Tian等人利用信息检索技术,特别是基于BM25的文本相似度算法和KNN算法来预测新缺陷报告的严重性[9]。该方法得到了比SEVERIS算法[12]更优的预测效果。2015年,Zhang等人提出了一种新的文本分类技术CP并用于预测缺陷报告严重性[13],实验证明该算法可以有效预测缺陷报告严重性。2016年,Zhang等人又提出了基于改进的REP模型和KNN分类算法寻找最相似缺陷报告方法的预测算法[14],并通过实验严重了算法有效性。

  本文的贡献主要有以下几个方面:

  (1)介绍并分析了Bugzilla缺陷跟踪系统在Mozilla项目和Eclipse项目中的缺陷报告数据仓库统计特性;

  (2)通过对不同软件项目的缺陷报告数据分析,针对严重性程度、修复率、解决时长等属性,进行项目间的差异比较;

  (3)开发者修复缺陷的概率随着其持有过缺陷报告数量的增加而减小;

  (4)通过对两个项目的缺陷报告的严重性程度对修复率、修复时长、修复者等因素的分析,得出项目间数据的关联性。

  3 Bugzilla简介

  Bugzilla是由Mozilla公司开发并维护的开源缺陷跟踪系统。该系统通过对软件缺陷记录和跟踪,为用户建立完善的缺陷跟踪体系,能够提供注册软件全生命周期的缺陷提交、分派、修复、关闭等服务,在软件缺陷管理及分析领域具有重要意义。

  图1 软件缺陷跟踪过程图  
图1 软件缺陷跟踪过程图

  由用户提交的软件缺陷报告具有完整的生命周期[3],如图1所示。当用户确认并提交缺陷报告后,该报告状态被设置为未被认证状态(UNCONFIEMED);当该缺陷通过开发者接受后,则变为已认证状态(CONFIRMED);如果开发者能够直接解决该缺陷,其缺陷报告则被变为已解决状态(RESOLVED);不能解决的则要进入分派过程,同时缺陷状态调整为正在修复(IN_PROCRESS),该过程中缺陷按一定顺序分配给合适的开发者进行缺陷修复;修复完成,并确认后,到达已验证状态(VERIFIED);当缺陷报告的解决方案被开发者确认正确后,该报告状态变为已解决(RESOLVED),同时报告关闭;当报告需要被再次打开时,报告状态则被调整为重新开放(REOPENED)。

  在分派过程中,缺陷的严重性属性(SEVERITY),主要用于确定缺陷修复顺序以及修复人员。该属性的主要参数包括,较高的严重性(如blockers、critical、major,表示该缺陷是较严重的错误);较低的严重性(如normal、minor、trivial,代表比较表面、影响较小的缺陷);需要进行功能改进(enhancement)。

  3.1 Mozilla项目缺陷跟踪系统

  Mozilla由Netscape公司于1998年3月31日对外公布源代码,其衍生产品主要包括Firefox、Thunderbird、SeaMonkey等。

  该项目使用Bugzilla平台对其缺陷报告及处理过程进行系统性跟踪,并建立了完善的报告产生、查询、记录、解决及报表生成流程。截至2017年底,Mozilla的开发人员已经超过4700人,提交的缺陷报告超过110万个。

  缺陷报告提交时一般都会标出必要的属性,例如:编号为35的缺陷报告,其中包括报告提交后的状态、作者、时间、缺陷描述、严重性程度等信息[15],各部分包含的详细属性信息。该报告ID为35,题目为“Navigator does not free preference hash table when exit.”。报告作者为weitsang,最后更新记录是2018年3月1日。报告针对的产品为MozillaClassic,组件为XFE,严重级别为“minor”。根据Bugzilla的修复记录,1998年至2018年间该报告仅发生一次指派,指派对象为Chris McAfee,该指派人于1998年12月12日对该报告进行了修改。状态为“VERIFIED”。

  3.2 Eclipse项目缺陷跟踪系统

  Eclipse是一个开源的基于Java的可扩展开发平台。于1999年4月由OTI和IBM两家公司的IDE产品开发组创建。IBM提供了最初的Eclipse代码基础,包括Platform、JDT 和PDE,2001年11月贡献给开源社区

  截至2017年1月1日,Eclipse托管在Bugzilla缺陷报告仓库的有效缺陷报告,共496821个。

  由于Eclipse的使用者主要是程序开发人员,其上传的软件缺陷报告更具专业性,并具有较高的可参考性和代表性。同时,由于报告者的职业特征,对不同问题的描述的准确性更高。

  缺陷报告提交时一般都会标出必要的属性,例如:编号ID为30的Eclipse的缺陷报告信息[16]。该报告题目为“[CVS Core]server .cvsignore file should be considered by client .”。报告作者为Jean-Michel Lemieux,最后更新记录是2009年5月6日。报告针对的产品为Platform,组件是Team,严重级别为normal。根据Bugzilla的修复记录, 2001年至2009年间该报告由9人进行修复,报告作者指派对象为Platform-VCM-Inbox,并于2009年5月6日完成修复。

  4 缺陷报告仓库统计特性

  在Bugzilla缺陷报告处理系统中,所有报告的处理过程都需要人工干预。所以,缺陷报告的处理时间成为其主要的属性。

  Bugzilla系统的缺陷报告属性中,解决时长是由提交时间和已解决时间决定,该属性主要用来标记软件缺陷解决过程的时长[8]。由于开发者会向缺陷报告的报告者索取其报告信息的详细内容,并确认该报告的各属性。所以,需要对缺陷报告进行类型描述。其中信息不全类型的解决时长最长,可达734天;无法重现类型报告的解决时长,可达343天;不可修复类型报告的解决时长则无法描述;已修复类型报告的解决时长,可达139天;重复类型报告需通过进行确认,其解决时长可达82天;不合法类型报告的解决时长,可达150天[9]。

  4.1 Mozilla产品缺陷报告数据特性分析

  Mozilla项目由Netsape公司于1998年3月开放代码,所以本实验使用的数据是从1999年1月1 日开始,截止到2017年12月31日,以10 天为周期,对新提交的缺陷报告进行分析。缺陷报告提交频率较高的时间为2002年和2010年—2017年,每个周期的缺陷报告提交数量均超过60000个。在此期间,Mozilla产品正处于从Mozilla1.0向Firefox4.0过渡的过程。

  本实验采用的原始数据集,为1999年-2017年Mozilla缺陷报告数据库的全部数据,共有8497名开发者,1192075个缺陷报告。已解决(resolved,closed,verified)的缺陷报告占89.35%,其中已修复的为47.52%,重复的缺陷报告为19.84%;待解决的缺陷报告占10.65%,缺陷报告平均解决时长为772天。其中严重性程度最高的blocker等级缺陷报告修复率最高,严重性程度最低的enhancement等级的缺陷报告修复率最低,数量最多的normal等级缺陷报告的平均解决时长最低。

  根据数据统计结果可知,当Mozilla产品的新版本软件发布时,缺陷报告数量会大幅提高。缺陷报告严重性程度会严重影响缺陷修复率、解决时长,同时会影响各组件及持有者的缺陷修复率和解决时长。所以,缺陷报告的严重性分析,是保证Mozilla产品质量的重要方法。

  4.2 Eclipse产品缺陷报告数据特性分析

  Eclipse由IBM公司开发,于2001年11月开放代码,由Eclipse基金会管理。2007年至2015年经历了9次改版。改版过程中的缺陷报告数量有明显波动。

  从2001年10月10 日开始,截止到2017年1月1日,以10 天为周期,对新提交的缺陷报告进行分析。新提交的缺陷报告最多的时段为2001年10月10日到2001年10月20日,有3983个缺陷报告被提交,此后提交缺陷报告较多的时间段集中在2006年5 月末和6月初,2007年6月上旬,以及2008年5月中旬。

  本实验采用的原始数据集,为2001-年-2017年的所有Eclipse 缺陷报告,涉及到的缺陷报告总数量为496821,参与修复的开发者有3407位。截止到2017年1月1日所有的Eclipse缺陷报告中,已解决(resolved,closed,verified)的缺陷报告占85.72%(425882/496821),待解决的缺陷报告占14.28%。在已解决的缺陷报告中,被修复(fixed) 的占65%,重复的缺陷报告有12.45%。在Eclipse项目缺陷报告数据集中,缺陷报告严重性程度对缺陷修复率、解决时长、持有者以及产品组件等属性的影响,与Mozilla项目缺陷报告数据集的统计特性基本一致,各严重性等级缺陷解决比例的差距不超过0.1%,同样决定了各组件、持有者以及整个数据集的缺陷修复率、解决时长。但在严重性程度最低的enhance- ment等级缺陷中,解决数量有1%左右的提高。

  5 项目属性对缺陷报告严重性的影响

  Bugzilla缺陷报告处理系统在收集用户报告的过程中,会对报告内容进行严重程度分级标记,该标记决定了报告的处理优先级,同时会影响缺陷处理时长以及修复率等特征。缺陷报告严重程度分为7个等级,由高到低分别为blocker、critical、major、normal、minor、trivial、enhancement,其中normal为缺陷报告提交时的默认等级,也是用户提交报告过程中选择最多的属性,在Mozilla项目和Eclipse项目中,分别占比73.92%和67.02%。

  5.1 Mozilla项目缺陷报告属性与严重性等级关系分析

  (1)缺陷报告严重性程度对修复率的影响

  在Mozilla项目中,本文统计的严重性程度为normal等级的缺陷报告总数为885328个,占缺陷报告总数的73%以上。而严重性程度最高的blocker级别缺陷报告仅有1.14%。严重性程度的缺陷报告所占比例如表1所示。

  表1 Mozilla项目中已解决缺陷报告分布情况表
表1 Mozilla项目中已解决缺陷报告分布情况表

  根据不同严重性程度缺陷报告的解决数量综合比较可知,严重性程度最高的blocker等级缺陷报告的修复率最高,为65.76%;严重性程度最低的enhancement级别的重复率和不可修复率最高,分别为34.57%和19.09%。

  由此可见严重性程度较高的缺陷报告,对软件功能的影响较大,开发者更重视这样的软件缺陷,其修复率也会相应提高。相反严重性程度较低的软件缺陷,对软件性能的影响不大,修复率相对较低。

  (2)缺陷报告严重性程度对缺陷解决时长的影响

  图2 不同严重性程度缺陷报告的解决时长图
图2 不同严重性程度缺陷报告的解决时长图

  由于解决时长是缺陷报告的重要特征之一。所以,本实验对Mozilla项目的不同严重程度缺陷报告的平均解决时长进行了对比分析,结果如图2所示。实验中采集的全部缺陷报告的平均解决时长为772天;严重性程度最高的blocker级别缺陷报告的解决时长为1083天;严重性程度最低的enhancement级别缺陷的解决时长为1240天;严重性程度为normal的缺陷解决时长都小于平均解决时长;严重性程度不是normal的缺陷解决时长都大于平均解决时长。

  由此可见,严重性程度为normal级别的软件缺陷会被开发者优先解决;严重性程度较高的缺陷解决难度较大,导致解决时长也较长;严重性程度较低的缺陷受重视程度不高,导致解决时长也较长。

  (3)开发者持对缺陷修复率的影响

  通过对Mozilla产品的软件缺陷报告的分析,发现报告的持有者(开发者)与报告的修复率之间具有较密切的关系。该项目开发者共有8497个,其中持有5个以上缺陷修复工作的共有3505位,本文将这部分开发者分为6类,分别为0-5个、5-10个、10-50个、50-100个、100-500个、500-1000个以及大于1000个缺陷报告。由于持有5个以下缺陷修复工作的开发者的修复率都不高,本实验不对该部分数据进行比较。

  本实验针对Mozilla项目开发者持有的缺陷报告的修复率进行了分析。如图3所示,随着开发者持有的缺陷报告数量的增加,报告修复率从77.22%显着下降到52.40%;解决方案重复率从5.05%上升到18.31%,无法重现率从5.81%上升到18.02%,不合法、无法修复、信息不全等属性变化均在10%以内;从报告严重性程度属性来看,开发者持有的critical和major级别的报告比率上升了1.16倍(从11.51%上升到 24.91%),其修复率、是不断降低的,解决方案重复率、无法重现率小幅增加,不合法、无法修复、信息不全等属性也随整体曲线小幅增加。

  图3 开发者解决缺陷的方案比例图
图3 开发者解决缺陷的方案比例图

  由此可见,在报告分配过程中,修复率越高的开发者,获得报告的机率也越大,获得难度较高的报告的概率也会增加。从而导致持有报告较多的开发者,其报告修复率降低。

  (3)缺陷报告严重性对软件组件修复率的影响

  通过对Mozilla缺陷报告中数量高于10000的16个组件的严重性分布情况进行分析。发现各组件的缺陷报告中,严重性程度为normal等级的缺陷报告数量最多。

  通过统计Mozilla不同组件的缺陷报告的分布情况。Mozilla已有缺陷报告中涉及到的组件有1936个。如图4所示,各组件缺陷报告的修复率差异较大,其中Server Operationser组件修复率最高,达到了85.94%;Untriaged组件修复率最低,只有0.84%

  图4 不同组件缺陷报告数量和修复率分布图
图4 不同组件缺陷报告数量和修复率分布图

  根据不同组件对应的缺陷报告严重性程度分布可知,不同组件的缺陷报告严重性等级存在较大差异。主要原因是各组件中,不同严重性程度等级报告的比例波动较大。如Server Operationser组件中blocker等级的报告占比最大,导致其修复率最高;Untriaged组件中normal等级报告占比最大,导致其修复率最低。说明修复率会随严重程度的增加而提升。

  5.2 Eclipse项目缺陷报告属性与严重性等级关系分析

  (1)缺陷报告严重性程度对修复率的影响

  在Eclipse项目中,缺陷报告严重程度为默认等级的normal等级报告数量占报告总数量的67.02%。严重性程度最高的blocker等级缺陷报告仅占1.54%。不同严重性程度缺陷报告情况的解决情况如表2所示,严重性程度最高的blocker等级和critical等级的缺陷,被解决的比例超过95%。

  根据不同严重性程度的软件缺陷被解决情况的数量分布情况可以看出,严重性程度为enhancement等级的缺陷报告被修复情况中,解决结果为Fixed的比例最低,约为60%;解决结果为invalid的缺陷报告比例最高,达到18%。

  由此可见,严重性程度较高的缺陷报告的修复率对软件产品质量的影响较大、修复率较高。严重性程度较低的缺陷报告的修复率较低。

  (2)缺陷报告严重性程度对缺陷解决时长的影响

  图5 各严重性等级缺陷报告解决时长分布
图5 各严重性等级缺陷报告解决时长分布

  由于缺陷的解决时长是缺陷报告的主要属性之一,所以本文根据Eclipse项目的具体情况,分析了解决时长于严重性等级之间的关系。图5是Eclipse项目中,不同严重性缺陷报告对应的平均解决时长分布情况。整体趋势上,随着严重性等级的降低,缺陷报告的平均解决时长逐步增加。其中严重性程度最高的blocker级别报告的平均解决时长为45天,严重性程度最低的enhancement级别报告的解决时长为441天。

  由此可见,严重性程度为normal的缺陷会被优先解决,从而具有较短的解决时长。而严重性程度较高或较低的缺陷,受解决难度和重视程度的影响,导致解决时长增加。

  表2 Eclipse项目中不同严重性程度缺陷报告分布情况表
表2 Eclipse项目中不同严重性程度缺陷报告分布情况表

  (3)开发者对缺陷修复率的影响

  Bugzilla平台上参加Eclipse缺陷修复的开发者共有2624位,其中持有缺陷报告数量小于5个的用户最多,约占总用户量的35%。我们按照开发者持有缺陷报告的数量不同,将开发者分为6类。

  图6 开发者解决缺陷的方案比例
图6 开发者解决缺陷的方案比例

  本文统计了拥有不同数量缺陷的开发者的缺陷修复率,如图6所示。开发者持有缺陷数量小于5个时,缺陷修复率为80.11%;当开发者持有缺陷数量大于等于1000个时,缺陷修复率为49.75%;随着缺陷报告持有量的增加,解决方案的重复率由3.87%上升到18.69%,无法重现率由2.43%上升到10.18%,不合法、无法修复、信息不全等属性的增加量均在10%以内。以上现象表明,开发者持有的缺陷报告数量的增加,会使其修复率下降。

  (4)缺陷报告严重性对软件组件修复率的影响

  由于项目组件是缺陷报告的重要属性之一,所以本实验针对Eclipse产品的不同组件,进行了缺陷报告的分布情况分析。Eclipse项目的组件总数为782个。根据缺陷报告的分布情况,我们选取了缺陷报告数量最多的前10个组件的数据进行分析。如图7所示,各组件缺陷报告的修复率均高于80%,其中TPTP组件修复率最高,达到了99.82%。

  图7 不同组件缺陷报告数量和修复率分布
图7 不同组件缺陷报告数量和修复率分布

  根据不同组件对应的缺陷报告的严重性情况可以看出,各组件中严重性程度为normal等级的缺陷报告占比最大;严重性程度最高的blocker等级缺陷报告,在TPTP组件中所占比例最大,使其修复率最高;严重性程度最低的enhancement等级缺陷报告在Text组件中比例最大,导致其修复率最低。

  由此可见,不同组件的缺陷报告严重性等级存在一致性,即严重性程度越高的缺陷修复率越高,具有较多高严重性程度的缺陷的组件的缺陷修复率也较高。

  6 结论

  缺陷报告管理工具能够快速、标准的管理软件缺陷报告仓库。准确、全面、高效的评价缺陷报告的严重性,成为大型开源项目维护工作的重要问题。

  本文针对Bugzilla缺陷报告管理工具中的,Mozilla产品和Eclipse产品的缺陷报告仓库进行了系统性的分析。认为产品版本的更新会促使软件缺陷报告数量显着增加;软件缺陷报告的严重性程度的提升,会提高开发者对软件缺陷的重视,从而提高缺陷的修复率,并缩短软件缺陷的修复时间;开发者的缺陷报告持有量并不能决定其修复率。以上规律在不同的产品组件中也得到了证实。

  根据以上的统计结果可知,使用机器学习的方法对软件缺陷报告的数据进行分析,判断其严重性程度,能够使软件缺陷的归类更准确,有效缩短重要缺陷的修复时间,提高软件缺陷修复率,保障软件版本迭代的效率。今后,将在跨项目的缺陷报告严重性程度预测等方面,进行更深入的研究。

  参考文献:

  [1] Pressman R. Software Engineering: A Practitioner’s Ap-proadi[M]. New York: McGraw-Hill lnc,2010:210.
  [2] Anvik J. Automating bug report assignment[C]//Pro- ceedings of the 28th International Conference on Software Engineering, New York, 2006. NY: ACM, 2006: 937- 940.
  [3] Caglayan B, Tosun Misirli A, Bener A B, et al. Predicting defective modules in different test phases[J]. Software Quality Journal, 2015 , 23(2): 205 -227.
  [4] Jeong G, Kim S, Zimmermann T. Improving bug triage with bug tossing graphs[C]//European Software Engineering Conference and the ACM Sigsoft Symposium on the Foundations of Software Engineering, New York, 2009.New York: ACM, 2009:111-120.
  [5] J. Pohjalainen, O. R?s?nen, S. Kadioglu, Feature selection methods and their combinations in high-dimensional classification of speaker likability[J].Comput. Speech & Language, 2015, 29 (1):145-171.
  [6] Hooimeijer P, Weimer W. Modeling bug report quality[C]//Ieee/acm International Conference on Automated Software Engineering, New York, 2007. NY: DBLP, 2007: 34-43.
  [7] Jurado F, Rodriguez P. Sentiment Analysis in monitoring software development processes: An exploratory case study on GitHub's project issues[J]. Journal of Systems & Software, 2015, 104(C):82-89.
  [8] Anvik J. Who should fix this bug? [C]//Proc. International Conference on Software Engineering, New York, 2006. NY: ACM, 2006:361-370.
  [9] Shepperd M, Bowes D, Hall T. Researcher bias:the use of machine learning in software defect prediction[J]. IEEE Transactions on Software Engineering,2014,40 (6): 603-616.
  [10] Zimmermann T, Premraj R, Bettenburg N, et al. What Makes a Good Bug Report?[J]. IEEE Transactions on Software Engineering, 2010, 36(5):618-643.
  [11] Rastkar S, Murphy G C, Murray G. Summarizing software artifacts: a case study of bug reports[C]// ACM/IEEE International Conference on Software Engineering., New York, 2010. NY: ACM, 2010:505-514.
  [12] Zhang T, Yang G, Lee B, et al. Predicting severity of bug report by mining bug repository with concept profile[C]// SAC '15 Proceedings of the 30th Annual ACM Symposium on Applied Computing., New York, 2015. NY: ACM, 2015:1553-1558.
  [13] Kim S, Whitehead E J,How long did it take to fix bugs?[C]//Proceedings of the 2006 Intemalional Workshup on Mining Software Repositories, New York, 2006. NY: ACM, 2006. 173-174.
  [14] Zhang T, Chen J, Yang G, et al. Towards more accurate severity prediction and fixer recommendation of software bugs[J]. Journal of Systems & Software, 2016, 117(C): 166-184.
  [15] Runeson P, Alexandersson M. Nyholm O. Detection of duplicate defect reports using natural language processing[Cl//Proceedings of the 29rh International Conference on Software Engineering, Washington, 2007. DC: IEEE Computer Society, 2007:499-510.
  [16] W.J. Liu, S.S. Wang, X. Chen H. Jiang. Predicting the severity of bug reports based on feature selection[J]. International Journal of Software Engineering and Knowledge Engineering, 2018, 28(4): 537-558.

联系我们
  • 写作QQ:78307562
  • 发表QQ:78303642
  • 服务电话:18930620780
  • 售后电话:18930493766
  • 邮箱:lunwen021@163.com
范文范例
网站地图 | 网站介绍 | 联系我们 | 服务承诺| 服务报价| 论文要求 | 期刊发表 | 服务流程