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

　　一、Coverity基线怎么重置

　　在动手去重置Coverity的基线之前，要先想明白，这次到底是要解决什么问题，是希望后面的扫描只去统计那些新引入的缺陷，还是想重新把历史的缺陷状态给理一遍，又或者是因为分支、构建脚本、编译环境发生了变化，导致扫出来的结果忽上忽下不够稳定，目标不一样，动手的方式也会跟着不一样。

　　1、先把用来做基线的版本给定下来

　　要挑一个代码的状态比较稳定、构建的脚本也固定下来了、扫描用到的参数也都已经确认过的版本，拿来当这个基线，注意不要在代码频繁往里面合入、依赖的包还在变来变去的时候去重置基线，要不然，到了后面，哪些是新增的问题，哪些是旧的问题，就很难分得清楚了。

　　2、去完成一次干净的扫描

　　在构建的那台机器上，先把旧的中间目录给清理掉，然后重新去跑一遍Coverity的捕获、分析，还有提交这一整套流程，比较常见的顺序是，先让代码编译的过程被完整地捕获下来，再去执行分析，最后把得到的结果提交到对应的那个流里面去，在提交之前，要去确认一下流的名称、项目的名称，还有分支的来源，这些都没有填错。

　　3、到Coverity里面去把快照给确认好

　　登录进Coverity的页面，进到对应的项目和流里面，去查看一下这次提交完之后生成的那个快照的记录，等确认了快照的时间、代码的版本、缺陷的数量，还有构建的信息，这些都跟自己心里预期的一样了，再把这个快照当作后面去对比的一个依据。

　　4、把质量门禁的口径给调整过来

　　如果项目里用到了CI流水线，那就需要同步去改一下门禁的条件，比如，从原来检查全部的缺陷，改成只检查新增的缺陷；从原来压制全量的遗留问题，改成只去拦截那些高风险的、新增的问题，要不然的话，基线虽然是已经重建好了，可流水线那边，还是有可能会照着旧的规则去报错。

　　二、Coverity基线重建后旧问题为什么还在

　　把Coverity的基线重建完之后，发现旧的问题还待在那里，这通常是一个正常的情况，因为那些旧的缺陷，只要还留在当前的代码里面，分析器下一次再去扫描的时候，照样还是会把它们给认出来，并且，很有可能还会继续沿用原来的CID、原来的状态，还有原来处理它的那些记录。

　　1、基线本身并不会自动去删掉缺陷

　　基线能起到的作用，是给后面的扫描提供一个用来比较的起点，它并不等于会把旧的缺陷从系统里面给清空掉，旧的问题它还实实在在地存在于代码里面，那扫描的结果里自然就还会有它，想要让一个问题真正地消失，是需要去把代码修掉，重新再扫一遍，并且确认这个缺陷已经被关闭了才行的。

　　2、旧问题的状态是被保留下来的

　　Coverity是会去跟踪一个缺陷的整个历史的，那些以前被标记成未处理的、已确认的、打算忽略的，或者认为是误报的问题，在重建了基线以后，很可能还是会继续保留着它们原来的那个状态，这么做有一个好处，就是可以避免同一个问题，每次扫描的时候都跳出来变成一个新的问题，但是，它也会给人一种感觉，好像旧的问题并没有被清掉。

　　3、流可能没有切换正确

　　有的时候，团队自己觉得已经把基线给重建了，可实际上提交的时候，还是提到了原来那个流里面，或者是页面上查看的，根本就是另外一个项目下面的流，这就需要去核对一下流的名称、项目的映射关系、提交命令里带的参数，还有页面上筛选的条件，尤其是在好几个分支并行着开发的时候，是很容易看错地方的。

　　4、筛选的条件仍然在显示着全部的问题

　　如果页面上的筛选器，选的一直是“所有没被关闭的问题”，那旧的问题当然是会被显示出来的，这个时候，可以去检查一下过滤器里面，关于问题的状态、严重的级别、被检测到的时间、快照的范围，还有是不是新增问题的这些条件，想要只看基线之后才被引入的问题，那就应该把筛选的口径，切到跟新增缺陷有关的那个条件上去。

　　三、Coverity基线重建后怎样确认是否生效

　　要想知道Coverity的基线到底生效了没有，不能光看页面上是不是还留着那些旧的问题，而是要去看看新增的问题、快照之间的对比，还有流水线的判断，是不是都跟预期的一样，旧的问题还存在，并不代表这次操作就失败了，关键的地方在于，后面新引入的那些风险，能不能被单独地给识别出来。

　　1、拿两次扫描的结果来对比一下

　　可以在基线那个快照生成之后，故意去做一个小范围的测试性改动，专门引入一个能够被识别出来的问题，然后再提交上去扫描一次，去看看它会不会被标记成一个新增的问题，如果这个新增的问题，能够被单独地给列出来，那就说明基线用来对比的那个口径，基本上是能够用的。

　　2、去检查一下旧的问题是不是已经进入了遗留的范围

　　旧的问题，是可以被继续保留在系统里面的，但是，它应该跟新增的问题被区分开来对待，项目组可以把那些历史的问题，放进一份遗留的清单里面，明确地写清楚，哪些是打算后面再去修的，哪些是暂时先接受了的，又有哪些是需要被重新拉出来再评审一遍的，这么一来，就不会因为旧的问题数量太多，反而把那些真正是新引入的问题，给淹没在里头了。

　　3、同步去更新一下团队的说明

　　在把基线重建完了之后，需要把基线的版本、快照的编号、适用在哪几个分支上、门禁的规则，还有那些遗留问题打算怎么去处理，都给写进项目的记录里面去，这样，后面开发的人员再看到旧的问题还挂在那里，心里就知道，哪些是历史遗留下来的问题，哪些是这一次提交，才新带进来的问题了。

　　总结

　　关于Coverity的基线要怎么去重置，还有为什么重建完了以后，旧的问题还在，这里面的关键，还是在于要理解基线它到底起的是一个什么作用，它主要就是用来定下一个后续做增量判断，还有质量门禁的起点的，并不会自动地去把已有的缺陷给删掉，在重置的时候，要选好一个稳定的版本，去完成一次干干净净的扫描，把快照和流都给确认好，然后再去调整筛选的条件和门禁的规则，旧的问题如果还留在代码里面，重新扫描之后又出现了，这是正常的，项目上需要通过修复代码、管理好缺陷的状态，还有做好新增问题的筛选，去完成一个真正的闭环。