4. 测试用例设计：基于FMEA和FTA的测试用例设计方法，如何覆盖高风险失效模式

做可靠性测试这么多年，我见过太多团队把测试用例写成“功能点检查清单”。说白了，就是照着规格书一条条对，根本没想过“这东西到底会怎么坏”。

你想想看，如果连产品最可能怎么失效都不知道，那测试用例写得再漂亮，也只是自我安慰。今天我们就聊聊怎么用FMEA和FTA这两个工具，把高风险失效模式一个一个揪出来，再转化成真正能打的测试用例。

4.1 FMEA：从失效模式倒推测试点

FMEA（失效模式与影响分析）是我个人最常用的工具。它的逻辑很简单：针对每个功能或组件，列出所有可能的失效模式，评估严重度（S）、发生频度（O）、可检测度（D），算出风险优先数（RPN），然后优先处理RPN高的项。

我在项目中遇到过这样一个案例：一款电源模块的FMEA分析显示，“输出电容老化导致纹波超标”的RPN高达252（S=9, O=7, D=4）。但原来的测试用例只测了常温下的输出纹波，根本没覆盖高温老化场景。结果呢？产品在客户现场用了半年，纹波超标导致后级电路误触发，批量召回。

所以，FMEA的产出不能只停留在文档里。你得把它翻译成测试用例。怎么翻译？我习惯用下面这个映射表：

4.2 FTA：从顶事件往下拆，不漏测

FMEA是从下往上（组件→系统），FTA（故障树分析）正好反过来——从上往下（顶事件→底事件）。

为什么要用FTA？因为有些失效模式是多个因素组合触发的，FMEA容易漏掉这种组合逻辑。举个例子，“系统死机”这个顶事件，可能是“电源波动”和“看门狗失效”同时发生才导致的。FMEA单独看电源和看门狗，RPN都不高，但组合起来就是致命问题。

我记得有一次做车载控制器的测试，FMEA分析完发现所有单项RPN都低于100，大家还挺高兴。结果FTA一建树，发现“CAN通信中断”这个顶事件下面，有3个底事件是“软件配置错误+硬件管脚虚焊+总线负载过高”的与门组合。单独测任何一项都测不出来，必须同时施加这三个条件。后来我们专门设计了组合应力测试用例，果然复现了问题。

FTA建树的基本步骤：

1. 定义顶事件：比如“产品在高温下功能失效”
2. 逐层分解：用与门（AND）和或门（OR）往下拆
3. 找到底事件：直到不可再分的根本原因
4. 提取测试条件：每个底事件或组合路径就是一条测试用例

下面这张图是我常用的FTA结构，你可以参考：

4.3 如何用FMEA+FTA组合拳覆盖高风险失效模式

FMEA和FTA不是二选一，而是互补的。我个人的做法是：

1. 先用FMEA做广度扫描：列出所有可能的失效模式，筛出RPN高的项
2. 再用FTA做深度挖掘：针对高RPN项或系统级顶事件，建故障树找组合逻辑
3. 合并输出测试用例矩阵：把FMEA的单项测试和FTA的组合测试汇总到一起

下面这个表格是我在项目中实际用过的测试用例矩阵模板：

4.4 实战避坑指南

最后分享几个我踩过的坑，希望能帮你少走弯路：

• 别让FMEA变成“填表运动”：我曾经在一个项目里，FMEA表格填了300多行，但没人去验证那些失效模式是否真的会发生。FMEA的价值在于后续的测试和改善，不是文档本身。
• FTA的“与门”最容易漏：很多测试工程师习惯测单项应力，但实际失效往往是多应力耦合的。我建议FTA建完后，专门标出所有“与门”路径，这些就是组合测试用例的来源。
• RPN不是绝对真理：严重度S打9分，但发生频度O只有1分，RPN=9。这种要不要测？我的经验是：只要S≥8，就算O很低，也建议至少测一次。因为一旦发生就是灾难。
• 测试判据要量化：别写“功能正常”这种模糊判据。要写“输出电压在4.75V~5.25V之间”、“复位信号脉宽≤200ms”。我在评审时看到模糊判据一定会打回去重写。