唐山小程序开发：上线前我必做的几项测试

上周帮唐山本地一个做烘焙连锁的客户做上线前最后一轮测试，老板在旁边看我拿着三台手机来回切换，问了句：“不就是点一点看看能不能用吗？”我笑了笑没解释，等测到支付回调那一步，他那台旧安卓机上果然卡住了——微信支付成功后，订单状态没同步。如果直接上线，客户付了钱却看不到订单，第二天就得炸锅。

这就是我为什么坚持：小程序开发测试不是走流程，是替真实用户提前踩坑。我是知码客，常年在唐山做小程序和 APP 开发，今天就把自己项目里那套测试清单摊开讲讲，都是踩出来的经验。

先搞清楚：你在测什么

很多团队把测试理解成“功能点一遍”，其实小程序有三层东西要分开看：

• 逻辑层：业务对不对，比如下单、核销、退款、会员积分。
• 渲染层：界面在不同机型上是否错位、字体是否溢出。
• 平台层：微信登录、支付、订阅消息、地理位置这些依赖微信生态的能力。

第三层最容易被忽略，也最容易在唐山本地场景里翻车。比如给唐山一家做社区团购的客户做小程序，自提点定位用的是 wx.getLocation，在写字楼里测试一切正常，结果团长在老旧小区地下室开团，定位漂移了三百米，用户找不到自提点。后来我们加了手动选点兜底，才把这个问题压下去。

真机测试，别只信开发者工具

开发者工具很好用，但它模拟不出真实网络和真实性能。我的习惯是至少准备这几台设备：

• 一台两三年以上的安卓中低端机（唐山本地用户里这类机型占比不低）
• 一台 iPhone，重点看安全区适配和键盘弹起
• 一台平板或大屏手机，检查 rpx 布局会不会被拉变形

网络也要模拟。用 Chrome DevTools 的弱网限速还不够，最好在真机上切到 3G 或者手动限速，观察首屏白屏时间。之前一个唐山本地的预约类小程序，首页接口串行请求了四个，弱网下要等五六秒，用户早划走了。改成并行加骨架屏之后，体感好了很多。

// 串行改并行的小例子
const [banner, notice, list] = await Promise.all([
  api.getBanner(),
  api.getNotice(),
  api.getList()
]);

支付和登录，必须走完整链路

这两块是事故高发区，我的原则是：不用测试账号走通一遍，不算测完。

登录

• 首次授权、拒绝授权后再进入、清除缓存后重新进入，三种路径都要走。
• 检查 code 换取 openid 失败时的兜底提示，别让用户卡在空白页。

支付

• 正常支付、取消支付、支付超时、重复点击支付按钮，四种情况都要覆盖。
• 重点看支付回调：前端 success 回调不代表订单一定成功，最终要以服务端回调为准。我一般会在支付成功后主动轮询一次订单状态，避免用户看到“支付成功”但后台没入账。

唐山有个做本地生活服务的客户，早期版本就是只信前端回调，结果遇到一次微信回调延迟，用户重复下单。后来加了服务端幂等和前端轮询，这类问题再没出现过。

那些不起眼但很致命的细节

• 订阅消息：用户拒绝后不能再弹，要在合适时机引导去设置页开启。
• 分享路径：从分享卡片进入的页面，参数有没有带全，未登录状态下能不能正常展示。
• 返回栈：连续跳转多级页面后，返回按钮会不会跳回首页而不是上一页。
• 缓存：版本更新后旧缓存导致的样式错乱，建议在 onLaunch 里做一次版本比对清理。

上线前最后一遍：体验版走查

代码合并到体验版之后，我会拉上客户一起，用真实微信账号从头到尾走一遍核心流程。这一步不是找 bug，是确认“业务理解没跑偏”。唐山不少中小商家对线上流程不熟，让他们亲手点一遍，往往能发现我们以为理所当然、但他们完全看不懂的文案和按钮。

测试这件事，说到底是在替用户提前把不舒服的地方走一遍。唐山小程序开发的市场这两年越来越卷，功能大家都能做，能不能稳定跑起来、少出岔子，才是本地客户愿意长期合作的理由。我是知码客，专注小程序和 APP 开发，用代码改变生活——下次聊聊上线后的性能监控怎么做。