汽车功能安全-嵌入式软件测试（软件合格性测试）【目的、验证输入、集成&验证要求】11

文章目录

[1 嵌入式软件测试（Testing of the embedded Software）](#1 嵌入式软件测试（Testing of the embedded Software）)
[2 测试输入](#2 测试输入)
[3 验证要求和建议](#3 验证要求和建议)
- [3.1 测试环境](#3.1 测试环境)
- [3.2 测试方法](#3.2 测试方法)
- - [3.2.1 基于需求的测试](#3.2.1 基于需求的测试)
  - [3.2.2 故障注入测试](#3.2.2 故障注入测试)
  - [3.2.3 两种方法的区别与联系总结](#3.2.3 两种方法的区别与联系总结)
- [3.3 测试用例导出方法](#3.3 测试用例导出方法)
[4 嵌入式软件的测试结果评价](#4 嵌入式软件的测试结果评价)
[5 测试输出物](#5 测试输出物)

1 嵌入式软件测试（Testing of the embedded Software）

该活动目的是提供证据证明嵌入式软件在目标环境中满足其需求。可通过其他验证活动的适当结果提供该证据。

目的：
该子阶段目的是提供证据证明嵌入式软件：
a) 在目标环境中执行时满足安全相关需求；
b) 不包含与功能安全相关的非所需功能和特性。

2 测试输入

软件安全需求规范；

可参考：

可考虑下列信息：
技术安全概念（参见ISO 26262-4:2018, 6.5.2）；
系统设计规范（参见ISO 26262-4:2018, 6.5.3）；
集成和测试策略（参见ISO 26262-4:2018, 7.5.1）；及
集成测试报告（参见ISO 26262-4:2018, 7.5.2）。

3 验证要求和建议

为验证嵌入式软件在目标环境中满足软件安全需求，应在表13所列的适当测试环境中按照ISO 26262-8:2018第9章规定进行测试。

注：可以复用已有的测试用例，如来自软件集成测试的测试用例。

3.1 测试环境

表13 用于执行软件测试的测试环境 ：

备注：

a 示例包括集成了车辆部分或全部电气系统的测试台架、"lab-car"或"mule-car"，以及剩余总线仿真。
b 根据不同ASIL等级要求，合理灵活选取测试环境方法

3.2 测试方法

采用表14所列方法对嵌入式软件进行测试，以提供证据证明嵌入式软件满足各自ASIL等级要求的软件需求。

表14 嵌入式软件的测试方法

备注：

a 在软件测试环境中，故障注入测试是指通过破坏校准参数等方法将故障引入软件。

3.2.1 基于需求的测试

定义： 基于需求的测试是一种验证技术，其核心目标是确认嵌入式软件的实现是否精确地满足了其指定的（通常是高层次）功能安全需求和非功能安全需求。
目标： 证明软件的输出和行为与需求规范定义的预期结果完全一致。它通过正向测试来验证软件按预期工作的"功能正确性"和"安全机制的有效性"。
方法： 测试用例的设计直接来源于需求规范。每个测试用例都对应一个或多个具体的需求项。测试执行就是模拟需求定义的输入条件、操作序列和环境状态，并检查软件的输出、行为以及时间特性是否与需求规定的输出、行为和约束（如时间限制）完全匹配。
ISO 26262 上下文： ISO 26262 强烈要求在软件单元测试和软件集成测试阶段执行基于需求的测试（如Part 6中的章节6.4.3和6.5.3）。它被视为建立软件功能安全可信度的基础。
覆盖要求： 通常追求100%的需求覆盖度 ，即每个软件安全需求 （无论是功能性的还是非功能性的，如时序约束）都必须至少有一个对应的测试用例进行验证。在更高ASIL等级下，甚至要求路径覆盖或MC/DC覆盖作为补充。
验证属性： 主要关注功能正确性、接口正确性、安全机制的激活条件/逻辑/效果以及时间行为（如响应时间）。
汽车行业示例 - 外灯TSR需求（RBT视角）：
- 需求： "CCU 应监控导致倒车时右转向灯点亮的 SPF（信号处理故障）。若检测到该 SPF，CCU 应在 500 毫秒内关闭右转向灯并输出故障报警信号。"
- 基于需求的测试设计（部分关键测试点）：
  1. 测试用例 TC_RBT_SPF_Detection：
  - 测试场景： CCU处于倒车档位，右转向灯因正常操作（非故障）被点亮。
  - 注入条件： 模拟一个会被识别为"导致倒车时右转向灯点亮的SPF"（例如，故意设置一个来自转向灯信号处理模块的标志位/内部状态为"故障状态"，或者模拟一个不符合安全期望的信号值序列）。
  - 预期输出： CCU 应该检测到这个模拟的SPF。
  - 验证点： 确保监控机制（软件逻辑）能够正确识别出这类特定的故障信号。
  1. 测试用例 TC_RBT_SPF_Reaction：
  - 测试场景： CCU处于倒车档位，右转向灯被点亮（无论是正常点亮还是因其他原因点亮）。
  - 注入条件： 模拟CCU内部检测到上述SPF（设置一个代表SPF被检测到的标志位或事件）。
  - 预期输出： CCU 在500毫秒内 完成以下动作：
    - 关闭右转向灯的控制信号。
    - 生成并输出一个故障报警信号（例如，设置一个诊断故障码/内部标志位，或通过总线发送报警信息）。
  - 验证点： 验证安全机制的核心逻辑（关闭灯光+报警）及其关键时间特性（≤500ms）完全符合需求。
  1. 测试用例 TC_RBT_SPF_NoDetection：
  - 测试场景： CCU处于倒车档位，右转向灯工作正常，没有任何SPF发生。
  - 注入条件： 无SPF。
  - 预期输出： CCU不会关闭右转向灯（它应保持工作），也不会输出故障报警信号。
  - 验证点： 确保安全机制仅在检测到指定SPF时才被触发，避免误动作（确保"虚警率"符合要求）。
- 总结： 这些测试严格对照需求文本设计，直接验证需求描述的"监控"、"检测到则500ms内关闭+报警"的行为是否在软件中被精确实现。测试执行时会精确测量从注入SPF到灯灭+报警发出的时间差。

3.2.2 故障注入测试

定义： 故障注入测试是一种评估软件安全机制在应对内部或外部故障时的鲁棒性 和有效性 的负向测试技术。它故意在软件运行过程中引入模拟的故障或错误状态，以观察系统（尤其是其安全机制）如何检测、控制和处理这些故障。
目标： 验证安全机制是否能够按设计要求 检测到特定的故障模式，并且在指定时间内 执行正确的容错或失效安全操作（如进入安全状态、降级运行、报警），从而防止或减轻因这些故障导致的危险（违背安全目标）。
方法： 在软件运行时（通常在目标硬件或高保真模拟环境下），通过特定工具或手段，强制性地将错误或故障状态（如：修改关键变量的值、强制设置/复位错误标志位、翻转存储位、注入错误的传感器数据、模拟硬件寄存器/内存位翻转、模拟总线通信错误/延迟/丢失）注入到软件中。然后监控系统的行为。
ISO 26262 上下文： FIT主要与软件集成测试 和硬件-软件集成测试强相关（如Part 6中的章节6.5.3）。它对应ISO 26262中故障避免和故障控制策略的验证，特别是针对由硬件随机故障或瞬态干扰导致的软件错误。
覆盖要求： 通常追求覆盖安全机制设计中考虑的关键故障模式列表。这个列表来源于FMEA/FTA等安全分析中识别出的、需要软件安全机制处理的故障。
验证属性： 主要关注安全机制在故障存在下的检测能力 、故障覆盖率 、反应逻辑的正确性 、时间可靠性 （能否在规定时间内响应）以及整体系统的失效行为（能否进入并维持安全状态）。
通俗易懂的解释：
- 想象你在测试一个设备的紧急备用系统 （安全机制）。故障注入测试就像一个故意的"破坏者"。
- "破坏者"会想方设法给设备制造一些麻烦或"假故障"（比如，往数据里加"噪音"，故意拔掉某个传感器的"线"，或者在内部存储里制造点"乱码"）。
- 然后，观察设备的备用系统（安全机制）能不能发现这些麻烦（故障） ？发现了之后是不是按照应急预案（安全需求）快速地采取了保护措施（比如紧急关机、报故障灯）？
- 目的是确保在真的发生问题时，备用系统能可靠地顶上去，避免出现灾难性的后果（违背安全目标）。
汽车行业示例 - 外灯TSR需求 (FIT视角)：
- 需求中的安全机制： CCU对SPF的监控和处理逻辑本身就是一种软件安全机制。
- 可能相关的故障模式及测试设计：
  1. 测试用例 TC_FIT_MemoryBitFlip：
  - 目标故障模式： 硬件随机故障（如单粒子翻转SEU）导致CCU内存中存储的 SPF_DetectionFlag (假设用来表示是否检测到SPF) 的值从 False (未检测到) 意外翻转为 True (检测到）。
  - 注入方式： 在软件运行过程中（尤其是在倒车时，无论右灯是否点亮），通过调试接口、硬件故障注入工具或仿真平台，强制修改内存地址将该标志位设为True。
  - 预期行为： CCU的安全机制（监控逻辑）应"误以为"检测到了SPF。
  - 预期安全反应： CCU 应在500毫秒内 关闭右转向灯并输出故障报警信号。
  - 验证点： 验证安全机制对自身状态错误的容错能力。即使这个故障标志位是由于硬件错误被错误置位的，机制也应正常触发关闭和报警，防止转向灯因虚假信号在倒车时意外点亮。
  1. 测试用例 TC_FIT_CorruptedSensorData：
  - 目标故障模式： 从转向灯信号处理模块（或其他相关源）到CCU的信号在传输/处理中被破坏（例如，数据帧因EMC干扰被篡改、延迟或丢失），导致它看起来像是一个"导致倒车时右转向灯点亮的SPF"（尽管实际上不是）。
  - 注入方式： 在CCU接收相关信号的输入端口（软件接口层面），模拟注入异常的、无效的、或符合SPF错误模式的数据包或值。
  - 预期行为： CCU的监控逻辑应识别出这是一个SPF（无论信号是真的故障还是被注入的错误）。
  - 预期安全反应： CCU应在500毫秒内关闭右转向灯并输出故障报警信号。
  - 验证点： 验证监控逻辑对输入信号故障/错误的检测能力和鲁棒性。
  1. 测试用例 TC_FIT_LatentFault：
  - 目标故障模式： 一个SPF确实发生了，但CCU的监控逻辑自身因为某个软件错误（比如一个关键循环计数变量溢出）未能成功设置 SPF_DetectionFlag 为 True。
  - 注入方式： 在SPF实际发生（或模拟其发生）的同时，通过故障注入工具阻止或篡改监控逻辑内部设置标志位的代码路径或变量值。
  - 预期安全反应: 机制失效（Flag保持为False）。在这个例子中，CCU不会关闭右转向灯也不会报警！
  - 验证点： 这时需要监控更高层的安全机制 或者看是否违背了更高层的安全目标 （e.g., "车辆在倒车时不得有转向灯意外点亮"）。这可能暴露当前监控机制的单点弱点，需要分析其影响是否符合ASIL等级要求（可能要求额外的独立监控机制或更高级别的故障探测）。这个测试用于验证安全机制的诊断覆盖度（发现自身内部问题的能力）。
- 总结 (FIT)： 这些测试主动模拟各种可能影响安全机制本身或其输入的异常情况和故障，检验该机制在这些"坏情况下"是否还能正确、及时地履行其安全职责（关闭灯+报警），或者暴露机制本身的缺陷。它与RBT相辅相成，RBT验证"好路上走的对"，FIT验证"坏路上还能不能撑得住"。

3.2.3 两种方法的区别与联系总结

特性	基于需求的测试	故障注入测试
核心目标	验证功能正确性 & 实现符合需求	验证安全机制在故障下的鲁棒性、检测能力和容错效果
测试方向	正向测试 (验证需求要求的"应该发生")	负向测试 (验证在"不应该发生"的故障下系统的反应)
输入来源	直接从需求规范导出测试用例	从FMEA/FTA等分析得出的关键故障模式、失效场景导出测试用例
测试条件	正常输入条件、预期的操作序列	人为注入异常/错误/故障状态 (篡改数据、状态、输入信号、模拟硬件错误)
主要关注点	功能行为、接口、时间约束是否正确实现	安全机制的覆盖率、故障检测率、反应时间、失效安全行为
ISO 26262关联	软件单元/集成测试验证的基础	软件集成/HSI测试验证安全机制有效性的核心手段
类比	质检员 (按说明书检查功能)	破坏测试员 (故意捣乱看应急系统顶不顶得住)
案例重点	能否正确检测SPF？能否在500ms内关闭+报警？	如果监控逻辑内存出错怎么办？如果输入信号被污染怎么办？

关联性：

两者是高度互补且必要的。RBT是基础，确保安全机制在"晴空万里"时能正确工作；FIT是深化，证明安全机制在"风雨交加"（故障）时依然可靠。在安全验证中，尤其是对于高ASIL等级的软件，两者都必须严格执行，以达到要求的测试覆盖度和置信度。RBT建立功能的信心，FIT建立安全韧性的信心。

3.3 测试用例导出方法

为确保软件测试的测试案例规范符合11.4.2要求，应通过表15所列方法导出测试用例。

表1.5：获取嵌入式软件测试案例的方法

备注：

a 软件的操作使用案例包括现场更新软件，仅在通过引导程序确保软件完整的情况下启动名义应用程序，嵌入式软件在启动、诊断、降级、休眠（进入睡眠状态）、恢复电源（唤醒）、校准等不同操作模式下的安全相关行为，与不同ECUs之间的同步模式或为保障生产人员安全的生产线终端测试台模式相关的功能。

测试用例导出方法介绍：

需求分析 (Requirements-Based Testing - RBT)
- 专业解释： 测试用例直接从软件安全需求（SRs）和软件架构设计需求（SWADs）中推导出来。目的是验证软件是否实现了所有指定的需求。每个需求至少对应一个验证其被满足的测试用例（正向测试）。对于关键需求（尤其是安全目标相关），还需要考虑其被违反的情形（负向测试）。
- 通俗解释： 就像按照说明书检查软件。拿软件的"任务清单"（需求列表）一条条看软件做的对不对。主要关注"软件应该做什么"。
- 汽车示例 - TSR:
  - 需求： CCU 应监控导致倒车时右转向灯点亮的 SPF（信号处理故障），若检测到该 SPF，CCU 应在 500 毫秒内关闭右转向灯并输出故障报警信号。
  - 需求分析导出的测试用例：
    - TC_RBT_1 (正向)： 模拟在倒车档位下注入一个导致右转向灯错误点亮的SPF信号。预期结果： CCU在500ms内关闭右转向灯，并输出故障报警信号。
    - TC_RBT_2 (负向)： 模拟在非倒车档位下（如前进挡）的相同SPF信号。预期结果： CCU不应该因为该信号而关闭右转向灯或输出报警（因为该SPF在非倒车时可能无危害或有其他处理逻辑）。
    - TC_RBT_3 (边界/负向)： 模拟一个导致右转向灯错误点亮的SPF信号，但信号特征仅略微超出"正常"范围，检查CCU是否仍能识别为SPF并做出响应。
等价类生成与分析 (Equivalence Class Partitioning - ECP)
- 专业解释： 将输入数据、输出结果或内部状态的取值范围划分为若干个被称为"等价类"的区间。这些区间具有关键特性：同一个等价类内的所有值，预期会触发相同的软件行为或导致相同的处理结果。通过从每个等价类中选择代表性值（通常是典型值）进行测试，就能在显著减少测试用例数量的同时，提供合理的覆盖率。
- 通俗解释： 把输入数据分成"看上去差不多"的几组。比如，考试分数：0-59不及格，60-79及格，80-100优秀。每组里抽一个分数测试就够了，不用每个分数都考一次。
- 汽车示例 - TSR:
  - 输入： SPF检测模块的输入信号强度（假设范围0-5V，0V正常，>4V表示有效SPF）。
  - 等价类划分：
  - EC1: 无效/弱信号 (0V - 3.9V)：不应触发故障处理（正常范围）。
  - EC2: 边界模糊信号 (~3.9V - 4.1V)：需要明确定义处理方式（可能不计为SPF，或计入但需考虑信号毛刺）。
  - EC3: 有效SPF信号 (>=4.1V)：应触发故障处理（关灯+报警）。
  - 等价类测试用例：
  - TC_ECP_1: 输入信号 = 2.0V (EC1典型值)。预期结果： 无动作（右转向灯保持正常或关闭状态）。
  - TC_ECP_2: 输入信号 = 4.0V (EC2典型值/边界值)。预期结果： 需根据需求定义（可能无动作，或设置警告但不关灯）。
  - TC_ECP_3: 输入信号 = 4.5V (EC3典型值)。预期结果： 同TC_RBT_1： 500ms内关灯+报警。
边界值分析 (Boundary Value Analysis - BVA)
- 专业解释： 经验表明，很多缺陷发生在输入等价类的边界区域附近。BVA强调测试边界值以及边界值两侧的邻点（即边界值和刚刚超过/低于边界的值）。它通常是对等价类划分的补充和完善。
- 通俗解释： 特别关注"临界点"附近。比如，上面考试的例子，不仅要测60（及格），还要测59（不及格）和61（及格），因为及格线附近最容易出判分错误。再比如电梯限重1000Kg，要测1000Kg能上（边界），999Kg能上（边界内邻点），1001Kg不能上（边界外邻点）。
- 汽车示例 - TSR:
  - 关注边界： 500ms 的时间要求是核心安全关键边界。
  - 边界值测试用例：
  - TC_BVA_1: 模拟SPF发生，CCU在499ms 时响应（关灯+报警）。预期结果： 不满足需求 ！（必须前进档）。预期结果： CCU应能正确处理档位变化，在档位变更为非倒车后停止关灯动作或维持安全状态？具体行为需定义（根据设计，可能停止关灯并清除报警？或者仍需完成关灯动作以消除潜在风险？）。
  - TC_FDA_2: 模拟SPF发生时，右转向灯驱动电路报告硬件故障（如短路）。预期结果： CCU仍应在500ms内尝试关灯，并输出故障报警信号（报警信号应能同时或额外指示硬件故障）。
  - TC_FDA_3: 资源冲突： 在SPF发生、CCU准备启动500ms计时器时，另一个高ASIL等级的任务（如刹车控制）请求抢占同一个计时器资源。预期结果： 安全相关功能（计时器）应得到保障，可通过优先级或专用资源实现，避免延迟导致超时。
操作使用案例分析 (Operational Scenario Analysis - OSA)
- 专业解释： 识别并测试在实际车辆运行环境中预期发生的各种操作情景（包括正常、降级、故障和紧急情况），特别是那些涉及安全机制激活的场景。场景涵盖用户操作、环境条件、系统状态变化序列（前置条件）及其触发的事件（如特定传感器输入），然后验证软件在该场景下的响应（输出）。
- 通俗解释： 测试软件在"实际开车时会遇到的各种情况"下的表现。比如：一边开雨刮、一边开空调、同时手机在充电、然后倒车入库时触发故障，看软件还能不能正确处理关键安全动作。
- 汽车示例 - TSR:
  - 操作场景：
  - 场景"倒车入库"： 车辆缓慢倒入停车位（挂倒挡），驾驶员无转向操作。此时，突然发生导致右转向灯异常点亮的SPF。
  - 场景"故障后倒车修正"： 在TC_RBT_1场景后（右转向灯已被关，报警已输出），驾驶员尝试再次倒车（挂D档后重新挂R档）。
  - 操作场景分析导出的测试用例：
  - TC_OSA_1: (基于"倒车入库") 结合功能依赖或错误猜测的用例（如TC_ERR_1），再加入典型倒车工况的负载（如超声波雷达工作、仪表显示倒车影像、EPB驻车动作等）。预期结果： CCU在综合负载下仍满足TC_RBT_1的要求（500ms关灯+报警）。
  - TC_OSA_2: (基于"故障后倒车修正") 在TSR处于"右转向灯因SPF已关闭且报警持续中"的状态下，驾驶员再次挂入倒挡。预期结果：
    - 报警信号应持续存在（提醒维修）。
    - 在再次倒车时，没有发生新的SPF：右转向灯应保持关闭（不会点亮）。
    - 如果模拟一个新的SPF再次发生在倒车时 ：CCU应能再次检测到并执行关灯+报警（即使之前已报过警）。确保安全机制能重复触发。
    - 故障信号是否在特定条件下可清除？（如IGN OFF/ON复位），清除后行为？ (需根据需求定义测试)

总结：

这些测试用例导出方法不是互斥的，而是互补的。在ISO 26262合规的嵌入式软件测试中，通常需要综合运用这些方法：

需求分析 (RBT) 提供基础和强制性覆盖。
等价类(ECP) 和 边界值分析(BVA) 用于高效处理输入输出空间，提高黑盒覆盖率。
错误猜测(Error Guessing) 利用经验挖掘深层次和边界外问题。
功能依赖分析(FDA) 关注模块间复杂的交互和资源冲突，这对嵌入式并发系统尤其重要。
操作使用案例分析(OSA) 确保软件在真实、复杂的环境下行为符合预期。

通过这种多层次、多角度的测试方法，才能最大限度地验证嵌入式软件的功能安全性，满足ISO 26262对高ASIL等级系统的严格要求。您提供的TSR示例清晰地展示了如何将这些抽象的方法映射到一个具体、关键的安全需求上。

4 嵌入式软件的测试结果评价

从以下几个方面评价嵌入式软件的测试结果：

a) 是否符合预期结果；及
b) 是否覆盖软件安全需求。
注其中包括是否覆盖配置和校准范围参见ISO 26262附件C

5 测试输出物

软件验证规范（用例）
软件验证报告