校园里做点餐系统，听起来不算复杂，但真到了测试阶段，尤其当系统开始支撑几千人的同时下单时，你会发现测试用例的设计直接决定了线上会不会出事故。我之前就亲眼见过一个点餐系统，上线第一天就因为支付回调没处理好，用户扣了钱但订单没生成，食堂窗口排着长队，学生在群里炸了锅。那一次事故的根源，就是测试用例里漏掉了支付超时和回调失败的组合场景。所以别觉得写测试用例是走形式，它本质上是在用最低的成本模拟最混乱的现实。
我这次就以一个校园电商点餐系统的测试用例设计为主线，把从业务拆解、用例设计方法、核心模块实操到跨项目复用维护的完整思路都梳理一遍。文章里会直接给出可以抄作业的用例模板和参数设计思路，也会把我踩过的坑和排查过程一并交代清楚。适合刚入行的测试工程师、正在做校园或垂直场景电商系统的开发者，以及想把自己的用例体系从“能用”升级到“可维护”的团队参考。
1. 校园电商点餐系统的业务场景拆解与测试挑战
测试用例不是凭空想出来的，它是业务模型的映射。一个系统如果连业务角色和状态流转都没梳理清楚，用例写出来一定是东一榔头西一棒子。
1.1 系统角色远比想象中复杂
校园点餐系统表面上只有一个App，但实际上背后有至少四类角色：学生用户、食堂/商家、配送骑手、平台管理员。每类角色都有自己的操作入口和权限边界，测试时必须分开覆盖。
学生用户端关注的是点餐体验，比如菜品浏览、加购、下单、支付、订单追踪、评价。商家端关注的是菜品上下架、库存管理、接单、出餐、结算。骑手端关注的是接单、取餐、送达确认。管理后台则负责用户管理、商家审核、订单监控、数据统计、优惠券配置。
这里有一个很容易忽略的点：角色的权限隔离。我见过很多测试用例只验证了“学生能下单”，却没验证“学生不能访问商家端的接单接口”。这类越权问题在下单、改价、退款接口上尤其常见。设计用例时，每一个接口和页面都需要同时设计正向用例和越权反例。
提示：校园点餐系统和普通电商有个本质区别——它的下单高峰期非常集中。午饭和晚饭时段会在短时间内涌入大量并发请求，这意味着测试用例不仅要覆盖功能正确性，还要专门设计高峰期下的并发、超时、降级场景。
1.2 核心业务链路与状态流转
点餐系统的核心链路可以归纳为：用户选菜→提交订单→支付→商家接单→出餐→配送/自取→完成→评价。这条链路里的每一个环节都有状态字段，比如订单状态有待支付、已支付、已接单、制作中、待配送、配送中、已完成、已取消、退款中、已退款。
测试用例必须覆盖所有合法流转和非法流转。什么是非法流转？比如已取消的订单不能再被商家接单，已完成的订单不能再发起退款，待支付订单超时后自动关闭但用户又点了支付按钮。这些场景一旦漏测，上线后就是客诉。
我在设计用例时，会把订单状态做成一个矩阵表格，横轴是当前状态，纵轴是触发动作，交叉点就是测试用例。比如当前状态是“已支付”，触发动作是“商家取消订单”，预期结果是“订单自动进入退款流程，用户收到退款通知”。这种穷举法看起来笨，但确实能把状态流转的坑全部填平。
1.3 测试用例设计的难点在哪里
校园点餐系统的测试难点有三块。第一，业务规则多。比如起送价、配送费规则、优惠券叠加规则、不同时段的营业状态等，这些规则组合在一起会产生大量分支。第二，第三方依赖重。支付接口、地图定位、短信服务，这些外部系统不受我们控制，测试时要考虑它们的各种异常。第三，迭代速度快。学校里的运营活动频繁，今天搞满减，明天搞新客立减，测试用例需要不断跟着变。
难点本身不是问题，问题是测试用例设计往往赶不上业务变化。后面我会专门讲怎么通过分层设计和管理策略来解决这些难点，这里先建立这个意识：用例设计不是一次性工作，而是跟业务一起生长的活文档。
2. 测试用例设计方法选型：不靠灵感靠套路
很多人问我测试用例怎么写，我的答案始终是：不要靠灵感，要靠方法。测试用例设计方法论有好几种，关键是选对合适的组合。
2.1 等价类和边界值：最基础也最容易被低估
等价类划分是把输入域划分成若干个子集，每个子集里的数据对测试来说都是等价的。比如手机号输入框，合法格式是11位数字，那就可以划分成有效等价类（11位数字）、无效等价类（10位数字、12位数字、包含字母、包含特殊字符、空值）。每个等价类只需要选一个代表值测试即可，这样能用最少的用例覆盖最多的情况。
边界值分析是等价类的补充，专门盯住边界上的数据。比如满20元起送，那19.99、20.00、20.01就是必须测的三个边界。配送费规则里，3公里内免费、超出每公里加1元，那3.0公里、3.1公里、2.9公里就得单独验证。
看起来很简单，但实际执行时有个经常犯的错：只测了输入框的边界，没测业务规则的边界。比如优惠券的“满30减5”，系统处理时可能用的是分而不是元，那29.99元和30.01元的边界测试就不能只在界面上做，还要看接口层的实际计算逻辑。
实操经验：设计边界值用例时，我习惯在Excel里单独建一个Sheet，记录每个规则的精确边界值、近似边界值和边界内外的值，然后统一标注数据构造方式。这样做的好处是，后续如果规则变了，只需要改这一个Sheet，用例就能自动映射到需要调整的范围。
2.2 场景法与判定表：对付复杂业务流程的组合逻辑
等价类和边界值解决的是单点输入的问题，但点餐系统里大量问题是组合逻辑产生的。比如用户下单时，不同时段、不同校区、不同商家类型、不同支付方式，会走完全不同的流程。
场景法就是用来覆盖这些业务流和分支流的。我会画出核心业务的流程路径图，把每一个分支都变成一条用例。拿支付来说，正常路径是用户支付成功→系统回调更新订单。分支路径包括：支付成功但回调延迟、回调成功但验签失败、用户中途取消支付、支付超时、重复支付、部分退款后再支付等。每一条分支都对应一条或一组用例。
判定表更适合处理多条件组合的场景。比如优惠券是否可用，取决于用户是否是新人、订单金额是否达标、是否在活动时间内、商家是否参与活动。把条件列出来，动作（用券/不用券/提示错误）列出来，组合起来就能完整覆盖。理论上4个条件有16种组合，但如果用判定表做，你会发现很多组合是矛盾的或不可能的，直接排除掉，大大节省用例数量。
2.3 测试数据构造的细节
好的用例设计离不开合理的测试数据。我见过太多团队测试数据就是随便填的“111111”，结果很多问题都测不出来。
构造测试数据时要贴近真实业务。学校点餐系统的菜品名称、价格、分类要有代表性，比如要有一个低价菜（0.5元米饭）、一个临界起送价菜品（正好卡在起送价上）、一个高价菜（超过单次购买限额）。用户账号也要分层级，普通学生、黑名单用户、有历史异常订单的用户、未绑定手机号的用户。
数据构造最麻烦的是支付相关。测试环境里不能用真实支付，一般用沙箱环境或者模拟网关。这种情况下，我建议在测试环境里把支付回调做成可配置的，比如可以设定回调延迟几秒、回调失败一次后再成功、重复回调等，这样能模拟出真实世界的各种异常。
另外，测试数据要和用例建立对应关系。每个用例里明确标注前置数据条件和数据构造步骤，这样不仅自己回归方便，后面做自动化测试时，脚本也能直接引用这些数据配置。
3. 核心模块的测试用例实操设计
这一部分我直接以校园点餐系统的关键模块为例，把用例设计的实操过程拆开来看。不同模块的测试侧重点不一样，掌握各自的套路，用例设计就会很顺手。
3.1 用户端：从注册登录到订单支付的完整链路
用户端的用例是整个系统的主体，也是日常迭代最频繁的部分。注册登录模块首先要测手机号验证码登录的完整流程，包括验证码发送、60秒倒计时重发限制、错误验证码提示、验证码过期处理、新用户自动注册、老用户直接登录。这里有个容易漏的点：同一手机号在不同设备上登录时，旧设备是否会被踢下线，token的失效策略是什么。
菜品浏览模块要考虑分类展示、搜索排序、库存显示。比如搜索关键词支持模糊匹配，搜索结果为空时要有兜底提示。库存显示要特别注意那个“仅剩1份”的临界状态，以及两个人同时点最后一份时，一个人下单成功后另一个人的页面要实时刷新。
购物车和下单模块是最容易出现业务逻辑错误的地方。购物车的价格计算涉及菜品价格、口味加价、打包费、配送费、优惠券抵扣。我通常会把价格计算单独拉一张用例表，列出所有加价项的排列组合，核对每一项在界面、接口、订单详情三个位置显示是否一致。
下单模块的重点是库存锁定和超时处理。用户提交订单后系统要锁定库存，但锁定时长和超时释放的规则需要明确。我测过一个系统，用户提交订单后不支付，30分钟后订单自动关闭，但库存已经提前释放了，导致用户在评论区看到有货却无法下单。这就是库存锁定规则与订单超时规则不一致导致的典型问题，用例设计时一定要把这两条规则的联动场景覆盖到。
支付模块的用例设计，核心在异步回调。我列的支付相关用例至少会包含：支付成功回调、支付成功但验签失败、支付失败、用户取消、支付超时、重复通知、通知丢失。每一类都要验证订单状态是否按预期流转、消息队列是否有重复消费、用户是否收到正确的通知。
3.2 商家端：菜品管理与接单出餐的状态流转
商家端测试往往被轻视，但商家端一出问题就是运营事故。菜品上下架模块，要测下架后用户在App端是否还能看到菜品、菜品的库存会不会被重置、已加购但未提交的购物车里下架菜品如何提示。上下架操作要同时覆盖单个操作和批量操作。
接单出餐模块是状态流转的重灾区。商家的接单状态包括待接单、已接单、制作中、出餐完成、配送中。这类用例我建议按照上面的状态矩阵来设计，重点是“已接单的订单能否被商家取消”和“出餐完成后能否修改菜品”。校园场景里经常有学生点了菜又不要了的情况，商家端取消订单后，退款是原路退回还是线下退，测试用例要先跟产品确认清楚，再落地成预期结果。
商家端还有一个核心点是店铺营业状态。营业中、休息中、打烊前30分钟不可下单，这些状态变化要即时同步到用户端。如果商家休息中，用户还能正常下单，那就等着被投诉吧。测试用例里这个场景一定要写，而且要有实时性和缓存机制的验证。
3.3 管理后台：数据一致性与权限控制
管理后台的测试用例设计，最核心的两个词：权限和控制。权限是指不同角色（超级管理员、运营、财务、客服）能看到的菜单和数据范围不同。我见过一个后台系统，普通客服账号能访问财务模块的导出功能，数据全部泄露。所以权限用例必须覆盖功能权限和数据权限两层：A角色不能访问B角色的接口，A角色只能看本校区的订单数据。
数据一致性是另一个重点。后台的订单统计报表，下单数、支付数、退款数、实收金额，这些数据要和数据库里的明细对得上。测试时要设计特定数据，比如今天有10单支付、2单退款，验证报表显示是否准确。还有一个很隐蔽的点：数据倾斜。比如某个食堂订单量特别大，后台列表分页加载时会不会超时、会不会丢数据、排序是否正确。
优惠券配置也是后台的高风险功能。创建满减券、新人券、折扣券时，有效期、适用商家范围、发放数量、每人限领数、叠加规则，这些参数组合起来非常多。我会用判定表来设计这部分用例，把优惠券的创建条件分解成列，把用户可以领取/使用的条件分解成行，交叉组合后再剔除矛盾项。
4. 用例管理、复用与维护：多项目迭代下的生存之道
测试用例写得好不好，不仅要看单个用例的质量，还要看整个用例体系能不能在复杂的迭代中活下来。这里说的“活下来”，是指面对不同项目组的需求变更、功能复用、人员流动时，用例仍然清晰、可用、有价值。
4.1 用例分层与模块化设计
我强烈建议把用例分三层：UI层、业务层、接口层。UI层用例关注界面展示和交互，比如按钮显示、页面跳转、错误提示的文案。业务层用例关注业务流程和规则，比如下单成功后订单状态流转、支付回调更新订单。接口层用例关注数据交互和异常处理，比如参数校验、鉴权失败、服务端异常。
分层的意义在于复用。不同项目组迭代时，UI层改动频繁，但业务层和接口层相对稳定。如果三层混在一起，一旦前端重构，整个用例集都要重写。分层之后，UI层用例单独维护，业务层和接口层用例可以沿用。比如学校新增了一个食堂，UI层的页面可能不变，但业务层增加了新食堂的下单规则，这时只需要新增业务层用例，UI层和大部分接口层用例都能复用。
模块化设计也很重要。把用例拆成可组合的最小单元，比如“登录”、“加购”、“提交订单”分别是独立用例，然后通过用例组合的方式拼出完整业务流程。这样当某个模块逻辑变了，只改对应模块的用例，引用它的流程用例会自动感知。
4.2 标签体系与可追溯性
用例规模大了以后，检索和维护就成了痛点。我用的办法是给每条用例打标签。标签维度包括业务模块（注册、下单、支付）、优先级（P0冒烟、P1核心回归、P2常规、P3低频）、测试类型（功能、接口、兼容、性能）、关联需求版本。
标签体系最大的价值是支持快速筛选。比如发版前要做冒烟测试，我只需要筛出P0且模块属于核心链路的用例，一键生成冒烟用例集。比如支付模块最近改动了接口，就可以筛出所有带“支付”标签的用例做全量回归。
可追溯性是指每条用例都能追溯到需求来源。我习惯在用例里加一列“需求单号”，这样测试发现失败时，能立刻知道是哪个需求改动导致的。到了复盘会上，这个字段能帮你快速定位问题责任人，不扯皮。
提示：用例管理工具不一定要多高级。最开始我们用Excel，后来换到TestRail，再后来是用开源的MeterSphere。工具只是载体，真正决定用例是否好维护的是模块拆分是否合理、标签是否规范、是否定期清理失效用例。工具迁移时，只要用例结构设计得好，导出导入就非常顺畅。
4.3 用例评审、基线管理与定期维护
用例评审是保证质量的关键环节。每次重大迭代，我都会拉着开发、产品、测试三方一起过用例。开发和产品往往能补充很多业务细节，比如某个状态异常是不会出现的、某个接口的错误码是固定的，这些信息能帮你剔除多余的用例，也能帮你写出更准确的预期结果。
基线管理针对的是用例变更。建立了基线之后，任何人要修改用例都要走变更流程，不能悄悄改，不然回归时出了问题根本不知道是不是用例本身错了。基线的意义在于让“这次和上次相比变化了什么”变得可控可查。
定期维护主要是清理死用例和过期用例。我每两个迭代周期做一次用例清理，把业务上已经废弃的用例标记为“过时”，把参数已经变化的用例更新到最新规则。这个过程有点枯燥，但非常必要。不清理的后果就是用例集越来越大，每次回归执行时间越来越长，而且失败的用例里有一大堆是“用例本身过时了”，严重消耗团队信任感。
5. 从测试用例到自动化脚本的进阶之路
现在聊一个热词：从测试用例到自动化脚本。很多团队已经有playwright、selenium、appium这套东西了，但落地效果天差地别。差别在哪？在于用例设计阶段有没有为自动化铺路。
5.1 用例设计如何为自动化铺路
要让测试用例能被自动化脚本稳定执行，用例本身需要具备三个特点：步骤可编程、数据可参数化、预期可断言。
步骤可编程的意思是用例里的操作步骤要尽量原子化。比如“添加一份黄焖鸡米饭到购物车”和“点击去结算”是分开的步骤，不要写在一起。每个步骤可以对应到代码里的一个动作，这样写脚本时就能直接映射。
数据可参数化是指用例里的测试数据不要写死。比如“手机号13800138000”作为测试账号，脚本里可以用变量引用。如果用例设计时就把数据和步骤分离，自动化脚本的数据驱动模型就很容易建立。
预期可断言是指每条用例的预期结果要具体、可验证。不要写“用户看到下单成功页面”这种模糊的描述，要写“页面出现订单号且订单状态为待支付，接口返回orderId和status=1”。这样脚本断言时才有明确的判断依据。
5.2 Playwright等工具的落地实践
Playwright现在是我做Web端自动化测试的主力工具。它的优势在于自动等待机制非常完善，基本上告别了强迫症式的sleep。另外它支持多浏览器并行，对测试效率的提升很明显。
在点餐系统的自动化实践中，我把核心链路脚本分成了几个独立的spec。用户下单流程的脚本会复用登录接口的token，而不是每跑一次都走一遍验证码登录。菜品列表的脚本会用内置的mock数据替换真实接口，避免测试数据不稳定导致断言失败。
这里我走过一个弯路：一开始过于追求case数量，把几十个用例全塞进自动化回归集里，结果每次跑都有三五个失败是环境问题。后来我把自动化用例分成冒烟集和回归集，冒烟集只跑核心链路，控制在10分钟内跑完；回归集跑全量，每天晚上定时跑，第二天早上看报告。稳定性明显好了很多。
实操心得：自动化脚本的维护成本比编写成本高得多。前端页面只要按钮文案变了，xpath和text定位就全挂了。我建议优先用data-testid或者text属性等相对稳定的定位方式，少用嵌套层级很深的css选择器。我们团队内部还定了规矩：前端开发在关键按钮上必须埋data-testid属性，否则测试不验收。
5.3 AI辅助生成测试脚本的探索
最近有个趋势，用AI根据测试用例生成自动化脚本。基于LangChain这类框架，把自然语言描述的测试用例解析成可执行的playwright脚本，这个方向已经有了落地雏形。
我试过其中一个开源方案，把测试用例Excel导入，AI会解析出操作步骤和预期断言，然后生成对应的Python脚本。对于简单用例，生成质量还不错，但遇到多条件分支、动态数据、复杂断言，AI生成的脚本还是需要人工修改。
我的观点是，AI目前适合做“翻译器”，把用例步骤变成脚本骨架，但脚本的稳定性和容错处理，还是得靠有经验的测试工程师来调优。不要指望AI完全替代写脚本，但善用AI确实能把编写工作量减少一半左右。
另外提醒一下，AI生成脚本的质量高度依赖用例描述的结构化程度。如果你用例本来就是“输入手机号，点击验证码，点击登录”这种结构化短句，AI生成效果会很好；如果你写的是“用户输入正确的手机号并完成登录，验证页面展示正常”这种口语化混在一起的描述，AI就很难处理。所以想要走AI辅助这条路，前提还是把用例设计得足够规范。
最后分享几个小经验
回到开头的场景，那次支付回调漏测的教训，让我后来养成了一个习惯：每写一组用例，都逼着自己问三个问题——这个功能的正常路径是什么，异常路径有哪些，异常恢复后用户看到的是什么。这三个问题问完，用例的质量基本就有保证了。
还有一个习惯是关于用例评审的。评审时不要只对着Excel念用例，最好现场把核心流程手动走一遍。我经常发现评审时大家觉得“没问题”的用例，手动走一遍就发现预期结果根本不对。纸上的用例和真实运行的系统之间，永远有道鸿沟，测试要做的事情就是不断把这个鸿沟填小。
校园点餐系统虽然是个垂直场景，但它背后的测试方法论可以复用到其他电商系统、预约系统、外卖平台。你把这里的用例设计逻辑吃透了，换一个系统，只是换了一套业务规则和状态流转，方法论是通用的。这也是我为什么建议新人从写用例开始，而不是一上来就学自动化工具——用例设计能力是测试的核心内功，自动化只是把内功变成招式的工具而已。
