在进行C/C++test静态分析时，很多团队经常不知道如何去改规则的严重级别，也不知道怎么把级别和流水线门禁对应起来，其实严重级别不只是让告警的颜色变一下，它会直接影响到开发人员先改哪个、评审时看哪个，还会影响到CI门禁到底卡住哪些代码，一般来说，这个工具的规则严重级别是1到5级，1级是最高的，5级是最低的，这个数字代表了如果违反这条规则，代码出现严重缺陷的可能性有多大。
一、怎么去调整C/C++test规则的严重级别
大家在改规则严重级别的时候，千万不要随便乱改，比较稳妥的办法是先把项目的测试配置复制一份，然后用Rule Map功能，把规则ID、规则名字、规则分类还有严重级别这些东西，重新映射成自己团队需要的标准。
1.首先要搞清楚是改级别还是直接关掉规则
我们先进入到【Parasoft】→【Test Configurations】这个界面，把项目用的测试配置打开，在【Static】→【Rules Tree】里面就能看到所有的规则。
在这里我们要先想清楚，要是某条规则根本不适合我们的项目，那就在测试配置里面把它勾掉关闭；要是这条规则我们还想检查，只是觉得它的风险没有那么高或者更高，这时候才需要去改它的严重级别，简单来说，测试配置是用来决定哪些规则要参与检查的，而Rule Map是用来修改规则的ID、名字、分类和严重级别这些元数据的。
2.利用【Edit Rulemap】来修改严重级别的具体操作
在打开【Static】→【Rules Tree】之后，我们可以点击【Edit Rulemap】这个按钮。
然后在Rules这个页签里面添加一条映射的记录，这里一般要写上原先的规则ID，也就是像SECURITY-01或者BD-PB-xxxx这种原有的规则编号，接着在Severity这一列里面选一个新的严重级别就行了。
3.团队一起开发时需要统一导入和导出Rule Map
如果只是在自己的电脑上改了严重级别，那只能解决个人环境的问题，团队一起做项目的时候，最好把这个Rule Map导出成文件然后放到版本库里，或者用DTP来统一管起来，因为C/C++test是支持Rule Map导入和导出的；要是把测试配置直接放在DTP上面，大家也可以直接在DTP里面管理规则的映射，这样能保证所有的团队成员用的都是同一套规则定义。
二、调整规则严重级别的时候需要注意什么
虽然修改严重级别看起来只是改了改配置，但是它实际上会影响到报告的解释、缺陷的统计还有最后门禁的结果，特别是在项目要符合MISRA、CERT、AUTOSAR或者公司自己的编码规范时，不能为了让红色的报错变少就随便去降低级别。
1.不要把降低严重级别当成隐藏错误
如果发现某条告警是误报，或者现在这个地方确实不需要处理，我们应该去使用抑制规则，并且把原因写清楚，因为调低严重级别只是让它的优先级变后了，不代表这个问题就被评审通过了，比如本来是1级的空指针风险，要是把它改成4级，它其实还是会出现在报告里面的，只是看着没那么着急了；C/C++test是支持对单独某一条finding进行抑制的，要是大家不想检查某条规则的所有违规情况，其实更建议在测试配置里面直接把这条规则关掉。
2.严重级别的设置要和项目的实际风险对得上
同一条规则放在不同的项目里，处理的优先级肯定是不一样的，比如在跟安全关系很大的项目里面，像内存越界、变量没初始化、用了危险函数这些问题，通常都要保持很高的级别；但如果只是一个普通的工具类项目，像命名规范、注释格式、代码好不好读这些问题，就可以放在比较低的级别，一般来说，1级和2级更适合放那些必须马上改掉的问题，4级和5级更适合放一些代码整洁度或者以后慢慢治理的问题。
3.改了规则编号之后一定要记得更新文档
要是通过Rule Map把Parasoft原本的规则映射成了公司内部的规则编号，那么报告里面的规则ID就会发生变化，这样做虽然能和公司的编码规范对得上，但是大家一定要记得去更新说明文档、抑制规则、门禁脚本还有缺陷分派的规则，要不然开发人员看到的是新的编号，但是历史记录或者旧的脚本里面用的还是老编号，后面去复查的时候就会变得非常乱。
三、C/C++test规则严重级别和门禁怎么对应起来
设置门禁的时候，不能简单地搞成“只要有告警就让流水线失败”，比较好的是把严重级别、数量的卡点、是不是新增加的问题、还有会不会影响安全目标结合在一起来弄，否则刚开始用这个工具的时候，因为历史留下来的旧问题太多了，流水线可能天天都报错失败；但是门禁要是设得太松了，又起不到控制质量的作用。
1.在本地用命令行跑门禁主要看返回码
我们在命令行执行cpptestcli的时候，如果加上了-fail这个参数，只要扫描到了静态分析违规，系统就会返回一个不是零的错误码，在C/C++test的返回码里面，0x2代表有静态分析违规，0x4代表单元测试有违规，0x40代表有配置问题，这些问题要是同时出现，返回码还会组合在一起，不过这里需要注意，命令行返回的错误码通常只能告诉你“有没有违规”，没办法直接帮你做到“1级问题超过几个才算失败”这种很细的门禁控制。
2.在Jenkins或者Azure DevOps里面可以根据数量来设门禁
要是团队用了Parasoft Findings Plugin for Jenkins这个插件，它就可以去读C/C++test生成的XML报告，而且它支持Quality Gates这个功能，这个Jenkins插件能把构建的结果标记成成功、不稳定或者失败，大家可以在Quality Gates里面去设置门禁的类型和数量限制；如果是在Pipeline的脚本场景下，也可以在type里面去选具体用哪个严重级别或者用总数来做门禁。
3.DTP这个平台更适合用来做团队层面的质量看板
如果项目已经接到了DTP里面，建议把严重级别、规则的分类、责任人、变化趋势还有抑制的情况都放到DTP里面去统一看，因为DTP的静态分析仪表盘能看到构建的趋势、抑制的记录、开发人员的分工、修复的跟踪以及严重级别的分布情况，这很适合团队做质量的管理和领导层看汇总，我们可以让本地的CI门禁去管“代码能不能合进来”，而让DTP来回答“质量风险都在哪些地方、谁在负责处理、趋势有没有变好”这些大问题。
总结
关于C/C++test规则严重级别怎么调整，以及它和门禁怎么对应，我们可以按照这样一个思路来做：先去测试配置里面看规则有没有打开，再通过Rule Map把规则ID、名字、分类还有严重级别改掉；团队合作时要把Rule Map导出分享，或者直接放DTP上管，别让每个人电脑上的配置都不一样。这样既能把高风险的问题管住，也不会因为历史留下的低级别告警太多，把流水线卡住导致大家的工作没法往下推进。
