彩票走势图

“过多的误报”可能是避免进行静态分析的最常见借口。但是静态分析不必太吵。

几年前，静态代码分析中的最大挑战是试图找到越来越多的有趣检查对象。在90年代初期的Parasoft原始CodeWizard产品中，我们根据Scott Meyers的书《Effective C++》中的条款制定了30条规则。我想将其视为“程序员的直觉”。我曾向Scott提过一次，虽然他没有想到过……但是确实给了他一个很好的笑声。

从那时起，静态分析研究人员一直在努力扩大可检测的范围，扩展静态分析的功能，并识别缺陷，而不仅仅是一些弱代码。但是它仍然遭受误报。静态分析已经改变了用户的注意力，从强化代码到寻找错误，这是很棒的，但是现在人们进行静态代码分析时遇到的最常见障碍之一就是试图弄清他们得到的结果。

尽管人们确实说“我希望静态分析能够捕获____”（将您喜欢的无法找到的错误命名），但听到“哇，我得到的结果太多了！”的说法更为常见。或“静态分析很吵！”或“静态分析中误报率很高！”因此，作为软件测试组织，我们的工作是继续为客户解决该问题——继续提供工具和功能，以帮助您对所获得的结果进行排序，并了解哪些风险最大。

静态分析中的误报是什么？

在静态分析的上下文中，当静态分析工具错误地报告违反了静态分析规则时，就会出现“误报”。当然，这可以是主观的。有时，开发人员陷入了将任何他们不喜欢的错误消息标记为“误报”的陷阱，但这并不是真的。在许多情况下，他们只是不同意该规则，他们不了解该规则在这种情况下的适用方式，或者他们认为该规则通常不重要（或在这种情况下）。我称之为噪音，而不是误报。我在这里发现的有趣之处在于，该工具越聪明，就越有可能产生开发人员乍看之下可能无法理解的发现。

基于模式的分析中的误报

基于模式的静态分析实际上没有误报。如果该工具报告实际上没有违反静态分析规则，则表明该规则存在错误（因为规则不应含糊不清）。如果该规则没有明确的模式可寻，那就是错误的规则。

我并不是说每个报告的违反规则都表明存在缺陷。违反仅表示找到了模式，表明代码有缺陷，容易产生缺陷。

当我查看违规时，我会问自己这个规则是否适用于我的代码。如果适用，我会修复代码。如果没有，我将禁止违规。最好直接在代码中禁止违反静态分析的行为，以便团队成员可以看到它，而不必再次进行审查。否则，您将不断地反复审查相同的违规行为；这就像尝试拼写检查，但切勿在字典中添加“特殊”字词。代码内抑制的优点在于它独立于静态分析引擎。任何人都可以查看该代码，并查看该代码已被审查，并且该模式在该代码中被视为可以接受。如果您需要证明符合编码标准，则此功能特别有用。而且，如果确实需要合规性，则可以轻松地将现有配置用于这些标准，例如CWE，MISRA，IEC 62304，DO-178B/C等。

基于流的分析中的误报

使用基于流的分析，误报不仅是方法固有的，而且是相关的，因此需要加以解决。流分析无法避免误报，原因与单元测试无法生成完美的单元测试用例相同。分析必须确定代码的预期行为。有时候，太多的选择无法知道什么是现实的。有时，您只是根本没有足够的信息来了解系统其他部分的情况。

这里重要的是，真正的误报是完全错误的。例如，假设您使用的静态分析工具说您正在读取空指针。如果您看一下代码，发现实际上是不可能的，那么您肯定会误判。

另一方面，如果您根本不担心代码中的空值（因为它们是在其他地方处理的），那么该消息（虽然对您并不重要）也不是错误的肯定。这是真的，而且碰巧并不重要。来自流量分析工具的消息的范围从“真实和重要”到“真实和不重要”，“真实和不可能”到“不真实”。这里有很多变体，每种变体的处理方式应不同。

这里也有一个常见的陷阱。就像上面的null示例一样，您可能会认为null值无法做到这一点，但是该工具找到了实现它的方法。如果对您的应用程序很重要，请确保进行检查并可能对此加以保护。

了解流量分析既有力量又有弱点，这一点至关重要。流分析的功能在于它遍历代码并尝试查找热点并在热点周围发现问题。缺点是必须假设才能尝试遍历代码，并且遍历得越远，产生可能性越大的可能性就越大。

真正的问题是，如果您开始认为由于流程分析是干净的而已经清理了所有代码，那么您就在自欺欺人。确实，您发现了一些错误，对此深表感谢。缺少流分析错误只是意味着您一无所获，而不是代码很干净。如果您要构建对安全至关重要的软件，则最好确保使用的是C/C++test，dotTEST或Jtest之类的工具，同时具有两种类型的静态分析

运行时错误检测

补充流分析的一种很棒但通常被忽略的方法是运行时错误检测。运行时错误检测可以帮助您发现比流分析所能发现的复杂得多的问题，并且您可以确信情况确实发生了。运行时错误检测不会像静态分析那样具有误报率。当发现缺陷时，是因为它实际上观察到了它在执行过程中发生的情况-没有涉及任何假设。

您的运行时规则集应与静态分析规则集紧密匹配。规则可以发现相同类型的问题，但是运行时分析具有大量可用的执行路径。这是因为在运行时，存根，设置，初始化等对于流分析的方式都没有问题。唯一的限制是它只能与您的测试套件一样好，因为它会检查您的测试套件恰好执行的路径。如果您使用C或C++进行编程，尤其是在IoT等嵌入式设备中，请查看Insure++——它在运行时发现的错误比其他任何工具都多。您可以在运行时准确地找到它们，而不必陷入诸如线程问题，内存泄漏和竞争条件之类的棘手问题中。

值得吗？

我对误报的处理方法是：如果要花3天的时间来修复错误，则最好花20分钟的时间来检查误报…只要我可以标记它，而不必再次查看它。在正确的背景下查看它是一个问题。例如，假设您有线程问题。线程问题极难发现。如果要查找与线程相关的问题，可能需要花费数周的时间才能对其进行跟踪。我希望编写代码时不会出现任何问题。换句话说，我试图将我的过程从发现转向预防。 

如果部署正确，则静态分析不一定会带来嘈杂的令人不愉快的体验。看看我们在Parasoft的工作方式有何不同，特别是利用Parasoft DTP的全部功能通过智能分析来管理结果，使您始终专注于软件中的风险，而不是追逐不重要的问题。