没有合适的资源?快使用搜索试试~ 我知道了~
理论计算机科学电子笔记174(2007)55-59www.elsevier.com/locate/entcsbug从哪里来?Andreas Zeller1Saarland University萨尔大学摘要对错误数据库的分析表明,某些软件组件比其他组件更容易发生故障。然而,很难找到容易发生故障的组件普遍共享的属性。我们已经挖掘了Eclipse bug和版本数据库,将故障映射到Eclipse组件。生成的数据集列出了所有Eclipse组件的缺陷密度,因此可能有助于找到预测组件缺陷倾向的特征。保留字:调试、验证、程序分析、跟踪验证和调试都与发现缺陷有关--要么是导致已知故障的缺陷(调试),要么是可能导致未知故障的缺陷这两种技术在过去都取得了长足的进步,并且可以广泛实现自动化-每天都可以更容易地检测和修复缺陷。但是,这些缺陷最初是如何产生的呢?当然是人类。所有缺陷都是工件,因此是由人类创建的,例如开发人员,设计师,技术作家(或高级验证和调试工具的构建者)。但是是什么让这些人犯错呢?为了解决这个问题,我们从软件故障本身开始。我们已经挖掘了许多实际的bug数据库--也就是存储用户报告的问题的档案。 通过将这些问题与它们各自的修复程序联系起来,并将修复程序与它们适用的位置联系起来,我们可以将问题追溯到实际的软件组件。这给了我们每个组件的缺陷密度--简单地通过计算应用的修复数。在每个项目中,组件之间的缺陷密度差异很大。人们可能想知道这些度量是否与常见的软件功能(如大小或复杂性)相关在微软[1]的一项研究中,我们发现对于每个项目,我们都可以找到与缺陷密度相关的指标,但我们发现的指标中没有一个与所有项目相关。1 电子邮件地址:zeller@acm.org1571-0661 © 2007 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi:10.1016/j.entcs.2006.12.02956A. Zeller/Electronic Notes in Theoretical Computer Science 174(2007)55使用的包失败概率org.eclipse.jdt.internal.compiler.lookup. *0.8629org.eclipse.jdt.internal.compiler。*0.8623org.eclipse.jdt.internal.compiler.ast。*0.8409org.eclipse.jdt.internal.compiler.util. *0.8175org.eclipse.jdt.internal.ui.preferences.*0.7619org.eclipse.jdt.core.compiler。*0.7169org.eclipse.jdt.internal.ui.actions.*0.6727org.eclipse.jdt.internal.ui.viewsupport.*0.6666org.eclipse.swt.internal.photon.*0.6600org.eclipse.jdt.internal.corext.util.*0.5982org.eclipse.swt.internal.motif.*0.5869org.eclipse.jdt.internal.ui.dialogs.*0.5666.. .org.eclipse.ui.model。*0.1797org.eclipse.swt.custom。*0.1760org.eclipse.pde.internal.ui。*0.1659org.eclipse.jface.resource.*0.1654org.eclipse.pde.core。*0.1608org.eclipse.jface.wizard。*0.1566org.eclipse.ui。*0.1488表1Eclipse 2.0中好的和坏的导入(包)(来自[3])既然开发人员首先会创建错误,那么是否有开发人员比其他人创建了更容易出现缺陷的代码?答案是肯定的,但同样,很难将缺陷密度与开发人员的具体特征特别是,管理者通常知道每个团队成员的长处和短处。因此,最有经验的开发人员会做风险最大的编码工作,因此这些人产生最多的缺陷也就不足为奇了到目前为止,我们发现缺陷密度的最佳预测是问题的核心。这是受到一个简单观察的启发:一些问题域比其他问题域更容易失败。例如,当在Eclipse代码库上工作时,我们发现在编译器内部工作比构建用户界面更困难和更容易出错。无论开发人员、编程语言或结果代码的复杂性如何,这种观察都是有效的。域由所使用的组件隐式地描述。当构建一个在Java文件上工作的Eclipse插件时,必须导入JDT类;如果插件带有用户界面,则GUI类是强制性的。表1显示了Eclipse中特定包的使用如何影响故障概率。使用编译器内部的组件有87%的机会在发布后的前六个月内有需要修复的缺陷。然而,使用用户界面包的组件只有15%的缺陷机会。同样,这些数字可以从现有的错误和版本数据库中收集。事实证明,导入关系是非常具有预测性的-事实上,我们发现由导入表示的域是软件缺陷的最佳预测器之一[3]。如果是域使软件容易出现缺陷,那么是什么使A. Zeller/Electronic Notes in Theoretical Computer Science 174(2007)5557域缺陷倾向? 现在我不知道 不过,我倒是有个假设一般来说,与其他组件的使用相关的软件缺陷是由于违反了这些组件的约束。作为一个例子,考虑编译器的内部数据结构,特别是抽象语法树。程序的这种内部表示有大量的约束,反映了编程语言的语法和语义属性。这些约束中的一些通过抽象语法树的声明结构和类型变得显式然而,大多数约束都是隐含的,因此很容易违反。如果我在一个抽象语法树中引入一个循环,它就不再是一个树,并且将它作为参数传递给一个期望树的函数可能会造成严重的破坏。然而,很少有语言允许我显式地表达抽象语法树的属性,这就是为什么这样的错误在编译时仍然无法捕获。相比之下,图形用户界面(GUI)出错的可能性要小可能是某些界面元素放置不当或根本不可见,但这样的错误很容易在第一次测试中被发现,并且很难逃脱到生产中。 需要遵守的约束更少,而且它们是明确的,特别是在经常使用的标准类中。我的假设是,正是这些隐含的约束决定了一个组件是否容易出现缺陷-域的隐式约束,如导入的组件所表示的。我们拥有的约束越多,它们越不明确,就越容易违反它们。如何确定隐式约束?我们必须分析组件的有效用法以及它们的用户的正常用法。我们必须找到适当的抽象来区分有效和无效的用法,或者正常和异常的用法。我们必须找到适当的方法来判断哪些约束容易违反,哪些不容易。我们必须看看这样的措施是否真的预测模块的缺陷倾向。请注意,我可能完全错了,决定缺陷密度的例如,某些领域可能要求控制或数据流具有特定的复杂性,而这种复杂性会导致更多的也可能是特定的领域吸引了特定的程序员,他们强加了自己的工作标准。可能还有其他我们还没有想到的错误来源。最有可能的结果是,缺陷倾向是多种因素的组合,有些在上面列出,有些根本没有列出。不过,好消息是,你可以帮助找出bug来自哪里。我们已经公开了Eclipse缺陷密度数据供下载[2]。它告诉Eclipse的每个组件在该组件中发生了多少发布后缺陷(图1)。现在的挑战是找出这些组件的哪些属性是缺陷密度的最佳预测因子。这是一对多个学科的人的挑战:• 在程序分析中(用于确定所有基本度量),• 在验证中(为了弄清楚约束是什么,以及是什么使它们变得复杂),58A. Zeller/Electronic Notes in Theoretical Computer Science 174(2007)55<?XML version=“1.0”encoding=“UTF-8”?><缺陷项目=“eclipse”release=“3.0”><包名=“org.eclipse.core.runtime”><计数><计数id=“前”值=“16”平均=“0.609”点=“43”最大=“5”>计数><编译单元名称=”Plugin.java“><计数>计数>编译单元><编译单元名称=”Platform.java“><计数>计数>编译单元>...<产品展示...缺陷>Fig. 1. Eclipse bug数据集(节选)。• 在调试中(为了找出这些缺陷是如何产生的),• 在设计中(设计新的方法来避免这些缺陷)。在过去,软件工程领域的实证研究发现,人们有很多想法,也有很多数据,但人们总是愿意分享他们的想法,很难找到愿意分享数据的人。我们希望像我们这样的数据集的公开可用性将促进调试和验证方面的实证研究,就像开源程序的公开可用性最终,我们不仅会知道错误在哪里,而且还会知道它们来自哪里,以及我们可以做些什么来避免它们。要访问Eclipse bug数据集以及项目的后续信息,请参见http://www.st.cs.uni-sb.de/softevo/致谢。 这项工作是由Thomas Ball、Nachi Na-gappann、RahulPremraj、AdrianSchr?o?r和TomZimmermann完成的。与他们进行的讨论有助于形成本文件。A. Zeller/Electronic Notes in Theoretical Computer Science 174(2007)5559引用[1] Nagappan,N.,T. 球和A。Zeller,Mining metrics to predict component failures,in:Proc. 软件工程国际会议,上海,中国,2006年,页。452-461[2] Schréoter,A., R. Prmr aj,T. Z imm erm an nandA. 你好,我想你应该知道的。 . . ,in:Proc. 第五届经验软件工程国际研讨会(ISESE),巴西里约热内卢,2006年。[3] Schréoter,A.,T. Zimm erm an nandA. Zellle err,Proc.,Proc.,P r o c.,Proc. 5th经验软件工程国际研讨会(ISESE),巴西里约热内卢,2006年。
下载后可阅读完整内容,剩余1页未读,立即下载
cpongm
- 粉丝: 5
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 李兴华Java基础教程:从入门到精通
- U盘与硬盘启动安装教程:从菜鸟到专家
- C++面试宝典:动态内存管理与继承解析
- C++ STL源码深度解析:专家级剖析与关键技术
- C/C++调用DOS命令实战指南
- 神经网络补偿的多传感器航迹融合技术
- GIS中的大地坐标系与椭球体解析
- 海思Hi3515 H.264编解码处理器用户手册
- Oracle基础练习题与解答
- 谷歌地球3D建筑筛选新流程详解
- CFO与CIO携手:数据管理与企业增值的战略
- Eclipse IDE基础教程:从入门到精通
- Shell脚本专家宝典:全面学习与资源指南
- Tomcat安装指南:附带JDK配置步骤
- NA3003A电子水准仪数据格式解析与转换研究
- 自动化专业英语词汇精华:必备术语集锦
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功