单元测试运行成功后，下一步是看代码究竟执行到了哪里。C/C++test可以按行、函数、分支等口径统计覆盖率；如果结果为空，先别急着补测试用例，检查测试是否执行、覆盖率是否启用，往往更快找到问题。下文以C/C++test Professional的Eclipse集成界面为例。

C/C++test做静态分析时，检查范围由测试配置里的规则集决定。同一个工程换一套规则配置，告警数量可能差很多。老项目刚接入静态分析时，比较常见的情况是一次出现几百甚至更多告警，其中可能混有第三方源码、自动生成文件、项目当前并不采用的编码规范，以及已经评审过的例外项。处理这类结果时，先把规则集和扫描范围整理好，再处理真正属于项目源码的问题，告警列表会更容易查看和维护。

C/C++test执行单元测试后，可以统计函数、语句、分支以及条件等不同层级的代码覆盖情况。很多人第一次看覆盖率时，会发现测试明明全部执行成功，报告里的覆盖率却比预想低，甚至部分源文件没有数据。这里通常要分清两件事：一是测试时到底插桩了哪些源码，二是当前查看的是哪一种覆盖率。覆盖范围没选全、使用了File Scope配置、测试路径没跑到，都会让最终统计结果看起来“不完整”。

C/C++test代码审查任务通常围绕代码变更、开发人员、审查人员和审查结论展开。不同版本的入口会有差异，较早的C/C++test Professional多在IDE测试配置中创建审查任务，采用DTP集中管理的环境则可以通过构建审查比较两个版本的文件变化。处理“C/C++test代码审查任务怎么创建C/C++test代码审查任务无法分配如何处理”，要先把用户、源码管理和项目映射配置完整。

C/C++程序中的数组越界、非法指针和未初始化内存，有时不会立即造成崩溃，普通功能测试看起来照样通过。处理C/C++test怎么开启运行时错误检测C/C++test运行时检测不到数组越界是什么原因，需要让C/C++test对代码完成运行时插桩，并用测试数据真正执行到存在问题的访问路径。

大家在用这个工具做静态分析的时候，往往只盯着告警的数量看，代码指标反而被冷落了，其实去看这些指标，还有处理超标的情况，主要不是为了让报告里那些红色的数字消失，而是得去琢磨代码是不是已经变得不好修、不好测、也不好审了；这个工具的分析能力挺多的，像什么基础规则检查、数据流、抽象解释，还有度量指标这些都有，算出来的结果能给代码结构风险当个参考。

在做 C/C++test 静态分析时，很多团队都会遇到 C/C++ test抑制规则怎么添加，C/C++ test抑制规则复扫后为什么还提示 这类问题。抑制规则不是简单把告警“隐藏掉”，它更像是一条确认记录：这条告警已经被判断过，当前场景下可以接受，后续报告里不再反复打扰开发人员。C/C++test 支持在源码、抑制文件和界面中处理指定 findings；如果是整条规则都不想检查，应该在测试配置里关闭规则，而不是给每个告警加抑制。

把代码分析的任务交给流水线之后，总不能每次都由人工点开界面去操作，所以就需要弄明白C/C++test怎么通过命令行批量地跑，以及命令执行完返回的那些数字该怎么看，这里主要用到的是一个叫cpptestcli的程序，批处理脚本、Shell脚本或者持续集成任务都可以把它调起来，用来做静态分析、单元测试、报告生成和结果上传，不过命令行模式需要专门的许可证，在正式接入流水线之前，最好先在构建机上单独让它跑通一次，确认环境没有大问题。

当把一个项目从旧电脑上原封不动地复制到新电脑，或者把整个工作区从一块硬盘挪到另一块硬盘之后，不少人都会遇到一种情况：C/C++test这个工具里面，突然就冒出来一大片红色的错误提示。明明源文件都还在原来的位置，原来的工程也能正常编译通过，可工具那边却一直提示说头文件找不到了、编译时用的那些参数失效了，或者链接的目录丢失了。在大多数时候，这都不是代码本身出了什么毛病，而是因为旧的工作区配置里面保存了很多绝对路径，搬了家以后，那些路径还依然指着原来的老目录，完全没有跟着变过来。再加上C/C++test的项目文件里面，还有可能挂着外部链接的文件夹、构建过程产生的数据文件，以及一堆缓存信息，这里面只要有一项没有同步好，错误就会扎堆地跳出来。

功能安全项目一旦进入评审阶段，临时从工具里匆匆导出一份扫描报告，往往是不够的。C/C++test这个工具，可以覆盖静态分析、单元测试、结构覆盖率以及需求的追踪，而Parasoft也提供了面向ISO 26262的合规资料和工具鉴定方面的支持。但真正需要准备出来的，其实是一条完整的证据链：这次到底用了什么规则、具体分析了哪些代码、发现的问题是怎么处理的、测试执行的结果怎样、覆盖率有没有达到预定的目标，以及需求和测试之间能不能做到互相追溯。这几块少了哪一样，评审的时候都可能被问到答不上来。