如何处理静态分析器的输出

StackOverflow https://stackoverflow.com/questions/2070397

  •  20-09-2019
  •  | 
  •  

题

我们已经开始在我们的代码库上使用静态分析器（Coverity）。我们很快就被收到的警告数量之多（数十万）惊呆了，整个团队需要几个月的时间才能清除所有警告（显然是不可能的）。

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

1）聘请承包商来整理警告并修复它们 - 他的缺点：我们可能需要非常有经验的人来完成所有这些修改，并且承包商不需要了解代码。

2）过滤掉警告并只处理危险的警告 - 这里的问题是我们的静态分析输出总是会被警告弄乱，这使得我们很难隔离问题。另外，对警告的过滤也是一项重大工作。

无论哪种方式，使我们的代码达到静态分析器对我们有用的工具的状态似乎是一项艰巨的任务。

那么如何才能在不使当前的开发工作陷入完全停滞的情况下使用静态分析器呢？

有帮助吗？

解决方案

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

  • 对缺陷的代表性样本进行分类，如果检查器似乎没有产生比噪音更多的信号，请暂时将其关闭。（Coverity 的大多数跳棋都很好，但没有人是完美的，听起来你需要进行一些无情的优先级排序。）
    • 从长远来看，重新打开其中一些检查器，但在报告中将它们标记为低优先级。（这比应有的困难；长期以来，我一直认为 Coverity 需要阅读 Dawson Engler 撰写的几篇有关缺陷排名的论文。:-)
    • 从长远来看，请尝试默认禁用的检查器；其中一些人发现了令人印象深刻的错误。解析警告非常有用，尽管您确实需要关闭一些虚假警告。
  • 对于您实际上将很快修复代码库的哪一部分，要保持现实的态度。使用组件来跳过对您不打算修复缺陷的代码的分析，至少现在是这样。（例如，理论上，如果您的产品包含第三方代码，您就对其质量负责，并且应该修补其中的错误。实际上，此类错误很少得到修复。而且如果是成熟的第三方代码，误报率会很高。）
    • 设置组件和排除是很棘手的，但一旦完成，它们就可以很好地工作——我的一个负向前瞻正则表达式有一百多个析取项。
    • 组件还有助于分配缺陷的个人责任，我发现这对于修复缺陷至关重要。
  • 仅针对新缺陷设置报告，并让人们查看该 URL。新缺陷存在于活动代码中，并且更容易开始使用“无新警告”策略。

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

  • 您可能想在 Coverity 支持论坛中重新提出此问题 (http://forums.coverity.com/），这不是很活跃，但我们不必担心违反 NDA。我在那里列出了我认为值得启用的检查器。

  • 我以此为生，也许你想雇用我们（http://codeintegritysolutions.com/）；我今天将在斯坦福大学就这个主题发表演讲。聘请顾问进行调整非常有意义；让公司外部的人进行分类会比较棘手。让外部人员来修复问题就更棘手了；从错误中吸取教训比纠正错误更重要。

其他提示

一天一个星期：打开数据;挑100个最讨厌的警告;解决这些问题;把分析过。简而言之：不要惊慌;你的代码的工作，因为它是（不是吗？）;通过在一口大小的块的警告工作。

如果您发现相同类型的警告不断重现（坏的编码实践），教育你的团队，以避免他们的未来。

我这样做是与旧的代码库：我会得到在清晨（该团队的其他成员之前），杀青编译器警告/分析水平，修复了一些警告，然后将其设置回的默认值。

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

有关你的承包商的选择，你可能会去一个更温和的路线中有他们唯一的解决方法是明确的，局部的，不需要你的代码有充分的认识问题。我猜想，大量的Coverity的匹配都喜欢的东西可能的空指针引用或可能写入超出了缓冲区的结尾，可以固定简单的检查是完全地方有问题的代码和不需要的理解大图。

我承认 - 我做了这样的工作，使用的PREfast /前缀或任何工具从微软调用之前，很多的是机械样的变化。非常适合于承包商或者甚至一个实习生。但会有东西，需要更多的分析 - 只要确保明明承包商（s）表示，他们不应该试图去深入到事物

和善待他们 - 这是苦力工作，所以让其他任何你能愉快

在Coverity的人告诉我们“忽略”的所有警告你使用它的第一次。那么在接下来的差分的建立，将有新的增量警告：你应该可以解决。使用该工具再经过几个月，你会得到舒服你回去开始修复旧的警告。

尝试其他静态分析仪。我用Parasoft的C ++测试工作，它有一个方便的方式根据它们的严重程度来过滤警告。

这是否意味着你必须用它来定制您的需求的问题？结果 如

“” 定制的分析

Coverity的静态分析提供了微调的能力通过修改部署的跳棋的数目，或诸如用于空指针解引用所述阈值特定于单个检验器的设置，分析。配置Coverity的特定代码块，或应用程序的能力，使开发人员能够选择最适合他们应用的性能水平，并导致更准确，更可靠的结果。 Coverity公司的软件开发工具包允许您创建自定义检查器检测到C和C ++代码唯一的缺陷类型。这是除了寻找并发性，异常处理等关键问题创建自定义跳棋。“”点击 http://www.coverity.com/products/static-analysis.html

有关Coverity的典型外的现成分析配置将倾向于每千行代码的一个和三个缺陷之间得到。如果你有几十万的缺陷，你有显著低于100万行代码，我可以保证您的分析配置不正确或不理想的为您的组织。

除了调整分析配置本身，你可以通过影响优先级 - 默认的“高”，“中”，“低”映射应该足以让你开始，直到你感受一下其子类别往往是最损害你的应用程序。

三，如果你的代码是大（且其并不）细分成组件，使开发人员每个小组或团队可以看看只在他们的代码直接维护 - 这使得双方的工作更易管理的块来处理，它也可以让你优先组份（在服务器代码中的缺陷是比在客户端代码，或测试代码或第三方代码等缺陷，更重要的）。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top