验收当天才发现问题，是最贵的问题。等服务商把项目打包交付，你再从头摸索哪里不对，时间紧、心态急，多半就签了，丑话说在纸面上，比事后追责体面得多。老练的客户会在开发中期就开始写验收用例，小程序定制的交付质量，一半取决于这份用例表。
验收用例不是测试报告
很多客户把这两样搞混。测试报告是服务商出的，证明他自己测过了；验收用例是你写的，代表你的业务能不能跑通。两者视角完全不同。一份合格的客户侧验收用例，来源是你自己的真实业务：一个老顾客完整下一次单会经过哪些步骤，店员后台配一个新商品要点几步，把这些日常动作一条条列出来，就是最实用的小程序定制验收用例。
写法不用专业工具，一张表格就行。三列足够：操作步骤、预期结果、实际结果。比如，用九折会员身份购买两件商品，预期支付金额为原价九折且积分增加相应数值。写二十到三十条，覆盖你业务的八成场景，这个量一个下午就能整理出来。用例里别只写顺利的路径，故意输错一次密码、在支付页面直接关掉小程序再回来、库存只剩一件时两个人同时下单，这些捣乱场景才是系统质量的真实考验，顺路径人人会测，乱路径才见真章。
什么时候开始写
最佳时点是原型确认之后。功能清单定稿了，你对系统将有什么能力有了准确预期，这时候写用例，写的是将来真实要用的东西。写完交给服务商看一眼，让他们标注哪些用例在当前功能范围内、哪些超范围，超范围的部分当场谈，是砍掉还是加钱补上，白纸黑字定下来。比格网络的客户里有几位用了这招的，交付日基本一遍过。
交付日用例怎么跑
正式验收别只在自己办公室点，拉上真实的店员、客服甚至两三个老客户，按用例一条条过。每一条当场填实际结果，通过的打钩，不通过的截图记录。全部跑完，问题清单当场分类：影响下单支付的一类，必须修完再验收；体验类问题二类，约定一周内修复。分类之后再谈签字，签得踏实。用例跑完别当场散会，双方把问题清单过一遍并确认修复时限，这一步省了，后面容易各说各话。
两条建议：验收用例在原型定稿后一周内动笔，别拖到交付前；验收当天按用例跑完再签字，签字页附上用例结果作为凭证。提前一小时准备，省掉后面一个月的扯皮，这笔账怎么算都划算。
