在嵌入式软件、汽车电子或者工业控制这些项目里，碰到MISRA工具怎么选型、检查工具和人工评审如何分工的问题，我们不要只看工具宣传页上写了支持多少条规则，因为MISRA检查会涉及编程规范、编译器的特性、静态分析的设定、偏差的批准还有评审的记录，工具的任务是把那些能自动找出来的问题尽早地暴露出来，而人工评审则要处理工具判断不了的问题，这些问题需要结合设计意图和项目背景才能确认，MISRA Compliance:2020里面也清楚地提到，在挑选静态分析工具的时候，工具应当尽可能多地去执行指南里的检查，并且要有检查整个程序的能力，不能只检查单个的源文件。
一、MISRA工具选型怎么做
在给MISRA工具选型的时候，我们最先要看的，是项目所用的语言、标准的版本和编译的环境，项目到底是用C语言还是C++语言，采用的是MISRA C还是MISRA C++，编译器有没有用到它特有的扩展功能，这些都会影响到工具的配置和检查出来的结果。
1、确认标准的版本
我们需要先弄清楚项目要求的是MISRA C:2012、MISRA C:2023，还是MISRA C++有关的版本，不要在计划里只写一句“执行MISRA检查”，而应该在项目计划或者质量计划当中，把版本、适用的范围、要排除的目录以及第三方代码的处理方式都写清楚。
2、去看规则的覆盖能力
我们要去看工具供应商给出来的规则覆盖表格，重点看一看强制性的、要求性的和建议性的这几类规则，分别被支持到了什么程度，光看覆盖了多少条规则还不够，还得看哪些规则可以由工具完全自动地检查，哪些规则只会给出提示，又有哪些规则需要人工再去补充检查。
3、去看跨文件分析的能力
我们还要考察工具的跨文件分析能力，因为很多MISRA方面的问题，光靠单个.c文件是判断不出来的，比方说外部对象的声明、函数接口是不是一致、类型的传播、宏定义带来的影响等等，在选型的时候，要去测试一下这个工具能不能按照整个工程来做分析，能不能读得懂编译的命令、头文件的路径、宏的开关还有目标平台的配置。
4、去看误报处理的能力
静态分析工具是没办法做到完全没有误报的，MISRA Compliance:2020里也说明了，理想的工具应当能发现所有的违规，同时又不产生误报，但实际当中这种状态是做不到的，所以我们选型的时候，要关注工具在找出问题的能力和误报的数量之间，能不能达到一个比较好的平衡。
5、去看流程集成的能力
在真实的项目里面，工具需要能够接入本地的构建、持续集成、代码评审还有缺陷管理这些环节，如果工具只能在自己的界面上单独跑一次报告，那么后面去做整改和闭环就会非常吃力，建议大家去测试一下它的导出格式、基线的管理、增量的检查、负责人的分派以及历史趋势的统计这些功能。
二、MISRA检查工具和人工评审怎么分工
MISRA检查这件事，不能把所有的责任都推给工具，合规性文档里也指出，光靠人工去检查，在理论上是行得通的，但是会非常耗费时间，而且也很容易出错，所以在现实的工作流程里，一般都会至少用上一款静态分析工具。
1、批量扫描的工作，适合交给工具去完成
它可以处理那些能够被规则清楚地识别出来的问题，比如语法层面的、类型层面的、控制流、数据流、宏的使用、隐式的转换、未初始化的变量、死代码还有命名的冲突等等，这类问题数量往往很多，靠人工一行一行去看的话，效率会很低，而且还容易看漏。
2、需要结合具体语境来判断的部分，就要交给人工评审了
人工评审要去看工具报告背后所反映的设计想法，比如说，某一个强制的类型转换，是不是因为要操作硬件寄存器才那样写的，某一个宏，是不是来自平台适配的那一层，某一段代码，是不是已经被评估过，属于可以留下来的旧代码，做这类判断是离不开对需求、架构、接口协议还有安全分析的了解的。
3、工具的报告出来以后，要做分类的处理
我们不要简单地只分成“通过”和“不通过”这两类，可以按照真实的违规、可能的违规、误报、还有那些不属于MISRA范围但是需要关注的问题，来分别进行处理，MISRA Compliance:2020对检查消息的分类也给出了相似的思路，同时还要求有关的调查记录，要经过合格的技术人员去评审和批准。
4、人工的确认，不能变成给问题找理由
那些能够修改的代码，应该优先去把它改掉，确实没有办法修改的，才让它进入偏差处理的流程，比如底层驱动、编译器的一些特性、对性能很敏感的代码，如果确实需要作为例外来处理，那就要把风险、影响的范围还有补偿的措施都说明清楚。
三、MISRA偏差记录怎么留
MISRA的偏差记录，是把工具检查和人工评审衔接起来的地方，要是没有偏差记录，到了项目的后期，我们就很难向客户、审核的一方或者功能安全的评审去说明，为什么某一条规则没有按照常规的方式去处理。
1、要建立好规则的执行计划
在项目刚开始的时候，我们就要建立好规则的执行计划，也就是Guideline Enforcement Plan，在里面写清楚每一条规则，是由编译器来检查、由静态分析工具来检查，还是由人工评审来检查，合规性文档要求，要把工具的版本、配置文件、调用的选项、工具能够发现对应违规的证据，还有人工流程的各种细节，都记录下来。
2、偏差的记录要跟具体的代码绑定在一起
不能只是笼统地写一句“项目需要”，它一定要绑定文件、函数、规则的编号、代码的片段、触发的原因、处理的意见还有批准的人，这样一来，等到后面代码发生了变更，我们才能判断这个偏差是不是还有效。
3、要保留一个复核的机制
在每次版本发布以前，最好是把那些还没有关闭的问题以及已经批准的偏差，都重新检查一遍，因为代码改动之后，原来偏差所依据的理由，可能就已经站不住脚了，不能一直沿用旧的记录。
4、要把责任的边界给划清楚
工具负责给出报告，开发人员负责去做整改和解释，评审人员负责去判断整改的理由是不是成立，而项目负责人则要负责接受剩余下来的风险，把这些分工都写明白，MISRA检查才不至于变成临近交付时，只是走个形式扫一遍的那种工作。
总结
总结来说，MISRA工具怎么选，检查工具和人工评审又如何分工，关键就是要把“自动检查”跟“人工判断”这两件事情分开，工具选型时，我们要去看标准的版本、规则的覆盖情况、跨文件分析的能力、对误报的控制还有流程的集成，而人工评审时，要去看设计的背景、偏差的理由、风险的影响还有整改能不能闭环，如果在项目的早期，我们就把规则执行计划、工具的配置以及偏差批准的流程都确定下来，那么后面的MISRA检查，就不会变成反复去补报告、补说明、补截图的那种被动工作了。
