2. 特征清单概念:什么是压力测试特征清单
压力测试特征清单是一份结构化的测试资产,它把“系统在高压下会表现出哪些行为”这个模糊问题,拆解为可观测、可度量、可复现的指标、阈值与场景三元组。它不是测试用例的简单罗列,而是对系统压力行为的形式化描述——告诉团队:测什么、测到什么程度算通过、在什么条件下测。
2.1 清单的核心作用
特征清单在压力测试全生命周期中扮演三个关键角色:
| 作用维度 | 具体说明 | 典型产出 |
|---|---|---|
| 对齐 | 将业务方、开发、运维对“系统能扛多少压力”的模糊期望,转化为精确数字 | SLA 指标表、性能验收标准 |
| 可复现 | 同一份清单在不同环境(测试/预发/生产)执行,结果可比 | 场景参数模板、环境基线 |
| 可追溯 | 每次压测结果都能关联到具体特征条目,快速定位退化点 | 特征-结果映射表、回归报告 |
实践要点: 特征清单不是一次性产物。每次系统架构变更、依赖升级或容量规划调整后,都应重新审视并更新清单中的阈值与场景。
2.2 清单的组成要素
一份完整的压力测试特征清单由三个核心要素构成,缺一不可:指标(测什么)、阈值(测到什么程度)、场景(在什么条件下测)。
2.2.1 指标(Metrics)
指标是系统在压力下的可量化观测值。按观测层次可分为三类:
- 业务指标:直接反映用户体验,如响应时间(RT)、吞吐量(TPS/QPS)、错误率、成功率。
- 资源指标:反映基础设施承载状态,如 CPU 使用率、内存占用、磁盘 IO、网络带宽。
- 中间件指标:反映依赖组件健康度,如数据库连接池活跃数、消息队列堆积长度、缓存命中率。
选指标原则: 优先选择业务指标作为“通过/不通过”的判定依据,资源指标作为辅助诊断线索。不要试图监控所有指标——每个场景聚焦 3~5 个核心指标即可。
2.2.2 阈值(Thresholds)
阈值是判定测试是否通过的数字边界。好的阈值应满足 SMART 原则:
| SMART 维度 | 解释 | 反例 | 正例 |
|---|---|---|---|
| S 具体 | 指标名称和统计方式明确 | “响应时间不能太慢” | “P99 响应时间 ≤ 500ms” |
| M 可度量 | 有明确的采集工具和计算口径 | “系统要稳定” | “错误率 ≤ 0.1%(基于 5 分钟滑动窗口)” |
| A 可达成 | 阈值基于历史基线或容量规划设定 | “TPS 无限大” | “TPS ≥ 2000(基于当前集群 4 节点)” |
| R 相关 | 阈值与业务目标直接关联 | “CPU 不超过 50%” | “CPU ≤ 80% 且 P99 RT 达标” |
| T 有时限 | 阈值在指定持续时间内有效 | “压测 5 分钟” | “在 2000 TPS 持续 30 分钟内,P99 RT ≤ 500ms” |
2.2.3 场景(Scenarios)
场景定义了“如何施加压力”以及“系统处于何种状态”。每个场景应包含:
- 负载模型:并发用户数、Ramp-up 策略、持续时长、压力曲线(阶梯/脉冲/恒定)。
- 数据条件:测试数据量级、数据分布(热数据比例)、缓存预热状态。
- 系统状态:是否开启限流、降级、熔断;依赖服务是否模拟故障。
- 前置条件:是否需要先执行特定业务流程(如登录、下单)才能进入压测状态。
常见误区: 很多团队只写“1000 并发压测 30 分钟”,忽略了数据条件和系统状态。结果两次压测结果差异巨大,却找不到原因——因为一次缓存已预热,一次缓存是空的。
2.3 三要素关系图
下面这张 SVG 图展示了指标、阈值、场景三者之间的依赖与协作关系:
2.4 清单模板示例
以下是一个真实项目中使用的特征清单条目模板(以电商下单接口为例):
特征编号: PRS-ORDER-001
接口: POST /api/order/create
场景名称: 大促峰值下单压测
【指标】
- P99 响应时间 (RT)
- 吞吐量 (TPS)
- 错误率 (Error Rate)
- CPU 使用率 (CPU %)
【阈值】
- P99 RT ≤ 800ms(持续 15 分钟)
- TPS ≥ 1500(持续 15 分钟)
- 错误率 ≤ 0.5%(HTTP 5xx + 业务异常)
- CPU ≤ 85%(所有节点平均值)
【场景】
- 负载模型: 阶梯式加压,从 500 TPS 起步,每 3 分钟增加 200 TPS,目标 1500 TPS
- 数据条件: 商品库存 10 万,用户账号 5 万,缓存已预热(Redis 命中率 > 95%)
- 系统状态: 限流关闭,降级关闭,熔断阈值设为 2000 TPS
- 前置条件: 所有用户已登录,token 有效
- 持续时间: 达到目标 TPS 后持续 15 分钟
模板使用建议: 每个特征条目独立编号,方便与自动化压测脚本绑定。建议使用 YAML 或 JSON 格式存储清单,便于版本管理和 CI/CD 集成。
2.5 清单的层级结构
对于大型系统,特征清单通常按层级组织,从全局到局部逐层细化:
层级化组织的好处:系统级清单用于验收和汇报,服务级清单用于团队内部质量门禁,接口级清单直接绑定自动化压测脚本。每一层都包含完整的指标、阈值、场景三要素,只是粒度不同。
落地建议: 从接口级清单开始构建,积累 2~3 个核心接口的特征后,再向上聚合为服务级和系统级清单。不要一开始就试图覆盖所有接口——优先覆盖核心交易链路。