什么是故障注入测试

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

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

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

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

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

硬件故障，

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

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

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

场景描述

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

测试目标

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

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

测试方案与实施

1. 硬件故障注入：传感器信号丢失

   • 注入方法：
     在 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检查一次  
         }  
     }  
     

2. 软件故障注入：内存数据篡改

   • 注入方法：
     在 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);  // 记录错误  
         }  
     }  
     

3. 通信故障注入：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）：在仿真环境中注入虚拟故障（如内存访问错误）。

故障注入测试的注意事项

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

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

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

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

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

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

1. 动态性与灵活性

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

2. 以 “学习” 为驱动

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

3. 测试人员的主导作用

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

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

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

图片

代码

确定探索目标

范围界定与资源规划

执行探索性测试

记录发现与反馈

迭代优化探索策略

确定探索目标

范围界定与资源规划

执行探索性测试

记录发现与反馈

迭代优化探索策略

豆包

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

2. 核心策略与方法

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

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

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

1. 需求不明确或快速迭代的项目

   • 例：初创公司的 APP 开发，需求频繁变更，探索性测试可快速验证新功能的可用性。

2. 复杂业务逻辑或用户场景

   • 例：银行理财产品系统，探索不同投资组合、利率波动下的计算逻辑是否正确。

3. 新兴技术或架构的系统

   • 例：基于 AI 的图像识别系统，探索性测试可验证模型在极端光照、角度下的鲁棒性。

4. 嵌入式与物联网设备

   • 例：智能家电测试中，探索性测试验证设备在断网、电压波动后的自动恢复能力。

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

场景描述

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

探索步骤与发现

1. 正常流程探索

   • 操作：选择商品→点击微信支付→跳转支付页→输入密码→支付成功。
   • 探索点：支付成功后，订单状态是否实时更新，库存是否同步扣减。

2. 异常场景探索

   • 网络中断：在支付确认页断开 Wi-Fi，观察系统是否提示 “支付处理中”，重连后订单状态是否正确。
   • 中途取消：在微信支付页点击 “取消支付”，返回 APP 后是否能正确回到商品页，无订单生成。
   • 重复支付：快速点击 “确认支付” 两次，验证是否会产生两笔扣款，系统是否有防重机制。

3. 边界条件探索

   • 支付金额为 0.01 元（最小金额）时，支付接口是否正常处理。
   • 余额不足时，是否正确提示并跳转至充值页面。

发现的缺陷示例

• 当支付成功但 APP 后台网络延迟时，订单状态显示 “待支付”，但实际已扣款（数据一致性问题）。
• 取消支付后，再次进入支付流程时，系统未清空之前的支付参数，导致重复提交。

探索性测试的工具与辅助方法

• 测试管理工具：TestRail（记录探索过程与缺陷）、PractiTest（支持测试会话管理）。
• 思维导图工具：XMind（梳理探索范围与路径，如以 “用户旅程” 为中心扩展测试点）。
• 日志分析工具：ELK Stack（实时分析探索过程中系统的日志异常）。
• 协作工具：Miro（团队协同绘制探索思维导图，共享测试发现）。

探索性测试的优缺点与注意事项

优点

• 发现未知缺陷：尤其适合探索复杂场景或逻辑死角，如多模块交互缺陷。
• 适应变化快：无需提前编写大量测试用例，需求变更时测试调整成本低。
• 提升测试深度：依赖测试人员经验，可挖掘脚本化测试难以覆盖的隐性问题（如用户体验缺陷）。

缺点

• 难以复用：测试过程依赖个人经验，不同测试人员的探索路径差异大，结果难以复现。
• 覆盖率不可控：缺乏系统性设计，可能遗漏重要场景（需结合需求分析弥补）。
• 依赖人员能力：新手测试人员可能无法有效开展探索，需培训或资深人员带领。

实施注意事项

1. 明确探索目标：避免无方向探索，可提前定义 “必须覆盖的风险点”。
2. 结构化记录：使用模板记录探索步骤、发现结果，便于后续复盘（例：时间 + 操作 + 预期 vs 实际 + 截图）。
3. 团队协作：多人分工探索不同模块，定期同步发现，避免重复工作。
4. 与脚本化测试结合：关键场景仍需脚本化测试保证覆盖率，探索性测试作为补充。

总结

探索性测试是一种 “以思维驱动、以发现为目标” 的测试方法，其价值在于突破预设框架，挖掘系统潜在风险。在实际应用中，需结合项目特点（如需求稳定性、团队经验）灵活运用，并与其他测试方法形成互补，才能最大化测试效率与质量。

编辑

分享

探索性测试的具体实施步骤是什么？

探索性测试和脚本化测试有哪些区别？

分享一些探索性测试的实际应用案例