1. 先把三种测试掰开揉碎性能、负重、极限不是一回事很多刚入行的测试同学或者转了三年开发想补测试知识的后端工程师最常问我的一个问题就是性能测试、负载测试、压力测试到底有啥区别很多人以为这三个词是同一个东西换着叫面试的时候答不好实际干活的时候也容易把场景搞混。我自己的理解是这三者其实是一条路上的三个阶段或者说三个不同角度的问题。性能测试是问你做得好不好负载测试是问你能扛多少还不出问题压力测试是问你被压垮之后是什么反应。虽然都要用压测工具去制造并发请求但目标、手段、结论完全不同。把它们混为一谈最直接的后果就是你测出来的数据报告业务方和研发根本没法用。1.1 一张表看懂核心区别这里我直接给一个对比表是我培训团队时必发的一张图。做测试之前先对着这张表想清楚自己到底要做哪一种。维度性能测试负载测试压力测试核心问题系统表现是否达到预期系统能承受多大负载超过极限后会发生什么加压方式按预期业务量执行阶梯式缓慢增加负载持续加压直至系统崩溃或濒临崩溃关注重点响应时间、吞吐量是否达标找到容量拐点和最大承载能力系统失败方式、恢复能力、是否产生数据损坏典型场景上线前性能验收容量规划、扩容评估极端突发流量、重构后稳定性验证结束条件完成预设场景和指标判定发现拐点或达到目标负载观察到系统出现可接受的降级或明确崩溃打个比方性能测试就像你试驾一台车在标准道路上能不能跑到标称的百公里加速负载测试是看它满载5个人加一后备箱行李还能不能正常跑压力测试是你硬塞8个人进去看它是爆胎还是悬挂塌了或者夸张一点——车会不会翻。1.2 实际项目中为什么总把三者混用说句实在话绝大多数中小团队在真正落地的时候并不会非常严格地区分我现在做的是性能测试因为商业项目节奏太快。你拿到一个需求第一反应往往不是我要定义这是负载还是压力而是我要模拟多少用户、打多少并发、看哪些指标。但正因为这样问题才会频出。我记得有次帮一个团队看他们线上服务为什么会超时他们给的压测报告写的是1000并发下平均响应时间2.8秒。结果我去一问他们测试时用的是终极线程组初始线程数直接拉到1000一秒之内全冲上去。这根本不是真实用户负载这是压力测试的做法但他们在报告里把它当成性能基准去解读自然得不出正确结论。如果你不知道这三种测试的区别你就不知道你这个场景数据到底是在验证什么更不知道瓶颈是容量问题还是极限下的崩溃问题。所以我一直建议团队在做任何压测之前先做一个三选一的判断这次要回答的问题是达标不达标还是能扛多少还是崩了好不好看。三种答案对应的是完全不同的测试设计。2. 测试前必须定清楚的指标和压测模型测试方案里最怕的就是人到了、工具开了但是指标没定。你会看到大家的对话变成好像挺快的这个并发挺高的服务器CPU有点高啊。没有量化指标压测就是在自嗨。一次有效的性能测试从一开始就必须知道你在看什么数据、这些数据达到什么值才算过。2.1 核心指标拆解先搞懂这些词再动手不管是JMeter还是LoadRunner最终跑出来的报告里都会有一堆数字。你不需要每个都盯但下面这五个是无论如何都要确定的第一是响应时间。这个最直观就是用户发起请求到收到完整响应的时间。业内常说的2-5-10原则虽然不是绝对标准但很有参考意义2秒以内用户感觉流畅2到5秒还能接受超过5秒用户会明显不耐烦超过10秒基本等于用户流失。在C端业务上我通常会再严格一点核心接口的TP95在1.5秒以内才算及格。第二是吞吐量也就是TPS或者QPS。TPS指每秒事务数QPS指每秒查询数。很多工具里叫Throughput单位是 requests/sec。这个数字的意义是告诉你系统每分钟能处理多少业务是做容量规划的关键依据。一个双十一前的系统估算容量本质就是在算峰值QPS。第三是错误率。这个指标最容易被新手忽略因为平均响应时间和TPS都好看的时候他们就觉得过了。但高性能系统里哪怕0.1%的错误率在百万级请求量下就是一千个用户失败。线上支付类接口我会要求错误率为零一般查询类接口也至少要低于0.01%。记住平均响应时间会掩盖尾部延迟问题错误率才是真实体检报告。第四是并发用户数。这里有一个特别大的误区很多人把JMeter里的线程数直接当成在线用户数。其实并发用户数是指同时向服务器发起请求的用户数量而不是系统当前的在线人数。拿一个在线商城举例100万注册用户可能同时在线只有5万这5万人里会同时点击某个按钮的可能只有几百人。真实的并发模型是用用户行为推算出来的不能拍脑袋。第五是资源利用率。包括CPU、内存、磁盘I/O、网络带宽。这个指标是给研发定位瓶颈用的。如果响应时间变慢但服务器CPU只用了20%那问题大概率不在服务器算力而在锁、I/O或者数据库连接池上。如果CPU已经100%那方向就很明确了先去优化代码逻辑或者扩容。2.2 压测模型怎么建别把并发数拍脑袋定出来确定了指标之后下一步就是设计压测模型。所谓压测模型就是你模拟的压力长什么样。我见过最粗糙的做法是运维拍个脑袋说我们系统可能有1万人同时用然后JMeter里就真的开1万个线程去测。结果把压测机自己先跑挂了服务器连请求都没收到几个。正确的建模方法是先确定三个数目标TPS、单用户节奏和并发用户数。以电商下单接口为例假设业务方的预期是高峰期每分钟要处理6000个订单。那么目标TPS就是100也就是每秒要处理100笔订单。接着根据用户操作习惯估算单用户节奏一个用户从打开页面到完成下单中间要经过加载商品、查看详情、加入购物车、提交订单多个步骤大概花30秒。那么活跃用户数就等于TPS乘以每用户平均操作时间也就是100乘以30等于3000个活跃用户。有了这3000个用户的规模之后你再根据压测工具的能力去配置线程数。要注意这3000个用户并不是时刻都在点提交订单他们分布在不同的操作步骤上。所以压测环境里通常只需要模拟提交订单这一个接口的实际并发压力可能300个线程配合思考时间就能覆盖。这些细节决定了你配置线程组时要不要加定时器、要不要加循环次数而不是傻乎乎地线性放大。还有一个容易被忽略的点压测数据要贴合生产。测试数据如果是空的、重复的、没有索引规律的接口响应时间会和你上线后的真实表现差很远。我的习惯是从生产库脱敏后抽取一部分真实数据到压测环境至少保证账号、商品、订单三条核心链路的数据量级和生产一致。3. 工具选型与实操步骤从JMeter到LoadRunner再到硬件压测工具这东西真的不用纠结太多。只要理解原理任何工具都只是发请求和收响应。团队里最常用的组合是JMeter为主、LoadRunner为备然后针对CPU和显卡的稳定性再单独用专门的硬件压测工具。下面我按这个思路把每一步怎么操作、为什么要这么操作都讲透。3.1 JMeter压测从零到跑通的六个步骤JMeter是目前开源工具里占有率最高的压测工具没有之一。原因很简单免费、插件丰富、支持分布式而且官方一直在更新。很多帖子会写一长串安装教程我这里只讲从安装到出报告最关键的六个步骤。第一步是准备脚本。你可以在JMeter里通过HTTP请求Sampler手动配置接口地址、请求方式和参数也可以用Badboy或者JMeter自带的HTTP(S) Test Script Recorder录制浏览器的操作。手写脚本的好处是清晰可控录制的好处是复杂流程快。我的建议是核心接口尽量手写只有那种要模拟完整浏览器用户路径的场景才用录制。第二步是配置线程组。这一步的核心是决定你要用多少线程、多少时间加完、循环多少次。这就要回到上面说的压测模型。以我们要模拟100TPS为例每个线程执行一次事务需要1秒那100个线程就能达到100TPS如果每个线程一次事务需要2秒那就要200个线程。线程数乘以循环次数等于总请求量要根据测试时长来定。第三步是加定时器。很多新手做压测只发请求不加思考时间这测出来的系统压力是重度压力不代表真实用户行为。真实的用户流程中用户看到页面、读文字、点按钮之间是有停顿的。JMeter里可以用Constant Timer或者Gaussian Random Timer来模拟。加不加思考时间取决于你做的是容量评估还是极限压力测试。第四步是添加断言。断言就像一个自动化测试里expect步骤它告诉JMeter什么样的响应算成功。我建议至少加一个响应代码断言明确期望是200再配合一个响应文本断言确认返回内容里包含关键业务字段。如果没有断言只要TCP连接成功JMeter就认为请求成功了哪怕你后端抛了500或者返回了一个错误JSON它都算通过。第五步是配监听器和聚合报告。JMeter的监听器有很多种但真正拿来讲结论的我用得最多的是聚合报告和表格监听器。聚合报告里可以看样本数、平均响应时间、中位数、90%、95%和99%百分位、吞吐量、错误率这些就是上一节说的核心指标。需要注意监听器本身也会消耗资源压测过程中尽量少开图形化监听器可以在跑完后再打开查看结果文件。第六步是跑起来并保存结果。跑完之后记得勾选保存表格数据输出一份CSV结果文件。这样即使JMeter关了你还可以用脚本从CSV里提取各种百分位数据方便写报告或者后续复盘。3.2 线程组到底怎么选这个选择直接决定测试类型这里专门说一下热词里提到的压力测试选择什么线程组。很多人第一次用JMeter都以为线程组就一个Thread Group。其实JMeter的线程组可以分为几个大类而选哪个直接决定了你做的是哪种测试。基础的Thread Group用于配置线程数、Ramp-up时间、循环次数。它适合我们上一节说的性能测试和常规负载测试。通过调节Ramp-up时间控制压力上升的坡度例如10个线程在10秒内逐步启动每个线程每秒启动一个。另外两个常用的高级线程组来自插件分别是Stepping Thread Group和Ultimate Thread Group。Stepping Thread Group可以设置逐级加线程的步长比如每10秒增加20个线程保持运行30秒后再加。这是典型的负载测试模型通过阶梯式加压来观察系统响应时间在什么阶段开始劣化从而找到容量拐点。Ultimate Thread Group更灵活启动时间、运行时间、关闭时间各自独立配置。它可以模拟一个波峰、波谷的曲线适合压力测试中模拟流量高峰。还有一个bzm - Arrivals Thread Group它的特点是不关心有多少线程而是按到达率来配置直接指定每秒要产生多少个请求。这个思路更贴近我们计算目标TPS的模型对于以TPS为目标的压测场景非常合适。我自己的习惯是性能测试用基础Thread Group负载测试用Stepping Thread Group压力测试用Ultimate Thread Group配合高并发短时间冲击。团队里新人也常问压力测试选择什么线程组我的标准回答是先回答你的目标是什么再谈线程组。3.3 LoadRunner的流程和适用场景LoadRunner可以说是老牌商业压测工具里的标杆。它的核心流程是用VuGen录制脚本用Controller设计场景用Analysis分析结果。和JMeter相比它最大的优势在于企业级场景的完整度包括大并发支撑、专业报告、对很多老协议的支持。LoadRunner的VuGen录制脚本和JMeter录制类似但它录出来的脚本是C语言风格的。Controller里可以设置场景类型比如手动场景、面向目标的场景。面向目标场景接口你可以直接设置目标TPS或者目标并发数让工具自动调整负载去接近这个目标这个功能在JMeter里要配合插件才能勉强做到。LoadRunner的问题在于贵、重、学习曲线陡峭。中小企业如果没有大并发合规审计需求我一般不建议上来就用它。用JMeter已经能覆盖90%的常规场景剩下10%再考虑上商业工具。3.4 不止是接口CPU和显卡压力测试怎么做回到热词里的cpu压力测试和显卡压力测试 furmark。这个其实是硬件稳定性测试和软件接口压测是两个不同的测试领域但在一些场景下它们会交叉。例如压测机本身的稳定性、做音视频转码或渲染的应用CPU和显卡可能会成为系统瓶颈因此有必要单独做硬件压测。CPU压力测试我比较常用的是Prime95和AIDA64。Prime95是跑最大发热负载的经典工具它利用梅森素数计算把CPU核心压到满载短时间内温度会迅速上升。软件行业里很多人用它来验证新装机CPU散热和稳定性。如果你的代码是CPU密集型的在上线前用这种方式把整机负载拉满跑30分钟能提前发现散热不足导致的降频。AIDA64的优势在于可以只压CPU的FPU部分实测FPU压测比普通测试负载高很多发热更猛。显卡压力测试最出名的是FurMark。它通过渲染毛茸茸的圆环来让GPU跑满同时显示实时帧率和温度曲线。正常情况下连续跑15到30分钟如果显卡不出现画面撕裂、驱动崩溃温度控制在合理范围就可以认为显卡在长时间满载下是稳定的。这里的合理范围因显卡而异NVIDIA显卡的核心温度一般建议控制在85度以内AMD显卡可以稍微放宽到90度左右但超过95度就要排查散热或者机箱风道了。这些硬件压测工具虽然看起来是DIY玩家在玩的东西但如果是做图形渲染、3D应用测试的同学这些工具完全可以纳入你的性能测试工具箱用来验证测试环境本身有没有硬件隐患。别等压测报告数据异常的时候查到最后发现是测试机散热出了问题那就太憋屈了。3.5 小程序上线前到底要不要做压力测试还有一个热词是小程序上线前要做压力测试吗还要做什么类似测试。这个问题几乎每次技术评审都会被问。我的答案很直接要但不是只做压力测试。小程序的架构和平常Web系统不太一样除了你的后端接口还有前端渲染、微信网关、云开发资源等环节。你压测的目标主要是后端接口和依赖的第三方服务而不是小程序本身。小程序上线前的完整测试清单我一般建议至少覆盖六类接口性能测试、弱网测试、兼容性测试、回归测试、安全测试、体验测试。接口性能测试就是我们上面说的JMeter压测重点看核心接口的TPS和响应时间。弱网测试用Chrome DevTools或者Charles模拟2G、3G、4G网络看小程序在低带宽和高延迟下是否会出现白屏、超时重试等体验问题。兼容性测试覆盖不同微信版本、iOS和Android不同机型。回归测试确保新功能没有破坏老功能。安全测试关注越权访问、敏感信息泄露、支付链路的安全性。体验测试则要真机去点看看弱网下的加载动画、错误提示是否友好。所以回到那个问题上压力测试只是其中一个环节而且它测的是后端兜底能力。真正决定用户感受的往往是弱网和兼容性这些看起来不起眼的测试。别本末倒置。4. 压测实战中的坑与排查技巧实录最后这一部分我专门聊坑。原因很简单压测这件事理论大家都懂工具也都会开但实际跑起来问题一个接一个。这里列出我这些年亲手踩过、也帮别人排查过的几个高频问题希望你能避开。4.1 线程组配置的几个致命误区先讲一个我觉得最常见的错误线程数误解。JMeter里如果设置1000个线程、Ramp-up时间为1秒那这1000个线程会在一秒内同时启动瞬间产生巨大的冲击。有些同学不知道这一点以为1000个线程就是1000个普通用户慢慢来结果一启动目标服务直接被压到OOM。这就是前面说的线程组配置必须跟测试模型配套。做常规性能测试的时候我一般会把Ramp-up时间设置成总线程数除以5到10让压力缓慢递增便于观察系统性能的渐进变化。第二个误区是循环次数无限大。很多压测脚本喜欢把循环次数设成永远然后用持续时间来控制。这本身没问题但如果你不确定接口正常响应时长就可能出现线程越积越多的情况。举个例子接口批量查询很慢一个请求需要10秒才返回而你的线程并发是200一秒发出200个请求那么10秒内积压了2000个未完成请求。这个现象在JVM层看就是活跃线程数暴涨连接池被打满。所以压测之前先用单线程跑一次确认接口基础响应时间再推算并发量。第三个是缺少断言导致数据失真。这一点前面提到过但值得再强调。我见过有人压测一个登录接口返回的其实是验证码错误提示但因为没有断言JMeter判定为成功。整份测试报告错误率显示0%平均响应时间还特别好看实际上所有请求都在业务层失败了。这种报告拿去给研发会耗费他们大量的排查时间。4.2 结果不准的五个经典排查方向如果压测结果明显不合理比如吞吐量极低、错误率飙升或者响应时间异常我会按顺序排查以下五个方向第一压测机自身是否成为瓶颈。JMeter本身也吃资源单台压测机在大并发下会出现线程阻塞、GC频繁。如果压测机CPU已经接近100%那压力还没发出去就先自损了。解决办法是启用JMeter分布式压测用多台施压机分担压力。注意分布式压测时一定要保证施压机时间同步否则聚合数据会乱掉。第二服务器连接数限制。Linux系统默认的文件描述符上限是1024如果你的并发数超过这个值就会出现socket连接建立失败错误率飙升。压测前记得执行ulimit -n检查一般建议调高到65535以上。第三连接池和线程池大小。数据库连接池配太小的压测一开始数据库连接就被占满后续请求全部排队。常见的HikariCP默认初始连接是10最大连接是10对于并发较高的场景肯定不够。排查方法是压测过程中监控数据库的连接数曲线。第四网络带宽瓶颈。高吞吐压测很容易把测试机或者服务器的网卡打满。如果压测时错误率高且很多错误是超时先看看带宽是不是跑满了。我踩过的坑是一次压测500TPS轻松搞定结果追加到1000TPS时一堆超时最后查出来是压测机和服务器之间只有千兆网卡带宽上限摆在那里。第五防火墙和负载均衡配置干扰。有些环境的防火墙规则会触发连接限速有些负载均衡会话保持配置不对会导致请求集中打到某一台节点上。这些问题不属于应用代码问题但会直接影响压测数据。4.3 我的几组实操建议拿去就能用写到最后分享几条我总结的压测实操建议都是我实测下来觉得性价比很高的习惯性动作。压测前一定先写一个测试方案文档哪怕只有半页纸也要写清楚测试目标、环境拓扑、脚本设计、指标阈值、退出标准。不要小看这半页纸它能避免你和开发、运维之间扯皮。标准要提前达成一致比如响应时间P95小于2秒这个结论是大家一起认可才算数。压测过程中每轮跑完立刻记录时间戳、版本号、配置变更项。你可以建一个简单的压测日志表每轮压测跑完填一行。线上问题排查的时候回头翻这些记录经常能一眼锁定是哪次变更导致的性能回退。这个习惯救过我很多次。压测结束出报告的时候一定要附上环境信息压测机配置、服务器配置、网络环境、并发量、持续时间、被测服务版本。因为没有这些参数别人根本没法评估你这份报告的可信度。你写系统支持1000并发但没说这个1000是用什么规格的机器跑出来的这个结论就是空洞的。最后再讲一个小技巧。压测结果里不要只盯平均值重点看P90、P95、P99这几个百分位数据。平均值很容易被少数慢请求拉高被大量快请求拉低参考价值有限。P99才是那个决定用户极端体验的数字。如果一个接口平均响应时间0.5秒但P99是6秒那你上线后一定有1%的用户在骂娘。性能优化优先压P99比压平均值有意义的得多。测试这个岗位很多时候不是在验证系统有多好而是在系统上线之前帮大家把问题的底线摸清楚。多做一次认真的压测线上少熬一次夜。这套方法论从最开始做性能测试到现在我一直在用希望对你有用。