校园点餐系统看着简单真正做测试的时候才知道坑有多深。注册登录、菜品展示、加购结算、支付退款、商家接单、骑手配送随便一环出问题用户当场就骂娘。尤其是校园场景下课高峰期几千人同时下单库存扣重、支付回调、订单状态同步这些环节一点都不能含糊。这篇就把我做校园电商点餐系统测试的全套用例设计思路、核心链路拆解、实操过程和踩坑记录整理出来给同样在搞这类项目的测试朋友一个参考。1. 校园点餐系统的测试思路拆解1.1 校园场景的特殊性决定了测试重点校园点餐和普通餐饮外卖看着相似实际测试重心差得远。普通外卖用户分散高峰期相对平均校园点餐用户高度集中中午11:40到12:10这半个小时可能是全天订单量的60%以上。这种集中爆发式的流量模型对系统的并发处理能力、库存扣减的原子性、支付回调的及时性都提出了更高要求。另外校园点餐的角色也比一般外卖系统复杂。除了学生用户端还有食堂档口/商户端、配送员端有的学校是取餐柜模式、平台管理后台。每个角色都有自己的操作流程和权限边界测试用例必须覆盖到每一种身份的主干路径和异常路径。支付方式也和普通外卖不同除了微信支付、支付宝很多学校还有校园卡余额、一卡通虚拟账户、优惠券叠加等支付途径。支付方式的多样性意味着支付流程的测试用例要额外增加支付渠道切换、支付状态同步、退款原路返回等场景。校园点餐还有典型的物理位置特征取餐点、配送范围、宿舍楼区域划分。点餐系统需要校验用户定位是否在配送范围内菜品是否支持配送到当前地址。这一块如果测试不到位就会出现用户下单成功但实际无法配送、或者配送范围外用户也能下单的严重问题。1.2 测试范围划分与优先级排序我做这类项目从来不会一上来就闷头写用例。先拉出测试范围再按业务影响面定优先级这样用例写起来才有条理、执行的时候才知道先跑什么。整个校园点餐系统的测试范围可以划分为五个核心域用户端功能点餐全流程、商户端功能接单、出餐、上架管理、配送/取餐流程、支付结算体系、后台管理系统商品管理、订单管理、数据统计。每个域下面再细分子模块比如用户端又分注册登录、首页推荐、菜品搜索、购物车、订单确认、支付、订单详情、评价售后。优先级排序上我习惯把支付结算体系、订单核心链路、库存扣减这三块定为P0因为它们直接影响交易成功率和资金安全。用户点餐主流程、商户接单出餐是P1直接影响用户体验。个人中心、评价、发票申请、优惠券管理等是P2相对独立、影响面可控。这个优先级在后面用例设计时直接映射到用例的优先级字段保证核心用例在有限测试周期内一定被覆盖。1.3 先理清业务规则再动手写用例点餐系统的业务规则非常多而且很多规则之间有耦合关系。比如优惠券规则满减券、折扣券、校园专享券是否能叠加优惠券计算基数是否包含配送费退款时优惠券是否退回这些规则如果没有在测试用例中明确转化为预期结果测试执行就变成瞎点点根本验证不了规则的正确性。我习惯先把核心业务规则用表格梳理清楚再开始写用例。这样做的好处是每个测试用例的预期结果可以直接引用规则编号既保证可追溯性又方便后续需求变更时快速定位影响范围。规则编号业务规则描述对应模块R-001新用户注册后赠送3张满20减5优惠券有效期7天优惠券R-002优惠券不可叠加使用每笔订单最多使用1张订单结算R-003菜品售罄后前端立即置灰不允许加入购物车菜品展示R-004下单后15分钟内未支付订单自动取消并释放库存订单管理R-005退款金额按实际支付金额原路退回优惠券不退回退款售后这类规则一般是产品经理定的但测试一定要在写用例前逐条和产品、开发对齐尤其是边界情况。比如R-004里“15分钟未支付自动取消”到底从哪个时间点开始计时下单成功还是进入支付页计时过程中用户反复进入支付页计时是否重置这类细节不问清楚用例写出来就是错的。2. 核心业务链路与用例设计方法2.1 从用户旅程拆出全链路用例地图写用例最大的忌讳是只盯着单个功能点写结果单个功能测得好好的一连起来就出事。点餐系统的核心链路很长用户打开小程序/APP → 浏览推荐/搜索菜品 → 加入购物车 → 确认订单选地址/备注/使用优惠券 → 支付 → 商户接单 → 后厨出餐 → 配送/放入取餐柜 → 用户取餐 → 评价/售后。我把这个主链路切成四段来分别设计用例每段单独测完再做端到端联测第一段是“逛与选”覆盖首页推荐、分类浏览、搜索、菜品详情、购物车管理。重点验证菜品信息的准确性、库存状态的实时性、价格和规格的展示正确性。第二段是“下单与支付”覆盖订单确认页的信息回显、优惠计算、地址配送判断、支付唤起、支付结果回调、超时取消。这段是核心中的核心用例密度要最高。第三段是“履约与交付”覆盖商户接单、出餐状态流转、配送员取餐、取餐码生成、用户取餐通知。第四段是“售后与评价”覆盖订单完成后的评价入口、退款申请、客服介入、发票申请。每段之间的接口最容易出问题。比如“下单与支付”段的支付成功后订单状态要推送给商户端并触发接单提醒如果这个状态同步不及时用户已支付但商户端看不到订单就会出现餐品漏做的情况。2.2 等价类和边界值在点餐场景中的具体应用点餐系统里适合用边界值分析的参数非常多典型的有菜品库存数量0、1、库存上限1、购物车单次加购上限通常限制99件、订单金额边界满减门槛的临界值、优惠券有效期边界生效当天、过期当天、评价字数上限如500字。举一个我实际写过的例子订单满30减5元的满减规则。有效等价类很简单订单金额31元、50元都能享受满减但边界值分析必须覆盖恰好30元、29.99元、30.01元、刚好用券后金额为0元、用券后出现负数金额等极端情况。尤其是满减优惠后订单金额的计算逻辑在配置了多级满减满30减5、满50减10时要额外验证重复命中、最高档位命中、金额取整规则等场景。库存边界也很有代表性。菜品规格大份/小份、辣/不辣不同库存是共享还是独立比如大份鸡腿饭和小份鸡腿饭如果都归属同一菜品维度的总库存而规格维度又分别记录各自库存两套库存数据在扣减时必须保持一致性。我遇到过一个实际Bug用户在规格维度下单库存扣减成功但总库存维度没有同步扣减导致总库存显示充足实际上对应规格已经没货了。这类跨维度数据一致性问题是库存边界测试的重点。2.3 场景法与异常流用例设计场景法最适合点餐系统测试。从用户角度梳理出正常的完整流程、备选流程和异常流程确保用例覆盖的不是孤立的操作而是完整的故事线。一个典型的主场景用例是新用户注册 → 领取新人券 → 浏览食堂推荐页 → 选择川菜窗口 → 添加回锅肉盖饭和一杯酸梅汤 → 进入购物车 → 调整数量 → 确认订单 → 选择宿舍地址 → 使用新人券 → 微信支付 → 支付成功 → 商户接单 → 出餐完成 → 用户收到取餐通知 → 到取餐柜取餐 → 订单完成 → 发表评价。这个长流程在端到端联测时非常重要能一次性暴露上下游数据传递问题。异常流程要专门设计不能指望主流程测完顺带覆盖。比如支付过程中用户主动取消支付、支付时余额不足、支付回调超时、支付成功但商户端断网、出餐过程中餐品售罄、取餐码被重复扫描、退款过程中账户已注销等。每一个异常流程都要明确系统应该怎么表现是提示重试自动补偿状态置为待人工处理还是回滚订单我单独把“支付成功但回调丢失”这个场景拎出来重点测因为这是点餐系统最致命的问题之一。用户的钱扣了但系统没收到支付成功的通知如果这时候没有主动查询支付结果或补偿机制订单就一直卡在待支付状态。测试时需要模拟回调超时、回调重复推送、回调签名错误等各种情况验证系统的对账和补偿逻辑是否正常。3. 实操过程典型功能模块用例实现3.1 用户端核心模块用例示例账号登录模块是最基础的但也是最容易被忽视的。手机号验证码登录、密码登录、第三方授权登录微信一键登录、游客浏览模式四条路径都要覆盖。还要考虑验证码有效期一般5分钟、发送频率限制同一手机号60秒内只能发送一次、连续输错密码锁定策略、多设备同时登录处理等安全相关场景。我整理过一批典型的用户端用例字段包括用例编号、所属模块、前置条件、操作步骤、预期结果、优先级。举几个有代表性的用例编号模块前置条件操作步骤预期结果优先级UC_Login_001登录已注册手机号输入正确手机号和密码点击登录登录成功跳转首页显示用户昵称P0UC_Login_007登录用户已登录同一账号在另一台设备登录原设备收到下线提醒数据保持同步P1UC_Cart_013购物车菜品有库存购物车有3件商品对其中1件点击减少数量至0该菜品自动移出购物车金额重新计算P0UC_Order_025订单确认购物车已选好商品修改订单备注“不要香菜”后提交订单订单详情显示备注内容商户端可见P1UC_Pay_031支付待支付订单金额35元有满30减5券使用优惠券后支付实付金额30元优惠记录写入订单明细P0购物车模块有几个点容易在测试时漏掉购物车商品价格是每次进入都实时拉取、还是用加购时的缓存价如果商户在用户加购后修改了菜品价格用户结算时按哪个价格算生产环境一般按最新价格结算但要在结算页给用户明确提示价格变动信息。购物车里菜品售罄、菜品下架、规格售罄这三个状态也要分别处理不能一刀切。3.2 商户端与后台管理用例要点商户端食堂档口的操作链路相对简单但状态机很复杂。商户接单后可以操作的状态包括接单、开始制作、出餐完成、申请拒单需选原因并提交平台审核。每个状态的流转条件、可操作范围、超时处理都要有明确用例。以拒单为例很多系统允许商户在用户下单后一段时间内申请拒单但超过某个时间节点如出餐开始后就不能拒了。拒单后订单自动退款给用户商户端要填写拒单原因平台审核通过后不处罚商户审核不通过则计入商户考核。这类规则逻辑复杂测试时要用判定表把各种条件组合都覆盖到。我常用的条件项有是否在可拒单时间内、是否有拒单库存、是否填写原因、是否同一订单重复拒单、当日累计拒单次数是否超限。后台管理模块重点测商品管理上下架、改价、库存调整、批量导入导出、订单管理按状态/时间/档口筛选、异常订单标注、人工介入退款、用户管理冻结/解冻、余额调整和数据统计订单量、销售额、热门菜品排行、退款率。后台管理用例一般功能不复杂但一定要验证权限控制确保不同角色的管理员只能看到和操作自己权限范围内的数据。3.3 接口测试与自动化脚本落地功能测试做得再细核心链路的接口测试也不能少。点餐系统最关键的几个接口包括获取菜品列表、加入购物车、提交订单、支付下单、支付回调、查询订单状态、商户接单、出餐状态上报。接口测试重点验证参数校验、业务逻辑正确性、异常处理和数据一致性。我实际项目里会把核心接口的测试脚本存下来反复跑尤其是提交订单和支付回调这两个接口。提交订单接口要验证库存充足、菜品在架、地址在配送范围、优惠券可用性和金额计算的正确性。支付回调接口要验证签名、订单号匹配、金额匹配、重复回调幂等性、回调与主动查询的结果一致性。自动化这一块这两年我慢慢把重心转到Playwright上。相比以前用的SeleniumPlaywright在等待策略、自动截图、追踪录制这些方面更省心。下面给一段用Python写的核心用例示例场景是“搜索菜品并加入购物车然后结算”import re from playwright.sync_api import PwPage, expect def test_search_and_add_to_cart(page: PwPage): # 打开校园点餐小程序对应的Web管理端页面 page.goto(https://test-campus-order.example.com) # 用测试账号登录 page.get_by_placeholder(手机号).fill(13800138000) page.get_by_placeholder(密码).fill(test123456) page.get_by_role(button, name登录).click() # 等待首页加载完成 await expect(page.get_by_text(今日推荐)).to_be_visible() # 搜索一道菜 page.get_by_placeholder(搜索菜品).fill(回锅肉盖饭) page.get_by_role(button, name搜索).click() # 断言搜索结果中出现目标菜品 await expect(page.get_by_text(回锅肉盖饭).first).to_be_visible() # 点击加入购物车并断言购物车角标变为1 page.get_by_role(button, name加入购物车).click() await expect(page.locator(.cart-badge)).to_have_text(1) # 进入结算页并断言金额显示正确 page.locator(.cart-icon).click() await expect(page.get_by_role(button, name去结算)).to_be_visible() await expect(page.locator(.total-price)).to_have_text(¥25.00)这类自动用例能不能稳定跑起来核心不在于脚本写得多漂亮而在于前端元素定位稳不稳定。如果前端频繁改版导致选择器失效脚本维护成本会非常高。我的经验是尽量用text、placeholder、role这类语义化定位方式少用CSS层级路径测试数据用独立的测试账号避免依赖真实用户数据造成脏数据污染。4. 测试用例在不同项目组的复杂迭代需求中的管理与复用4.1 用例沉淀的两种形态业务用例库与基础操作库做过几个迭代之后就会发现点餐系统的用例重复度非常高。每次需求变更比如满减规则调整、接单流程优化、支付方式新增很大一部分用例只是稍微改一下前置条件和预期结果操作步骤基本不变。这时候如果用例还是散落在各个测试执行记录里每次都重新写一遍效率非常低。我的做法是把用例拆成两层。第一层是业务用例库按业务模块组织比如“订单结算”“支付回调”“优惠券核销”每条用例都有明确的业务编号。第二层是基础操作复用库把高频操作用模板做成公共步骤比如“登录校园点餐后台”“按订单号查询订单”“构造指定金额的支付回调报文”。业务用例引用基础操作库里的步骤而不是重复粘贴操作细节。这样做的好处是当登录逻辑从验证码登录改成扫码登录时只需要改基础操作库里的“用户登录”步骤所有引用它的业务用例自动生效不需要逐条去翻去改。4.2 跨项目组协作时的用例复用机制校园点餐系统一般会拆成用户端、商户端、支付中台、履约调度等多个项目组并行开发。这时候测试用例的复用就不能只靠测试团队自己内部维护还要考虑跨组协作时的版本对齐。我们使用禅道管理用例所有用例按模块树维护支付中台的用例有独立的目录用户端和商户端通过用例引用方式关联支付中台的公共用例。需求变更时先由测试负责人更新公共用例再通知关联项目组的测试同步。这个流程看起来很简单但实际操作中最大的坑是通知链路断裂——公共用例改了下游项目组不知道还在按旧用例跑回归测试结果自然对不上。我踩过这个坑之后定了一个规则凡是公共用例变更必须同时在用例管理平台提交变更记录并在项目群内相关测试负责人确认。每周五做一次用例同步检查比对公共用例的版本号。这个机制听着笨但真的能避免很多跨组扯皮。4.3 用例向自动化脚本转化的思路现在测试行业都在推自然语言测试用例自动生成UI自动化脚本我也试过用LangChain接入大模型做用例转脚本的尝试。思路大体是从用例管理平台读取结构化测试用例步骤、输入数据、预期结果结合平台已有的页面对象模型让大模型生成可执行的Playwright脚本片段再由测试人员进行二次校验和参数化改造。这个方向可行但效果取决于用例描述的结构化程度。自然语言写得越接近操作指令模型生成的脚本越能直接用。比如“点击搜索按钮”比“用户进行搜索操作”更容易被模型转化为选择器定位。在项目初期推行这套方案时我会要求测试人员在写用例时统一动词库点击、输入、选择、拖拽、滚动、断言避免大量口语化描述。半自动化的定位是“辅助生成人工确认”目标是把重复性的脚本编码工作省掉而不是期望完全无人监督。5. 常见问题与排查技巧实录5.1 支付成功后订单状态不同步这是点餐系统测试中最常见也最严重的问题。用户端显示支付成功商户端看不到订单或者商户端已出餐用户端还显示待接单。排查思路一般是先看支付回调是否正常到达再看订单状态机的状态流转条件是否被满足最后看WebSocket或消息推送链路是否有消息堆积。我遇到过一个实际案例支付回调正常到达订单状态也更新了但商户端App没有弹出新订单提醒。最后定位是商户端App在前台时收不到推送原因是没有建立长连接只依赖应用在前台拉取订单接口。这个问题在功能测试阶段很难发现需要结合弱网、App前后台切换、长时间挂机等场景来模拟。5.2 库存超卖问题模拟高峰并发下单时经常出现库存超卖100份菜品卖出120份订单。这个问题的根源在于库存扣减不是原子操作。测试排查时如果开发用的是先查库存再扣减的逻辑并发场景下必然出问题正确做法是数据库层面使用乐观锁或分布式锁在扣减时校验库存大于等于购买数量。我测试时会在用例设计阶段就增加并发用例10个线程同时下单同一菜品库存上限设为5断言最终订单成功数不超过5剩余库存为0。这个用例如果在测试环境都不能稳定通过绝对不上线。5.3 优惠金额计算精度问题金额计算这类问题隐蔽性很强普通功能测试很难发现。满减、折扣、抹零、退款分摊叠加起来经常出现几分钱的差异。我通常准备一组金额计算专项用例覆盖常见的小数位组合单价为小数如0.9元、多件商品总额出现循环小数、折扣后金额取整规则、退款按比例分摊后余几分钱的去向。每个场景都要数据库验证金额字段的实际存储值而不仅仅是看前端展示的UI数值。5.4 测试环境数据相互污染多人同时在测试环境跑用例如果共用同一批测试数据常常出现数据相互覆盖。比如测试A在修改某菜品价格测试B同时在下单这个菜品订单金额就不可预期用例失败原因也说不清。我们的解决办法是为每个测试模块准备独立的数据集用户端用独立的测试账号组商户端用独立的档口账号订单数据使用前缀标识区分测试批次。写入测试环境前先执行数据清理脚本确保用例前置条件可控。这个操作虽然笨但是稳定。5.5 用例执行后维护的一点点经验最后说点个人体会。测试用例的核心价值是长期复用所以写的时候一定要想着后面的人能不能看懂。用例描述里尽量避免“选择某个菜品”“点击某个按钮”这种模糊表述要在前置条件里写清楚用的是哪个测试账号、哪家档口、哪个菜品、库存数量是多少。预期结果一定要可判定不要写“页面显示正确”这种无法验证的话。推荐用“页面显示文案支付成功订单号xxx出现在订单列表中商户端生成新订单提醒”这样的具体描述。每次迭代结束后我会抽时间做一次用例维护清除已经失效的用例更新被需求变更影响的预期结果补充本次迭代暴露出的回归用例。这套工作看起来不起眼但对测试效率的提升非常明显。坚持两三个迭代之后回归测试的执行时间能缩短三分之一左右而且重点链路的覆盖更稳了。做项目测试拼到最后就是拼用例资产的质量和可维护性。