性能测试、负载测试、压力测试的区别与JMeter实战指南

很多人做了几年测试，甚至一些开发、运维同学，被问到“性能测试、负载测试、压力测试有什么区别”时，还是会愣一下。网上的解释也不少，但大多绕来绕去，要么过于理论化，要么直接说“负载测试就是压力测试”，看得人更迷糊。我自己刚入行那会儿也被这三个词坑过，后来在几个大促项目里反复折腾，才慢慢把它们的边界和实际用法摸清楚。

这篇文章不打算给你堆概念，而是从实际工作视角出发，把三者的定位、目标、场景设计、指标观测和工具配置一次性讲透。无论你是刚接触压测的新手，还是准备梳理团队测试体系的负责人，这篇文章都能给你一个可以直接落地的参考框架。尤其是后面会用JMeter做一组对比实验配置，看完你就可以照着在自己的项目里试。

1. 三者到底差在哪：先理清概念，别再被面试题绕晕

先把最核心的结论放在前面：性能测试是一个统称，负载测试和压力测试都是它的子集，但它们的测试目标和通过标准完全不同。很多人混淆三者，本质上是把“测试类型”和“测试目的”混为一谈了。

1.1 性能测试：以“是否符合预期”为唯一标准的验证活动

性能测试（Performance Testing）的核心目标是验证系统在特定负载条件下，各项性能指标是否满足预先设定的需求。它回答的问题是：“系统快不快？稳不稳？能不能达到我们承诺的指标？”

这里面有两个关键词：特定负载和预定指标。负载是事先定好的，比如“1000个用户同时在线操作”，指标也是预先定义好的，比如“平均响应时间小于500ms，错误率低于0.1%”。测试结束时，你不是去看系统还能扛多少，而是看系统在这个既定条件下是否达标。达标就通过，不达标就找出瓶颈去优化。

这里要特别强调一点：性能测试的“通过标准”不在测试人员手里，而在需求文档里。如果没人定义过“响应时间小于2秒”这类SLA（服务等级协议），那性能测试就没有意义，测出来的数字只是一堆无用的观测值，你没法判断好还是坏。所以做性能测试之前，第一件事永远是找产品、业务方对齐指标基线。

1.2 负载测试：用梯度加压找到系统的舒适区

负载测试（Load Testing）的核心目标是验证系统在逐渐增加的负载下，性能表现如何变化，并最终找到系统的拐点——也就是从哪个并发数开始，吞吐量不再增长、响应时间开始急剧恶化。它回答的问题是：“系统能撑到多少人？在什么负载下开始吃不消？”

我习惯把负载测试理解为“摸底考试”。不是一次压到死，而是逐步加压：100人、200人、400人、800人……每一步观察系统表现，记录各项指标。这样做的好处是你能清晰看到性能退化的过程——是平稳下滑还是有明显的断崖式下跌，这两种情况对应的排查方向完全不同。

负载测试的通过标准是自己定义的：比如设定“系统在500并发时，TPS不低于X，响应时间不高于Y”，然后在梯度加压的不同阶段去观察是否满足。它比性能测试更灵活，也更接近“探索性”测试。

1.3 压力测试：把系统逼到极限，看它怎么死

压力测试（Stress Testing）的核心目标是找到系统的极限承受能力，并验证系统在超负荷状态下是否还能正常运行、崩溃后能否快速恢复。它回答的问题是：“系统的天花板在哪里？超出极限后会怎样？”

压力测试的结果通常不是“通过”或“失败”，而是一份极限报告：最大支撑并发数、资源耗尽时的表现、系统是优雅降级还是直接宕机、恢复后能否正常服务。这部分内容在面试时经常被问到“你们做过压力测试吗”，很多人答不上来，其实就是没搞明白压力测试和负载测试的区别——负载测试问“什么时候开始不行”，压力测问问的是“彻底不行之后会怎样”。

还有一个容易忽略的点：压力测试不只是针对整个系统的，单机单组件的极限验证同样属于压力测试范畴，比如CPU压到100%、内存占用耗尽、文件句柄打满等。这类测试在容量评估和故障演练中非常常见。

1.4 生活化类比：一张桌子帮你记住全部

我们拿一张桌子来类比。假设这张桌子设计承重是50公斤。

• 性能测试：往桌上放50公斤的东西，检查桌面有没有变形、桌脚有没有晃动。符合预期就通过。
• 负载测试：从10公斤开始，每次加5公斤，观察桌子在20、30、40、50公斤时的状态变化，找到从正常到异常的那个临界重量。
• 压力测试：继续往上加，超过50公斤一直加到80公斤甚至100公斤，看它什么时候塌、塌了之后把东西挪走还能不能继续用。

这样再回头看网上的各种解释就不会乱了。性能测试是“验货”，负载测试是“摸底”，压力测试是“蹂躏”。三者目标不同、方法不同、结论也不同。

1.5 常见混淆点：可扩展性测试和容量测试是什么角色

除了这三个词，你大概率还听过可扩展性测试和容量测试，这里一并说清楚，省得以后看到术语表又懵。

• 容量测试：本质上是负载测试和性能测试的结合变体，核心目标是验证系统在达到某个特定数据规模或用户规模时，是否还能满足性能指标。比如“数据库里已有1亿条数据，1000并发查询时响应时间会不会超过3秒”，这是一个容量问题。它关注的是“数据的量”对性能的影响，而不只是“用户并发量”。
• 可扩展性测试：关注的是当系统资源（比如加服务器、加CPU核数）增加时，性能能否线性提升。比如从2台应用服务器扩展到4台，TPS能否翻倍。如果只提升30%，说明系统存在瓶颈，扩展性差。

这两个概念经常和负载测试绑在一起出现，但在实际项目里，它们的定位和观察指标有明确差异。了解这些差异，能帮你在设计整体测试方案时考虑得更全面，而不是只盯着“并发数调大、看会不会挂”这一件事。

2. 从目标到场景：三种测试的落地设计思路

搞清楚定义只是第一步，真正有价值的是知道在什么业务场景下该选择哪种测试方式，怎么把测试目标翻译成可执行的压测场景。这一章讲的是从目标推导场景的完整思考路径，用实际业务案例来展开。

2.1 先定指标，再定方式：目标不同，场景完全不同

在设计压测方案的时候，我会按这样一个顺序往下推：业务目标 → 性能指标 → 测试类型 → 场景参数 → 监控数据 → 分析方法。

举例说明。如果你的业务目标是“确保双11大促期间，核心下单接口在峰值流量下不崩、用户体验不下降”，那么性能指标可能是“2000并发下单时，成功率达到99.95%，99分位响应时间低于800ms”，对应的测试类型是性能测试和负载测试，因为你关注的核心是“达标”，而不是“打爆”。

如果业务目标变成了“摸清网关服务的极限承载，为后续扩容提供数据依据”，那对应的一定是压力测试，因为你需要把流量往上打，直到系统出现异常，从而拿到网关的极限水位。

同样的业务系统，不同的问题，对应完全不同的压测方案。我见过很多团队拿着一个固定的压测脚本反复跑，问他“这次测试的目标是什么”，答不上来——这就是典型的本末倒置。先有目标，再有脚本，脚本永远服务于目标。

2.2 场景参数怎么定：并发数、加压方式、持续时间

确定了测试类型之后，下一步是设计具体的场景参数。这里先说几个最容易踩坑的环节。

并发数怎么定？很多人直接拍脑袋写“5000并发”，看起来专业，实际没有依据。正确做法是根据业务数据的峰值推算，而不仅是看系统容量假设值。一个有效路径是：先统计生产环境的日常QPS或在线用户数，结合历史大促峰值的增长率，用公式推算出目标并发数。比如日常高峰期在线用户约2万人，预计大促翻3倍，那就是6万在线用户。但这些用户不会同时操作，真正同时点按钮、提交请求的一般占在线用户数的10%～20%，算下来压测目标大致就是6000到12000的并发操作量。当然这个比例要根据业务类型调整，纯浏览型业务占比会高一些，强交互型业务占比低一些，需要结合你自己的访问日志来修正。

Ramp-Up时间（爬坡时间）怎么设？这也是一个特别容易出问题的参数。很多新手把并发数设为1000，Ramp-Up时间设为1秒，结果系统直接被打挂，还以为是自己代码有bug。实际上Ramp-Up时间的作用是让压力逐步升温，避免瞬间冲击导致结果失真——它模拟的是真实用户逐渐涌入的过程。一般建议Ramp-Up时长为总运行时长的10%～20%，或者按“每秒增加X个并发”的方式来计算。比如压测时长10分钟，用1分钟爬到目标并负载，剩下的时间稳定运行观察系统状态，这是比较常见的做法。

持续时间怎么定？性能测试和负载测试的持续时间取决于你要观察什么。如果只是验证接口响应是否达标，5～10分钟基本够用；如果要观察内存泄漏、连接池耗尽这类慢性问题，持续时间至少30分钟以上，甚至需要做数小时的稳定性测试。压力测试的持续时间没有固定标准，只需要覆盖系统从正常到过载再到崩溃的完整过程即可。

2.3 三个真实场景：电商大促、限流验证、容灾恢复

用三个具体业务场景来说明三种测试的差异化设计。

场景一：电商平台秒杀接口的性能验证。业务方给出的承诺是“1万并发抢购时，下单成功率不低于99%，响应时间不超过1秒”。这个场景需要做的是性能测试，直接按1万并发、Ramp-Up 30秒、持续压测10分钟来设计。所有断言和监控都围绕“是否达到99%成功率和1秒响应时间”这个指标展开。

场景二：网关服务的负载摸底。团队要对API网关做容量规划，想知道网关在什么样并发数下吞吐会开始下降。这个场景需要做负载测试，设计为多级梯度：从1000并发开始，每5分钟增加1000，依次加到5000、8000、12000，每个梯度都记录TPS、响应时间和错误率变化，最终绘制出一条完整的“性能拐点曲线”。

场景三：核心数据库的极限压力与故障恢复验证。业务想知道数据库在极限负载下是否会出现连接池耗尽、主从切换之类的现象，以及恢复后系统是否还能正常对外提供服务。这个场景需要做压力测试，压测目标设定在正常负载的3～5倍，持续压到系统出现异常，然后观察异常表现、停止压测后的恢复时间、恢复后的服务状态是否回归正常。

这三个场景我一直建议团队里的新人反复推演，因为它们覆盖了三种测试在最典型业务下的全流程逻辑。你可以在自己的项目里对照着去套，把业务目标、测试类型、场景参数和观测指标填成一张表，方案设计就会清晰很多。

3. 核心指标与监控分析：没有数据支撑的压测等于白做

很多团队做压测时犯的最大错误是只盯着一个TPS看，甚至只看“系统没挂”这个粗糙结果。实际上，一次合格的压测至少要同时观测几个维度的数据，并且能把这些数据关联起来分析，才可能真正定位到瓶颈。这一章把三类测试通用的核心指标和各自的分析重点拆开讲清楚。

3.1 六大基础性能指标：每一个都有不可替代的价值

TPS（每秒事务数）和QPS（每秒查询数）是衡量吞吐能力的核心指标。注意两者严格说不是同一概念，TPS一般指完整事务（比如一次下单包含多个请求），QPS指单次请求。但在很多业务场景里，大家不会刻意区分这两者的定义边界，关键是要在测试报告里注明你统计的口径，避免后续分析时对齐出现偏差。更实用的记录口径是：同时记下总请求数、总耗时，然后实际计算每秒请求量，而不是只看压测工具界面实时跳动的数字。

响应时间不能只看平均值。平均值在分布式系统里迷惑性很强，极端场景下99%的请求都是100ms，但1%的请求是5秒，平均值依然很好看，用户体验却很糟糕。正确的做法是同时观察多个分位值：TP50、TP90、TP99、TP99.9，分别代表50%、90%、99%、99.9%的请求耗时小于该值。上线前用TP99来定SLA，排查问题时重点关注TP99.9的曲线，因为长尾请求往往指向问题的真正根源。

错误率是压测中“一票否决”的指标，更严谨的做法是分三类统计：网络层错误（超时、连接重置）、业务层错误（返回错误码、逻辑异常）、协议层错误（状态码5xx/4xx）。不同位置的错误定位路径完全不同，混在一起统计会让你排查问题时分不清方向。

资源使用率包括CPU、内存、磁盘I/O、网络带宽等。这里也容易出认知偏差——不一定CPU越高越有问题，要结合系统类型区分：计算密集型服务CPU高是正常的，但如果一个IO密集型的服务CPU跑到90%以上，通常说明线程模型或锁竞争存在隐患。内存使用率关注的是增长趋势而非瞬时值，如果在稳定压测期间内存只增不减，大概率存在内存泄漏。

并发数和TPS/响应时间之间存在换算关系。并发数与TPS和响应时间之间有明确的换算关系：TPS约等于并发数除以平均响应时间（秒）。比如平均响应时间是200ms、当前并发数是1000，按公式计算理论上的TPS约为5000。如果实际TPS远低于这个理论值，说明系统还有调度或锁竞争等深层瓶颈，需要继续下钻分析。这个换算公式做压测分析时很实用，能帮你快速判断系统是否已偏离理想状态。

线程数/连接数是服务端处理能力的直接体现。Tomcat的线程池、数据库的连接池、HTTP客户端的连接池，任何一个打满都会成为瓶颈。要注意的是，连接池打满时系统通常不会直接报错，而是表现为响应时间线性上涨，这时候看应用日志常常一无所获，但连接池监控已经一片通红。

3.2 三类测试的指标侧重：同一个数字，解读方式完全不同

同一个TPS数值，在性能测试、负载测试、压力测试里的意义完全不一样。这一点极其重要。

性能测试侧重SLA指标。核心观察对象是响应时间分位值、错误率、TPS是否同时满足需求基线。只要有一个不满足，测试就不通过。此时资源使用率只是辅助参考，你可以为后续调优方向预留判断依据。

负载测试侧重拐点分析。核心观察对象是TPS、响应时间随并发数上升的变化曲线。重点指标是“拐点”：当并发数从N增加到N+1时，如果TPS不再线性增长甚至下降，而响应时间开始指数级上涨，说明系统已经越过最佳工作区间。这时候的N+1就是我们常说的性能拐点，它是容量规划和限流阈值设置的重要参考数据。

压力测试侧重极限行为和恢复能力。核心观察对象不仅仅是“系统挂没挂”，还包括挂了之后怎么挂的，以及停止压测后多久能恢复。判断维度应包括：进程崩溃还是假死？是否有错误堆积？有无主从切换？恢复后是快速回到正常水平还是需要手动干预重启？这三个问题的答案直接决定系统的容灾设计是否需要重新调整。

这三类测试的观测思路差异，建议写进团队的内部测试规范里，避免大家拿到工具就开压，压完只截一张TPS图就交差。

3.3 监控工具链的搭建：压测工具与监控平台联动

压测工具自带的数据通常只有“客户端视角”，也就是发起端看到的TPS、响应时间和错误率。但真正的性能瓶颈分析需要“服务端视角”的数据——CPU、内存、磁盘、JVM GC、数据库慢查询、网络连接状态等。光有客户端数据，你只能知道系统“慢”或者“挂”，却不知道“为什么慢”“为什么挂”。

我在团队里常用的监控组合方案是：Prometheus + Grafana做基础设施和应用层指标的采集与可视化，链路追踪系统（如SkyWalking、Jaeger）做请求级别的耗时拆解，再加上压测工具自身的数据。这三层数据缺一不可：基础设施层告诉你“哪个资源满了”，链路追踪层告诉你“哪个环节耗时最长”，压测工具告诉你“整体用户体验如何”。

搭建的时候有个容易被忽略的细节：监控系统自身的性能也会受压测影响。如果监控组件和应用部署在同一台机器上，压测把CPU打满后，监控数据采集本身就会出现延迟和缺失，导致你在关键时刻看不到数据。在大规模压测时，监控系统最好独立部署，或者至少保证采集端有足够冗余度。

另外，压测过程中一定要记录时间戳对齐的数据。比如压测从14:00开始，每1分钟标记一次数据点，出现异常时精确记录“14:37分出现连接超时”，这样才能回到监控系统里精准定位该时间段的日志和指标。没有时间戳配合，事后分析会非常痛苦。

4. JMeter实操：一套脚本跑通三种测试场景

JMeter是做接口层压测最常用的工具，它本身不区分“性能测试”“负载测试”“压力测试”，区别完全体现在场景怎么配、参数怎么设、结果怎么读。这一章用一套实际可用的JMeter配置，把三种测试的差异体现出来，并顺带讲一下前面提到的CPU压力、GPU压力相关工具怎么选。

4.1 三种测试在JMeter中的配置差异对比

以“商城查询商品列表接口”为例，用一个线程组配置对比三种测试的差异。

性能验证场景配置：

• 线程数（并发）：根据生产峰值推算，比如300
• Ramp-Up（爬坡）：60秒（逐渐增加到300并发）
• 循环次数：固定值，比如总持续时间为10分钟
• 监听器：聚合报告、响应时间图、TPS图

这个场景关注的核心是：300并发下，TPS是否稳定在预期值，响应时间的TP99是否低于SLA要求，错误率是否为0。压测结束后直接和需求基线做对比，得出“达标/不达标”的结论。

负载摸底场景配置：

• 采用Ultimate Thread Group插件（需要安装JMeter Plugins Manager）
• 设置多个负载台阶：500并发持续3分钟 → 1000并发持续3分钟 → 1500并发持续3分钟 → 2000并发持续3分钟
• 监听器：重点看TPS和响应时间随线程数变化的折线图

使用Ultimate Thread Group的目的是实现梯度加压，每个样本组都从零开始逐渐增加并发数，并在指定负载水平上持续一段稳定时间，这样得到的数据曲线更能反映系统在不同压力下的表现趋势。如果没有插件，也可以用多个普通线程组配合“启动时间”来模拟，但操作繁琐且时间控制精度较差。

压力打爆场景配置：

• 线程数：直接设定为正常负载的3～5倍，比如正常峰值300并发，这里设置为1500并发
• Ramp-Up：30秒（快速冲击，模拟流量突刺）
• 循环次数：无限循环，配合Duration设置总运行时长，比如持续压测15分钟或直到系统报错率达到阈值
• 监听器：除常规报告外，建议添加Backend Listener将结果实时发送到InfluxDB，配合Grafana实时展示

这个场景的目标就是压出问题：观察系统在远超正常负载下如何表现、何时开始出现错误、错误率如何爬升、哪些组件最先达到极限、最终是恢复正常还是不可用。

4.2 实战中的关键参数选择与避坑经验

配置JMeter压测脚本时，有几个参数和细节特别容易踩坑，我按重要性列出来。

线程数分配不等于用户数。这是新手最容易误解的地方。一个线程代表一个持续的虚拟用户会话，它会循环执行脚本中的请求，而不是只发一次请求就结束。如果你设置的循环次数是100，单线程就会连续发送100个请求请求。所以“线程数 × 循环次数”才是总请求数。在估算压测规模时，要用“目标TPS × 运行时长”来设置请求总量，而不是简单用并发数乘循环次数。

善用逻辑控制器模拟真实行为。真实用户的操作是随机的，不可能所有人都在同一毫秒点同一个按钮。在JMeter中可以用泊松随机定时器或均匀随机定时器来模拟用户思考时间，避免所有请求像机关枪一样密集。不过这也要看压测目的：做极限压力测试时，反而要禁用所有定时器，让请求以最大速率冲击服务端；做贴近真实的性能测试时，则需要加入思考时间。

Ramp-Up时间设置不当会导致“冷启动”假象。如果并发数很大但Ramp-Up时间太短，服务端会因为大量TCP连接同时建立而出现连接超时，但这种超时不一定代表业务处理能力不行，可能只是连接池初始化的瞬时瓶颈。更好的做法是将Ramp-Up时间适当拉长，同时观察服务端在预热期间的CPU和内存变化，把预热阶段的异常数据从头几秒内剥离再进入正式压测循环。

断言一定要加。很多人的压测脚本没有加任何响应断言，只看HTTP状态码200就认为成功。但实际业务中，状态码200也可能返回“库存不足”“参数校验失败”等业务失败内容。建议使用响应断言检查关键业务字段，或使用JSON Extractor提取业务码做二次判断。否则错误率数据失真，后续所有分析都可能被带偏。

不要在GUI模式下跑正式压测。JMeter的GUI模式本身会消耗相当可观的CPU和内存资源，用GUI跑大规模压测会得到虚假的低TPS数据。正式压测一律用命令行模式（jmeter -n -t script.jmx -l result.jtl），GUI只用于调试脚本。命令行实测下来在同等压力下性能差异很明显，这一点务必养成习惯。

4.3 除JMeter外的压测工具选型参考

JMeter是通用性最好的开源压测工具，但并不是所有场景都适合用它。这里补充一套选型思路，也是我这些年实测下来的经验清单。

• 接口级压测：JMeter或wrk均可。JMeter功能全面，支持复杂业务逻辑和分布式压测；wrk更适合快速压测简单HTTP接口，命令行操作、资源占用极低，适合本地开发时的快速验证。
• 全链路压测：可以考虑基于流量录制回放的工具方案，比如GoReplay或阿里开源的众多方案。这类工具能直接把生产环境的真实流量导入压测环境，比脚本模拟更接近真实。
• 数据库压测：sysbench和pgbench分别是MySQL和PostgreSQL生态中最常用的基准测试工具，可以精确控制线程数、测试时长、读写比例，测试结果也更贴近数据库内核的能力边界。
• CPU压力测试：行业里常用Prime95、r23（Cinebench R23）这类工具，通过持续高负载计算来验证CPU稳定性、散热和降频表现。做服务端容量评估时，也可以用stress命令配合监控工具查看CPU在100%负载下的系统表现。
• GPU压力测试：Linux环境下最常用的是gpu-burn工具，它通过CUDA计算持续压榨GPU算力与显存带宽，主要用来验证GPU在高负载下的稳定性、温度控制与散热性能。AI、图形渲染相关的服务上线前，这类测试尤其重要。

工具选型不需要追求“大而全”，关键是匹配你的测试对象和测试目标。日常做接口测试，JMeter完全够用；涉及硬件稳定性验证，再引入r23、gpu-burn这类专用工具。

4.4 关于“AI+JMeter性能测试”的一点观察

最近经常看到“AI+JMeter性能测试”这类说法，也顺着热词聊两句。目前AI在性能测试领域的落地主要集中在几个方向：用AI辅助生成压测脚本和测试数据、通过历史压测数据智能推荐并发数和阈值、压测过程中结合AIOps自动定位瓶颈根因。这些方向确实能减少重复劳动，比如让大模型根据接口文档生成JMeter脚本片段，实测下来在简单场景里可用性还不错，复杂场景依然需要人工调整。

但我要泼一盆冷水：AI可以帮你更快地“跑”测试，但不能帮你判断“测什么”“结果意不意味着有问题”。性能测试的核心能力和价值在于业务分析与瓶颈定位，这部分短时间无法被AI替代。建议你可以尝试AI辅助提效，但不要把核心判断力拱手让给工具。

5. 常见问题与排查技巧实录

压测过程中踩坑是必然的，区别在于踩完之后有没有总结成可复用的经验。这一章把我自己和团队这些年积攒下来的高频问题和排查思路整理成速查表，并且附上一些独家技巧。

5.1 高频问题速查表

5.2 三个压测后必做的分析动作

压测结束不是把报告一贴就完事。我建议每次压测后至少做三个动作，这套流程帮我在多个项目里快速沉淀了团队的压测体系。

第一，做横向对比。每次压测结果和上一次对比、和历史基线对比。TPS是否下降？TP99是否升高？对比能让你尽早发现性能回退问题——很多隐患在功能开发阶段测不出来，只有在压测曲线对比中才会露出马脚。

第二，拆解瓶颈链路。一次压测暴露的性能问题往往不止一个。比如你看到的是接口响应慢，往下拆可能是数据库慢查询，再往下是缺少索引，再往下是表数据量到了一定规模导致执行计划变化。善用链路追踪工具，把一次请求的完整调用链拉出来，每一跳的耗时都记下来，瓶颈在哪个环节一目了然。

第三，形成优化闭环。每个压测问题的处理不能只停留在“改完就完”，要有前后对比数据。优化前TPS是500，优化后TPS是1200，这个提升就是具体可量化的收益。我在团队里要求每次压测报告都包含“问题—原因—改动—验证结果”的四段式记录，这样半年后回头看，整个团队的成长轨迹和我们系统的进化路径都清清楚楚。

5.3 独家技巧：压测前的系统预热为什么那么关键

这里单独说一个很多人会遗漏的细节：预热（Warm-up）。做过Java服务压测的朋友应该有体会：刚启动的应用，代码是解释执行的，JVM还没有完成JIT编译优化，各类缓存的命中率还处于未建立状态，算法中的热点路径还没被完全识别，直接在大并发下压测，前几分钟的性能表现会明显低于稳定运行阶段。

我习惯在正式压测前先跑一轮3～5分钟的低并发预热，让JIT完成热点代码编译、懒加载数据初始化完成、各类缓存填充到位，再正式进入压测阶段。预热阶段的数据不要混入正式统计，通常从报告里把前面两分钟的数据去掉，只保留稳定段的数据做分析。这个动作虽然简单，但能让压测数据的可复用性提高很多。

还有一个容易踩的坑：压测结束后不要马上关掉监控。系统从高压状态恢复到正常运行，也会暴露很多问题，比如连接池释放不及时、线程没有正常回收、内存没有完全释放等。建议压测结束后再持续观察3～5分钟，确认系统确实回到了正常水位，压测才算真正完成。

6. 写在最后：我的几点真心建议

我自己在压测这件事上栽过不少跟头，从最早的“上来就加并发，压挂了就改代码”到后来形成一套相对科学的压测方法论，中间最大的转变是心态上的：压测的目标不是把系统压挂，而是更好地理解系统。

如果你刚入门，我的建议是先不要追求工具多花哨，把JMeter或wrk学好，把HTTP层面的性能测试和负载测试跑明白，再逐步扩展。先学会看TPS、响应时间分位值、错误率这三个最基本的指标，再学习如何分析资源瓶颈。性能测试是一个实践性极强的领域，看十篇理论不如亲手跑一次压测、看一次监控曲线变化来得有用。

如果你已经有一定经验，我建议把关注点从“怎么测”转移到“怎么分析”。同样是TPS下降，背后的原因可能差异很大，你的价值体现在能在多短时间内定位到根因并给出可落地的优化建议。这套能力需要在真实项目中反复打磨，没有任何捷径。

最后再分享一个我个人的小习惯：每次压测的关键数据我都会保存下来，并按时间线归档。隔一段时间翻出来对比，你能看到系统演进的轨迹——哪些优化真实有效，哪些问题反复出现，哪些瓶颈一直在潜伏。这个数据库积累久了，比任何测试方案模板都更有价值。希望这篇文章能帮你在性能测试这条路上少走一些弯路。