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

　　一、Coverity怎么做快照对比

　　Coverity里面的快照，大致可以把它理解成某一次分析被提交上去之后留下来的那组结果记录。在动手做对比之前，需要先指定好一条基准快照和一条目标快照，通常会用上一个发布版本的那条快照来对比当前的这一版。

　　1、先进到项目或者Stream里面去

　　用你的账号登进Coverity Connect之后，找到并进入对应的项目，然后再去定位到需要分析的那条Stream。不同分支、不同版本最好是能用清楚的命名来区分，比如main分支、release分支、feature分支，别让那些不相干的快照混在一块儿去比较。

　　2、把快照的列表给打开

　　在Stream的那个页面里面，找到Snapshots或者名字差不多的快照列表入口，点进去就能看到每一次分析提交的时间、构建的编号、是谁提交的，还有当时含有多少问题数量。在正式开始之前，要先确认好用作基准的那条旧快照，和拿来当目标的这条新快照，都已经分析完了，状态还挂着异常的快照，可不能拿它来当对比的参照物。

　　3、去选好这次要比对的两个对象

　　在列表里先挑出一条历史的快照，把它设成Baseline，然后再把当前最新的这条快照设成Target。比的时候，重点去看新冒出来的缺陷、消失不见了的缺陷、两次比对里都没有变化的缺陷，还有审计状态发生过改变的那些记录。不过得留个心，如果这两次扫描的代码范围不一样，那比出来的差异就只能算是个参考，不能直接把它拿来当成质量变化的实锤。

　　4、结合过滤条件再去查看结果

　　进到缺陷列表以后，可以按照问题的检查规则、严重级别、文件所在的路径、所属的组件、负责人，还有当前的状态去一层层地筛。那些新冒出来的高风险问题，应该往前排，优先去看，至于那些历史遗留下来的问题，就照着原来的整改计划，按部就班地去处理。

　　二、Coverity快照差异结果怎么看

　　快照之间的差异，并不是简单地去算一个“多了几个问题”或者“少了几个问题”。得把它跟代码的变更、规则本身的变化，还有分析范围是不是一样，这些东西绑在一块儿去看。

　　1、去看一眼新增出来的问题

　　新增的问题，说的就是当前这条快照跟基准快照比起来，多出来的那些缺陷。先去翻一翻影响程度高和置信度也高的那些问题，然后再去看它们是不是集中出现在了某个特定的模块，或者集中在某一次代码提交里面。如果新增的问题主要是扎堆在新增代码的目录底下，那就说明它们跟这一轮的开发改动关系比较大。

　　2、去查一下已经被修掉的问题

　　已经被修掉的问题，就是指在基准快照里面还存在，但是到了当前这条快照里已经找不到了的那些缺陷。到了这一步，一定得去确认一下，这些问题的消失，到底是因为代码真的被修好了，还是因为相关的文件这次压根儿就没被扫到，或者是因为文件的路径变了，又被或者是哪条扫描规则被关掉了，才让问题看起来像是没了一样。

　　3、去翻一翻那些没发生变化的问题

　　没有发生变化的问题，说明在前后两条快照里它都是一直存在的。这些缺陷倒不一定本身就优先级很低，只是没有赶在这一个版本里面去解决掉它而已，后面可以再结合它的严重级别、影响的范围，还有客户那边的具体要求，来拿主意要不要把它排进后续的整改计划里面去。

　　4、去注意一下问题状态的变化

　　同一条缺陷，它的审计状态有可能从还没被分类，变成了已经被确认，也有可能从等待处理的状态，被判定成误报，或是被标记成了有意保留的风险。在做快照对比的时候，要多留一双眼睛去盯着这些状态的变动，可别光顾着数缺陷的数量，却把背后审计人员下的结论给忽略掉了。

　　三、Coverity快照差异结果怎么导出

　　在把差异的结果往外导以前，得先把过滤的条件给设好了。导出来的这张表格，最好是只装着这一次需要拿去沟通，或者需要着手整改的那些内容，别不管不顾地把全部的历史问题都给一股脑儿倒出来。

　　1、先去把这次差异的范围给筛好

　　在缺陷的列表里面，按照当前快照和用来对比的那组条件去筛，比如只筛新增的问题、只筛某一个严重级别、只筛指定的组件或者指定的负责人。等把这些条件都过了一遍筛子，确认出来的结果是自己想要的，然后再去执行导出，这样后面丢到Excel里再去整理的时候，工作量就会轻很多。

　　2、去用一下导出的功能

　　在结果列表的那个页面上，去找一找Export、Download或者Report这一类按钮，然后用它把当前列表里筛好的内容，导出成CSV或者Excel格式的文件。导出的那些字段里面，建议把CID、检查规则、严重级别、文件路径、函数名、当前的状态、负责人、这个问题第一次是出现在哪条快照里的，还有当前这条快照的信息，这些都给带上。

　　3、如果需要拿去做项目评审

　　那就再专门导出一份问题报告，或者是按组件拆分开来的摘要报告。在报告里面，最好是能把新增的问题、已经被修复的问题，还有那些遗留的问题，分开来列，不要全搅在一张表里面去讨论。

　　４、把这次对比所用的口径给留在文件名里

　　给导出的文件起名字的时候，最好能把项目的名字、Stream的名字、基准快照是哪一版、目标快照是哪一版，还有导出的日期都给写清楚。比如可以写成coverity_releaseA_vs_releaseB_new_issues这样，等到后面再回过头来复盘的时候，一眼就能看出来这份表到底是按什么标准生成的。

　　总结

　　在做Coverity的快照对比时，先要在同一条Stream底下去挑好用作基准和目标的两条快照，然后再按照新增、已修复、没有变化，还有状态发生了变化这几种情况，去把差异给看明白。往外导数据以前，一定要记得先把过滤的条件给设好，只把这次真正需要拿去整改，或者需要向上汇报的问题给筛出来。快照之间比出来的差异结果，只有在扫描的范围、规则的配置，还有构建的环境都基本保持不变的条件下，才适合被拿来当作代码质量变化的判断依据。