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

10次阅读

共计 2288 个字符,预计需要花费 6 分钟才能阅读完成。

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

人类思维中总存在缺点,写出的代码一样会存在缺点,导致软件系统呈现不合乎预期的行为。自动化地检测和修复缺点是进步软件开发效率和软件品质的重要伎俩。本文探讨了软件缺陷的定义、分类、检测和修复。

软件缺陷与其分类

计算机学科中的中文词汇很多是从英文翻译过去的,有时不可能精确地形容或刻画词汇实在的含意。在软件畛域,你能想到的和缺点相干的词汇可能有: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。

点击关注,第一工夫理解华为云陈腐技术~

正文完
 0