如何处理静态分析仪输出

Question

我们已开始在代码库中使用静态分析器（Coverity）。我们收到了大量的警告（数十万），我们很快就被惊呆了，整个团队需要几个月的时间才能清除所有这些警告（一点也不可能）。

我们到目前为止讨论的选项是

1）雇用承包商来整理警告并修复它们 - 他的缺点是：我们可能需要非常经验的人来做所有这些修改，并且没有承包商需要理解代码。

2）过滤掉警告并仅处理危险警告 - 这里的问题是我们的静态分析输出总是被警告混乱，使我们难以隔离问题。过滤警告也是一项重大努力。

无论哪种方式，将我们的代码置于静态分析器对我们来说是一个有用工具的状态似乎是一项艰巨的任务。

那么如何在不将当前的开发工作强化到一个完整的支架的情况下使用静态分析器怎么样呢？

Answer 1

每周一天：开启分析;挑选100个最烦人的警告;解决它们;关闭分析。简而言之：不要惊慌;你的代码按原样运行（不是吗？）;以一口大小的方式处理警告。

如果您发现相同类型的警告再次出现（错误的编码习惯），请教育您的团队以后避免使用它们。

我用一个旧的代码库做了这个：我早上进入（在团队的其他成员之前），在编译器上调高警告/分析级别，修复一些警告，然后将其设置回默认值。

Answer 2

1. 对于遗留代码。优先考虑这些漏洞错误并制定计划来处理它们。平衡错误修复和新功能开发。新功能总是更重要。
2. 新代码。使其成为整合过程的一部分：在签入新代码之前，确保它们没有覆盖。

Answer 3

要做的第一件事就是调整分析设置; Coverity支持可能会给你一个相当通用的配置。

• 对缺陷的代表性样本进行分类，如果检查器似乎没有产生比噪声更多的信号，请暂时将其关闭。 （Coverity的大多数跳棋都很好，但是没有人是完美的，听起来你需要做一些无情的优先排序。）
  • 从长远来看，将其中一些检查器重新打开，但在报告中将它们标记为低优先级。 （这比应该的更难;我一直认为Coverity需要读一些名为Dawson Engler的人关于缺陷排名的论文。： - ）
  • 在更长的时间内，尝试默认禁用的检查程序;其中一些人发现了令人印象深刻的错虽然你确实需要关闭一些虚假的警告，但是解析警告非常有用。
• 对于您实际上即将修复的代码库的哪个部分，请保持冷嘲热讽。使用组件跳过对您不会修复缺陷的代码的分析，至少目前是这样。 （例如，从理论上讲，如果您的产品包含第三方代码，那么您应对其质量负责，并且应修补其中的错误。在实践中，此类错误很少得到修复。如果它是成熟的第三方代码，则为假积极率会很高。）
  • 设置组件和排除是很棘手的，但一旦完成，它们运行良好 - 我的一个负面的前瞻性正则表达式有超过一百个析取。
  • 组件也有助于为缺陷分配个人责任，我发现这对于修复缺陷至关重要。
• 仅为新缺陷设置报告，让人们观看该网址。新的缺陷存在于活动代码中，并且更容易开始使用“无新警告”策略。

让我以几个免责声明结束：

• 您可能想在Coverity支持论坛（http://forums.coverity.com/）中重新提出这个问题，该论坛不是非常活跃，但我们不必担心违反NDA。我在那里找到了我认为值得启用的跳棋列表。

• 我这样做是为了谋生，也许你想聘请我们（http://codeintegritysolutions.com/）;我今天在斯坦福大学就这个问题发表演讲。聘请顾问进行调整很有意义;在公司外面有人做分类是比较棘手的。有一个局外人做修复工作仍然比较棘手;从错误中吸取教训比修复错误更重要。

  • 我在斯坦福大学的一些演讲中对我们的企业博客http://codeintegrity.blogspot.com/2010/01/handling-embarrassment-of-riches.html进行了一些扩展。

Answer 4

对于您的承包商选项，您可能会采用更温和的方式，让他们只修复明确的问题，本地问题并且不需要完全了解您的代码。我猜想大量的Coverity命中是可能的NULL指针解引用或可能的写入超过缓冲区的末尾，可以通过简单的检查来解决，这些检查完全是有问题的代码本地的，并且不需要理解大图。

我承认 - 在使用preFAST / preFIX或者微软调用的工具之前，我已经完成了这样的工作，其中很多都是机械式的变化。非常适合承包商或甚至实习生。但是会有一些东西需要更多的分析 - 只要确保承包商明白他们不应该试图深入研究。

对他们好一点 - 这是苦差事，所以做任何你可以愉快的事情。

Answer 5

人们告诉我们，第一次使用它时，我们会“忽略”所有警告。然后在下一个差异构建中，它会逐渐增加新的警告：你应该修复它。然后，在您使用该工具几个月后，您会对它感到满意，然后返回并开始修复旧的警告。

Answer 6

尝试其他静态分析仪。我曾经使用过Parasoft C ++ Test，它有一种方便的方法可以根据严重程度过滤警告。

Answer 7

这是否意味着您在根据自己的需求定制时遇到问题？ 正如

“”可自定义分析

Coverity Static Analysis提供了通过修改部署的检查器数量或特定于单个检查器的设置（例如空指针解除引用的阈值）来微调分析的功能。为特定代码块或应用程序配置Coverity的功能允许开发人员选择最适合其应用程序的性能级别，从而获得更准确可靠的结果。 Coverity软件开发工具包允许您通过创建自定义检查器来检测C和C ++代码中的唯一缺陷类型。除了创建用于查找并发性，异常处理和其他关键问题的自定义检查器之外，还可以使用此功能。“” http://www.coverity.com/products/static-analysis.html

Answer 8

Coverity的典型开箱即用分析配置将倾向于每千行代码提供一到三个缺陷。如果您有数十万个缺陷，并且您的代码行数远远少于1亿行，我可以保证您的分析配置不正确或对您的组织而言不是最理想的。

除了调整分析配置本身，您还可以通过影响确定优先级 - 默认的“高”，“中”和“低”映射应该足以让您开始，直到您了解哪些子类别倾向于对你的应用程序最具破坏性。

第三，如果您的代码库很大（并且不是），则将其细分为组件，以便每个团队或开发人员组只能查看他们直接维护的代码 - 这样可以使更多可管理的工作块处理，它还允许您优先考虑组件（服务器代码中的缺陷比客户端代码中的缺陷，测试代码或第三方代码等更重要）。