写点什么

遇到代码缺陷不要慌,马上教你快速检测和修复

发布于: 2021 年 01 月 15 日

摘要:人类思维中总存在缺陷,写出的代码一样会存在缺陷,导致软件系统出现不符合预期的行为。本文讨论了软件缺陷的定义、分类、检测和修复。


人类思维中总存在缺陷,写出的代码一样会存在缺陷,导致软件系统出现不符合预期的行为。自动化地检测和修复缺陷是提高软件开发效率和软件质量的重要手段。本文讨论了软件缺陷的定义、分类、检测和修复。

软件缺陷与其分类

计算机学科中的中文词汇很多是从英文翻译过来的,有时不能够准确地描述或刻画词汇真实的含义。在软件领域,你能想到的和缺陷相关的词汇可能有: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 修复工具。


本文分享自华为云社区《遇到代码缺陷不要慌,马上教你快速检测和修复》,原文作者:APTX-486977 。


点击关注,第一时间了解华为云新鲜技术~


发布于: 2021 年 01 月 15 日阅读数: 25
用户头像

提供全面深入的云计算技术干货 2020.07.14 加入

华为云开发者社区,提供全面深入的云计算前景分析、丰富的技术干货、程序样例,分享华为云前沿资讯动态,方便开发者快速成长与发展,欢迎提问、互动,多方位了解云计算! 传送门:https://bbs.huaweicloud.com/

评论

发布
暂无评论
遇到代码缺陷不要慌,马上教你快速检测和修复