汽车电子ISO 26262功能安全系列（第28期）：软件单元验证——测试方法与覆盖率全攻略

ISO 26262要求的不只是“代码没语法错误”，而是用实际的测试用例证明代码在运行时确实是安全的。这就是软件单元验证（Software Unit Verification）的核心使命。

软件单元验证：不只是“跑一下看看”

验证的五大目标

根据ISO 26262-6:2018第9章的要求，软件单元验证要达成以下目标：

1. ✅验证实现与设计一致——代码跟设计文档对得上

2. ✅尽早隔离缺陷——在单元层面就把bug扼杀在摇篮里

3. ✅满足ASIL覆盖率要求——不同等级有不同“及格线”

4. ✅形成可追溯证据——每个测试都能追溯到需求

5. ✅保证运行安全稳定——避免死机、失控等风险

💡核心逻辑：单元验证不是“随便测测”，而是用结构化的方法、量化的指标，证明每个函数在运行时都是安全的。

验证的两种大法：静态 vs 动态

ISO 26262的软件验证分为静态验证和动态验证两大类别：

上期我们讲的MISRA检查和静态分析属于静态验证。本期重点讲的是动态验证——真正把代码跑起来，看它到底行不行。

五种单元测试方法：ISO 26262的“官方菜单”

ISO 26262-6:2018的表1列出了五种推荐的软件单元测试方法。不同ASIL等级要求使用的方法不同——等级越高，需要组合的方法越多。

解读：++ = 强烈推荐，+ = 推荐。ASIL-D要用上全部五种方法。这不是“选做”，是“必做”。

方法一：基于需求的测试——“需求说啥就测啥”

核心思想：每一条软件安全需求（SSR），至少要有对应的测试用例来证明它被正确实现了。

怎么做：

• 把每条SSR拆解成可验证的条目

• 每条条目至少对应一组测试用例

• 测试用例写清楚：输入是什么、期望输出是什么、判定点在哪里

ACC示例：

方法二：接口测试——“函数之间传数据对不对”

核心思想：验证模块之间的接口契约是否正确——函数调用的参数、返回值、数据类型、范围。

方法三：故障注入测试——“人为制造故障，看系统扛不扛得住”

核心思想：人为引入故障（如内存错误、变量篡改、通信中断），观察软件是否能检测并安全处理。

为什么重要？

很多安全机制在正常运行时根本不会被触发——看门狗只有在程序跑飞时才干活，ECC只有在内存出错时才纠错。如果不做故障注入，你怎么知道这些“备胎”真的能用？

ACC故障注入示例：

方法四：资源使用测试——“内存会不会爆、CPU会不会满载”

核心思想：验证软件在资源受限的嵌入式环境中，不会耗尽内存、不会占满CPU、不会导致系统崩溃。

ACC资源测试示例：

方法五：背靠背测试——“模型说的和代码做的一样吗”

核心思想：在相同的输入下，比较算法模型的输出和代码的输出是否一致。

适用场景：基于模型开发（MBD）的项目——先用Simulink建模，再自动生成C代码。

ACC背靠背测试示例：

测试用例怎么设计？四种“武器”帮你搞定

有了测试方法，还得有具体的测试用例。ISO 26262推荐了以下几种测试用例设计方法。

武器一：等价类划分——“同类问题，测一个代表就行”

核心思想：把输入数据分成若干“等价类”，从每个类中选一个代表来测试。

ACC示例：calc_safe_distance(int speed, int weather)

测试用例：从每个等价类选一个代表——speed选60（有效）、-1（无效）、131（无效）；weather选0、1、2、3（无效）。

武器二：边界值分析——“边界最容易出问题”

核心思想：重点测试边界值——0、最小值、最大值、临界阈值。

ACC示例：

💡为什么边界值这么重要？绝大多数bug都出现在边界——if (speed < 130)写成if (speed <= 130)，差一个等号就是天壤之别。

武器三：MC/DC覆盖——“每一个条件都要单独验证”

MC/DC是最严格的覆盖率标准，ASIL-D强制要求100%。

要满足MC/DC，你需要测试4种组合，证明每个条件都能独立影响结果：

关键点：必须证明每一个条件都能独立改变判定结果——这才是MC/DC和普通分支覆盖的根本区别。

武器四：错误推测法——“凭经验猜哪里容易出问题”

核心思想：根据开发经验和领域知识，猜测哪里最容易出错，针对性设计测试用例。

ACC常见“坑”：

覆盖率要求：ASIL等级的“及格线”

这是ISO 26262最硬核的要求之一。不同ASIL等级对代码覆盖率的要求不同。

ASIL-D要求MC/DC达到100%——这意味着代码中每一个条件的所有可能组合都必须被测试覆盖。

为什么覆盖率这么重要？

ISO 26262要求度量结构化代码覆盖率，以证明测试的完整性。简单说：

覆盖率不是为了“凑数字”，而是为了证明“你确实测到了每一个可能出问题的地方”。

覆盖不足怎么办？

如果覆盖率不达标，需要：

1. 分析未被覆盖的代码路径

2. 补充测试用例覆盖这些路径

3. 优先补充关键分支和异常路径

4. 覆盖不足视为未达标

   ——用例全通过但覆盖不足，不能算过关

单元测试的“武器库”：主流工具一览

手动做单元测试不现实——代码量动辄几万行，靠人工跑用例得跑到天荒地老。

商业工具

开源/通用框架

选择工具的要点：工具本身需要有功能安全认证（如Tessy已通过TÜV认证），才能用它产出的测试报告作为功能安全证据。

实战：ACC控制器单元验证全流程

把以上所有内容整合起来，ACC控制器的单元验证完整流程是这样的。

Step 1：确定验证范围

Step 2：设计测试用例（以calc_safe_distance()为例）

Step 3：执行测试并采集覆盖率

使用Tessy等工具执行测试用例，自动采集覆盖率数据。

覆盖率报告示例：

Step 4：建立可追溯性

每个测试用例都必须能追溯到对应的需求。

审核员会查什么：你说“测过了”——证据呢？测试用例在哪？覆盖率报告在哪？每条SSR都有对应的测试用例吗？可追溯性是审核必查项。

单元验证中容易踩的“坑”

坑1：只测“正常情况”，不测“异常情况”

❌ 只验证“输入合法时输出正确”
✅ 必须测试非法输入、边界值、异常路径——安全系统的代码必须在任何情况下都不崩溃

坑2：用例全过了，但覆盖率为0

❌ “所有测试用例都通过了，肯定没问题”
✅用例全通过但覆盖不足，不能算过关——没测到的代码，就是潜在的雷

坑3：忘记做故障注入

❌ “功能都正常，不用测故障”
✅安全机制在正常运行时根本不会触发——不做故障注入，你怎么知道它们真的能用？

坑4：没有建立可追溯性

❌ 测试用例和需求之间没有关联
✅ 建立SSR ↔ 测试用例 ↔ 测试结果的完整追溯链。