在项目开始持续扫描以后，每次跑出来的结果数量会一直变动。想要弄明白C/C++test的结果基线是怎么建立的，以及基线和后来结果之间的差异要怎么对比，关键就是先选定一个已经确认过的构建版本拿来当参照，然后再用后面的构建去查看新增加的问题、已经修掉的问题，还有那些两个版本里一直都还在的问题。在团队协作的环境下，一般是通过Parasoft DTP来管理这些基线，C/C++test这边则负责执行分析，并把结果上传到对应的项目和构建号下面。

　　一、C/C++test结果基线怎么建立

　　基线不是说随便存一份扫描报告就算建好了，它应该对应的是一版代码状态比较稳定、规则集也很明确、扫描范围已经核对过的版本，比如需求冻结的那个版本、测试要启动的版本，或者是准备拿去发布的候选版本。

　　1、先把扫描的配置统一好。建立基线以前，要确认项目用的是同一套Test Configuration，再去核对一下静态分析用到的规则、排除了哪些目录、编译时候的参数，还有代码分支是不是也全都一样。如果规则集和扫描范围在半道上变过了，那后面数量上的差异就不一定是来自代码本身的修改了。

　　2、把DTP项目和构建编号固定下来。在流水线的配置文件里，设置好dtp.project和build.id，同时也要打开report.dtp.publish等于true，好让结果能传到DTP上面去。Parasoft的文档说过，build.id就是给结果加上一个构建标记用的，同一次构建里头就算跑了多次测试，也可以用同一个编号。

　　3、在DTP里把准备当基线的构建给锁住。扫描跑完之后，进到DTP的Build Administration页面，找到那个打算用来当参照的构建，把它锁定起来。按照文档的说明，一旦锁定，系统就不会再接使用相同Build ID的新报告了，这个办法很适合用来标记一个阶段已经收尾的版本；而归档这个功能，主要是为了把测试和覆盖率的详细数据留下来，免得后面被自动清掉。

　　4、给基线补上一点说明。可以给这个构建写一段简短的描述，像“V2.3需求冻结”或者“V2.3发布前检查”这样的。以后构建数量攒得多了，光看Build ID是很难很快想起来这个基线当初到底为什么被留下的。

　　二、C/C++test结果基线差异怎么对比

　　在对比差异的时候，不能只盯着总数看它是变多了还是变少了。真正需要去关注的，是新冒出来的问题有哪些、已经被修掉的问题有哪些，还有那些一直没处理的遗留问题有哪些，以及这些变化是不是都落在这一次修改的范围里面。

　　1、进到Violations Explorer里面。打开DTP里的Violations Explorer，点一下【Change Search】，去选好目标Filter和当前的Build，DTP这边最少要指定Filter和Build，当前选中的这个构建就会被当成目标构建来用。

　　2、把Basline Build选好。在搜索条件里挑中前面已经锁定的那个Baseline Build，然后到State那一栏里去分别看New、Fixed和Existing。New说的是目标构建里新出来的问题，Fixed说的是在基线里还有但是当前构建里已经不见了的问题，Existing就是两个构建里都还一直存在的问题。

　　3、按严重级别和目录筛一下。先去看严重级别高的那些问题，再顺着Resource Group、文件所在的目录、规则的类型，还有负责人，把范围一步步缩小。要是某一次提交只改动了某一个模块，那就应该先去看这个模块里新增加出来的告警，别让那些堆了很久的老问题给淹了。

　　4、分清楚是真修好了还是口径变了。如果某一次构建的问题数量突然之间有了很大的变动，那就得去看看规则集、扫描的目录、代码分支还有编译数据库是不是也变了。因为有时候规则被关掉了、目录被漏扫了，或者构建上传的东西不齐全，也会让问题的数量看起来像是突然少掉了。

　　三、C/C++test基线差异对比后怎么复核

　　差异列表拉出来以后，还得再去看一看这些数据到底能不能信。基线管理这件事真正让人觉得头疼的地方，往往不是某个按钮该怎么点，而是不同的团队成员在跑的时候用了不一样的参数，最后搞出来的对比结果没法跟别人说清楚。

　　1、去看一下Build Audit Report。进到目标构建的Build Audit Report里面，去检查Static Analysis、Tests、Coverage还有Runs这几块内容。这个报告会把这次构建关联的分析数据都汇总到一起，同时也会显示出Setup Problems，这样就能很容易地发现扫描的配置是不是有哪里不正常。

　　2、核对一下是不是同一套口径。在拿基线和目标构建做对比的时候，要确认DTP Project、Build ID的命名规则、Test Configuration、Session Tag，还有扫描范围，这些东西都是不是一样的。只有这些口径都保持一致了，新增和修复的数量才有拿出来参考的价值。

　　3、把几个关键阶段的基线留下来。平常跑的构建，不用个个都去锁定。像需求冻结、测试启动、版本发布这些重要的关口，可以各留一条基线下来。要是碰上涉及覆盖率和测试详细数据的情况，最好再同时做一下归档，因为DTP在默认的情况下，只会在最近那几个构建里保留一部分测试和覆盖的明细。

　　4、把对比这一步加到流水线里面去。每次发布以前固定做一次基线差异的检查，重点去看新增出来的高风险问题、还没关掉的问题，还有Setup Problems。这样团队每次处理的，就是这一次改动真正带来的那部分风险，用不着回回都去把整份报告翻一个遍。

　　总结

　　版本迭代的次数一多，单独的某一次扫描报告很快就会没有拿来判断的价值了。要说C/C++test的结果基线怎么去建，以及基线和后来结果的差异又该怎么去比，实际上的做法就是用稳定的Build ID去上传结果，在DTP里面把阶段性的构建给锁住，再通过Violations Explorer去查看New、Fixed和Existing这些变化。比完了以后，再补上一次Build Audit Report复核，把规则、目录和运行的参数都确认没有变过，这样基线的数据才算能真正拿来做版本评审的依据。