当你说“做过性能测试”之后，面试官一定会追问的 4 个问题

 

一、追问一：那你们并发量怎么定？

如果你回答：

❌ 我们一般压 500 / 1000 并发

基本等于自爆。因为这说明：你是在“拍脑袋压测”。

更好的回答方式是： 

　　👉 把问题从技术参数，拉回业务模型。

可以这样说：我们不会直接设并发数，而是先根据业务量级反推真实压力，比如：

• 日活规模

• 峰值在线比例

• 核心行为集中度

举个电商例子：如果活动瞬间 10 万人进入，但真正下单行为可能只有 15%。

那么真正需要验证的不是：

　　系统能不能扛 10 万并发，

而是：

　　👉 能不能扛住 1.5 万的“有效行为洪峰”。

这叫：业务并发，而不是技术并发。

 

二、追问二：你们发现过性能瓶颈吗？

这题是用来区分：👉 工具执行者和👉 问题解决者很多人会开始讲：

• JVM

• GC

• CPU 飙高

但真正有项目经验的人会说：我们遇到的瓶颈，其实很多不是系统资源，而是业务设计问题。

比如：

• 热点库存锁竞争

• 缓存失效导致 DB 放大

• 同步流程过长导致 RT 堆积

重点在于：

👉 性能问题，往往不是“系统扛不住”，而是“业务路径设计不合理”。

这就是从：技术视角升级到系统视角

 

三、追问三：那你们怎么定位问题？

这是面试官在试探：你是不是只会“压完看报表”。

你可以把回答控制在测试视角：我们一般不是直接看资源，而是从业务异常入手。

比如：

• 成功率突然下降

• RT 抖动

• 某条链路变慢

然后再去对齐：

• 应用指标

• 数据库状态

• 连接池使用情况

重点是：

　　👉 先看业务，再看系统。

而不是：

　　👉 先看 CPU。

 

四、追问四：你们做过稳定性测试吗？

因为很多系统：不是被压垮的，而是：👉 跑死的。

你可以举典型场景：

比如：系统在高负载下跑 2 小时没问题，但 6 小时后：

• 线程池耗尽

• 连接泄露

• 队列堆积

这种问题，只能通过长时间运行暴露。

这说明：你理解的是系统“持续能力”，而不是瞬时能力。

 

五、追问五：性能测试的价值是什么？

如果你回答：❌ 找瓶颈，太初级了。

更成熟的回答是：性能测试的核心价值，不是找到系统极限，而是识别业务增长下的风险拐点。

也就是说：

它不是技术工作，

而是：

👉 业务安全工作。