Coverity每次向Stream提交完整分析结果后都会形成Snapshot，连续快照能够反映缺陷在不同代码版本中的出现和消失。真正容易混淆的是，快照中的“存在/不存在”、Coverity自动计算的缺陷状态，以及人工设置的Classification、Action等Triage属性并不是同一套概念。处理“Coverity怎么比较不同分析快照，Coverity快照对比时缺陷状态不一致如何检查”时，需要先确认比较的是同一个CID，再判断差异来自检测结果还是Triage数据。

　　一、Coverity怎么比较不同分析快照

　　Coverity Connect提供Snapshot Comparison，用于判断某个CID在指定快照范围中是否存在。比较完成后还可以继续通过筛选条件缩小结果，例如只查看新出现或已经消失的缺陷。

　　1、进入需要比较的快照

　　①登录Coverity Connect，进入对应Project。

　　②打开【Snapshots】视图，确认待比较的两个Snapshot属于预期的Stream和代码版本。

　　③选中较新的Snapshot，在右侧查看提交时间、提交用户、Build Details和Analysis Details，先确认没有选错分析结果。

　　④打开右侧的【Snapshot Comparison】，准备设置比较范围。

　　Coverity的Snapshots视图可以查看项目中的快照，并提供快照提交信息、构建信息、分析信息和快照比较入口。

　　2、设置两个快照的比较范围

　　①在【Show】中指定作为当前结果基础的Snapshot。

　　②在Comparison范围中选择需要作为基准的旧Snapshot。

　　③应用比较后进入【Issues:By Snapshot】结果页。

　　④在筛选条件中加入【Comparison】，分别查看【Present】和【Absent】。

　　其中【Present】表示CID存在于Show范围，同时也至少存在于一个比较快照；【Absent】表示CID存在于Show范围，但没有出现在任何比较快照中。利用这两个值可以进一步整理新增、持续存在或不同版本之间发生变化的问题。

　　3、保存需要长期使用的比较结果

　　①在比较结果中继续加入【Checker】【Classification】【Severity】【Component】等条件。

　　②删除与当前排查无关的过滤项，确认CID数量符合预期。

　　③使用【Save as Copy】保存当前未保存视图，并填写简短、明确的名称。

　　④后续重新分析后继续使用相同规则，便于比较版本之间的变化。

　　二、Coverity快照对比时缺陷状态不一致如何检查

　　看到同一个问题在不同页面显示为不同状态时，不要先修改Classification。首先要确定差异字段究竟是Comparison、Status，还是人工维护的Triage属性，因为它们的产生方式不同。

　　1、区分Comparison和缺陷Status

　　①在【Issues:By Snapshot】中显示【CID】【Comparison】【Status】等列。

　　②找到状态异常的CID，分别记录两个快照中的出现情况。

　　③如果差异只发生在【Comparison】，检查两个快照的检测结果，不要修改Triage属性。

　　④如果显示为Fixed等状态，则继续确认该CID在后续快照中是否已经不再被检测。

　　Coverity说明中，用户并不直接设置CID的Status；New、Triaged、Dismissed和Fixed等状态由Coverity Connect确定，而Comparison只是描述CID在比较范围中的存在或缺失。

　　2、检查Classification和Action是否来自不同Triage Store

　　同一个CID并不一定在所有Stream中拥有完全相同的人工处理结果。每个Stream都会关联一个Triage Store；共享同一个Store时，相同CID共享Triage值，使用不同Store时则可以分别设置Classification、Action等属性。

　　①打开异常CID，记录当前【Classification】【Severity】【Action】和【Owner】。

　　②查看该CID的Triage History，确认这些属性最近由谁、在什么时间修改。

　　③检查两个快照所属Stream分别关联哪个Triage Store。

　　④如果两个Stream使用不同Store，再比较两个Store中的CID属性，而不要直接认为快照状态发生了错误。

　　3、检查Stream是否更换过Triage Store

　　更换Stream关联的Triage Store后，CID会采用新Store中已有的Triage值；如果新Store中从未处理过该CID，则会使用默认值，因此可能出现之前已经分类、切换后重新显示为默认状态的情况。

　　①进入Triage Store管理区域，确认当前Stream的关联关系。

　　②检查近期是否调整过Stream与Triage Store的绑定。

　　③对照发生变化的时间点与快照提交时间。

　　④发现关联发生变化时，以目标Triage Store中的历史记录作为判断依据。

　　三、怎样快速定位真正发生变化的原因

　　快照对比的重点不只是统计缺陷数量，还要判断“代码已经修复”“本次没有被分析到”和“Triage信息发生变化”这几种情况。它们最终可能都会表现为列表数量不同，但处理方式完全不同。

　　1、围绕同一个CID做纵向核对

　　①从异常记录中选取一个CID，打开Issue详情。

　　②查看Detection History，确认该CID在哪些快照中出现。

　　③再查看Triage History，确认Classification、Action和Owner是否发生过人工调整。

　　④返回Snapshot Comparison，核对该CID在两个目标快照中的【Present】或【Absent】结果。

　　Coverity在Issue详情中提供Detection History、Triage History和Occurrences，用于结合检测历史与人工处理记录判断问题状态。

　　2、排除分析范围发生变化

　　①对比两个Snapshot的Build Details和Analysis Details。

　　②检查源码范围、构建目标和分析配置是否一致。

　　③如果大量CID同时消失，而代码修改量很小，优先确认本次分析是否覆盖了原来的文件和组件。

　　④分析条件一致后，再把CID的缺失判断为更可信的代码变化结果。

　　这一步属于基于Coverity快照所记录构建与分析信息进行的排查判断；Snapshot本身提供这些详情，可用于识别两次分析输入是否具有可比性。

　　总结

　　Coverity怎么比较不同分析快照，核心是通过Snapshot Comparison确定同一CID在不同分析结果中的存在关系；Coverity快照对比时缺陷状态不一致如何检查，则必须进一步区分Comparison、系统Status和人工Triage属性。尤其在多Stream、多分支项目中，Triage Store的关联方式会直接影响Classification、Action等处理结果。把CID检测历史、Triage历史和快照分析范围结合起来核对，才能判断缺陷是真的修复、暂时未被检测，还是仅仅换了一套Triage数据。希望本文对大家进行Coverity版本缺陷追踪有所帮助，如需进一步了解Coverity分析快照比较与缺陷状态不一致的排查方法，欢迎联系咨询。