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

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

C/C++test做变更影响分析时，既可以按代码变更缩小静态分析范围，也可以结合DTP，根据历史覆盖率找出需要重新执行的测试。处理“C/C++test变更影响分析怎么配置C/C++test变更影响范围不完整如何检查”，先确认自己要筛的是代码文件，还是受影响的测试用例，这两套配置不能混着看。

在做 C/C++test 动态测试时，C/C++ test内存检查怎么开启，C/C++ test内存检查结果异常怎么判断 经常会和单元测试、应用监控、目标板运行放在一起看。内存检查不是普通静态规则扫描，它需要把程序编译成带监控能力的测试程序或应用程序，再在运行过程中捕捉内存访问问题。

使用C/C++test做静态分析、单元测试或覆盖率检查时，测试配置不要随手改内置模板。比较稳的做法，是先复制一份配置，再在复制出来的配置里调整规则、范围、报告、抑制项和运行参数。C/C++test测试配置怎么复制，C/C++test测试配置迁移后为什么失效，这两个问题经常连在一起出现：本机能跑，换到同事电脑或流水线就找不到配置；界面里能看到配置，命令行却提示不可用；规则还在，但自定义规则、路径、编译器参数又丢了。

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

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

汽车软件项目把静态分析工具接入以后，检查规则就不能再靠开发人员临时去勾选了。要搞清楚C/C++test里面的AUTOSAR检查到底该怎么配置，以及AUTOSAR的规则集又要怎么去切换，关键是要先分清楚，这一次项目要检查的到底是AUTOSAR C++14，还是Classic AUTOSAR项目里头的C语言代码。Parasoft的C/C++test针对AUTOSAR C++14提供了一套内置的检查器和合规报告功能，但有一些条目光靠静态分析是跑不完的，还得靠人工去评审，并且把偏差记录给留下来。

很多团队看到C/C++test的Baseline结果“不对”，第一反应是工具失效了，实际上更常见的情况是比较口径没对齐。按Parasoft DTP的定义，Baseline build只是一个用于和当前目标构建做比较的历史构建，而真正决定比较结果能不能出来的，是Filter、Build、Run Configuration和搜索范围是不是在同一套口径里。

很多团队刚把Parasoft C/C++test接进流程时，最容易混掉的不是规则怎么选，而是“怎么启动分析”和“到底分析哪些代码”这两件事没有先分开。官方文档把这条线说得很清楚，静态分析是围绕Test Configuration也就是测试配置来跑的，配置里一部分负责规则和分析方式，另一部分负责范围和入口；如果前面只顾着点运行，不先把输入源、资源选择和Scope条件定好，后面很容易出现扫得太大、扫不到改动代码，或者头文件结果看不全这类问题。