电商下单流程的核心测试点有哪些？

👔 Raina面试官： 电商下单这条主链路，你觉得核心测试点有哪些？

🙋 候选人：

我会按下单前 → 下单中 → 下单后三段拆，每段都有钱和状态，漏一个都可能资损。
下单前：商品可售状态、库存可见量、价格（含促销价）、地址/配送范围、限购规则。下单中：选规格 SKU、数量边界、优惠券选用、运费计算、订单金额汇总、幂等（重复提交）、并发下单。下单后：订单生成、库存预占/扣减、支付单创建、超时关单、订单详情与列表一致性。
横切关注点：登录态、多端（App/H5/小程序）行为一致、弱网/中断恢复、日志与 trace 能串起 orderId。P0 一定是钱算对 + 库存不错 + 状态可追溯。

👔 Raina面试官： 促销叠加的时候怎么保证测全？

🙋 候选人：

单独拉价格计算矩阵，不和主流程混在一起。
用判定表列出：满减 × 优惠券 × 会员价 × 运费券的合法/非法组合，每条组合断言最终应付金额和优惠明细字段。主流程用典型组合冒烟，矩阵用接口批量回归——手工点 200 种组合不现实。

库存扣减、超卖问题测试怎么设计？

👔 Raina面试官： 库存扣减和超卖是电商经典难题，你怎么设计测试？

🙋 候选人：

核心验证三件事：扣减时机对不对、并发下会不会超卖、异常回滚后库存是否一致。
扣减时机：下单预占 vs 支付后扣减 vs 发货扣减——每种策略测取消订单、支付超时、支付失败时库存是否正确释放。功能用例覆盖单用户正常购买、买超库存、买 0 和负数。并发用 JMeter/Locust 模拟 N 个用户同时抢最后 M 件库存，断言成功订单数 ≤ 库存数，且 DB 库存不为负。
还要测补偿：支付回调重复、消息重复消费、服务重启中途——库存流水表和实际可售量对得上。如果有 Redis 缓存库存，要测缓存与 DB 不一致时的兜底策略。

👔 Raina面试官： 测试环境很难造真实并发，怎么办？

🙋 候选人：

三层手段：接口层压测 + 单元/集成层模拟并发 + 生产灰度观察。
测试环境用压测工具打；开发配合写集成测试用 CountDownLatch 模拟多线程扣减；大促前在预发用影子流量或内部秒杀演练。没有绝对真实，但三层叠加能把超卖风险压到可接受范围。

👔 Raina面试官： 优惠券、满减、叠加规则这块，测试难点主要在哪？

🙋 候选人：

难点在规则组合爆炸 + 时间窗口 + 状态机复杂，不是单点功能而是数学和策略问题。
组合爆炸：满 300 减 50、店铺券、平台券、会员折扣能不能叠、叠的顺序影响最终价——规则一改就是 N×M 种组合。时间窗口：券有效期、活动开始结束临界点、时区、服务器与客户端时间不一致。状态机：未领取/已领取/已使用/已过期/已作废，以及退款后券是否返还。
测试策略：产品出规则矩阵文档 → 测试转判定表 + 自动化价格断言；临界点用边界值（差 1 分达标、活动最后一秒）；异常规则（互斥券同时选）要有明确错误码和前端提示。

👔 Raina面试官： 线上价格和结算页不一致怎么查？

🙋 候选人：

👔 Raina面试官： 支付流程——收银台、回调、对账，你怎么测？

🙋 候选人：

分三块，每块都有同步路径和异步路径。
收银台：唤起支付、金额与订单一致、支付方式切换、支付中取消、超时。沙箱环境走微信/支付宝测试账号，断言支付单号和商户订单号映射正确。回调：模拟渠道成功/失败/重复回调/乱序回调/签名错误，验证订单状态只迁移一次（幂等）、重复通知不重复发货。对账：构造长短款、掉单、跨日交易，跑对账任务后断言差异报表和补单流程。
横切：金额精度（分）、币种、合单支付、部分支付。P0 是回调幂等和状态机——钱收了订单还待支付，或者没收钱订单变已支付，都是 P0 事故。

👔 Raina面试官： 真实支付渠道测试环境不好搞怎么办？

🙋 候选人：

用渠道沙箱 + Mock 网关 + 录制回放组合。
日常回归 Mock 回调报文跑状态机；发版前在沙箱走真支付小额单；对账逻辑用构造好的账单文件做离线验证。关键是 Mock 报文要和生产文档一致，别测了个假协议。

👔 Raina面试官： 退款这块——全额退、部分退、原路退回，你怎么覆盖？

🙋 候选人：

按退款类型 × 订单状态 × 支付渠道建矩阵，重点测资金和状态双一致。
全额退：未发货仅退款、已发货退货退款、超时自动退。部分退：多商品订单退其中一件，断言退款金额、优惠分摊、运费处理、剩余商品仍可正常履约。原路退回：微信/支付宝/银行卡各走一遍沙箱，验证退款单号、到账时间字段、重复退款拦截。
异常：退款中用户又下单、退款失败重试、渠道返回 processing 中间态、已结算订单退款。每笔退款后订单状态、库存回滚（若适用）、优惠券返还规则都要断言。

👔 Raina面试官： 部分退款的优惠分摊怎么验？

🙋 候选人：

要产品给分摊公式，测试用固定数据集手算期望值。
比如满减按商品实付比例摊，退一件后剩余商品不应享受已失效的满减档——这种最容易算错。接口返回里要有 promotion_detail 字段，自动化直接 diff 手算结果。

👔 Raina面试官： 订单状态机常见有哪些状态？流转测试你怎么设计？

🙋 候选人：

常见状态：待支付 → 待发货 → 已发货 → 已完成，旁路有已取消、退款中、已关闭、售后中。
测试用状态迁移表：列出合法迁移（待支付+支付成功→待发货）和非法迁移（待支付+发货→应拒绝）。每个迁移触发事件要明确——用户操作、支付回调、超时任务、客服介入。
重点场景：支付超时关单、发货前取消、发货后仅退款 vs 退货退款、确认收货超时自动完成、售后完结后状态。并发：支付回调和用户取消同时到达，最终状态唯一且符合业务优先级规则。

👔 Raina面试官： 状态机测试用例会不会爆炸？

🙋 候选人：

会，所以分 P0 主路径 + P1 异常边 + 探索性补洞。
P0 覆盖 happy path 和最高资损路径（重复支付、错误取消）；P1 覆盖售后各分支；用接口直接打状态迁移 API 比纯 UI 快很多。状态非法迁移要有统一错误码，方便自动化断言。