美团测试面试题

本题清单

给美团 App 搜索模块设计测试用例
JMeter 关注哪些指标？如何定目标 QPS？
组合推荐策略（多标签 + AB）怎么测准确性？
埋点漏了但后端数据还对，怎么发现与处理？
在微信支付上增加红包抵扣，测试点怎么拆？
秒杀三端流量如何设计压测比例？
用户反馈价格不对，如何判断缓存还是 DB？
请求经 5 个环节结果错了，怎么逐层验证？
灰度发布平台动态流控，怎么验证？
GET/POST 区别？都幂等吗？Redis 为何比 MySQL 快？
订单超时未支付自动取消，怎么设计测试？
多张优惠券叠加规则如何用决策表设计用例？
主从库延迟可能导致什么测试误判？怎么规避？
外卖/订单状态推送（推送丢失或乱序）怎么测？
地图选点/配送范围相关功能测什么？
大促前你会做哪些质量保障动作？

1. 给美团 App 搜索模块设计测试用例

参考答案：

搜索是「功能 + 相关性 + 数据」三位一体。

功能
关键词搜索、历史、热榜、联想词、纠错（「美券」→「美团」）、空结果推荐、筛选（价格/距离/品类）、排序、分页/加载更多、清除历史。

相关性与业务规则（美团特色）
距离、营业状态、配送范围是否影响展示；广告与自然结果间隔规则；敏感词无结果或替换。

性能体验
首屏耗时、联想防抖、弱网、快速输入取消请求（防止乱序返回覆盖）。

数据与埋点
曝光、点击、query、策略 ID；无结果率监控。

安全兼容
注入、越权看隐藏商家、多机型。

策略：接口测规则与排序稳定性；真机测体验；线上看无结果率与点击率异常。

2. JMeter 关注哪些指标？如何定目标 QPS？

参考答案：

施压侧：并发线程、Ramp-up、吞吐量、错误率、平均/中位数/TP90/TP99 响应时间。
系统侧：CPU、内存、IO、网卡、GC、线程池队列、DB 连接、慢查询、下游 RT。
业务侧：成功率按业务码、核心订单是否一致。

定目标 QPS

取线上历史峰值（或大促预测）。
乘冗余系数（常见 1.5～2，看业务容忍）。
对照 SLA（如 TP99 < 200ms、错误率 < 0.1%）。
阶梯加压找拐点，容量结论写清「在何种机器规模下」。

讲优化时：必须前后两次同条件对比，例如「串行改并行后 TP99 从 800ms 到 300ms，QPS 提升 X%」。

3. 组合推荐策略（多标签 + AB）怎么测准确性？

参考答案：

4. 埋点漏了但后端数据还对，怎么发现与处理？

参考答案：

发现

日常：客户端埋点量 vs 服务端业务量对账（允许采样误差带宽）。
异常：某事件量断崖而订单量正常。
自动化：关键页面 UI 测附带埋点字段校验；发包前用校验平台扫。

可能原因
客户端未调用、被开关关掉、采样率变更、字段改名、网络失败未补传、WebView 桥失败、隐私权限拒绝。

处理
紧急修客户端；评估历史能否补报；业务报表切换可靠数据源；发版增加「核心埋点门禁」。测试用例要覆盖「无网发送失败后的缓存补传」。

5. 在微信支付上增加红包抵扣，测试点怎么拆？

参考答案：

这是典型的组合爆炸，要用决策表降维。

维度：订单金额、红包面额/门槛、是否可叠加、支付渠道、退款、并发。

重点用例：

红包刚好抵扣、超额抵扣（实付 0）、不满足门槛不可用。
微信支付成功/失败/重复回调与红包冻结/解冻一致。
部分退款、全额退款后门款与红包回退规则。
活动过期、红包核销库存、一红包两单并发核销。
账务：订单实付 + 红包 = 应付；三方流水可对上。

P0 是资金一致与核销幂等。

6. 秒杀三端流量如何设计压测比例？

参考答案：

拉线上或大促预案的端占比（如 App 60% / 小程序 30% / 服务号 10%）。
JMeter/自研按比例混合线程组，请求头带端标识。
行为差异：小程序冷启动更慢、服务号可能经不同网关——模型里体现。
场景分段：预热、开售尖峰、售罄尾部。
校验：总体库存、各端成功率是否符合限流策略（是否某端被误伤）。

7. 用户反馈价格不对，如何判断缓存还是 DB？

参考答案：

同一时刻三方比对：

App/接口返回价。
Redis（或本地缓存）中的价格 key。
DB 商品表价格。

现象	更可能原因
DB 已新，缓存旧，接口旧	缓存未失效/TTL 过长
缓存新，DB 旧	写缓存成功写库失败或读了错误源
三者一致但用户觉着错	优惠/会员价/配送费展示误解

构造用例：改价后读；主动失效；双写延迟窗口；多级缓存（本地+Redis）一致性。产品若允许秒级延迟，要在预期里写明。

8. 请求经 5 个环节结果错了，怎么逐层验证？

参考答案：

用同一 TraceId/业务单号把五环串起来：客户端 → 网关 → 服务 → 下游 → 存储。

方法：

从存储结果反查，看错误最早出现在哪一层出参。
每一层对比入参、出参、时间戳、错误码。
若某层入参已错，问题在上游；入参对出参错，问题在本层。
无 Trace 时用时间对齐 + 用户 ID + 手机号等业务键拼时间线。

这体现你具备线上排障的系统方法。

9. 灰度发布平台动态流控，怎么验证？

参考答案：

比例正确：1% / 10% / 50% 流量是否落在新版本（用版本标或实验标统计）。
切换及时：调高/调低/回滚是否分钟级生效。
一致性：同用户多次请求是否粘滞（按设计）。
监控联动：错误率超阈值是否自动停量。
负向：错误配置（总和超过 100%、空版本）的拦截。
业务验证：灰度用户打到新逻辑，对照用户仍旧逻辑。

10. GET/POST 区别？都幂等吗？Redis 为何比 MySQL 快？

参考答案：

GET vs POST

语义：GET 获取；POST 提交/创建。
参数位置、缓存、长度限制、浏览器历史记录行为不同。
测试上：GET 更要关注缓存与安全（敏感信息勿放 URL）；POST 更要关注重复提交。

幂等

HTTP 语义上 GET/PUT/DELETE 应幂等，POST 默认不幂等。
实现上 POST 可通过业务幂等键变成幂等。测试必须按真实实现测，不能只背语义。

Redis 更快的常见原因
内存访问 vs 磁盘；数据结构简单；单线程执行命令避免锁竞争；无复杂查询优化器开销。但也要说：不合适的大 key、持久化、网络 RTT 也会慢——结合你们踩过的坑更佳。

11. 订单超时未支付自动取消，怎么设计测试？

参考答案：

功能：到点取消、取消后库存/券回滚、状态机不可再支付。
边界：超时前 1 秒支付成功应成交；超时后支付回调到达要拒绝或走异常单。
时间：不要傻等 30 分钟——调短配置、或 mock 时间、或手动触发超时任务。
并发：超时任务与用户支付同时发生的竞态。
消息：取消通知是否发送；重复调度是否幂等。
观测：超时任务积压导致「该取消未取消」。

12. 多张优惠券叠加规则如何用决策表设计用例？

参考答案：

先列出条件：券类型（满减/折扣/配送券）、是否互斥、门槛、平台券 vs 商家券、是否与活动同享。

用决策表列出组合与预期实付，避免口语化遗漏。重点测：

互斥券不能同用
叠加顺序（先商家后平台等，以 PRD 为准）
门槛临界
退款后门款回退顺序
券核销库存并发

把表直接给面试官看，结构感很强。

13. 主从库延迟可能导致什么测试误判？怎么规避？

参考答案：

误判：写后立刻读从库，断言失败（其实主库已对）；或测试以为失败实则延迟。线上用户也可能读到旧数据。

规避

强一致读走主库或读自己写。
自动化断言加短重试，或查主库。
专门测「延迟窗口内的产品预期」。
注入延迟，验证业务是否可接受。

14. 外卖/订单状态推送（推送丢失或乱序）怎么测？

参考答案：

状态如：已下单 → 商家接单 → 配送中 → 完成。

测：

正常顺序推送与端内展示
乱序到达（先「配送中」后「接单」）客户端/服务端是否纠正
丢失补推、冷启动拉取最新状态
推送通道失败时的轮询兜底
多端（用户/骑手/商家）一致性
勿扰与权限关闭时的降级

15. 地图选点/配送范围相关功能测什么？

参考答案：

定位权限拒绝/失败
选点在范围内/边界/范围外
地址解析错误、POI 搜索
跨城、坐标系（GCJ-02 等）偏差导致「看起来在店门口实际判外」
弱网下地图加载
配送费随距离变化的计价

边界点与围栏算法要用已知坐标集做自动化断言。

16. 大促前你会做哪些质量保障动作？

参考答案：

核心链路用例冻结与加跑。
全链路/核心接口压测与容量评估。
限流熔断降级预案演练。
监控与告警阈值检查、值班表。
开关与回滚演练。
数据对账与影子链路。
变更冷冻期：大促前停高风险发布。

按时间线讲（T-14/T-7/T-1）更有画面。

速查： 多练「搜索/推荐/交易可验证指标、压测与灰度」；少踩「「感觉准」；埋点不会对账」。