C/C++ test

C/C++test报告空指针、未初始化变量或资源泄漏后，单看报错行往往不够，因为问题可能在几个函数之前就已经产生。处理C/C++test数据流路径怎么查看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做静态分析、单元测试之前，得先让测试工程正确拿到源文件、编译器和原工程里的编译选项。很多导入失败其实不是代码有问题，而是工程只导进了文件目录，头文件路径、宏定义、编译器参数没有一起带进来；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扫描范围排除第三方代码怎么处理。比较安全、稳妥的做法并不是直接把整个项目文件夹一股脑地丢给软件去跑，而是测试人员应该提前把“我们自己写的代码、别人写的第三方代码、机器自动生成的代码、还有用来测试的代码”这四个东西给分得清清楚楚的，然后再通过改动项目属性、调整测试选项或者去写命令行的一些参数，从而把检查的区域给控制住。

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

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

C/C++test代码审查任务通常围绕代码变更、开发人员、审查人员和审查结论展开。不同版本的入口会有差异，较早的C/C++test Professional多在IDE测试配置中创建审查任务，采用DTP集中管理的环境则可以通过构建审查比较两个版本的文件变化。处理“C/C++test代码审查任务怎么创建C/C++test代码审查任务无法分配如何处理”，要先把用户、源码管理和项目映射配置完整。

C/C++程序中的数组越界、非法指针和未初始化内存，有时不会立即造成崩溃，普通功能测试看起来照样通过。处理C/C++test怎么开启运行时错误检测C/C++test运行时检测不到数组越界是什么原因，需要让C/C++test对代码完成运行时插桩，并用测试数据真正执行到存在问题的访问路径。

大家在用这个工具做静态分析的时候，往往只盯着告警的数量看，代码指标反而被冷落了，其实去看这些指标，还有处理超标的情况，主要不是为了让报告里那些红色的数字消失，而是得去琢磨代码是不是已经变得不好修、不好测、也不好审了；这个工具的分析能力挺多的，像什么基础规则检查、数据流、抽象解释，还有度量指标这些都有，算出来的结果能给代码结构风险当个参考。

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则更适合用来做统一的分派、筛选，还有对历史状态的跟踪。