压测方案设计方法

一、为什么压测前一定要先做方案

很多压测失败，不是工具不会用，而是压测前根本没有方案。

常见问题有：

不知道压哪些接口
不知道目标 QPS 是多少
不知道结果算不算达标
出现异常后没人能解释

所以：

压测方案的作用，是把“为什么测、测什么、怎么测、怎么判断结果”提前说清楚。

二、一份压测方案至少要回答什么问题

对 Java 后端团队来说，一份合格的压测方案至少要回答以下 5 个问题：

本次压测目标是什么
压测对象是什么
压测场景怎么设计
压测指标怎么验收
风险和前提条件是什么

如果这 5 个问题没说清楚，压测就很容易变成“随便跑一跑”。

三、先定义压测目标

压测目标不能写成：

测试一下系统性能

这太空了。

更合理的写法应该是：

验证订单系统在 2000 QPS 下是否稳定
验证大促场景下下单流程 P95 是否小于 300ms
验证核心链路在 2 小时持续压测下错误率是否低于 0.1%

目标一定要：

明确
可量化
可验证

四、明确压测范围

压测范围要先圈定，不然很容易越测越乱。

可以从三个维度定义：

1. 业务范围

例如：

登录
商品浏览
下单
支付

2. 系统范围

例如：

用户服务
商品服务
订单服务
Redis
MySQL

3. 环境范围

例如：

测试环境
预发环境
压测专用环境

五、设计压测场景

场景设计是方案的核心。

常见做法是先拆业务，再给流量比例。

例如电商系统：

浏览商品 70%
加入购物车 20%
下单 8%
支付 2%

然后再决定每个场景的：

并发数
持续时间
请求路径
是否需要关联

六、定义验收指标

没有验收标准，压测结果就没有结论。

推荐至少定义以下指标：

平均响应时间
P95 / P99
错误率
目标 QPS / TPS
CPU / 内存使用率

例如：

订单接口 P95 < 300ms
错误率 < 0.1%
系统稳定支撑 2000 QPS
CPU < 80%

七、准备前置条件

压测方案里还要写清楚前置条件。

例如：

测试账号是否足够
商品库存是否足够
数据库是否已初始化
Redis 是否清空缓存
监控是否已开启

这些内容经常被忽略，但它们决定压测能不能顺利进行。

八、风险识别

压测不是零风险活动，方案里要提前写出风险点。

常见风险包括：

压测数据污染环境
打挂共享数据库
影响其他测试团队
磁盘日志被写满
调用了真实第三方接口

因此方案里要说明：

哪些依赖是真实调用
哪些依赖要 mock
出问题如何回滚

九、一个简化的压测方案模板

你可以先用这个最小模板：

1. 背景

为验证大促前订单系统容量，计划对下单主链路进行压测

2. 目标

在 2000 QPS 下保持 P95 < 300ms，错误率 < 0.1%

3. 范围

登录、商品查询、下单、支付

4. 场景

浏览 70%
加购 20%
下单 8%
支付 2%

5. 指标

QPS、P95、P99、错误率、CPU、内存、DB连接数

6. 风险

库存可能被打空，需要提前准备隔离商品数据

十、Java 后端团队的推荐做法

如果你是 Java 后端开发，建议方案尽量写得工程化一点：

明确到接口和链路
明确到监控项
明确到达标门槛
明确到谁负责分析

这样压测结束后，大家不是争论“测没测好”，而是直接看方案里的标准。

十一、总结

压测方案不是文档负担，而是压测成功的前提。

一份好的压测方案，至少能做到：

目标清晰
范围明确
场景真实
指标可验收
风险可控

对后端工程师来说，压测方案的核心不是写得多漂亮，而是能不能真正指导执行。