响应时间、吞吐量、并发用户数三者是什么关系？

👔 Raina面试官： 响应时间、吞吐量、并发用户数，这三者啥关系？

🙋 候选人：

• 三者是同一负载下互相制约的三角：并发用户越多，系统排队变长，响应时间往往上升；吞吐量则是单位时间成功处理的请求数。
• 经典关系可记 Little 定律：并发数 ≈ 吞吐量 × 平均响应时间。压测时要固定场景（同一接口、同一数据量），分别看 RT 曲线和 TPS 拐点，不能拿不同口径的数字硬比。
• 业务上还要区分活跃并发 vs 在线用户：1000 人在线可能只有 50 人同时在点，思考时间会把真实并发拉低。指标报告要写清并发模型和 SLA 定义。

👔 Raina面试官： 压测报告里 TPS 高了但 RT 也高了，算通过吗？

🙋 候选人：

• 看SLA 和用户体验：若 P95/P99 已超阈值，即使 TPS 达标也不算通过。
• 应找拐点：在 RT 可接受范围内取最大稳定 TPS，而不是单纯追峰值。

如何做接口基准测试（Baseline）并设定告警阈值？

👔 Raina面试官： 接口 Baseline 怎么做？告警阈值怎么定？

🙋 候选人：

• Baseline 是在稳定环境 + 固定数据集 + 低并发下跑多轮，取 P50/P95/P99 和错误率作为对照基线，版本变更或架构调整后复跑对比。
• 步骤：选核心接口清单 → 隔离依赖（Mock 下游或专用测试库）→ 同脚本跑 30 分钟以上 → 记录 RT、TPS、CPU/内存。基线要带版本号、部署配置、数据规模，否则不可比。
• 告警阈值用基线 + 统计偏差：如 P95 超过基线 20% 或连续 5 分钟错误率 >0.1% 触发 P2；大促前可临时收紧。避免拍脑袋设 500ms，要和历史波动、业务 SLA 对齐。

👔 Raina面试官： 新接口没有历史数据，阈值怎么定？

🙋 候选人：

• 先定产品 SLA（如搜索 P95 <300ms），再用首轮压测结果打 80% 余量作初值。
• 上线后观察 1～2 周真实流量分布，再迭代阈值；初期宁可告警松一点，但要留变更记录。

内存泄漏在 Web / App 上分别怎么发现？

👔 Raina面试官： Web 和 App 上内存泄漏，你怎么发现？

🙋 候选人：

• Web 侧重浏览器堆快照 + 长时间 soak；App 侧重 Profiler 和前后台切换场景，共同点都是看内存是否只升不降。
• Web：Chrome DevTools Memory 做 Heap Snapshot 对比，反复操作同一页面 30～60 分钟，Detached DOM、EventListener 未释放是常见根因。配合 Performance monitor 看 JS heap 曲线。
• App：Android Profiler / Xcode Instruments 的 Leaks、Allocations，重点测反复进出页面、旋转屏幕、推送唤醒。Monkey 或脚本循环操作后对比 PSS/常驻内存，超过基线 15%～20% 要提单。

👔 Raina面试官： 怎么区分泄漏和正常缓存？

🙋 候选人：

• 强制GC 或杀进程重启后，正常缓存会回落，泄漏曲线阶梯式上涨。
• 对比同等操作次数下的内存峰值和回收后残留，必要时让开发做 heap dump 定性。

长连接、大文件上传下载场景的性能怎么测？

👔 Raina面试官： 长连接和大文件上传下载，性能怎么测？

🙋 候选人：

• 长连接看连接保活与资源占用，大文件看吞吐、断点续传和超时策略，不能只测小 JSON 接口。
• 长连接：WebSocket/SSE/心跳接口，模拟 N 万 idle 连接 + 少量突发消息，监控 FD、内存、LB 超时断开。压测工具（JMeter、gatling、自研）要支持连接复用，别每秒重建连接。
• 大文件：分片上传（1MB～1GB）、弱网（丢包/高延迟）、并发多文件。指标：有效吞吐、首字节时间、断点恢复成功率。下载验 Range 请求、CDN 命中、磁盘 IO 瓶颈。边界：超限时拒绝、病毒扫描阻塞时的超时提示。

👔 Raina面试官： 上传一半断网，怎么设计用例？

🙋 候选人：

• 断网后恢复应从已传分片续传，总耗时明显小于重传全量。
• 断言服务端分片状态、客户端本地缓存、重复 uploadId 幂等，避免双份文件。

数据库连接池打满会出现什么现象？测试怎么复现？

👔 Raina面试官： 连接池打满会怎样？你怎么复现？

🙋 候选人：

• 典型现象是接口超时、GetConnection 等待超时、线程堆积，日志里常见 pool exhausted、too many connections，严重时整站雪崩。
• 用户侧：随机 504/500，RT 陡增但 CPU 不一定高。监控侧：活跃连接数顶满 maxPoolSize、等待队列长度持续 >0、DB 侧 connections 接近 max_connections。
• 复现：压测核心写接口 + 人为慢 SQL 或 sleep 事务占住连接不释放；或把 pool max 调小做故障注入。Soak 测试长时间跑也能暴露连接泄漏。验证修复后连接能回收、超时配置合理。

👔 Raina面试官： 和数据库本身连接数打满怎么区分？

🙋 候选人：

• 看报错栈：应用池等待超时在 DataSource 层，DB 拒绝在 JDBC/MySQL too many connections。
• 对比应用监控 pool active 与 DB show processlist 总数，定位是池配置太小还是连接泄漏。

缓存命中率下降会导致什么？你怎么验证？

👔 Raina面试官： 缓存命中率掉了会有啥影响？你怎么验？

🙋 候选人：

• 命中率下降会直接放大 DB 和下游压力：RT 上升、DB QPS/慢查询增多、热点 key 穿透甚至拖垮存储。
• 验证分三层：监控 Redis/Memcached hit rate、evicted keys、内存使用率；应用侧对比 cache miss 日志或 metrics；DB 侧看同一时段 QPS 和 P95 是否同步恶化。
• 主动验证：flush 指定 key 或缩小 TTL 后跑对比压测，或模拟大促前缓存冷启动。还要查原因：key 设计变更、批量失效、热点过期同时 rebuild（缓存击穿）。

👔 Raina面试官： 命中率 90% 降到 70%，一定有问题吗？

🙋 候选人：

• 不一定，要看业务流量结构是否变了（新接口、长尾请求增多）。
• 结合 RT 和 DB 负载一起看；若 RT 稳定、DB 无压力，可能是统计口径或 key 总量变大导致的相对下降。

高峰流量模拟时，思考时间和集合点（Rendezvous）怎么用？

👔 Raina面试官： 模拟高峰流量，思考时间和集合点怎么用？

🙋 候选人：

• 思考时间模拟用户操作间隔，集合点制造同时发请求的尖峰，两者配合才能还原真实高峰而不是虚高并发。
• 思考时间：登录后 random 1～5 秒再点下单，避免所有虚拟用户齐步走。不同业务设不同分布（正态/均匀），否则 TPS 会失真。
• Rendezvous：在秒杀开抢、整点抢券前设集合点，到点同时释放线程，验证库存扣减、限流、排队。注意集合点人数 ≤ 实际可承受并发，并配合 ramp-up 做阶梯加压对比。

👔 Raina面试官： 不设思考时间行不行？

🙋 候选人：

• 可以测系统极限容量，但不代表真实用户行为。
• 报告里要标注 zero think time Stress 模式，和业务高峰 Simulation 模式分开写结论。

性能瓶颈在应用层还是数据库层，你怎么快速判断？

👔 Raina面试官： 瓶颈在应用还是数据库，你怎么快速判断？

🙋 候选人：

• 用分层指标对齐时间窗口：同一请求链路里，哪一层资源先打满、哪一层 RT 占比最大，瓶颈就在哪。
• 应用层信号：CPU 高、GC 频繁、线程池满、接口 RT 高但 DB time 占比低。DB 层信号：active sessions 高、慢查询、锁等待、磁盘 IO util 顶满，应用 RT 里 jdbc/sql 段突出。
• 快速手段：APM 火焰图 + 单接口对比；Mock 掉 DB 看 RT 是否仍高（应用问题），或 EXPLAIN/只读压测 DB 看是否独立变慢。压测时逐步加并发，先拐点的那层优先优化。

👔 Raina面试官： 两边 CPU 都不高但还是慢，呢？

🙋 候选人：

• 查外部依赖、网络、锁竞争、同步等待，常见于下游 HTTP、MQ 或分布式锁。
• 看 trace 的 span 瀑布图，找最长等待段，别只盯 CPU。

线上突然变慢，测试侧能提供哪些排查思路？

👔 Raina面试官： 线上突然变慢，测试这边能帮忙排查啥？

🙋 候选人：

• 测试侧价值是快速复现 + 缩小变更面 + 提供对照数据，不是替运维查日志，而是把问题变成可验证的假设。
• 第一时间：对齐慢的范围（全站/单接口/单地域）、开始时间和发布/配置/大促是否重合。拉 Baseline 对比：同脚本在预发或生产低峰跑一轮，看能否复现。
• 协助定位：回放生产流量样本（脱敏）、对比新旧版本 diff、检查测试环境是否有同样依赖超时。输出：复现步骤、影响接口清单、临时规避建议（降级开关、限流），方便研发定点修复。

👔 Raina面试官： 预发复现不了怎么办？

🙋 候选人：

• 差异通常在数据量、流量级别、生产专属配置。
• 申请只读影子验证或生产小流量拨测，同步核对缓存、DB 索引、第三方配额是否生产独有。

稳定性测试一般要跑多久？关注哪些指标？

👔 Raina面试官： 稳定性测试一般跑多久？看哪些指标？

🙋 候选人：

• 时长看发布周期和风险等级：常规 soak 至少 8～24 小时，核心系统或大版本前常跑 72 小时；要覆盖至少一个 GC 周期和业务日峰。
• 负载用日常峰值 60%～70% 恒定压力，不是极限压测。关注：RT/错误率是否漂移（越跑越慢）、内存/连接数/句柄是否泄漏、磁盘和日志是否撑满。
• 业务指标：MQ 堆积、定时任务漏跑、缓存一致性。通过标准：全程 SLA 达标、无 OOM/重启、资源曲线平稳无单调上升。报告附趋势图比单点截图更有说服力。

👔 Raina面试官： 24 小时太长，能缩短吗？

🙋 候选人：

• 可分段：4 小时快速 soak + 夜间全量，但大促前不能省。
• 缩短时用加速因子（更高并发换时间）要谨慎，可能掩盖慢泄漏，需开发确认等价性。