软件评估方法:从质量属性场景到架构权衡

哪些决策支撑了目标，哪些决策可能让目标落空，哪两个质量属性正在互相拉扯。

软件评估要交付的就是这张清单。它把"好不好"这种没法验证的判断，换成"哪里有风险、代价是多少"这种可以追踪、可以复核的表述。

一、先把边界划清楚

教材给出的定义是：在架构设计完成之后、系统实现之前，对架构满足质量属性需求的能力进行分析与验证。三个限定词决定了它的活动范围——输入是已经设计出来的架构方案，输出是对质量属性的判断，时间窗在编码之前。

四类输入

时间窗为什么重要

评估放在架构评审通过之后、详细设计与编码之前，是因为这个位置同时满足两个条件：架构信息已经足够支撑分析，改动成本还没有高到无法承受。等到编码完成再发现问题，多半只能带着风险上线，评估也就变成了事后追认。

它不是这些事

评估不产出总分，不替代压力测试、故障演练、安全测试和代码审查，也不负责证明系统永远不出问题。它做的是在投入大量工程资源之前，用少量关键场景检查架构决策，把风险和冲突提前暴露出来。

谁来评

评估负责人（熟悉方法流程）、架构师（提供架构与决策依据）、项目决策者（提供业务目标与约束）、利益相关者代表（提供场景和优先级判断）。少了决策者，评估就失去商业锚点，不知道哪条质量属性更重要；少了业务侧的利益相关者，收集到的场景会明显偏向技术，缓存命中率、连接池大小这类指标挤满清单，而"结算高峰期降级运行"这种真正致命的情形反而没人提。

二、场景是评估用的尺子

只说"系统性能要高"，没法评。因为还不知道谁在什么状态下发起什么请求、请求打到系统哪一部分、系统该怎么反应、达到什么数字才算合格。

质量属性场景（Quality Attribute Scenario）就是把这句空话变成一道具体试题的工具，由六个要素构成：

套成一句话就是：当[刺激源]在[环境]下对[制品]施加[刺激]时，系统应[响应]，且[响应度量]。

拿前面的例子填进去：当充电桩与平台之间的通信链路（刺激源）在系统正常运行状态下（环境）发生中断（刺激）时，通信与计费模块（制品）应切换到备用通道并保持已开始的计费不中断（响应），切换时间不超过 30 秒（响应度量）。

最容易踩的坑

环境指的是刺激到达时系统的内部状态，不是时间点，也不是机房、网络这类外部条件。教材原文用的是"刺激到达时制品所处的环境"，这七个字被误读成"刺激什么时候发生"的概率相当高。

场景分三类

• 用例场景：描述系统日常运行时的预期行为，比如用户提交预约后 1.5 秒内返回桩位列表。

• 增长场景：描述负载增长时的表现，比如并发预约量从 2000 涨到 20000 时响应时间不超过 3 秒。

• 探索场景：描述极端情况下的表现，比如数据库主节点宕机后 20 秒内完成切换。

效用树

场景收集齐了，下一步是排序。真实系统的质量要求动辄几十条，评估时间有限，不可能平均投入。效用树把抽象目标逐层摊开：树根是效用，第二层是质量属性，第三层是属性细化，叶子节点是具体场景。每个叶子标注两个维度——对系统成功的重要程度（高/中/低）和实现难度（高/中/低）。

排序的主体是全部利益相关者集体投票，架构师只负责提供技术分析。评估的注意力应该压在"重要而且困难"的格子里，比如高重要度加大难度的那些场景。

三、评估方法分成三大类

市面上方法很多，按依赖什么来判断，可以归成三类：

三类不是互斥关系。实践中常见做法是以场景为主线组织评估过程，用度量数据给判断提供支撑，再对少数高风险部分建立模型或原型做验证。

四、基于场景的四条路线

这是考试和工程实践里最常遇到的一族，也是本篇的重点。

SAAM：最早的场景评估

Software Architecture Analysis Method，1994 年由 Kazman 等人提出，是架构评估方法的开山之作。五个步骤：开发场景，描述架构，对场景分类并排序，逐个评估间接场景，评估场景交互。

场景在这里被分成两类：当前架构已经支持的叫直接场景，需要修改架构才能支持的叫间接场景。分析的落脚点是间接场景：为了支持它，究竟得动哪些构件。

它的灵魂在第五步。如果两个间接场景都需要改同一个构件，说明这个构件同时承担了多项职责，单一职责原则很可能已经被破坏。只做单场景分析，拿不到这个结论。

SAAM 早期主要用于可修改性分析，也常用于比较多个候选方案。它不强调效用树，流程相对轻，容易被开发和非技术角色理解。

ATAM：从"支持不支持"走到"代价是什么"

Architecture Tradeoff Analysis Method，2001 年由 Kazman、Klein 等人在 SAAM 基础上发展而来，是当前工程实践和考试中的主流方法。

它要回答的问题变了。不再问"架构支不支持某个属性"，而是问"为了支持属性 A，会在多大程度上损害属性 B"。这是 ATAM 相对 SAAM 最本质的改进，效用树只是它顺手引入的工具。

四个阶段、九个步骤：

阶段一 表述与收集

1. 介绍 ATAM 的目的、流程与预期产出

1. 描述业务驱动因素：商业目标、约束、各利益相关者的诉求

1. 描述待评估的架构：组件、连接件、部署视图与关键设计决策

阶段二 分析与识别

1. 识别架构方法：梳理架构中使用的风格、模式与关键策略

1. 生成质量属性效用树：把高优先级场景整理成树并按重要度、难度标注

1. 分析架构方法：把高优先级场景映射到架构决策，识别四类点

阶段三 场景挑战

1. 头脑风暴并排序场景：扩大参与范围，补充架构团队没想到的场景

1. 再次分析架构方法：用新增的高优先级场景重跑分析

阶段四 结果呈现

1. 汇总风险、非风险、敏感点、权衡点，形成风险主题与改进建议

第 4 步和第 6 步决定评估质量。架构方法清单如果漏了，后面所有分析都建在不完整的地基上。有团队在第一次评估时只识别出 5 种架构方法，到第 8 步补充到 11 种，第 6 步的结论几乎全部推翻重来。

四类输出

三者之间有两层关系需要理清。权衡点一定是敏感点，因为它是多个质量属性的敏感点；敏感点不一定升级成权衡点，只影响一个属性的决策就够了。非风险点有边界，它只说明针对当前已分析的场景没有暴露风险，不等于这项决策永远安全，也不等于未来条件变化后仍然成立。

CBAM：在质量分析之后算经济账

Cost Benefit Analysis Method 依赖 ATAM 的产出，ATAM 找风险，CBAM 算代价。它把场景一路收敛，让利益相关者的时间集中在回报最高的部分：

1. 整理场景：汇总 ATAM 阶段的场景并允许补充，按业务目标排序后取前三分之一

1. 细化场景：针对刺激与响应度量，给出最差、当前、期望、最佳四档响应水平

1. 排序场景：给每位利益相关者 100 票自由分配，汇总后取前 50%，最高票场景权重记为 1.0，其余按比例折算

1. 分配效用：为每档质量属性响应水平确定效用值

1. 确定架构策略的预期收益与成本

1. 计算投资回报率并排序，给出决策建议

同样能提升可用性的两个方案，一个投入 20 万把停机时间减少 60%，另一个投入 80 万减少 70%，选哪个是 CBAM 回答的问题。它常与 ATAM 连着用：先用 ATAM 完成质量属性权衡，再用 CBAM 在预算约束下做取舍。

ARID：为做了一半的架构准备的评审

Architecture Reviews for Intermediate Designs，1997 年由 Clements 提出。它解决的是一类很现实的困境：微服务拆到一半、缓存策略还没定，外围模块根本没法用完整场景去评，但核心部分的设计已经成型，想提前发现问题怎么办。

ARID 的两点不同值得记牢。第一，评估对象是架构片段，不是完整架构。第二，场景由评估团队主动设计，而不是等利益相关者头脑风暴——因为半成品架构的使用者往往还没法提出完整场景。

它的关注点落在可复用性和组件接口设计的合理性上，目标是设计中途提前发现缺陷，避免错误被后续模块放大。

五、五种方法横向对比

选型可以记成四句话：场景改架构看 SAAM，属性做权衡看 ATAM，继续算经济账看 CBAM，架构只做了一半看 ARID。

六、最近三年，评估这件事变了什么

方法的主体框架十几年没大动，但评估的输入、对象和关注点都在变。

质量属性的清单更新了

ISO/IEC 25010 在 2023 年 11 月发布第二版，替代了用了十二年的 2011 版。这次修订对效用树的第二层影响直接：

• 新增 safety 作为顶层质量特性，下面细分出 operational constraint、risk identification、fail safe、hazard warning、safe integration

• usability 更名为 interaction capability，portability 更名为 flexibility

• interaction capability、security、flexibility 分别新增 inclusivity、self-descriptiveness、resistance、scalability 等子特性

• user interface aesthetics 与 maturity 分别更名为 user engagement 与 faultlessness

• accessibility 拆成 inclusivity 与 user assistance

含义很实际：沿用 2011 版清单画效用树，会把安全性和包容性这类诉求漏在外层。新版本还把适用对象从软件产品扩展到各类 ICT 产品与信息系统，云服务、边缘设备一并纳入。

架构描述有了更明确的合格线

ISO/IEC/IEEE 42010 第二版于 2022 年 11 月发布，把架构描述拆成利益相关者、关注点、视角、视图、架构决策与决策理由这一组概念，并要求视图之间存在一致性对应规则。相比早前的版本，2022 版强化了决策理由的记录、模型验证以及架构权衡分析的要求。

这条对评估的直接影响是：评估的输入质量第一次有了标准可依。架构描述如果不写决策理由，评估人员就只能猜设计意图，敏感点和权衡点也就无从谈起。

评估对象的重心转移了

CNCF 与 SlashData 在 2025 年 11 月发布的云原生开发现状报告给出了一组规模数据：全球云原生开发者达到 1560 万，77% 的后端开发者至少使用一项云原生技术，API 网关与微服务的采用率分别为 50% 和 46%，混合云升至 32%，多云为 26%。

数字背后是评估场景在换位置。单体时代最关心的是模块耦合和部署窗口，现在更常出现在清单上的是服务边界划分是否合理、分布式事务如何保证一致性、链路追踪能否覆盖全部调用、单点依赖藏在哪里。可用性场景的度量也从"系统宕机多久恢复"细化到"某个服务的实例故障后，流量多久完成转移"。

评估在变轻

两到三天走完 ATAM 九步，对很多迭代节奏以周计的团队来说成本偏高。轻量化做法因此流行：保留效用树和四类点的核心逻辑，把完整九步压缩成半天到一天的场景工作坊，把头脑风暴与排序环节合并，用在线投票代替现场会议。评估也从一次性活动变成随迭代周期反复进行的例行检查。

AI 能帮上什么，帮不上什么

用大模型把零散的需求文档整理成结构化场景、补全缺失的要素、生成候选场景清单，是目前比较务实的用法。它省下的是整理和归纳的时间。

但有几条界限需要守住：模型给出的场景排序不能替代利益相关者的投票，因为优先级本质上是业务取舍；模型识别出的"风险"必须回到具体场景和架构决策上验证，否则只是措辞猜测；压力测试、故障演练和安全测试仍然只能真做。评估的价值在于发现需要验证的地方，不在于宣称已经验证过。

七、几道例题

例题一：判断质量属性

某市拟建"城市充电桩预约与结算平台"，需求方在评审前提交了下面一组要求，请指出每条对应的质量属性，并说明判断依据。

（a）用车高峰期，用户提交预约请求后，系统应在 1.5 秒内返回可用桩位列表。 （b）充电桩与平台的通信链路中断后，系统应在 30 秒内切换到备用通道，切换期间已开始的计费不中断。 （c）接入一家新运营商的工作量不超过 5 人日，且不修改既有结算模块。 （d）所有计费与退款操作需留有不可篡改的操作日志，可按用户和时间检索，供事后审计。 （e）平台需提供桩位状态与计费结果的查询接口，供测试团队编写自动化用例，接口覆盖率不低于 85%。 （f）新用户从打开小程序到完成首次预约，操作步骤不超过 4 步，并支持大字模式。 （g）用户名以字母开头，由数字和字母组成，长度不少于 6 位。

参考答案

（a）性能。刺激是提交预约请求，度量是响应时间 1.5 秒，属于典型的延迟指标。 （b）可用性。刺激是链路中断这一故障事件，响应是切换通道并保持计费连续，度量是 30 秒内完成。 （c）可修改性。度量单位是人日和工作影响范围，衡量的是变更成本，不是功能本身。 （d）安全性。关注的是操作的不可抵赖与可审计，属于安全属性中的审计与完整性要求。 （e）可测试性。要求系统暴露可观测的内部状态与接口，方便构建测试用例，度量是接口覆盖率。 （f）易用性。评价对象是使用者完成任务的难易程度，度量是操作步数与无障碍支持。 （g）设计约束。它规定的是形式规则，没有响应行为和度量指标，不属于质量属性，这一点在效用树里不应该出现在叶子节点上。

例题二：补全六要素

请用质量属性场景的六个要素描述上述要求（b）。

参考答案

例题三：识别四类点

平台当前的架构决策是：使用 Redis 缓存热点桩位数据；所有应用实例共用同一套 Redis 主节点且未配置高可用；为满足合规要求，对桩位与计费数据全程启用国密算法加密；应用实例多副本部署，配合健康检查，故障演练显示 30 秒内可完成流量转移。

请各指出一处敏感点、权衡点和风险点，并说明理由。

参考答案

敏感点：热点桩位数据的缓存过期时间设置。它直接决定数据库的读压力与预约请求的响应时间，参数一动，性能结果就明显变化。

权衡点：全链路启用国密算法加密。这条决策同时作用于安全性和性能：安全性上升，加解密带来的计算开销让响应时间变长，属于两个质量属性之间的取舍，符合权衡点的"同时影响多个属性"。

风险点：所有应用实例共用单套无高可用的 Redis 主节点。Redis 一旦故障，全部实例无法读取热点数据，预约服务整体不可用，直接冲击"链路中断后 30 秒内恢复"的可用性目标。注意这里的关键不是"Redis 有风险"这种笼统表述，而是它可能让某个具体场景失败。

补充一点：多副本加健康检查、30 秒内完成流量转移这条，经故障演练验证后可以作为非风险点，但它只针对当前已验证的场景成立。

例题四：选方法

八、答题与落地的通用骨架

案例题问"请采用 ATAM 评估该系统的架构"，可以按下面的顺序组织：

先收集业务目标、质量属性需求、利益相关者关注点和架构描述，把质量要求细化成可度量的场景，建立效用树并按重要度与难度排序。然后把高优先级场景映射到架构风格、构件、接口和关键决策上，分析系统在刺激下的响应是否达到度量目标，识别敏感点、权衡点、风险和非风险，并归纳风险主题。最后汇总结果，提出改进措施，并说明用压力测试、故障演练或安全测试来验证。

分析具体问题时用这个句式：针对【质量属性场景】，分析【架构决策】。由于【原因】，该决策会导致【质量属性后果】，因此属于【敏感点/权衡点/风险/非风险】。建议采用【改进措施】，并通过【度量或测试】验证。

把例题三的第一条填进去：针对链路中断后 30 秒内恢复的可用性场景，分析所有应用实例共用单套无高可用 Redis 的架构决策。由于 Redis 故障会使全部实例无法读取热点数据，该决策可能使服务连续性目标失败，因此属于可用性风险。建议为 Redis 配置高可用与故障转移机制，并通过故障注入验证恢复时间是否不超过 30 秒。

四条需要记住的边界

敏感点不等于风险。连接池大小对性能很敏感，但只有它可能让场景失败时才构成风险。

权衡点不等于缺陷。权衡点说明必须取舍，架构师能说明选择理由、控制副作用并完成验证，它就不是错误。

非风险不等于永久正确。它只针对当前场景和已知条件，业务规模、部署环境或质量目标一变，需要重新评估。

ATAM 不等于性能测试。它能发现需要验证的性能风险和敏感参数，替代不了真实的压力测试。

评估报告如果不转化成架构修改和验证任务，就只是纸面成果。