性能需求要写成什么
性能需求不是形容词，而是一组可测量的数字加测量条件。最少要同时给出三要素：响应时间（按分位表达）、吞吐量（峰值与日常口径）、容量边界（数据规模、并发用户、增长预期）。缺任何一项都无法验证，也无法据此设计压测场景或容量模型——只写“要快”，验收时只能各说各话。
基本信息
| 响应时间 | 按分位表达，如 P95 小于 300ms、P99 小于 800ms，并标注测量点位置 |
|---|---|
| 吞吐 | 区分峰值与日常口径，标注统计时间窗口与是否含重试 |
| 容量边界 | 数据规模、并发连接数、增长预期与数据分布特征 |
| 附属条件 | 环境规格、预热状态、依赖是否为本地或真实链路 |
典型使用场景
- 需求评审：把模糊的体验要求转成可验收的数值，作为设计与评审依据
- 压测设计：压测脚本直接按三要素生成场景与放量曲线
- 容量规划：用吞吐与容量边界推导实例数、连接数与存储规模
- SLO 定义：把关键接口的响应时间分位与错误率写进服务目标
- 变更评估：新增依赖或功能时对照预算，判断是否已超支
可测需求写法示例
可测需求写法示例
弱：搜索要快
强：在 500 万商品数据、100 并发查询条件下，
搜索接口 P95 ≤ 300ms、P99 ≤ 800ms，
峰值吞吐 ≥ 300 QPS，错误率 < 0.1%
弱：系统要能扩容
强：订单量增至 3 倍时，扩容可在 2 小时内完成，
且成本增幅符合预算口径三要素核查表
| 要素 | 合格写法 | 常见缺失 |
|---|---|---|
| 响应时间 | 分位 + 数值 + 测量点 | 只写平均值，长尾被掩盖 |
| 吞吐 | 数值 + 时间窗口 + 峰值或日常 | 不写口径，数据无法复现 |
| 容量边界 | 数据规模 + 并发 + 增长预期 | 不提数据量，压测条件不可比 |
| 测量条件 | 环境、预热、依赖真实性 | 压测机与生产配置差异大 |
落地做法
- 三要素齐备后再评审：响应时间（分位）、吞吐（峰值与日常）、容量边界（数据规模与并发）
- 标注测量条件：数据量、并发数、环境规格、预热状态与依赖是否真实
- 需求评审输出压测验收清单，指标名与监控看板保持同名，避免口径漂移
- 对每条需求标注不可达时的处理方式：降级、排队还是明确拒绝
需求评审时把三要素写成可测句子，压测脚本就能据此生成验收条件；反过来，如果一句话写不出可执行的压测脚本，说明需求还没写清楚。
压测环境与生产配置差异（CPU 型号、网络、数据规模、依赖真假）会让验收数字失去意义，报告里必须写明环境差异与换算依据。