解读

面试官通过“区别+案例”的组合，既考察候选人对基础概念的理解深度，也验证其是否能把抽象模型映射到国内真实生产故障。回答时要先给出“可量化、可落地”的定义差异，再用“时间线+指标+根因+代价”四要素讲清案例，最后回扣到测试价值。切忌只背概念或讲国外老旧案例。

知识点

1. 负载测试（Load Test）：在预期并发区间内逐步加压，验证 SLA 是否达标，核心指标是 95RT、TPS、CPU、内存、DB 连接池、线程池、GC 次数等；通过曲线找拐点，不破坏系统。
2. 压力测试（Stress Test）：持续加压到资源耗尽或错误率>5%，观察系统“何时、如何”失效，验证降级、熔断、限流、告警、自愈是否生效；关注错误类型、恢复时间、数据一致性。
3. 国内常见线上故障特征：大促零点、秒杀、热点新闻、短视频爆款、政务系统集中申报、春运抢票、教育 App 选课。
4. 案例叙述模板：背景→峰值 QPS→监控表现→用户感知→业务损失→根因→测试缺失→改进。

答案

负载测试与压力测试的核心区别在“目的”和“停止条件”：
负载测试是“验证系统在目标并发下能否满足 SLA”，压力测试是“找到系统极限并验证失效模式是否可控”。

线上真实故障案例

1. 负载测试缺失案例——2022 年某省“健康码”核酸结果查询接口
   背景：全省统一把 48 小时核酸证明作为公共场所准入条件，早 8 点并发陡增。
   峰值：预估 8 w/s，实际 28 w/s。
   表现：95RT 从 300 ms 暴涨到 9 s，大量 502，市民扫码卡死，地铁滞留。
   根因：网关默认最大连接 2 w，Tomcat 200 线程，Redis 单分片 4 w QPS，均未按真实峰值做负载测试；缓存 key 带时间戳，命中率低。
   业务损失：舆情冲上热搜，政府通报，相关负责人停职。
   改进：后续建立“阶梯 0.5×、1×、1.5×、2×”负载模型，每轮发布前强制回归。

2. 压力测试缺失案例——2021 年“618”某头部电商优惠券系统
   背景：零点发放 2000 万张“满 300 减 50”券。
   峰值：券核销 QPS 12 w/s。
   表现：MySQL 主库 CPU 100%，线程堆积 8 k，券重复扣减，超发 63 万张，资损 3100 万元。
   根因：乐观锁重试 3 次后仍失败就抛异常，压力测试未做到“锁等待超时+库存热点”极限场景，限流开关默认关闭。
   改进：后续用影子表+流量镜像做压力测试，把库存扣减改为缓存队列+异步消息，单节点压到 18 w/s 错误率<0.1% 才上线。

拓展思考

1. 国内云厂商资源弹性快，很多团队把“压测”简化为“加机器”，却忽视代码热点和锁竞争；面试时可补充“纵向扩容无法解决串行瓶颈”的观点。
2. 金融、政务类系统对“错误率=0”更敏感，压力测试要引入“故障注入+数据一致性校验”双指标，而不仅是“能扛多少并发”。
3. 随着 Service Mesh 普及，压力测试的失效模式从“单机线程打满”变成“Sidecar 网络延迟+熔断风暴”，面试中可主动提及 Istio 的压测经验，展示技术前瞻性。