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

很多团队看到C/C++test的Baseline结果“不对”，第一反应是工具失效了，实际上更常见的情况是比较口径没对齐。按Parasoft DTP的定义，Baseline build只是一个用于和当前目标构建做比较的历史构建，而真正决定比较结果能不能出来的，是Filter、Build、Run Configuration和搜索范围是不是在同一套口径里。

很多团队刚把Parasoft C/C++test接进流程时，最容易混掉的不是规则怎么选，而是“怎么启动分析”和“到底分析哪些代码”这两件事没有先分开。官方文档把这条线说得很清楚，静态分析是围绕Test Configuration也就是测试配置来跑的，配置里一部分负责规则和分析方式，另一部分负责范围和入口；如果前面只顾着点运行，不先把输入源、资源选择和Scope条件定好，后面很容易出现扫得太大、扫不到改动代码，或者头文件结果看不全这类问题。

很多团队上来就把C/C++test跑起来，结果要么告警太多压不住，要么为了赶进度一路放宽，最后规则、阈值和例外混在一起，谁也说不清哪一类问题必须改、哪一类问题可以备案后放行。Parasoft的文档其实把边界分得很清楚，测试最好先基于内置配置复制出自己的配置来调，规则本身、度量阈值和抑制例外也分别有不同的落点。

很多团队上C/C++test以后，前期最容易卡住的不是工具能不能跑起来，而是单元测试到底该先自动生成，还是先手工补，后面测试套件到底按文件放还是按函数拆。Parasoft官方文档其实把这件事讲得很清楚，C/C++test既支持自动生成测试，也支持用【Test Case Editor】和【Test Case Wizard】补用户自定义用例，同时还把测试套件、测试用例和数据源都集中放在【Test Case Explorer】里管理。只要先把“怎么建”和“怎么统一”两件事定住，后面的回归、覆盖率和团队协作都会顺很多。

做静态分析最怕的，不是规则少，而是规则一开始就配乱了。有人上来全开，结果告警一片红，开发根本不看；有人嫌误报多，干脆关掉一大半，最后留下来的又不足以支撑代码治理。C/C++test本身内置了大量静态分析规则，规则按类别和严重级别组织，真正执行检查时依赖的是测试配置，也就是Test Configuration，所以规则管理的关键不是临时点开点关，而是先把配置结构搭稳，再去做启用、禁用和分层。