维护成本高的自动化套件，你会怎么优化？

👔 Raina面试官： 自动化套件维护成本越来越高，跑起来还慢，你会怎么优化？

🙋 候选人：

• 先做资产盘点：统计每条 case 近 6 个月的失败次数、修复耗时、业务价值，画出 ROI 矩阵。
• 低价值高维护的直接删或降级为手工；重复覆盖的合并；UI 断言能下沉到接口层的就下沉。然后做技术优化：并行执行、容器化环境、去掉硬 sleep、引入 API 直接造数跳过 UI 步骤。
• 最后建立准入机制——新 case 必须说明维护 owner 和预期运行频率，防止再次膨胀。

👔 Raina面试官： 删 case 业务方不同意怎么办？

🙋 候选人：

• 用风险说明 + 替代方案：这条 case 测的内容已被接口 case X 覆盖，或近一年零 bug 关联。
• 不是直接删，是先 quarantine 一个迭代观察，没问题再正式移除。让业务参与优先级评审，而不是测试单方面决定。

无代码/低代码自动化工具和传统脚本自动化怎么选？

👔 Raina面试官： 无代码/低代码自动化和传统脚本自动化，你怎么选？

🙋 候选人：

• 低代码适合业务人员参与、场景简单、快速出 Demo的场景，比如录制回放做冒烟、运营同学生成简单校验。
• 脚本自动化适合复杂逻辑、CI 深度集成、版本管理、自定义扩展。低代码工具往往在分支管理、复杂断言、跨系统编排上会碰到天花板。
• 我的策略是：低代码做广覆盖的探索和临时校验，核心回归和门禁一定用代码框架，保证可维护性和 Git 管理。

👔 Raina面试官： 团队非技术背景多，全用低代码行吗？

🙋 候选人：

• 短期可以，长期要有技术同学做平台治理——统一环境、数据、报告，否则会变成一堆跑不通的录制脚本。
• 设定边界：低代码 case 超过一定复杂度必须转代码；定期 audit 低代码资产，清理无人维护的录制。

性能测试、压力测试、负载测试、稳定性测试有什么区别？

👔 Raina面试官： 性能、压力、负载、稳定性测试，很多人混着叫，你怎么区分？

🙋 候选人：

• 负载测试：在预期并发下验证系统是否满足 SLA，看正常负载下的 RT 和 TPS。
• 压力测试：逐步加压到极限，找崩溃点和降级行为。
• 稳定性/ soak 测试：中等负载长时间运行（8-24 小时），看内存泄漏、连接池耗尽、日志打满。
• 性能测试是总称，上面三种都是子类型。面试时能分清场景和目的，比背定义加分。

👔 Raina面试官： 一个项目时间紧，你会优先做哪种？

🙋 候选人：

• 看上线风险：有明确 SLA 先做负载验证；担心高并发崩溃先做压力；怀疑内存泄漏做 soak。
• 大多数互联网项目优先负载 + 短压力，稳定性可以 nightly 长跑。别三种都没做就上线。

性能测试常见的指标有哪些？

👔 Raina面试官： 性能测试常见指标有哪些？TPS、RT、并发数这些你怎么理解和使用？

🙋 候选人：

• 核心指标我关注这几组：吞吐量（TPS/QPS）、响应时间（Avg/P95/P99 RT）、并发用户数、错误率、资源利用率。
• RT 一定要看 P95/P99，平均值会骗人——10 个请求 9 个 50ms、1 个 5s，Avg 还是好看的。错误率在高并发下有没有飙升也很关键。
• 资源侧看 CPU、内存、GC、IO、网络带宽、DB 连接数和慢查询，帮助定位瓶颈在哪一层。

👔 Raina面试官： TPS 越高越好吗？

🙋 候选人：

• 不是。TPS 要在 SLA 约束下看——TPS 很高但 P99 RT 超标，用户体验照样差。
• 还要结合业务场景：支付链路 TPS 不高但 RT 和成功率要求极严；日志上报可以 TPS 高但 RT 宽松。

性能测试的基本流程是什么？

👔 Raina面试官： 性能测试的基本流程是什么？从接到需求到出报告。

🙋 候选人：

• 我通常走这几步：需求分析 → 场景设计 → 环境准备 → 脚本开发 → 基准测试 → 压测执行 → 监控分析 → 报告输出 → 复测验证。
• 需求阶段明确目标和 SLA；场景设计要和业务对齐典型路径和峰值模型；基准测试在单用户下建立 baseline，再逐步加压。
• 执行时同步看服务端监控和 APM，不是只看 JMeter 报告上的 RT。优化后必须复测确认效果。

👔 Raina面试官： 没有独立性能环境怎么办？

🙋 候选人：

• 最低要求：隔离时段 + 限流 + 提前通知，在 test/staging 做相对压测，结论标注环境限制。
• 可以用缩放比例推算，但必须说明假设。推动建设独立 perf 环境，用线上流量回放提升仿真度。

如何确定性能测试的目标和 SLA？

👔 Raina面试官： 性能测试的目标和 SLA 怎么定？不能拍脑袋吧？

🙋 候选人：

• SLA 来源通常是：产品需求、历史基线、竞品体验、技术架构容量规划。
• 具体化到：核心接口 P99 RT = 500、错误率 < 0.1%、峰值并发 X 万。
• 没有历史数据时，先测 baseline，和产品/架构一起定可接受和不可接受两档，上线后再用真实监控校准。

👔 Raina面试官： 产品和研发对 SLA 意见不一致呢？

🙋 候选人：

• 用用户感知数据拉齐：页面加载超过 3 秒跳出率多少、历史故障时 RT 多少。
• SLA 写进发布 checklist，未达标走 risk assessment，而不是测试单方面拍板或放行。

性能瓶颈常见在哪些层面？

👔 Raina面试官： 性能瓶颈常见在哪些层面？CPU、内存、IO、网络、数据库你怎么排查？

🙋 候选人：

• 我会自上而下 + 监控佐证：先看 APM 链路哪段 RT 最长，再对应到具体资源。
• CPU 高：热点代码、正则、序列化、线程竞争。内存：泄漏、缓存过大、大对象 GC。IO：磁盘读写、日志狂打。网络：带宽、DNS、跨机房延迟。数据库：慢 SQL、锁等待、连接池不够、索引缺失。
• 实际项目里数据库和应用层 código 问题最常见，别一上来就怀疑硬件。

👔 Raina面试官： 各项指标都正常但 RT 还是高？

🙋 候选人：

• 查下游依赖和同步阻塞：外部 API 慢、消息堆积、线程池排队、Full GC 间歇抖动。
• 用火焰图和分布式 trace 看时间花在哪，很多时候瓶颈在等而不是算。

慢 SQL 对性能的影响怎么定位和验证？

👔 Raina面试官： 慢 SQL 对性能影响很大，你怎么定位和验证？

🙋 候选人：

• 定位三板斧：慢查询日志 + EXPLAIN 执行计划 + 压测前后 SQL 耗时对比。
• 压测时打开 DB 监控，看 QPS、慢查询数、锁等待。定位到具体 SQL 后，EXPLAIN 看是否全表扫描、索引失效、回表过多。
• 验证优化效果：同样并发下复压，对比 RT、TPS 和该 SQL 的 avg execution time，最好有 APM 的 DB span 数据。

👔 Raina面试官： 开发说 SQL 没问题，你怎么反驳？

🙋 候选人：

• 拿压测期间的实际执行数据：这条 SQL 在峰值时 execution time 多少、扫描行数多少。
• 在 test 库用 EXPLAIN ANALYZE 复现，或让 DBA Review。数据说话比争论有效。

性能测试环境和生产环境差异大，结果可信吗？

👔 Raina面试官： 性能环境和生产差很多，压测结果能信吗？你怎么处理？

🙋 候选人：

• 完全等价很难，目标是趋势可信 + 风险可识别。
• 差异点要文档化：机器规格、数据量、网络拓扑、缓存命中率、中间件版本。结论用相对 baseline 的变化而非绝对 TPS 来表述。
• 尽量缩小 gap：生产数据脱敏采样、同版本配置、独立 perf 集群。上线后用 APM 做对比校准，修正模型。

👔 Raina面试官： 只有一台小机器做压测，结论怎么写？

🙋 候选人：

• 明确写环境限制和推算假设：如单机 TPS 100，生产 10 台理论 1000，打折 70% 估 700。
• 给出 risk items——哪些组件在 perf 环境没覆盖（CDN、WAF、读写分离）。让决策方知道不确定性在哪。

JMeter 和 LoadRunner / k6 等工具你怎么选？

👔 Raina面试官： JMeter、LoadRunner、k6 这些压测工具你怎么选？

🙋 候选人：

• JMeter：开源、生态大、GUI 上手快，适合 HTTP/协议压测，但分布式和资源消耗要调。
• LoadRunner：企业级、协议支持全、报告强大，但贵，传统 IT/金融还在用。
• k6：脚本用 JS、CI 友好、云原生，开发者体验好，适合 DevOps 团队。
• 选型看：预算、团队技能、协议类型、是否要 CI 集成。互联网团队新项目我倾向 k6 或 JMeter + Grafana；已有 LoadRunner 资产就延续。

👔 Raina面试官： 工具会性能测试吗？

🙋 候选人：

• 工具只是执行器，场景设计、监控分析、瓶颈定位才是核心能力。
• 会写 JMeter 脚本不等于会做性能测试——关键是能否从数据里读出 actionable 的结论。