质量属性场景是什么
质量属性场景把非功能需求写成可测试的六要素描述：刺激源、刺激、环境、制品、响应与响应度量。它解决的是“系统要快、要稳”这类表述无法验收的问题：把谁在什么条件下做了什么、系统应有什么反应、用哪个指标判定，一次性说清。它也是架构评估（如 ATAM）中逐条讨论与验证质量属性的通用语言。
示例
示例
刺激源：正常营业时间的用户客户端
刺激：发起订单查询请求
环境：峰值负载，系统正常运行
制品：订单查询服务
响应：返回查询结果并记录访问日志
响应度量：p95 延迟不超过 500 毫秒，错误率低于 0.1%基本信息
| 六要素 | 刺激源、刺激、环境、制品、响应、响应度量 |
|---|---|
| 两种形态 | 一般场景（该属性整体要求）与具体场景（可测试的单点） |
| 用途 | 把口号转成可验证的验收指标，作为架构评审输入 |
| 变体 | 故障场景把刺激换成断电、网络分区、依赖超时等异常事件 |
| 记录位置 | 非功能需求清单、架构决策记录、压测计划 |
常用场景模板
| 属性 | 刺激示例 | 响应度量示例 |
|---|---|---|
| 性能 | 峰值时段并发查询 | p95 延迟、每秒查询数上限 |
| 可用性 | 单个可用区故障 | 服务中断时长、降级后可用率 |
| 安全性 | 未授权用户尝试访问他人数据 | 拒绝比例、审计记录完整性 |
| 可修改性 | 新增一个支付渠道 | 涉及模块数、所需人日 |
| 可测试性 | 新增一条业务规则 | 回归验证耗时、用例覆盖比例 |
| 易用性 | 新用户首次完成下单 | 完成耗时、操作出错次数 |
典型使用场景
- 非功能需求澄清：把模糊目标改写成可测试场景
- 架构评估：逐条讨论场景，判断当前设计能否支撑
- 压测计划制定：场景直接转成压测用例与通过判据
- 验收对照：上线前逐条核对响应度量是否被监控覆盖
- 故障演练设计：用故障型场景设计演练脚本与恢复目标
- 方案对比：用同一组场景比较不同技术方案的满足程度
场景的响应度量必须可观测：如果指标无法从监控或压测中直接读出，场景就只是文字描述，无法作为验收依据。
只写一般场景（“系统应高性能”）而不落到具体场景，评审时仍然无法判断设计是否达标。