购物车测试用例设计：从加购到结算与宝贝上限验证

1. 先把场景摸清购物车到底在测什么购物车这个模块我在几个电商项目里都从头到尾跟过测试方案说实话它是最容易被低估的一块。新人一看不就是个列表吗加、删、改数量能有多复杂。真上手才发现一个购物车页面背后牵扯着商品中心、库存中心、营销中心、价格中心、订单中心五六个服务任何一处状态不同步用户在结算页看到的数字就会对不上。这也是它在软件测试面试和实际项目里都高频出现的原因它足够小能在一两个小时内讲清楚又足够深能一路挖到分布式一致性和性能边界。下面我会把购物车的测试用例从加购入口一直拆到结算跳转同时正面回答一个经常被问到、但很少有人系统讲清楚的问题——电商平台为什么要给购物车设置宝贝上限这个上限值到底是怎么定出来的验证的时候又该怎么下手。全文以某头部电商平台的购物车作为参照样本逻辑和参数放到同类产品上也一样通用。适合三类人看刚转测试、需要一份能直接抄的用例清单的带项目、需要给团队成员做用例评审的以及想搞明白业务规则背后的工程权衡这件事的。1.1 购物车的业务模型拆解在写第一条用例之前我一般会先把购物车的数据结构列出来不然后面全是拍脑袋。一个典型的购物车条目至少包含这些字段用户 ID、SKU ID、规格属性颜色/尺码/容量等、购买数量、选中状态、加入时间、来源渠道、加购时命中的活动标记、以及一个最近一次校验时间。这里要特别注意 SKU 和 SPU 的区别。SPU 是商品SKU 是具体到规格的可售卖单元。同一件衣服黑色 M 码和白色 L 码是两个 SKU在购物车里是两条独立记录。这个区分直接决定了后面用例怎么设计——比如加购上限到底是按条目数算还是按件数算很多时候线上出问题就出在这个口径没对齐。购物车本身还分两层。一层是购物车头记录用户维度的一些状态比如全选状态、上一次进入购物车的时间、结算页暂存信息另一层是购物车明细就是一条条的商品记录。很多项目做重构的时候会把这两层拆到不同的服务里一旦拆开就必须处理一致性问题明细加成功了但购物车头的统计没更新用户看到的就是商品在但角标数字不对。还有一类经常被忽略的数据失效快照。商品下架、删除、规格变更之后购物车里那条记录不能直接物理删除否则用户会觉得我明明加过的东西怎么没了。常见的做法是保留记录、打上失效标记、把加购时的价格和标题存成快照展示时用一个灰色的失效区隔开。这套快照机制本身就是一堆用例的来源。1.2 测试用例设计的整体思路与分层购物车的用例我习惯按四层来铺从下往上分别是数据层、服务层、接口层、UI 层。比例大概是金字塔形UI 层只保留最核心的主流程和跨端一致性大量的边界、异常、组合逻辑全部下沉到接口层去覆盖。为什么这么分因为购物车的绝大多数 bug 不在界面长什么样而在状态算得对不对。UI 层跑一条用例要几十秒接口层跑一条几百毫秒同样一份边界值矩阵放接口层能在一分钟内跑完放 UI 层得跑一下午。而且 UI 层特别容易受加载动画、弹窗、网络抖动干扰失败率一高团队就没人看报告了。服务层主要盯两件事一是依赖服务的降级和超时比如库存服务挂了购物车列表应该还能展示只是库存状态显示未知而不是报错二是缓存和数据库的一致性购物车这种高频读写的数据基本都会走缓存缓存没失效就是经典的删了还在。数据层则要覆盖脏数据的容错。真实环境里一定存在这种情况某个 SKU 被物理删除了购物车里还挂着引用。系统要么静默过滤要么展示成失效绝不能直接抛异常把整页打挂。1.3 为什么动手之前要先画状态机这是我个人的习惯也是我觉得最省时间的一步。购物车条目其实是一个很典型的状态机把状态画出来用例覆盖度基本就清楚了。一条购物车记录常见的状态有正常可购买、库存不足、已售罄、已下架、已删除、价格已变动、活动已结束、预售未开始、限购超限、区域不可售。每个状态还要配上迁移条件比如正常 → 售罄是因为库存被抢完售罄 → 正常是因为补货正常 → 下架是运营操作。画完状态机你会立刻发现两个高频缺陷区一是不可逆迁移比如商品被删除后再恢复购物车里的记录能不能自动活过来二是多状态并存比如一个商品同时满足价格变动和活动结束前端到底弹几条提示、算哪个价格。我见过最典型的一个问题某次大促后商品批量下架购物车里的失效区一下子堆了几十条用户想清理却只能一条条删删除接口还有频率限制结果就是用户体验崩了。这类问题在状态机上一眼就能看出来但如果不画很容易漏在用例之外。2. 核心测试用例拆解从加购到结算的全链路这一部分我把用例按链路顺序摊开每条都尽量写清楚测什么和为什么这么测。你可以直接拿去当评审底稿。2.1 加购入口与数量边界加购的入口远比想象中多商品详情页、搜索结果列表、店铺首页、活动会场、扫码、分享链接、购物车内的再买一次、以及批量加购。每个入口传的参数不一样比如列表页快速加购可能默认数量为 1 且不能选规格详情页加购必须选完规格。入口不同后端走的接口甚至可能不是同一个所以入口矩阵必须单独列一遍。数量边界是必测项而且要用等价类和边界值一起做。有效等价类是 1 到上限值无效等价类是 0、负数、超过上限、非数字、小数、科学计数法、全角数字、首尾空格、以及超长字符串。边界值取 1、上限-1、上限、上限1。这里有个很实际的坑前端输入框通常会做一层拦截但接口层未必做。我测过的项目里起码有三分之一的情况是前端拦住了、直接调接口照样能加进去。所以数量边界的用例一定要在接口层再跑一遍把前端校验当成体验优化而不是安全边界。另一个必测点是重复加购的行为。同一个 SKU 再次加购是数量累加还是新增一条记录如果累加累加后超过上限怎么处理——是拦截整次操作还是加到上限为止这两种策略对用户的心理感受差别很大产品文档里经常写得模棱两可必须逼着产品明确。还要测并发加购。同一个账号在两台设备上同时点加购或者弱网下用户连点三次最终购物车里应该是几条这就涉及接口的幂等设计。常见做法是带一个客户端生成的请求 ID 做去重测试时可以用脚本并发打同一个请求 ID看结果是不是只有一条。2.2 商品状态变化与失效处理这一块是我认为购物车用例里价值最高的部分也是最容易出线上事故的地方。要覆盖的状态变化包括商品下架、商品删除、库存归零、规格变更比如原本的黑色 M被合并成黑色 L、价格上调或下调、限购规则变化、活动开始或结束、店铺关闭、以及配送区域变更导致不可售。每一条都要验证三件事购物车列表怎么展示、选中状态怎么处理、点击结算时的拦截提示是什么。举个例子商品下架后那条记录应该自动取消勾选并且置灰用户点全选时不能把它选上点结算时如果强行带上应该被后端拦下来。这三步任何一步漏了都会导致用户走到结算页才被拦体验极差。价格变动的处理尤其微妙。大部分平台的做法是购物车里展示最新价格同时给一个较加入时降价 X 元的提示。但这里有个隐蔽的问题如果用户加购时用的是活动价活动结束后恢复原价这个降价提示到底该跟哪个价格比我见过有项目直接拿当前价和快照价比结果活动结束后反而提示涨价用户投诉一片。用例里必须把这个场景单列出来。失效商品还有一个必测点它们占不占上限名额。这个我放到第 3 章详细说因为它直接关系到上限规则的定义。2.3 价格、优惠与结算金额校验金额算错是购物车最严重的缺陷类型没有之一。用户对这个极度敏感一旦发现结算金额和预期不符信任感直接崩塌。所以这一块的用例要写到每一分钱都能对上的程度。我一般会先构造一个可控的小数据集然后手算一遍期望值再和系统结果比对。举个具体的例子商品单价数量小计商品 A99.002198.00商品 B59.00159.00商品 C39.00139.00合计296.00假设规则是店铺满 200 减 30平台券满 150 减 20全场满 99 包邮不满收 8 元运费。正确的计算顺序应该是商品小计 296 → 店铺满减296 ≥ 200减 30→ 266 → 平台券门槛判断按 296 还是按 266这就是关键的歧义点→ 如果按 296 算减 20 得 246如果按 266 算仍然 ≥ 150也减 20得 246。这个例子里两者结果一样所以要故意构造一个能区分两者的数据把商品 C 去掉小计变成 257店铺满减后 227都 ≥ 150还是分不出来。真正能区分的是把总额调到 210 左右店铺满减后 180平台券门槛 150 仍然满足但如果平台券门槛是 200那就只有按原价算才满足。所以用例设计的关键不是多凑几个商品而是刻意构造能区分计算顺序的临界数据。这类数据我一般会在 Excel 里单独维护一张歧义数据表每次回归都跑一遍。还要覆盖的金额场景包括优惠券过期、优惠券被其他订单占用、优惠券不适用当前商品、多个店铺商品混合结算时的运费合并规则、积分抵扣的上限、以及金额的小数精度尤其是 0.1 0.2 这类浮点问题虽然是老生常谈但每年都能测出来。2.4 多端同步与异常场景现在的购物车基本都是多端共享的App、小程序、网页、平板同时登录一个账号很常见。同步策略一般有两种实时同步一端改动立刻推给其他端和拉取同步其他端下次刷新时更新。两种策略的用例完全不同。实时同步要测一端删除另一端多久消失一端改数量另一端会不会覆盖用户正在编辑的输入断网重连后状态怎么对齐。拉取同步相对简单但要测用户在两端的操作冲突——比如手机上删了网页上还在编辑数量并提交这时候数量提交应该失败并提示商品已移除而不是默默加回去。弱网和异常是另一大块。要测的场景包括请求超时后重试导致重复加购、加购过程中切后台再回来、加购成功后立刻断网导致前端状态和后端不一致、以及支付前置校验失败后的回滚。还有一个容易被漏掉的账号切换。同一台设备上 A 账号退出、B 账号登录购物车数据必须彻底隔离。这个如果做不好就是严重的隐私问题。测试时要注意本地缓存有没有清理干净尤其是图片缓存和价格缓存。3. 上限问题的正面回答为什么购物车要设置宝贝上限终于说到正题。这个问题我在面试里问过不少人绝大多数回答都是防止用户加太多——这等于没说。真正的答案要从技术成本、业务风控、用户体验三个维度一起看而且这三个维度的权重在不同阶段是不一样的。3.1 从技术成本算一笔账先算存储。假设一个中等规模的电商平台日活 8000 万其中有购物车行为的活跃用户按 3000 万算。一条购物车明细的原始字段加起来大约 100 字节但加上主键索引、用户维度二级索引、以及各种冗余字段实际落盘大约 300 到 500 字节取中间值 400 字节。如果平均每人 50 条那就是 3000 万 × 50 × 400B ≈ 6TB。如果上限放开、平均条数涨到 80 条就是 9.6TB涨了 60%。这个数字看着还能接受但购物车是高频读写的场景不是冷数据。每次进购物车都要全量拉取每次加购都要写一次存储成本只是开始真正的压力在 IO 上。再算渲染。购物车列表接口每条商品要返回主图、标题、规格、价格、库存状态、活动标签、优惠预估序列化后大约 800 字节到 1.5KB取 1KB。100 条就是 100KB 的响应体gzip 压缩后约 25KB。500 条就是 500KB压缩后 120KB 以上。在弱网环境下这 100KB 的差距就是首屏多等一秒和多等五秒的区别。最要命的是结算校验。用户点结算后端要对每一条商品做库存校验、价格重算、活动可用性判断、限购判断。这些校验通常要调下游服务批量接口单次能处理的条数一般有上限常见是 50 或 100 条。如果是 500 条就得分 5 到 10 批去调每批的响应时间叠加起来结算页的 loading 可能要转好几秒。而结算页的转化率对加载时间极其敏感这个损失是实打实的。所以上限的第一个作用是给系统一个确定的性能边界。有了上限容量规划就能算清楚单机 QPS 多少、缓存多大、批量接口分几批最合适。没有上限你就只能按最坏情况做容量而这个最坏情况可能是被少数用户撑爆的。3.2 从业务与风控角度第二个维度是业务。购物车做长了对平台其实是负资产因为它会显著拉低转化率。道理不难理解用户加了 200 件商品结算是要一件件确认的决策成本高到一定程度他干脆就不买了。相反购物车里只有 10 件用户更容易一次性清空。所以很多平台会做购物车瘦身的运营动作比如提示您有 15 件商品已降价、3 件商品库存紧张本质上都是在帮用户缩小决策范围。还有一层是风控。购物车虽然不锁库存但它是很多链路的前置。恶意用户或者爬虫可以批量加购来做几件事探测商品是否存在、探测价格和库存变化、以及在被限购规则拦住之前先囤一批。设置上限能明显提高这类行为的成本——想扫 10 万个 SKU就得反复加删请求量翻好几倍很容易被风控策略识别出来。另外上限还和数据统计口径有关。运营看的人均加购件数、购物车转化率这些指标如果存在少数用户加了几千件的情况均值会被严重拉偏。设个上限统计数据的分布会健康很多做分析的时候不用天天做异常值清洗。3.3 从用户体验角度第三个维度才是大家第一反应想到的但它其实是结果而不是原因。用户视角看购物车无限长带来的问题不是装不下而是找不到。列表一长靠滑动去找商品基本不可能只能依赖搜索和筛选。而购物车的搜索功能通常做得很弱这就变成了一个死循环。所以上限在体验上的作用是逼着用户做一次整理把不买的删掉把要买的留下这其实是在帮他做决策。还有一个心理层面的东西购物车里的商品数会形成一个心理账户。10 件以内用户觉得我这次买得挺克制50 件以上用户会有明显的压力感反而更容易放弃。这个不是我瞎猜是电商领域反复验证过的现象也是为什么很多平台会主动提示购物车已满请先清理来制造一种稀缺感。3.4 上限值的合理区间与验证方法综合上面三点业内常见的上限值落在 100 到 200 之间按 SKU 条目数计算居多。也有按件数算的比如总数不超过 999 件但按条目算更主流因为条目数才是真正影响渲染和校验成本的量。验证上限我一般按这个顺序做第一确认计数口径。是条目数还是件数不同规格算不算两条失效商品占不占名额这三个问题必须先问清楚否则后面全是无效用例。我遇到过最离谱的一次产品文档写上限 120 件开发按条目实现测试按件数验证三方理解完全不一致。第二验证边界行为。加到 119 条能成功加到 120 条能成功加到 121 条要给出明确提示且不能静默失败。提示文案也很重要操作失败和购物车已满最多可放 120 件商品给用户的感受完全不同。第三验证上限后的恢复。满了之后删掉一条能不能立刻再加一条这个是高频缺陷点因为很多实现里上限判断走的是缓存计数删除后缓存没及时更新用户就会遇到我明明删了还是加不进去。第四验证失效商品的处理。失效商品如果占名额用户就必须手动清理才能继续加购体验很差如果不占名额那上限判断就要排除失效记录实现会复杂一些。两种方案都能接受但必须和产品确认清楚并写进用例。第五验证并发下的上限。两个端同时加购最后一条名额会不会突破上限这个要用脚本并发打验证后端是不是用了原子操作或者分布式锁。4. 实操把用例真正跑起来前面讲的都是设计思路这一章讲怎么落地。用例写在文档里没人跑等于零我的经验是一定要有一部分能自动执行尤其是边界和金额这两类。4.1 用例表的结构与优先级划分我的用例表一般是这几列编号、模块、用例标题、前置条件、操作步骤、预期结果、优先级、是否自动化。优先级只分三档P0 是主流程和金额相关必须每次回归都跑P1 是常见异常版本回归跑P2 是极端场景发版前抽跑。编号模块用例标题预期结果优先级CART-001加购详情页选择完整规格后加购 1 件加购成功购物车角标 1P0CART-002加购未选规格直接加购提示请选择规格不产生记录P0CART-003加购同一 SKU 连续加购两次数量累加为 2不新增记录P0CART-004边界加购数量输入 0前端拦截或后端返回参数错误P1CART-005边界加购至上限值成功无异常提示P0CART-006边界加购至上限值 1明确提示已达上限数量不变P0CART-007失效商品下架后查看购物车记录置灰、取消勾选、不可结算P0CART-008金额店铺满减 平台券叠加按约定顺序计算结果与手算一致P0CART-009同步A 端删除B 端刷新B 端记录消失无残留P1CART-010并发两端同时加购最后一条名额只有一条成功总数不超上限P1这张表只是个骨架实际项目里我一般会铺到 150 到 250 条。数量不是目的覆盖状态机的每一条边才是。4.2 数据构造与接口层校验脚本接口层的边界测试我习惯用 pytest 加 requests 写因为上手快、报告清晰。下面是我常用的一个骨架用来验证上限相关的行为import pytest import requests BASE_URL https://cart.example.com AUTH_TOKEN test-token-placeholder pytest.fixture(scopemodule) def client(): session requests.Session() session.headers.update({ Authorization: fBearer {AUTH_TOKEN}, Content-Type: application/json, }) return session def add_item(client, sku_id, quantity1): return client.post( f{BASE_URL}/v1/cart/items, json{skuId: sku_id, quantity: quantity}, timeout5, ) def clear_cart(client): client.delete(f{BASE_URL}/v1/cart/items, timeout5) def test_add_at_limit(client): clear_cart(client) for i in range(120): resp add_item(client, fSKU_{i:04d}) assert resp.status_code 200, f第 {i1} 条加购失败 assert len(client.get(f{BASE_URL}/v1/cart/items).json()[items]) 120 def test_add_over_limit(client): resp add_item(client, SKU_OVER) assert resp.status_code 409 body resp.json() assert body[code] CART_FULL assert 上限 in body[message] def test_add_after_delete(client): items client.get(f{BASE_URL}/v1/cart/items).json()[items] target items[0][skuId] client.delete(f{BASE_URL}/v1/cart/items/{target}, timeout5) resp add_item(client, SKU_NEW) assert resp.status_code 200, 删除后仍无法加购疑似计数缓存未刷新这段脚本里最关键的是最后一个用例。删除后能否立刻加购是上限功能里 bug 密度最高的地方十有八九第一次跑都会挂。余额和金额的校验脚本我会单独拆一个文件把期望值写死在数据里避免用系统算的结果去验证系统这种假验证。4.3 自动化怎么铺才不失控自动化最容易犯的错是想一口气全铺。我的建议是先把 P0 里的加购主流程、失效处理、金额计算、上限边界这四类做掉大概 30 到 40 条跑通之后再加。数据隔离一定要做好。购物车是用户维度的强状态数据如果多个用例共用同一个测试账号跑起来互相污染失败原因根本查不清。我的做法是每个用例用独立的测试账号或者每个用例开头强制清空。清空这一步别省省下来的时间会在排查上十倍还回去。断言点要选稳定的。别去断言完整的响应体字段一变就全挂。只断言你真正关心的那几个状态码、业务 code、条目数量、以及金额字段。UI 层的自动化只保留从加购走到结算页这一条主链路其他全部下沉。5. 常见问题与排查技巧实录5.1 几个反复出现的典型缺陷删除后加不进去。这是上限功能的老朋友了。根源通常是计数走了缓存删除只删了数据库。排查方法是删完之后立刻调一次购物车列表接口看返回的条数是不是已经减了如果列表对了但加购还是失败那基本可以定位到计数缓存。失效商品占了名额。用户加满了 120 件其中 30 件已经下架想加新的加不进去又不知道该删哪些。这个问题的本质是上限判断的范围和列表展示的范围没对齐。修法有两种一是失效不占名额二是满的时候优先清理失效。两种都能接受但必须在产品层面拍板。金额差一分钱。九成是浮点运算或者四舍五入时机不对。排查时不要看最终结果要把每一步的中间值都打出来尤其是优惠券分摊到每个商品上的金额。分摊之后每条商品的小计之和必须精确等于总优惠这个校验一定要加。多端状态覆盖。用户在手机上改数量网页上还显示旧值提交后互相覆盖。这类问题基本都要靠版本号或者时间戳做乐观锁测试的时候重点验证提交旧版本会不会被拒绝。上限判断非原子。并发下突破上限。用 JMeter 或者 locust 起 20 个并发打同一个账号的加购看最终条数会不会超过限制。如果超了说明后端是先查后写的非原子操作。5.2 问题速查表现象可能原因排查手段加购成功但角标不变前端未刷新或统计接口失败刷新页面看是否恢复抓包看统计接口返回删除后列表还有缓存未失效直接查库确认再查缓存 TTL 配置金额与手算不符计算顺序或分摊规则错误打印中间值逐条核对优惠分摊上限后无法恢复计数未随删除更新调列表接口比对条数与加购判断逻辑失效商品无法批量清理批量接口频率限制查接口限流配置确认前端是否串行调用结算页提示商品已失效列表与结算校验口径不一致对比两处对可售的定义并发下超出上限非原子判断查是否用了分布式锁或数据库行锁5.3 我在实际项目里攒下的几条经验第一先跟产品把口径对齐再动手写用例。购物车里上限按什么算失效占不占名额优惠按什么顺序叠这三个问题如果开工前没问清楚后面返工的量会非常大。我现在的习惯是把这三个问题写成一页纸让产品签字确认再开始。第二把金额用例的期望值手工算一遍并写进文档。不要指望后来的人能看懂你的计算逻辑把每一步的中间值都列出来包括优惠分摊到每个 SKU 的金额。这样出了问题谁都能在五分钟内定位到是哪一步偏了。第三上限相关的用例一定要在真实数据量下跑一次。测试环境里加 120 条数据可能秒开线上有几十万用户同时在刷的时候完全是另一回事。哪怕只是简单压一下列表接口也能提前发现慢查询这类问题。第四别忽略提示文案的测试。用户被上限拦住的时候看到的是操作失败还是购物车已满最多可放 120 件请先清理这直接决定了他会不会继续用。文案的用例看起来琐碎但它是用户能感知到的唯一部分。第五也是我个人体会最深的一点购物车这个模块的价值不在用例数量而在状态覆盖。我见过写了 300 条用例但状态机还有边没覆盖到的方案也见过只有 80 条但每条都卡在关键路径上的方案。后者上线后的缺陷率明显更低。写用例的时候多问一句这条记录如果失败了用户会看到什么比多写十条重复的 UI 检查有用得多。