把代码分析的任务交给流水线之后，总不能每次都由人工点开界面去操作，所以就需要弄明白C/C++test怎么通过命令行批量地跑，以及命令执行完返回的那些数字该怎么看，这里主要用到的是一个叫cpptestcli的程序，批处理脚本、Shell脚本或者持续集成任务都可以把它调起来，用来做静态分析、单元测试、报告生成和结果上传，不过命令行模式需要专门的许可证，在正式接入流水线之前，最好先在构建机上单独让它跑通一次，确认环境没有大问题。

　　一、C/C++test命令行怎么批量执行

　　在正式开始批量执行之前，得先把输入的范围、要用哪套测试配置、工作区放在哪里，还有报告输出到哪个目录这些都定下来，要是把一堆参数临时写死在命令里，等换到另一台构建机上，常常会碰到路径或环境变得不一样而跑不起来的情况。

　　1、确认cpptestcli能够正常运行

　　你可以先到构建机上C/C++test的安装目录下面，直接执行cpptestcli，看看它能不能把帮助信息给弹出来，也可以顺手把安装目录加到系统的PATH变量里面；要是敲完命令没有反应或者启动就报错，那应该从安装路径和许可证的状态着手去查，不用一上来就怀疑是项目配置出了毛病，按照官方文档的说法，命令行模式正是通过cpptestcli这个入口来启动的。

　　2、准备好输入文件

　　如果之前已经拿到了compile_commands.json或者bdf文件，那就可以拿-input这个参数把它给指定进去，这份数据库里需要带着源文件的真实路径、编译器的信息、头文件所在的目录，还有用到的那一串宏定义；如果只是在做增量编译，那数据库里面很可能就只记下了少量发生变化的源文件，这样很容易漏掉整块整块的模块，所以更稳当的做法是在生成数据库之前先跑一版完整的全新构建，把所有的编译动作都抓进来。

　　3、指定好测试用的配置

　　这时需要借用-config参数来告诉工具要挑哪套规则集，它既可以是软件自带的，也可以是用户自己定制的，还可以是从DTP上面直接取过来用的，官方的命令行选项里面就支持builtin://、user://和dtp://这几种写法；在项目里成批地执行分析的时候，规则集的名称最好能固定下来，不要在不同的流水线里面各用各的叫法，否则到最后得出来的分析结果就很难互相比较了。

　　4、把工作区和报告目录单独设好

　　比较推荐的做法是给每个项目切出一块独立的工作区，用-workspace来落地，再用-report指定报告往哪里放，如果还想把分析结果自动传到DTP上面去，还可以额外加上-publish参数，用-showdetails能让控制台吐出来的信息更加详细，日后万一跑失败了回头查日志时也会省掉很多力气；这里有一点要特别留意，官方文档也明确提醒了，同一个workspace在同一时间只能跑一个C/C++test实例，所以不要把几个并发任务挤到一个工作区里去。

　　二、C/C++test命令行返回码怎么解读

　　解读返回码的时候，心里最好先把它们分成两种情形：一种是因为某种原因工具自己没能正常执行到最后，另一种是扫描确实跑完了，但在代码里面揪出了违规的地方；流水线脚本可不能一见到非零的值就直接断定是工具本身趴窝了，那样判断很容易跑偏。

　　1、返回码是0代表任务顺利完成了

　　返回一个0，是说这条命令从头到尾跑顺了，可这里的顺利并不等于源代码里面一个警告都没有，如果命令里面没有加上-fail这个选项，那么就算扫描时发现了静态分析问题，程序还是可以照常退出的，并不会往上抛出一个错误。

　　2、碰到130到135这一段的码，先往环境那头去查

　　一般返回130是说命令的写法有问题，或者后面跟的资源压根儿就找不到；131表示指定的那个workspace正被别人用着；134是许可证这边出了状况；135则代表程序跑着跑着自己崩掉了，这个时候就得去翻一翻详细的错误日志，凡是在这个区间的返回码，最先应该查一下命令参数、文件路径、是不是有并发任务在争抢，再核对一下许可证的状态，把这些外部的东西逐个排除一遍。

　　3、有些版本还会把配置问题拆得更细

　　一部分C/C++test版本还会继续用到136到140这些码，它们分别表示测试配置不对、输入范围有问题、编译器配置出了错、规则配置出岔子或者settings配置方面的事情，因为不同产品版本里的返回码范围可能会有些出入，每次升级完版本以后，都要重新瞄一眼当前版本所对应的文档，不要光凭老经验去套新的情况。

　　4、一旦加上了-fail，得学会看返回值里面的位组合

　　当把-fail这个参数用上以后，只要被检测出问题，返回的就一定不是零了，其中0x2对应的是静态分析发现的违规，0x4对应单元测试的违规，0x40则是设置类的毛病，万一好几类问题同时冒出来，这个返回值就会把它们叠到一块儿去，所以不能傻傻地只拿一个十进制的数字去机械判断，最好能把它拆成二进制的位来看，分开去理解各自的意思。

　　三、C/C++test批量任务怎么留下排查证据

　　命令行的任务偶尔跑败一回，留下来的一份日志往往比匆匆再跑一次要有用得多，所以在流水线里面，最好把这一次到底敲了什么命令、返回了哪个码，还有最后生成的报告都一块儿归档保存下来。

　　1、留下完整的控制台输出

　　每一次任务跑完之后，都把cpptestcli打到控制台上的那整份日志给存下来，同时别忘了打开-showdetails开关，失败以后先顺着日志去确认命令是不是真的已经进到分析那一步了，然后再去分别确认输入文件、规则配置还有许可证这些环节有没有成功加载，一步步顺藤摸瓜。

　　2、随手记下这次执行的关键参数

　　像workspace的路径、输入的到底是哪个文件、选了什么规则集、报告扔在了哪里，还有这次的构建编号和源码分支，这些信息最好都统一地记上一笔，等下一次发现分析结果的数量忽然波动时，就可以先回过头去看看输入范围是不是变了，配置是不是被人动过，从最基础的元素开始排除干扰。

　　3、把质量门槛没过和工具本身的故障分开看

　　看到返回码是0x2或者0x4的时候，一般就说明静态或单元测试的分析已经跑完了，只是设好的质量门禁没能通过，而碰到130、134或者135这类情况，倒更像是运行环境或者执行过程当中自己先折了，前一种和后一种问题得各走各的路子去处理，别把它们都算成“分析失败”的同一笔账。

　　总结

　　总的来看，C/C++test的命令行怎么批量执行，以及它的返回码又该怎样去解读，实际上可以按“先备好输入，再定下配置，把工作区固定住，生成报告，最后去读懂返回码”这种顺序来一步步处理；流水线里一旦把-fail加上了，还必须分清楚到底是因为违规项没过关，还是工具自己跑出了故障，只要把参数、日志和返回码这几样东西都妥当地保留下来，等批量任务哪天真出了问题，才能很快地找到根子。