在嵌入式工程里，MISRA静态检查的结果应该怎样去复核，以及MISRA问题单的关闭依据又该怎样去统一，这两个问题经常没有得到足够的重视。开发团队拿到静态检查的报告以后，不能只去看违规的数量是不是变少了，也不能只盯着工具是不是给出了一份“通过”的结果。MISRA的检查结果，需要能和代码的版本、工具的配置、规则的版本以及问题处理记录一一对应起来；在关闭MISRA问题单的时候，团队同样要有一个统一的口径，一个问题究竟是修改后关闭、通过偏离关闭、被认定为误报关闭，还是暂时保留下来，项目负责人都应当能够看得清楚。只要团队把复核的标准和关闭的依据统一起来，后面的代码评审、客户评审还有供应商交付，才不容易出现来回返工的情况。
一、MISRA静态检查的结果应该怎么复核
在复核MISRA静态检查结果的时候，团队先要去看报告本身是不是可靠的，然后再去看发现的问题是不是都处理到位了。很多项目会把报告导出来就当成了完成，这样做很容易留下隐患，工具生成的报告只是一个起点，复核的人员还需要确认配置、代码、规则和问题记录这几点能不能互相吻合。
1、先确认检查版本和工具配置
复核的时候，团队要先确认好工具的版本、规则集的版本、编译器的配置以及扫描的范围；假如代码是按MISRA C 2012来查的，报告里面就不能夹杂别的规则版本。要是工具没有把正确的头文件路径加载上，报告里也可能出现不少误报，所以复核的人要把检查配置和开发计划放到一起来对照：开发计划里写了哪些模块需要被检查，工具报告就应当把这些模块覆盖住。团队不能只去看报告的页数，也要看看报告是不是真的把目标代码扫描到了。
2、确认代码版本和报告版本一致
MISRA检查的结果，一定要和具体的代码版本对应上。如果开发人员在扫描完成之后又对代码做了改动，那原来的报告就不能直接拿来当作关闭的依据；复核人员需要去看提交号、分支名称、扫描时间还有代码包的版本。项目里面经常碰到的情况，就是报告跟代码对不上——开发人员已经把修复提交了，可工具报告还来自旧的代码；评审人员看到了问题被关掉，但实际代码里还没有把修改合并进去。因此，团队要把代码的版本写进问题单里面，这样后面追溯起来才会清楚。
3、区分真实问题和工具误报
代码自动检查的工具虽然能找出不少毛病，但它不一定每一次都判断得准确；复核的人既要看具体的代码位置，又要看工具给出的规则说明。团队不能一看到工具报警，就把它们全当成真实的问题，也不能因为问题数量多，就一下子批量忽略掉。真实的问题要放进整改的流程里去处理，而被当作误报的问题，则需要把判断的理由写清楚。复核人员应当说明，为什么这个检查结果并不会影响代码的运行，以及工具在这个地方是不是判断得太严了。误报不能只凭一句“这是工具的问题”就关掉了事。
4、检查整改是否真的改变了风险
开发人员把MISRA问题修改完以后，复核的人不能只盯着问题数量是不是减下去了；团队还要去看代码修改之后，有没有把新的问题带进来，同时也要看原来的风险是不是真的消除了。举个例子，类型转换的问题改掉之后，数据的范围是不是还正确；指针的问题修复以后，调用关系是不是依然清楚。复核人员要对那些重点的问题做一遍代码复查，特别是底层驱动、中断处理、通信解析、控制算法这一类模块，更要看得仔细一些，因为这些地方一旦出了毛病，后面去排查的代价会非常大。
二、MISRA问题单的关闭依据怎么统一
MISRA问题单的关闭依据该怎么统一起来，团队首先要做的，就是把关闭的类型分分清楚。问题单里的状态，不能清一色都写成“已处理”，这种写法看上去简单，但到了后面评审的时候，解释起来就会比较困难。关闭的依据既要能说清问题为什么可以结束，也要能讲清楚团队为此采取了哪些控制的办法。
1、修改关闭要有代码和复测记录
如果开发人员是通过改动代码来关闭问题单的，那么在问题单里就要写明白修改的位置、修改的方式，还有复测的结果；团队既要保留修改前后的代码差异，也要把重新扫描之后的结果保存下来。修改关闭不能只填一句“已修改”，评审的人需要看见问题是从哪里来的，开发人员是怎么去改的，工具复扫之后到底有没有通过。只要团队照着这样去做记录，以后碰到同类问题再冒出来的时候，也就有了可以参考的东西。
2、偏离关闭要有理由和控制措施
在嵌入式工程当中，有一些MISRA问题确实是没有办法直接去改动的，像硬件寄存器的访问、底层地址的访问、中断向量、启动代码还有编译器的扩展这些地方，常常会触碰到规则，碰到这一类情况，团队就可以走偏离关闭的路线。偏离关闭需要把原因写得清清楚楚，开发人员要说明为什么一定要保留现在的写法，它的影响范围在哪儿，代码有没有做隔离处理，测试是怎样覆盖的，后期又该由谁来维护。团队不能把偏离关闭当成一个躲开整改的借口。
3、误报关闭要有判断依据
工具产生的误报可以拿来关单，但团队必须把判断的依据写清楚；复核的人员要讲清楚工具为什么报警，而实际的代码为什么没有违反规则，相关的数据范围、调用路径或者宏展开的结果是不是都已经确认过了。误报关闭同样需要有人去复核，因为开发人员自己去判断误报的时候，容易带上一些习惯上的看法，让评审的人再查看一遍，结果就会稳当一些。团队可以规定，关键模块里出现的误报，一定要由项目的负责人或者质量人员来确认。
4、暂缓关闭要有期限和责任人
还有一些问题既不能马上修改，也不适合直接走偏离，比如要等供应商那边更新代码，或者等平台的接口确定下来，这类问题可以先暂缓处理，但问题单不能一直挂在那里而不带任何说明。做暂缓关闭的时候，需要写清楚责任人、处理的期限，还有下一步要做的动作；团队要讲明白，这个问题目前为什么没法处理，后面又打算怎样去解决。项目的负责人要定期去翻看这一类问题，不能由着它们长期留在列表里面。
三、MISRA的复核记录应该怎样保留
MISRA的复核记录应该怎样保留下来，团队要让这些记录，在后面评审的时候能撑得住；记录没有必要写得太复杂，但一定要写得清楚。当评审的人看到问题单时，应当能够一眼就知道，这条问题是来自哪一份报告，影响到的是哪一段代码，团队又是用什么样的方式把它关闭掉的。
1、建立统一的问题单字段
团队可以给MISRA的问题单设定一套固定的字段，这些字段可以包含规则编号、文件路径、代码行号、问题的类型、处理的方式、关闭的依据、复扫的结果、责任人还有关闭的时间。字段统一之后，不同的人写出来的记录，相互之间才好做对比。如果一个项目里只有自由的文本，那问题单的质量就会差上一大截，有的人记得非常详细，有的人只留下一句话，到后面去整理的时候就会十分麻烦。
2、把工具报告和问题单对应起来
团队需要把工具报告和问题单关联到一起去，每一条关键的问题，都要能找得到它来自哪一份报告；报告编号、扫描时间、代码版本还有工具配置，这些信息都需要保留下来。这样做带来的好处很直接——等到客户评审的时候，如果对某一条问题追问下来，团队就可以很快地找出原始的检查报告，既不用临时去翻找文件，也不用光靠某一位开发人员的回忆了。
3、定期复查关闭质量
MISRA的问题单关闭了以后，团队还需要做一些抽查，项目负责人可以定期从修改关闭、偏离关闭和误报关闭的问题里抽出几条来，看一看关闭的依据是不是充分，代码跟报告是不是保持一致。抽查的目的并不是为了给流程再增加负担，而是通过它来发现记录当中的漏洞，比如关闭的理由写得太空、复扫的报告缺失了、偏离的说明没有测试来支撑。团队早一些把这些问题找出来，评审之前就不会被集中追问。
4、把供应商问题纳入同一口径
供应商交付过来的代码，也要按照同样的口径去处理，不能让内部的代码执行一套关闭标准，而供应商的代码又执行另外一套。如果供应商提交了MISRA报告，团队就要要求他们把工具的版本、规则的版本、还没有关闭的问题以及偏离的原因都说明清楚；主项目的负责人需要对供应商的问题单也做一次复核，因为供应商的代码一旦进入主工程，问题的责任就会影响到整体的交付。团队只要把供应商的记录一并管起来，后面的集成和评审就会顺畅很多。
总结
MISRA静态检查的结果怎样复核，MISRA问题单的关闭依据又怎样统一，团队应当把关注点放在证据的链条上。MISRA的检查报告，需要和代码版本、工具配置、规则版本对应起来；在关闭MISRA问题单的时候，则要把修改关闭、偏离关闭、误报关闭和暂缓处理区分开。团队还要把复扫的结果、关闭的理由以及责任人的记录都保留好。经过这样一轮处理，MISRA检查就不会仅仅剩下一份工具报告，问题的关闭也不会只停留在“已处理”这么一句话上面。等工程走到了代码评审、客户评审或者供应商交付的阶段，团队也就更容易把每一类问题都讲得清楚了。
