学习目标
完成本讲学习后，你将能够：
- 理解软件质量的基本概念和重要性
- 掌握ISO/IEC 25000系列标准体系架构
- 了解GB/T 34943质量模型的8个质量特性
- 熟悉GB/T 34944质量要求的制定方法
- 认识GB/T 25000.51 RUSP标准的应用场景
- 分析三个标准之间的关系和协同作用
本讲是整个课程的基础，请认真听讲
真实案例：2018年英国TSB银行系统大崩溃
事件经过
2018年4月，英国TSB银行进行IT系统迁移，从Lloyds银行的旧系统迁移到母公司Sabadell的新平台。升级后系统完全崩溃。
具体影响
- 190万客户无法访问网上银行
- ATM取款功能瘫痪持续一周
- 客户看到其他人的账户信息
- 37万客户的按揭贷款利息计算错误
- 移动APP完全无法使用
损失统计
- 直接损失：3.3亿英镑（约30亿人民币）
- CEO Paul Pester被迫辞职
- 客户流失：80,000个账户关闭
- 监管罚款：4,800万英镑
软件质量问题造成的重大损失案例
1. 波音737 MAX的MCAS系统（2018-2019）
- 软件逻辑缺陷导致两起空难
- 346人死亡
- 波音损失超过180亿美元
2. 东京证券交易所系统故障（2020年10月）
- 硬件故障后备份系统切换失败
- 全天停止交易
- 影响交易额6万亿日元
3. Facebook全球宕机（2021年10月）
- BGP配置错误导致全球服务中断6小时
- 影响35亿用户
- 市值蒸发470亿美元
结论：软件质量问题不仅造成经济损失，更可能危及生命
软件质量的经济账
全球软件质量成本报告（CISQ 2022）
美国市场数据
- 软件缺陷造成的损失：2.41万亿美元/年
- 占GDP比例：10.2%
- 平均每个程序员产生的缺陷成本：51,000美元/年
中国市场估算
- 软件缺陷年度损失：约1.5万亿人民币
- IT项目失败率：31%
- 超预算项目比例：52%
行业分布
- 金融服务业：4,850亿美元
- 医疗健康：3,920亿美元
- 制造业：2,670亿美元
- 零售业：1,960亿美元
数据来源：Consortium for Information & Software Quality (CISQ)
什么是软件质量？
ISO/IEC 25000:2014 标准定义：
"软件产品在规定条件下使用时，满足明确和隐含需求的能力的总和"
关键词解析
规定条件
- 运行环境（操作系统、硬件配置）
- 使用场景（用户类型、使用频率）
- 负载条件（并发用户数、数据量）
明确需求
- 功能需求规格说明书中的内容
- 合同条款规定的性能指标
- 法律法规的强制性要求
隐含需求
- 行业惯例
如银行系统24小时可用
- 用户期望
如电商网站快速响应
- 安全基线
如密码加密存储
软件质量 = 功能质量 + 结构质量
功能质量（做正确的事）
- 需求的完整实现
- 业务流程的准确性
- 计算结果的正确性
- 用户任务的完成度
示例：银行转账功能
✓ 金额正确扣减和增加
✓ 交易记录准确保存
✓ 余额实时更新
结构质量（正确地做事）
- 代码的可维护性
- 系统的可扩展性
- 性能的可伸缩性
- 安全的可靠性
示例：银行转账实现
✓ 代码模块化设计
✓ 数据库事务保证一致性
✓ 加密传输敏感数据
越晚发现，代价越大
IBM系统科学研究所的研究数据
| 发现阶段 |
相对成本 |
实际成本示例 |
| 需求阶段 |
1× |
1,000元 |
| 设计阶段 |
6× |
6,000元 |
| 编码阶段 |
10× |
10,000元 |
| 单元测试 |
15× |
15,000元 |
| 集成测试 |
22× |
22,000元 |
| 系统测试 |
50× |
50,000元 |
| 生产环境 |
100× |
100,000元 |
真实案例：某电商平台优惠券计算bug
• 开发阶段修复：2人天
• 生产环境修复：200人天（含数据修复、用户补偿、公关处理）
标准化 - 质量管理的基石
没有标准的困境
A公司说："我们的软件质量很高"
B公司说："我们的软件质量更高"
客户困惑："如何比较？标准是什么？"
有了标准后
A公司："我们达到GB/T 34943的可靠性4级"
B公司："我们达到GB/T 34943的可靠性3级"
客户明确："A公司的可靠性更好"
标准的四大作用
1. 统一语言
消除沟通歧义
2. 量化评价
从定性到定量
3. 持续改进
明确改进方向
4. 商业价值
投标资质证明
从ISO 9126到ISO/IEC 25000
第一代：ISO/IEC 9126系列（1991-2001）
发布时间：1991年首版，2001年修订
核心内容：6大特性，27个子特性
局限性：
第二代：ISO/IEC 25000系列（2005-现在）
正式名称：SQuaRE (Software product Quality Requirements and Evaluation)
发布历程：
- 2005年：25000基础标准
- 2011年：25010质量模型
- 2014年：完整体系形成
改进之处：
- 增加使用质量和数据质量
- 提供具体度量方法
- 完整的评价流程
GB/T软件质量标准族谱
采标情况（等同采用ISO/IEC标准）
| GB/T标准号 |
对应ISO/IEC |
中文名称 |
发布年份 |
| GB/T 25000.10 |
ISO/IEC 25010 |
系统与软件质量模型 |
2016 |
| GB/T 25000.12 |
ISO/IEC 25012 |
数据质量模型 |
2017 |
| GB/T 25000.51 |
ISO/IEC 25051 |
RUSP质量要求 |
2016 |
| GB/T 34943 |
ISO/IEC 25010 |
质量模型（本地化） |
2017 |
| GB/T 34944 |
ISO/IEC 25030 |
质量要求（本地化） |
2017 |
中国特色补充
- 增加了中文示例
- 补充了本土化案例
- 强调了安全性要求（等保2.0）
- 适配了国内行业规范
ISO/IEC 25000 系列 - 五大模块
2501n - 质量模型
（设计图纸）
- 25010：产品质量模型
- 25011：服务质量模型
- 25012：数据质量模型
2502n - 质量测量
（测量工具）
- 25020：测量参考模型
- 25021：质量测量元素
- 25022-25025：具体度量方法
2504n - 质量评价
（评审标准）
- 25040：评价过程
- 25041：评价指南
- 25045：可恢复性评价
每个标准都是一份独立文档，总计超过2000页
SQuaRE的三大核心理念
1. 多视角质量观
传统观点："质量就是没有Bug"
SQuaRE观点："质量是多维度的综合体现"
- 开发者视角：代码优雅、架构清晰
- 用户视角：好用、快速、稳定
- 运维视角：易部署、易监控、易扩展
- 商业视角：成本可控、风险可管
2. 全生命周期覆盖
需求→设计→开发→测试→部署→运维→退役
每个阶段都有对应的质量活动和标准
3. 可度量可验证
"不能度量就不能管理" - Peter Drucker
每个质量特性都有：
本课程的三个支柱
为什么选这三个标准？
GB/T 34943
质量模型
作用：回答"什么是质量"
地位：所有质量工作的基础
比喻：质量管理的"元素周期表"
GB/T 34944
质量要求
作用：回答"如何定义质量"
地位：需求工程的核心
比喻：质量管理的"语法规则"
GB/T 25000.51
RUSP标准
作用：回答"产品如何达标"
地位：商用软件的准入门槛
比喻：质量管理的"合格证"
三者关系：模型 → 要求 → 实现
GB/T 34943 - 产品质量模型概览
标准定位：定义"什么是质量"
主要内容
产品质量模型
• 8个质量特性
• 31个质量子特性
使用质量模型
• 5个质量特性
• 11个质量子特性
作用：为质量评价提供维度框架
8 + 5 + 15 = 54个质量特性
产品质量的8大特性
| 质量特性 |
定义 |
1. 功能适合性
(Functional Suitability) |
产品功能满足明示和隐含需求的程度 |
2. 性能效率
(Performance Efficiency) |
相对于所用资源量，产品执行功能的性能 |
3. 兼容性
(Compatibility) |
产品与其他产品交换信息和执行功能的程度 |
4. 易用性
(Usability) |
用户使用产品达到目标的有效性、效率和满意度 |
5. 可靠性
(Reliability) |
产品在规定条件和时间内执行规定功能的程度 |
6. 安全性
(Security) |
产品保护信息和数据的程度 |
7. 维护性
(Maintainability) |
产品被修改的有效性和效率 |
8. 可移植性
(Portability) |
产品从一个环境迁移到另一个环境的有效性和效率 |
每个特性下还有3-6个子特性，共31个子特性
功能适合性 - 软件能做什么
功能适合性的3个子特性
1. 功能完备性 (Functional Completeness)
- 定义：功能集覆盖所有指定任务和用户目标的程度
- 度量：已实现功能数 / 需求规定功能数 × 100%
- 示例：ERP系统需求100个功能点，实现95个，完备性：95%
2. 功能正确性 (Functional Correctness)
- 定义：产品提供满足需求的正确结果的程度
- 度量：正确执行的功能数 / 总功能数 × 100%
- 示例：计算器应用1000个测试用例，通过998个，正确性：99.8%
3. 功能恰当性 (Functional Appropriateness)
- 定义：功能促进完成指定任务和目标的程度
- 评价：用户任务完成的便捷程度
- 示例：批量操作功能减少重复工作
性能效率 - 软件有多快
性能效率的3个子特性
1. 时间特性 (Time Behaviour)
- 响应时间：用户操作到系统响应的时间
- 处理时间：完成特定任务所需时间
- 吞吐率：单位时间内处理的事务数
典型指标：网页加载 < 3秒、API响应 < 200ms、数据库查询 < 100ms
2. 资源利用性 (Resource Utilization)
- CPU使用率：正常负载 < 70%
- 内存占用：不超过可用内存80%
- 网络带宽：峰值不超过80%
- 磁盘I/O：队列深度 < 4
3. 容量 (Capacity)
- 最大并发用户数：如10000
- 最大数据处理量：如100TB
- 最大事务处理量：如10000 TPS
可靠性 - 软件有多稳定
可靠性的4个子特性详解
1. 成熟性 (Maturity)
定义：正常运行时满足可靠性需求的程度
度量指标：
- MTBF（平均故障间隔时间）> 720小时
- 缺陷密度 < 1个/千行代码
2. 可用性 (Availability)
计算公式：可用性 = MTBF / (MTBF + MTTR)
行业标准：
- 99.9%（一年停机8.76小时）- 三个9
- 99.99%（一年停机52.56分钟）- 四个9
- 99.999%（一年停机5.26分钟）- 五个9
3. 容错性 (Fault Tolerance)
- 硬件故障容错：RAID、冗余电源
- 软件故障容错：异常处理、降级服务
- 示例：Redis主从切换、数据库读写分离
4. 易恢复性 (Recoverability)
- RTO（恢复时间目标）：< 4小时
- RPO（恢复点目标）：< 1小时数据
安全性 - 软件有多安全
安全性的5个子特性（CIA+）
1. 保密性 (Confidentiality)
- 数据加密：AES-256、RSA-2048
- 传输加密：TLS 1.3、HTTPS
- 存储加密：透明数据加密(TDE)
2. 完整性 (Integrity)
- 数据校验：MD5、SHA-256
- 数字签名：RSA、ECDSA
- 区块链：不可篡改性
3. 抗抵赖性 (Non-repudiation)
- 数字证书：CA认证
- 审计日志：完整操作记录
- 时间戳：可信时间源
4. 可核查性 (Accountability)
- 操作日志：谁、何时、做什么
- 合规审计：满足监管要求
5. 真实性 (Authenticity)
- 身份认证：多因素认证(MFA)
- 生物识别：指纹、人脸、虹膜
易用性 - 软件好不好用
易用性的6个子特性
1. 可辨识性
用户能否快速判断软件是否满足需求
度量：新用户识别主要功能的时间 < 30秒
2. 易学性
学习曲线的陡峭程度
度量：新用户掌握基本操作的时间 < 2小时
3. 易操作性
操作的便捷程度
原则：常用功能3次点击内可达
4. 用户差错防护
防呆设计：删除前确认
撤销机制：Ctrl+Z
自动保存：防止数据丢失
5. 用户界面美观性
符合设计规范：Material Design、iOS HIG
视觉一致性：颜色、字体、间距
6. 易访问性
无障碍设计：屏幕阅读器支持
WCAG 2.1标准：AA级别
维护性 - 软件好不好改
维护性的5个子特性
1. 模块化 (Modularity)
定义：组件化程度
最佳实践：
- 单一职责原则(SRP)
- 微服务架构
- 依赖注入(DI)
3. 易分析性 (Analysability)
- 问题定位时间 < 2小时
- 日志完整性 > 95%
- 调试工具支持
4. 易修改性 (Modifiability)
- 简单bug修复 < 4小时
- 中等需求变更 < 2天
- 回归测试通过率 > 95%
5. 易测试性 (Testability)
- 单元测试覆盖率 > 80%
- 集成测试自动化率 > 70%
- Mock工具支持
兼容性与可移植性
兼容性的2个子特性
1. 共存性 (Co-existence)
与其他软件共享资源而不产生负面影响
- 不占用常用端口（80、443、3306）
- 不修改系统关键配置
- 不与杀毒软件冲突
2. 互操作性 (Interoperability)
与其他系统交换和使用信息
- 标准协议：REST API、SOAP、GraphQL
- 数据格式：JSON、XML、Protocol Buffers
可移植性的3个子特性
1. 适应性 (Adaptability)
- 支持多操作系统：Windows、Linux、macOS
- 支持多浏览器：Chrome、Firefox、Safari、Edge
- 支持多设备：PC、平板、手机
2. 易安装性 (Installability)
- 一键安装、Docker容器化
- 安装时间 < 10分钟
- 安装成功率 > 99%
使用质量 - 用户体验的5个维度
使用质量模型（Quality in Use）
1. 有效性 (Effectiveness)
- 用户完成任务的准确度和完整度
- 度量：任务完成率、错误率
- 示例：在线购物成功下单率 > 95%
2. 效率 (Efficiency)
- 完成任务所需的资源
- 度量：任务完成时间、步骤数
- 示例：注册流程 < 3分钟
3. 满意度 (Satisfaction)
- 有用性：解决实际问题
- 信任度：用户信赖程度
- 愉悦性：使用过程愉快
- 度量：NPS（净推荐值）> 50
4. 免于风险 (Freedom from Risk)
- 经济风险：财产损失风险
- 健康安全风险：人身伤害风险
- 环境风险：环境破坏风险
5. 覆盖性 (Context Coverage)
- 完备性：覆盖所有使用场景
- 灵活性：适应不同使用环境
数据质量 - 15个关键维度
数据质量模型的15个特性
准确性维度
- 准确性：数据值的正确程度（误差<0.1%）
- 精确性：数据的精度级别（小数位数）
- 可信性：数据来源的可靠程度
完整性维度
- 完整性：必填字段填充率>99%
- 现时性：数据更新及时性<24小时
- 一致性：跨系统数据一致率>99%
可用性维度
- 可用性：数据可被访问和处理
- 可移植性：支持标准格式导入导出
- 可恢复性：数据备份和恢复能力
理解性维度
- 可理解性：数据含义清晰
- 可追溯性：数据血缘关系明确
安全性维度
- 保密性：敏感数据加密
- 可访问性：权限控制完善
- 符合性：满足法规要求
- 效率：数据处理性能
GB/T 34944 - 如何正确定义质量要求
质量要求 vs 功能要求
功能要求示例：
"系统应提供用户登录功能"
→ 描述做什么
质量要求示例：
"登录响应时间应小于2秒，并发1000用户时成功率>99%"
→ 描述做得多好
质量要求的SMART原则
Specific
具体 |
❌ "系统要快"
✅ "查询响应时间<500ms" |
Measurable
可测量 |
❌ "用户体验要好"
✅ "用户满意度评分>4.5/5" |
Achievable
可达成 |
❌ "100%可用性"
✅ "99.9%可用性" |
Relevant
相关 |
❌ "代码行数>10万"
✅ "代码测试覆盖率>80%" |
Time-bound
有时限 |
❌ "将来要支持"
✅ "6个月内上线" |
质量要求的MoSCoW优先级
Must have（必须有）- 60%
- 核心功能的正确性
- 关键数据的安全性
- 法规要求的合规性
示例："支付功能必须符合PCI-DSS标准"
Should have（应该有）- 20%
示例："页面加载应小于3秒"
Could have（可以有）- 15%
示例："支持深色模式"
Won't have（这次不要）- 5%
示例："支持AR/VR界面"
冲突处理原则：安全性 > 可靠性 > 功能性 > 性能 > 易用性
GB/T 25000.51 - 商用现货软件产品的质量要求
什么是RUSP？
Ready to Use Software Product（商用现货软件产品）
典型RUSP产品：Microsoft Office、WPS、Windows、Oracle、MySQL、Photoshop、AutoCAD
RUSP vs 定制软件
| 特征 |
RUSP |
定制软件 |
| 用户群体 |
大量未知用户 |
特定已知用户 |
| 需求来源 |
市场调研 |
用户提供 |
| 更新方式 |
版本发布 |
按需修改 |
| 文档要求 |
完整详细 |
按合同约定 |
| 安装部署 |
标准化 |
定制化 |
| 技术支持 |
通用支持 |
专项支持 |
RUSP质量要求的四层结构
第一层：产品描述（20%）
必须包含：
- 产品名称和版本号
- 功能清单（至少覆盖80%主要功能）
- 运行环境要求（硬件/软件）
- 已知问题和限制
第二层：用户文档（30%）
必须提供：
- 安装指南（成功率>95%）
- 用户手册（覆盖所有功能）
- 快速入门指南（30分钟内上手）
- FAQ（至少50个常见问题）
- 在线帮助系统
第三层：程序质量（40%）
必须达到：
- 功能测试通过率>98%
- 无1、2级严重缺陷
- 性能达到声明指标
- 安全漏洞为零（高危）
标准协同 - 1+1+1>3
实际应用流程
Step 1：使用GB/T 34943选择质量特性
→ 识别产品类型 → 确定关键质量特性 → 设定优先级
Step 2：使用GB/T 34944定义质量要求
→ 将特性转化为具体要求 → 设定可测量的指标 → 明确验收标准
Step 3：使用GB/T 25000.51规范产品
→ 完善产品文档 → 执行质量测试 → 准备交付物
案例：开发在线教育平台
- 34943：重点关注易用性、可靠性、兼容性
- 34944：定义"视频播放流畅度>95%"等要求
- 25000.51：提供教师手册、学生手册、管理员手册
协同效果
- 方向明确：知道做什么
- 目标清晰：知道做多好
- 交付完整：知道怎么交
真实案例 - 阿里云如何应用质量标准
应用GB/T 34943质量模型
- 可靠性：承诺99.995%可用性（全年停机<26分钟）
- 安全性：通过ISO 27001、等保三级认证
- 性能效率：单实例QPS达100万
- 兼容性：支持所有主流开发语言和框架
应用GB/T 34944质量要求
- 明确SLA条款，未达标按比例赔偿
- RTO<30分钟，RPO<1分钟
- API响应时间p99<100ms
应用GB/T 25000.51 RUSP要求
- 提供详尽的产品文档（>5000页）
- 7×24小时技术支持
- 控制台全中文界面
- 新手教程和最佳实践案例
成果
- 市场份额：中国第一（40.1%）
- 客户数量：400万+
- 服务可用性：超过承诺SLA
实施标准的常见误区
误区1：追求所有指标都最优
❌ 错误：8个特性全部追求最高级别
✅ 正确：根据产品特点选择3-4个关键特性
原因：资源有限，需要权衡
误区2：照搬标准不结合实际
❌ 错误：游戏软件套用银行系统标准
✅ 正确：行业特点+通用标准
原因：不同领域差异巨大
误区3：只在测试阶段考虑质量
❌ 错误：开发完成后再对照标准
✅ 正确：需求阶段就引入标准
原因：越早越好，成本越低
误区4：重文档轻实践
❌ 错误：文档完美，产品糟糕
✅ 正确：文档和产品质量并重
原因：用户用的是产品不是文档
误区5：一次达标终身无忧
❌ 错误：通过认证后不再关注
✅ 正确：持续改进和监控
原因：需求和技术都在变化
8周学习计划
基础阶段（1-3周）
- 第1周：标准体系概述 ← 今天在这里
- 第2周：产品质量模型详解
- 第3周：使用质量和数据质量模型
深入阶段（4-6周）
- 第4周：质量要求规范方法
- 第5周：RUSP产品描述和文档
- 第6周：RUSP程序和数据要求
学习建议
- 理论联系实际：每学一个概念，找一个软件对应
- 建立知识体系：画思维导图串联知识点
- 积累案例库：收集质量问题和优秀实践
- 动手实践：选一个开源项目做质量评估
本讲要点总结
记住这10个核心要点
- 软件质量是满足明确和隐含需求的能力总和
- 质量成本随发现阶段呈指数级增长（1→100倍）
- ISO/IEC 25000（SQuaRE）是现行国际标准体系
- GB/T 34943定义了8个质量特性和31个子特性
- GB/T 34944规范了质量要求的SMART原则
- GB/T 25000.51专门针对商用现货软件产品
- 产品质量、使用质量、数据质量是三个视角
- 质量标准提供通用语言、度量方法和评价依据
- 标准应用要贯穿软件全生命周期
- 质量保证需要标准、工具、流程、人员四要素
这10点构成了软件质量管理的基础框架
第二讲预告
GB/T 34943 质量模型 - 产品质量特性深度解析
上半场：功能与性能（30分钟）
- 功能适合性的3个子特性详解
- 性能效率的测试方法和工具
- 兼容性测试矩阵设计
下半场：质量与体验（30分钟）
- 可靠性工程和故障树分析
- 安全性测试和渗透测试
- 易用性测试和用户体验设计
- 维护性度量和重构时机
- 可移植性和容器化技术
准备工作
- 思考：微信最重要的三个质量特性是什么？为什么？
- 观察：找一个软件的质量问题并分类
- 预习：GB/T 34943标准第5-6章
彩蛋预告：下一讲将分享Google、Facebook、Netflix的质量工程实践
第一讲结束
软件质量标准
奠定质量基石
感谢聆听
欢迎提问与讨论
下周同一时间，我们不见不散