Coverity分析快照的对比这件事，还有如果对比出来的结果差异太大，该怎么处理，在做版本质量复查的时候，是经常会碰到的。快照对比，它不是只去看缺陷的总数是多了还是少了，而是要先去看一看这两次分析，是不是都在同一个项目里面、用的是不是同一个流、环境是不是同一套、规则是不是同一套，才能去比的。只要扫描的范围有了变化、规则集有了变化，或者路径有了变化，那对比出来的差异就会被放大。所以做判断之前，要先把对比的口径给固定下来，然后再分开去看新冒出来的问题、还留在那里的问题，还有已经不见了的问题，这样得出来的结论，才更有把握一些。

　　一、Coverity分析快照怎么对比

　　对比之前，需要先弄明白这次对比的目的，是想看提交的影响，还是想看版本的质量，又或者是想去排查扫描的异常情况，因为目的不一样，选哪两个快照来对比，也是不一样的。

　　1、先要把项目和流确认下来

　　进到项目里面以后，要先去看一下当前的流，是不是对应着要看的那个分支，然后再去对照构建的任务、版本号和提交的记录，把范围给确认好。一个项目底下可能会有好几个流，主干的流和发布分支的流，它们包含的代码是不一样的，历史的缺陷也不一样，不能把两个流的快照拿到一起比，否则新问题、老问题和消失的问题都会搅和到一块儿去。

　　2、然后要去选基线快照和目标快照

　　打开了快照的列表以后，要先挑一个跑得比较稳定的扫描结果来当基线，然后再去选当前需要复查的那个目标快照。用来当基线的快照，最好是完整构建和完整分析得出来的，不要去找那些构建都失败了，或者是代码没有抓全，再或者是临时改过规则的扫描结果。如果是要看一次代码合入的影响，那就可以选合入前和合入后的两个快照；如果是想看版本发布的质量，那就选上一个发布版本和当前候选的版本。

　　3、要把新问题、老问题和消失的问题，分开来

　　通过缺陷的视图去筛选状态，把结果拆成新冒出来的问题、还是没有被修掉的问题，还有在当前快照里面已经看不到了的问题。新问题通常是要在这一轮里面去修掉或者去评审的，老问题就要看它的负责人和修复的计划，消失的问题不能直接就说它已经被修好了，还要去确认一下对应的那些文件，是不是还在被扫描的范围里面。

　　二、Coverity快照对比结果差异过大怎么办

　　如果对比出来的差异很大，先不要马上就下结论，觉得是代码质量一下子变差了很多。静态分析跑出来的结果，跟构建时的代码抓取、规则的开关、源码的路径，还有组件的映射，这些东西都是有关系的。排查的时候，最好是先去看扫描的条件，然后再去看代码本身的改动。

　　1、检查构建时抓取的范围

　　要对着构建的日志和cov-int那个目录，去看看这两次扫描，抓的是不是同一批模块、同一套target和同一批源文件。要是有一次少扫了某个目录，那么跟这个目录有关的缺陷，自然就会一下子全都不见了；要是多扫了以前没有扫过的模块，那问题的数量也就会突然多出来。做嵌入式项目的时候，一个平台的宏、一个驱动模块的变化，都可能会让Coverity看到不一样的代码路径。

　　2、核对规则集和分析的参数

　　要进到分析配置里面，或者去看扫描的脚本，去确认这两次扫描用的checker、严重级别、建模的文件，还有分析的选项，这些东西是不是都一样的。规则集一变，结果的数量就会跟着变，如果最近升级过Coverity的版本，工具版本的变化也要单独去记下来，不能把所有的差异都算到代码的改动头上。

　　3、排查路径和组件的映射

　　要结合文件的路径、组件的映射，还有代码仓库的记录，去看一看这些差异，是不是都集中在了那些被搬过的目录、被改过名字的模块，或者是新建的组件上面。有时候代码只是挪了一个位置，问题就被重新识别了一遍，结果看起来新增的缺陷就特别多；有些项目调整了组件归属的规则，原来算在公共库头上的问题，一下子划到了业务模块下面，统计出来的结果也会变化很大。碰到这种情况，就要把路径的变化，和真实的代码缺陷，给区分开。

　　三、Coverity快照对比结果怎么复核

　　对比完了以后，还需要再复核一遍，复核不是说把所有的问题都重新看一遍，而是要把这些差异，按照来源分一分类，看看哪些是真的需要开发的去动手的，哪些是因为扫描条件变了才出现的，哪些是还需要再确认的。

　　1、优先去复核新增的那些高风险问题

　　把新增的问题筛出来以后，要按照严重的级别、checker的类型和组件的归属，去排一个序，那些高风险的、落在核心模块里面的、跟本次提交直接挂钩的问题，要优先去看。如果新增的那些问题，都集中在了同一类的事情上面，比如资源释放、空指针的判断、数组的边界，或者是错误处理的逻辑，那就先把共同的原因找出来，不要一条一条地分散去处理。

　　2、确认消失的问题是不是真的修掉了

　　对于那些消失的问题，要结合提交的记录、扫描的范围和规则的配置，一起去看，不能直接就写个已修复。只有当对应的文件还待在扫描的范围里面，而且代码里面也确实有为了修它而做的提交时，才算得上是解决了。如果只是文件没被抓到、模块没编译、规则被关了，或者路径变了，那只能说这次快照里面没有再看到它，不能代表风险就已经没有了。

　　3、把以后对比的口径固定下来

　　要把基线快照、目标快照、流的名称、构建的入口、规则集的版本，还有扫描的时间，这些东西都记下来，以后每一次做版本复查的时候，都照着这个口径来，差异就更容易说得清楚。如果要给项目组看，可以把结果整理成新增问题、遗留问题、已消失问题，还有需要复核的问题，这样四类，研发、测试和项目负责人看起来会更清楚一些，跟踪修复的进度也会更方便。

　　总结

　　Coverity快照怎么对比，差异太大的时候又该怎么办，最要紧的就是先把对比的那个标准给定下来，然后再去分析缺陷为什么会变。对比的时候，要确认项目、流、基线快照和目标快照都是对得上的，再把新增、遗留和消失的问题分开来看；差异太大的时候，就要按照顺序去检查构建抓取的范围、规则集、分析的参数、路径的变化，还有组件的映射这些东西。只有确认了这两次快照，是在相同或者可以说得通的扫描条件下得到的，对比出来的差异，才好拿去判断代码质量到底变了多少、版本的风险有多大，还有修复走到了哪一步。