# 1. 负载测试(Load Testing)、压力测试(Stress Testing)、容量测试(Capacity Testing)与稳定性/浸泡测试(Soak Test)四类性能测试的目标、指标与适用场景差异？ A 负载测试面向未来业务增长确定扩容阈值，属于容量规划手段 B 压力测试是在预期负载下验证系统是否满足 SLA，关注响应时间与吞吐量 C 容量测试通过持续加压直至系统崩溃，用于确定系统崩溃点 D 浸泡测试以中等负载长时间运行，主要为了发现内存泄漏与资源长期劣化问题 ✓ 正确答案
# 2. 性能测试指标，响应时间(Response Time)、吞吐量(Throughput)、并发用户数(Concurrent Users)、资源利用率(Resource Utilization)各自的含义和分析方法？ A 并发用户数指单位时间内系统处理的请求数，是衡量承载能力的核心指标 B 在稳定状态下，并发数约等于吞吐量乘以平均响应时间（Little's Law） ✓ 正确答案 C 吞吐量越高，响应时间一定越低，两者负相关 D 资源利用率达到 100% 时，系统吞吐量必然达到上限
# 3. 性能测试工具（JMeter/Locust/k6/Gatling）的选型依据和脚本设计最佳实践？ A JMeter 脚本完全代码化，最适合与 CI 流水线深度集成 B k6 使用 Scala 编写脚本，高性能且自带详细报表 C Locust 基于协程模型，用 Python 编写脚本，适合高并发用户模拟 ✓ 正确答案 D Gatling 通过 GUI 录制脚本，协议支持最全面
# 4. 性能测试场景设计原则，基线、阶梯、峰值、浪涌、长时间浸泡五类场景的覆盖完整性？ A 基线场景以最高负载运行，用于验证系统峰值表现 B 浪涌场景用于模拟突发流量，验证系统应对瞬时冲击与恢复能力 ✓ 正确答案 C 阶梯场景以固定负载运行，为后续对比提供基准 D 浸泡场景用于寻找系统拐点，无需长时间运行
# 5. 性能指标金字塔，业务层（订单/秒）、服务层（TPS/RPS）、系统层（CPU/内存/IO）、资源层（带宽/磁盘）的逐层下钻方法？ A 服务层关注订单/秒等业务结果，是金字塔最顶层 B 资源层关注 CPU、内存、GC 等进程运行状态，粒度最细 C 系统层关注带宽与磁盘容量等基础设施资源 D 逐层下钻是从业务层到服务层再到系统层/资源层，把宏观现象定位到具体组件 ✓ 正确答案
# 6. 如何用排队论(M/M/1)估算单实例 QPS 上限，并将其与压测结果互相验证？ A 实测 QPS 一定高于理论值，因为理论模型忽略了真实开销 B 服务率 μ 等于平均响应时间，到达率 λ 越大系统越稳定 C 当利用率 ρ 趋近 1 时，队列长度与响应时间趋于无穷，故系统稳定运行要求 ρ < 1 ✓ 正确答案 D M/M/1 模型假设服务时间方差很大，适合所有真实系统
# 7. 全链路压测的"流量染色"如何保证压测数据不影响线上报表与计费？ A 压测流量写入真实业务表，再通过报表过滤已产生的数据 B 流量标记在链路中透传，各环节据此将压测数据路由到影子资源并过滤计费 ✓ 正确答案 C 流量染色只作用于入口网关，下游无需感知标记 D 压测数据可以参与计费统计，只需在报表中单独标注
# 8. 性能测试中的'拐点分析'，如何识别系统性能瓶颈并定位到具体组件？ A 拐点指并发数增加而吞吐量同步增长、响应时间稳定不变的临界点 B 拐点分析只关注吞吐量曲线，无需观察响应时间 C 拐点出现时某资源饱和，结合资源利用率曲线可定位瓶颈组件 ✓ 正确答案 D 拐点前系统已进入饱和区，应在此处设置安全水位
# 9. Soak test（浸泡测试）的设计要点，内存泄漏和性能劣化的长时间验证方法？ A 浸泡测试以峰值负载短时间运行，用于发现崩溃点 B 浸泡测试负载越高越好，能更快暴露问题 C 浸泡测试只关注瞬时响应时间，不关心内存趋势 D 浸泡测试监控的是指标随时间的变化趋势，以发现内存泄漏与性能劣化 ✓ 正确答案
# 10. 性能测试的瓶颈定位，自顶向下（业务→服务→系统→资源）vs 自底向上（资源→系统→服务→业务）的取舍？ A 自底向上从业务指标出发沿链路下钻，适合已知资源饱和的场景 B 自顶向下快速扫描资源层，能忽略应用层问题直接定位瓶颈 C 自底向上先看资源层，适合资源明显饱和的场景；自顶向下适合业务异常但瓶颈不明的场景 ✓ 正确答案 D 两种方向互斥，必须二选一，不能结合
# 11. 延迟分布与百分位（P50/P95/P99/P99.9），长尾延迟对用户体验的真实影响与缓解策略？ A 平均延迟最能反映真实用户体验，P99 只代表极端个案 B P50 代表高负载下的极端延迟，是优化重点 C P99 越高越说明系统平均性能好，无需优化 D 长尾延迟由 GC 停顿、锁竞争等偶发阻塞引起，操作涉及多次请求时任一请求长尾都会拖慢整体 ✓ 正确答案
# 12. 性能基线（Baseline）的建立与漂移告警，性能退化如何被自动识别并触发回滚？ A 性能基线取单次压测的瞬时值即可，无需多次统计 B 漂移告警通过将当前结果与基线对比，性能退化超过阈值时触发回滚 ✓ 正确答案 C 性能退化只通过人工抽查发现，无法接入 CI 自动判断 D 环境噪声对性能基线的准确性无任何影响
# 13. k6 与 JMeter 在脚本编写、分布式压测与可观测性集成上的主要差异？ A k6 使用 JavaScript 编写代码化脚本，原生支持 Prometheus 输出与 CI 集成 ✓ 正确答案 B JMeter 脚本完全代码化，可维护性高于 k6 C k6 通过 Master-Slave 架构做分布式压测，需手工管理 Slave D JMeter 原生内置 Prometheus 输出，无需后端监听器
# 14. 性能测试中如何设计"阶梯加压"与"目标达标即停"的自动化判定规则？ A 阶梯加压每级驻留时间越短越好，可快速完成测试 B 阶梯加压逐级增加并发并驻留观察，达标即停通过阈值判断提前结束或熔断 ✓ 正确答案 C 达标即停指一旦出现错误率骤升就立即记录拐点并停止，无需逐步加压 D 阶梯加压无需设置目标负载，只关注最终并发数
# 15. 前端性能测试如何量化，Core Web Vitals 的 LCP/INP/CLS 良好阈值（2.5 秒/200 毫秒/0.1）与 75 分位统计口径，如何用 Lighthouse 与 Lighthouse CI 在流水线中落地性能预算（Performance Budget）门禁并区分实验室与 RUM 数据？ A Web Vitals 取真实用户数据的 75 分位作为评估值，实验室数据用 Lighthouse 用于 CI 门禁 ✓ 正确答案 B RUM 数据在固定环境测得，可重复性好，适合做回归门禁 C Core Web Vitals 的 LCP 良好阈值是 200 毫秒，INP 是 2.5 秒 D CLS 反映交互响应，良好阈值小于 0.1
# 16. 性能测试环境的"等效性"，如何缩小测试环境与生产环境的差异（硬件/网络/数据量/中间件）？ A 测试环境数据量小一些不影响结果，因为性能与数据量无关 B 测试环境网络带宽高能更真实反映生产性能 C 中间件版本差异不影响压测结果，无需同步 D 硬件、网络、数据量与中间件版本差异都会使压测结果失真，需尽量保持一致 ✓ 正确答案
# 17. CPU 密集型与 IO 密集型服务的压测瓶颈识别方法有何不同？ A CPU 密集型服务瓶颈通常表现为 IO 等待时间长、CPU 利用率低 B IO 密集型服务 CPU 利用率高但吞吐量上不去，瓶颈在 CPU C 两类服务的瓶颈识别方法完全相同，无需区分 D CPU 密集型服务以 CPU 饱和度为主，IO 密集型以 IO 等待与连接池排队为主 ✓ 正确答案
