京东测试面试题
本题清单
- 电商下单全链路你会怎么测？
- 库存超卖怎么测？如何设计压测与校验？
- 促销叠券（满减 + 券 + 京豆）规则怎么设计用例？
- 京东物流「配送时效」相关功能测什么？
- 大促前质量保障你会做什么？
- 订单状态机非法迁移怎么测？
- 支付回调延迟/重复怎么测？
- 主从延迟导致「刚下单查不到」怎么验证与规避？
- 购物车/结算页价格不一致怎么排查？
- 接口幂等你怎么设计和验证？
- 灰度发布（按用户/门店）怎么测？
- 售后（退款/退货）链路测试重点是什么？
- 缓存击穿/雪崩在商品详情场景怎么测？
- 数据对账：订单、库存、资金三方不一致如何发现？
1. 电商下单全链路你会怎么测？
考察意图：看你会不会把京东式交易拆成可断言的链路，而不是只测「能下单」。
参考答案：
我会先跟面试官对齐边界：自营还是三方、是否含促销、扣库存发生在下单还是支付。然后按链路分层。
1）主链路切段
选品 → 加购/立即购买 → 结算（地址、运费、优惠）→ 提交订单 → 支付 → 库存落账 → 履约出库通知。每一段都有独立断言，避免「最后红了不知道哪坏」。
2）按优先级组织
| 优先级 | 典型场景 | 为何 |
|---|---|---|
| P0 | 主成功流；库存不足拦截；支付成功后订单态正确；取消未支付回滚库存 | 资损与履约底线 |
| P1 | 限购、区域不可售、发票、自营/三方差异、优惠叠加 | 高频业务规则 |
| P2 | 发票种类、备注、多地址簿体验 | 可迭代 |
3）非功能
大促峰值下提交成功率；重复点击提交的幂等；弱网「半成功」（超时后重试是否双单）。
4）验证手段
- 接口自动化覆盖状态迁移（待支付→已支付→出库）。
- 造数工厂：固定可售库存、可控促销。
- 支付/库存可 Mock，但至少一条走联调/预发真链路。
- 对账：订单成功数 vs 库存扣减流水。
常被追问
扣库存在下单还是支付？→ 答你们系统策略，并说明测试点不同：下单扣要测取消回滚；支付扣要测预占超时。
2. 库存超卖怎么测？如何设计压测与校验？
参考答案：
超卖定义先说清：卖出成功量 > 可售库存。京东面试想听「并发 + 最终对账」，不是口头说「加锁」。
实验设计
- 造数：SKU 可售库存固定为 N（例如 10）。
- 并发：用 JMeter/Locust 打 >N 的下单/秒杀请求（如 200 并发）。
- 断言：
- 业务成功单数 ≤ N；
- 库存最终 ≥ 0，无负库存；
- 超卖请求失败码符合约定。
- 变体必测：
- 预占后未支付超时回滚，再被别人抢走；
- 支付成功回调晚到；
- 取消订单回补后能否再次售出。
压测与校验的关系
压测看系统在高压下是否仍守住「成功数≤N」；校验看 DB/缓存/流水三方一致。只会压不会对账，说明不了没超卖。
常被追问
Redis 扣减和 DB 扣减不一致怎么办？→ 讲以哪边为准、补偿任务、测试如何制造不一致再验补偿。
3. 促销叠券（满减 + 券 + 京豆）规则怎么设计用例？
参考答案：
计价是资损重灾区，我会用决策表而不是穷举感觉。
维度
活动类型（满减/满件）、券门槛与品类限制、互斥规则、京豆抵扣上限、运费券是否可叠加、生效时间窗。
典型用例
- 单活动：达门槛/差 0.01 元未达。
- 两活动互斥：只生效规则声明的那一个，UI 与接口一致。
- 三方叠加触及封顶。
- 过期券、已核销券、跨店券误用。
- 精度：分进位、四舍五入，展示价与实付一致。
断言三连
结算页展示价 = 提交订单金额 = 支付金额 = 订单明细拆分之和。再补一条：抓包改价应失败。
收尾：规则变更必须进回归集；大促改价配置要有预发演练单。
4. 京东物流「配送时效」相关功能测什么？
参考答案：
时效 = 规则引擎 + 地址/仓数据 + 多端展示，测「算得对、展示一致、临界正确」。
功能
- 地址命中仓与配送范围（含偏远、自提点）。
- 截单时间临界：截单前 1 分钟 / 后 1 分钟。
- 节假日、运力紧张时的降级文案是否按开关出现。
一致性
商详、结算、订单详情三处时效文案与时间点一致，避免「详情写次日达、结算变两日达」。
数据与缓存
时效规则变更后缓存是否刷新；错误地址是否有兜底提示。
接口测引擎输出；端上测文案与刷新；监控「时效投诉」与配置变更的关联。
5. 大促前质量保障你会做什么？
参考答案：
大促不是多写几条用例，而是降风险的作战计划。
- 收口范围：交易、支付、库存、结算、履约入口进红线；边缘需求砍或延后。
- 压测：按历史峰值 × 冗余系数阶梯加压，写清「多少机器规模下的结论」，找拐点而非压垮才停。
- 预案演练：限流、降级、熔断、开关；回滚演练至少一次。
- 可观测：下单成功率、支付成功率、库存失败率、对账差异告警。
- 门禁：冒烟自动化 + 发布 checklist；配置变更双人复核。
一句话：可回滚、可观测、可熔断，比「用例 100% 执行完」更重要。
6. 订单状态机非法迁移怎么测？
参考答案：
先画出合法边：待支付 → 已支付 → 出库 → 签收；以及取消、关闭等分支。再系统测非法边。
方法
- 对每个状态调用「下一步允许/不允许」的接口。
- 并发：支付与取消 race、重复支付回调。
- 消息乱序：出库消息早于支付成功（若架构可能）。
断言
非法迁移被拒且有明确错误码；DB 状态与流水一致；不出现「已取消却扣了库存」的悬挂。
把非法迁移表做成自动化，比零散手工点更靠谱。
7. 支付回调延迟/重复怎么测？
参考答案：
支付是异步结果，测试重点是最终一致 + 幂等。
| 场景 | 测什么 |
|---|---|
| 延迟回调 | 预占是否超时回滚；晚到回调后是否正确扣库存/记成功 |
| 重复回调 | 同一支付单号多次通知，订单只成功一次、不重复记账 |
| 乱序 | 先关单再回调，走拒绝还是人工核对，行为符合设计 |
手段：Mock 支付网关，可控延迟与重放。联调环境再跑一条真实渠道沙箱（若有）。
常被追问：回调丢了怎么办？→ 主动查询对账任务；测试要覆盖查询补偿路径。
8. 主从延迟导致「刚下单查不到」怎么验证与规避？
参考答案：
现象：写主、读从，提交后立刻查订单列表为空，用户以为失败再下一单。
怎么测
- 测试环境制造复制延迟（停从库复制/人为延迟）。
- 提交后立即读列表/详情。
- 断言业务是否读主、或重试、或提示「处理中」。
规避（答设计）
关键读走主；提交后短窗口读主；UI 用提交返回的 orderId 直跳详情而不是立刻刷列表。
强调：测环境若从不模拟延迟，这类 bug 只会在线上高峰出现。
9. 购物车/结算页价格不一致怎么排查？
参考答案：
用分层排查，面试按 STAR 讲一遍即可。
- 复现：同一 SKU、同一地址，记录购物车价与结算价、时间戳。
- 抓包：对比购物车接口与结算计价接口字段（促销 ID、生效时间、区域）。
- 分层怀疑：前端缓存旧价；促销引擎版本不一致；会员价/到手价口径不同；区域价。
- 对齐：以结算/下单服务为准修展示；补回归「改价后购物车刷新」。
- 预防：结算前强制重计价；监控「车结算价差」埋点。
不要一上来就说「清缓存试试」——要显得有方法论。
10. 接口幂等你怎么设计和验证？
参考答案：
设计口述
业务唯一键（客户端请求号 / 订单号 / 支付单号）+ 服务端去重表或状态机：已成功则直接返回成功结果，不二次扣减。
测试
- 相同请求连发、并发双发。
- 超时后客户端重试。
- 先失败再成功的部分重试（看是否丢幂等键）。
断言副作用只一次：库存、积分、券核销、短信。返回体第二次应与第一次业务结果一致（或明确「已处理」）。
11. 灰度发布（按用户/门店）怎么测？
参考答案：
灰度测的是「进对桶、可观测、可回滚」，不是只测新功能本身。
- 进组正确：白名单必中；同一用户多次请求组稳定；比例扩缩符合配置。
- 兼容：新旧接口字段；灰度写是否污染全量报表。
- 监控：按桶对比错误率、转化、资损相关指标。
- 回滚：一键切回全量旧逻辑，演练过。
门店灰度还要测：门店维度库存/促销是否串店。
12. 售后（退款/退货）链路测试重点是什么？
参考答案：
售后是第二条资金链路，复杂度不亚于下单。
流程
申请条件 → 审核通过/驳回 → 仅退款 / 退货退款 → 入库质检 → 退款到账。
重点
- 部分退、多次退，累计 ≤ 实付。
- 优惠分摊回退（券、满减如何退）。
- 库存是否回补、回补到哪一仓。
- 运费谁承担。
- 并发：用户取消申请 vs 客服审核。
资金断言 + 库存断言 + 状态机非法迁移，三者都要有。
13. 缓存击穿/雪崩在商品详情场景怎么测？
参考答案：
先区分概念，再设计实验。
- 击穿：热点 key 过期瞬间，高并发打穿到 DB。
- 雪崩：大量 key 同时过期。
- 穿透：查不存在的商品绕过缓存（可顺带提）。
测法
造热点 SKU；集中设置过期；打压测。观测 DB QPS、连接池、是否互斥重建、是否限流。
断言：详情仍可降级返回；交易不被拖死；无长时间全站 5xx。
14. 数据对账：订单、库存、资金三方不一致如何发现？
参考答案：
测试同学的价值不只是手工点，而是建立发现机制。
- 定时对账：支付成功订单 vs 库存扣减流水 vs 渠道/账务流水。
- 差异进告警与工单，有处理 SLA。
- 测对账任务本身：漏扫、重复扫、日切时区、任务失败重跑幂等。
- 大促后加大对账频率与人工抽检。
面试收尾：「一致是目标，对账是手段，监控是日常。」
速查： 多练「交易闭环、库存超卖、促销计价、大促压测与对账」；少踩「只测页面、对账说不清」。