在嵌入式的C和C++项目里面，经常会碰到QAC的增量检查要怎么去做，还有跑完增量以后，要是漏掉了一些改动，又该怎么去把它给找出来的问题，增量检查这件事，它的目的并不是要去替代全量的检查，而是要在平日里提交代码、发起合并请求，还有在持续集成跑起来的时候，能更快地去发现，那些因为新的改动才被带进来的问题，按照Perforce Helix QAC的文档说明，要想在持续集成里跑增量构建，是需要先有一次已经跑成功的全量构建，来作为基线的，然后呢，增量构建它就会去分析，那些相对于上一次成功的全量构建来说，发生了直接，或者是间接变化的文件，这里面，也包括了那些，被改过的头文件给牵连到的源文件。

　　一、增量检查要怎么做

　　QAC的增量检查，是需要先去建立一条完整的基线，然后再让工具，围着那些被改动过的文件去跑分析，要是连一条基线都还没有，那增量这件事就根本无从谈起了，因为工具它自己，也不知道哪些结果算是历史上已经有的老问题，又有哪些问题，是由这一次的改动才给带进来的。

　　1、要先去跑完一次全量的分析

　　在项目刚刚接入进来的那个初期，要先用图形界面，或者是命令行的方式，去跑完一次全量的分析，要保证所有的源文件、头文件、编译的选项、宏的定义，还有包含的路径，这些东西，全都是被正确地识别到了的，全量跑出来的那一套结果，是要能被拿来，当成后面做比较的那条基线用的，要是连在全量这个阶段，就已经有一大片的文件没有被解析出来，那到了增量的时候，只会把那些藏着的问题，给埋得更深。

　　2、到了持续集成里面，去把增量的参数给打开

　　在用命令行去跑的时候，可以在持续集成的任务里面，用一种类似增量构建的命令，去把那个增量的模式给打开，按照官方的说明，一旦用上了增量的那个参数，它就会把全程序的分析给关掉，只去分析那些发生了变化的文件，要是你的项目，对合规那些规则的要求特别严，那就要先去掂量掂量，这种增量的模式，到底适不适合被直接拿来，当成质量的门禁。

　　3、去把工程文件的范围给同步好

　　在跑增量检查之前，是要保证好，QAC的项目，跟你真实的那个代码仓库，是保持同步的，在图形界面里面，一般是通过项目菜单下的同步功能，去把项目里的内容给更新一下，要是那些新增的文件，没有被同步进QAC的工程里面，那么，就算是代码仓库那边已经有了改动，这个工具，它也是有可能会不去分析它的。

　　二、增量检查漏掉了改动要怎么定位

　　当发现增量检查，好像漏掉了一些改动的时候，不要只是盯着扫描报告上，那个数量的变化来看，要先去确认一下，那些被改动过的文件，到底有没有进到QAC的项目里面去，然后，再去确认一下，构建的基线、头文件的依赖，还有持续集成的工作区，这些东西，是不是都保持了一致。

　　1、去查一下，那些改过的文件，是不是已经待在项目里面了

　　先去把QAC工程的文件列表给打开，去确认一下，你这一次动了的那几个源文件和头文件，是不是已经提前存在于这个项目里面了，要是文件在代码仓库里待得好好的，但是在QAC的工程里面，却找不到它，那通常就是同步的规则、排除的规则，或者是项目根目录的配置，出了毛病，特别是那种新加的模块、临时的目录，还有自动生成文件的目录，这几个地方，是最容易被漏掉的。

　　2、去查一下头文件，它能影响到的链路

　　有些改动，它是发生在头文件里面的，但是，真正需要被拉出来重新分析的，其实是那些包含了它的源文件，官方的增量说明里，是明确提到过的，增量构建，它会去分析那些直接被改动过的文件，还有，通过头文件，被间接影响到的那些文件，要是你发现头文件明明已经改了，但是，相关的源文件却没有被顺手给带出来，那就要去检查一下，包含的路径、编译的数据库、宏的开关，还有文件的依赖，这些东西，是不是都被QAC给正确地认出来了。

　　3、去查一下，基线是不是给选错了

　　增量构建，它是相对于，上一次那个成功的全量构建，去判断变化的，要是持续集成的任务，用错了工程、用错了构建的名字、指到了一条旧的基线上，或者是拿到了另一个分支跑出来的结果，那就有可能会出现，代码明明已经改过了，可是报告上却一点变化都没有的情况，在定位的时候，要去把这一次提交的编号、全量基线的时间、持续集成工作区的路径，还有上传上去的那个项目的名称，放在一起去对照着看。

　　三、增量检查要怎样避免结果失真

　　增量检查这个东西，是比较适合拿来给你一个快速的反馈的，但是，它并不适合，被拿来完完全全地取代，那种周期性的全量扫描，官方的文档里，也是提醒过的，说增量的分析，是会把某一些，要靠着全程序分析才能完成的能力，给关掉的，所以，最后跑出来的结果，是有可能会跟全量分析，不太一样的。

　　1、要把定期的全量检查给保留下来

　　平日里提交代码的时候，就用增量的检查去把速度给提上来，但是到了晚上自动构建的时候、版本快要冻结的时候、还有在里程碑交付以前，这些关键的时刻，仍然是要去把全量的检查，给跑上一遍的，这么干，既能保证在开发的那个阶段，反馈是足够快的，也能避免，因为长期只盯着增量的结果看，结果导致，那些跟历史依赖有关的老问题，全都悄悄地沉积下来了。

　　2、要把新增文件的检查，给放进质量门禁里面去

　　在持续集成里面，除了要跑QAC的分析，还要再去检查一下，这一次提交上来的、新增的源文件，是不是都已经进到了QAC的项目里面去了，要是发现有新加进来的源文件，却没有对应着的分析结果，那就直接让这一次的构建给失败掉，这么做，可是要比到了后期，再靠人工去补查，要稳当得多了。

　　3、要把跑增量的依据给记录下来

　　每一次去跑增量的检查，都要去把提交的编号、分支的名字、基线的版本、QAC工程的版本、规则配置的版本，还有分析的日志，这些信息，全给留下来，这样，万一到了后面，出现了漏检的争议，就能顺着这些留下来的信息，去查清楚，这到底是工具没有识别出来、是配置没有同步到位，还是在持续集成拉取代码的时候，没有把代码给拉完整。

　　总结

　　关于QAC的增量检查要怎么去做，还有万一它漏掉了改动，又要怎么去定位，这里面的关键，就是先要有一条靠谱的全量基线，然后，再靠着增量的参数，或者是持续集成的增量任务，去分析那些被改动过的文件，当发现漏了改动的时候，要重点去查三样东西：那些文件，是不是已经被同步进了QAC的工程里面；头文件的依赖关系，是不是被正确地给识别出来了；还有，用来做增量的那条基线，是不是选对了，在平常的时候，可以用增量的检查去把速度给提上来，但是，在版本交付以前，还是得把全量的检查给保留下来的，要不然的话，那个跑出来的结果，是很容易因为项目的同步、依赖的链路，或者是基线的问题，而变得不再可靠了。