静态分析发展简史

第一代静态分析

第一个静态分析工具出现在70年代后期，以Lint最为人所知，它可被视为第一代商业可行的静态分。Lint最初发布时给了开发人员的一个大承诺。第一次，开发人员有能力在开发周期的早期——最容易修复缺陷的时间—— 自动检测软件缺陷。推而广之，这让开发人员在其代码发布之前对他们的代码质量更有信心。Lint后面的第三代分析技术——布尔可满足性技术和路径仿真的完美组合——是革命性的，因为它使用编译器进行缺陷检查，使之成为第一个可行的静态源代码分析的解决方案。

但实际上，Lint的真正设计目标并不是要确认导致运行时问题的缺陷，而是标记代码中可疑的或不可移植的结构，帮助开发人员以更一致的格式编码。“可疑代码”是指从源代码语言（如C、C++）的角度看，技术上是正确的，但可能会以程序员不期望的方式执行。被标记大量可疑代码的问题是，就好比编译器警告，这种类型的代码可以，并且，经常工作正常。基于此和有限的分析能力，Lint的噪声比率高的离谱，噪声和真正缺陷的比率经常超过10:1。

  因此，发现真正的缺陷需要开发人员耗费大量时间，对Lint的结果进行详细的审查，捞出静态分析被期望消除的精确的问题。由于这个原因，Lint从未被当作一个缺陷检测工具被广泛采用，尽管它确实在一些组织中有一些有限的成功，事实上，作为Lint基本技术质量的一个证明，今天仍然有许多不同版本的产品。

第二代静态分析

相比于现实情况，近二十年来静态分析仍然更多地虚构为一个商业上可行的生产工具用来确认缺陷。2000年第二代工具出现，提供了足够的商业可行的价值。通过使用新技术，扩展了第一代工具过去简单的模式匹配的能力，也专注于路径覆盖。第二代静态分析可以发现更多的与实际运行时相关的缺陷。
 
这些工具还可以分析整个项目代码，而不仅仅是一个文件。通过将关注点从“可疑代码结构”转移至“运行时缺陷”，这些新静态分析技术的开发人员认识到需要更多的了解代码的内部工作。这意味着，当在一个特定的软件系统里控制流从一个函数到另一个时，复杂路径分析会结合“过程间分析”，以便理解发生了什么。

尽管有组织接纳并使用它，第二代静态分析仍然很难在精确度和可扩展性之间找到最佳点。有些解决方案对一小部分的缺陷类型是精确的，但不能扩展到分析数百万行的代码规模。其他一些可以在很短的时间里运行，但准确率接近于Lint，引入了熟悉的误报率和噪声问题。实施时，这些工具可以在一个可接受的比例内报告缺陷，但只用于严格受限的分析参数。

很难在精确度和可扩展性之间找到最佳结合点的难题导致了误报的问题，就像噪声问题阻止了第一代工具实现静态分析的承诺一样，误报问题减缓了第二代工具被快速接纳的速度。从技术角度看，虽然第二代工具将静态分析向前推进到检测有意义的缺陷上，但对于开发人员来讲，其结果在“更精确”方面还比较欠缺。

许多第二代工具受制于不同的构建和开发环境。由于不同组织使用不同的开发
环境，第二代工具往往需要团队进行痛苦的、耗时的定制或集成工作，除了使用最通用的技术，如简单的针对单一平台的Makefiles、antifiles、或者Visual Studio ®项目文件。

第三代静态分析

今天，新一代的静态分析技术正崭露头角，从适合目前的开发过程和环境的解决方案中提供无可匹敌的质量结果。利用布尔可满足性（SAT）解算器 ，补充传统的路径模拟分析技术，第三代静态分析将为开发人员提供一个是既全面又准确的无可匹敌的结果。

（完）

附：

静态分析的误报和噪声

 

有两种类型的不准确结果，可造成静态分析解决方案的问题——噪声和误报。嘈杂的结果是，技术上是正确的，但结果是无关紧要的分析。误报结果是分析断言代码的情况（例如，指针在150行可能为NULL并被引用），而实际上事实并非如此（例如，指针不可能为NULL）。低比率的噪声和低误报对任何静态分析都是非常重要的。换句话说，大多数时候它都应该是正确的（低误报率），报告的结果对于最终用户来讲是相关的（低噪声率）。

误报与噪声和第一代工具

 

误报和噪声结果一直是静态分析面临的一个挑战。即使是最流行的第一代测试工具的开发者也认识到这一点了。引用Lint发明者斯蒂芬约翰逊（Stephen

Johnson）的一句话：“Lint努力提供高度相关的信息。‘xxx可能是一个bug’格式的信息很容易生成，但只有小比例的真正的bug部分是可以接受的。如果这一小部分真正的bug太小，那么这些信息将会失去其可信度，只会使输出混乱，从而掩盖更重要的信息。”

 

——Stephen Johnson 7 /26 /1978