一次MISRA扫描产生上百条告警，开发人员修改后重新扫描，数量确实减少了，但哪些问题已经修好、哪些只是被过滤掉，未必能从汇总数字中看出来。等到版本交付时再补查，往往还要翻提交记录、找旧报告。比较省事的做法，是从发现问题时就保留身份信息，让修改、复查和关闭记录始终围绕同一项问题展开。

　　一、MISRA如何跟踪规则违规的修复状态

　　MISRA是编码规范体系，状态跟踪需要借助静态分析平台、问题管理系统或项目台账。下面的状态划分是一种项目实施方式，并非MISRA规定的统一字段。

　　1、给每项问题保留稳定编号

　　①保存首次扫描报告，记录源码提交号、工具版本、规则配置和分析范围。

　　②为确认需要处理的问题分配编号，同时保留工具生成的诊断标识。

　　③记录标准版本、规则编号、文件路径、函数名称及告警描述。

　　④将问题分配给具体负责人，注明计划处理的版本。

　　行号可以辅助定位，但不适合作为唯一标识。文件前面增加几行注释，原来的问题就会换位置。遇到这种情况，应结合函数、代码上下文和诊断内容判断，避免重新登记为另一项问题。

　　2、把“修改完成”与“复查通过”分开

　　①完成初步分析后，将问题区分为确认违规、待调查或疑似误报。

　　②开发人员提交修改时，记录提交号和修改说明，状态转为待复查。

　　③复查人员确认检查范围、修改内容和重新分析结果后，再决定关闭或退回。

　　④后续版本再次出现相同问题时，保留原有历史，记录重新打开的原因。

　　开发人员说“已经修改”，只能说明代码处理完成。复查还要确认修改确实进入被扫描的分支，以及告警消失的原因是否成立。

　　3、单独记录误报、偏离和暂未修复项

　　工具报告的告警需要调查，不能全部直接认定为真实违规。对于确实保留的违规，则应按适用规则类别和项目偏离流程处理。MISRA Compliance:2020区分了违规与有依据的偏离，抑制消息本身不能代替偏离论证。

　　①判为误报时，写明判断依据和复核结论，保留对应代码上下文。

　　②申请偏离时，关联规则、适用代码、保留理由、风险分析及审批记录。

　　③暂缓修复时，记录原因、负责人和后续安排，继续保留待处理状态。

　　④汇总时分别统计修复关闭、误报、已批准偏离和未关闭问题。

　　Mandatory类别的违规不能通过偏离予以接受。具体处理还应核对项目采用的标准及重分类安排，不能将所有规则都设置为允许豁免。

　　二、MISRA违规修复后复查记录如何关联

　　关联记录时，可以从问题单出发连接修改提交和复查结果，再从这些证据反向找到问题单。评审人员应能沿着记录还原处理过程。

　　1、在提交记录中注明问题编号

　　①开发人员提交修改时，注明对应问题编号和处理内容。

　　②在问题单中回填提交号，说明影响的函数或模块。

　　③一次提交处理多项问题时，逐项列明对应关系。

　　例如，同一提交修改了三处类型转换，三个问题单都应能找到该提交，同时说明各自对应哪处修改。只关联一个大范围合并记录，复查时仍需重新寻找代码。

　　2、让复查报告对应到确切版本

　　①在包含修复内容的源码版本上重新分析，保存扫描任务标识和报告。

　　②核对工具、规则集、编译宏和包含路径是否与原检查口径一致。

　　③检查目标文件是否实际参与分析，相关规则是否仍然启用。

　　④将复查结果关联到问题编号和修复提交，写明结论及复查人员。

　　⑤如果检查配置发生变化，记录差异，并说明前后结果如何比较。

　　报告中找不到原告警，并不总是修复成功。例如文件被移出分析范围、条件编译排除了相关代码，告警也会消失。基线同样可能抑制历史消息；使用基线的平台，应检查原始结果与抑制设置。help.perforce.com

　　3、补充修改影响的验证结果

　　①检查修改是否涉及数值范围、符号转换、求值顺序或接口行为。

　　②对可能影响运行行为的修改，按影响范围执行测试。

　　③在问题单中关联测试用例、执行版本和结果，说明是否发现其他影响。

　　静态检查通过不能证明功能没有变化。为消除告警而调整表达式时，尤其要核对边界输入和目标平台上的类型宽度。

　　4、关闭问题时保留简明结论

　　①确认修复提交、复查报告和必要的测试结果均可访问。

　　②写清原问题是否消除，是否产生新的相关告警。

　　③对未通过的复查保留原记录，退回处理后追加新一轮结果。

　　④关闭后保留状态变更时间和处理人员，不用最终结论覆盖之前的失败记录。

　　一条合格的关闭说明，应能回答“检查了哪个版本、依据什么关闭”。“已处理”“扫描通过”缺少上下文，后续很难据此判断证据是否适用于交付版本。

　　三、MISRA版本交付前如何检查记录完整性

　　日常处理记录齐全，交付时也要核对一次范围。长期开发分支中的修复，未必已经合入本次发布版本。

　　1、沿交付版本抽查处理记录

　　①选定交付源码基线，核对已关闭问题的修复提交是否包含在其中。

　　②从关闭清单抽取问题，反向检查原始告警、代码修改和复查报告。

　　③对仍保留的偏离，确认实际代码仍符合批准时的适用条件。

　　④将问题清单与规则合规汇总核对，解释未关闭项及统计差异。

　　MISRA的指南合规汇总按各项指南记录合规情况，因此问题单关闭数量不能直接替代合规结论。仍存在已批准偏离时，也应在汇总中如实反映。

　　总结

　　MISRA违规处理需要留下可复核的过程：原来发现了什么、代码如何修改、在哪个版本上确认，以及为什么能够关闭。稳定的问题编号和明确的版本信息，可以减少反复查找报告的时间，也便于交接。遇到误报、偏离或暂缓处理的情况，分别记录原因，统计结果才容易解释。希望这些方法能帮助大家把修复状态与复查证据对应起来，让日常整改和交付检查都有据可查。后续如有相关需求，欢迎进一步交流。