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

　　一、QAC误报问题怎么处理

　　QAC的误报在处理的时候，应当先把那一条告警拉出来，从头到尾复核上一遍，然后再去下结论，看它到底算是工具那边给看岔了，算是一种规则上面的偏离，还是说那段代码本身就确实需要动手改一改才行。有很多项目在这一点上出的毛病，就是把这么几种不太一样的情况，全给搅和到一起去了，只要是眼前这一阵子不大想去动它的，就一股脑儿地，全给它贴上一张“误报”的标签。要是这么干，越到后头，那些真正藏着的问题，它就会变得越模糊，越看不清楚。

　　1、先去看告警的那一截上下文

　　在翻看【QAC告警列表】的时候，有几样东西是需要特别留意去核对的，就是那条规则的编号、文件呆在哪个位置、触发的是哪一行代码、那个变量的来源是哪里，还有跟它关联在一起的调用关系。有些告警，你要是只把眼光落在那孤零零的一行代码上头，是会觉着它像是个误报的，可是如果再跟宏展开以后的样子、类型是怎么转换的、数组的下标还有指针的活路这些因素一块儿合起来看，说不定里面就真的埋着点什么问题。尤其是那些底层的驱动、大家都要用到的公共函数，还有跟安全方面牵涉比较深的那些模块，就不太适合只靠着以往的经验，就很快地把它给关掉了。

　　2、把误报和偏差这两样给分分开

　　误报这东西，它一般是在说，工具那套分析的本事它还不太够，结果报出来一个实际上并不会真的发生的问题；而偏差呢，它指的却是，代码确实没照着那条规则来写，可是项目这边有能站得住脚的、合理的理由，非得把这种写法给留下来不可。就好比是去访问寄存器、用到编译器自己特有的那些扩展功能，还有对硬件地址做映射的这一类代码，大多数时候，它都是更适合去走那个正式的偏差审批流程的，而不是就简单地给它写成一条误报，那样就了事了。

　　3、能动手改的问题，优先去改它

　　如果这条告警，它是能够靠着给代码增加一点边界的判断、把类型转换写得更规矩一些、把那些太复杂的式子给拆开来，再或者就是调整一下宏的写法，就能给解决掉的话，那就不太建议直接去把它标记成误报。误报这个标记，它应当是用在那种确实有证据能证明，工具这一次的判断它是不成立的这种情形下，而不是拿来让报告里头的告警条数，变得少一些。

　　二、QAC误报标记后审核记录怎么保留

　　误报的标记做完以后，接下来顶要紧的一件事，就是得让后面接手去看的人，能弄得明白当初是因为什么，才做下了这么一个判断。要是光在工具里头，去点一个忽略或者抑制的按钮，留下来的那点东西，是远远不够当证据的。审核记录它要能够说明，这个问题的来源是什么、关掉它的原因又是什么、是经过谁确认过的，还有它对应的是哪一个代码版本。

　　1、把误报的判断说明给留下来

　　在【误报说明】这个地方，应当去把规则的编号、代码文件、代码行、触发的原因、判断的依据，还有最后是怎么处理的这个结论，都给记下来。那上面写的话，不能简简单单就一句“确认是误报”就完了。更合适一些的写法，是把它给解释清楚，为什么这一条路径它不会把风险给引出来，比如说，输入的那个值的范围，它早就已经被控制住了、变量初始化的那条路径是很清楚的、宏展开出来的结果跟预先想的是一个样，再或者，这个分支在目标平台底下，它根本就不会被编译进去。

　　2、把审核人和审批的结论也保留下来

　　误报这件事，最好是由代码的负责人、质量方面的人，再或者就是安全方面的负责人来复核一下。在记录里头，要把提交人、审核人、审核的时间，还有审核的结论都包含进去。对于那些风险偏高的规则，还可以要求做上第二次确认，这么做是为了避免开发人员自己判断、自己关闭，让误报这一块的管理到最后没有了管束。

　　3、把代码版本和扫描报告关联起来

　　误报的记录，它需要和代码的提交、QAC工具的版本、规则的配置，还有扫描的报告，这些东西互相能对应得上。这是因为，代码只要被人改动过，原来那条误报所依据的理由，它可能就不再能成立了；规则集一旦升了级，原来对告警的那套解释，也有可能需要被重新拿出来确认一次。一个缺少了版本信息的误报记录，到了后面想要去追溯的时候，会是相当困难的。

　　三、QAC误报管理怎么避免失控

　　误报的管理，它不是光靠一次处理就能做好的。项目的周期越是长，那些过去的告警就越是容易堆起来，要是没有定期去复核一下，误报的那张清单，它就会变成一个长期都敞着的放行口子。比较稳当一些的做法，是把误报、偏差、已经修好了的，还有暂时搁着不修的这一类情形，都给分开来，一样一样地去管。

　　1、建立一套判定的标准

　　团队里面要提前商量好，哪些情况是可以把它标记成误报的，哪些情况是必须要动手去修改的，还有哪些情况是需要去走那个偏差审批的流程的。工具的路径分析出了错，这种情况可以考虑当作误报；违反了规则但是项目又必须保留下来的代码，那就应当去走偏差；要是仅仅是因为暂时没有时间去改的问题，那就不能把它给包装成一条误报。

　　2、定期去复核以前的历史标记

　　在检查【误报清单】的时候，要去确认一下，那些历史遗留下来的误报，它是不是还对得上当前的代码版本，还有当前的规则配置。如果代码已经被重构过了，或者是工具的版本、编译器、规则集这些东西有了变化，那么原来做下的误报结论，就需要被重新拿出来判断一次。那些已经不再存在的告警，要把它的记录给关掉；如果告警依然还存在，那就要去确认一下，原来给出来的那条理由，它还站不站得住脚。

　　3、把记录用到评审的闭环里面去

　　到了最后交付，或者是要过审计的时候，应当能够拿得出QAC的扫描报告、误报的说明、偏差的记录、复核的结论，还有整改的记录。这样一来的话，做评审的人，他看到的就不再是“告警被藏起来了”这么一回事，而是每一个关闭动作的背面，它的原因、责任人，还有那些证据，都是可以往后去追的。

　　总结

　　QAC误报问题怎么处理，QAC误报标记后审核记录怎么保留，这里面顶要紧的一条，就是不要轻飘飘地，把误报给当成一种简单的放行操作。处理的时候，先去看上下文，再把误报、偏差和真实的问题给区分开；标记完了以后，要保留好规则的编号、代码的位置、判断的理由、审核人、版本，还有扫描的报告。只有当这些记录全都是完整的，QAC的误报管理才不会演变成把告警给遮住，而是能够真正去给代码质量和过程审核，提供上一套合得拢的证据。