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

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

创新互联建站是一家集网站建设,电白企业网站建设,电白品牌网站建设,网站定制,电白网站建设报价,网络营销,网络优化,电白网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

软件缺陷与其分类

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

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