企业做微信小程序，到了开发后期经常会出现一种错觉：页面都能打开，按钮也能点击，功能看起来已经差不多，就可以准备上线了。实际上，小程序真正容易出问题的地方，往往不是首页少一张图片，也不是某个按钮颜色不对，而是不同用户进入以后看到了不该看的数据、订单状态走不下去、预约时间发生冲突、支付失败以后没有正确回滚、工单已经关闭却还能继续修改。
小程序测试真正要验证的，不是“这个功能能不能用”，而是“不同用户在不同状态下做不同操作时，系统是不是仍然按照正确规则运行”。
对于商城、预约、会员、售后工单、经销商协同和企业内部管理等定制项目，如果只按照页面逐个点一遍，很难发现真正影响上线后的业务问题。
一、先测权限，而不是先测页面
很多企业小程序都不是只有一种用户。
一个售后系统里可能有客户、客服、工程师、部门负责人和管理员；经销商系统里可能有普通经销商、区域负责人、业务人员和总部管理员；内部管理小程序则可能按照部门、岗位、区域和项目设置不同权限。
这时候测试首先要确认的不是“每个页面能不能打开”，而是：
谁能打开这个页面，谁不能打开；打开以后能看到哪些数据，又不能看到哪些数据。
例如一个售后工程师登录以后，正常情况下可能只能看到分配给自己的工单。如果因为权限判断遗漏，他能够通过修改URL参数、切换查询条件或者接口请求看到其他工程师的客户信息，那么页面表面上虽然正常，实际上已经存在严重的数据权限问题。
经销商系统同样如此。南京区域经销商如果只能查看南京区域客户，就要分别测试：
正常列表里是否只显示南京客户；
搜索时会不会搜到其他区域客户；
订单详情接口是否还能直接打开其他区域订单；
导出数据时有没有突破权限；
后台人工调整区域以后，旧数据权限是否同步变化。
权限测试必须同时看页面权限和数据权限。
只隐藏按钮并不代表真正限制了操作。如果前端没有“删除订单”按钮，但用户仍然能够通过接口调用删除数据，这个权限仍然是不完整的。
因此企业验收小程序时，最好准备几种不同身份的测试账号，真正按照实际角色登录，而不是所有功能都使用管理员账号测试。
二、再测状态，因为大量业务问题都出现在“上一环节和下一环节之间”
定制小程序通常都会存在状态。
订单可能有待付款、待审核、待发货、已发货、已完成、已取消；
预约可能有待确认、已确认、已到店、已完成、已取消；
工单可能有待受理、待派单、处理中、待复核、已关闭；
审批可能有待提交、审批中、通过、驳回、撤回。
很多系统开发完成后，单独看每个状态页面都没有问题，真正出错的是状态之间的转换。
例如：
已经取消的预约还能不能再次确认；
已经关闭的工单还能不能继续上传维修结果；
订单退款以后积分有没有退回；
审批已经通过以后还能不能重复审批；
预约时间已经被别人占用，另一个用户还能不能同时提交；
商品已经下架，但购物车里的旧商品还能不能继续结算。
这些问题都属于“状态边界”。
所以测试不能只走一次正常流程。
例如测试预约小程序，不应该只测试：
选择时间 → 提交预约 → 后台确认 → 完成。
还应该测试：
用户提交以后马上取消；
管理员确认以后用户再取消；
同一个时间同时有两个人预约；
服务人员临时停班；
预约时间已经过去但状态仍然是待确认；
管理员修改资源数量以后已有预约如何处理。
正常流程证明系统能运行，异常流程才真正决定系统能不能长期运行。
三、支付、库存、积分和消息，要重点测试“失败以后怎么办”
涉及交易的小程序尤其容易出现这种问题：开发人员把“成功流程”做得很完整，但失败情况处理不够。
例如用户点击微信支付以后，可能发生：
支付成功；
用户主动取消；
支付超时；
支付完成但回调延迟；
网络断开；
用户重复点击支付；
支付成功以后页面没有及时刷新。
如果系统只考虑“支付成功”这一条路径，就可能出现用户已经付款但订单仍显示未付款，或者一个订单产生两次业务处理。
库存也一样。
假设一件商品只剩最后1件，同时有两个人提交订单，系统应该在什么时间扣库存？创建订单时、付款时，还是审核通过时？订单取消以后库存是否自动恢复？这些规则不同企业可以不一样，但必须在上线前明确并测试。
积分同样需要测试失败场景。
订单付款送积分，退款以后积分是否扣回；如果用户已经把积分花掉再申请退款怎么办；后台人工调整积分是否留下记录；积分过期以后历史记录是否仍然可查。
消息通知也不能只测试“能不能收到”。
更重要的是：
什么状态发送通知；
发送给谁；
重复操作会不会重复发送；
发送失败是否影响主业务；
客户和内部人员收到的内容是否不同。
涉及钱、库存、积分和数据变化的功能，测试重点应该放在“业务没有按预期完成时，系统如何恢复正确状态”。
四、管理后台必须单独测试，因为很多小程序真正复杂的是后台
企业验收时容易把注意力全部放在手机端，实际上很多定制项目真正长期使用的是管理后台。
例如会员小程序前端只是查看等级、积分和订单，但后台需要维护会员、调整等级、处理异常积分、查看消费记录和配置权益；
售后小程序前端只是提交报修和查看进度，但后台要受理、派单、调整负责人、统计工单和查询设备历史；
经销商小程序前端负责产品和订单，但后台还涉及经销商等级、区域、价格、客户归属和订单审核。
后台至少要测试几类问题：
大量数据以后列表是否还能正常查询；
搜索和筛选条件是否正确；
删除数据是否存在关联影响；
修改产品以后历史订单是否被改变；
管理员误操作以后有没有必要的提示；
Excel导入出现错误数据时如何处理；
导出内容是否符合当前角色权限；
图片、附件和资料长期积累以后如何管理。
例如产品后台如果删除一个已经产生大量历史订单的产品，系统是允许直接删除，还是改成停用？通常后者更合理，因为历史订单仍然需要保留当时的产品信息。
这类问题如果没有在开发阶段设计好，上线以后企业管理员第一次真正维护数据时才会暴露。
所以小程序验收不能只有一句：
“手机端都测试过了。”
还应该专门安排一次后台操作测试，让以后真正负责运营、客服、销售或者售后的人员参与，而不是只由开发人员自己验证。
五、上线前最好准备一份“真实业务测试清单”
企业验收小程序，最有效的方法不是让十个人随便点，而是按照真实业务准备测试案例。
例如售后工单小程序，可以准备：
正常客户提交报修；
不存在的设备编号提交报修；
同一设备连续提交两次；
客服派给工程师A；
再改派工程师B；
工程师提交维修结果；
客户未确认；
管理员主动关闭；
客户再次查看历史记录。
预约小程序则可以准备：
正常预约；
同一时间冲突；
取消预约；
修改时间；
会员优先预约；
资源停用；
超时未处理；
管理员后台补录预约。
经销商系统可以测试：
不同等级登录；
不同价格显示；
跨区域数据；
特殊协议价；
提交订单；
订单审核；
取消订单；
ERP同步失败。
把这些测试案例写下来以后，每次系统修改都可以重新检查一遍，这实际上也是后续版本升级的重要依据。
南京安优网络科技有限公司面向南京企业提供微信小程序定制开发，在项目实施过程中除前端页面和管理后台开发外，还会根据实际业务对用户角色、权限、状态流转、数据关系和异常流程进行梳理，并在上线前进行功能测试和业务流程验证。对于商城、预约、会员、产品查询、售后工单、经销商协同及企业内部管理等不同类型项目，测试重点也会根据真实业务发生变化，而不是使用完全相同的验收清单。
企业判断一个小程序能不能上线，不能只看“正常操作能不能完成”，更应该看用户操作错误、网络异常、状态冲突、权限变化和业务失败以后，系统还能不能保持数据正确。
真正成熟的小程序测试，不是证明程序“多数时候能用”，而是尽可能提前发现那些上线以后最容易影响客户、员工和企业数据的问题。
上一篇：南京企业做巡检小程序，真正要设计的是异常闭环：扫码、拍照、整改和复核怎么连起来？
下一篇：没有了