说实话，这是作者第一次见到这个高端的词汇

但是仔细一看内容，我相信其实大家平时工作都有用到，只是很模糊，没有系统化的知道这个知识，也不知道如何真正清楚有效的进行风险分析

那今天我们就来讲一讲这个吧

一、什么是FMEA

FMEA（Failure Mode and Effects Analysis，失效模式与影响分析）是一种系统化的预防性分析技术。

作者有话说：我刚开始还以为，这四个字母是什么高端缩写呢，原来就只是 失效模式与影响分析的缩写，哈哈  

核心思想：
在问题发生之前，主动地去思考：“这个东西可能会怎么失效？如果失效了，会有什么后果？有多严重？为什么会失效？我们能不能提前预防？”

作者有话说：这个东西是做事情之前就分析，用来规避风险的，大家应该知道吧，不是复盘用的，起码我不是把他当这个用的，应该不是吧？

二、FMEA的起源与应用领域

• 起源：20世纪60年代，美国航空航天局（NASA）和阿波罗计划中首次系统应用，用于确保登月任务的安全性。

• 成熟：被汽车工业（尤其是福特、丰田）大力推广，成为QS-9000等质量体系的核心工具。

• 现在：广泛应用于航空航天、汽车、医疗设备、核工业等高可靠性要求的领域，也逐渐被软件行业借鉴。

作者有话说：其实这个东西每个人生活中多多少少都用了，特别是焦虑的人，被老美归纳总结了，就好像是他们的了，所以说归纳总结真的很重要 。

三、FMEA的核心三要素（风险评估的量化指标）

FMEA的核心是通过三个维度的量化评分，来评估风险的高低：

指标	英文	含义	评分范围
严重度 (S)	Severity	如果这个失效发生了，后果有多严重？（用户数据丢失？系统崩溃？只是界面不好看？）	1-10分（10分最严重）
发生度 (O)	Occurrence	这个失效发生的可能性有多大？（是极难触发的边界条件？还是日常操作很容易遇到？）	1-10分（10分最可能发生）
探测度 (D)	Detection	在失效发生后、影响用户前，我们现有的测试手段有多大的可能性发现它？（测试能测出来吗？还是会上线后才发现？）	1-10分（10分最难发现）

风险优先数 RPN = 严重度 (S) × 发生度 (O) × 探测度 (D)

• RPN越高，说明这个失效模式的风险越大，越需要优先采取预防措施。

作者有话说：这里的核心三要素只是分析的不是全部的，还要根据上面的做预防措施。严重程度各位想必已经很熟悉了，平时提bug的时候就要填，就不多说。

但是那这个发生度是怎么回事呢，作者一开始有些不明白，我这还没开始测呢，我怎么知道这个bug的发生的可能性有多大，后来我看看含义，我又以为这个是指的功能操作频率，结果也不是哈哈，我真是太聪明了。最后我才发现，这个也是我们平时经常会思考到的东西。就是开发写出这个bug的概率有多大，这个项目很难，开发又不是很厉害的话那这个发生度就很高了。项目很复杂、开发不熟悉、这个功能跟别的功能交互太多了、需求不清晰 、新功能没有数据支撑、甚至开发频繁离职变动这些都会影响缺陷的发生度。

这个探测度呢，跟我们质量维度的可测试性就有很大的联系了，可测试性很高，那探测度可能很高了，可测试性不高，哎！但是我们很会测，那探测度可能也会高哈哈哈，总之这个就是要结合具体的场景来判断。

四、软件测试中如何应用FMEA？（实战步骤）

在软件测试中，FMEA通常在设计阶段（写代码之前）进行，可以作为测试分析的输入。以下是标准流程：

第一步：确定分析对象

选择一个关键模块或复杂功能。不要试图对整个系统做FMEA，那太耗时了。选择核心业务逻辑、高风险模块（如支付、数据迁移、权限控制）。

第二步：头脑风暴失效模式

针对这个模块的功能，问：“它可能会怎么失效？”

• 功能层面：没反应、反应错误、反应延迟。

• 数据层面：数据丢失、数据写错、数据不一致。

• 接口层面：调用失败、返回超时、返回乱码。

• 用户体验层面：误导用户、让用户无法操作。

第三步：分析影响和原因

对每个失效模式：

• 影响分析：如果发生，对用户、对系统、对业务会有什么后果？（用于评估严重度S）

• 原因分析：为什么会发生？是代码逻辑问题？网络问题？并发问题？第三方依赖问题？（用于评估发生度O）

第四步：评估当前控制措施

我们现在有什么手段来发现这个问题？

• 代码评审能发现吗？

• 单元测试能覆盖吗？

• 功能测试用例能测到吗？

• 性能测试能暴露吗？

• 监控告警能抓到吗？（用于评估探测度D）

第五步：计算RPN，确定优先级

计算S×O×D，找出RPN最高的几个失效模式，这些就是测试设计的重点。

第六步：制定改进措施

• 如果是严重度高：必须改设计，从架构上规避（比如增加二次确认、增加备份机制）。

• 如果是发生度高：需要增加测试用例，加强自动化覆盖。

• 如果是探测度低：需要增加日志、增加监控、设计专门的测试工具。

作者有话说：总结这几个步骤

首先就是要找出我要探测什么东西，然后分析出可能的缺陷

然后就是根据缺陷来定SOD,算出RPN

最后就是根据计算结果来确定优先级制定预防措施

六、FMEA对测试人员的价值

1. 从“被动执行”到“主动预防”

• 普通测试：等代码写好，然后找Bug。

• FMEA思维：在代码还没写的时候，就分析哪里可能出问题，提前设计测试策略，甚至推动设计改进。

作者有话说：这就是传说中的代码左移啊各位！

2. 测试设计的“导航仪”

测试资源总是有限的。FMEA告诉你：哪里风险最高，就把子弹打向哪里。 它帮你回答“测什么”和“测多深”。

作者有话说：快速整合资源！稳准狠！实现精准打击！

3. 沟通的“共同语言”

• 对开发：不是空泛地说“这里要多测测”，而是说“这个失效模式RPN 320，我们需要一起加防护”。

• 对产品：不是简单地说“有风险”，而是说“如果这个发生，后果是客户投诉，严重度10，我们需要增加二次确认”。

作者有话说：下次面对开发的质疑我们将不再吃瘪！拿出量化数据狠狠摔在桌上！

4. 知识沉淀

FMEA表格做出来后，可以成为团队的宝贵资产。新人接手时，看一遍FMEA，就知道这个模块的“命门”在哪里。

作者有话说：不想分享也不是不行 哈哈哈