核心目标：验证系统在预期流量、并发、数据量下，响应时间、吞吐量、稳定性、资源占用满足业务指标；提前发现瓶颈、内存泄漏、死锁、数据库慢 SQL 等问题，避免上线雪崩。
1. 测试准备阶段
1.1 明确性能需求 & 制定指标（性能基线 SLA）
和产品、开发、运维对齐业务场景，定义指标，区分业务指标和资源指标
业务：并发用户数、TPS/QPS、95/99 响应时间、成功率、事务响应时间
资源：CPU、内存、磁盘 IO、网络、连接数、GC 指标
场景：日常峰值、大促峰值、梯度压测、长时间稳定性压测
示例：接口 95 响应 < 200ms，TPS≥1000，成功率 100%，CPU≤70%
同时识别核心链路：登录、下单、查询、支付等关键业务接口，区分冷热数据。
1.2 环境准备
性能压测环境尽量生产等配置（硬件、中间件版本、数据库数据量），禁止直接压生产。
隔离压测环境，避免影响其他测试；
数据库准备生产量级的基础数据（千万级表不能拿几百条数据压，结果失真）；
部署监控套件：服务器监控、数据库监控、JVM / 进程监控、链路追踪（SkyWalking/Pinpoint）；
压测工具准备：JMeter、Locust、Gatling、k6；压测机单独部署，避免压测机本身成为瓶颈。
1.3 脚本 & 数据准备
录制 / 编写压测脚本，参数化：账号、查询 ID、请求体，避免重复请求缓存导致压测结果虚高
构造压测数据：
业务参数做数据池，避免重复 ID；
准备预热脚本，压测前预热缓存、连接池；
脚本评审：检查是否有思考时间、是否漏前置依赖（如登录 token），是否有脏数据清理逻辑。
1.4 制定压测方案
明确压测类型、压测顺序、停机 / 回滚预案、脏数据清理方案：
基准测试
梯度并发压测（负载测试）
稳定性测试（耐久压测）
极限压力测试（容量测试）
异常场景压测（熔断、限流、降级）
2. 执行压测阶段（按顺序执行）
2.1 基准测试（单用户轻量）
少量并发（1~5 用户）跑核心接口，得到基准响应时间。 目的：验证脚本可用、链路通、监控正常；识别基础慢 SQL、接口逻辑问题。
2.2 负载测试（梯度加压，最常用）
逐步增加并发，阶梯加压：比如 50→100→200→500 用户，每级稳定运行一段时间。 重点观察：
TPS 上升趋势，什么时候 TPS 不再上涨（拐点）
响应时间随并发的变化
服务器资源、数据库连接池、锁等待
找到拐点：继续增加并发，TPS 不升、响应时间陡增，这就是系统当前容量上限。
2.3 稳定性 / 耐久测试
在日常峰值并发下长时间跑（通常几小时～24h）。 重点查：内存泄漏、连接不释放、GC 长时间 STW、数据库事务堆积、磁盘空间持续上涨。很多问题短压测发现不了。
2.4 压力 / 容量极限测试
超过预期峰值，持续加压，找到系统崩溃点。 目的：了解系统极限，验证限流熔断是否生效；当流量突增时，系统是优雅降级还是直接宕机。
2.5 异常场景压测（容错测试）
模拟线上故障：
数据库慢查询、连接打满
下游接口超时、抖动
网络延迟、丢包 验证：熔断、降级、限流、重试策略是否生效，防止雪崩。
压测全程：同步记录监控指标 + 日志，压测不看监控等于白测。
3. 瓶颈定位与调优阶段（性能测试最核心环节）
压测出现指标不达标，按链路逐层排查：
应用层：接口代码、循环查询、对象创建过多、GC、线程池配置不合理
中间件：Redis 慢命令、MQ 堆积、连接池过小
数据库：慢 SQL、缺少索引、锁竞争、事务过长、分库分表瓶颈
基础设施：CPU 瓶颈、磁盘 IO、带宽、容器资源限制
调优原则：改一处，重新跑基准验证，不要一次性大量修改。每次调优后复测，对比前后指标，确认优化有效。
4. 回归验证 & 报告输出
调优完成后，完整重跑全套压测用例，确认所有 SLA 指标达标；
输出性能测试报告：
测试环境、版本、压测场景
基准 / 负载 / 稳定性压测图表（TPS、响应时间、资源曲线）
发现的瓶颈、优化措施、优化前后对比
遗留风险、容量评估、上线建议
组织评审：开发、运维、产品共同确认，评估风险是否可接受。
5. 上线前最后准备（性能测试收尾）
确认压测环境和生产差异，评估环境差异带来的风险；
配置线上限流、熔断告警；
准备线上小流量灰度验证方案（上线后灰度放量，持续观测线上真实性能指标）；
制定扩容预案、回滚方案。
常见踩坑点
压测环境数据量远小于生产，压测结果虚高；
脚本没有参数化，大量重复请求命中缓存，指标失真；
只做短时间压测，不做耐久测试，上线后内存泄漏慢慢拖垮系统；
只关注 TPS，忽略 99 响应时间；
压测时不开启全链路监控，出问题无法定位瓶颈。