QAC

“QAC报告怎么生成“以及“QAC报告字段怎么按评审要求调整“，这两个问题一般不是单纯点哪里导出能说清的。真正到了项目评审的时候，评审人员看的并不是页面有多漂亮，而是报告里有没有把事情交代明白：扫描了哪些代码，用了什么规则，发现了哪些问题，哪些问题已经处理完了，哪些做了偏离或抑制，后面由谁负责。所以，生成报告之前，最好先把分析结果、规则配置和评审字段放在一起想清楚。

QAC基线怎么建立，还有QAC基线更新以后，历史问题要怎么去做对比，这在使用静态分析的时候，是经常会遇到的问题。很多项目头一回接入QAC的时候，会看到历史代码里面诊断出来的结果特别多，要是要求这一次就全部改干净，开发那边的压力会非常大，实际上也不太容易做得到。基线的用处，就是把现在已经有的那些诊断结果先固定下来，往后再把精力主要放在新增的问题、有变化的问题，还有那些必须得去改的问题上面。Perforce QAC官方文档里面也提到过，基线的诊断抑制功能，是可以在新开发周期刚开始的时候，拿来把旧的诊断警告给抑制掉的。

在嵌入式的C和C++项目里面，QAC报头文件找不到这种事，是挺常见的，它说找不到，往往倒不是代码里面真的就少了那么一个文件，而是在QAC的项目里头，没有拿到跟真实编译时候一模一样的那些包含路径、宏的定义、编译器的选项，还有工程的根目录，按照Perforce Helix QAC的文档说明，项目的文件，是需要从真实的构建环境里面，去把它相关的那些选项给提取出来的；而构建监控这个功能，也会在构建的过程当中，去把那些被编译的文件、它们的路径，还有其它的信息，全给识别下来。

在C、C++项目刚开始接入静态分析的时候，常常会碰到编译数据库要怎么去配置，还有往QAC里导入这个数据库万一失败了，又该怎么去修正的问题，QAC这个工具，它并不是只把源文件拿过来简简单单地扫一遍就完事了，它还需要知道，每一个源文件在当时，到底是怎么被编译出来的，这中间就包括了用的是哪一种编译器、头文件都从哪些路径去找、都定义了哪些宏、工作目录是在哪里，还有编译的时候都加了哪些选项，Helix QAC是支持通过命令行的方式，去用一个JSON格式的编译数据库，来把项目给同步起来的，这里面，那个最典型的文件，就是记录了编译命令的那个JSON文件。

做QAC结果评审时，最容易把团队带乱的，不是告警太多，而是把真缺陷、存量问题、可接受偏离和真正误报全堆在一张结果表里一起看。Perforce官方对QAC的定位很明确，这个工具本来就支持用过滤、抑制和基线去聚焦关键问题，而不是要求团队把所有诊断都用同一种方式处理。换句话说，误报审查这件事，关键不是“怎么把红点删掉”，而是先把结果分类，再决定哪些该修、哪些该偏离、哪些只是历史噪声。

在QAC工具里，工程导入怎样设置，导入之后头文件又找不到该怎么处理，这两个问题经常是一起出现的。出现这类情况，一般不是因为工具本身不能分析代码，而是由于在导入工程的环节里，编译环境、头文件搜索路径、宏定义和源代码的目录结构没有被完整地带入，结果分析工具在处理源代码时，无法找到需要的头文件。把代码导入QAC工程，并不是简单理解为“把源文件加进来”，更为准确的说法是，要尽量让QAC还原出真实编译器所看到的那套环境。

QAC里面冒出来的误报，应该怎么去处理它，还有给误报打好标记之后，那份要拿来审核的记录，又该怎么给它保留下来，这是把静态代码检查这套东西往项目里用的时候，比较容易碰到的一类情况。QAC给出的告警，它不是每一条都铁定代表代码里就有毛病，但是也不能说，就凭着代码能编译过去、功能测试跑着也没什么问题，就直截了当地把那条告警当成误报给处理了。处理误报这件事，它里头最要紧的那个地方，倒不是要怎么把那一条条的问题，从报告里面给弄消失掉，而是要把问题的性质到底是什么，给分辨清楚，并且得把你是怎么去判断的、那套审核是怎么走过来的，还有跟哪个版本绑在一起的这些个凭据，都一并给留下来。如果不这么去做，那等到后面再去做质量评审、过ASPICE审计，再或者遇上安全合规检查的时候，就很难去说明白，这些告警它当初到底是因为什么，才被允许关掉的了。

在项目里去看QAC的历史趋势，还有当趋势图上的波动变得不正常了，要怎么去判断，这件事的重点，并不是去盯着某一次扫描的结果在那里看，而是要去观察同一个项目，在不同的构建版本、不同的软件版本，还有用了不同的规则集的情况下，它的质量到底是怎么一步一步发生变化的，Perforce的那个QAC仪表板，它就是被拿来集中地汇总，然后展示QAC分析出来的那些结果的，每一次，你往上面上传了不同的分析结果，它都会形成一个新的快照，有了这些快照，后面才能按照时间，或者是按照构建的记录，去观察趋势是怎么变的，要是一个项目，只是在本地去生成那种一次性的HTML报告，那一般就只能看到当前这独一份的结果了，至于历史的趋势，那是需要靠着持续不断地往上传结果、把配置给统一好，还有一条稳稳当当的基线，这些条件都给凑齐了，才能够看到的。

在嵌入式的C和C++项目里面，经常会碰到QAC的增量检查要怎么去做，还有跑完增量以后，要是漏掉了一些改动，又该怎么去把它给找出来的问题，增量检查这件事，它的目的并不是要去替代全量的检查，而是要在平日里提交代码、发起合并请求，还有在持续集成跑起来的时候，能更快地去发现，那些因为新的改动才被带进来的问题，按照Perforce Helix QAC的文档说明，要想在持续集成里跑增量构建，是需要先有一次已经跑成功的全量构建，来作为基线的，然后呢，增量构建它就会去分析，那些相对于上一次成功的全量构建来说，发生了直接，或者是间接变化的文件，这里面，也包括了那些，被改过的头文件给牵连到的源文件。

很多团队在做QAC治理时，嘴上说的是“基线以后只看新增”，实际落地时却常常变成“先把老问题放着不管”。这两件事看着接近，做法却完全不同。按Perforce QAC当前官方文档的口径，基线更像是一份后续比对用的参考结果，而“只管新增违规”则要么依赖基线抑制，要么依赖后续差异分析流程。要是这两个概念没拆开，团队最后看到的往往不是新增问题，而是一堆混着老问题、改动问题和匹配失败问题的结果。

QAC的增量分析应当怎样配置，以及QAC增量分析的结果不完整又该怎样处理，这是老项目在接入静态分析时很容易碰到的问题。如果每次都跑全量分析，时间会拖得很长，CI流水线也容易被拖慢；但如果只做增量分析，又担心某些受到影响的文件没有被扫描到。QAC的增量分析，更适合用在日常提交、合并请求和分支检查这些场景中，用来尽早地发现新增的问题，但是它不应当完全替代周期性的全量分析。在CI场景下，增量分析通常需要依赖已有的基线，并且着重关注由本次变更所带来的新增问题。

想要搞懂QAC的分析结果怎么看，还有分析结果里的调用路径怎么定位，不能只盯着告警的总数量不放；QAC的静态分析结果，一般会按文件、消息等级、规则组、诊断信息这几个维度来展示，使用的人要先分清问题属于哪种类型，是违反了编码规则，是数据流出了问题，是跨模块带来的问题，还是项目配置不对引发的分析异常。Perforce的QAC官方文档里也写了，在图形界面里，可以通过Files、Message Levels、Rule Groups和Analysis Results/Diagnostics这些面板，来查看完整的分析内容。

在给QAC划定分析范围的时候，关键是要先分清楚，哪些代码是必须要进到规则检查里面去的，又有哪些，只不过是第三方的库、机器自动生成出来的代码、历史归档留下来的东西，或者是临时构建出来的产物，QAC的命令行工具，它可以去分析单个的文件，也可以去分析整个QAC的项目，或者是CMA的项目，在默认的情况下，它只会去把那些发生了变化的文件，还有那些依赖着它们的文件，或者是相关的设置，给重新分析一遍；要是你动手去执行了清理的操作，那它就会把之前分析的结果给删掉，等到下一次再去跑的时候，就会触发一次从头再来的重新分析。

在代码静态分析跑完了以后，有时候会碰到一种情况，就是分析的结果，在工具里面看着倒是挺好的，可一旦到了要拿去交付给评审的时候，光靠那个界面就不太够用了，项目组这边，通常是需要去导出像代码评审报告、MISRA合规报告，还有标准符合性报告，这一类的文件，好把它们交给研发的负责人、质量的团队，或者是客户那边去做审核，QAC它是支持在项目的级别上，去生成报告的，也可以通过命令行的方式，基于项目分析的结果去出报告，这里面，常见的报告类型，就包括CRR、MCR、SCR等等好几种。

在QAC里做规则裁剪，真正要先分清的一件事是，规则本身和消息本身不是一回事。Perforce官方文档写得很清楚，QAC用RCF，也就是Rule Configuration File，来定义分析过程中发现的warning messages和规则之间的映射关系；项目里的Rule Configuration面板会按层级树的方式展示这些规则和子组，选到最底层规则时，才能看到实际关联的enforcement messages。也就是说，所谓“裁剪规则”，本质上不是把分析器关掉，而是在项目层面对哪些消息归入哪些规则、哪些规则纳入当前合规口径做配置。

QAC的MISRA检查应当怎样开启，以及QAC的MISRA违规项应该怎样筛选，关键之处不在于把项目导入后仅仅运行一次分析就结束，而在于要先弄清楚项目的语言、编译配置、MISRA版本和规则集这几项是否彼此匹配。Perforce QAC这个工具支持C和C++的静态分析，也支持MISRA规则检查，官方资料里也说明它覆盖了MISRA C与MISRA C++的多个版本，包括MISRA C:2023、MISRA C++:2023等规则体系。

QAC规则配置要怎么设置，QAC规则配置和项目编码规范要怎么匹配，这类问题在嵌入式C/C++开发项目中经常出现；很多团队最开始只想着把MISRA检查运行起来，等到真正接入工具之后才发现，并不是把所有规则全部打开就可以完成设置。QAC常被用于C/C++代码的静态检测、缺陷排查和编码标准合规校验，在安全关键软件、车载软件这类项目中应用较多，规则配置如果和项目编码规范不相匹配，扫描结果就难以发挥实际作用，开发人员也容易将这款工具视为额外的工作负担。

在MISRA检查、代码合规审计和版本升级之后，经常会碰到QAC的规则集要怎么去管理，还有把规则集升了级，结果却出现了波动，又该怎么去分析的问题。QAC的规则集，并不是去简单地开关几条规则就完事了，它会影响到缺陷的数量、严重的级别、误报的判断、历史的趋势，还有项目准入的那个结论，要是管理上没弄明白，那么一旦升级了一次规则包，结果里面突然就多冒出来几百条问题，团队那边就很难去判断，这到底是真的有风险，还是仅仅因为工具的规则发生了变化，才带来的波动。

在把QAC接入Jenkins的时候，需要留意一点，就是它那个旧版的Jenkins插件，从某个版本号开始已经进入弃用状态了，虽然还在插件目录里放着，但新的项目，更建议优先去考虑命令行的方式，或者是Perforce静态分析相关的集成办法，这件事的核心，就是要把在本地能顺顺当当跑通的QAC分析流程，给挪到流水线里面去，并且让Jenkins能拿得到许可证、编译的环境、项目的配置，还有最后产出来的报告文件。

做QAC静态分析时，很多团队最容易出现的误区，不是不会跑扫描，而是把所有项目、所有组件、所有检查层级一次性全开，结果分析时间越跑越长，最后连日常提交前检查也推不进去。Perforce QAC官方文档对这件事说得很清楚，分析耗时主要受三类因素影响，也就是分析范围、并行度和是否启用整套组件。官方还明确提供了针对性能的几个关键入口，例如只分析变更文件的file-based analysis、CI场景下的incremental分析、通过`--jobs`控制并行度，以及通过`--skip-components`跳过部分组件。也就是说，QAC变慢时，真正要调的不是某一个神秘参数，而是整条分析链路。