随着项目代码规模变大，Coverity的检查结果要是全部堆在一个列表里，后面无论是分派任务还是统计缺陷都会变得很乱。解决这个问题，比较有效的办法是配置组件映射，其实就是按照代码的文件路径把问题自动归类到不同组件下，这样哪个团队该处理哪部分代码就一目了然。Coverity Connect本身支持组件功能，允许用户通过文件规则把源代码文件做逻辑分组，而且在一个组件映射里可以添加多条规则，还能设置这些规则的优先级，让匹配更准确。

在静态代码扫描刚刚接入项目的时候，有一个情况是挺常见的，那就是团队想把某个版本作为一个新的质量起点，后面只盯着新冒出来的问题去看，可是等把基线重建完了，再打开Coverity的页面，发现以前那些旧的缺陷还是能看得见，于是就很容易觉得，是不是基线没有生效，其实，在Coverity里面，基线的调整，更多是影响到问题怎么去对比、新增怎么去判断，还有质量门禁按什么口径来卡，它并不会自动地帮你把历史缺陷都给删掉，所以处理的时候，要先分清楚，“重置基线”跟“清理旧问题”，这是两件不同的事。

在Coverity里分配缺陷，真正要先分清的是“手工指派”和“自动指派”两条线。官方文档里已经把这两层拆开了，一层是在Coverity Connect里通过triage修改缺陷属性，另一层是基于SCM历史和owner assignment rules做自动归属；另外，组件映射本身也支持文件规则和执行优先级，所以缺陷最后落到谁手里，往往不只是点一下Owner，而是规则、组件和SCM三层一起作用。

Coverity里真正影响协同效率的，不是规则扫出了多少条，而是同一条CID在不同团队手里能不能按统一口径流转。官方文档把triage data定义为挂在CID上的处置数据，典型包括classification、action、severity和owner；同时每个stream都要关联一个triage store，用来保存当前和历史处置值。

做Coverity落地时，最容易踩坑的不是“跑不跑得起来”，而是同一套代码在不同人、不同流水线、不同分支上跑出来的结果口径不一致，最后规则集越加越乱、误报越堆越多、开发逐渐不信任报告。要把Coverity用稳，建议把工作拆成两件事：先把“采集构建与提交结果”的配置链路固定下来，再把“规则启用、参数、权限与分流”的管理方式固化为可复用的标准动作。

在Coverity里，分析流这个概念通常对应着一个具体的代码分支、一条版本线，或者某个固定的构建入口；所以一个项目底下往往可以挂上好几个不同的stream，比如main主干一个，release发布分支一个，feature特性分支再单独一个，分别用来接收和存放各自的扫描结果。要是对stream的管理不够上心，最容易碰到的问题就是缺陷被稀里糊涂地交到了错误的分支里，修复状态在几个地方看起来对不上，或者同一个CID在不同版本的stream之间根本没办法放在一起比对。Coverity Connect在stream收到新的缺陷数据时，会专门生成一份snapshot，后面所有关于结果的对比，也基本都是围绕着snapshot和stream的范围来展开的。

项目在持续做静态分析的时候，光盯着某一次的扫描结果去看，其实很难说得清整体的质量到底是在变好还是变坏。要搞清楚Coverity里面怎么做快照之间的对比，以及快照差异的结果又要怎么导出来，关键就在于先要确认用来比较的这两份快照，它俩是来自同一个项目、同一条Stream底下的，并且扫描的范围和规则配置，也要尽量保持一样。做快照对比，主要就是去看新增了哪些问题、有哪些已经被修掉了、哪些还一直挂在那里，以及问题的状态发生了哪些变化，不要光去盯着总数的增加或者减少。

在SketchUp、Revit、Rhino这类软件里联动Enscape做渲染的时候，经常会碰到一种情况，模型本身挑不出什么毛病，可Enscape的窗口一打开，画面边缘就感觉发糊，材质上的纹理也不够利索，有灯光的地方甚至还带着明显的噪点，遇到这种事，不能把问题全推到显卡性能上，也不能一上来就把所有参数都拉满，比较稳当的做法，是先分清楚，这种发虚的感觉，到底是分辨率、渲染质量、景深、运动模糊、纹理贴图带来的，还是跟显示器的缩放以及导出时候的设置有关。

很多人看Coverity版本变化时，第一反应都是比总问题数，但这样往往不够准。真正有用的，不是单看这次多了多少、少了多少，而是先把比较范围定住，再看哪些问题是这次新出现的，哪些问题已经在当前快照里消失，哪些只是一直留到了现在。Black Duck官方文档对这件事说得很明确，Snapshot comparison本质上是一种过滤机制，用来用快照选择语法构造比较范围，而不是只给你一个简单的数量差。

看Coverity代码扫描报错时，最容易走偏的地方不是不会看日志，而是把捕获失败、解析失败、分析失败和提交失败混成一个“扫描报错”。更稳的做法是先按阶段拆开，先判断问题出在cov-build、cov-analyze还是cov-commit-defects，再去看对应日志和结果视图。Coverity官方文档本身就是按这几段命令链路来组织排查内容的。

项目里面只要夹杂了第三方库、自动生成的代码、测试用的桩模块，还有那些为了兼容老版本而保留的历史目录，这些内容并不一定都要被Coverity扫进去。这时候我们就得弄明白两件事：Coverity里到底怎么去设置忽略目录的规则，以及当这些规则加好以后，如果发现忽略路径并没有生效，又该从哪些地方开始排查。这里的一个关键，是先分清当前所做的忽略到底发生在整个流程的哪一个阶段。比较常见的处理方式，可以是在代码被捕获之前就直接把它排除掉，也可以在分析环节启动之前再把它移除掉，还可以到Coverity Connect里去用组件映射的办法，把那些我们不打算花精力去管的问题归拢起来。按照Black Duck社区里一些资料的说法，coverity_config.xml里面的skip_file这个配置项，就能够用来排除那些既不想提交发射、也不打算让分析器去碰的文件和目录。

在代码扫描结果评审的时候，经常会碰到这样一类情况，开发的人看到了缺陷，想把它的状态改成误报、已经确认、等着修复，或者是指定给某一个人去处理，可页面上的按钮却是灰色的，又或者点了保存以后，状态压根儿就没有变，其实，在Coverity Connect里面，审计这个操作，它本质上是一种分诊的权限，用户得在对应的流上面，拥有处理问题的权限才行，而且这个流，还必须关联着一个有效的分诊存储库，权限和对象的范围，只要有一个地方没对上，都会出现改不了的情况，按照官方的权限说明，分诊问题的权限，就是用来修改和更新某一个流里面，那些问题的分诊状态的。

在Coverity里做组件映射，真正麻烦的通常不是先建几个组件，而是后面文件到底按什么规则归到哪个组件。官方文档把这个逻辑讲得很直接，Coverity Connect会根据文件的绝对路径去匹配组件映射规则，而且采用的是第一条完整匹配成功的正则表达式结果。换句话说，组件映射不是简单贴标签，而是一套有先后顺序的归属规则。只要这层没理顺，后面缺陷归属、组件报表和责任分发都会跟着乱。

做Coverity时，很多人前面的问题不是不会跑分析，而是项目还没建顺，后面的流、配置文件和上传目标就已经先乱了。Black Duck官方文档把这件事分成了两层，一层是Coverity Connect里的项目和流配置，另一层是分析侧的初始化配置文件，也就是coverity.yaml。更稳的做法，不是先随手跑一遍命令，而是先把项目和流建清，再把初始化参数按上传目标补齐。

看Coverity结果时，最容易犯的错不是不会点界面，而是把检查器名称、严重级别、分类状态和修复优先级混成一件事。更稳的做法是先把单条问题读成一张完整的缺陷卡片，再把同类问题按业务风险和整改成本分层，这样结果才不会越看越乱。Coverity官方把问题查看和分诊都放在统一的Issue triage流程里，严重级别、分类和状态本身也是独立属性。

在Coverity的体系里，每一个被检测出来的缺陷，都会带上一个属于自己的CID编号，这个编号，就是用来标识和跟踪同一类问题的。想要弄明白在Coverity里面怎么去查看一条CID所对应的详细信息，关键就在于先在问题列表的视图里面，把那个CID给定位出来，然后再点进源码的详情页面，去细看它到底是被哪个检查器给揪出来的、触发的完整路径是怎样的、严重级别有多高，以及当前它处在什么样的处理状态之下。按照Coverity文档里的说法，你是可以直接拿这个CID编号去搜索特定问题的；同时也能通过不同角度的视图，比方说按项目、按组件、按问题本身的数据去分组，来把它给筛出来。

在代码静态分析刚刚导入项目的时候，经常会碰到这样一种情况：跑完一遍扫描，列表里面一下子冒出好几百条甚至更多的问题，如果就这么从上往下一行一行地改，很容易就把时间全耗在了那些低风险的告警上，而真正会造成崩溃、越界、资源泄漏，还有安全漏洞的问题，反而被拖到了最后面，一种比较稳当的做法，是先去做一次分层的筛选，然后再按照影响的范围、缺陷的类型、代码所处的位置，还有修起来要花多少成本，来安排处理的先后顺序。

在Coverity里做项目管理时，很多人会把分析流当成一个普通目录来理解，结果前面流已经建了，后面提交、归类和结果查看却总对不上。官方文档对stream的定位其实很明确，它是用来承载某一部分代码基线和缺陷数据的单位，而且必须先有stream，后面才能把分析结果提交到Coverity Connect。也正因为这样，分析流设置和结果查看本来就是一条线，前面流挂错了，后面看到的缺陷、趋势和筛选结果都会跟着偏。

把Coverity接进Jenkins时，真正要先定下来的不是插件装不装，而是扫描入口、构建节点和结果回传三件事。官方资料已经把这条链路拆得很清楚，Jenkins侧可以直接使用Synopsys Coverity for Jenkins插件，流水线里可用的核心步骤是withCoverityEnvironment和coverityIssueCheck；Coverity分析本身则仍然沿着configure、build、analyze、commit这条标准命令链执行。也就是说，Jenkins负责把环境、项目流和触发时机接起来，真正的扫描动作还是落在Coverity的命令行工具上。

Coverity静态分析变慢，通常不是单一命令的问题，而是捕获、翻译、分析和提交这几段链路里，有一段把资源吃满了。官方文档把增量分析、并行分析和并行翻译单独列成性能优化主题，而且明确说明增量分析是通过在同一代码基上复用同一个中间目录来减少重复工作；并行分析则通过`cov-analyze--jobs`这类方式提高吞吐。