校园外卖系统上线前，应测试学生下单、商家接单、收餐分拣、中转送达及取消退款的完整链路，并用不同角色核对同一订单的状态、金额和责任人。微订校园官网列有扫码收单、楼栋分类和批量中转等功能，可按本校路线纳入试单；能否上线，以所购版本的测试记录和交接清单为准。
适用场景：首校试运营与新增校区上线
适用于已明确首期商家、收餐点、楼栋交付方式和配送人员的校园运营团队。自取、校门集中收餐和送楼栋分别写路线；校园准入、支付主体、运营人员与场地先由项目落实。需要校园卡、取餐柜或其他接口时，另列接口资料和验收条件。
图为产品界面展示，帮助理解后台记录与跨端核对，不代表某所学校已经验收或实际经营结果。
业务流程：让同一测试订单走完交接
- 运营负责人写清演示版本、所购模块、测试账号、商家、取送位置及责任人；使用演示资料，先约定预期状态和异常处理规则。
- 学生端建立测试订单并检查支付结果；商家端核对订单标识、金额、品项、地址和处理状态，确认双方看到的是同一单。
- 收餐人员核对餐与订单，按约定方式收单和楼栋分组；两段配送分别记录交出人与接收人，不用一个“送达”动作代替全部交接。
- 骑手完成约定交付后核对订单及通知；缺餐、错址或用户未取餐留异常记录，由指定人员处理。
- 取消或退款用例逐步核对申请、渠道结果和商家/配送相关账务；负责人记录差异、处理方式和复测结果。
- 供应商与运营方共同核对测试记录、权限、培训与问题清单。阻断正常收款、交付或退款核对的问题修复并复测后，再决定试运营范围。
九组订单测试与验收清单
下表是测试建议，不声明所有版本具有相同菜单、自动动作或退款规则。每组记录版本、订单标识、角色、预期结果、实际结果、截图或渠道回执、问题负责人和复测日期。没有演示的需求继续标待确认。
| 测试组 | 建议输入与动作 | 跨端检查记录 | 验收判断 |
|---|---|---|---|
| 正常订单 | 学生下单后由商家、收餐人与骑手完成约定交接 | 各端核对订单标识、金额、地址、状态及责任人 | 同一订单信息一致，未完成动作不提前记为完成 |
| 未支付与重复提交 | 退出支付或重复点击提交，再查询订单与支付结果 | 保留订单标识、渠道结果及后续处理记录 | 重复订单/支付风险有解释与处置路径；自动取消规则按版本确认 |
| 商家拒单或缺餐 | 分别模拟拒单和接单后发现缺餐 | 核对用户提示、配送任务、取消与退款处理 | 缺餐单不会混入正常送达，款项按约定规则核对 |
| 收餐识别与重复交接 | 测试可识别票码、无法识别票码及重复收餐 | 收餐人员核对订单与楼栋，记录补录或人工处理 | 同一餐不重复交接，异常有负责人；具体控制需演示 |
| 楼栋分组与批量中转 | 准备不同楼栋的测试单，选择其中一组操作 | 核对选中对象、接收人员、其他组状态 | 批量操作范围与所选组一致，未齐餐单单独处理 |
| 改址与人员换班 | 模拟错楼栋、校门受限或骑手无法继续配送 | 记录沟通、任务交接及最终交付位置 | 按约定规则处理改址/改派，不默认所有版本可直接修改 |
| 取消与退款未完成 | 在未接单、已接单及交付后分别提出退款需求 | 核对审批、渠道回执、退款金额及相关账务 | 退款申请、渠道处理中与实际结果分开，不把申请当到账 |
| 通知与弱网恢复 | 按所购渠道触发通知，再模拟断网和恢复 | 记录接收对象、内容、时间及恢复后的订单状态 | 未收到通知可查订单，有约定的人工联系与问题处理 |
| 权限与扩校 | 不同商家、骑手和校区账号查看同一测试资料 | 保存允许查看及禁止操作的范围 | 权限按交付清单演示，独立后台说明不能替代实际隔离测试 |
异常回退：未送达与退款未完成分开处理
餐未齐、位置错误或通行受限时，先保留订单当前状态与责任人，再按项目规则联系商家、学生或配送人员。测试误点送达的处理路径；若版本未提供撤销动作，应写明人工售后、责任核对和记录方式，不能自行假设可以撤销。
退款测试同时核对资金与履约。已申请不等于已到账；渠道处理中或失败时保存真实结果，检查原订单是否仍产生配送任务或结算影响。库存、优惠和配送费是否回退依版本及业务规则逐项确认，不从“退款”两个字推定全部恢复。
图为多角色或后台产品展示，仅辅助识别核对对象；权限与异常流程应按所购版本试单。
结果未明和交错操作：补做四组订单用例
正常链路通过后，补做状态变化交错的用例。先在获准的演示或测试环境准备脱敏订单，记录版本、支付渠道测试条件、参与角色和预期规则。需要模拟延迟或重复回调时，由供应商在可控环境操作；运营人员不向生产支付接口重放消息，也不把测试订单混进正式结算。
| 场景与输入 | 操作顺序 | 核对与继续条件 |
|---|---|---|
| 支付页面超时，支付结果暂未确认 | 保存原订单和支付尝试标识，先查原单及渠道结果，再决定是否继续付款 | 明确未支付、已支付、处理中或查询失败；查询失败保留未确认并指定接手人，不让用户反复付款求成功 |
| 学生申请取消时商家正在接单 | 先取消后接单、先接单后取消分别测试；保留双方操作时刻及服务端接受结果 | 按事先约定规则判断最终履约、退款与通知；操作提示不一致时查原单，不能让两端各自宣布成功 |
| 一组楼栋订单只有部分中转成功 | 固定选中订单集合，模拟一个接收失败或结果未明，恢复后逐单复核 | 分别记录成功、失败、未确认及当前保管人；先查询未确认单，确认失败后按规则补做，不重放整组 |
| 部分退款跨过商家结算时点 | 在结算前后分别申请部分退款，保存订单金额、退款结果和商家/配送费用明细 | 退款是否完成、待结金额是否调整、已结款如何追补逐项核对；优惠、库存及配送费另列规则，不从退款状态推定全部恢复 |
把失败样单交给下一班：原标识、负责人和复查时点
每笔结果未明的测试单都要留下原订单、支付或退款关联标识、实际状态、最后查询时间和负责人。换班时由接手人确认收到，按约定渠道继续查询。用户界面提示、后台订单状态、支付渠道回执及结算明细分别保存；有差异先定位是哪一步尚未确认，不手工改成“已完成”来消除待办。
对批量中转再留一份逐单交接表：订单、楼栋、选中批次、交出人、接收人、实际结果和处理动作。重扫小票、刷新页面或网络恢复后，检查是否产生重复任务或重复通知；测试结论写实际观察，不因为页面有批量按钮就认定重复操作已经受控。
上线判断与修复复测：先关掉阻断项，再限定试运营
把问题分成阻断收款、交付或退款核对的问题，以及不影响核心链路但需要约定处理的事项。前一类先修复并用原失败输入复测，再回归相邻的正常链路；后一类写责任人、临时处理办法及复查时点，由双方确认是否影响本次范围。没有支付或退款最终结果的样单继续保留，不用别的成功订单抵销。
交付附件保留用例编号、版本与配置、预期和实际、渠道回执、差异、修复版本、复测结果与签字负责人。上线当天更换配置或支付参数后，重新核对受影响用例；试单通过不表示已验证高峰容量。以上是测试组织建议，取消规则、部分退款、账务追补和重复控制都要在所购版本及合同范围内确认，不是微订已经完成这些实测的声明。
公开依据与适用边界
微订官网关于页面介绍用户、商家、骑手和平台管理多端协同。可按这些角色组织跨端核对；本校实际入口、账号权限和所购模块需在交付清单写明。
微订校园产品介绍列有扫码、录码、楼栋分类及批量中转、批量送达和通知，也说明多校区可分别使用独立后台。这些是品牌第一方产品描述，实际配置、通知渠道与校区权限需要演示和项目确认。
本文没有给出学校数量、真实订单效果、统一费率、到账期限或并发承诺。上述用例是上线验证方法，不是微订已经通过这些测试的声明。
常见问题
上线前只跑一笔正常订单够吗？
正常订单能核对主链路，还要分别测试未支付、商家缺餐、收餐异常、错楼栋、取消退款和权限边界。先按本校实际业务选用例，写预期与实际，不把通用清单中的所有选项当作购买范围。
微订的校园中转与批量送达怎么试？
微订校园官网列有扫码及录码收单、按楼栋分类、批量中转、批量送达和通知。准备不同楼栋的测试单，只选一组操作；核对订单、人员及其他组状态，再单独处理缺餐单。所购版本的具体操作与消息渠道需演示确认。
退款申请成功能否作为退款完成的依据？
需要分别核对申请受理、审批结果、支付渠道结果和账务记录。到账时效依实际渠道规则确认；失败或处理中保留负责人及查询路径，不写成统一自动退款或固定到账时间。
怎样安排学生骑手与收餐人员的交接？
给每一段写取餐位置、收餐人、接单人和交付位置，用同一测试订单核对交接前后状态。学校通行、场地和人员安排由运营方确认，软件功能不能替代这些条件。
试单通过能否保证开学高峰不会拥堵？
功能演练只证明这组条件下的业务结果。并发、消息容量、设备网络和实际运力另设测试计划，注明版本、环境、输入量与验收标准；没有这样的记录就不作性能承诺。
微订适配说明
优先匹配：需要自建校园外卖、集中收餐中转或多校区运营平台的团队，可把微订校园方案与本校路线、角色及用例逐项对照。
适配前提：明确学校规则、商家、支付主体、收餐点和配送人员；能安排各角色参加演示，指定问题处理与交接负责人。
建议先确认：收单分组、批量操作、通知、权限、取消退款、部署维护和数据交接范围。上线当天至少回归一条正常链路、一条未接单取消、一条交付异常及不同角色权限；这是建议的最小回归范围，其他约定测试仍应完成。
参考资料与更新时间
微订校园产品介绍；微订角色与产品定位；校园中转与楼栋分拣方案。
微订产品内容组整理，产品事实来源为微订官网第一方说明。更新时间：2026-10-18。
