在MISRA检查、代码合规审计和版本升级之后，经常会碰到QAC的规则集要怎么去管理，还有把规则集升了级，结果却出现了波动，又该怎么去分析的问题。QAC的规则集，并不是去简单地开关几条规则就完事了，它会影响到缺陷的数量、严重的级别、误报的判断、历史的趋势，还有项目准入的那个结论，要是管理上没弄明白，那么一旦升级了一次规则包，结果里面突然就多冒出来几百条问题，团队那边就很难去判断，这到底是真的有风险，还是仅仅因为工具的规则发生了变化，才带来的波动。

　　一、规则集要怎么管理

　　在管理QAC的规则集时，要先去做一件事，就是把“公司用来打底的基线规则”和“各个项目自己差异化的规则”，给分开来管，可不要给每一个项目，都靠手工去单独改一份配置，要不然的话，到了后面，无论是想要做升级、回退，还是去应对审计，都不好去解释。

　　1、去建立一套统一的规则基线

　　这件事，可以先由质量的团队，或者是专门负责这个工具的人，去整理出一份公司级别的规则集，在这份规则集里面，要明确下来，到底是采用MISRA C、MISRA C++、CERT C，还是公司内部自己定的编码规范，在规则集里头，要把哪些规则是启用的、哪些是禁用的、都是什么严重的级别、豁免的原则又是什么，还有它适用在哪种语言版本上，这些东西全给写清楚，这样做了以后，各个项目就不是从一套空白的配置开始做起，而是在一条统一的基线下，只去做少量的调整就行了。

　　2、按照项目去把它复制一份，然后把版本给锁死

　　当具体的项目，要去用规则集的时候，就应该从公司的那条基线上，复制一份出来，当成这个项目自己的配置，然后再去把规则集的名字、版本、当时用的工具版本，还有它是从哪一天开始生效的，这些都给记录下来，不要直接就跑到那条公共的基线上去，改动项目自己特殊的地方，不然的话，其他项目跑出来的结果，也是会被连累着一起变的，等到项目要交付，或者是客户来做审核的时候，也才能说得清楚，当时用的，到底是哪一个版本的规则。

　　3、把跟规则有关的变更，也给纳进评审里面去

　　不管是新增加一条规则、关掉了一条规则，还是把一条规则的级别给降低了，这些动作，全都是应该经过评审的，就比如说，某一条规则，因为平台代码自己的特点，长期都在那误报，那就可以把它给记成是这个项目的一条豁免；可要是那种跟安全死死绑在一起的规则，那就不太建议随随便便地就去把它给关掉，在规则变更的记录里面，要去把为什么要改、影响的范围有多大、是谁批准的，还有到时候要怎么退回去，这些都给写明白了。

　　4、要让规则集，跟构建的环境，保持着匹配的关系

　　QAC规则跑出来的结果，还是会受到编译器的配置、宏的定义、头文件的路径，还有目标平台，这些东西的影响的，所以，在管理规则集的时候，是要去把它跟项目的配置，放在一起去保存的，不能就只去保存一个光秃秃的规则文件，要不然的话，同一套代码，换到另一台机器上再去跑，那个结果，也有可能是会不一样的。

　　二、规则集升级后结果出现波动要怎么分析

　　当把QAC的规则集升了级以后，发现结果出现了波动，这个时候，要先把它给拆开来看看：这到底是因为新增了规则，才带进来的新增告警；还是因为旧的规则，它判断的逻辑发生了变化；又或者，仅仅是工程的配置被动过了，结果导致分析的范围，跟以前不一样了。

　　1、先去把升级前和升级后的配置，拿出来对比一下

　　去把升级以前的那套规则集，和升级以后的那套规则集，放在一起做一次对比，去确认一下，有哪些规则是新被启用起来的，有哪些规则的严重级别被调整过了，还有哪些规则的参数，发生了变化，可不要一上来，就直接拿着问题的数量去比对，然后就下结论，数量的变化，它顶多只能告诉你，结果变了，但是并不能说明，风险就真的一下子变高了。

　　2、去把新增的问题，和那些被重新分了类的问题，给区分开

　　在升级完了以后，多出来的那些问题，要去看一看，它们是不是都来自于那些新加进来的规则；而原有问题的严重级别要是变了，那这背后，可能就是规则的分类，做了调整，这个时候，可以按照规则的编号、文件的路径，还有消息的类型，去分着组来做统计，这么做完了以后，就能看出来，这次的波动，是集中在了少数的几条规则上，还是说，广泛地分布在了整个代码库里面。

　　3、去检查一下，分析的范围，是不是也发生了变化

　　当结果突然之间，猛增了一大截的时候，就要去看一看，这一次的扫描，是不是又多分析了什么目录、生成的代码、第三方的库，或者是测试的代码，在QAC的项目里面，排除的路径、宏的定义，还有包含目录，这些地方一旦被改动了，那也是会让工具，看到更多的代码分支的，有很多的波动，其实根子上就不是规则的升级，而是输进去的范围，变了。

　　4、要抽着样，去复核一下那些高风险的告警

　　在升完级了以后，可不要一上来，就急着去批量地压制那些告警，要先抽着样，去看一看那些严重级别很高的告警，去确认一下，它们到底是真的问题、是重复了的问题，还是工具的解释，发生了变化，对于那些真实存在的风险，是要把它给放进整改的计划里面去的，而对于那些确实是误报的，就要按照流程，去把原因给记录下来，可不能只为了，让结果的数量能恢复到以前那个样子，就去随随便便地关掉规则。

　　三、规则集升级的记录要怎么留下来

　　QAC规则集升级的这些记录，是要能被留下来，去撑得起后面的复盘的，当客户，或者是公司内部做质量评审的人，追着问起来的时候，团队是需要能够说得清楚，在升级的前前后后，到底都发生了一些什么，有哪些结果是可以在时间上拿来做对比的，又有哪些结果，是不能被直接拿来放在一起去比的。

　　1、把升级时候的说明给保留下来

　　去把升级的时间、工具的版本、规则集的版本、都牵扯到了哪些项目，还有是谁动手做的，这些都给记下来，要是厂商那边，发布过关于规则的更新说明，或者是版本的说明，那也要把它，跟公司内部的记录，放在一块儿去保存好。

　　2、去把结果的对比表给保留下来

　　最好是能按照规则的编号，去把升级前和升级后的告警数量、严重级别的变化，还有新增文件的范围，都给统计出来，做成一张表，这张表，不用搞得多复杂，但是，得能让人一眼就看出来，主要的波动，它是从哪个地方来的。

　　3、去把最后是怎么处置的结论，也给保留下来

　　对于每一类出现的波动，都得有一个处理它的结论，就比如，是把它纳进整改计划了、是继续维持着观察、是把规则的参数给调整了、是把它当成误报给豁免了，还是直接把那些不属于交付范围内的代码，给排除出去了，一份没有结论的对比表，它只能说明，你发现了有变化，但是，不能说明，那个风险，是已经被管起来了。

　　4、去把回退的方案给保留下来

　　在升级的初期，是可以去把旧的规则集，还有旧的分析报告，都给留下来的，要是新的规则，影响到了对交付的判断，那就要能够，在短期内，先退回到那个已经被确认过的版本上去，与此同时，也要去说明清楚，针对新规则的验证计划，到底打算怎么去安排。

　　总结

　　关于QAC的规则集要怎么去管，还有当规则集升了级以后，跑出来的结果出现了波动，又要怎么去分析，这里面的关键，就是要把规则集，当成是一种受到严格控制的配置项，去好好地管理起来，先要去建立起公司的基线，然后再按照项目去复制，去把版本给记录好；等到升了级以后，也别光是盯着问题的数量在那里看，而是要从规则的变化、严重级别、分析的范围，还有真实的代码风险，这么四个方向，去把它给拆开了，一层一层地去分析，只要规则有了版本，结果有了对比，处置也有了记录，那QAC检查出来的东西，才更容易被评审的人所接受。