人的思维总是有缺陷的，写出的代码也会有缺陷，从而导致软件系统出现意想不到的行为.自动检测和修复缺陷是提高软件开发效率和软件质量的重要手段。本文讨论了软件缺陷的定义、分类、检测和修复。软件缺陷及其分类计算机科学中的许多中文词汇都是从英文翻译过来的，有时并不能准确描述或刻画词汇的真正含义。在软件领域，你能想到的与缺陷相关的词可能包括：bug、defect、fault、error、failure、exception等等。老实说，我一直不明白这两个词的区别。但是了解这些词汇的区别不仅仅是文字游戏，还可以帮助我们了解它们在检测和修复技术上的差异。所以我用谷歌搜索了一下，但大多数文章对这些词的定义都不一致。以下是我同意的软件代码中这些术语的定义。Fault/Bug：软件中出现不符合业务逻辑的代码，如+号写成了-号；错误：软件运行过程中出现非预期值，如a的值为2，计算为3；失败：在软件与人的交互中出现意外行为，例如程序崩溃。因此，Fault可能导致Error，最终可能导致Failure。请注意，这是可能的，但不一定；Defect：Defect的一种，是对代码本身存在的一类缺陷的统称（归纳），比如内存泄漏。Fault通常需要从Error、Failure来检测，即比较程序的执行结果是否符合预期的规范（Specification）。这个过程其实就是调试（debugging）和测试（testing）。故障也可以称为与业务逻辑相关的缺陷。Defect是代码本身的问题，是不依赖于执行结果和预期规范的软件问题，所以Defect通常是通过静态扫描（不运行）代码来检测的。缺陷检测与修复的现状从上面可以看出，Fault是通过测试来检测的，而Defect是通过静态分析来检测的。在企业中，Faultdetection的普及度和认可度通常高于Defectdetection。开发者认为影响软件行为是可有可无的，或者只在非常特殊的场景下影响软件行为；(2)Fault引起的软件错误易于观察。如果有直接证据表明软件存在错误，开发人员会倾向于修改，而Defect通常更难观察；(3)测试门槛较低，测试人员只需编写一些测试脚本即可，而静态分析则需要程序分析技术的积累；(4)静态分析固有的一些缺点（耗时、误报）引起开发者的不满。自动修复这几年在学术界比较流行，在企业也逐渐开始使用，但应该还处于起步阶段。与检测相反，故障自动修复的难度比较大，因为涉及到业务逻辑，需要手动添加一些逻辑。当然，最近也有很多学术研究利用机器学习来自动学习故障自动修复；而很多缺陷修复是不需要添加与业务逻辑相关的代码，所以自动化程度可以达到更高的水平，但是目前还没有这方面的自动化工具。缺陷检测与修复的问题与展望不难发现，故障检测已经比较成熟；而缺陷检测并没有受到足够的重视。以前，我们可能只关注软件的正确性，所以故障的检测和修复比较流行，但是缺陷也会影响软件的质量，同样需要引起重视。近期，公司提倡提升软件工程能力，打造高可靠的软件产品。它还强调我们不仅要关注软件功能的正确性，还要关注非功能方面的质量，写出“漂亮”的代码。因此，缺陷的自动检测和修复是一个更有价值的方向。以下是一些可能要做的事情：(1)加强开发人员对Defects的培训，让开发人员了解常见的Defect，在编码时尽量避免，写出这样的Defect比后续的检测和修复成本要低得多。虽然公司有很多编程规范来定义不同的缺陷，但开发人员可能不会认真学习。如何让开发者意识到缺陷的危害更为关键；（二）强化代码审查机制。这一点我个人深有体会：没有review的时候，写的代码比较随意，有review的时候，会考虑的更全面，毕竟要给别人看；(3)缺陷自动检测。对于故障检测，人优于机器（如编写测试用例），但对于缺陷检测，机器优于人（如枚举程序路径），因此缺陷检测更适合自动化。目前公司也推出了一些Defect自动检测工具，如coverity、fortify、findbugs等，但这些工具通常只作为黑盒使用。这样可以覆盖更多的缺陷，但也带来了一些问题：同一个缺陷实例被不同的工具重复上报，难以添加一些缺陷检测规则，难以处理缺陷异常场景。因此，我们可能需要一个统一的缺陷检测工具。(4)缺陷自动修复。Defectdetection除了耗时和误报之外，另一个不受欢迎的方面是开发人员不知道如何修复它。因此，Defect的自动修复也是提高Defect关注度的有效途径。而且与Fault的自动修复相比，Defect的自动修复对机器来说更简单，因为Defect的类别有限，可以枚举，而且Defect的性质比较正式，不依赖于业务逻辑。未来，我们希望开发一个统一的缺陷修复工具。
