C/C++test做静态分析时，检查范围由测试配置里的规则集决定。同一个工程换一套规则配置，告警数量可能差很多。老项目刚接入静态分析时，比较常见的情况是一次出现几百甚至更多告警，其中可能混有第三方源码、自动生成文件、项目当前并不采用的编码规范，以及已经评审过的例外项。处理这类结果时，先把规则集和扫描范围整理好，再处理真正属于项目源码的问题，告警列表会更容易查看和维护。

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

　　1、复制一份测试配置再修改

　　内置配置可以直接拿来执行，项目准备长期使用时，可以复制一份单独维护。

　　①打开【Parasoft】→【Test Configurations】。

　　②展开左侧【Built-in】配置列表。

　　③找到准备使用的静态分析配置，例如【Recommended Rules】。

　　④右键该配置，选择【Duplicate】。

　　⑤将复制出来的配置放到【User-defined】分类。

　　⑥修改配置名称，例如【Project Static Check】。

　　⑦选中这份配置，进入【Static Analysis】设置。

　　这样修改规则时不会影响原来的内置配置，后面也方便给项目成员使用同一套检查条件。

　　2、在Rules里增加或关闭检查规则

　　①进入【Test Configurations】→【Static Analysis】→【Rules】。

　　②打开【Show Enabled Only】，先查看当前已经启用的规则。

　　③关闭【Show Enabled Only】，可以浏览当前版本提供的其他规则。

　　④知道规则编号时，在搜索框中直接输入【Rule ID】查找。

　　⑤勾选需要检查的规则，取消暂时不用于当前项目的规则。

　　⑥选中具体规则后，查看右侧的规则说明和严重级别。

　　⑦规则带可配置参数时，进入对应【Rule Options】修改参数。

　　⑧完成后点击【Apply】保存。

　　如果项目要求检查MISRA、AUTOSAR或CERT一类规范，应按项目实际采用的规范建立规则集，不要把几套规范全部混到同一次日常扫描中。有些规则检查的代码写法接近，全部开启后很容易在同一段代码附近产生多条结果。

　　3、确认运行时使用的是修改后的配置

　　规则改好了，执行时还要选对测试配置。

　　①在【Project Explorer】中选中工程或待检查目录。

　　②右键选择【Parasoft】→【Test Using】。

　　③展开【User-defined】。

　　④选择刚才保存的静态分析配置。

　　⑤执行分析。

　　⑥打开【Quality Tasks】查看检查结果。

　　⑦按规则编号展开结果，核对本次告警是否来自刚才启用的规则。

　　使用命令行分析时，可以用【-listconfigs】查看可用配置，再通过【-config】指定测试配置。例如：

　　cpptestcli-config"user://Project Static Check"

　　二、C/C++test静态分析告警过多如何调整

　　1、先找出告警主要集中在哪几条规则

　　告警数量很多时，不用从列表第一条开始逐个改源码，可以先看哪些规则出现频率较高。

　　①打开【Quality Tasks】。

　　②按照【Rule】展开静态分析结果。

　　③查看同一规则下面集中出现了多少条告警。

　　④再按照【Resource】检查问题主要来自哪些文件。

　　⑤双击其中一条告警，跳到对应代码位置。

　　⑥确认该规则是否属于项目要求执行的检查内容。

　　⑦规则不在当前项目规范范围内时，回到【Test Configurations】→【Static Analysis】→【Rules】关闭对应规则。

　　⑧重新执行一次静态分析，对比告警数量。

　　如果某条规则属于项目明确采用的编码要求，即使数量较多也应保留，然后分批修改源码。单纯为了减少数字把规则关掉，后面很难判断代码到底有没有满足原来的检查要求。

　　2、排除第三方库和自动生成代码

　　项目源码只有几万行，结果里却出现大量库文件告警，可以检查测试范围。

　　①在【Project Explorer】中右键工程，选择【Properties】。

　　②进入【Parasoft】→【C/C++test】。

　　③打开【Scope Settings】。

　　④检查当前参与分析的源码范围。

　　⑤将无需检查的第三方库目录加入排除范围。

　　⑥代码生成工具产生、项目又不直接维护的文件，也可以按项目要求排除。

　　⑦保留开发人员实际维护的.c、.cpp和相关头文件。

　　⑧点击【Apply】→【OK】，重新运行静态分析。

　　例如项目中包含vendor、generated、third_party一类目录，可以先确认这些文件是否属于当前代码检查范围，再决定是否排除。这样不会让外部代码长期占据告警列表。

　　3、已经确认接受的告警用Suppression处理

　　某条规则需要继续启用，但其中少数位置已经评审确认可以保留，可以只抑制具体告警。

　　①在【Quality Tasks】中找到对应告警。

　　②右键选择【Suppress Task】。

　　③在弹出的窗口中填写【Reason】。

　　④希望抑制记录随工程一起保存时，选择【Suppress in suppression file】。

　　⑤确认后检查源码目录中的【parasoft.suppress】文件。

　　⑥重新执行相同静态分析配置。

　　⑦被抑制的具体结果不会继续出现在普通任务列表中，其他位置触发同一规则时仍可继续报告。

　　也可以选择【Suppress in Source Code】把抑制信息写进源码。团队不希望在业务代码里增加这类标记时，用【parasoft.suppress】会更便于单独维护。

　　三、规则调整后怎么管理后续告警

　　1、把项目规则配置固定下来

　　多人项目里，每个人各自删几条规则，跑出来的结果很难对齐。

　　①确认【User-defined】配置中的规则已经整理完成。

　　②记录本项目启用的编码规范和规则范围。

　　③将统一配置放到团队约定的位置。

　　④命令行分析时统一使用相同的【-config】配置名称。

　　⑤规则发生调整时修改共享配置，不要在每台电脑上单独改一套。

　　⑥改完后选取一批已有源码重新扫描，检查结果变化是否符合预期。

　　C/C++test也支持DTP托管测试配置。项目已经使用DTP时，可以把统一的静态分析配置放到集中配置中，再由开发和持续集成环境调用。

　　2、老项目把历史告警和新增问题分开处理

　　已有大量历史代码的工程，一次把全部告警处理完往往不现实，可以先整理现有结果。

　　①用统一规则配置执行一次完整扫描。

　　②处理容易确认的空指针、越界、资源释放等代码问题。

　　③对评审后允许保留的具体结果添加抑制记录。

　　④保存当前【parasoft.suppress】文件和测试配置。

　　⑤代码修改后继续使用同一套规则扫描。

　　⑥在新结果中重点查看新增或发生变化的告警。

　　如果某段代码改动后原有抑制失效，也要重新确认代码位置和问题是否发生变化，不要直接复制旧抑制记录。

　　3、规则数量调整后再检查扫描结果

　　修改规则集后，可以用一次小范围分析确认配置是否合适。

　　①在【Project Explorer】里选中一个代表性的源码目录。

　　②使用项目静态分析配置执行检查。

　　③打开【Quality Tasks】查看剩余规则类型。

　　④确认项目要求检查的规则仍然存在。

　　⑤确认第三方代码和明确排除的目录没有继续产生结果。

　　⑥检查Suppression是否只隐藏已经确认的具体告警。

　　⑦确认结果没有问题后，再扩大到整个工程执行。

　　总结

　　C/C++test静态分析出现大量告警时，先把规则范围、源码范围和已有例外项理清，后面的代码处理会轻松不少。项目长期使用同一套规则配置，也能避免不同成员扫描同一份代码却得到不同结果。对于已有代码较多的工程，可以分开处理历史问题和后续新增问题，让静态分析结果更便于持续维护。如需进一步了解C/C++test静态分析规则配置、告警筛选与Suppression使用方法，欢迎联系咨询。