软件失效模式与影响分析（Software Failure Modes and Effects Analysis，软件FMEA） 是一种通过识别软件失效模式(存在概率可能出现的故障)，分析其后果，并研究各种失效模式产生的原因，寻找消除和减少其有害后果的方法，以提高软件可靠性和安全性的方法。
软件FMEA的基本步骤

1. 系统定义：确定分析级别和分析对象，明确系统的主要功能、用途、约束条件
2. 失效模式分析：识别软件失效模式，例如输出结果错误、精度不满足要求等
3. 失效原因分析：找出潜在的软件缺陷，例如逻辑遗漏、数据错误等
4. 失效影响分析：分析每个失效模式对系统的影响及其严重性
5. 制定改进措施：根据失效原因和影响的严重性，制定相应的改进措施

软件FMEA的分类

• 系统级软件FMEA：在软件开发阶段的早期进行，用于发现软件需求或软件体系结构中的缺陷
• 详细级软件FMEA：分析已经编码实现的软件单元或由伪代码描述的单元，通常在软件设计完成后进行

国内对软件失效模式分析方法的应用很少，国内绝大部分的科技研发公司依然是一种作坊模式，对软件开发过程的管理还停留在比较原始的阶段，对软件工程的理解还很浅，几家互联网企业大部分在玩敏捷，对可靠性的应对措施往往是通过多备份、异地容灾的方式。国内也没有很多深入研究软件FMEA的方法，网上相关的文章也比较少，所以触发作者把之前的经验总结分享出来。

• 北京航空航天大学：系统工程系有SFMEA的课件，在战机飞控软件的设计中有应用SFMEA，同时公开有两篇《基于UML建模软件的SFMEA分析研究》论文
• 美国最有名软件FMEA专家：安.玛丽.纽菲尔德  根据自己在相关行业多年的经验出版了《Effective Application of Software Failure Modes Effects Analysis》并建了 网站推广SFMEA方法。

如汽车、军工、航天、存储等在可靠性要求高的领域大家可以尝试应用《软件失效模式与故障影响分析》的方法，用于提升系统的可靠性。

本文作者结合自身在多个项目中的实践并阅读了北航的论文后整理输出关于SFMEA的培训ppt并在单位内部做了分享和培训。

软件系统重通常出错的原因：

• 软件工程师不会编写需求规格书中未要求的代码
• 测试工程师会测需求规格书要求的功能，但不会测规格书中未要求的功能
• 软件工程师可能并不完全按照需求规格书的要求进行的编码，需求正确不代表代码也正确
• 如果有多个实现需求的方案，软件工程师可能会选择最简单的实现方案
• 不能假设在软件发布前的完整测试能发现所有软件故障；

软件FMEA的关键收益：

解决一种故障模式可能意味着消除多处故障发生点，也就是说，如果软件工程师在硬件故障时没有考虑软件应该做什么，这会导致所有调用这些接口的地方成为问题爆发的风险点；

SFMEA输出文档（含容错措施、定位信息、故障注入方法、测试用例）可用于完善：

1. 完善软件需求规格说明书或使需求规格评审更有效

• 需求规格说明书或设计文档中未明确的异常处理和容错措施；
• 需求规格说明书中未写明的假设；

1. 完善设计方案和代码或使设计审查更有效

• 功能/特性需要的故障处理更完备；
• 开发工程师在查看设计文档或代码时更容易看到测试过程很难发现的缺陷

1. 构建健康管理系统或内置BIT

• 识别无法解决的缺陷并增加冗余硬件

1. 完善测试方案

• 识别能发现故障的用例，而不仅仅是确认需求
• 识别那些难以发现或测试代价高昂的故障

1. 完善开发软件或支持文档，最大限度的减少用户错误

SFMEA开展阶段：

单体软件(如嵌入式的单片机软件)一般只开展详细级软件FMEA，分布式软件、多线程软件、微服务软件同时需开展系统级软件FMEA

1. 详细级软件FMEA，一般在详设或编码阶段开展软件失效影响分析；
2. FMEA除可能的失效模式外，还需要分析故障的影响、容错措施、定位信息、故障注入方式、测试用例等信息；
3. 输出的测试用例要能集成到CI环境中，通过CI持续看护相应的故障下对应的容错措施是持续有效

故障模式库的建立

1. 故障模式即为本产品常见的故障类型，初始版本一般由各模块的有经验老员工“头脑风暴”的方式输出
2. 在实际开发过程中可以再逐渐将遇到的一些典型问题增补到故障模式库中，进一步持续完善故障模式库

故障分类	故障类型
通用类	内存申请失败
	异常掉电
	内存ECC
	return fail
	……
前端故障	链路闪断
	误码
	……
后端故障	……
……

基于UML的软件建模开展SFMEA故障分析

• 基于UML的SFMEA故障分析，更多的是针对软件与硬件的交互接口、模块与模块间的交互接口开展
• 详设文档中的UML图是开展SFMEA的前提，针对流程图结合可能的失效模式做正交分析

基于UML的活动图/泳道图开展SFMEA故障分析

上述泳道图中不同泳道间的交互步骤需要结合前述的故障模型做正交，开展分析

基于UML的消息序列图开展SFMEA方法进行故障分析：

上图的中step 3/4/7/8和各种故障类型做正交(所谓正交可以理解为表格的行列两个维度做分析看交互点是否有概率存在)，有存在可能性且影响较大的就要考虑做降低概率或容错措施等；

SFMEA分析结果

SFMEA的分析以excel表的形式作为输出结果

类型

迭代

特性

用例编号

正交步骤

正交对象(失效模式)

故障影响

发生概率

容错措施

定位信息

预置条件

故障注入方式

测试步骤

预期结果

责任人

测试结果

测试对齐

SFMEA

UML图中的step

故障模式1

出故障后的后果

高

规避措施，或降低影响的措施

DFX:log/print、统计等

测试预置条件

测测试性手段

step1； step2； step3；

故障模式2

中

故障模式2

低

最终转换为自动化测试用例

自动化测试用例持续保障容错措施、DFX等代码持续有效，开发员工需按上述表格分析的结果，使用gtest等工具转换为自动化测试代码，加到每日持续集成中，保障在后续的代码迭代更新中持续有效。

#include "gtest/gtest.h"
#include "MyStack.h"

//测试实例1
TEST(testStack, simpletest) {
    MyStack st;
    st.push(4);
    EXPECT_EQ(4, st.pop());//使用Google Test宏进行测试（非致命断言）
}

//测试实例2
TEST(testStack, testAll) {
    MyStack st;
    st.push(9);
    st.push(28);
    
    int val = st.pop();
    EXPECT_EQ(28, val);//28等于val则测试通过（非致命断言）
    EXPECT_NE(0,val);//0不等于val则测试通过（非致命断言）
    EXPECT_GT(29, val);//29大于val则测试通过（非致命断言）
    EXPECT_GE(29, val);//29大于等于val则测试通过（非致命断言）
    EXPECT_TRUE(val == 28) << "val is not equal to 28";//val == 28结果为false，输出后面日志（非致命断言）
}
————————————————

                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
                        
原文链接：https://blog.csdn.net/wangmj_hdu/article/details/118369609

总述：

SFMEA可以理解为一种系统性的分析软件运行过程中存在的异常路径，并采取相应的应对措施的系统性的方法论。软件失效模型与故障影响分析SFMEA，确实并非软件开发过程中必须的，但对高可靠性要求的产品开发，应用SFMEA可大幅提升系统的可靠性。作者曾在多个年发货上百万的产品用应用上述方法，产品上市后的失效率做到了小于100ppm，并且这100ppm基本也不是软件的问题。当然之前产品的质量也不仅仅只是应用了SFMEA的方法，应该是一些列成熟的软件工程方法应用的最终效果。