1. 定义与总体框架

软件质量：软件系统与明确/隐含需求一致的程度。
在工程化上，可拆成两类：

• 开发期质量属性：影响研发效率与可演进性（易理解、可扩展、可复用、可测试、可维护、可移植）。
• 运行期质量属性：影响上线后的表现与SLA（性能、安全性、可伸缩性、互操作性、可靠性、可用性、鲁棒性）。

关键方法：把每个质量目标写成质量属性场景（QAS），并绑定度量与验证手段（见 §4）。

2. 六大维度（管理视角）逐条深入

每条均包含：关注点 → 常用度量 → 架构/设计战术 → 验证方法 → 常见误区

2.1 功能性（适合性、准确性、互操作性、依从性）

• 关注点：需求覆盖与业务正确；对外接口遵循标准。
• 度量：功能覆盖率、关键路径缺陷率、接口合规率（Schema/协议校验通过率）。
• 战术：领域建模（DDD）、契约优先（OpenAPI/Proto）、输入输出契约校验、幂等设计。
• 验证：基于契约的测试（Contract Test）、回归/端到端用例集、数据对账。
• 误区：只做”接口能通”，未校验边界/异常与数据一致性。

2.2 可靠性（容错、易恢复、成熟度）

• 关注点：持续无故障；故障后能恢复且不丢关键数据。
• 度量：MTBF/MTTF、错误率、重试成功率、数据恢复点目标（RPO）。
• 战术：冗余/副本、超时+重试+幂等、事务（含补偿事务）、仲裁/选主、写前日志、健康探针。
• 验证：故障注入/混沌工程、断网/抖动演练、数据恢复演练。
• 误区：有重试无幂等；有副本无一致性设计。

2.3 易用性（易学、易理解、易操作）

• 关注点：用户/运维认知负担。
• 度量：新手任务完成率与时长、误操作率、NPS/CSAT、运维手册可完成度。
• 战术：任务流简化、可逆操作（撤销/回滚）、可视化告警与操作审计、良好默认值。
• 验证：可用性测试、可观测性面板的可读性评审、操作演练。
• 误区：仅看页面易用性，忽略运维/排障易用性。

2.4 效率（时间特性、资源特性）

• 关注点：响应时间、吞吐、资源（CPU/内存/IO/网络）利用。
• 度量：延迟分位（P50/P95/P99）、TPS/QPS、CPU/内存/GC、带宽/RTT。
• 战术：缓存（含一致性策略）、连接池/零拷贝、异步批处理、背压与队列、热路径隔离、就近计算。
• 验证：基准/容量/压力测试，性能剖析，瓶颈定位。
• 误区：只看平均值，不看长尾（P95/P99）；”盲目加缓存”引入陈旧/放大效应。

2.5 维护性（可测试、可修改、稳定、易分析）

• 关注点：改动容易、影响面可控、问题可定位。
• 度量：变更lead time、变更失败率、回滚率、代码复杂度/内聚耦合、测试覆盖、缺陷修复时长。
• 战术：稳定的边界（模块/上下文划分）、接口兼容策略、特性开关、可观察性三件套（日志/指标/追踪）、ADR（架构决策记录）。
• 验证：变更演练（一天改法）、回归矩阵、静态/依赖扫描。
• 误区：把”微服务数量”当可维护性的替代指标；无兼容/弃用策略。

2.6 可移植性（适应性、安装性、一致性、替换性）

• 关注点：跨平台/云/硬件迁移成本。
• 度量：迁移工时、环境差异问题数、容器镜像体积/启动时长、平台依赖比率。
• 战术：容器化/基础镜像、IaaS/PaaS 抽象层、可配置化（不硬编码）、跨平台构建流水线。
• 验证：多平台CI矩阵、金丝雀迁移、演练（蓝绿/灰度）。
• 误区：过度抽象导致性能/复杂度飙升；忽视目标平台限制（文件系统、网络MTU等）。

3. 分类深化：开发期 vs 运行期

3.1 开发期质量属性（工程效率与演进能力）

• 易理解性：领域模型/命名一致；度量：认知复杂度、模块文档覆盖率。
  战术：统一术语表、架构视图、代码规范与示例仓库。
• 可扩展性（演进）：新需求落地的摩擦成本。
  度量：新功能交付周期、涉及模块数、破坏性变更比例。
  战术：分层+领域边界、策略/插件点、Schema 演进（向后兼容）。
• 可重用性：公共能力沉淀与复用率。
  度量：组件被复用次数/覆盖的产品数。
  战术：组件目录、二进制/包管理、版本与弃用策略。
• 可测试性：可控可测的切入点。
  度量：覆盖率、独立可测模块数、端到端用例通过率。
  战术：端口与适配器、契约测试、可注入依赖、测试数据工厂。
• 可维护性：见 §2.5。
• 可移植性：见 §2.6。

3.2 运行期质量属性（SLA 与韧性）

• 性能：延迟与吞吐（见 §2.4）。
• 安全性：机密性/完整性/可用性 + 可审计性。
  度量：未授权访问阻断率、漏洞修复时长、密钥轮换周期、审计留存。
  战术：强身份（OIDC、mTLS）、最小权限、加密（静态/传输/端到端）、速率限制、WAF/IDS、审计日志与溯源。
• 可伸缩性：负载增长时的线性扩展能力。
  度量：扩展弹性（单位资源吞吐提升率）、自动扩缩容收敛时间。
  战术：无状态化、分片/分区、事件驱动、读写分离、缓存/队列解耦、水平扩展优先。
• 互操作性：跨系统协同。
  度量：协议兼容通过率、Schema 演进兼容率、集成缺陷率。
  战术：标准协议（HTTP/gRPC/MQTT）、版本化契约、适配层、兼容性测试矩阵。
• 可靠性/可用性：A = MTBF / (MTBF + MTTR)。
  战术与验证见 §2.2；同时建立错误预算与告警SLO。
• 鲁棒性：异常与不良输入下的稳定性。
  度量：异常输入导致崩溃比例、资源泄漏事件数。
  战术：输入校验、隔离舱（Bulkhead）、超时/熔断、背压、资源配额、优雅降级。
  验证：故障注入、极端/畸形数据测试、低带宽/高延迟网络模拟。

小贴士（IoT/边云场景）：把断续网、本地缓存一致性、时钟漂移、固件回滚、离线策略评估纳入运行期质量场景。

4. 把目标写成 QAS：质量属性场景模板

通用模板（六要素）

❝

在【环境】下，当【刺激源】发出【刺激】作用于【制品】时，系统应【响应】，并以【响应度量】验证。

示例

• 性能：在”高峰（1万rps）”环境下，用户提交订单触发结账服务，请求应完成处理并保证**P95<250ms、错误率<0.2%**；超阈值自动降级”去个性化推荐”。
• 可用性：当主支付网关故障时，系统在30秒内切备用通道，业务不中断；MTTR≤5分钟。
• 安全：对未授权访问结算明细的请求，应拒绝+记录审计，异常行为3秒内触发告警。
• 可修改性：在一天内完成”新增优惠策略”改动，影响模块≤3个，回归用例全绿。
• 互操作性：与第三方账务接口升级到 v2，旧v1 调用仍能90天内兼容并提供弃用告知。

5. 常见权衡与依赖

• 性能 vs 一致性：缓存、异步会引入陈旧或最终一致；需给出业务容忍度与补偿流程。
• 可用性 vs 成本：多活/冗余提升可用性，但增加成本与复杂度。
• 安全 vs 易用/性能：强鉴权与加密可能增加延迟与流程复杂度；通过会话复用/硬件加密/零信任边界缓解。
• 可移植性 vs 效率：抽象层越厚，往往性能越差；对”热路径”允许适度平台优化。
• 可维护性 vs 交付速度：短期堆功能可能牺牲边界稳定与测试债务；用错误预算/技术债看板平衡。

6. 落地路线图

（1）确定SLO：为每个运行期属性定SLO（P95 延迟、可用性、误报/漏报、MTTR…）。

（2）写QAS：SLO→QAS 六要素，把目标可验证化。

（3）映射战术：为每个QAS选定战术（缓存/幂等/熔断/分片…）与实施清单。

（4）度量与可观测性：为每个QAS配置指标、日志、Trace 字段与面板。

（5）验证与门禁：性能/安全/混沌/兼容/回归测试接入CI/CD（失败即阻断）。

（6）治理与演进：ADR、弃用策略、错误预算、定期复盘（ATAM/CBAM 小型化工作坊）。

附：速查表

评审检查清单

• 所有运行期目标都有SLO+QAS与度量/看板
• 每个关键路径有战术→验证的一一映射
• 建立错误预算与告警阈值（含噪声控制）
• 契约/Schema 版本化与弃用公告策略已定义
• 性能/安全/混沌测试已接入 CI 门禁
• 关键决策均有 ADR，并标注权衡/替代方案
• 变更演练（一天改法）结果可量化，影响面受控
• 生产环境具备审计与追踪，满足合规留存