ISO 26262要求的不只是“代码没语法错误”而是用实际的测试用例证明代码在运行时确实是安全的。这就是软件单元验证Software Unit Verification的核心使命。软件单元验证不只是“跑一下看看”验证的五大目标根据ISO 26262-6:2018第9章的要求软件单元验证要达成以下目标✅验证实现与设计一致——代码跟设计文档对得上✅尽早隔离缺陷——在单元层面就把bug扼杀在摇篮里✅满足ASIL覆盖率要求——不同等级有不同“及格线”✅形成可追溯证据——每个测试都能追溯到需求✅保证运行安全稳定——避免死机、失控等风险核心逻辑单元验证不是“随便测测”而是用结构化的方法、量化的指标证明每个函数在运行时都是安全的。验证的两种大法静态 vs 动态ISO 26262的软件验证分为静态验证和动态验证两大类别验证类型大白话什么时候做典型方法静态验证“不运行代码光看代码找问题”编码阶段代码走查、技术评审、静态分析动态验证“运行代码看实际行为对不对”编码后单元测试、集成测试、故障注入上期我们讲的MISRA检查和静态分析属于静态验证。本期重点讲的是动态验证——真正把代码跑起来看它到底行不行。五种单元测试方法ISO 26262的“官方菜单”ISO 26262-6:2018的表1列出了五种推荐的软件单元测试方法。不同ASIL等级要求使用的方法不同——等级越高需要组合的方法越多。测试方法ASIL AASIL BASIL CASIL D大白话基于需求的测试“需求说啥就测啥”接口测试“函数之间传数据对不对”故障注入测试“人为制造故障看系统扛不扛得住”资源使用测试“内存会不会爆、CPU会不会满载”背靠背测试“模型输出和代码输出对不对得上”解读 强烈推荐 推荐。ASIL-D要用上全部五种方法。这不是“选做”是“必做”。方法一基于需求的测试——“需求说啥就测啥”核心思想每一条软件安全需求SSR至少要有对应的测试用例来证明它被正确实现了。怎么做把每条SSR拆解成可验证的条目每条条目至少对应一组测试用例测试用例写清楚输入是什么、期望输出是什么、判定点在哪里ACC示例SSR测试用例输入预期输出“系统应在200ms内计算出安全跟车距离”TC-001本车速度60km/h前车距离50m计算时间200ms输出跟车距离≥20m方法二接口测试——“函数之间传数据对不对”核心思想验证模块之间的接口契约是否正确——函数调用的参数、返回值、数据类型、范围。方法三故障注入测试——“人为制造故障看系统扛不扛得住”核心思想人为引入故障如内存错误、变量篡改、通信中断观察软件是否能检测并安全处理。为什么重要很多安全机制在正常运行时根本不会被触发——看门狗只有在程序跑飞时才干活ECC只有在内存出错时才纠错。如果不做故障注入你怎么知道这些“备胎”真的能用ACC故障注入示例故障注入预期响应篡改雷达距离数据为-100m系统检测到异常值 → 触发报警 → 进入安全状态模拟内存分配失败系统检测到资源不足 → 降级运行 → 不崩溃模拟函数返回超时超时监控触发 → 进入安全状态方法四资源使用测试——“内存会不会爆、CPU会不会满载”核心思想验证软件在资源受限的嵌入式环境中不会耗尽内存、不会占满CPU、不会导致系统崩溃。ACC资源测试示例测试项验证目标内存使用峰值不超过可用RAM的80%CPU负载峰值不超过可用算力的70%堆栈使用不超过分配堆栈的80%任务执行时间不超过分配的时间片方法五背靠背测试——“模型说的和代码做的一样吗”核心思想在相同的输入下比较算法模型的输出和代码的输出是否一致。适用场景基于模型开发MBD的项目——先用Simulink建模再自动生成C代码。ACC背靠背测试示例测试步骤操作1在Simulink中运行跟车距离算法模型输入一组雷达数据2在目标硬件上运行生成的C代码输入同样的雷达数据3对比两者的输出减速度请求值是否一致测试用例怎么设计四种“武器”帮你搞定有了测试方法还得有具体的测试用例。ISO 26262推荐了以下几种测试用例设计方法。武器一等价类划分——“同类问题测一个代表就行”核心思想把输入数据分成若干“等价类”从每个类中选一个代表来测试。ACC示例calc_safe_distance(int speed, int weather)输入参数有效等价类无效等价类speed (km/h)0-1300, 130weather0(晴天), 1(雨天), 2(雪天)0, 2测试用例从每个等价类选一个代表——speed选60有效、-1无效、131无效weather选0、1、2、3无效。武器二边界值分析——“边界最容易出问题”核心思想重点测试边界值——0、最小值、最大值、临界阈值。ACC示例边界测试值speed最小值0speed最大值130speed临界值129, 131越过边界weather有效范围边界0, 2, -1, 3为什么边界值这么重要绝大多数bug都出现在边界——if (speed 130)写成if (speed 130)差一个等号就是天壤之别。武器三MC/DC覆盖——“每一个条件都要单独验证”MC/DC是最严格的覆盖率标准ASIL-D强制要求100%。要满足MC/DC你需要测试4种组合证明每个条件都能独立影响结果测试sensor_okdistance SAFE结果证明了什么TC-01✅ TRUE✅ TRUETRUE条件为真TC-02❌ FALSE✅ TRUEFALSEsensor_ok单独影响结果TC-03✅ TRUE❌ FALSEFALSEdistance单独影响结果TC-04❌ FALSE❌ FALSEFALSE条件为假关键点必须证明每一个条件都能独立改变判定结果——这才是MC/DC和普通分支覆盖的根本区别。武器四错误推测法——“凭经验猜哪里容易出问题”核心思想根据开发经验和领域知识猜测哪里最容易出错针对性设计测试用例。ACC常见“坑”常见问题测试用例除零速度差为0时相对速度计算是否除零空指针传入NULL指针会不会崩溃数组越界缓冲区写入是否超过分配大小状态机异常非法状态转换是否被拦截覆盖率要求ASIL等级的“及格线”这是ISO 26262最硬核的要求之一。不同ASIL等级对代码覆盖率的要求不同。ASIL等级语句覆盖分支覆盖MC/DC覆盖ASIL A≥80%≥70%不强制ASIL B≥80%~100%≥80%~100%可选ASIL C100%100%≥90%~100%ASIL D100%100%100%ASIL-D要求MC/DC达到100%——这意味着代码中每一个条件的所有可能组合都必须被测试覆盖。为什么覆盖率这么重要ISO 26262要求度量结构化代码覆盖率以证明测试的完整性。简单说覆盖率不是为了“凑数字”而是为了证明“你确实测到了每一个可能出问题的地方”。覆盖不足怎么办如果覆盖率不达标需要分析未被覆盖的代码路径补充测试用例覆盖这些路径优先补充关键分支和异常路径覆盖不足视为未达标——用例全通过但覆盖不足不能算过关单元测试的“武器库”主流工具一览手动做单元测试不现实——代码量动辄几万行靠人工跑用例得跑到天荒地老。商业工具工具特点适用场景Tessy专为嵌入式C/C设计已通过TÜV认证支持自动化执行测试并生成报告ASIL-D项目首选Cantata支持在主机和目标平台自动化单元/集成测试高安全等级项目VectorCAST完整的嵌入式测试平台大型项目开源/通用框架框架特点适用场景Google Test功能强大社区活跃AUTOSAR AP平台CppUTest轻量级适合嵌入式C资源受限的ECUCatch2单头文件编译快快速原型开发选择工具的要点工具本身需要有功能安全认证如Tessy已通过TÜV认证才能用它产出的测试报告作为功能安全证据。实战ACC控制器单元验证全流程把以上所有内容整合起来ACC控制器的单元验证完整流程是这样的。Step 1确定验证范围软件单元功能ASIL验证方法get_radar_distance()读取雷达数据D需求测试接口测试故障注入资源测试背靠背calc_safe_distance()计算安全距离D全部五种方法check_following()判断跟车状态D全部五种方法Step 2设计测试用例以calc_safe_distance()为例用例ID测试方法输入(speed, weather)预期输出覆盖目标TC-001基于需求(60, 0)26正常晴天TC-002基于需求(60, 1)36正常雨天TC-003基于需求(60, 2)46正常雪天TC-004接口测试(-1, 0)-1无效speedTC-005接口测试(131, 0)-1speed超上限TC-006接口测试(60, 3)-1无效weatherTC-007边界值(0, 0)20speed0TC-008边界值(130, 0)33speed130TC-009故障注入模拟speed读取失败返回-1异常处理TC-010资源测试连续调用1000次内存无泄漏资源稳定性Step 3执行测试并采集覆盖率使用Tessy等工具执行测试用例自动采集覆盖率数据。覆盖率报告示例覆盖类型目标实际状态语句覆盖100%100%✅分支覆盖100%100%✅MC/DC覆盖100%100%✅Step 4建立可追溯性每个测试用例都必须能追溯到对应的需求。审核员会查什么你说“测过了”——证据呢测试用例在哪覆盖率报告在哪每条SSR都有对应的测试用例吗可追溯性是审核必查项。单元验证中容易踩的“坑”坑1只测“正常情况”不测“异常情况”❌ 只验证“输入合法时输出正确”✅ 必须测试非法输入、边界值、异常路径——安全系统的代码必须在任何情况下都不崩溃坑2用例全过了但覆盖率为0❌ “所有测试用例都通过了肯定没问题”✅用例全通过但覆盖不足不能算过关——没测到的代码就是潜在的雷坑3忘记做故障注入❌ “功能都正常不用测故障”✅安全机制在正常运行时根本不会触发——不做故障注入你怎么知道它们真的能用坑4没有建立可追溯性❌ 测试用例和需求之间没有关联✅ 建立SSR ↔ 测试用例 ↔ 测试结果的完整追溯链。