企业官网建设流程全解析

做测试这么多年，有一个感受特别深：很多系统上线前看着一切正常，功能测试全过，结果一到流量高峰期就崩了，数据库连接池被打满，接口响应从几十毫秒变成几秒，最后闹到凌晨紧急扩容。这种问题靠功能测试根本发现不了，必须靠压力测试提前暴露。

压力测试（Stress Testing）是整个性能测试体系里最硬核、也最容易被误解的一块。很多人觉得压力测试就是拿工具狂发请求，看系统什么时候挂，其实远没有这么简单。这篇内容我按自己的理解做了一个超详细整理，从核心概念、关键指标、工具选型到完整实操流程，再到常见的故障排查思路，一次讲透。不管你是刚入行的测试新人，还是在准备软件测试面试，或者即将独立负责一个系统的压测工作，这篇都应该能帮上忙。

1. 先搞清楚压力测试到底在测什么

1.1 压力测试不是"使劲点按钮"

我见过太多人对压力测试的理解停留在"用工具并发怼接口"。真要这么简单，那就不会有那么多系统在双十一、秒杀、抢票这类场景下翻车了。

压力测试的定义其实很明确：通过逐步增加系统负载，观察系统在超过正常预期负载的情况下，能否稳定运行，以及在何种负载条件下开始出现性能下降、报错甚至崩溃。它回答的核心问题不是"系统能处理多少请求"，而是"系统在极端情况下还能不能扛得住，扛不住的时候以什么方式失败"。

这里顺带把几个容易混淆的概念放在一起对比一下，这是软件测试面试题里出现频率极高的一组概念区分：

压力测试关注的是极限状态。打个比方，负载测试是问"一个人每天能跑5公里吗"，压力测试是问"这个人连续跑100公里会不会猝死，跑到第几公里开始出问题"。知道了极限在哪里，你才知道日常应该预留多少余量。

1.2 为什么非做不可

不做压力测试就上线，就像不试刹车就上高速，不是一定出事，但出事就是大事。具体来说，压力测试解决以下几个核心问题：

• 提前发现性能瓶颈：数据库慢查询、缓存穿透、线程池配置不当、内存泄漏，这些隐藏问题在低并发下根本不会暴露，只有把负载顶上去才会现出原形。
• 为容量规划提供依据：业务方问你"系统能扛多少用户"，没有压测数据你只能拍脑袋。有了压测报告，你就可以说"单实例最高支撑2000 QPS，超过这个值需要加机器"。
• 验证系统在过载时的表现：最好的情况是系统优雅降级，最差的情况是进程崩溃、数据丢失。压力测试能帮你验证熔断、限流、降级策略是否真的生效。
• 为稳定性提供信心：尤其是银行、支付、电商这类对稳定性要求极高的行业，上线前压测是硬性流程。银行软件测试的逻辑更是如此，宁可提前测出问题，也不能让线上出问题。

1.3 压力测试的目标设定

动手压测之前，先要明确目标。不同阶段、不同系统，目标完全不一样：

• 验证型目标：系统声称能支撑5000 TPS，那压测就是验证在5000 TPS下，响应时间是否在可接受范围内，错误率是否低于阈值。这类目标在功能上线前最常见。
• 探索型目标：不知道系统的上限在哪里，那就逐步加压，从100并发开始，逐级升到200、400、800，直到系统性能出现明显拐点。这类目标常用于容量评估和技术选型对比。
• 稳定性目标：在某个固定压力下持续跑1小时、4小时甚至更久，观察系统是否会出现内存增长、性能衰减等长期运行问题。

目标设定决定了你的压测方案怎么设计，这是整个压力测试工作的第一步，也是很多人容易跳过的一步。没有明确目标就开压测工具，最后跑出来的数据往往只能看看热闹。

2. 核心指标：看不懂这些数据等于白测

压力测试结束以后，会得到一堆数据。这些数据不是拿来看的，是用来做判断的。但前提是你要懂每个指标的含义，以及它们之间的关系。

2.1 TPS 和 QPS：系统吞吐能力的度量衡

TPS（Transactions Per Second）指每秒处理的事务数，QPS（Queries Per Second）指每秒处理的查询数。在接口测试场景中，很多人把这两个混用，因为一个接口请求可以看作一个事务，也可以看作一个查询。严格来说，一个事务可能包含多个查询，但实际工作中绝大多数情况可以画等号。

计算方式很简单：TPS = 总请求数 / 总耗时（秒）。比如压测10分钟，一共完成120万个请求，那么TPS就是1200000 / 600 = 2000。

这里有个容易被忽视的细节：TPS是压测工具的统计口径，它统计的是客户端视角的完成情况，并不完全等于服务端的真实处理能力。如果客户端已经出现超时或连接异常，统计到的TPS会比服务端实际处理的低。所以做压测时，服务端也要同时监控，两边数据对照看才有意义。

2.2 响应时间和百分位数：平均值的陷阱

响应时间是最直观的指标，但也是被误解最多的指标。很多测试报告只写"平均响应时间50ms"，这是骗人骗己的写法。为什么？因为平均值会被极端值拉高，同时也会被大量快请求稀释。假设一个接口在压测期间，99%的请求都是10ms返回，但有1%的请求卡了10秒，平均值是110ms左右，看着还行，但实际上那1%的用户已经卡到怀疑人生。

正确做法是看百分位数，即 TP50、TP90、TP95、TP99：

• TP50：50%的请求响应时间不超过该值，代表大多数用户的体验
• TP90：90%的请求响应时间不超过该值
• TP99：99%的请求响应时间不超过该值，代表最差一批用户的体验
• TP999：99.9%的请求响应时间不超过该值，常用于核心链路场景

JMeter的聚合报告（Aggregate Report）里会直接给出这些数据，不用自己算。分析的时候重点关注 TP99，如果 TP99 和 TP50 差距过大，说明系统存在明显的长尾延迟，这往往是某个资源竞争或者垃圾回收导致的。

2.3 并发用户数、并发请求数和资源利用率

这里有个概念必须先掰清楚：并发用户数不等于并发请求数，也不等于TPS。1000个在线用户，同一时刻真正在发请求的可能只有100个，而服务器每秒钟能处理的请求可能是5000个。这三者之间的换算关系取决于用户的操作频率和思考时间。

资源利用率是压测时必须实时监控的指标，包括：

• CPU使用率：单核还是多核被打满，用户态和内核态的比例是否正常
• 内存使用率：是否有持续增长趋势，是否存在内存泄漏
• 磁盘I/O：读写延迟、队列长度、吞吐量
• 网络I/O：带宽占用、连接数、重传率
• 线程池/连接池使用率：活跃线程数、等待队列长度、连接获取等待时间

判断系统是否达到瓶颈，不能只看某一个指标，要综合看。比如CPU没打满但TPS上不去，那瓶颈就不在CPU上，可能在数据库锁、网络带宽或者代码本身的串行逻辑上。

2.4 错误率和性能拐点

错误率是压测报告里最敏感的数据。理想情况下压测全程错误率为0，但实际操作中几乎不可能。关键是看错误出现在什么阶段、什么类型。

• 连接超时：说明后端处理不过来，请求堆积在等待队列
• 请求超时：说明单个请求处理时间超过了客户端设定的超时阈值
• 连接被重置：可能是服务端主动断连，也可能是负载均衡层做了拦截
• 5xx状态码：说明服务端已经进入异常状态

性能拐点是压测过程中需要重点观察的现象。典型的场景是：并发从100升到200时TPS线性增长，从200升到300时TPS增长变缓，从300升到400时TPS不升反降，错误率开始飙升。这个"不升反降"的点就是性能拐点，它意味着系统已经过载，继续加压只会让情况更糟。

我个人习惯在压测过程中画一条TPS随并发变化的趋势曲线，拐点出现的位置，就是系统真实承载能力的上限。后续做容量规划、限流阈值设定，都以这个数据为依据。

3. 工具选型：别一上来就只认JMeter

压力测试工具太多了，每个都有自己适合的场景。选工具的标准不是"哪个最流行"，而是"哪个最适合当前项目的技术栈和测试目标"。

3.1 接口和协议压测工具

• JMeter：开源、免费、生态成熟，支持HTTP、HTTPS、WebService、JDBC、JMS等几乎所有主流协议。图形化操作界面，上手门槛低，而且有完整的报告体系。是目前国内使用率最高的压测工具，面试被问到的概率也最大。
• wrk / wrk2：基于C语言的高性能HTTP压测工具，单机就能压出很高的并发。适合快速对某个接口做冒烟式压测，但不支持复杂的业务脚本和参数化。Linux下用起来很顺手。
• Apache ab：Apache自带的压测工具，轻量简单，适合临时验证接口性能。但功能非常有限，不支持场景编排，也不适合复杂压测。
• Locust：基于Python的开源压测工具，用代码定义用户行为，支持分布式压测。适合写复杂业务场景，但对Python水平有一定要求。
• k6：基于Go语言的压测工具，脚本用JavaScript编写，性能好，支持云原生部署。近年很火，适合对性能要求高、有DevOps基础的团队。
• LoadRunner：商业工具中的老大哥，功能强大，支持协议极多，适合大企业复杂系统。但价格高昂，学习曲线陡峭，现在的互联网公司用得越来越少了。

做技术选型的时候，我的建议是：大多数Web项目首选JMeter，理由有三点：一是免费，二是资料多，三是公司内外协作方便。即使个人电脑上没装Linux环境，Windows/macOS都能跑起来。

3.2 硬件资源压测工具

压力测试不只是测接口，很多时候还要测服务器本身的硬件稳定性。这也是热搜词里"cpu压力测试怎么开""gpu压力测试(gpu-burn)工具""r23压力测试软件"这些词的来源场景。

• CPU压力测试：Linux上最常用的是stress-ng，可以指定压力类型（CPU计算、内存分配、I/O读写等）和压力时长。Windows上可以用 AIDA64 的系统稳定性测试，或者直接跑 Cinebench R23 这种专业渲染工具来拉满CPU负载。
• GPU压力测试：最知名的是gpu-burn，专门在Linux下对NVIDIA显卡做高负载运算测试，用来验证GPU在满载情况下的稳定性和散热能力。Windows端常用 3DMark 的 Time Spy 压力测试或 FurMark，通过持续渲染高负载场景来测试显卡稳定性。
• 内存压力测试：Linux下可以用memtester和stress-ng的--vm参数，Windows下用 MemTest86 这类工具。这在存储压力测试场景中很常见，比如你怀疑内存条有问题或者要验证应用内存占用是否泄漏，跑一轮就能发现。
• 磁盘压力测试：用fio工具做IOPS、吞吐量和延迟测试，可以模拟随机读写、顺序读写等多种负载模式。

这里多说一句：硬件压测和应用压测往往是配合使用的。比如你压测一个视频转码服务，CPU必须拉满，这时候就要先确认CPU在持续高负载下的稳定性，否则应用压测过程中CPU降频或者死机，你就分不清是应用的问题还是硬件的问题。

3.3 压测工具选型的实操建议

选型没有什么标准答案，但有几个经验原则可以参考：

• 协议匹配优先：先确认被测系统的协议类型。如果是纯HTTP接口，JMeter、wrk、k6随便选；如果是数据库，JMeter的JDBC插件或者专门的数据库压测工具有更合适的。
• 脚本复杂度决定选择：只是简单压一个GET接口，用wrk就够了；要模拟用户登录、浏览、下单、支付这种多步骤场景，还是JMeter更合适。
• 团队技术栈要考虑：团队都是Python背景，Locust的学习成本低很多；团队有Go基础，k6是不错的选择。工具是给人用的，团队成员用得顺手才是硬道理。
• 分布式压测是后期的必经之路：单机压测到一定规模就上不去了，因为压测工具本身也消耗系统资源。JMeter支持 Master-Slave 分布式压测，k6、Locust本身也支持分布式部署，选型时把这个因素考虑进去。

4. 压力测试实操：从0到1跑完一轮完整压测

工具选好了，接下来就是实战。我以最常用的 JMeter 为例，完整梳理一遍压测的流程和关键动作。这套流程不管用什么工具，思路都是通用的。

4.1 需求分析和场景设计

压测不是直接打开工具就开始发请求，先要回答几个问题：

• 压什么接口：是登录接口、下单接口还是查询接口？还是整个业务流程？
• 压多少并发：这个数据怎么来？可以基于现有线上流量统计，也可以基于业务预期。比如业务方说未来三个月注册用户要到100万，日活10万，那核心接口的并发就可以按"日活/忙碌小时/3600"粗算一个基础值，再乘一个峰值系数。
• 压多长时间：普通验证跑10-15分钟足够，稳定性测试至少1小时起步。
• 成功标准是什么：TPS目标值、TP99响应时间上限、错误率上限，这些要在压测前就定好，不然压完没法评估结果。

场景设计时，我的建议是核心链路优先。不要试图一次性把所有接口都覆盖到，先把最关键、最影响用户体验的接口挑出来单独压测，然后做组合场景压测。组合场景要参考真实的用户操作比例，比如登录和查询的比例可能是1:10，那就按这个比例分配压测流量。

4.2 脚本准备和参数化

JMeter脚本准备过程中，有几个关键点容易踩坑：

线程组设置。线程数（Number of Threads）代表并发用户数，Ramp-Up Period代表多长时间内启动所有线程。如果设置了100个线程、Ramp-Up为10秒，那么每秒增加10个线程。这里有个常见误区：Ramp-Up设为0不代表没有效果，而是代表立即启动所有线程，会瞬间产生非常大的冲击。压测初期我通常设置一个递增的Ramp-Up，比如60秒，让系统逐步承受压力，这样能更清晰地观察到不同负载阶段的表现。

循环次数和持续时间。更推荐用Duration（持续时间）控制压测时长，比如固定压5分钟，而不是固定循环100次。因为固定次数的压测总耗时受系统响应速度影响，系统变慢时压测时间会被拉长，数据可比性就差。

参数化。这是压测实录中最重要也最容易忽略的环节。如果压测请求里的数据都是写死的同一个值，那就等于在测缓存，测出来的TPS可能虚高。比如压测用户查询接口，所有请求都查同一个userId，第一次查询后数据进了缓存，后面的请求全部命中缓存，这个数据完全不能反映真实性能。

常规做法是使用JMeter的CSV Data Set Config，准备一批测试数据存到CSV文件里，每个请求取一行，循环使用。不同场景对数据的要求不一样：

• 查询类接口：准备一批真实存在的ID，注意不要只用一个
• 登录接口：准备多个测试账号密码，避免账号被锁定影响压测
• 写操作接口：注意数据清理，压测会产生海量脏数据，压测完要清掉

4.3 测试执行和实时监控

脚本准备好后，正式执行压测。这一步最忌讳的是"脚本一跑就等着出结果"。压测过程中必须实时监控，因为很多问题只在特定负载阶段出现，错过了就不好复现了。

我个人的执行习惯是分阶段进行：

• 预热阶段（1-2分钟）：用小并发（比如10-20线程）跑起来，确认脚本没问题、参数化正确、被压测环境没有报错。
• 阶梯加压阶段：逐步提高并发，观察TPS和响应时间的变化趋势。每提升一档，等系统稳定1-2分钟再继续加。
• 持续压测阶段：达到目标并发后，保持压力持续运行一段时间，观察系统是否有性能衰减、内存增长等问题。
• 释放阶段：压测结束后不要立即关闭脚本，观察系统恢复到正常状态需要多长时间，这也能反映系统的自愈能力。

监控方面，至少要做到以下几条：

• 通过网络监控工具看服务端的CPU、内存、磁盘I/O、网络I/O
• 用top、free、df -h、iostat、sar这些Linux基础命令做系统层监控
• 查看应用日志，关注错误日志和慢请求日志
• 监控中间件状态：数据库连接数、Redis命中率、消息队列堆积量

这个过程中如果发现TPS急剧下降、错误率飙升、CPU持续100%，就要及时判断是继续加压还是停止排查。不要为了追求一个"好看的结果"而硬撑着跑完，压测的目的是发现问题，不是交差。

4.4 结果分析和瓶颈定位

压测跑完，到了最考验功力的环节：数据分析。除了直接看JMeter聚合报告里的TPS、响应时间、错误率，更重要的是把服务端的监控数据和压测工具的统计数据对照起来看。

以最常见的"TPS上不去"问题为例，排查思路大致是：

• 先看服务端CPU：如果CPU已经满负荷，说明计算密集，重点排查应用代码效率、GC频率
• 再看数据库：如果CPU没打满，但数据库的CPU高、慢查询多，瓶颈在存储层
• 检查连接池和线程池：看线程池是否打满，请求是否在排队。线程池打满的典型特征是TPS上不去、响应时间线性增长
• 检查外部依赖：被测系统依赖的第三方接口、下游服务是否成了瓶颈，可能导致同步阻塞
• 检查网络和负载均衡：带宽是否打满、负载均衡的转发能力是否受限

这里有一个我踩过很多次的坑：压测结果不好，第一反应不要怀疑系统代码，先检查压测工具本身。因为JMeter单机压测能力有限，线程数开得过大，JMeter自身的CPU和内存会成为瓶颈，导致发压能力不足。曾经有一次压测，TPS始终上不去，排查了很久服务端，最后发现是JMeter所在机器只有4核CPU，压测线程开到了500，JMeter进程CPU已经100%，根本发不出更多请求。压测机的性能必须远高于被测系统，否则测出来的不是系统瓶颈，是压测工具瓶颈。

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

压测做得多了，遇到的问题也就那么多。我把高频问题整理成速查表，每个都对应到具体的排查方向和实操建议。

5.1 内存泄漏的经典排查过程

内存泄漏是稳定性压测中最典型的长期问题。简单描述一下排查套路：

压测开始阶段TPS正常，跑了2小时后TPS开始缓慢下降，响应时间逐渐增加。用top查看进程内存，发现JVM内存占用持续增长，GC日志显示Full GC频率越来越高。

下一步用jmap -dump:format=b,file=heap.hprof <pid>导出堆内存快照，然后用 MAT（Memory Analyzer Tool）分析，重点看：

• 哪些对象占用了最多内存
• 是否有对象实例数量异常庞大
• 是否有对象无法被垃圾回收器回收

找到疑似问题对象后，回到代码里定位创建该对象的逻辑，通常就会发现某个静态集合类只加不删、或者连接没有关闭导致的对象引用链无法释放。修复后再压测一轮，确认内存曲线变成平稳状态，问题才算真正解决。

5.2 数据库连接池被耗尽

这个问题的典型表现是：压测初期一切正常，并发升高后突然大量报错，错误信息类似Connection pool exhausted或者Cannot get a connection, pool exhausted。

排查思路是：

• 确认当前连接池的最大连接数配置：HikariCP默认是10，Druid默认是8，这个数量在高并发下非常容易被打满
• 查看每个请求获取连接的持续时间：如果每次请求持连接时间过长，说明SQL执行太慢或者事务范围过大
• 检查数据库侧的最大连接数限制：MySQL的max_connections默认为151，如果应用实例开得很多，连接数很容易超限
• 排查连接泄漏：是否有代码获取连接后没有finally释放，或者异常路径漏了关闭连接

调整方向通常是：先优化SQL减少每条请求持锁/持连接的时间，再评估是否要增大连接池和数据库最大连接数，同时给连接设置合理的空闲回收和最大生命周期。

5.3 压测机上发现资源不足

前面说过压测机本身可能成为瓶颈。这里再补充一个典型场景：压测过程中发现JMeter的TPS出现周期性下跌，而且错误率升高，但在服务端完全看不到任何异常。

用top看了下压测机，发现CPU使用率100%，而且是JMeter进程占满。再往下看，JMeter是纯Java应用，内存开得太小导致频繁GC，GC停顿期间发压能力骤降。解决办法：

• 给JMeter加大堆内存：修改jmeter.bat或jmeter.sh里的HEAP="-Xms2g -Xmx2g"，具体大小根据压测机配置来
• 减少不必要的内容：关掉View Results Tree这类监听器，因为保存全部响应结果会非常消耗内存
• 改用非GUI模式运行：jmeter -n -t test.jmx -l result.jtl -e -o report_dir，GUI模式本身也会消耗不少资源，正式压测一定要用命令行模式

这条经验几乎每次给团队培训都会讲：正式压测必须用命令行模式，GUI只适合调试脚本阶段。命令行模式跑出来的结果更稳定，也更容易集成到CI/CD流水线里。

5.4 定位性能瓶颈的完整方法

如果压测结果不达标，但上面的速查表没有完全命中，可以走一套完整的定位流程。我的核心思路是分层排查，逐层剥离：

• 压测工具层：先确认压测机资源充足，脚本没有明显不合理的地方
• 网络层：检查压测机到服务端的网络延迟、带宽、丢包率。方法很简单，压测期间在压测机和服务端分别执行ping、sar -n DEV 1看流量
• 接入层：检查负载均衡、网关的转发能力和配置。Nginx的worker_processes、worker_connections是否足够，是否开启keepalive
• 应用层：看应用实例的CPU、内存、线程Dump、GC日志，用APM工具（如Arthas、SkyWalking）分析热点方法
• 数据层：看数据库的慢查询、连接数、锁等待情况，检查缓存命中率

每排查完一层没有发现问题，就往下继续。正常来说，80%的瓶颈要么在数据库，要么在应用层的线程池/连接池配置上，这两处优先排查。

6. 压测报告怎么写才有说服力

压测数据出来了，问题也定位了，最后还要落到一份报告上。很多人不重视报告，觉得数据摆上去就行了。实际工作中报告写得好不好，直接影响领导/客户/开发团队对系统质量的判断。

一份完整的压测报告至少要包含以下内容：

• 测试概述：测试时间、测试环境（机器配置、网络环境、操作系统）、测试工具、被测系统版本
• 测试场景：压了哪些接口、并发多大、持续时间多长、测试数据怎么构造的
• 关键指标结果：TPS、响应时间（TP50/TP90/TP99）、错误率、资源利用率，用表格对比目标值
• 问题清单：压测过程中发现了哪些问题、严重程度、影响范围
• 性能结论：系统是否达到预期目标，当前承载能力是多少，瓶颈在哪里
• 优化建议：针对每个问题给出可落地的优化方向，按优先级排序

写报告有一个原则我始终强调：数据波动要解释原因。比如TPS在压测中期有一个明显的下跌，报告里不能只写"TPS下跌30%"，要说明是因为数据库出现了慢查询，还是因为GC频率升高。没有原因解释的数据，对决策者来说只是一串数字，对开发排查问题也帮助有限。

报告里还有一个细节：要区分测试环境压测结果和线上环境压测结果。同一个系统，测试环境和线上环境的机器配置、网络环境、数据量完全不一样，压测数据不能直接画等号。如果是在测试环境做的压测，报告要注明，并给出换算到生产环境的估算逻辑。

7. 给新人的几条实在建议

如果看完这篇内容，你正准备开始接触压力测试，我再多啰嗦几句实操层面的经验：

第一，先学会看懂系统资源监控。很多测试新人一上来就学JMeter，工具用得很溜，但问起服务端CPU、内存、磁盘I/O都说不清楚。压测的核心是分析，不是发请求。建议先在Linux上把top、free、iostat、sar、vmstat这些基础命令用熟，这是做性能分析的基本功。

第二，自己搭一套简单的压测环境练手。在自己电脑上装一个Spring Boot应用，写两个接口，一个查询数据库，一个做计算密集任务，然后用JMeter分别压测，观察不同负载下TPS和CPU的表现。这个过程不需要真实业务，但能帮你把压测的完整流程跑通。

第三，学会看GC日志和线程Dump。这是Java应用性能排查的核心工具，也是面试中经常被考察的加分项。不会分析GC日志，遇到内存问题时就会抓瞎；不会看线程Dump，遇到死锁、线程池打满就只能靠猜。

第四，多多关注真实的压测案例和开源压测工具文档。现在网上有很多免费的开源课程和社区文章，比纯看理论书有效得多。像JMeter官方文档里的示例、GitHub上的k6案例、各类技术社区的性能优化实战文章，都是很值得反复研究的内容。另外像全国大学生软件测试大赛这类专业赛事也值得关注，里面的题目往往会超出日常工作的视野，对提升测试设计思维帮助很大。

压测这条路上踩过的坑很多，但每一项经验沉淀下来，都会变成你自己的判断力。对一个系统性能的判断，从"我觉得应该没问题"变成"我压过了，数据证明没问题"，这中间的差别，正是压力测试这个岗位不可替代的价值所在。