C/C++ test

工程里的代码能编译，单元测试却停在执行前。这时需要检查工程的构建参数、测试配置，以及测试程序实际在哪里运行。下面围绕“C/C++test怎么配置测试执行环境C/C++test测试执行环境初始化失败如何解决”展开，以C/C++test专业版的Eclipse集成界面为例。

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 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可以按行、函数、分支等口径统计覆盖率；如果结果为空，先别急着补测试用例，检查测试是否执行、覆盖率是否启用，往往更快找到问题。下文以C/C++test Professional的Eclipse集成界面为例。

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 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测试配置迁移后为什么失效，这两个问题经常连在一起出现：本机能跑，换到同事电脑或流水线就找不到配置；界面里能看到配置，命令行却提示不可用；规则还在，但自定义规则、路径、编译器参数又丢了。