静态分析整套跑完之后，报告里虽然跳出来不少告警，但数量多本身并不算太难办，让人头疼的是这些告警长期找不到人认领，再加上不同开发人员对于同一个问题处理的口径完全不一样，慢慢地就把问题堆成了山。想要真正用好C/C++test的检查结果，比较实际的做法是把本地分析和DTP集中管理拆成两件事：本地环境可以留给开发人员自己快速改掉手头的问题，DTP则更适合用来做统一的分派、筛选，还有对历史状态的跟踪。

　　一、C/C++test检查结果怎么分派

　　给结果做分派的时候，如果还是靠人工按着文件夹一个一个去拆，不仅花时间，责任还容易搅浑。只要项目已经接入了Git或者SVN这样的源码管理工具，完全可以把代码的作者信息先利用起来，让系统根据提交记录自动匹配一个负责人，然后再由项目负责人去做补充和调整。

　　1、配置好源码管理的连接

　　先进到C/C++test里面，顺着菜单找到【Parasoft】→【Preferences】→【Scope and Authorship】，把使用源码管理系统来计算范围和作者信息的那个开关给打开，接着还要去【Source Controls】里头，把代码仓库的连接方式给配置好。这样一来，工具就能够按照文件的修订记录，判断出每一部分代码分别是由谁提交的，然后自动把测试中发现的失败项和规则违规分配到对应的人员头上。

　　2、确认作者识别得准不准

　　打开一个源文件，在上面点右键，找到类似【Show Line Authors】这种用来查看代码作者的入口，检查一下每一行旁边有没有显示出对应的提交人。如果发现作者信息是空的，不要急着大批量地往下分派任务，应该先回过头去，把仓库链接、用户的映射关系还有工作区的路径修正好，等作者信息显示正常了再去做分发。

　　3、到DTP里做集中分派

　　分析结果上传到DTP之后，我们就可以进入Violations Explorer这个界面，用项目、构建版本、规则、模块、作者还有Assignee作为条件来一层层筛选告警。DTP本身支持按Assignee、Action、优先级、风险影响程度以及Reference Number等多个维度进行搜索，用它来把不同模块冒出来的问题拆开，送到对应的负责人手上，会比手动分发方便很多。

　　4、人工修正一些特殊归属

　　自动分派只能当做起步的基础，碰上公共组件、历史遗留下来的老代码，或者好几个人共同维护的文件，经常会被分错人，这个时候项目负责人就需要按照模块的实际分工重新调整责任人，同时把处理的期限和说明也一并补上，这样每个人拿到任务才能真正清楚自己要做什么。

　　二、C/C++test检查结果状态怎么流转

　　在讲状态流转之前，有两个概念要分开来看：一个是扫描结果在不同的构建版本之间起了哪些变化，另一个是团队成员对某条告警动手采取了什么处理动作，这两件事不能混在一起。

　　1、先把新增、遗留和已修复区分开

　　在DTP里面选好一个目标构建版本和一个基准构建版本之后，就可以按State这个字段，把告警筛成New、Fixed和Existing这三类。New表示是当前构建里新冒出来的问题，Fixed是说旧版本里的问题在这次构建中消失不见了，Existing则意味着那些老问题还留在原地没有被动过。

　　2、修复以后要重新扫描确认

　　开发人员把代码改完之后，不能想当然地直接把那条告警标成已关闭，比较稳妥的做法是先把改好的代码提交上去，然后重新跑一次C/C++test的分析，亲眼确认同一条告警确实没有再冒出来。只有等它经过重新扫描进入了Fixed的范围，才算真正走完了一次技术闭环。

　　3、合情合理地处理可接受的告警

　　有些告警经过确认确实属于误报，或者是因为工具本身的局限性，又或者已经通过了评审被允许暂时保留，这个时候就可以对它执行抑制，也就是Suppress，但一定要把抑制的原因写清楚。C/C++test既支持在IDE里选中一条或几条告警后直接做抑制，也支持针对特定场景定义一套完整的抑制规则，但是要记住，抑制不能拿来代替真正的修复，如果涉及到MISRA偏离这类情况，还要把当时的评审依据留下来。

　　4、保留好处理动作和责任人

　　DTP里面的Action字段是用来表达下一步要往哪个方向处理的，Assignee则是指定了具体要动手的人。项目可以按照实际流程，把状态设置成待确认、修复中、待复测、允许保留等等不同的环节，再用Priority和Due Date把轻重缓急排出来。

　　三、C/C++test检查结果怎样避免积压

　　告警越堆越多，背后的原因一般不是扫描的频次不够，而是分派和关闭的规则一直没给定下来，所以在项目刚开始的阶段，就得明确好哪些问题是必须动手去改的，哪些需要走评审流程。

　　1、优先处理新增的高风险告警

　　每次构建跑完之后，先把目光盯在New那一类告警上，再按严重的级别、规则的类别和所属的模块去细分处理，至于过去遗留下来的老问题，可以排出一个分批清理的计划，但无论如何都不要再让新产生的告警继续渗进代码库里。

　　2、把抑制的要求统一下来

　　所有执行过Suppress的记录，都要把抑制的原因、责任人和评审结论填完整，没有留下任何说明的抑制项，到了后面再想分清它到底属于误报、是得到了豁免，还只是临时跳过没有修，就非常困难了。

　　3、定期把结果导出来做复核

　　DTP的Violations Explorer支持把当前筛选出来的结果直接导出成CSV文件，导出的时候还会保留页面上显示的那些列和排序方式。到了项目周会的时候，完全可以拿出这样一份清单，逐项去核对新增的、遗留的、已经修复的以及被抑制的条目，从而保证整个团队都对告警的当前状况心里有数。

　　总结

　　C/C++test的检查结果分派，应该先把源码管理和作者识别这些基础配置做好，再借助DTP按模块和负责人去做集中调整；状态流转这一块，则要把New、Existing、Fixed还有Suppress这几种情况分得清清楚楚，并且修复完成之后一定要重新扫描来确认。只要把责任人、处理动作、时限和抑制的原因都记录下来，静态分析产出的这些结果，才有机会真正进入项目里一条可追溯、能闭环的流程中。