刚接触C/C++test的编码规范检查，容易先选一套规则扫描整个项目，结果一次出现几百条告警。逐条看之前，先确认检查范围和规则集是否符合项目要求。下面以C/C++test Professional的Eclipse集成界面为例，说明如何配置检查，以及告警过多时怎样调整。

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

测试一个函数时，它可能会顺带访问数据库、设备接口或尚未完成的模块。想让这些调用按预设结果返回，就需要设置桩函数。下面以C/C++test Professional的Eclipse集成界面为例，说明怎样创建桩，以及调用异常时从哪里查起。

工程里的代码能编译，单元测试却停在执行前。这时需要检查工程的构建参数、测试配置，以及测试程序实际在哪里运行。下面围绕“C/C++test怎么配置测试执行环境C/C++test测试执行环境初始化失败如何解决”展开，以C/C++test专业版的Eclipse集成界面为例。

C/C++test完成静态分析、单元测试或覆盖率采集后，可以把本次执行结果整理成HTML、PDF等测试报告。报告中能看到多少内容，并不只取决于报告格式，还和本次测试配置、执行范围、覆盖率采集方式以及报告参数有关。有时工程测试已经结束，生成的报告却只有部分告警，或者缺少测试用例、覆盖率明细。这类情况可以先确认测试结果本身是否存在，再检查报告生成配置，避免把测试数据缺失和报告显示不全混在一起处理。

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

C/C++test完成测试工程配置后，就可以针对工程、源文件或指定测试用例执行单元测试。实际测试时，运行失败并不一定发生在测试用例本身，源码插桩、测试可执行文件构建、外部函数链接、运行环境和测试数据都可能让任务提前停止。碰到测试用例没有执行、构建阶段报错或者执行结果直接显示Failed时，把失败位置先分清，再去处理对应配置，通常比反复修改测试用例更容易找到问题。

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

C/C++test做静态分析、单元测试之前，得先让测试工程正确拿到源文件、编译器和原工程里的编译选项。很多导入失败其实不是代码有问题，而是工程只导进了文件目录，头文件路径、宏定义、编译器参数没有一起带进来；Makefile工程、交叉编译工程尤其容易碰到这类情况。下面以C/C++test Professional的Eclipse/Standalone界面为主，说明测试工程怎么配置，以及工程导不进来、导入后大量文件报错时该从哪里查。

C/C++test报告空指针、未初始化变量或资源泄漏后，单看报错行往往不够，因为问题可能在几个函数之前就已经产生。处理C/C++test数据流路径怎么查看C/C++test数据流路径中断如何定位，需要沿着变量来源、条件分支和函数调用逐段检查，同时确认分析范围里没有漏掉关键源文件。