QAC

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

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

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

很多团队说“申请QAC认证”，表面看是在问工具认证怎么做，实际更常见的场景是三件事混在一起了，一是确认Perforce QAC这款工具本身具备什么第三方认证资质，二是向厂商获取对应的认证资料或资格包，三是把这些资料真正接进项目合规流程里。公开的Perforce官方资料已经说明，QAC本身已经通过TÜV-SÜD功能安全认证，覆盖ISO 26262最高到ASIL D、IEC 61508最高到SIL 4、IEC 62304最高到Class C等标准；另外，官方也公开提到它提供DO-330 qualification pack。换句话说，很多项目并不是“重新给QAC做一次认证”，而是把已经具备资质的工具和配套证据引入到自己的项目里。

QAC报告导出做不好，最常见的问题不是找不到按钮，而是同一个团队有人导PDF有人导HTML，文件名不统一，报告里字段口径也不一致，复评时就会被追问到底以哪一份为准。要把事情做稳，你需要先把导出路径固定成可重复步骤，再把报告格式、模板、命名与归档规则一次性统一。

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

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

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

很多团队上QAC时，真正卡住的地方不是买了工具不会点，而是第一步把它当成“装上就能出价值”的现成方案。按Perforce官方当前公开资料来看，QAC本身定位就是面向C、C++和Rust的静态分析与持续合规工具，强调的是编码规范符合性、功能安全合规和集中化结果管理；换句话说，它更适合被当成一套过程能力来落，而不是一台独立软件来摆。

QAC误报太多时，最容易走偏的做法是到处加抑制，短期看起来告警少了，长期会把真实问题和误报一起埋掉，后面做基线复评和审计复核会很被动。更稳的处理方式是先把误报来源分层，把遗留噪声与新增噪声分开，再把编译器口径、规则口径、抑制口径统一到同一条可复跑链路上，误报量才会稳定下降。

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

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

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

很多人第一次装QAC，问题并不出在安装包本身，而是出在环境没有先对齐。官方当前文档已经把Helix QAC逐步统一到Perforce QAC这一名称下，支持平台也比较明确，Windows主要是64位的Windows 10和Windows 11，Linux主要是Ubuntu 22.04、Ubuntu 24.04和Rocky Linux 9。要是系统版本不在支持范围内，或者安装器选错，后面很容易连续冒出缺组件、起不来、授权不通这一串问题。

QAC基线的作用，是把某个时间点已接受的存量告警固化下来，后续扫描只把新增问题当作治理对象。做基线时最重要的是选对基线来源与生效范围，并把基线与代码版本绑定，否则很容易出现今天是存量明天又变新增的口径漂移。

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

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

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

QAC部署这件事，表面上看像是在装软件，真正决定后面用得顺不顺的，其实是先把使用模式选对。Perforce官方文档把QAC的使用方式分成两大类，一类是桌面侧使用，也就是开发人员在本机用IDE、QA·GUI或QA·CLI做分析；另一类是服务器侧使用，也就是把分析放进CI或夜间构建流程里，再把结果上传到Validate或旧版Dashboard之类的结果平台。这个边界先分清，后面的安装、授权和资源分配才不会乱。

QAC做静态检查时，规则口径如果没配稳，常见现象是同一份代码在不同人机器上结果不一致，或者误报太多导致大家直接忽略报告。把规则配置与规则集管理做成标准流程，关键是用RCF文件把告警消息与规则映射关系固定下来，再用可回滚的启用禁用机制控制噪声与范围。