在把C/C++test接入Jenkins、GitLab CI、Azure DevOps或本地批处理脚本时，常见问题就是C/C++test命令行扫描怎么执行，C/C++test命令行扫描返回码怎么看。界面里点一下能跑，不代表命令行也能跑通。命令行扫描需要把测试配置、编译器配置、输入范围、报告目录和本地设置都写清楚；返回码也不能只看是不是0，还要分清楚是“扫描失败”，还是“扫描完成但发现了违规”。
一、C/C++test命令行扫描怎么执行
C/C++test命令行一般通过cpptestcli执行。不同版本和使用形态的参数会有差异，比较常见的是两类：一类是基于workspace和project resource执行，另一类是基于BDF、compile_commands.json、Visual Studio工程文件等输入数据执行。cpptestcli支持用-config指定测试配置，用-compiler指定编译器配置，用-input指定BDF或项目定义文件，也可以用-report输出报告。
1、先确认配置和编译器能识别
正式扫描前，不建议直接写一长串命令。可以先确认工具能不能找到测试配置和编译器配置：
cpptestcli-listconfigs
cpptestcli-list-compilers
如果配置名写错，后面扫描命令再完整也会失败。比如测试配置实际叫Project_MISRA，命令里却写成Project_Misra，有些环境下就会找不到。编译器也是一样，实际支持的ID要以工具列出来的结果为准，不要凭印象写gcc、gcc_9或clang。
2、用输入文件执行扫描
如果项目已经有构建数据库，常见命令可以这样写：
cpptestcli^
-config"user://Project_MISRA"^
-compiler gcc_9-64^
-input cpptest.bdf^
-report"C:cpptest-report"^
-showdetails
Linux环境可以写成：
cpptestcli
-config"user://Project_MISRA"
-compiler gcc_9-64
-input cpptest.bdf
-report"./cpptest-report"
-showdetails
这里几个参数要看清楚：-config控制跑哪套规则，-compiler控制按哪种编译器理解代码，-input提供扫描输入范围，-report指定报告输出目录，-showdetails用来增加控制台进度信息。-input可以接.bdf、Visual Studio工程或解决方案，也可以接CMake生成的JSON文件，例如compile_commands.json。
如果还没有BDF，可以通过构建跟踪生成，例如：
cpptestcli
-config"builtin://Recommended Rules"
-compiler gcc_9-64
-trace make clean all
-trace后面的内容会被当成构建命令，所以C/C++test自己的参数要放在-trace前面。这个细节很容易写错，写错后工具可能不是扫描失败，而是把后面的参数都误当成构建命令的一部分。
3、在CI里固定扫描脚本
流水线里不要把命令散写在多个地方，建议整理成一个脚本，比如run_cpptest.sh：
#!/bin/bash
cpptestcli
-config"user://Project_MISRA"
-compiler gcc_9-64
-input build/cpptest.bdf
-resource./src
-exclude./third_party
-report./report/cpptest
-localsettings./tools/parasoft/cpptest.properties
-fail
-showdetails
exit$?
这里的-resource可以进一步收窄扫描范围，-exclude可以排除第三方代码或不需要检查的目录。-localsettings适合放DTP、报告格式、许可证、项目名、session tag等统一设置。-include和-exclude可以按模式包含或排除文件，也可以引用.lst清单文件。
二、C/C++test命令行扫描返回码怎么看
返回码是流水线判断“通过还是失败”的关键，但不能简单理解成“有告警就一定非0”。默认情况下，扫描过程正常完成时可能返回0；如果希望发现违规后让流水线失败，需要加-fail参数。-fail的作用就是在发现违规或特定设置问题时返回非零退出码。
1、先区分扫描异常和质量失败
常见返回码可以分成两类。第一类是工具执行问题，比如命令写错、workspace被占用、许可证异常、编译器配置错误。第二类是质量门禁问题，比如静态分析发现违规、单元测试失败。
常见执行类返回码可以这样理解：
0扫描过程成功完成
130命令行格式错误，或引用了不存在的资源
131 workspace正在被占用
134许可证问题
135进程异常退出，需要查看错误日志
136测试配置问题
137输入范围错误
138编译器配置错误
139规则配置错误
140 settings配置问题
这些返回码通常说明命令行环境本身没有跑稳，不应直接当成“代码质量不通过”。比如138更像是编译器配置没对上，136多半要回头查测试配置是否存在、是否可用。
2、看-fail触发的质量返回码
加了-fail后，返回码才会更适合做质量门禁。常见质量类返回码包括：
2 静态分析发现违规
4 单元测试发现违规
64 发现 setup problems
这里要注意，返回码可以组合。比如返回6，通常可以理解成2+4，也就是既有静态分析违规，又有单元测试问题；返回66，就是2+64，说明静态分析违规和setup problems同时存在。64这一类setup problems还需要配置cpptest.fail.setup.problems=true才会作为失败返回。
所以CI脚本里不要只写一句“非0就是代码问题”。更合理的判断是：130—140先归为环境或配置错误；2、4、64以及它们的组合，再归为质量门禁未通过。
3、在脚本里打印返回码
这样做的好处是流水线日志里能明确看到退出码，不用只靠控制台最后几行判断。尤其是扫描日志很长时，返回码能帮助快速区分“规则发现问题”和“扫描环境坏了”。
三、命令行扫描常见问题怎么排查
命令行扫描失败时，不要一开始就改规则集。很多问题和规则无关，而是命令参数、工作目录、路径、许可证、编译器或输入文件没准备好。
1、先看命令是否完整
一条可用的命令至少要说清楚三个问题：用哪套测试配置、按什么编译器分析、扫描哪些输入。如果少了-config，工具不知道按哪套规则跑；少了-compiler，源码解析可能不稳定；少了-input或-resource，扫描范围就可能不符合预期。
命令能跑通后，再逐步加-fail、-publish、-localsettings、-exclude等参数。一次性把所有配置都塞进去，排查时反而不容易看出是哪一项导致失败。
2、检查工作目录和路径
命令行里最容易出错的是路径。比如本地用的是C:project，流水线里变成了/workspace/project；BDF里记录的是旧目录；报告目录没有写权限；localsettings文件没有被复制到构建机。这些都会造成看起来像工具异常的问题。
3、把返回码和报告一起看
返回码只能告诉你“这次命令是否通过”，不能替代报告。比如返回2，只说明静态分析发现违规，具体是哪条规则、哪个文件、严重程度如何，还要看XML、HTML或DTP报告。-report没写时，报告会生成到默认位置；写了-report后，最好在流水线里把报告目录作为构建产物保存下来，方便开发人员打开查看。-report可以指定报告输出位置，未指定时会按默认名称生成报告。
总结
C/C++test命令行扫描，核心就是把cpptestcli的关键参数写清楚：-config选择测试配置，-compiler选择编译器配置，-input或-resource确定扫描范围，-report输出报告，必要时再加-localsettings、-include、-exclude、-publish和-fail。本地能跑通后，再把同一套命令固化到CI脚本里。
