误解:静态分析只是为了寻找bug

更快的上市时间趋势可能会导致这种误解静态分析只是为了找出漏洞。软件开发人员必须消除尽可能多的bug，并使用快速的bug查找工具，尽管有些bug可能仍然存在。这种做法对于非安全关键型应用程序(如智能手机应用程序)可能足够了，但对于安全关键型应用程序可能还不够。因此，安全关键型应用程序需要更严格的方法来验证安全性和健壮性，这就是静态分析的其他好处所在。在本文中，我们将打破静态分析只是为了寻找错误的误解，并证明它可以帮助验证编码标准的遵从性，产生关于代码质量的度量，并在软件开发的任何阶段使用。

发现bug绝对是一个重要的方面静态代码分析．然而，静态分析技术可以从简单的语法检查或基于启发式的方法到高级的基于形式方法的验证。这个范围也代表了市场上各种各样的静态分析工具。例如，一些高级编译器有内置的语法检查器作为静态分析的一种形式。另一端是基于形式化方法的工具，如Polyspace^®s manbetx 845进行语义分析的产品，为您提供软件的详细运行时行为。

例如，Polyspace Bug Finder™是一个静态分析工具，可以帮助您发现错误，但它也可以用于(1)检查您的软件是否符合MISRA C/ c++、JSF++和自定义规则等编码标准，以及(2)生成代码度量来帮助提高代码质量。此外，使用Polyspace Code Prover™，您可以证明您的软件不会由于某些类型的关键运行时错误而崩溃。

因此，这些工具不仅仅是简单的错误查找，而且在验证和验证过程中很有价值。例如，下图中的代码是正式验证的结果，确认在任何操作条件下都不会发生溢出:

如前所述，您可以使用静态分析来检查您的代码是否符合特定的编码指南或标准，从而防止使用不安全或不可靠的结构。它还可以帮助您捕获指示代码质量的关键指标，例如圈复杂度、无法到达的代码、共享全局变量的使用和递归——而无需编写测试用例的开销。这些指标可以帮助您识别设计问题，例如代码的架构，这些问题最终会影响软件的性能和可靠性。

例如，在特定的测试用例中，使用未初始化的变量或不受保护的共享变量可能会出现意外的结果。然后，您可能开始调试任务，并花费无数小时试图确定问题。更麻烦的是，这些缺陷可能不会在测试期间出现，因为这些运行时错误具有不可预测的性质。

静态分析更广泛的好处并不为人所知，因此在软件开发工作流的后期阶段才采用它。因为它被简单地认为是一种发现错误的方法，所以通常在软件开发的最后阶段采用(例如，静态分析是QE小组发布代码之前的最后一道大门)。超过90%的与我们联系的静态分析解决方案的潜在客户正在进入项目的结束阶段。

然而，如果您想要利用上面讨论的所有好处，您应该在开发的早期阶段结合静态分析。事实上，编译器的使用就是一个例子，因为编译器是一个非常简单的静态分析工具，可以帮助开发代码的语法和语义。研究强调了早期发现和修复编码错误的显著成本效益*。您还减少了正在开发的软件所需的测试量。通过这种方式，尽早将静态分析合并到您的工作流中是很重要的，而且它不仅仅是简单地识别错误。

参考

• V. Basili和B. Boehm，“基于cots的十大系统列表”IEEE计算机,卷34(5):91-93,2001年5月。