做ISO 26262软件单元验证时，很多团队前面把测试跑了不少，后面一到评审或审计阶段却又说不清证据链到底在哪一版、哪一条需求、哪一次执行上。问题往往不是测试没做，而是验证动作和归档动作从一开始就没有按同一条线设计。公开资料对这件事讲得很清楚，ISO 26262第6部分覆盖软件开发、验证和确认活动，第8部分还单独覆盖配置管理、变更控制和文档等支持过程，所以软件单元验证不能只停在“测过了”，还要落到可追溯、可复核、可回放的证据管理上。

　　一、ISO 26262软件单元验证怎么做

　　软件单元验证真正稳的做法，不是先堆很多测试用例，而是先把验证对象、验证依据和验证方法摆在同一张表上。这样后面每做完一步，你都能明确回答这次验证对应的是哪条单元需求、哪段实现、哪类风险，而不是最后再回头补说明。ISO 26262相关公开资料也都把要求集中在几个核心动作上，也就是基于需求的单元测试、静态与人工检查、结构覆盖和结果评估。

　　1、先把单元边界和验证基线定清

　　先定义软件单元是什么、输入输出接口是什么、依赖关系是什么，再把对应的单元需求、设计说明和代码版本锁成当前验证基线。若这一步没先定，后面测试跑得再多，也很难说明到底验证的是哪一个对象。

　　2、按需求推导单元测试

　　单元测试不要只凭经验补几条典型路径，更稳的做法是按需求逐条推导测试，并把正常场景、边界场景、异常场景、鲁棒性和资源约束一起考虑进去。公开资料明确提到，软件单元测试应由需求导出，并用于证明单元满足设计、功能、接口、鲁棒性和资源要求。

　　3、把静态验证和动态验证一起做

　　如果只做单元测试，不做代码审查、静态分析和数据控制流检查，很多实现层问题会被漏掉。公开资料把代码评审、静态分析、数据流和控制流分析都列在ISO 26262软件单元验证支持方法里，所以更稳的验证方式是审查、静态分析和单元测试并行推进。

　　4、最后用结构覆盖检查测试是否真的到位

　　测试执行完以后，不要只看通过率，还要看覆盖率。公开资料指出，ISO 26262在软件单元层面要求通过结构覆盖来判断测试完整性，而且随着ASIL提高，覆盖要求和验证严谨度也会提高。也就是说，覆盖率不是附加项，而是判断“是否测到位”的关键证据。

　　二、ISO 26262软件单元验证证据怎么归档

　　证据归档最怕的是“文件很多，但链路断了”。真正稳的归档，不是把报告全塞进一个目录，而是把需求、设计、代码基线、测试用例、执行结果、缺陷处理和覆盖率按同一条追溯链串起来。公开资料明确提到，第8部分覆盖配置管理、变更控制和文档，而软件验证活动本身又依赖需求追溯、测试结果和覆盖率数据，所以归档动作应和验证动作同步发生，而不是事后补资料。

　　1、先把基线类证据归成一组

　　这一组至少应包括单元需求、单元设计说明、代码版本、编译参数、测试环境说明和工具版本。这样后面任何一条测试结果都能回指到当时的对象和环境，不会出现结果有了却说不清是基于哪一版代码跑出来的情况。

　　2、再把执行类证据归成一组

　　这一组更适合放测试用例、测试过程记录、原始日志、通过失败结果、代码覆盖率、静态分析结果、评审记录和异常问题单。公开资料把单元测试、静态分析、代码覆盖和评审都作为软件验证的重要组成，所以这些结果应一起归档，而不是只留下最终汇总表。

　　3、归档时把追溯关系一并固化

　　真正有价值的证据不是单个文件，而是需求到测试、测试到代码、代码到结果之间的双向关系。公开资料反复强调requirements traceability的重要性，所以归档时最好同步输出追溯矩阵或等价索引，而不是让审核人员靠人工翻文件自己拼链路。

　　4、最后把变更和审批记录锁进配置管理

　　如果测试过程中改了需求、补了用例、换了工具版本，却没有把变更原因和批准记录一起归档，后面的证据就会失去完整性。第8部分把配置管理、变更控制和文档单独列出来，本身就在说明证据归档不是简单存盘，而是带状态、带版本、带责任人的受控归档。

　　三、ISO 26262软件单元验证闭环怎么收口

　　很多项目不是不会做验证，而是做完以后收不住。最常见的问题，一是测试做了但没有对应需求，二是覆盖率有了但缺少异常处理记录，三是报告齐了但版本不一致。要把软件单元验证真正收成闭环，就得在结束前再反过来查一遍，确认验证、证据和配置三条线已经对上，而不是只看一份总结报告。

　　1、先查有没有只留截图不留原始记录

　　很多团队会保留测试通过截图，却没有保存原始日志、覆盖率明细和分析输出。这样短期看像有证据，长期复核时却很难复现，所以收口时应优先补齐原始执行记录。

　　2、再查有没有只测功能不测异常

　　如果测试只覆盖正常路径，没有把边界、异常和鲁棒性要求一起带进来，软件单元验证就还没做完整。公开资料明确把鲁棒性和资源支持列进单元测试目标，所以这类缺口要在归档前补齐。

　　3、再查有没有结果和版本对不上

　　一份覆盖率、一份日志、一份评审记录，如果对应的是三版不同代码，那这些证据放在一起也不能直接成立。配置管理和变更控制之所以被单独强调，就是为了避免这种“证据都有，但不在同一基线”的问题。

　　4、最后查追溯链能不能从需求走到结果

　　真正闭环的标准，不是资料数量多，而是从一条单元需求出发，能一路找到设计、代码、测试、覆盖和问题处理结果；从任何一条问题记录往回，也能追到它对应的需求和基线。如果这条链还断着，说明验证工作还没有真正收口。

　　总结

　　ISO 26262软件单元验证怎么做，ISO 26262软件单元验证证据怎么归档，真正关键的不是先把用例数量做大，而是把验证动作、证据输出和配置管理从一开始就放进同一条闭环里。前面先按需求做单元验证，再把静态分析、代码审查和结构覆盖一起补齐，后面再按基线、执行结果、追溯关系和变更记录做归档，最后用闭环检查把缺口收住，这样拿出去的证据才更容易经得起复核。