解读

面试官真正想考察的是：

1. 在资源受限、时间受限的“真实战场”里，性能测试工程师能否用“业务+技术+风险”三维视角快速收敛测试范围；
2. 能否把“不可量化”的优先级问题转化为“可量化、可沟通、可落地”的决策逻辑，并给出让研发、产品、运维都信服的结论；
3. 是否具备“用最小成本覆盖最大风险”的意识，而不是“拍脑袋”或“照搬模板”。

因此，回答必须体现：

• 对业务流量特征、用户痛点、营收链路的高度敏感；
• 对系统架构瓶颈、历史故障、SLA 违约点的快速识别；
• 对“单场景覆盖度”与“交叉叠加风险”之间权衡的严谨推演。

知识点

1. 业务黄金链路：能够直接带来收入或影响品牌口碑的最短请求路径，如电商“下单-支付-减库存”、金融“转账-入账”、短视频“刷新-播放-广告曝光”。
2. 高频+高并发接口：日活占比 Top 3 的读接口或写接口，通常决定整体吞吐量天花板。
3. 历史故障热点：近 6 个月内 P3 及以上故障中，因性能导致的比例 >50% 的模块。
4. SLA 临界指标：合同或对内承诺中“一旦超时即赔偿”的阈值，如 99.9% 请求 ≤500 ms。
5. 资源瓶颈模型：CPU 密集型、IO 密集型、线程阻塞型、锁竞争型、缓存穿透型，不同模型下同样 TPS 对硬件消耗差异 3~10 倍。
6. 容量换算公式：峰值 QPS = 日活 × 人均访问次数 × 峰值系数 / 86400；峰值系数国内互联网一般取 38，大促取 1530。
7. 风险矩阵：纵轴“发生概率”，横轴“业务损失”，高概率×高损失场景必须优先压测。
8. 快速验证策略：单场景压测 ≤2 小时可完成基线采样，混合场景 ≥8 小时才能暴露锁/缓存一致性隐患，排期紧张时优先单场景。

答案

面对“只能选 3 个”的硬约束，我会用“三步量化打分法”在 30 分钟内完成优先级评估，并输出可审计的评分表，步骤如下：

第一步：建立候选池

1. 拉取近 30 天生产 access log，按接口维度聚合 PV、UV、错误码 5xx 次数、P99 延迟、收入转化事件（下单、支付成功、广告曝光）数量；
2. 交叉近 6 个月故障平台记录，过滤出“因性能导致”的故障 Top 10 接口；
3. 与产品、运营、运维开 15 分钟站会，确认未来 3 个月业务重点（如 618 大促、会员日、红包活动），补充潜在热点接口。
   最终得到 10~15 个候选场景。

第二步：四维量化打分（百分制）
A. 业务损失权重（40 分）

• 直接关联收入：每 1% 请求失败或超时预计损失金额，按万元计，≥50 万元得 40 分，线性递减。
  B. 流量权重（25 分）
• 峰值 QPS 占比：候选接口峰值 QPS / 全局峰值 QPS，≥30% 得 25 分，线性递减。
  C. 历史故障权重（20 分）
• 近 6 个月因性能故障次数，≥3 次得 20 分，2 次 15 分，1 次 10 分，0 次 0 分。
  D. 技术风险权重（15 分）
• 是否跨多个微服务、是否含分布式事务、是否依赖缓存或外部支付渠道，每满足 1 项加 5 分，封顶 15 分。
  每项得分由测试、研发、运维三方共同确认，避免“自说自话”。

第三步：收敛与验证

1. 按总分降序取 Top 5，再用“资源消耗/验证效率”二次筛选：
   • 若某场景需要准备 5000 万条铺底数据、构造 200 个 SKU 库存才能压测，且准备时间 >1 人日，则降级；
   • 若某场景可通过流量回放直接放大，无需额外脚本开发，则加分。
2. 最终输出 3 个核心场景，并给出“风险兜底”说明：
   • 若后续时间有 1 天富余，立即补充第 4 场景混合压测；
   • 若 3 场景中任一出现“RT 上涨 30% 或错误率 >1%”即触发阻塞流程，暂停上线。

示例结论（某社区电商项目）：

1. 下单接口（业务损失 40 + 流量 23 + 故障 20 + 技术 15 = 98 分）
2. 刷新推荐Feed接口（业务 35 + 流量 25 + 故障 15 + 技术 10 = 85 分）
3. 优惠券领取接口（业务 30 + 流量 20 + 故障 20 + 技术 10 = 80 分）

以上 3 个场景即可覆盖 72% 的峰值流量、85% 的收入链路、100% 的历史性能故障点，且脚本可在 4 小时内完成开发，满足“排期紧张”约束。

拓展思考

1. 如果老板临时加需求“再砍 1 个场景只剩 2 个”，怎么办？
   把“业务损失”权重提高到 60 分，并引入“降级预案成熟度”作为负向扣分项：有完整降级开关的场景可扣减 10 分，从而把“可降级”场景筛掉，留下“不可降级”的高损失场景。

2. 如何在同一套量化框架里兼顾“稳定性”与“容量”两类目标？
   稳定性更关注“长时间低资源波动”，可把“技术风险权重”替换为“资源泄漏风险分”，通过 8 小时 soak 测试小样本预跑，把内存增长 >200 MB 的场景强制置顶。

3. 如果系统采用 Serverless 弹性架构，峰值理论上无限扩容，还需要压测吗？
   此时瓶颈转移到“下游 RDS 最大连接数”“第三方支付并发限额”“缓存带宽”，优先级评估要把“外部配额”作为第一约束，重新计算“业务损失权重”，避免盲目自信。