很多团队第一次配C/C++test增量扫描，都会先去找一个叫“增量分析”的总开关。真到软件里摸一圈才发现，事情没那么简单。它不是点一下就完，而是先让工具认出源码管理里的改动，再把测试配置里的扫描范围收紧，最后根据项目情况决定要不要把头文件关联和分支对比一起补上。顺着这个思路去配，增量扫描就会比较顺；反过来，如果一开始只想着“别全量跑”，最后往往会变成要么还是扫太多，要么把该扫的改动漏掉。Parasoft官方文档也把这件事拆成了Scope过滤、源码管理接入和高级设置三部分来看。

　　一、C/C++test增量扫描怎么开

　　增量扫描这件事，表面上是在收范围，实质上是在让工具只盯着最近的变化。顺序很重要，先接源码管理，再配过滤条件，最后再看结果是否真的缩小到了你想要的那一圈，别一上来就急着跑。

　　1、先把源码管理接通

　　先进入【Parasoft】里的【Preferences】，把【Scope and Authorship】中基于源码管理计算范围的能力开起来，再到【Source Controls】里把仓库和客户端路径配完整。官方说明里写得很清楚，只有源码管理连接正常，C/C++test后面的本地改动过滤、作者过滤和分支差异过滤才有依据，不然你看到的“增量”其实只是表面设了选项，底层并没有识别到真实变更。

　　2、再到测试配置里收文件范围

　　源码管理打通以后，再去【Parasoft】里的【Test Configurations】复制一套要用的静态分析配置，进入【Scope】页，把文件过滤收成“只测本地新增或修改的文件”。这一步更像先画一个大圈，先把没碰过的文件排出去。官方对Scope页的定义也很直接，文件过滤本来就是用来按本地修改、分支差异、作者和时间来限制分析对象的，不是分析完了再去筛结果。

　　3、想再收紧，就继续收成改动代码行

　　只收文件还不算最窄。如果你只是改了一个源文件里的几行，却不想把整份文件都扫一遍，就继续在同一个【Scope】页里把行过滤收成“只测本地新增或修改的行”。官方对这层关系讲得很明白，文件过滤会先执行，只有已经通过文件过滤的文件，才会继续按行过滤往下筛，所以“只扫改动行”其实是建在“先找出改动文件”这个基础上的。

　　4、跑完别只看任务数，要看范围指标

　　很多人配置完以后，只盯着告警是不是变少了，这样判断其实不稳。更实用的做法，是去【Test Progress】里看两个指标，一个是Source Files to Check，一个是Source Lines to Check。官方把这两个指标写得很清楚，前者反映最后被纳入检查的文件数，后者反映最后真正被纳入检查的代码行数。你想确认增量范围有没有收准，看这里比看结果数量更直接。

　　二、C/C++test只扫改动代码怎么配置

　　“只扫改动代码”这句话，平时说起来很顺，真落到配置里其实分两层。一层是只扫改动过的文件，另一层是再往里缩，只扫这些文件里改动过的代码行。很多人把这两件事混在一起说，最后配出来的效果就跟预期差很远。

　　1、只扫改动文件，适合本机先自查一遍

　　如果你的目标很朴素，就是开发改完代码后先自测一下，不想把整个项目拖进来，那就优先用“只测本地新增或修改的文件”这种配置。它的好处是干脆，范围收得快，日常在桌面端用起来也最顺手。对多数开发者来说，这一层已经能把本次提交前的大部分低级问题先拦下来。

　　2、只扫改动行，适合把反馈再压短一点

　　如果文件本身很大，只改了其中一小段，那就继续往下，把行过滤也开上。这样做的核心价值不是图省事，而是把反馈时间压得更短。官方的Test Progress说明里专门提到，Source Lines to Check统计的就是被行过滤接受后的代码行数，所以配完这一步以后，你能很直观地看到分析对象是不是已经缩到你刚改动的那部分。

　　3、批处理和流水线里更适合用高级设置固化

　　如果这套增量逻辑不只是个人本机用，而是准备放到团队脚本、定时任务或者CI里，那就别只靠图形界面点选了，直接写到高级设置文件里会更稳。Parasoft官方给出的示例很明确，scope.scontrol.files.filter.mode=local用来限制到本地修改文件，scope.scontrol.files.filter.mode=branch用来按当前工作分支和参考分支的差异收范围，scope.scontrol.ref.branch可以指定参考分支。更关键的是，官方明确说明高级范围设置会覆盖测试配置里的Scope选项，所以它更适合拿来做统一口径。

　　4、头文件改了时，记得把关联编译单元一起带上

　　这一步特别容易漏。官方文档直接写了，C/C++test不能直接单独分析头文件，所以如果你改的是头文件，最好把cpptest.scope.adjuster.cu.enabled=true一起加上，让和它属于同一编译单元的源码也跟着进来。这样做不是为了扩大范围，而是为了避免表面上只扫改动，实际上却把真正受影响的上下文给切没了。

　　三、C/C++test为什么还要保留全量扫描

　　增量扫描好用，这是事实。可一旦团队把它用顺了，另一个问题也会慢慢冒出来，就是会不会以后都不用全量了。这个念头很常见，但真这么干，后面十有八九会留下盲区。官方在Scope相关说明里其实已经把这件事点透了，范围缩小以后，确实能更快，但不代表所有类型的分析都还能保持同样完整。

　　1、路径分析类规则对上下文更敏感

　　有些规则不是盯着一行代码就能下结论，它需要看到更长的调用链和更多相关资源。Parasoft官方明确提醒过，限制Scope以后，执行路径分析相关的规则更容易出现误报或漏报。换句话说，增量扫描适合抓最近新带进来的问题，不适合永久替代全局视角。

　　2、度量和重复代码检查也会受影响

　　除了路径分析，度量类检查和重复代码检查也一样。因为这类能力本来就依赖更大的样本范围，你把文件和代码行切得太碎，工具看到的只是局部，自然不容易得出完整结果。官方把这类风险写得很直接，所以增量跑得再顺，也别把它误当成“已经覆盖全部质量问题”。

　　3、本地增量适合快，服务端全量适合稳

　　官方给出的建议其实很实在，就是桌面端可以用受限Scope加快反馈，服务器上的自动构建再定期做全量分析。这个搭配很符合真实开发节奏，开发者本地先看自己改动，流水线再兜底补齐全局风险，速度和完整性两边都不会太吃亏。

　　4、想长期稳定，就把设置写进localsettings

　　如果团队打算长期用这套方式，最好把关键设置沉到localsettings里，而不是每个人手动点一遍。官方文档说明，localsettings里的参数会覆盖GUI里对应的设置，而且命令行可以直接用cpptestcli加localsettings文件来执行。这么做的好处很现实，机器换了、成员多了、脚本迁移了，增量扫描的口径还在，不容易越用越散。

　　总结

　　C/C++test增量扫描怎么开，真正的关键不是找一个总开关，而是先让源码管理识别改动，再用【Scope】把范围收成改动文件或改动代码行，最后在需要时用高级设置把这套规则固化下来。C/C++test只扫改动代码怎么配置，也不是一句“只扫最近改过的地方”就能说完，文件过滤和行过滤是两层，头文件关联、分支对比和localsettings固化又是另外几层。把这些关系理顺以后，你会发现增量扫描最适合做的是日常快速反馈，而全量扫描更适合做周期性兜底，两者配合起来，才更像一套能长期跑下去的做法。