性能测试项目实战¶
概述
本实战以电商系统的商品查询和创建订单接口为对象，训练从性能目标确认、场景设计、JMeter 脚本编写、执行压测到结果分析的完整流程。
新手导读¶
| 项目 | 说明 |
|---|---|
| 适合人群 | 已会基础接口测试，想学习 JMeter 压测和结果分析的新手 |
| 前置知识 | HTTP 请求、状态码、JMeter 基本组件、服务器基础指标 |
| 最终产出 | 压测目标、JMeter 脚本、测试数据、HTML 报告、性能结论 |
| 跟练方式 | 先 10 并发跑通单接口，再做阶梯加压和混合场景 |
| 常见卡点 | 只看平均响应时间；不加断言；测试数据不足；压测环境和生产环境混用 |
性能测试的重点不是把线程数调大，而是能解释“什么时候开始慢、慢在哪里、证据是什么”。每次压测都要保留报告、监控截图和结论。
一、项目目标¶
性能测试不是简单“开很多线程跑一下”。本项目目标是通过可控压测回答三个问题：
- 当前系统在目标并发下是否稳定。
- 核心接口的响应时间、吞吐量和错误率是否满足要求。
- 如果不满足，瓶颈可能在哪里。
核心目标¶
| 目标 | 说明 |
|---|---|
| 明确指标 | 定义响应时间、TPS、错误率、资源使用率 |
| 设计场景 | 区分单接口压测、混合场景、阶梯加压和稳定性测试 |
| 准备数据 | 避免测试数据不足导致结果失真 |
| 执行压测 | 使用 JMeter 命令行执行并生成报告 |
| 分析结果 | 结合服务器监控、日志和数据库指标定位瓶颈 |
二、新手先搞懂几个词¶
| 词 | 通俗解释 | 例子 |
|---|---|---|
| 并发用户 | 同一时间一起请求系统的人数 | 100 个用户同时查商品 |
| 响应时间 | 从发出请求到收到结果的耗时 | 查询商品用了 300ms |
| TPS | 每秒完成多少个业务请求 | 每秒创建 50 个订单 |
| 错误率 | 请求失败的比例 | 1000 个请求里 5 个失败，错误率 0.5% |
| P95 | 95% 的请求都小于这个耗时 | P95 为 800ms，说明大多数请求在 800ms 内完成 |
| 瓶颈 | 限制系统继续变快的地方 | CPU、数据库、网络、代码逻辑 |
新手最容易犯的错是只看平均响应时间。平均值可能掩盖慢请求，所以要同时看 P95、错误率和 TPS。
三、第一次性能测试怎么做¶
第一次不要压太大，先做一个小规模基准测试：
- 选择一个稳定接口，例如商品列表查询。
- 准备 10 到 20 个商品关键词。
- 设置 10 个并发用户。
- 持续运行 3 到 5 分钟。
- 观察响应时间、TPS 和错误率。
- 保存 JMeter 报告。
- 写出一句测试结论。
示例结论：
这个结论虽然简单，但比“性能正常”清楚得多。
四、性能测试范围¶
第一阶段建议选择核心、稳定、可重复的接口：
| 模块 | 接口 | 场景 | 优先级 |
|---|---|---|---|
| 商品 | /api/products |
商品列表查询 | P0 |
| 商品 | /api/products/{id} |
商品详情查询 | P0 |
| 登录 | /api/login |
用户登录 | P1 |
| 订单 | /api/orders |
创建订单 | P0 |
| 订单 | /api/orders/{id} |
查询订单 | P1 |
暂不建议第一版压测真实支付回调、第三方服务和频繁变更的活动接口。依赖外部系统的接口需要先确认是否有沙箱或 Mock 环境。
五、性能指标¶
常用指标如下：
| 指标 | 说明 | 示例目标 |
|---|---|---|
| 平均响应时间 | 所有请求的平均耗时 | 小于 500ms |
| P95 响应时间 | 95% 请求低于该耗时 | 小于 1000ms |
| TPS | 每秒处理事务数 | 大于 200 |
| 错误率 | 失败请求占比 | 小于 0.1% |
| CPU 使用率 | 应用服务器 CPU | 稳定低于 80% |
| 内存使用率 | 应用服务器内存 | 无持续上涨 |
| 数据库慢查询 | SQL 执行耗时 | 无核心慢查询 |
指标应来自业务目标和历史基线，不要凭感觉随意设定。
六、压测场景设计¶
6.1 单接口基准测试¶
目标：了解单个接口在低并发下的基础性能。
| 参数 | 示例 |
|---|---|
| 并发用户 | 10 |
| 持续时间 | 5 分钟 |
| 场景 | 商品列表查询 |
| 关注点 | 平均响应时间、P95、错误率 |
6.2 阶梯加压测试¶
目标：观察系统容量变化和拐点。
| 阶段 | 并发 | 持续时间 |
|---|---|---|
| 阶段 1 | 20 | 5 分钟 |
| 阶段 2 | 50 | 5 分钟 |
| 阶段 3 | 100 | 5 分钟 |
| 阶段 4 | 200 | 5 分钟 |
如果某个阶段开始错误率上升或响应时间急剧变长，就需要结合监控定位瓶颈。
6.3 混合业务场景¶
目标：模拟更接近真实用户的行为。
| 操作 | 占比 |
|---|---|
| 商品列表查询 | 50% |
| 商品详情查询 | 30% |
| 登录 | 10% |
| 创建订单 | 10% |
混合场景要注意测试数据隔离，创建订单会改变库存和订单数据，执行前需要准备足够库存。
七、JMeter 脚本设计¶
7.1 测试计划结构¶
测试计划
├── 线程组：商品查询场景
│ ├── HTTP Header Manager
│ ├── HTTP Request Defaults
│ ├── CSV Data Set Config
│ ├── 商品列表请求
│ ├── 商品详情请求
│ └── 断言
├── 线程组：订单场景
│ ├── 登录请求
│ ├── JSON Extractor 提取 Token
│ ├── 创建订单请求
│ └── 数据库或响应断言
└── 监听器
7.2 参数化数据¶
示例 products.csv：
JMeter 中使用：
7.3 断言策略¶
性能测试也需要断言，避免系统返回错误页面却被统计为成功。
建议断言：
- HTTP 状态码为 200。
- 业务 code 为 0。
- 响应中包含关键字段。
- 创建订单返回订单号。
八、JMeter 新手操作步骤¶
如果你第一次使用 JMeter，可以这样做：
- 新建 Test Plan。
- 添加 Thread Group。
- 在线程组里添加 HTTP Request。
- 填写协议、服务器地址、路径和请求方法。
- 添加 Response Assertion，检查响应中包含业务成功标识。
- 添加 Summary Report 或 View Results Tree 用于调试。
- 小并发调试通过后，保存为
.jmx文件。 - 正式压测时用命令行运行。
调试阶段可以使用 View Results Tree，正式压测不要开太多图形监听器，否则 JMeter 本身会消耗大量资源，影响结果。
九、测试数据准备¶
性能测试前需要准备足够数据：
| 数据 | 要求 |
|---|---|
| 用户账号 | 足够并发使用，避免同一账号互相影响 |
| 商品数据 | 商品数量充足，覆盖不同分类和价格 |
| 库存数据 | 创建订单场景必须保证库存足够 |
| 订单数据 | 查询订单场景需要提前准备订单 |
如果所有线程共用一个账号或一个商品，可能测到的是锁冲突、库存竞争或缓存热点，不一定代表真实性能。
十、执行策略¶
本地调试时可以用图形界面，正式压测建议使用命令行：
执行前确认：
- 压测环境和生产环境隔离。
- 压测时间已通知相关团队。
- 监控已开启。
- 测试数据可恢复。
- 日志级别不会产生过多磁盘写入。
十一、结果分析¶
分析时不要只看平均响应时间，应重点看：
| 指标 | 说明 |
|---|---|
| P90 / P95 / P99 | 反映大部分用户体验和长尾问题 |
| TPS 曲线 | 判断吞吐量是否随并发增长 |
| 错误率曲线 | 判断系统从哪个阶段开始不稳定 |
| 响应时间曲线 | 判断是否出现明显拐点 |
| CPU / 内存 / IO | 判断资源瓶颈 |
| 数据库慢查询 | 判断 SQL 或索引问题 |
典型判断：
- 并发上升但 TPS 不涨，可能到达瓶颈。
- CPU 很高，可能是计算密集、线程竞争或代码热点。
- 数据库 CPU 或慢查询高，可能是 SQL 或索引问题。
- 内存持续上涨，可能存在内存泄漏或缓存失控。
十二、结果怎么看：新手判断模板¶
拿到结果后，可以按下面顺序判断：
第一步：错误率是否超过目标？
是：先看错误响应和服务日志。
否：继续看响应时间。
第二步：P95 是否超过目标？
是：说明有较多用户会感觉慢。
否：继续看 TPS。
第三步：并发增加时 TPS 是否继续上升？
不上升：可能到达系统瓶颈。
上升：说明系统还有容量。
第四步：服务器资源是否异常？
CPU、内存、数据库、磁盘、网络逐项看。
不要只给出数字，要把数字翻译成结论。
十三、瓶颈定位¶
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 响应时间持续升高 | 应用线程不足、数据库慢查询 | 应用日志、线程池、慢 SQL |
| 错误率突然上升 | 连接池耗尽、限流、超时 | 网关日志、连接池配置 |
| CPU 打满 | 代码热点、序列化、加密计算 | CPU 监控、火焰图 |
| 数据库负载高 | 索引缺失、SQL 扫描大表 | 慢查询日志、执行计划 |
| 磁盘 IO 高 | 日志过多、报表写入 | 磁盘监控、日志级别 |
性能测试报告里不要只写“系统性能较差”，要写清楚问题发生在什么并发、什么接口、什么指标、有什么证据。
十四、测试报告¶
14.1 报告结构¶
14.2 结论示例¶
在 100 并发混合场景下，系统 TPS 稳定在 230 左右，P95 响应时间为 860ms，错误率为 0.03%，满足本轮性能目标。
在 200 并发时，创建订单接口 P95 响应时间升至 2400ms，错误率达到 1.8%。同时数据库慢查询日志显示 order_items 表存在全表扫描，建议优化索引后重新压测。
十五、练习任务¶
请完成一次小型压测练习：
- 选择商品列表接口。
- 设置 10 并发，持续 3 分钟。
- 添加状态码和业务 code 断言。
- 导出 JMeter HTML 报告。
- 记录平均响应时间、P95、TPS、错误率。
- 写一段不少于 150 字的测试结论。
完成标准：
- 报告中能看到响应时间、吞吐量和错误率。
- 结论中说明是否满足目标。
- 如果不满足，能写出下一步排查方向。
十六、风险与优化建议¶
常见建议：
- 商品查询接口增加合理缓存。
- 慢 SQL 补充索引或改写查询。
- 创建订单接口增加幂等控制。
- 调整应用线程池和数据库连接池。
- 将压测数据与普通测试数据隔离。
- 建立性能基线，后续版本持续对比。
性能测试的价值不在于跑出一个漂亮数字，而在于提前发现系统容量边界和上线风险。