在TESSY中，测试对象的创建与识别不完整的排查，重点在于让TESSY获得完整的待测源码和编译环境，再通过模块分析将可测试的函数识别出来。当测试对象没有完整显示时，问题通常并不在于测试用例本身，而是源文件的范围、头文件的路径、宏定义、条件编译或者筛选规则，与正式工程没有保持一致。排查时应当先查看分析日志，再去检查预处理之后的源码内容。

在TESSY中，测试对象的创建与识别不完整的排查，重点在于让TESSY获得完整的待测源码和编译环境，再通过模块分析将可测试的函数识别出来。当测试对象没有完整显示时，问题通常并不在于测试用例本身，而是源文件的范围、头文件的路径、宏定义、条件编译或者筛选规则，与正式工程没有保持一致。排查时应当先查看分析日志，再去检查预处理之后的源码内容。

MISRA合规证据应该留到什么程度MISRA合规审查通常先看哪些材料，许多做嵌入式软件的项目全都绕不开这些事。要把MISRA合规这件事办好，并不是光把静态扫描的工具拽过来跑上一遍就行了，也更不能只把违规的条数清到零就算交了差。真正应该留下来的那些证据，是要能说清楚项目到底用了哪一个版本的规矩，查过了哪些代码段落，中间翻出来了哪些毛病，这些毛病里又有哪些已经被修掉了，哪些是经过偏离那一套审批之后特意保留下来的。在MISRA Compliance:2020这份东西里面，它特别点明了，等项目跑到收尾的时候，是该攒出来一份合规方面的汇总材料，用它去记下项目在最后被声明出来的那个合规程度。

怎样安排MISRA培训才会更有效果，以及团队在落地时常遇到的阻力该怎么去化解，这个问题不能只是被理解成给开发人员上一堂规则课。很多项目组在做MISRA培训的时候，会讲上一大堆规则编号，也讲了很多专门的概念，可开发人员回到工程里面，还是不清楚该怎么去改代码，也不清楚哪些问题是必须处理的，更不清楚例外的说明要怎样去写，要让MISRA真正落到工程里面，培训就要把代码、工具、问题单还有评审资料放在一起讲，项目组也要提前把阻力化解掉，像开发人员会感觉规则拖慢了进度，工程负责人会觉得流程变重了，供应商会觉得要求不够清晰，如果培训安排得明白，落地时遇到的阻力也处理得及时，MISRA才不会一直停留在工具报告和文档要求里面。

开发人员不要只从名称上去理解这两套规则，它们虽然都面向C语言，也都可以帮助减少代码里的毛病，但处理问题的侧重点并不同。MISRA C会把注意力更多地放在代码写法是不是稳定、能不能被工具查出来，以及后期评审时团队能不能讲明白；CERT C则更关心代码会不会留下安全方面的隐患，比如内存使用越过了边界、整数计算结果溢出、资源用完后没有被释放、来自外部的数据没有做检查，这些都属于CERT C经常要查看的内容。项目团队可以把MISRA C当作基础的写法要求，再把CERT C看成安全问题的补充检查，这样在安排规则时方向会清楚一些。

很多人一提到MISRA C，第一反应就是“把所有规则背下来”。可真到项目里，最容易出错的地方反而不是记不住编号，而是把规则内容、规则级别和项目执行要求混成了一件事。MISRA官方在《MISRA Compliance:2020》里把这件事讲得很清楚：每条guideline都会带一个MISRA category，也就是Mandatory、Required或Advisory，这个级别决定的不是规则“重不重要”这么简单，而是违反之后在合规上能不能被接受、要不要走正式偏离流程。

MISRA合规说明与偏离说明写得好不好，评审看两点：一是你有没有按统一口径声明适用范围与合规结论，二是每一条偏离是不是把适用场景、风险与控制措施写成可复核证据。MISRA在MISRA Compliance:2020里把合规声明、偏离与过程要求统一了口径，你只要按它的结构组织材料，基本就不会在格式与完整性上吃亏。

做MISRA治理如果一上来就要求全量清零，团队通常会被告警数量压垮，开发节奏也会被打断。更可行的做法是先建立一条可追溯的基线，把现状固化为可管理的起点，然后用不回退的规则逐批消化历史遗留，让新增代码不再制造新债，老债再按优先级逐步还清。

MISRA告警一旦碰上历史遗留代码，最怕的不是数量大，而是口径乱、边界不清、整改没有节奏，最后变成一轮轮重复扫描与反复争论。要把事情做顺，思路应当从先稳住新增开始，再把存量分层消化，同时把豁免与证据链固定下来，做到每一步都有可复核的产出。

同一套代码在不同MISRA工具里跑出来的告警不一致，通常不是谁对谁错，而是检查口径没有对齐：规则版本不同、编译选项不同、宏与头文件解析不同、抑制与偏离记录不同，都会直接改变结果。处理这类问题要先把差异收敛到可比较的维度，再把规则集、编译数据库与裁决流程固化成团队统一动作。