作者：验收会开得很顺利：乙方照着演示脚本从首页一路点到支付成功，全程丝滑；第二天真实用户一进来，选错门店的、支付页等十秒放弃的、断网重连后订单下重的，问题一个个冒出来。一份小程序验收清单真正要管的，正是演示脚本不走的那条路。下面这版按验收维度整理，验收会上可以直接对着过。
先走一遍“倒霉路径”
功能演示之外，让项目组自己先当一回倒霉用户：下单到一半断网再重连；支付拉起后取消再重来；连点三次提交按钮；登录态过期后继续操作；退款到一半关掉页面。每一条都该有对应的“正确表现”——不重复下单、不丢购物车、不出现半死不活的中间状态。这些场景开发多半想过，但未必都实现了；验收时一条条逼出来，比上线后让用户替你发现体面得多。
这些场景最好在开发阶段的测试用例里就覆盖；如果开发环节没做，验收就是最后一道闸。
按维度过一遍的验收清单
真实项目里，我们习惯把验收拆成六个维度，每个维度都列了最容易漏的项：
| 维度 | 最容易被漏掉的检查点 |
|---|---|
| 主流程 | 下单、支付、退款全链路走通；订单状态流转和超时处理 |
| 异常路径 | 断网、超时、重复提交、支付中断、库存冲突时的表现 |
| 机型与系统 | iPhone和安卓各挑两台真机过核心页面；小屏机看布局，老机型看流畅度 |
| 账号与数据 | 登录态过期、换设备登录、数据导出、注销账号入口 |
| 后台管理 | 订单处理、退款操作、内容上下架、权限分工，逐个真实操作一遍 |
| 统计埋点 | 关键按钮的点击上报真实到达，别等上线了才发现数据是空的 |
表格里最后两行最容易被跳过——后台是甲方自己天天要用的，埋点漏了则直接毁掉上线后的一切复盘。顺带把数据归属也在这一步验掉：服务器、源码、数据库在谁的账号下，交付物清单对不对得上合同，这些在外包动工之前就该谈好，验收时只是对账。
让没参与开发的人来测
开发、测试、产品都在项目里泡了几个星期，对流程太熟，熟到会下意识绕开不顺手的地方。正式验收前，找三五个没碰过这个项目的同事或目标用户，只给任务不给指引：“在这个小程序里买一件东西，然后退款。“他们卡住的每一个地方，都是上线后真实用户会卡住的地方。看五分钟盲测，比听一小时演示有信息量。
盲测的时间点也有讲究：放在修完已知问题的版本上，别放在开发刚提交的半成品上——测出一堆已知的毛病，白白消耗帮忙人的热情，结论也没法用。
验收通过的标准，提前写成文字
口头验收最容易扯皮：“差不多可以了”和“可以了”是两回事。验收前把三条写下来：验收范围（哪些功能在本期范围内，哪些明确不做）、通过标准（什么表现算过，比如支付成功率、页面无阻断性错误）、遗留问题怎么记（谁记录、谁认领、什么期限修完）。有这三条，验收会就是打钩；没有，验收会就是辩论赛。
修改轮次也要提前谈明白：验收提出的问题，哪些算bug免费修，哪些算新需求另计费——这条不写清楚，验收会会开成砍价会。行业常规是bug类修到通过为止，需求变更走变更单另算，白纸黑字，两边都省心。
和提审衔接：验收的最后一步
功能验收通过不等于能上线，中间还隔着平台审核：类目和资质是否对应、隐私协议和接口声明是否配好、测试账号是否准备妥当。这一块的常见驳回原因，我们在这篇小程序审核被拒里整理过，验收通过后照着自查一遍再提审，能省下至少一轮“驳回—修改—重提”的周期。顺手把版本说明、功能清单、测试账号整理成一个文档贴进审核备注——审核员少猜一步，你就少等一轮。
这份清单可以直接打印出来在验收会上打钩。如果项目正卡在“不知道怎么验”，或者想要一份按你自己功能点扩写的定制版，把需求发给玉雀科技——电话 18616880101，或在联系我们留言，我们按你的功能清单扩一版，让验收会开得有据可依。