很多团队上来就把C/C++test跑起来，结果要么告警太多压不住，要么为了赶进度一路放宽，最后规则、阈值和例外混在一起，谁也说不清哪一类问题必须改、哪一类问题可以备案后放行。Parasoft的文档其实把边界分得很清楚，测试最好先基于内置配置复制出自己的配置来调，规则本身、度量阈值和抑制例外也分别有不同的落点。

　　一、C/C++test规则参数怎么调

　　规则参数这件事，最怕一边跑一边改。更稳妥的做法，是先把团队要用的基线配置单独拎出来，再在这份配置上做开关、分层和映射，不要直接拿内置配置当长期生产版本。

　　1、先复制内置配置，再开始细调

　　Parasoft明确建议在正式测试前先准备自定义测试配置，而不是长期直接跑内置配置。内置的【Recommended Rules】本身就是默认基线，只覆盖大部分Severity 1和Severity 2规则，并且已经包含【Flow Analysis Fast】里的规则，所以它更适合当起点，不适合当最终口径。

　　2、从【Parasoft】里的【Test Configurations】进入统一调参

　　规则启用、测试范围、静态分析和执行设置，都是在测试配置里集中管理的。实际操作时，先打开【Parasoft】里的【Test Configurations】，再进对应配置下的【静态】和【Rules Tree】去看哪些规则要启、哪些规则要停，这样后面GUI运行和命令行运行才更容易对齐。

　　3、同一条规则要分档使用时，别硬改原规则

　　文档里专门提到，遇到不同参数化需求时，可以复制规则实例再分别配置，而不是把一条原规则来回改。这个做法特别适合一类场景，比如同样是复杂度类检查，核心模块想收得更紧，外围模块想稍微放宽，这时候就该复制后分开管理，而不是用一条规则兼顾所有目录。

　　4、严重度、分类和规则名要通过规则映射统一收口

　　C/C++test的规则映射支持修改规则ID、规则名、严重度和分类，这些改动会作用到本地可用的测试配置，而相关信息会保存到rulemap.xml。也就是说，团队要改的不只是“报不报”，还应该把“按什么等级报、归到哪一类报”先定清楚，否则同一类问题今天叫建议，明天又变成阻断，结果会越来越乱。

　　二、C/C++test阈值与例外如何设定

　　阈值和例外看起来都像“放宽”，但两者不是一回事。阈值是在规则还有效的前提下，给出可接受边界；例外则是承认这一次不按常规处理，所以这两件事一定要分开管。

　　1、先把阈值类问题和普通规则类问题拆开

　　C/C++test里专门有【Metrics】测试配置用来算代码度量，官方文档也明确提到，度量规则可以设置上下界，超出范围时才报问题；同时也有一些指标本身不支持阈值设置。换句话说，不是所有规则都该靠“调阈值”解决，很多规则本质上还是开或关的问题。

　　2、做度量阈值时，优先复制【Metrics】配置再改

　　官方给了三种做法，可以在DTP里改，也可以在IDE里改，还可以直接改测试配置文件。手工方式的关键点很明确，先把内置【Metrics】配置复制到用户配置目录，再把对应指标的ThresholdEnabled打开，然后给Threshold写上下边界。这个顺序的价值在于，团队以后回看时能一眼看出哪些是默认门槛，哪些是你们自己定过的线。

　　3、整条规则都不想看时，应该停规则，不该堆例外

　　Parasoft在抑制说明里说得很直白，如果某条规则的任何违规都不想接收，就应当直接在测试配置里禁用那条规则；抑制只适合“总体遵守，但某个具体位置这次允许放行”的情况。这个边界要守住，不然团队很容易把suppression当成万能消音器，最后配置面上看着严格，实际却到处是洞。

　　4、例外优先做单点抑制，并且把原因写完整

　　C/C++test支持把抑制信息写进源码，也支持写进parasoft.suppress文件，还建议把suppression文件纳入版本管理，便于团队共享和复核。文档同时提醒，line这种按行号定位的抑制要慎用，因为代码一挪行就可能失效，所以真要长期留例外，优先保留原因字段，再尽量用更稳的定位方式。

　　5、碰到宏或特殊生成代码，再考虑正则型例外

　　有些位置很难靠行尾注释或块注释处理，例如某些宏展开场景。针对这类情况，C/C++test还支持基于正则表达式的行级抑制，并且可以在属性文件或命令行里配置。这个能力适合处理少数难缠场景，但不适合大面积代替正常规则治理。

　　三、C/C++test上线前先收哪几项

　　很多配置越调越乱，不是因为工具复杂，而是因为团队先跑了结果，后补规则。真要把后面返工压下来，上线前先把口径收紧，比后面一边救火一边补制度省力得多。

　　1、先定一份基线配置

　　更稳的起步方式，是先复制【Recommended Rules】做基线，再根据项目属性叠加安全规则、合规包或度量配置。因为官方已经说明这套默认基线覆盖大部分Severity 1和Severity 2规则，还把快速流分析也带进来了，所以它很适合当第一版，而不是从零散规则拼一套。

　　2、再定哪些项允许调阈值

　　复杂度、逻辑行数这类度量问题，适合用阈值管；资源泄漏、空指针、数组越界这类缺陷类问题，就不该靠抬高阈值去消化。把这两类问题分清楚后，后续讨论才不会变成一股脑地“把门槛再放宽一点”。这一点和官方把【Metrics】与【Flow Analysis】分成不同测试配置的思路是一致的。

　　3、最后定例外的落点和审批方式

　　源码内抑制更贴近上下文，适合需要长期保留并且希望审查时直接看见原因的场景；parasoft.suppress文件更适合集中管理和随分支审阅；规则映射则适合团队级严重度和分类口径统一。三种手段各有位置，别拿一种手段硬包所有问题。

　　4、把共享文件一起纳入版本库

　　规则映射文件、抑制文件和用户自定义配置，只要要给团队复用，就别停留在个人机器上。Parasoft文档已经给出导入导出规则映射、共享suppression文件以及保存到规则目录的做法，真正落地时，把这些文件和代码一起进库，后面谁改过、为什么改、什么时候改过，才有机会追得清。

　　总结

　　C/C++test规则参数怎么调，核心不是把告警数量先压下去，而是先把规则、阈值和例外三层边界分清。更顺手的落地顺序通常是这样，先复制内置配置做基线，再用规则映射统一严重度和分类，再把度量阈值放进独立配置里，最后只对确有理由的单点问题做抑制并写明原因。这样做下来，规则不会越调越散，例外也不容易反过来吃掉基线。