【问题标题】:coverity static code analysis across branches/projects跨分支/项目的覆盖率静态代码分析
【发布时间】:2014-06-19 08:36:41
【问题描述】:

我们有跨多个分支维护的产品代码。我们想对所有分支分别运行 Coverity 分析。 由于所有分支上的大部分代码都是相同的,我想将一个分支的分析结果用于另一个分支。 所以这里的问题是..我们可以关联 Coverity Connect 中不同项目的两个快照吗?这样对于创建的任何新分支,我都可以将其与之前分支快照的分析结果进行比较。

【问题讨论】:

  • 你有什么理由相信收集到的关于一个分支的事实对另一个分支是正确的?示例:分支 1:int x[7];我=5; x[i]...;显然没有下标错误。分支 2:int x[7];我=8; ...如果您假设分支 2 没有基于分支 1 属性的下标错误,您将得到错误的答案。 一个字符的变化可以从根本上改变软件系统的属性。
  • @Ira Baxter - 实际上,您可以跨分支进行很多干扰,毕竟大多数代码都是相同的。您还可以列出两个分支共有或唯一的缺陷列表。
  • @MarkRobinson:是的,defects 可以有效地跨越分支。在一个分支的某个地方诊断出错误提示另一个分支的那个地方可能存在相同的错误。而且,如果你看错了,你只会浪费一点时间。不正确的是,一个分支中的某个位置 absence 错误是一个很好的暗示,即在另一个分支中该位置没有错误,正如我的简单示例旨在显示的那样。因此,您需要非常小心跨分支进行的推理。
  • @Ira Baxter,哦,绝对的,你不能证明一个缺陷是固定的,因为它在另一个分支中丢失了。毕竟,C、宏和平台特定构建的世界仍然存在。另一方面,如果我们添加时间的维度,我们可以做一些有趣的事情。如果仅存在于 v2.0 中,我们可以推断该缺陷已在 v2.1 中修复

标签: static-analysis coverity


【解决方案1】:

是的,你可以。

跨分支/项目比较缺陷不是一流的操作,但可以使用 Web 服务接口(覆盖连接)来完成。

使用last() 的快照范围获取项目A 的缺陷,然后也使用last() 获取项目B 的缺陷。现在你需要一些集合操作,如果你使用合并键字段加入集合,这很容易。

所以A intersect B 上的merge key 会在两者中产生缺陷, A - B on merge key 只会在 A 中给出缺陷。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-05-31
    • 2012-01-11
    • 2014-03-08
    • 2019-12-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-07-08
    相关资源
    最近更新 更多