论坛精彩讲稿回顾|软件质量和可靠性工程(SRE)

在数字化时代，软件质量与可靠性已成为企业竞争力的核心。本文基于2024可靠性应用技术国际论坛资料，系统梳理软件可靠性工程（SRE）的关键概念、方法、模型与最佳实践，助你快速掌握SRE精髓。

软件质量和可靠性工程(SRE)

冯永昌；

ISO/TC176技术委员会委员；

美国质量学会院士(ASQ Fellow)；

英国皇家质量学院特许质量专员(CQP-MCQI)。

根据ANSI/IEEE标准定义：软件可靠性是指在指定环境下、指定时间内，软件运行无失效的概率。

与硬件不同，软件失效有其独特的机理：

·失效主因：设计缺陷（而非物理磨损）

·无老化现象：软件没有与能量相关的磨损阶段

·可修复性：定期重启可缓解部分问题

·时间独立性：软件可靠性不是运行时间的简单函数

·环境因素：环境影响输入，但不直接影响可靠性

·冗余局限：相同组件冗余无法提升可靠性

数据显示，影响软件可靠性的因素及其占比分别为：

注：技术和人员因素常被忽视，实际上它们对可靠性影响巨大。

·1960s-1970s：首次记录软件导致的系统故障（1962）；“软件可靠性”术语诞生（1968）；注意到“钟形曲线”

·1980s-1990s：美国空军罗马中心开发首个公开预测模型（仅适用于飞机，后未更新）

·2000s以后：专有模型出现，IEEE 1633标准改版贴近实践

该模型是国际通用的软件质量评估框架，强调外部度量：通过在测试和使用中观察系统行为来测量质量。

常用可靠性指标

·MTTF：平均失效时间

·MTTCF：平均关键失效时间

·MTBI：平均中断间隔时间

·MTBCI：平均关键中断间隔时间

·MTSWR：平均软件恢复时间

影响MTTF/MTTCF的三大要素

1、现场缺陷密度：缺陷减半 → MTBF翻倍

2、有效代码大小：有效代码减半 → MTBF翻倍

3、可靠性增长：交付后真实用户运行时间影响成长曲线

·SW-FMEA（软件失效模式与影响分析）

·SW-FTA（软件故障树分析）

·根本原因分析、正式产品评审

1、避免“编码一点、测试一点”；避免大版本、大团队；进行微观进度管理

2、强制开发人员进行模块、集成级的白盒测试

3、采用易可视化的技术追踪需求、设计、代码、测试

4、明确软件不该做什么

5、了解最终用户，吸纳领域专家，让客户参与需求

6、即使小版本也不跳过需求、设计、单元测试等环节

7、采用正式评审、SW-FMEA、根因分析等缺陷削减技术

8、流程改进要量体裁衣

9、严格版本控制、缺陷跟踪、变更优先级管理，禁止未记录变更

10、学习如何更好地测试软件，而非单纯延长测试时间

国际标准（ISO/IEEE）

·ISO/IEC 25010:2011 软件质量模型

·ISO/IEC 25023:2016 产品质量测量

·IEEE 730-2014 软件质量保证过程

·IEEE 1633-2016 软件可靠性推荐实践

国内标准（GB/T）

·GB/T 25000.1-2021 SQuaRE指南

·GB/T 8567-2016 软件文档编制规范

·GB/T 15532-2008 软件测试规范

通用可靠性标准

·IEC 61508-3（功能安全-软件要求）

·SAE JA 1002/1003（软件可靠性项目标准与实施指南）

·软件可靠性是软件质量中最关键的部分

·研究分为三块：建模、测量、改进

建模：已成熟，但不存在通用模型

测量：仍在进化，需间接测量相关因素

改进：困难，源于对软件复杂性认识不足，无法保证100%无缺陷

软件可靠性工程（SRE）不是一蹴而就的，它需要技术、流程、人员的持续优化。掌握上述方法，并结合实际项目灵活应用，才能稳步提升软件交付质量与用户满意度。

对应讲稿完整视频链接：

https://dgqf7.xetsl.com/s/w2jCp

扫码立即观看

相关链接：

含金量拉满！|2026可靠性应用技术国际论坛豪华嘉宾阵容&议题更新

【培训信息】可靠性测试样本量的实用贝叶斯方法培训开课通知

【培训信息】可靠性导向的产品设计与开发（Desing-for-Reliability）开课通知

【培训信息】新版FMEA理论与实践开课通知