性能测试面试，面试官真正想听什么？

很多同学以为性能测试面试就是问 JMeter 怎么用。

其实不是。

JMeter 只是工具，面试官真正想听的是：你能不能设计压测场景、看懂指标、定位瓶颈，并推动问题解决。

一、不要只说会用 JMeter

如果面试官问你做过性能测试吗？

差的回答是：

做过，用 JMeter 设置线程数，然后看 TPS 和响应时间。

这个回答太浅。

更好的回答应该是：

我会先明确压测目标，比如验证下单接口在 200 并发下的响应时间和错误率；然后准备测试数据、设计并发模型、配置监控指标；压测过程中关注 TPS、平均响应时间、P95、错误率、CPU、内存、数据库连接数等指标；如果发现瓶颈，会结合日志、数据库慢 SQL、服务器资源和中间件状态继续定位。

这个回答体现的是完整性能测试思路。

二、核心指标一定要讲清楚

性能测试常见指标：

TPS：每秒处理事务数；
QPS：每秒请求数；
响应时间：用户等待时间；
P95 / P99：95% 或 99% 请求的响应时间；
并发数：同一时间发起请求的用户或线程数量；
错误率：失败请求占比；
CPU、内存、磁盘、网络；
数据库连接数、慢 SQL、锁等待。

面试官不是要你背概念，而是看你能不能解释指标之间的关系。

比如：

如果并发继续增加，但 TPS 不再上升，同时响应时间变长，说明系统可能到达瓶颈，需要结合服务器资源、数据库和中间件继续分析。

这类回答就比单独背 TPS 定义更有价值。

三、瓶颈定位要有路径

性能瓶颈定位可以按这个顺序讲：

先看错误率和响应时间，确认问题是否稳定复现；
看服务器 CPU、内存、磁盘 IO、网络；
看应用日志是否有异常；
看数据库慢 SQL、索引、连接池、锁等待；
看 Redis、MQ 等中间件是否异常；
看是否存在外部接口依赖慢；
调整后重新压测验证。

注意，面试官喜欢听“定位路径”，不喜欢听“可能是服务器问题”。

四、性能测试要结合业务场景

不要只说压登录接口、压查询接口。

更好的方式是围绕业务链路讲：

秒杀下单；
支付回调；
订单查询；
库存扣减；
消息通知；
报表查询。

比如下单链路性能测试，要关注：

库存是否超卖；
订单是否重复生成；
支付状态是否一致；
MQ 消息是否堆积；
Redis 缓存是否击穿；
数据库是否出现慢 SQL。

这才像高级测试的思路。

五、一个参考回答模板

可以这样回答：

我做性能测试时，会先明确业务目标和压测指标，比如某核心接口需要在 300 并发下保持 P95 响应时间低于 1 秒，错误率低于 1%。执行前准备测试数据和监控环境，执行中关注 TPS、响应时间、错误率、CPU、内存、数据库连接池、慢 SQL 和 Redis 指标。如果 TPS 上不去或响应时间升高，会结合服务器资源、应用日志、数据库和中间件逐层定位，优化后再复测验证结果。

这个回答基本能覆盖面试官想听的重点。

六、配套刷题和进阶

建议配套看：