★ 第八章 · 软件质量属性
软件质量属性与可靠性
涵盖六大质量属性定义与战术、质量属性场景六要素、可靠性指标计算（MTBF/MTTF/MTTR）、容错与避错技术对比、可靠性增长测试等核心考点。本章是架构评估（ATAM）的基础，案例分析高频考点。
6知识小节
核心架构评估基础
★★★★★重要程度
10练习题
六大质量属性
核心考点📊六大质量属性定义与实现策略
| 质量属性 | 定义 | 量化指标 | 实现策略（战术） |
|---|---|---|---|
| 性能 Performance | 系统对事件做出响应的能力 | 响应时间、吞吐量、并发用户数 | 控制资源（连接池/并发控制）、管理资源（调度策略）、减少计算开销（缓存/异步） |
| 可用性 Availability | 系统正常运行时间的比例 | 可用性百分比、MTBF、MTTR | 错误检测（心跳/异常监控）、错误恢复（冗余/检查点）、错误预防（服务下线/事务管理） |
| 安全性 Security | 系统抵抗非授权访问和攻击的能力 | 漏洞数、攻击成功率、响应时间 | 认证授权、加密传输/存储、审计日志、入侵检测 |
| 可修改性 Modifiability | 系统接受变更的能力和成本 | 变更平均成本、变更平均时间 | 局部化变更（高内聚/抽象）、防止连锁反应（接口隔离/中介）、延迟绑定（配置/插件） |
| 可靠性 Reliability | 系统在规定条件下无故障运行的能力 | MTBF、故障率 | 冗余设计、容错机制、错误处理、监控告警 |
| 可测试性 Testability | 系统被测试的容易程度 | 测试覆盖率、缺陷发现率 | 模块化设计、接口明确、依赖注入、可观测性 |
⚡性能战术 vs 可用性战术区分
| 维度 | 性能战术 | 可用性战术 |
|---|---|---|
| 目标 | 让系统响应更快 | 让系统不宕机 |
| 核心思路 | 减少处理时间/增加处理能力 | 故障检测+快速恢复 |
| 典型手段 | 缓存、异步处理、负载均衡、连接池 | 心跳检测、冗余部署、故障转移、检查点 |
| 关注点 | 速度、吞吐量 | 连续性、容错 |
考试要点：性能关注"快"，可用性关注"不宕机"，可靠性关注"不出错"。缓存属于性能战术，心跳检测属于可用性战术，冗余同时服务于可用性和可靠性。可修改性的核心是"低耦合、高内聚"。
质量属性场景（六要素）
ATAM基础📋场景六要素详解
1. 刺激源（Source）：产生刺激的实体——用户、外部系统、攻击者、硬件故障等
2. 刺激（Stimulus）：到达系统的事件或条件变化
3. 环境（Artifact）：刺激发生时系统的运行状态（正常运行/维护/过载等）
4. 制品（Artifact）：被刺激影响的系统部分（整个系统/某模块/某服务）
5. 响应（Response）：系统对刺激采取的行动
6. 响应度量（Measure）：度量响应是否满足要求的量化指标
📌具体场景示例
| 要素 | 性能场景 | 可用性场景 | 安全性场景 |
|---|---|---|---|
| 刺激源 | 终端用户 | 服务器硬件 | 外部攻击者 |
| 刺激 | 发起查询请求 | CPU故障 | SQL注入攻击 |
| 环境 | 正常运行，高峰时段 | 正常运行中 | 正常运行中 |
| 制品 | 订单查询服务 | Web服务器节点 | 用户数据库 |
| 响应 | 处理请求并返回结果 | 故障转移至备用节点 | 拦截攻击并记录日志 |
| 响应度量 | 95%请求在2秒内响应 | 切换时间<30秒，数据不丢失 | 100%拦截，5分钟内告警 |
📌更多场景示例
| 要素 | 可修改性场景 | 可靠性场景 | 可测试性场景 |
|---|---|---|---|
| 刺激源 | 开发团队 | 网络交换机 | 测试人员 |
| 刺激 | 新增支付方式 | 网络中断5分钟 | 执行回归测试 |
| 环境 | 设计阶段 | 系统运行中 | 预发布环境 |
| 制品 | 支付模块 | 消息队列服务 | 订单处理流程 |
| 响应 | 新增支付插件，无需修改核心代码 | 消息暂存本地，网络恢复后自动补发 | 用例自动执行，生成覆盖率报告 |
| 响应度量 | 2人日内完成，不影响其他模块 | 消息零丢失，延迟<10分钟 | 覆盖率>80%，缺陷检出率>95% |
考试要点：质量属性场景的六要素必须完整描述。考试中常给出一个场景描述，要求识别六要素或判断属于哪种质量属性。注意区分：性能场景关注响应时间/吞吐量，可用性场景关注故障恢复，可靠性场景关注持续无故障运行。
质量属性战术
架构设计🏍性能战术
控制计算资源：管理执行时间（调度策略）、管理事件响应（限制队列大小）
控制资源使用：连接池管理、内存管理、线程池管理
管理并发：多线程/多进程、并发控制（锁/信号量）、减少上下文切换
减少计算开销：缓存（Cache）、异步处理、负载均衡、算法优化
减少数据量：数据压缩、增量传输、分页查询
🔄可用性战术
错误检测：心跳检测（定期探测存活）、异常监控（指标/日志告警）、Ping/Echo
错误恢复：冗余（主动/被动冗余）、检查点（Checkpoint，定期保存状态）、回滚（Rollback）、重新初始化
错误预防：服务下线（从负载均衡移除后维护）、事务管理（ACID保证一致性）
故障转移：主备切换（Active-Standby）、双活部署（Active-Active）
🔧可修改性战术
局部化变更：高内聚（相关功能集中）、低耦合（减少模块间依赖）、抽象接口（隐藏实现细节）
防止连锁反应：信息隐藏、接口隔离、使用中介（Mediator）解耦
延迟绑定：配置文件、插件架构、依赖注入、服务发现
其他：模块注册、多实例、发布-订阅模式
考试要点：性能战术的核心是"快"——减少开销、增加资源、优化并发。可用性战术的核心是"不宕机"——检测、恢复、预防。可修改性战术的核心是"易变"——低耦合、高内聚、抽象。考试中常给出具体技术方案，要求判断属于哪种质量属性的哪种战术。
软件可靠性基础
计算考点📈可靠性核心指标
MTTF（Mean Time To Failure）：平均故障前时间，系统从开始运行到第一次出现故障的平均时间
MTTR（Mean Time To Repair）：平均修复时间，从故障发生到恢复正常运行所需的平均时间
MTBF（Mean Time Between Failures）：平均无故障时间，两次相邻故障之间的平均时间
核心公式：MTBF = MTTF + MTTR
🧪可用性计算公式
可用性：A = MTBF / (MTBF + MTTR)
不可用性：1 - A = MTTR / (MTBF + MTTR)
串联系统可用性：A = A1 × A2 × ... × An（所有组件都可用时系统才可用）
并联系统可用性：A = 1 - (1-A1) × (1-A2) × ... × (1-An)（任一组件可用时系统可用）
📊可用性等级对照表
| 可用性 | 俗称 | 年不可用时间 | 月不可用时间 | 适用场景 |
|---|---|---|---|---|
| 99% | 两个9 | 87.6小时 | 7.3小时 | 普通网站 |
| 99.9% | 三个9 | 8.76小时 | 43.8分钟 | 一般企业应用 |
| 99.99% | 四个9 | 52.6分钟 | 4.38分钟 | 金融/电商核心系统 |
| 99.999% | 五个9 | 5.26分钟 | 26.3秒 | 电信/医疗/航天 |
📐可靠性模型
硬件可靠性：浴缸曲线（Bathtub Curve）——早期失效期（递减）、随机失效期（恒定）、磨损失效期（递增）
软件可靠性：无磨损失效期（软件不会磨损）。故障随测试和修复逐步减少，即可靠性增长
软件可靠性模型：Jelinski-Moranda模型、Goel-Okumoto模型、Musa-Okumoto模型等
必记公式：MTBF = MTTF + MTTR；可用性 A = MTBF / (MTBF + MTTR)。串联系统可靠性相乘（越低越差），并联系统1-各不可用性相乘（越高越好）。可用性99.9% = 8.76小时/年，99.99% = 52.6分钟/年，99.999% = 5.26分钟/年。
MTBF / MTTF / MTTR 关系图
正常运行
MTTF
MTTF
故障发生
故障点
故障点
修复中
MTTR
MTTR
恢复正常
循环
循环
MTBF = MTTF + MTTR｜可用性 = MTTF / (MTTF + MTTR)
容错与避错技术
高频对比🛡容错技术（Fault Tolerance）
容错技术承认故障必然发生，通过设计使系统在出现故障时仍能继续运行。
N版本程序设计：N个独立团队用不同算法/语言实现同一功能，运行时通过投票机制选择结果。成本高，适合安全关键系统
恢复块方法：主模块+备用模块+验收测试。主模块运行后验证结果，若失败则回滚并启动备用模块
冗余技术：硬件冗余（备用设备）、软件冗余（N版本/恢复块）、时间冗余（重复执行）、信息冗余（校验码/ECC）
降级运行：故障时降低功能等级但不中断服务（如推荐系统降级为默认推荐）
🚫避错技术（Fault Avoidance）
避错技术力求在开发过程中发现和消除故障，防止故障发生。
形式化方法：用数学方法描述和验证系统规格。最严格，成本最高
软件评审：同行评审（Peer Review）、走查（Walkthrough）、审查（Inspection）
软件测试：单元测试、集成测试、系统测试、回归测试
静态分析：代码规范检查、代码复杂度分析、依赖分析
⚖容错 vs 避错对比
| 对比维度 | 容错技术 | 避错技术 |
|---|---|---|
| 理念 | 承认故障存在，设计容错机制 | 努力消除故障，防止发生 |
| 时机 | 运行时（Runtime） | 开发时（Development） |
| 代表技术 | N版本程序设计、恢复块、冗余 | 评审、测试、形式化方法 |
| 成本 | 运行开销大 | 开发成本高 |
| 适用 | 安全关键系统（航空/医疗） | 所有软件项目 |
考试要点：N版本程序设计 = 多版本投票；恢复块 = 主模块+备用模块+验收测试。容错关注"运行时"，避错关注"开发时"。形式化方法是最高级别的避错技术。冗余分四类：硬件、软件、时间、信息。
可靠性管理
实践考点🔄故障管理流程
1. 故障检测：通过监控、心跳、日志等手段发现故障发生
2. 故障诊断：定位故障根因，分析影响范围
3. 故障恢复：重启服务、切换备用、回滚版本、修复数据
4. 故障预防：根因分析、改进架构、增加监控、完善预案
📈可靠性增长测试
定义：通过"测试→发现缺陷→修复→再测试"的迭代过程，逐步提高软件可靠性
流程：制定可靠性目标 → 设计测试用例 → 执行测试 → 记录故障 → 修复缺陷 → 验证修复 → 评估可靠性增长
指标：故障密度（缺陷数/KLOC）、故障率（故障数/时间）、MTBF增长趋势
模型：可靠性增长曲线通常呈"S"型，初期故障多增长快，后期趋于平稳
考试要点：故障管理四步流程：检测→诊断→恢复→预防，不可颠倒。可靠性增长测试的核心理念是通过迭代测试和修复逐步提高可靠性。考试中可能给出故障管理场景，要求排序或选择下一步操作。
章节练习
10题📝 第八章 · 软件质量属性练习题
0 / 10