C/C++ test

在进行C/C++test静态分析时，很多团队经常不知道如何去改规则的严重级别，也不知道怎么把级别和流水线门禁对应起来，其实严重级别不只是让告警的颜色变一下，它会直接影响到开发人员先改哪个、评审时看哪个，还会影响到CI门禁到底卡住哪些代码，一般来说，这个工具的规则严重级别是1到5级，1级是最高的，5级是最低的，这个数字代表了如果违反这条规则，代码出现严重缺陷的可能性有多大。

在进行功能安全测试、嵌入式软件测试，或者是在代码合规交付的时候，C/C++test需求追溯怎么建立，还有C/C++test需求追溯关系断开怎么修复，这些都是经常会遇到的头疼问题。需求追溯这件事情，并不是说只要在报告里面简单地贴上一个需求编号就可以的，而是需要测试人员把需求、测试用例、测试的结果、代码覆盖率、实现文件，还有静态分析出来的结果，把这些信息全部串联起来；通过使用Parasoft DTP这个工具，测试人员可以把ALM或者RMS系统里面的需求，和测试用例、实现文件、静态分析里不合规的地方、代码评审等质量数据，把它们紧密地建立起追溯的关系；在这个过程里面，C/C++test这个工具主要负责把测试、覆盖率和分析的数据产生出来，然后再把这些结果送到DTP里面去进行统一的展示。

在使用C/C++test进行静态分析、单元测试或者覆盖率检查的时候，很多报错其实不是规则本身的问题，而是因为编译器配置没有对上，C/C++test编译器配置怎么选择，以及C/C++test编译器配置不匹配为什么会报错，这两个问题是要放在一起看的，因为C/C++项目和普通的脚本文件不一样，不能拿来直接就分析。C/C++test在运行分析以前，需要把具体的C/C++编译器及其版本配置好，这个配置也应该尽量去反映项目实际构建时用的原始编译器。

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

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

在使用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 静态分析时，很多团队都会遇到 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的合规资料和工具鉴定方面的支持。但真正需要准备出来的，其实是一条完整的证据链：这次到底用了什么规则、具体分析了哪些代码、发现的问题是怎么处理的、测试执行的结果怎样、覆盖率有没有达到预定的目标，以及需求和测试之间能不能做到互相追溯。这几块少了哪一样，评审的时候都可能被问到答不上来。

在做 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提供了一套内置的检查器和合规报告功能，但有一些条目光靠静态分析是跑不完的，还得靠人工去评审，并且把偏差记录给留下来。