当前位置：首页 > news >正文

什么是故障注入测试

news 2025/6/28 18:25:45

故障注入测试（Fault Injection Testing）的定义与核心目的

故障注入测试是一种通过主动（主动是明显特征）引入异常条件（如硬件故障、网络中断、数据错误）来验证系统容错能力和稳定性的测试方法。其核心目标是：

暴露系统弱点：检测系统在异常情况下是否能保持功能完整性（如降级运行（安全模式）、自动恢复（复位））。
验证容错机制：确保系统的冗余设计、错误检测 / 恢复代码（如看门狗定时器、CRC 校验）有效工作。
提升可靠性：通过模拟极端场景，为系统可靠性评估提供数据支持（如 MTBF、MTTR 指标，MTBF（Mean Time Between Failures） 和 MTTR（Mean Time To Repair） 是核心指标，用于量化系统稳定性与维护效率（就是测量平均故障间隔时间，和出现故障后的修复时间，但是我又有一个疑问，这个如何界定））。

嵌入式系统中的故障注入测试特点

嵌入式系统通常具有资源受限、实时性要求高、硬件依赖性强等特点，其故障注入测试需关注：

硬件故障，

硬件级故障：如传感器信号异常、电源波动、总线错误。
软件级故障：如内存泄漏、任务抢占失败、中断处理异常。
实时性影响：故障是否导致系统响应超时或错过关键 deadlines。

嵌入式系统故障注入测试的典型场景与方法

故障类型	注入方法	测试目标
硬件故障	- 物理断开传感器连接 - 模拟电压波动（如 ADC 输入异常） - 中断总线通信（如 SPI/I2C 信号干扰）	- 验证系统能否检测传感器故障并报警 - 测试电源监控电路的阈值触发逻辑 - 检查总线错误恢复机制（如重传、错误帧处理）
软件故障	- 修改内存数据（如篡改变量值、破坏堆结构） - 模拟任务调度失败（如优先级反转） - 注入定时中断丢失	- 验证内存保护机制（如 MMU、内存校验） - 测试 RTOS 任务调度算法的健壮性 - 检查中断服务程序（ISR）的错误处理
通信故障	- 网络丢包模拟（如 TCP 连接断开） - 数据格式错误（如 UART 帧错误） - 延迟注入（如模拟网络拥塞）	- 验证通信协议的重传机制 - 测试数据校验算法（如 CRC、奇偶校验）的有效性 - 检查应用层超时处理逻辑
电源故障	- 突然断电 - 电压波动（如低于 LDO 阈值） - 电池电量模拟耗尽	- 验证系统能否安全保存关键数据 - 测试备用电源切换逻辑 - 检查电压监控电路的复位触发点

嵌入式故障注入测试实例：汽车电子控制单元（ECU）

场景描述

某汽车 ECU 负责控制发动机喷油系统，需在各种异常情况下确保安全运行。

测试目标

验证 ECU 在以下故障场景下的行为：

曲轴位置传感器信号丢失
内存数据被篡改（如喷油脉宽参数）
通信总线（CAN）突发错误

测试方案与实施

硬件故障注入：传感器信号丢失
- 注入方法：
  在 ECU 运行时，通过继电器断开曲轴位置传感器的信号线，模拟传感器故障。
- 预期行为：
  - ECU 应在 20ms 内检测到传感器信号异常（通过看门狗定时器）。
  - 触发安全模式：切换至备用转速估算算法，维持发动机怠速运行，并点亮故障灯。
- 验证代码示例（伪代码）：
  c
  
  运行
```
void sensor_monitor_task() {  while(1) {  if (crank_sensor_value == NO_SIGNAL) {  watchdog_reset();  // 重置看门狗  set_safe_mode();   // 切换至安全模式  activate_fault_indicator();  // 点亮故障灯  }  delay_ms(10);  // 每10ms检查一次  }  
}  
```
软件故障注入：内存数据篡改
- 注入方法：
  在 ECU 运行时，通过调试接口（如 JTAG/SWD）修改内存中存储的喷油脉宽参数（如将正常的 5ms 改为 10ms）。
- 预期行为：
  - ECU 应通过 CRC 校验检测到数据异常（参数存储区每 100ms 进行一次 CRC 校验）。
  - 恢复默认参数值，并记录错误日志。
- 验证代码示例（伪代码）：
  c
  
  运行
```
uint32_t calculate_crc(uint8_t *data, uint32_t length) {  // CRC计算逻辑...  
}  void parameter_check_task() {  uint32_t stored_crc = read_crc_from_flash();  uint32_t current_crc = calculate_crc(injection_params, PARAM_SIZE);  if (stored_crc != current_crc) {  load_default_params();  // 加载默认参数  log_error(ERROR_PARAM_CORRUPTED);  // 记录错误  }  
}  
```
通信故障注入：CAN 总线错误
- 注入方法：
  使用 CAN 分析仪在通信中插入错误帧（如位错误、CRC 错误），模拟总线干扰。
- 预期行为：
  - ECU 应能检测到错误并自动重传数据（根据 ISO 11898 标准，CAN 节点最多允许 255 次错误）。
  - 当错误计数器超过阈值（如 128）时，ECU 应进入错误被动状态，避免影响其他节点。
- 验证代码示例（伪代码）：
  c
  
  运行
```
void can_error_handler() {  if (can_error_counter > ERROR_PASSIVE_THRESHOLD) {  set_can_error_passive_mode();  // 进入错误被动模式  send_warning_message();  // 发送警告消息至仪表板  } else if (can_error_counter > ERROR_ACTIVE_THRESHOLD) {  retry_transmission();  // 重传数据  }  
}  
```

故障注入测试的工具与框架

硬件级工具：
- 可编程电源（如 Keysight E36313A）：模拟电压波动、断电。
- 逻辑分析仪（如 Saleae Logic）：注入总线错误、干扰信号。
软件级工具：
- 故障注入框架（如 FIAT、MACE）：通过修改二进制代码或运行时插桩注入故障。
- 模拟器（如 QEMU、Simics）：在仿真环境中注入虚拟故障（如内存访问错误）。

故障注入测试的注意事项

安全性：在汽车、医疗等安全关键系统中，需在隔离环境（如测试台架）中进行，避免影响真实设备。
可重复性：确保故障注入条件可精确复现，便于定位问题。
自动化：使用脚本或测试框架自动化执行故障注入，提高测试效率。

通过系统地注入各种故障并验证系统响应，嵌入式系统的故障注入测试可显著提升产品的可靠性和安全性，尤其适用于航空航天、自动驾驶等高风险领域。

探索性测试（Exploratory Testing）的核心概念与本质

探索性测试是一种强调 “测试设计与执行同步进行” 的动态测试方法，其本质是通过测试人员的主动探索、学习和经验判断，而非完全依赖预先编写的测试脚本。与传统脚本化测试（如自动化测试、基于需求的测试用例）的区别在于：

脚本化测试：遵循 “先设计测试用例→再执行” 的线性流程，侧重验证已知场景。
探索性测试：将 “测试设计、执行、分析” 视为循环迭代的整体，侧重发现未知缺陷和系统薄弱点。

探索性测试的核心特点与实施原则

1. 动态性与灵活性

测试人员根据实时反馈（如系统响应、日志输出）调整测试策略，而非严格遵循预设步骤。
例：在测试 APP 登录功能时，发现验证码加载缓慢，随即探索网络延迟对登录流程的影响。

2. 以 “学习” 为驱动

测试过程中持续理解系统架构、业务逻辑和潜在风险，进而设计更有针对性的测试场景。
例：测试电商平台结算模块时，通过探索不同促销规则的组合（如满减 + 折扣券），发现价格计算逻辑漏洞。

3. 测试人员的主导作用

依赖测试人员的经验、直觉和创造力，而非工具或文档驱动。
典型场景：安全性测试中，测试人员通过探索性尝试绕过认证机制（如 SQL 注入、越权访问）。

探索性测试的实施流程与策略

1. 探索性测试的基本流程

图片

代码

确定探索目标

范围界定与资源规划

执行探索性测试

记录发现与反馈

迭代优化探索策略

确定探索目标

范围界定与资源规划

执行探索性测试

记录发现与反馈

迭代优化探索策略

豆包

你的 AI 助手，助力每日工作学习

2. 核心策略与方法

基于场景的探索：围绕用户实际使用场景（如 “用户在高铁上切换网络时使用 APP”）设计测试路径。
错误猜测法：基于经验猜测系统可能的薄弱点（如边界值、异常输入、并发操作）。
分层探索：从功能层（如按钮点击）到系统层（如多设备联动）逐步深入。
时间盒管理：将探索划分为多个时间块（如每 30 分钟聚焦一个模块），避免测试范围发散。

探索性测试与其他测试方法的结合

结合方式	优势	实例
与脚本化测试互补	脚本化测试覆盖已知场景，探索性测试补充未知场景，形成完整测试体系。	自动化测试验证 “正常登录流程”，探索性测试验证 “登录时断网→重连后的状态恢复”。
与风险测试结合	基于风险优先级分配探索资源，提升测试效率。	在金融系统中，优先探索 “资金转账” 模块的异常网络中断场景。
与敏捷开发融合	适应需求快速变化，在迭代中动态调整测试重点。	敏捷 sprint 中，针对新增 “优惠券分享” 功能进行探索性测试，发现分享链接失效问题。

探索性测试的典型应用场景

需求不明确或快速迭代的项目
- 例：初创公司的 APP 开发，需求频繁变更，探索性测试可快速验证新功能的可用性。
复杂业务逻辑或用户场景
- 例：银行理财产品系统，探索不同投资组合、利率波动下的计算逻辑是否正确。
新兴技术或架构的系统
- 例：基于 AI 的图像识别系统，探索性测试可验证模型在极端光照、角度下的鲁棒性。
嵌入式与物联网设备
- 例：智能家电测试中，探索性测试验证设备在断网、电压波动后的自动恢复能力。

探索性测试实例：电商平台支付流程测试

场景描述

测试某电商 APP 的 “微信支付” 流程，目标是发现隐藏缺陷（如异常支付状态、数据一致性问题）。

探索步骤与发现

正常流程探索
- 操作：选择商品→点击微信支付→跳转支付页→输入密码→支付成功。
- 探索点：支付成功后，订单状态是否实时更新，库存是否同步扣减。
异常场景探索
- 网络中断：在支付确认页断开 Wi-Fi，观察系统是否提示 “支付处理中”，重连后订单状态是否正确。
- 中途取消：在微信支付页点击 “取消支付”，返回 APP 后是否能正确回到商品页，无订单生成。
- 重复支付：快速点击 “确认支付” 两次，验证是否会产生两笔扣款，系统是否有防重机制。
边界条件探索
- 支付金额为 0.01 元（最小金额）时，支付接口是否正常处理。
- 余额不足时，是否正确提示并跳转至充值页面。