我的编程空间,编程开发者的网络收藏夹
学习永远不晚

总结软件缺陷的定义、分类、检测和修复

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

总结软件缺陷的定义、分类、检测和修复

这篇文章主要介绍“总结软件缺陷的定义、分类、检测和修复”,在日常操作中,相信很多人在总结软件缺陷的定义、分类、检测和修复问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”总结软件缺陷的定义、分类、检测和修复”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

软件缺陷与其分类

计算机学科中的中文词汇很多是从英文翻译过来的,有时不能够准确地描述或刻画词汇真实的含义。在软件领域,你能想到的和缺陷相关的词汇可能有:bug,defect,fault,error,failure,exception等等。说实话,我一直也没搞懂这些词汇的区别。但理解这些词汇的区别不仅仅是文字游戏,也能够帮助我们理解针对它们的检测和修复技术的不同。于是我google了一下,但大多文章对这些词汇的定义都不太一致。以下是我比较认同的这些词汇在软件代码上的定义。

· Fault/Bug:软件中出现不符合业务逻辑的代码,比如+号写成-号;

· Error:软件运行中出现不符合预期的值,比如a的值为2,被计算成3;

· Failure:软件与人的交互中出现不符合预期的行为,比如程序崩溃。因此Fault可能导致Error,最终可能导致Failure,注意这里是可能,并不是一定;

· Defect:一种Defect是一类代码自身缺陷的统称(归纳),比如内存泄漏。

Fault通常需要从Error,Failure中检测到,也就是比较程序的执行结果与预期的规范(Specification)是否吻合。这个过程其实就是debugging(调试)和testing(测试)。Fault也可以称为业务逻辑相关的缺陷。而Defect是代码本身的问题,不依赖于执行结果和预期的规范的一种软件问题,因此Defect通常是通过静态地扫描(不运行)代码来检测的。

缺陷的检测和修复现状

从上文可以看到,Fault是通过测试来检测的,而Defect是通过静态分析来检测。在企业中,Fault检测的普及率和认可度通常比Defect检测的高,主要原因有如下几点:

(1)Fault会直接影响软件的行为,被视为比较严重的问题,而很多Defect不能直接影响软件的行为,或者在很特殊的场景下才影响软件的行为,开发人员觉得可有可无;

(2)Fault引起的软件错误容易被观测,有直接证据证明软件中存在错误,开发人员会倾向去修改,而Defect通常比较难观测;

(3)测试的门槛低一些,测试人员只需要写一些测试脚本就可以,但静态分析需要有程序分析方面技术的积累;

(4)静态分析固有的一些缺点(耗时,误报)引起开发人员的不满。

自动修复方面,这几年在学术界比较热门,慢慢也在企业中开始使用,但目前应该还处于初级阶段。与检测相反,Fault的自动修复难度是比较大的,因为涉及到业务逻辑,需要人工加入一些逻辑,当然最近也有很多学术研究使用机器学习来自动学习Fault的自动修复;而很多的Defect的修复是不需要加入业务逻辑相关的代码,所以自动化程度反而可以达到较高水平,不过目前也没有看到这方面的自动化工具。

Defect的检测和修复的问题和展望

我们不难发现,Fault的检测已经比较成熟;而Defect的检测受重视程度还不够。以前我们可能只关注软件的正确性,所以Fault的检测和修复比较受欢迎,但Defect也会影响软件的质量,同样需要受到关注。

最近公司在提倡提升软件工程能力,打造高可信的软件产品,也是强调我们不仅仅要关注软件功能的正确性,也需要关注非功能方面的质量,写出“优美”的代码。因此,Defect的自动检测和修复是一个比较有价值的方向,以下是一些可能做的事情:

(1)对开发人员加强Defect方面的培训,让开发人员了解常见的Defect,在编码时尽量地避免写出这样的Defect,这比后续的检测和修复付出的代价要少很多。现在公司虽然有很多的编程规范定义不同的Defect,但开发人员可能并没有用心去学习,如何让开发人员意识到Defect的危害是比较关键的;

(2)加强代码的Review的机制。这一点我个人深有体会:没有Review时,写的代码就比较随意,有Review时就会考虑得全面一些,毕竟要给别人看;

(3)Defect的自动检测。对于Fault的检测,人比机器更擅长(比如写测试用例),但对于Defect的检测,机器比人更擅长(比如枚举程序路径),因此Defect的检测是更适合自动化的。目前公司也引入了一些Defect的自动检测工具,如coverity,fortify,findbugs等等,但这些工具通常只是作为黑盒来使用。这样能够覆盖更多的Defect,同时也带来一些问题:同样的Defect实例被不同工具重复报告出来,新增一些Defect检测规则比较难,处理Defect例外场景比较难。因此,我们可能需要一个统一的Defect检测工具。

(4)Defect的自动修复。Defect的检测除了耗时和误报外,另一个不受欢迎的地方是开发人员不知道怎么修复。因此,Defect的自动修复也是提高Defect受重视程度的一个有效途径。而且,相比Fault的自动修复,Defect的自动修复对于机器而言是要简单一些的,因为Defect的类别是有限的可以枚举的,同时Defect的性质是比较形式化不依赖于业务逻辑的。未来希望能开发出一个统一的Defect修复工具。

到此,关于“总结软件缺陷的定义、分类、检测和修复”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注编程网网站,小编会继续努力为大家带来更多实用的文章!

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

总结软件缺陷的定义、分类、检测和修复

下载Word文档到电脑,方便收藏和打印~

下载Word文档

编程热搜

目录