QAC的增量分析应当怎样配置，以及QAC增量分析的结果不完整又该怎样处理，这是老项目在接入静态分析时很容易碰到的问题。如果每次都跑全量分析，时间会拖得很长，CI流水线也容易被拖慢；但如果只做增量分析，又担心某些受到影响的文件没有被扫描到。QAC的增量分析，更适合用在日常提交、合并请求和分支检查这些场景中，用来尽早地发现新增的问题，但是它不应当完全替代周期性的全量分析。在CI场景下，增量分析通常需要依赖已有的基线，并且着重关注由本次变更所带来的新增问题。

　　一、QAC增量分析怎么配置

　　QAC增量分析的配置，不能只是看命令能不能运行起来。在它的前面，需要有完整的项目配置、规则配置以及全量结果作为支撑，否则跑出来的结果虽然可能很快，但是不一定可信。尤其是在嵌入式项目中，宏定义、头文件路径、编译选项只要稍有不一样，分析的基准就会发生变化。

　　1、先完成一次全量分析

　　头一回接入的时候，先不要急着开启增量分析。项目需要先跑通一次完整的分析，把源文件、头文件、宏定义、编译器配置、规则包全都确认下来。假如在全量分析阶段还存在大量的解析错误，那么后面的增量分析，就仅仅是把问题遮盖了起来，并不是真的提升了效率。

　　2、固定分析的基线

　　可以把最近一次成功的全量分析，作为后续增量分析的参照，在这之后，只围绕发生了变化的文件以及受到影响的那些范围去进行检查。这里需要留意，“成功”并不是说任务没有报错就可以了，还要去看分析的范围是不是完整的，结果有没有保存好，规则的配置是不是已经稳定了。如果基线本身就缺少了一部分模块，那增量结果自然也会跟着有所缺少。

　　3、接入CI流程

　　增量分析适合放在代码提交、合并请求或者是分支构建的流程里面。QAC的CI分析，可以把变更带来的问题上传到Validate里面去，并且在CI构建当中把结果展示出来；要是发现了新增的问题，构建的状态就可能会被标记为不稳定。

　　二、QAC增量分析结果不完整怎么办

　　增量分析的结果不完整，先不要直接去判断是工具漏扫了。很多情况下，问题出在基线、变更识别、路径映射或者是排除规则上面。做排查的时候，要先问清楚一件事情：这次到底应当去分析哪些文件，而在实际结果里面又只出现了哪些文件。

　　1、检查基线是不是失效了

　　CI服务器清理了缓存、更换了工作区、切换了分支路径，又或者是上一次的全量分析曾经失败过，这些都有可能让增量分析找不到可靠的参照。碰到这种情况的时候，不要反复地去修改参数，重新去跑一次全量分析，往往要来得更快一些。

　　2、检查变更的范围

　　只修改了.c文件，是比较容易判断的；可要是改动的是头文件、公共的宏、编译的配置，那么受到影响的文件范围就会变得更大。QAC的新版本能力里面，也强化了针对头文件变化之后的自动分析，还有增量分析的支持，这一类依赖关系，需要让工具能够正确地识别出来。

　　3、检查排除目录

　　当结果少到不太正常的时候，要去看一看，是不是把源码目录误给排除掉了。生成代码、第三方库、测试目录，可以按照策略去排除，但是核心的业务代码是不能被排除在外的。多平台的项目还要注意，在不同的编译配置下面，参与分析的文件有可能是不同的，不能拿一个平台的结果，就去判断所有平台的情况。

　　三、增量分析怎么和全量分析配合

　　增量分析的长处在于速度，而全量分析的长处则在于完整。这两者不能互相去替代。比较稳妥的做法是，日常的提交去跑增量分析，夜间构建、版本冻结、规则调整之后，再去跑全量分析。

　　1、日常提交看新增问题

　　开发人员在做提交的时候，重点去看新增的告警，以及修改文件里面的高风险问题。不要把每一次的增量结果，都当作是整个项目质量的结论，它更加像是一种提醒，看看这次改动是不是带来了新的技术债务。

　　2、配置变化后跑全量

　　规则包、宏定义、编译器、头文件路径、排除目录发生改变以后，最好是重新去做一次全量分析。因为这些变化所影响的，是分析的基准本身，并不仅仅是某几个文件。

　　3、异常结果先暂停合入

　　如果本次的改动明明涉及到了多个模块，但是增量结果却只显示出一两个文件，这种情况不要直接去合并。先把扫描的范围、基线和CI日志都查看清楚，再去决定是不是要放行。在静态分析这件事情上，宁可让它稍微慢一点，也不能让团队生出一种“已经被扫描过了”的错觉。

　　总结

　　QAC增量分析怎么配置，QAC增量分析结果不完整怎么办，这里的关键是先要有一份可靠的全量基线，然后再让增量分析去为日常的开发服务。做配置的时候，要把工程配置、规则包、CI工作区和结果基线都管理好；当结果出现不完整的时候，先去检查基线、变更范围、头文件依赖和排除目录。增量分析适合用来快速地发现新增问题，而定期进行的全量分析，则用来在最后兜底，这两样配合起来，QAC的结果才会更加稳定。