静态检测工具STATIC以及静态分析的必要性

这一篇向大家介绍的是我司静态检测工具STATIC以及静态分析的必要性。欢迎各位技术大牛发表自己的看法呀!

正常运行的软件就是完美的软件吗？

下图是漫威电影《黑豹》中给小编留下很深印象的场面

答案是无论做的多好，也有改进的余地！

好的软件也是一样。正常运转不代表没有需要改善的地方，或许未被发现的BUG就隐藏在其中。

本文将针对动态测试未能发现的BUG和静态分析的必要性以及需要修改缺陷的理由这三块内容展开讨论。

 动态测试不能发现的BUG

找出动态测试中未能发现的BUG的方法都有哪些呢？

首先将对产生BUG的理由进行说明。虽然BU*生的原因有成千上万，但大体可分为以下4种：

1. 未考虑到的用例 (遗漏要求事项)

2. 意外行为 (误解要求事项)

3. 未预想的输入 (忽略异常处理)

4. 因编程出错而产生的BUG

1和2都可以通过动态测试在一定程度上得以覆盖。通过整理好的要求事项和100%的覆盖率以及QA流程，可以捕捉到大部分的BUG。下面让我们来思考一下容易被漏掉的3和4。

 

未预想到的输入（忽略异常处理）

为什么利用动态测试不能发现未预想到的输入呢？

没有将未预想到的输入作为动态测试的用例。这是因为如果将其作为动态测试用例的话，由于其已经是预想到的输入所以也就不会发生此类错误了。

最简单的例子就是divide by zero错误或buffer overrun错误。这种类型的错误最大的问题就是大部分都会在软件发布后发生。

 

由于简单的编码错误导致的故障

在动态测试中未能发现的编程错误有哪些呢？

最典型的例子就是memory leak。一般来说，memory leak只有在程序长时间的运行过程中未能释放不再使用内存的情况下出现。  

在开发阶段需快速确认结果的动态测试中很难发现memory leak。并且像内存泄漏这种错误，就算发现了相应的BUG也很难找到具体哪一部分发生了泄露。

前面提到的因未能预想到的输入或编程失误而导致的BUG一般不是在开发阶段而是在运行阶段被发现。为更方便说明我们将这样的BUG统称为运行时错误(Runtime Error)。

 

防止时错误的方法

下边我们一起来探讨一下为防止运行时错误需要经过哪些过程吧！

最好的方法是多多练习，多多积累经验。经验丰富的开发者能够在开发过程中便考虑到运行时错误。

那这么说的话，经验欠缺的开发者在面对运行时错误时只能是毫无防备地进行开发吗？ 

一般来说为了预防这种错误的出现，在开发中会进行结对编程、Mob编程、代码评审等过程。但是在日程紧凑，急于将产品上市的情况下实际上不会有充足的时间做以上工作。并且因为经验丰富的开发者工时成本高，所以在公司或团队的立场来看结对编程等活动有些效率低下。

 

需要静态分析 (Static Analysis)的理由

有一种方法可以用低廉的费用代替经验丰富的开发者，这便是静态分析。

通过执行静态分析可以在事前防止运行时错误方面起到事半功倍的作用。静态分析是基于经验丰富的开发者的技术以及实际产生的各种运行时错误总结规律、制定规则，并且利用这些规则对源代码整体执行分析。这里的分析是指我们对未预想到的输入、程序流或代码评审中意外忽略了的代码进行检查。其意味着可以找出在动态测试或代码评审时未能找到的BUG。

静态分析无需运行代码。对于不完整的代码也能进行分析，因此相比动态测试，静态测试能够在更早时期发现BUG。并且静态测试还拥有相比动态测试可以在更短时间内找出BUG的优点。

下图为我公司韩国本部Suresoft Tech的静态分析解决方案CodeScroll STATIC运行的画面。

Mission Critical领域更加重视编码规则检查以及运行时错误的产生，项目规模也变得大型化。因此，随着静态分析时间和交流费用的增加，缺陷的修改也遇到了困难。STATIC就是为了解决这些问题而开发的解决方案。其可以通过提供多种编码规则集，使项目高效、便利地进行。

<图2>CODESCROLL STATIC memory leak BUG检测画面

<图3>CODESCROLL STATIC Buffer Overrun检测画面

下面再一起看一下需要静态分析的其他理由吧。

正如本文在开头部分提到的正常运行的软件总会存在需要改善的地方。静态分析不仅可以找出BUG，还能找出可进一步改善的代码。静态分析也会提供编码样式指南相关的规则和代码的质量度量。

静态分析会检查编程语言是否遵循了编码样式指南规则提供的指南或团队及公司规定的指南。这种指南是考虑到代码的维护和可读性等进行制定的，因此必须要遵守这样的准则。

代码质量度量是用数值体现代码的复杂度、扩展性和可移植性。利用质量度量将看不见摸不着的代码质量定量化，进而我们可以控制工作，达到定量化的数值。如果在开发初期不进行质量度量管理，在之后这方面的费用将逐步增加，进而会出现放弃改善软件的情况。若在开发初期就进行质量度量管理，那便可以使用较少的技术投入改善升级产品。

<图 3>CODESCROLL STATIC Metric页面

 

动态测试VS静态测试

动态测试在测试方法中也是属于投入费用较大的一种工作。随着源代码不断增加复杂度提升，需要维护的测试代码的数量也在随之增大。并且编写测试代码也是编程的过程，自然会产生失误和错误，而测试代码的错误会给产品的质量带来很大的影响。

当然，动态测试和静态测试找出的错误类型和性质不同，最好是两种测试全部进行。但在日程和费用相同的情况下只能进行一项测试的话，我们会毫不犹豫地推荐您静态分析。

 

可能的话, 一定要修改

做完静态测试但却没有依据结果进行修正的情况很常见。因为是非常细微的错误所以就忽略或与程序的运行无关的错误就没再关注的这种情况也不少见。虽然充分考虑到费用和时间后再决定是否进行修改是很重要的，但最建议还是尽可能地修改代码减少所有缺陷。

有经验的开发者失误更少。因为所谓经验是与习惯相关联的，而习惯又来自于重复。所以不断修改代码的过程不只是对于完善产品有利，还有助于开发者养成良好的编码习惯。经验多的开发者大多是具有好习惯的开发者。静态分析不是一项繁琐的工作，而是提升开发者本人实力和从业价值的一种帮助。想象一下，若是有一天您写的代码在完成静态测试后得到0个错误的结果，那该有多满足。静态分析和修改缺陷不只是在完善产品，开发者本人也将获得巨大的益处。

无论多完美的软件都还有可以改善的地方。