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

　　一、C/C++test静态分析怎么跑

　　C/C++test跑静态分析，核心不是单独找一个“扫描”按钮，而是先选对测试配置，再用合适的方式把工程喂给分析引擎。官方说明里明确写到，不管是从GUI还是命令行启动，测试都是基于Test Configuration运行的。

　　1、先选静态分析用的Test Configuration

　　官方流程里第一步就是选择或创建一个带静态分析规则的Test Configuration。这里面会定义检查哪些规则、是否启用更深层的数据流分析、以及一些分析细节，所以它相当于整次静态分析的总开关。

　　2、GUI里直接按选中资源启动

　　如果你是在图形界面里跑，最稳的做法是先在项目树里选中项目、目录或文件，再启动测试。官方说明还特别提到，如果你只想扫一部分资源，可以用Ctrl加点选或Shift加连选的方式先框出目标资源，然后再运行分析。

　　3、命令行要先把输入入口喂对

　　如果你走cpptestcli，入口不是随便给一个源码目录就结束，官方支持的输入源包括build data file，也就是bdf文件、Visual Studio工程和解决方案文件，以及CMake生成的compile_commands.json。也就是说，命令行跑静态分析时，先把输入源类型定对，比后面补参数更关键。

　　4、现有构建系统优先先收集build data

　　如果项目本身靠Make、CMake或其他现成构建系统维护，官方更推荐先用cpptestscan或cpptesttrace收集构建过程，生成build data file，再让C/C++test基于这份数据做后续分析。这样编译选项、包含路径和工具链信息会更完整，静态分析结果通常也更稳。

　　二、C/C++test扫描范围与入口怎么设置

　　静态分析为什么有时扫太多，有时又漏代码，问题通常不在规则，而在范围和入口没定好。官方把这一层主要放在Scope tab和资源选择里处理，所以这部分最好在运行前就先调顺。

　　1、入口先按工程来源来定

　　如果你是IDE工程，就直接用工程或解决方案当输入入口；如果你是外部构建系统，就优先给bdf；如果你已经有compile_commands.json，也可以直接拿它做输入。入口一旦和真实构建口径不一致，后面即使跑起来，分析上下文也可能不完整。

　　2、范围可以先靠资源选择收一层

　　官方在GUI文档里写得很直接，先在项目树里选中你要测的项目、目录或文件，再开始测试，这本身就是第一层范围控制。这个做法特别适合临时只扫某个模块、某个提交目录，或者先做局部验证。

　　3、再用Scope tab细化到文件和代码行

　　如果你不只是想选几个文件，而是想把范围长期固定下来，就要进Test Configuration的Scope tab。官方说明里提到，这一页可以配置过滤条件，限制测试配置覆盖的代码范围，还支持基于源码管理数据只测本地改动、某个截止日期后的改动，或最近若干天内变更的代码行。

　　4、头文件要按真实包含关系理解

　　这一点特别容易误判。官方FAQ说明，C/C++test直接分析的是C和C++源文件，头文件是间接分析的，也就是只有被当前待测源文件包含的头文件，才会一起出现在结果里。所以如果你觉得某个头文件没被扫到，先不要急着改规则，先看是不是没有被所选源文件实际带入。

　　三、C/C++test日常扫描口径怎么定

　　真正让扫描稳定下来，不是每次手工临时点一遍，而是把入口、范围和配置口径固化。只要这三层先定住，后面的本地扫描、门禁扫描和夜间全量扫描就不容易互相打架。

　　1、本地自检优先扫改动范围

　　开发自检更适合把Scope tab收到本地改动文件或改动代码行，这样反馈快，也更适合提交前先清掉新引入的问题。官方已经提供了基于源码管理数据的范围过滤能力，这一层最适合放在日常自检。

　　2、集成扫描优先用稳定入口

　　CI或夜间任务更适合固定用bdf、工程文件或compile_commands.json这类稳定输入，而不是每次靠人工选目录。因为官方命令行文档本来就把这些对象定义为正式输入源，它们更适合作为自动化入口。

　　3、规则和范围不要放在同一个地方乱改

　　Test Configuration里的Static tab管的是怎么分析，Scope tab管的是分析哪些代码。实际落地时，最好把规则改动和范围改动分开维护，不然今天觉得问题太多去缩范围，明天又为了提速去关规则，最后谁也说不清到底是口径变了还是代码变了。

　　4、先用一套固定模板再扩展

　　比较稳的做法，是先沉淀一套团队常用的静态分析配置模板，里面把入口类型、基础规则和Scope口径都定好，后面再按项目差异做小范围调整。这样新项目接入时，不必每次从零开始试。这个建议是基于官方把分析建立在Test Configuration之上的机制推出来的。

　　总结

　　C/C++test静态分析怎么跑，关键不是先点运行，而是先把Test Configuration和工程输入入口定对。C/C++test扫描范围与入口怎么设置，重点也不是只选几个文件，而是把资源选择、Scope tab过滤和头文件间接分析这三层口径同时理顺。这样做下来，本地自检会更快，集成扫描也更容易稳定。