解读

面试官想知道三件事：

1. 你能否把“性能测试”拆成可落地的学习路径；
2. 你能否用“最小闭环”案例让新人两周内真正“跑得起来”，而不是只跑脚本；
3. 你能否把企业级约束（资源有限、业务排期紧、结果要可追溯）考虑进去。
   回答时要体现“培训设计能力 + 性能工程体系化思维 + 落地经验”，避免只说“讲JMeter、搭环境、跑脚本”这种表层操作。

知识点

1. 两周倒排：10 个工作日 = 3 天认知 + 4 天实战 + 2 天复盘答辩 + 1 天缓冲。
2. 认知层：SLA 指标、测试类型、全链路监控、瓶颈分级、报告模板。
3. 工具层：JMeter 脚本、Prometheus+Grafana 监控、Arthas 热点定位、Linux 三件套（top/vmstat/iostat）。
4. 实战层：
   选“登录+首页+下单”最小黄金链路，接口≤5 个，方便新人聚焦；
   数据构造用“10 万用户、100 SKU”规模，既覆盖索引又避免导入耗时；
   场景设计 4 档梯度：基准 50并发→负载 200→压力 500→容量 800，每档 15 min，直接对标 95rt<500ms、TPS≥200、CPU≤70% 的 SLA。
5. 教学层：
   每日“上午讲 1h 理论+演示，下午 3h 真机实操，晚上 1h 教练答疑”；
   用“任务卡”驱动：Day3 交付可运行脚本，Day5 交付首份监控大屏，Day7 交付瓶颈报告，Day9 答辩。
6. 质量门禁：脚本 Git 合并需 Code Review；报告必须含“指标截图+瓶颈证据+优化建议”三段式，否则打回。
7. 风险对冲：提前准备 Docker 镜像与 Mock 服务，避免新人被环境卡 2 天；每 2 天做一次“闪电复盘”，发现掉队立即 1v1 补救。

答案

“我采用 10-4-2-1 倒排模型：10 个工作日拆成 3 天认知、4 天实战、2 天复盘、1 天缓冲。
第一天就让新人拿到 Docker-Compose 一键环境：SpringBoot 订单服务+MySQL+Redis+Prometheus，脚本用 JMeter 现成的‘登录-查商品-下单’黄金链路，接口只有 3 个，降低认知负荷。
第二天讲透 SLA：95rt<500ms、TPS≥200、CPU≤70%，并演示怎么在 Grafana 看板里直接锚这三条线。
第三天下午新人必须交出首版脚本并通过 GitLab Pipeline 的静态检查，提前卡住‘参数化、断言、事务名’三类低级错误。
第四到第七天进入‘四档梯度’实战：50/200/500/800 并发阶梯压 15 min，每档跑完立刻截图“TPS-RT-CPU”三张图，用公司统一模板填《性能测试记录表》，培养“指标→瓶颈→证据”的肌肉记忆。
第八天引入 Arthas 现场定位：让新人把 CPU 飙到 80% 时 trace 到订单服务的‘扣库存 SQL’，再回表看是否有行锁，交付第一份《瓶颈定位报告》。
第九天做 Mini-Retrospect：每人 5 min 讲“我看到的瓶颈、我给的优化、我踩的坑”，评委由架构师+DBA+测试老兵组成，现场打分，低于 80 分强制补课。
第十天缓冲，补数据、补监控、补报告，确保所有人都能独立跑完‘脚本-压测-监控-定位-报告’全链路。
两周后，新人可直接领取生产环境的‘只读’灰度场景任务，主管只需 review 报告，无需再手把手。”

拓展思考

1. 如果业务是微服务+消息队列，可把案例升级成“下单→MQ→库存扣减”异步链路，引入 Kafka Lag 与线程池打满场景，训练新人观察“异步延迟”指标。
2. 两周培训结束后，建立“90 天成长营”：每双周给新人一个真实小需求，持续验收，直到他能独立设计容量模型、完成全链路压测并推动代码优化上线。
3. 培训效果量化：记录新人首次独立任务的“交付周期、报告打回次数、线上性能缺陷数”，用数据反向迭代培训案例，实现“自证有效”的闭环。