同一份代码，换一套规则后，违规数量从几百条变成上千条，并不能据此判断代码质量突然下降。新增检查项、抑制设置变化，甚至结果窗口累积了多轮记录，都可能影响数字。处理“C/C++test如何启用并管理静态分析规则C/C++test切换规则集后违规数量突变如何分析”，需要把规则变化和分析条件分开核对。以下以Professional版Eclipse界面为例说明。

　　一、C/C++test如何启用并管理静态分析规则

　　静态分析使用哪些规则，由本次执行的测试配置决定。修改规则前，应保留原配置，方便比较和恢复。

　　1、复制配置并启用所需规则

　　①进入【Parasoft】→【Test Configurations】，右键选择接近项目要求的配置，点击【Duplicate】。

　　②在【User-defined】中选中副本，设置便于区分的名称，打开【Static】，勾选【Enable Static Analysis】。

　　③进入【Rules Tree】，通过【Filter】查找规则，勾选需要启用的项目；批量调整时，右键类别使用【Enable Rules】或【Disable Rules】中的相应选项。

　　④右键目标规则，点击【View Rule Documentation】，核对触发条件和适用范围，再点击【Apply】保存。

　　内置配置不能直接修改，应编辑副本。类别名称相似，也要继续核对标准版本和实际规则，不能只凭名称选择。

　　2、保存规则清单并确认执行配置

　　①选中自定义配置，在【Static】中点击【Printable Docs】，保存本轮启用规则的说明，记录工具与配置版本。

　　②右键配置，选择【Set As Favorite】，设置常用执行入口；运行前再次核对所选配置名称。

　　③分析结束后，在结果任务上右键选择【View Test Configuration】，检查该条违规对应的配置及规则。

　　常用配置只是便捷入口。团队共享或流水线执行时，还应确认实际调用的是同一份配置，避免同名文件内容不同。

　　二、C/C++test切换规则集后违规数量突变如何分析

　　先用同一代码提交、同一文件范围分别运行两套配置。比较时保留独立报告，别只看结果窗口里的总数。

　　1、按规则编号查看增减来源

　　①分别打开两套配置的【Static】→【Rules Tree】，核对新增、停用及共同启用的规则编号。

　　②对数量变化集中的规则点击【View Rule Documentation】，检查规则参数和适用条件。

　　③从报告中抽取对应文件及代码位置，区分新增规则检出、原规则结果变化和停用规则不再报告的情况。

　　④涉及标准规则映射时，核对底层规则编号，避免把同一处代码对应的不同标准条款当成多个独立缺陷。

　　例如，新增一项格式检查后出现大量告警，可以单独列出这部分变化，再继续比较两套配置共有的规则。

　　2、核对抑制、显示筛选和报告上限

　　①进入【Static】，比较【Do not apply suppressions】是否一致；启用该项后，原来被抑制的违规可能重新报告。

　　②核对每条规则的报告数量上限。某条规则达到上限后，报告中的数量不能代表其全部发现。

　　③在【Quality Tasks】中点击【Filters...】，检查【Show only last session tasks】及【Limit visible tasks to】。

　　④统一设置后重新分析，将本轮报告与窗口显示结果对照，检查是否混入历史会话或受到可见条数限制。

　　规则是否执行、发现是否被抑制、结果是否显示，是不同环节。清除窗口消息也不等于修复违规，后续分析仍可能再次报告。

　　3、检查分析范围和解析问题

　　①核对两轮执行选择的项目、目录和文件，检查排除范围，以及宏定义、头文件路径和编译器配置。

　　②打开【Console】，检查解析错误、分析失败和未完成的文件，确认两轮实际分析范围可比。

　　③进入【Static】，比较【Code parsing problems】的处理方式；设置为【Error】时，发生解析问题的文件可能不报告静态分析发现。

　　数量突然减少时，尤其要查看文件是否成功完成分析。少报可能来自规则停用，也可能来自解析失败，处理方向不同。

　　三、C/C++test如何建立规则切换后的结果对照

　　查明变化原因后，还要留下能支持后续比较的记录。新配置上线后，旧报告仍应保留，便于解释规则切换带来的变化。

　　1、先比较配置，再比较代码

　　①固定旧代码，分别使用旧配置和新配置完成分析，保存报告。

　　②固定新配置，再分析新代码，比较两次结果中的新增和消失记录。

　　③通过【View Test Configuration】抽查变化较大的任务，确认报告没有引用错误配置。

　　这样可以分别观察配置变化和代码变化的影响，避免两者同时变化后，仅凭净增数量归因。

　　2、为差异记录安排处理动作

　　①在【Quality Tasks】中打开代表性违规，查看对应源码和规则说明，记录确认结果。

　　②规则适用且问题成立时安排修复；规则整体不适用时，返回【Rules Tree】调整，并记录依据。

　　③仅个别位置属于可接受例外时，按项目流程维护抑制及理由。

　　④需要验证某条规则是否导致数量变化时，复制配置后仅调整该规则，使用同一代码复算。

　　抑制用于具体例外，停用规则会影响整个检查范围，两种处理不能仅按“哪种能减少数量”来选择。

　　3、复核团队使用的最终配置

　　①打开【Test Configurations】，核对最终配置的规则和分析选项，点击【Apply】保存。

　　②重新生成【Printable Docs】，随配置变更说明归档，并更新团队共享版本。

　　③使用同一组代码样本分别执行本地与流水线分析，核对规则编号、文件范围和抑制设置，再采用新配置作为后续比较依据。

　　总结

　　处理“C/C++test如何启用并管理静态分析规则C/C++test切换规则集后违规数量突变如何分析”，评审时应能解释数字为什么变化，以及变化后哪些问题需要处理。规则集升级带来的新发现有其价值，但历史趋势也需要注明检查条件，避免把检查范围扩大误读为质量退步，或把漏分析误读为改进。希望这些操作能帮助大家建立可比较的结果记录，让规则调整有依据，后续整改也有明确对象。如有C/C++test相关需求，欢迎与我们交流。