性能测试面试题

本文档包含 32 道性能测试相关面试题，覆盖基础概念、负载与压力、稳定性与容量、常用工具、指标分析及优化思路等。

一、性能测试基础（10题）

Q1: 什么是性能测试？性能测试的目标是什么？

答案：

性能测试是在受控负载与环境下，度量系统是否满足约定的容量与体验指标，并暴露瓶颈的测试活动；常见度量包括响应时间、吞吐、错误率以及 CPU、内存、磁盘与网络等资源的利用情况。

目标可以概括为：一是用数据证明是否达到 SLA 或产品目标；二是在可接受成本下找出短板（应用、中间件、数据库或基础设施）；三是为容量与扩容决策提供依据；四是配合调优做前后对比，形成可复现的回归基线。

业界常把「性能」拆成多种测法，侧重点不同：负载测试看预期并发或 TPS 下是否达标；压力测试把负载推到极限之上，观察崩溃形态与恢复能力；容量测试关注数据量、连接数、存储或用户数逼近上限时的行为；稳定性（ soak ）测试用中等负载长时间跑，抓泄漏与缓慢劣化；并发测试强调多线程/多会话下的正确性与锁竞争；配置测试则对比不同部署参数、实例规格或 JVM 选项对结果的影响。实际项目里往往多种类型组合排期，而不是只做其中一种。

Q3: 性能测试的关键指标有哪些？

答案：

响应时间侧不仅看平均值，更要看 P90、P95、P99 与最大耗时，避免被少数慢请求掩盖。吞吐常用 TPS、QPS 或业务上的「单秒成功笔数」表达，需与事务边界定义一致。资源利用率帮助判断瓶颈在算力、内存、磁盘还是网络。并发要区分「在线」「活跃」与「同时发压的虚拟用户」，避免口径混用。错误率与超时率直接关联可用性；若压测中错误上升，吞吐再高也没有发布意义。

Q4: 性能测试的测试流程是什么？

答案：

先对齐业务场景、目标指标与环境差异，写出可执行的测试计划；再设计场景与脚本、准备数据与监控大盘。执行阶段按阶梯或模型加压，同步采集服务端、中间件与客户端日志。分析时把曲线、火焰图或慢查询与业务事件对齐，定位瓶颈后给出优化项并安排复测，最后把结论、风险与遗留问题写进报告，脚本与数据版本纳入配置管理，便于下次一键复跑。

Q5: 如何制定性能测试计划？

答案：

从需求或 SLA 里抽出可量化指标和通过线，列出必须覆盖的核心链路及「可砍」的次要范围。选定测法（负载/压力/稳定性等）、工具与发压机数量，评估环境是否与生产同代、数据是否脱敏且体量够用。排期上预留调优与复测缓冲，并写明风险：例如环境偏小只能做趋势验证、缺生产流量模型则结论带假设。成功标准建议写清：在什么负载下哪些指标的百分位与错误率必须满足。

Q6: 如何设计性能测试场景？

答案：

先按业务价值与流量占比挑出关键场景，再为每个场景定义思考时间、步间比例与混合比例，避免「全员只点登录」。负载模型可以是阶梯、脉冲或按历史曲线回放。数据要参数化，覆盖冷热数据与幂等边界，防止缓存把问题藏住。脚本需做基线校验（断言业务成功、关联动态 token），并在正式压测前小规模试跑，确认监控与日志采样不会成为瓶颈。

Q7: 性能测试中如何确定测试数据量？

答案：

优先参考生产或预发的数据量级与增长曲线，没有生产数据时可用统计模型估算。数据量要服务于测试目标：测大表扫描就与行数、索引选择性相关；测缓存就要有一定命中率梯度。注意隐私与合规，脱敏后仍要保持分布特征。准备策略上可分层：基础种子数据、增量造数、跑后清理或快照回滚，避免脏数据让下一轮结果不可比。

Q8: 性能测试环境的要求是什么？

答案：

环境应独占或与干扰源隔离，避免他人作业把曲线弄脏。硬件与软件版本尽量贴近生产，至少做到「同一代架构」；若缩小规格，要在报告里声明结论外推范围。网络拓扑、TLS、CDN 与生产不一致时，单独记录对延迟的影响。监控与日志采集要提前部署好，采样间隔与保留时长要够复盘一次完整压测窗口。

Q9: 性能测试中如何模拟真实负载？

答案：

用埋点、网关日志或 APM 还原请求比例、峰值窗口与思考时间；混合场景比单接口循环更接近真实。可对热点用户、热点商品做数据倾斜，必要时用限流或故障注入模拟弱网。注意发压机自身 CPU、带宽与文件句柄上限，否则先瓶颈在脚本侧。若生产有定时批处理，也要在模型里留出背景负载，否则结果偏乐观。

Q10: 性能测试中常见的性能问题有哪些？

答案：

典型有：响应时间长尾变大、吞吐上不去同时错误率抬头；CPU 打满或 iowait 飙高；内存持续上涨或 GC 停顿过长；连接池、线程池或队列堆积；数据库慢 SQL、缺索引、锁等待与 N+1 查询；缓存穿透、击穿、大 key 或不一致；以及同步调用链过长、第三方超时未熔断等。定位时优先用监控分域缩小范围，再下钻到具体组件。

二、负载测试（5题）

Q11: 什么是负载测试？负载测试的目标是什么？

答案：

负载测试是在预期或略高于日常的负载水平下运行系统，观察是否仍满足性能与正确性要求，一般不以「压垮」为目的。

目标包括：验证在约定并发或 TPS 下响应时间与错误率是否达标；观察资源使用是否健康、有无隐性排队；为容量规划提供「舒适区」数据；并在版本对比中做回归，防止优化引入退化。

Q12: 如何设计负载测试场景？

答案：

确定目标 TPS 或并发区间后，设计阶梯或稳定平台阶段，每段有足够采样时间。场景组合按业务比例混合，关键事务带校验断言。负载曲线可模拟早高峰、晚高峰或活动脉冲。数据与账号池要可轮换，避免单点热点偏离生产。最后预留一段「保温」阶段，观察稳定态下的资源与队列是否仍平稳。

Q13: 负载测试中如何确定并发用户数？

答案：

可从运营数据取峰值在线、活跃会话与下单 QPS，再按「每个用户平均请求间隔」反推需要的虚拟用户数，注意 Little 定律里到达率、并发与响应时间的关系。没有历史数据时，从低并发逐级加，找到指标刚触线的区间作为参考上限。口径上写清：是协议并发、业务并发还是仅登录态会话，避免面试或报告里各说各话。

Q14: 负载测试的执行策略是什么？

答案：

常用渐进加压：每阶观察曲线是否单调恶化，并保留可重复的起停脚本。可做一段恒定负载 soak 数小时，看是否有缓慢泄漏。峰值段可短促验证尖峰承接能力。混合场景与单场景分开跑一轮，便于归因。全程自动打点版本号、数据快照与配置，保证问题可复现。

Q15: 负载测试中如何分析测试结果？

答案：

把响应时间分布、吞吐与错误率放在同一时间轴上看是否同步恶化；对照 CPU、内存、GC、磁盘与网络，找最先饱和的资源。对慢事务抽样做链路追踪或 SQL 剖析。关注队列长度、线程池拒绝次数等先行指标。结论里区分「未达标」与「达标但余量不足」，并给出下一优先级的优化假设与复测项。

三、压力测试（5题）

Q16: 什么是压力测试？压力测试的目标是什么？

答案：

压力测试把负载推到高于设计容量或资源极限，观察系统在崩溃边缘的行为：是优雅降级、排队超时，还是雪崩式失败。

目标包括摸清极限吞吐与拐点、验证熔断限流与降级是否生效、观察恢复时间与数据一致性，以及为应急预案提供「最坏情况」参考。执行前务必确认环境隔离与数据可恢复，避免影响共用资源。

Q17: 压力测试与负载测试的区别是什么？

答案：

负载测试多在「预期区间内」验证是否达标；压力测试刻意超载，关注失效模式与恢复能力，对业务风险的问法不同。

两者常串联：先负载证明日常可信，再压力找边界。

维度	负载测试	压力测试
负载水平	预期或略高	明显高于设计容量
主要目的	是否满足指标	极限、降级与恢复
通过标准	SLA 内稳定	行为可接受、可恢复
风险侧重	性能不足	崩溃、数据损坏、级联故障

Q18: 如何设计压力测试场景？

答案：

在负载模型基础上继续加压，或缩小关键资源（连接数、堆内存、带宽）制造瓶颈。可设计尖峰脉冲、突增并发或大数据突发写入。对单点依赖（支付、短信、风控）可配合 mock 或故障注入，否则容易压到第三方合同上限。场景脚本里仍要带业务断言，区分「请求成功但业务失败」与真成功。

Q19: 压力测试中如何确定压力水平？

答案：

以基准或负载测试结果作起点，按固定步长或百分比递增，直到错误率、延迟或资源指标突破预设红线。也可直接瞄准「生产峰值的两倍」等业务给定目标。记录每一档的配置与曲线，便于复盘拐点。注意发压机与网络不要先于被测系统饱和。

Q20: 压力测试中如何观察系统行为？

答案：

同步看应用指标、系统指标与中间件指标：线程栈、连接池、队列深度、慢查询与锁等待。日志级别在高压时可适当收敛，但关键错误码要保留。数据库侧关注复制延迟与磁盘队列。必要时抓短时 heap dump 或 profiling，但要在变更窗口内并做好回滚预案。观察不仅看「崩没崩」，还要看崩后自愈与数据是否一致。

四、稳定性测试（3题）

Q21: 什么是稳定性测试？稳定性测试的目标是什么？

答案：

稳定性测试（ soak ）通常在中等负载下长时间运行数小时到数天，用来发现内存泄漏、句柄泄漏、磁盘涨满、日志打爆或性能缓慢衰减等问题，这些问题在短时压测里不易暴露。

目标是证明系统在持续压力下仍可靠，资源曲线趋于平稳，错误率不随时间爬升，并在测试结束后能恢复到正常水平。

Q22: 稳定性测试的执行策略是什么？

答案：

选定与生产峰值成一定比例的平台负载持续运行，避免一开始就用极限压力掩盖问题。按固定间隔做健康检查与小规模业务抽样校验。监控磁盘与日志分区容量，配置告警阈值。结束前后各做一次全量或抽样功能验证，确认长期运行没有悄悄写坏数据。

Q23: 稳定性测试中如何检测内存泄漏？

答案：

持续观察进程常驻内存与堆使用是否单调上升且 GC 无法回收。结合 JVM 的 GC 日志、native 内存跟踪或 jmap/MAT 做堆对比，查找增长最快的对象类型。对非 Java 服务用对应分析器或 OS 级指标。注意区分「缓存按设计变大」与真泄漏：前者应有上限或淘汰策略。定位后交由开发修复并安排同场景复跑直至曲线平坦。

五、容量测试（2题）

Q24: 什么是容量测试？容量测试的目标是什么？

答案：

容量测试关注系统在「数据量、用户数、连接数或存储」接近或达到规划上限时的表现，例如单表十亿行、百万在线会话、对象存储接近配额等。

目标是给出最大安全容量、超限时的报错是否友好、扩容路径（分库分表、加节点）是否有效，并为采购与配额设置提供数字依据。