做静态分析最怕的，不是规则少，而是规则一开始就配乱了。有人上来全开，结果告警一片红，开发根本不看；有人嫌误报多，干脆关掉一大半，最后留下来的又不足以支撑代码治理。C/C++test本身内置了大量静态分析规则，规则按类别和严重级别组织，真正执行检查时依赖的是测试配置，也就是Test Configuration，所以规则管理的关键不是临时点开点关，而是先把配置结构搭稳，再去做启用、禁用和分层。

　　一、C/C++test静态分析规则怎么配

　　规则怎么配，别从问题列表倒着推，先从团队目标正着建。你这次是为了抓通用缺陷、推编码规范，还是为了做安全合规，起点不同，后面启用的规则集就不会一样。官方文档里把规则按类别整理得很清楚，这正好说明配规则时不该一把梭，而该先分目的再下手。

　　1、先定一套基准规则集

　　先挑一套能代表当前目标的基准配置，不要一上来就把所有类别全开。C/C++test内置规则覆盖缺陷分析、编码规范、重复代码、安全、优化等多个类别，严重级别也分成五档，基准规则集先把真正影响质量和风险的部分拉出来，后面再逐步加深，比一次性铺满更稳。

　　2、从现成配置复制后再改

　　实际操作时，先进入【Parasoft】里的【Test Configurations】，选一个最接近需求的内置配置作为底稿，再复制出项目自己的配置去改，不要直接拿内置配置长期硬跑。官方明确建议在正式执行前准备自定义测试配置，而且后续所有规则、范围和执行方式，本来就是围绕测试配置来调的。

　　3、按层级配规则，不按情绪配规则

　　比较顺手的做法，是先保留一层团队通用规则，再根据项目类型加第二层专项规则。比如基础层偏通用质量，专项层再补安全或规范要求。这样做的好处是，后面就算要调严或调松，也是在已有层级上加减，不会每次项目一变，整套规则都被重新拆掉。这个分层方法是结合官方的类别组织方式和配置机制得出的，更适合长期维护。

　　4、把核对入口固定下来

　　规则配完以后，别只凭印象记。进入【Parasoft】里的【Test Configurations】，选中对应配置，切到【Static】，再点【Printable Docs】，就能查看这一套配置当前实际启用了哪些静态分析规则和规则说明。这个动作很适合做交接、复核和审计，能避免嘴上说开了某套规则，实际跑的却不是那一版。

　　二、C/C++test规则集启用禁用怎么管理

　　启用和禁用最怕随手改。今天为了过门禁关一条，明天为了压告警再关两条，改着改着，连谁动过配置都说不清。真正好管的方式，是把启用禁用收口到配置版本里，而不是散落在个人操作里。

　　1、把启用禁用放到测试配置层

　　C/C++test运行检查依赖测试配置，所以规则集启用禁用也应该跟着配置走，而不是让每个人临场改一遍再跑。谁负责基础配置，谁负责项目变体，先分清楚，后面管理才不会乱。官方文档也明确说明，想改检查规则、生成方式或覆盖行为，都应通过编辑已有配置或新建配置来做。

　　2、把长期禁用和临时禁用分开

　　有些规则是不适合当前代码基线，属于长期不启用；有些只是某个阶段先不看，后面还要补回。两种情况不要放在同一个配置里处理，最好保留一套基线配置，再复制出阶段配置做临时调整。这样后面要追查为什么这批代码没被某类规则扫到时，能直接回到配置版本上看，不会越查越糊。这个做法是基于官方的自定义配置机制作出的项目治理建议。

　　3、范围问题先用【Scope】处理

　　很多团队一看到第三方代码、自动生成代码告警太多，第一反应就是关规则。其实更稳的做法，是先用【Scope】或项目里的【Scope Settings】把不该扫的资源排出去。官方文档写得很清楚，测试范围可以在配置的【Scope】里限制，也可以在项目属性里通过排除资源和排除模式控制，这比为了躲无关代码而直接关规则更干净。

　　4、旧配置不能用时先处理兼容性

　　如果某套测试配置在菜单里已经变灰，就别再拿它当规则管理依据了。官方说明里提到，变灰的测试配置通常意味着它是由不兼容版本创建的，当前版本不能直接应用。这个时候先做配置迁移或重建，再谈启用禁用，不然你以为在管理规则，实际连配置本身都没跑起来。

　　三、C/C++test规则治理为什么总会越配越乱

　　规则治理越做越乱，通常不是工具不够，而是边界没立住。谁能改基线，谁能改项目配置，哪些设置团队统一下发，哪些允许本地覆盖，这几件事一开始不定，后面越配越像临时补丁。

　　1、基线配置没人守

　　最常见的问题，就是大家都能改，结果谁都说自己只是顺手调了一下。规则管理一旦没有基线配置，启用禁用就会越来越碎，最后项目之间根本没法横向比较。

　　2、共享方式没有收口

　　官方给过比较明确的团队化思路，就是先把团队级偏好配置好，再导出并放到DTP里统一分发，工具启动后再自动刷新到各安装端。这个机制的价值，不是为了多一个平台，而是为了让团队真正共享同一套规则治理口径。

　　3、本地覆盖没有边界

　　官方也允许在每台安装端对团队设置做扩展或覆盖，这很方便，但如果不规定哪些能改、哪些不能改，就容易出现团队说开着，个人机器其实关着的情况。所以共享可以放开，边界一定要先立。

　　4、结果回看没有固定出口

　　规则治理最后还是要落到结果上。C/C++test把详细结果放在【Quality Tasks】里，如果团队平时不固定用这个出口看问题，只在控制台里瞄一眼，规则开得再细，后面也很难沉淀成真正可追踪的治理动作。

　　总结

　　C/C++test静态分析规则怎么配，核心不是把规则越堆越多，而是先有基准配置，再按类别、风险和项目目标做增减。C/C++test规则集启用禁用怎么管理，关键也不是谁手快谁去改，而是把启用禁用放回测试配置、范围控制和团队共享机制里。规则一旦有了基线、有了变体、有了统一下发和固定复核入口，后面的治理就会稳定很多，不会再出现今天关一条、明天忘一条、最后整套规则谁也说不清的情况。