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

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

源文件能在工程导入后正常显示，并不代表头文件就一定能被工具正确地解析出来。很多人在配置C/C++test的时候，都会碰到两个很实际的问题：头文件的路径究竟该怎么设，以及头文件解析失败了又该怎么去处理。要想把这两件事弄明白，重点就得放在编译器、头文件所在的目录、那些用到的宏定义，还有当初真实构建时用的参数，这几样东西是不是都能对得上。C/C++test分析源文件的时候，其实是直接去读它的内容，而头文件则是通过源文件里include的关系，被间接带进分析范围的；如果单独挑一个头文件出来，直接让它去跑分析，工具一般是不去单独处理它的。

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

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

给项目接上静态分析的时候，光靠把源码目录指给工具是远远不够的；对于C/C++test来说，它还得弄清楚每一个源文件到底用的是哪一款编译器、带着哪些宏定义、头文件去哪儿找，以及编译的时候都跟着哪些参数。如果项目是用CMake来构建的，那完全可以先准备一份compile_commands.json文件；而换作是别的构建系统，也能通过C/C++test自己提供的工具去生成一种bdf格式的文件；这两条路子的目的都一样，就是要把软件当初真实的构建环境给还原出来，单靠手工去添加源码肯定是应付不过来的。

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

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

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

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