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

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

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

C/C++test接入GoogleTest时，所谓“导入用例”通常包含两件事：让测试工程能够正常编译执行，再把GoogleTest生成的测试结果交给C/C++test处理。处理“C/C++test如何导入GoogleTest用例C/C++test导入后用例不显示怎么排查”，要先确认测试程序里确实注册了用例，然后再检查XML结果、测试配置和界面过滤状态，单纯把测试源文件复制进项目并不会自动生成完整的测试结果列表。

在使用C/C++test做单元测试、覆盖率测试或持续集成扫描时，经常会遇到C/C++test测试环境怎么切换，C/C++test测试环境切换后用例为什么失败这类问题。这里说的“测试环境”，不只是换一台电脑那么简单，还可能包括编译器、目标平台、运行目录、环境变量、依赖库、测试数据、DTP配置、报告路径等内容。C/C++test的Test Configuration会决定代码如何被分析和测试，包括启用哪些规则、运行哪些测试项以及相关分析参数；命令行中也可以通过-config指定要使用的测试配置。

在把C/C++test接入Jenkins、GitLab CI、Azure DevOps或本地批处理脚本时，常见问题就是C/C++test命令行扫描怎么执行，C/C++test命令行扫描返回码怎么看。界面里点一下能跑，不代表命令行也能跑通。命令行扫描需要把测试配置、编译器配置、输入范围、报告目录和本地设置都写清楚；返回码也不能只看是不是0，还要分清楚是“扫描失败”，还是“扫描完成但发现了违规”。

在测试人员使用C/C++test这个工具去进行静态分析或者做单元测试之前，大家总会碰到一些比较头疼的问题，比如C/C++test扫描范围怎么设置，还有C/C++test扫描范围排除第三方代码怎么处理。比较安全、稳妥的做法并不是直接把整个项目文件夹一股脑地丢给软件去跑，而是测试人员应该提前把“我们自己写的代码、别人写的第三方代码、机器自动生成的代码、还有用来测试的代码”这四个东西给分得清清楚楚的，然后再通过改动项目属性、调整测试选项或者去写命令行的一些参数，从而把检查的区域给控制住。

当项目环境发生变动，比如从一台电脑挪到另一台电脑，更换了工作区的路径，或者之前是跑在持续集成的环境里、现在需要迁回到本机进行调试和修改，这时候用户常常会撞上一种挺憋闷的状况：在开发工具的界面上可以看见工程名字，但点开逐级的源码目录却发现底下空了一大块，很多原本该在那里的源代码文件并没有跟着显现出来。本文打算围绕Parasoft C/C++test这个工具，重点聊聊C/C++test工程到底应该怎么完成导入操作，以及万一在导入以后碰到了源码丢失的表现，我们该从哪些方向把它找回来。在处理之前，心里头需要先装着一个基本的概念：C/C++test的工程文件，它本质上是用来存放项目结构、分析配置这一类信息的，并不负责把真实的源代码复制并保管到工作区里头，源码始终是留在原本的代码目录下面的。所以，导入工程这个操作，绝不等于是把源码搬了进来。

在动手写单元测试的时候，我们常常碰到这样一种情况：被测的函数里会去调用数据库、操作硬件接口、读写文件、走网络通信，或者用到了一些还没开发完的底层模块。假如直接在测试里让这些真实的依赖跑起来，测试环境就很难被控制住，也不太容易稳定地把那些异常分支给复现出来。所以在C/C++test这个工具里，就需要搞清楚两件事：测试桩到底该怎么生成，以及桩的返回值要怎么去模拟。基本上的思路就是，先用一个桩把外部的函数给替换掉，然后再根据不同的测试用例，去设置正常的返回值、错误码、超时的表现，或者多次调用时每次返回什么不同的结果。C/C++test既支持我们自己手写桩，也可以让工具自动生成，而且一旦建了用户自定义的桩，它的优先级是比原始函数和自动桩更高的。

做C/C++test规则治理，真正容易乱的地方通常不是规则本身，而是同一套项目里有人在界面里改，有人在命令行里跑，还有人把规则映射单独放在本机上，最后每台机器看见的结果都不一样。Parasoft官方资料把这件事拆成了几层：一层是Test Configuration，也就是决定跑哪些规则和参数的.properties配置；一层是rulemap.xml，用来改规则分类、编号、名称和严重级别；再往上还有localsettings、DTP和Team Server，分别负责设置分发和团队共享。把这几层分清，后面的导出和版本化才不会越做越散。