Parasoft作为软件测试工具，小编接触过很多在这方面寻求帮助的人，所以有这方面疑惑的不止你一个人哦！

-------------华丽的分割线---------------

我们假定你已经安装了静态分析工具并配置了所有初始设置。除此以外，如果刚开始没有确定项目需要采取的策略，入门会比较困难。小编所说的“入门”是指深入理解将静态分析集成到现有项目中的一般方法，以及如何提高静态分析随着时间的推移带来的投资回报。

什么是静态分析？

简单来说，静态分析是在不执行代码的情况下检查源代码和二进制代码的过程，通常用于查找bug的前期准备或评估代码质量。与需要运行程序的动态分析（例如Parasoft Insure ++）不同，静态分析可以直接分析源代码而不需要执行源代码。

这意味着静态分析可用于部分完整的代码，库和第三方源代码。开发人员可以将静态分析应用在编写或修改代码的过程中，甚至可以应用到任何代码库。

支持功能安全和编码标准

在应用程序安全域中，静态代码分析采用了静态应用程序安全性测试（SAST）技术。静态分析可以支持安全漏洞检测，同时支持bug检测，质量指标和编码标准一致性检测。

另外，静态分析工具强制要求（在某些情况下“强烈推荐”）能够支持安全标准（如ISO 26262或EN 50128）的检测，因为这些标准能够检测难以发现的缺陷并提高软件的安全性。当然，这又回归到安全性的问题上，因为静态分析工具还可以帮助软件团队遵守主要用于验证安全编码的编码标准，例如CERT甚至MISRA。

静态分析工具优点及难点

静态分析工具的一个优点是它们可以在项目的任何阶段引入和使用，即使项目是不完整的或者只有部分编码是有效的。引入静态分析的最大难点在于代码量大会产生大量的警告。因此，将静态分析应用到项目中时的重点应该是使团队能够尽快高效工作，并最大限度地减少团队被静态分析的警告困扰的情况。这并不是说这些警告不重要，但大多数开发人员都不会修复现有或遗留代码缺陷，至少不是立即处理。

最重要的应该是将静态分析运用到日常流程中，以便最大化静态分析的使用效果和可用性，然后处理最危险的bug和安全漏洞。一旦团队变得更加熟练，你就可以专注于优化工具和流程，提高投资回报率。

如何管理早期静态分析报告

一旦将静态分析工具安装到项目中，该工具通常会报告相当长的违规和警告报告。这可能是多到无法处理的，特别是在大型代码库中，因此如何管理这些报告将会直接影响到工具集成到项目中能否成功。

并非所有警告都是至关重要的，因此不需要立即处理所有警告。学习哪些需要立即解决而哪些需要推迟处理是成功的关键。如上所述，产品的成熟度和规模对方法有直接影响，下面将更详细地概述。

底线方法

顾名思义，在这种方法中，开发人员决定在初步分析之后，他们不会让任何更严重的警告和违规进入代码库。换句话说，他们需要分析每个警告来确定其准确性，并及时修复，如果它确实是一个bug。

团队还可以决定在现有代码中添加已发现的关键警告，并将其添加到报告工具中的bug列表中。这些类型的警告可能是严重的安全漏洞，如SQL注入，或严重的内存错误，如缓冲区溢出。在大多数情况下，可以推迟不太严重的警告以供以后分析。你可能会想，“这不仅仅会增加我们的技术债务吗？”如果你这样想，那你就是对的！但在这个阶段，我们对此表示满意。这些警告中的任何潜在错误都已经在技术债务堆中。至少现在，它们被识别出来并且以后更容易修复。

确认并推迟处理方法

如果产品已经在市场上并且正在维护中，那么识别代码中的任何bug和安全漏洞仍然是有益的，但让开发人员分析（更不用说修复）所有这些警告是不可行的。

在这种情况下，查看最重要的报告并确定行动方案是有意义的。其余的警告只需要确认，因为软件团队认识到它们存在，但它们大多数都被推迟了。（这再次增加了该组织的技术债务，但如上所述，这些漏洞在技术上已经存在作为技术债务。）这种方法不同于底线方法的地方在于确定关键警告后，你会推迟其余的警告，而不需要所有的都分析。

绿地方法

现有代码很少的项目是静态分析的理想起点。在这种情况下，软件团队可以调查出现的所有警告并修复发现的错误。与其他方法不同，你只需要管理很少的警告，因此开发人员可以解决额外的工作。这也是通过这些工具实现和实施编码标准的理想时间，因为可以在IDE中以及在将任何代码提交到版本控制之前识别和修复违规（你可以在此处描述的其他方案中执行此操作）。

在三个主要阶段采用何种静态分析，可以通过如何处理积压的警告来区分，如下所示：

在三个主要阶段采用静态分析：在绿地项目中，大多数报告的警告都经过调查和修复，几乎没有进入技术债务堆。正在开发的项目往往会积压大量的警告，这些警告大部分都是推迟处理，只处理严重警告，维护中的产品往往会推迟大多数警告。

配置与过滤

开源或轻量级静态分析工具与商业高级静态分析工具之间的主要区别之一在于能否配置为分析启用哪组检查器，并根据警告类别，文件名，严重性等过滤掉报告的结果属性。这有助于突出目标——开发人员可以专注于他们感兴趣的警告类型，并减少在任何时间产生的垃圾信息量。

配置检查器和过滤结果之间也存在差异。尽管一开始限制全局配置中的规则数量似乎更好，但通常应使用过滤来限制报告范围，而不是完全消除检查程序。如果在配置中关闭后来证明是重要的规则，则警告存储库中将没有历史记录，因此你将无法确定错误是由最近的更改引入还是在静态分析之前已经在代码中。

我建议使用配置将规则集限制为可预见对软件团队有用的规则。同样，以最终目标为出发点：如果提高安全性是关键目标，那么启用所有与安全相关的规则，禁用不太重要的规则，启用CERT C等内置安全编码标准。如果你正在使用Parasoft C/C++test等高级静态分析解决方案，你可以利用其内置的管理工具来处理静态分析报告中生成的数据，并推进未来的重点开发工作。

总结

静态分析工具使团队无需执行代码，就能够检测和跟踪错误安全漏洞。这些工具可应用于现有、传统和第三方代码并提供质量审查结果。

采用何种静态分析方法在一定程度上取决于项目的成熟度。大量代码确实会产生大量警告。但这完全是可管理的，能否成功取决于团队如何决定处理结果。好好考虑为项目的每个成熟度阶段引入不同的技术，以及如何将这些工具集成到开发人员，团队负责人和经理的日常工作流程中。

产品咨询：

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。