# 1. JMeter 的线程组、Ramp-up、循环次数如何组合模拟目标并发模型？ A Ramp-up 时间越长，越接近瞬时全量并发 B 循环次数越多，并发数越高 C 线程数代表虚拟用户数，Ramp-up 控制加压速度，循环次数与时长决定负载曲线 ✓ 正确答案 D Ramp-up 与并发模型无关，可任意设置
# 2. JMeter 的参数化（CSV/函数）、关联（正则/JSON 提取器）与断言设计要点？ A 参数化保证数据动态，关联提取动态值供后续请求，断言校验结果正确性 ✓ 正确答案 B 关联用 CSV 读取外部数据，参数化从响应提取动态值 C 断言用于生成动态数据，无需校验请求结果 D 参数化与关联功能相同，可相互替代
# 3. 压测中 TPS 上不去、响应时间飙升时的瓶颈定位方法论（应用/数据库/中间件/带宽逐层排查）？ A 逐层排查应用、数据库、中间件与带宽，结合资源利用率定位瓶颈层 ✓ 正确答案 B TPS 上不去可直接断定是应用层问题，无需排查其他层 C 数据库慢查询与 TPS 上不去无关，无需排查 D 带宽占满不会影响 TPS，只影响响应时间
# 4. JMeter 分布式压测中 Master-Slave 的同步误差如何控制，结果如何合并？ A 各 Slave 时钟无需同步，启动时间差异不影响并发模型 B 分布式压测只由 Master 加压，Slave 不参与 C Master 与 Slave 结果需分别展示，不能合并 D 通过 NTP 时钟同步、同时启动与稳态平台期控制同步误差，结果汇总合并统计 ✓ 正确答案
# 5. k6/Locust 以代码方式编写压测脚本相对 JMeter GUI 的优势与适用场景？ A JMeter GUI 脚本可维护性高于代码化脚本 B k6/Locust 代码化脚本可维护、可版本管理、易接入 CI，适合工程化场景 ✓ 正确答案 C 代码化脚本无法编程构造复杂场景，只能简单请求 D 代码化脚本无法对接时序库，可观测性差
# 6. 如何用 Grafana + Prometheus 把压测过程中的服务指标与 JMeter 报告对齐？ A 压测指标与服务指标需分开看，无法对齐 B 压测时间与服务指标变化无需对齐，独立分析即可 C Prometheus 只采集服务指标，无法采集压测指标 D JMeter 指标上报 Prometheus，通过统一时间戳与标签在 Grafana 中与服务指标对齐分析 ✓ 正确答案
# 7. Locust 的协程模型相比 JMeter 线程模型在高并发模拟上的优势与陷阱？ A 协程模型每用户一个线程，单机并发数受限 B Locust 只能用同步阻塞 IO，无法支持高并发 C 协程模型与线程模型并发能力完全相同 D 协程单机可模拟高并发且开销低，但 CPU 密集操作会阻塞协程影响加压 ✓ 正确答案
# 8. 压测结果与业务指标的关联分析，TPS/RT 与订单量、错误率、营收等业务指标如何对照解读？ A TPS 只反映技术能力，与订单量等业务量无关 B RT 与转化率、营收无关，无需关联 C TPS 可折算为业务量，RT 影响用户体验，错误率影响业务成功率，需对照业务解读 ✓ 正确答案 D 压测只需看技术指标，业务指标由运营关注
# 9. JMeter 逻辑控制器与场景建模，IF、While、随机与交替控制器如何组合出真实用户路径，偏差如何评估？ A IF 控制器按概率随机选择请求，模拟用户多样性 B 逻辑控制器只能线性执行，无法模拟分支与循环 C 用 IF/While/随机/交替控制器组合建模真实用户路径，并用生产流量比例评估偏差 ✓ 正确答案 D 场景偏差无需评估，脚本结构即可保证真实
# 10. JMeter 变量作用域与脚本可维护性，用户定义变量、属性与 CSV 数据集的优先级如何影响复用，跨线程组共享如何实现？ A 用户定义变量作用于当前线程组，CSV 变量作用于全局 B 属性只能在线程组内使用，无法跨线程组 C 公共配置用用户定义变量与属性，线程数据用 CSV，跨线程组共享用属性 ✓ 正确答案 D 变量作用域不影响脚本复用与维护
# 11. 压测前的环境预热与数据铺底为什么重要？不做会导致什么误判？ A 预热消除冷启动造成的 TPS 偏低，数据铺底避免数据量不足导致 TPS 虚高 ✓ 正确答案 B 预热与铺底无关紧要，可直接压测 C 数据铺底只影响测试环境，不影响压测结论 D 冷启动的 TPS 偏低是真实性能，无需预热
# 12. 压测脚本中的思考时间(Think Time)与并发模型如何还原真实用户行为？ A 思考时间用于让虚拟用户持续快速发请求，提高 TPS B 思考时间只影响测试时长，不影响并发负载 C 思考时间决定用户操作间隔，影响用户数到请求负载的换算，能还原真实用户行为 ✓ 正确答案 D 思考时间应设为 0，以最快速度压测
# 13. 压测报告的解读，聚合与图表？ A 只需看平均响应时间即可评估性能，无需看分位 B 错误率与 TPS 无关，无需解读 C 聚合报告与图表数据矛盾时以平均值为准 D 结合 TPS/RT 曲线看拐点，结合资源利用率与分位判断瓶颈与稳定 ✓ 正确答案
# 14. JMeter 插件生态，WebSocket/gRPC/HTTP2 采样器如何扩展协议覆盖？ A JMeter 原生支持所有协议，无需插件 B HTTP/2 与 HTTP/1、WebSocket 采样器功能相同 C gRPC 插件基于 JSON 构造请求，无需 proto 文件 D 通过插件管理器安装 WebSocket、gRPC、HTTP2 等采样器扩展协议覆盖 ✓ 正确答案
# 15. 压测脚本的版本管理与团队协作，JMX/代码化脚本的评审、参数化规范与仓库管理？ A 压测脚本一次性使用，无需版本管理与评审 B 脚本纳入 Git 仓库、评审与参数化规范管理，保证可维护可追溯 ✓ 正确答案 C JMX 脚本无法纳入版本管理，只能本地保存 D 参数化规范与仓库管理无关，无需统一
# 16. JMeter CSV 参数化与分布式数据分配，多 Slave 间如何避免参数重复与冲突？ A 各 Slave 从同一 CSV 从头读取，数据重复无影响 B CSV 数据量越小越好，便于分配 C 分布式压测无需担心数据重复，参数天然唯一 D 通过 CSV 共享模式、数据分片或分布式数据源，确保各 Slave 数据不重叠避免冲突 ✓ 正确答案
# 17. 压测工具的选型矩阵，JMeter/Locust/k6/Gatling 在协议支持、脚本语言与可观测性上的取舍？ A 所有压测工具协议支持、脚本语言与可观测性完全相同 B k6 使用 JMX 脚本，可观测性差 C JMeter 协议广、k6 可观测性强且适合 CI、Locust 用 Python 协程、Gatling 用 Scala 高性能，按场景取舍 ✓ 正确答案 D Gatling 用 Python 编写脚本，适合高并发
# 18. JMeter 结果文件与报告生成，结果写入、HTML 报告生成与 CI 归档如何配置，结果文件过大如何处理？ A 通过命令行生成 HTML 报告并在 CI 归档；结果文件过大时可只存聚合或降低采样频率 ✓ 正确答案 B 结果文件只能保存原始样本，无法生成聚合报告 C HTML 报告无法在 CI 中生成，只能手动打开 D 结果文件越大越好，可完整记录所有数据
