一轮扫描有100条违规，下一轮剩下95条，并不能说明只修复了5条。实际情况可能是修复8条，同时又引入3条。要看清每次提交的影响，需要保存一份可比较的历史结果，再逐项匹配当前诊断。MISRA基线可以帮助团队分开处理存量问题和新问题，但进入基线的违规仍然需要跟踪，不能因此视为已经合规。

　　一、MISRA如何建立新增代码检查基线

　　基线需要同时对应代码、分析配置和诊断结果。只有一份旧报告，却不知道使用了什么规则和扫描范围，后续比较容易失真。

　　1、确定作为起点的代码版本

　　①选择能够重现的提交、标签或发布版本，记录分支和提交标识。

　　②明确纳入检查的模块、生成代码及第三方代码范围，列出产品变体和宏配置。

　　③确认项目采用的MISRA版本，保存检查器、规则包及分析配置。

　　基线不一定要等历史违规清零后再建立。已有工程可以从约定版本开始管理新增问题，但历史问题的审查、整改和偏差处理应继续保留。

　　2、完成一次结果可靠的分析

　　①按实际构建配置分析，核对源文件、头文件路径、目标数据类型及编译器设置。

　　②查看解析失败、跳过文件和超时记录，处理影响完整性的异常后重新运行。

　　③保存原始诊断、运行日志和配置，为问题保留规则、位置及上下文等识别信息。

　　扫描没有完成时就生成基线，可能把下一次正常检出的旧问题误判为新增。对于多变体工程，也要避免只保存其中一个变体的结果，却用来评价所有交付配置。

　　3、在工具中启用基线比较

　　使用Perforce QAC时，可通过工程属性设置基线诊断抑制。

　　①打开【Project Properties】→【Baseline】，勾选【Use Baseline Diagnostics Suppression】。

　　②根据工程方式选择版本控制、本地副本或Dashboard快照等基线来源，核对对应版本。

　　③重新分析后，使用【Show baseline suppressed diagnostics】查看被基线隐藏的诊断，确认历史问题仍可追查。

　　这类抑制作用于结果显示，不代表停止生成诊断。其他工具的基线入口和状态名称可能不同，应以实际比较机制为准。

　　二、MISRA历史违规与新增违规如何分开统计

　　先比较问题是否对应，再判断变化原因。“本次新检出”与“本次代码修改引入”需要分开看。

　　1、按问题匹配，不能只减总数

　　①使用工具的问题匹配功能，对照基线与当前结果，识别仍存在、新出现和不再报告的诊断。

　　②检查匹配异常项，结合规则、文件、函数及代码上下文确认是否为同一问题。

　　③对无法可靠匹配的结果保留待核验状态，避免直接计入新增或修复。

　　代码前面增加几行注释，违规行号就会移动。仅按“文件名＋行号”匹配，可能产生一条假新增和一条假修复。文件改名、函数重构等变化，也可能使工具失去原来的问题关联。

　　2、把新出现的问题再查一遍来源

　　①将新诊断与代码差异对应，检查是否由本次修改引入。

　　②核对工具升级、规则启用、宏定义或扫描范围是否变化。

　　③将新增违规、历史问题首次检出及匹配失败分别记录，保留判断依据。

　　例如，补入一个此前漏扫的源文件，会出现一批新诊断，但这些违规可能早已存在。它们仍需处理，只是不宜全部记在本次开发修改名下。

　　也不能只看修改行。调整类型定义、接口或宏，可能在未修改的代码位置引出违规。判断责任范围时，需要沿依赖关系检查。

　　3、核实“不再报告”是否真的修复

　　①查看原违规代码，确认问题是否已经消除，或相关代码是否已删除。

　　②检查文件是否退出分析、规则是否关闭，以及诊断是否被抑制。

　　③对工具标记为已解决的事项，区分代码修复、误报确认和偏差批准等处置。

　　部分工具的Resolved状态包含多种处理结果，不能直接当成修复数量。关闭规则后告警消失，也没有证明代码已经满足要求。统计时应保留处置原因，便于复查。

　　4、统一统计单位和计算条件

　　建议以确认的问题项为主要单位，同时保留工具原始诊断数。同一规则可以在多个位置产生诊断，同一根因也可能关联多条消息，需要说明采用什么归并方式。

　　在配置和范围一致的条件下，基线100项、确认修复8项、新增3项，当前为95项。若期间还有代码移出范围、偏差处置或匹配待定事项，应另外列明。仅展示总数下降，无法反映新增控制是否有效。

　　三、MISRA基线调整后如何核对比较结果

　　更新基线前，可以先用几项可控的修改检查比较功能，确认工具能分清新增、保留和修复。Perforce QAC可通过以下操作核对。

　　1、确认当前启用的基线

　　①打开【Project Properties】→【Baseline】，检查【Use Baseline Diagnostics Suppression】是否勾选，核对基线来源及对应代码版本。

　　②完成当前代码分析，在结果面板启用【Show baseline suppressed diagnostics】，查看被基线隐藏的历史诊断。

　　③选择几项已知历史问题，对照源代码确认仍然存在，并记录其规则、位置和处理状态。

　　2、用测试分支验证新增与修复识别

　　①从已建立基线的提交创建测试分支，保留分析配置。

　　②修复一项已知违规，重新分析，确认该项不再产生诊断。

　　③在另一处加入经确认可被工具检出的违规，再次分析，检查它是否作为非基线诊断显示。

　　④只在一项历史违规前增加注释，检查行号变化后能否继续匹配。

　　⑤保存测试结果，删除测试分支，回到正常开发代码。若匹配结果异常，先核查原因，再用于正式统计。

　　3、需要更换快照时保存旧记录

　　统一工程使用Dashboard快照时，先归档旧基线及未解决问题，再进入【Perforce QAC Dashboard】→【Download Baseline】，选择经过核对的快照，点击【OK】。随后回到【Project Properties】→【Baseline】确认启用来源，重新分析，并抽查未解决问题是否仍能关联到原处理记录。下载新基线会覆盖本地旧基线，因此归档应在下载前完成。

　　总结

　　对于维护周期较长的工程，开发人员需要尽快知道这次提交带来了什么问题，项目负责人则需要看到历史整改是否持续推进。一份可信的比较结果，能让双方围绕具体代码安排工作，减少反复翻旧报告的时间。即使暂时无法清理全部存量，也可以逐步形成稳定的提交检查习惯，让每次修改的质量变化看得见、查得到。希望这些操作能帮助大家把基线用于日常开发，减轻后续复查和交付时的整理负担。如果您还有相关需求，欢迎联系我们交流咨询。