使用C/C++test做静态分析、单元测试或覆盖率检查时，测试配置不要随手改内置模板。比较稳的做法，是先复制一份配置，再在复制出来的配置里调整规则、范围、报告、抑制项和运行参数。C/C++test测试配置怎么复制，C/C++test测试配置迁移后为什么失效，这两个问题经常连在一起出现：本机能跑，换到同事电脑或流水线就找不到配置；界面里能看到配置，命令行却提示不可用；规则还在，但自定义规则、路径、编译器参数又丢了。

　　一、C/C++test测试配置怎么复制

　　C/C++test的测试配置，本质上是在规定“这次测试怎么跑”。它会影响启用哪些静态分析规则、运行哪些测试项，以及相关分析参数。工具本身带有内置测试配置，用户也可以创建自己的配置，并通过本地配置、DTP配置或配置文件路径来调用。

　　1、从内置配置复制一份再修改

　　不要直接改内置的Recommended Rules、MISRA、CERT这类配置。更常见的做法是进入【Parasoft】→【Test Configurations】，找到接近需求的内置配置，然后复制或另存为用户配置。比如项目要做MISRA检查，就可以基于MISRA相关配置复制一份，再关闭暂时不适用的规则，补充项目自己的命名、注释、复杂度或安全检查要求。

　　这样做的好处是后面升级C/C++test或切换机器时，内置配置仍然保持原样，项目自己的规则也能单独维护。尤其是团队协作时，不同项目最好不要共用一个随手改过的配置，否则后期很难解释为什么某些规则突然被关闭了。

　　2、把用户配置保存成可迁移文件

　　用户自定义测试配置通常可以作为.properties文件保存和迁移。C/C++test支持从user://、dtp://、本地文件路径或URL指定测试配置；DTP中的用户配置也可以下载到安装目录下的configs/user目录，作为.properties文件使用。

　　如果只是复制给同事使用，可以把对应的配置文件放到对方C/C++test可识别的用户配置目录里。命令行场景下，也可以直接通过文件路径调用：

　　cpptestcli

　　-config"C:DevelConfigsProject_MISRA.properties"

　　-compiler gcc_9-64

　　-input cpptest.bdf

　　-report"C:report"

　　这里比直接写配置名更直观，尤其适合流水线。配置文件跟项目仓库一起管理时，也能减少“我电脑有、你电脑没有”的问题。

　　3、用配置目录统一管理

　　如果团队有多个测试配置，不建议每个人都手动复制到安装目录。可以在本地设置里指定用户配置目录，例如：

　　configuration.dir.user=C:\parasoft\cpptest\configs\user

　　configuration.dir.user用来指定用户自定义测试配置所在目录。默认安装目录不是唯一选择，团队可以把配置集中放到固定路径，再让GUI或命令行都读取这套目录。

　　命令行里还可以用下面的方式检查当前能识别到哪些配置：

　　cpptestcli

　　-listconfigs

　　-listconfigs会列出可用测试配置，适合在迁移后确认配置名有没有被工具识别。

　　Parasoft Documentation

　　二、C/C++test测试配置迁移后为什么失效

　　测试配置迁移后失效，不一定是配置文件坏了。很多时候，真正丢的是配置依赖的环境，比如自定义规则目录、编译器配置、工作空间路径、DTP连接、报告路径或本地settings文件。

　　1、配置名能写出来，但工具找不到

　　命令行里常见写法是：

　　cpptestcli

-config "user://Project_MISRA"

-input cpptest.bdf

-report "C:\report"

　　如果迁移后提示找不到配置，先看Project_MISRA.properties有没有放到当前机器能识别的用户配置目录。user://调用的前提，是这个配置已经在用户配置目录里被识别；如果配置只在原机器上存在，新机器没有复制文件，自然会失效。

　　2、自定义规则没有一起迁移

　　很多团队会在测试配置里启用自定义编码规则。配置文件复制过去后，界面里看起来规则还在，但实际运行时可能报规则缺失，或者某些规则不生效。原因通常是只复制了测试配置，没有复制对应的自定义规则文件。

　　自定义规则需要放在默认的rules/user目录，或者放在用户指定的规则目录中；配置中启用了规则，不代表规则文件本身也跟着迁移。

　　如果项目用了RuleWizard规则、规则映射文件或团队自定义编码规范，迁移时至少要一起检查这些内容：

　　1、自定义测试配置.properties文件是否存在。

　　2、自定义规则文件是否复制到规则目录。

　　3、rule.dir.user或cpptest.rule.dir.user指向的路径是否有效。

　　4、规则映射方式是否和原机器一致。

　　cpptest.rule.dir.user和rule.dir.user都可以用来指定自定义规则相关目录。路径换了以后，如果这个设置没有同步，配置就可能只剩下“外壳”，真正的规则加载不进来。

　　3、本地环境参数没有迁移

　　测试配置只解决“测什么、怎么测”的一部分问题，C/C++test运行时还会依赖工作空间、资源范围、编译器、报告输出、本地settings等信息。命令行常见关键参数包括-data、-config、-resource、-report、-localsettings等。

　　三、迁移后配置失效怎么排查

　　测试配置迁移排查，不建议一上来就重建配置。先确认配置能不能被识别，再看规则和路径，再看编译与输入数据。这样更省时间。

　　1、先确认配置是否被识别

　　迁移后先运行：

　　cpptestcli

　　-listconfigs

　　如果列表里没有你的配置，说明问题在配置放置位置、配置目录设置或DTP连接上。这个阶段不用急着改规则，因为工具连配置都没加载到。

　　如果列表里有配置，但运行时报错，再看命令里写的是不是同一个名称。builtin://、user://、dtp://不能随意替换。内置配置、本地用户配置、DTP配置属于不同来源，名字相似也不是同一个配置。

　　2、再检查配置依赖项

　　配置能识别之后，继续检查自定义规则目录、编译器配置、输入文件和本地settings。比如：

　　cpptestcli

-config "user://Project_MISRA"

-compiler gcc_9-64

-input cpptest.bdf

-localsettings "C:\parasoft\settings\project.properties"

-report "C:\report"

　　这里每一项都可能导致迁移失败。-compiler指向的编译器配置在新机器上是否支持，cpptest.bdf里的路径是否还存在，-localsettings文件是否复制过去，报告目录是否有写入权限，都要逐一看。C/C++test的命令行运行本来就依赖这些参数组合，测试配置只是其中一块。

　　3、团队配置建议放到统一位置

　　如果只是个人使用，把.properties文件复制到用户配置目录就可以。若是团队项目，更建议把测试配置、自定义规则、规则映射、本地settings模板放到版本库或统一共享目录中，再让命令行通过固定路径调用。

　　比较清楚的目录可以这样安排：

　　tools/parasoft/configs/Project_MISRA.properties

　　tools/parasoft/rules/

　　tools/parasoft/settings/cpptest_localsettings.properties

　　tools/parasoft/scripts/run_cpptest.bat

　　这样新成员接入项目时，不需要到处问“配置文件在哪”。流水线执行时，也不用依赖某台电脑安装目录里的隐藏配置。配置迁移最好做到可复现，而不是靠手动复制。

　　总结

　　C/C++test测试配置复制，建议从内置配置复制一份，再保存为项目自己的用户配置或.properties文件。迁移时不要只复制测试配置本身，还要同步自定义规则、规则映射、本地settings、编译器配置、DTP连接和路径设置。