小程序上线前，我踩过的测试坑

上周帮朋友收尾一个小程序，功能都写完了，提审前我让他先跑一遍测试。他回了一句：本地都点过了，没问题。结果上线第二天，客服群里炸了——iOS 上支付回调没反应，安卓低端机进详情页白屏。这两个问题，本地开发者工具里一个都复现不出来。

这篇就聊聊小程序开发测试这件事。不是教科书式的清单，是我自己反复踩坑之后，觉得真正值得花时间的地方。

开发者工具只是起点，不是终点

很多人把微信开发者工具的模拟器当成测试环境，这是最大的误区。模拟器跑的是 Chrome 内核，真机是各家的 WebView，差异比想象中大。

• iOS 的日期解析：new Date('2024-01-01 10:00') 在 iOS 上直接 Invalid Date，安卓正常。这种坑模拟器永远发现不了。
• 键盘弹起后的布局：真机上输入框被顶起、页面滚动位置错乱，模拟器里风平浪静。
• 字体和行高：不同机型渲染差异会导致文案截断，尤其是按钮里的文字。

我的习惯是，功能写完先在开发者工具里过一遍逻辑，然后立刻上真机。手边至少准备三台：一台 iPhone、一台中端安卓、一台两年前的低端安卓。低端机是照妖镜，卡顿、内存溢出、图片加载失败，全在它身上现形。

性能测试别只看启动时间

小程序性能有个容易被忽略的点：页面栈。用户点得越深，页面栈越厚，内存占用越高。我见过一个电商小程序，商品列表→详情→店铺→再进详情，来回跳几次之后，低端机直接卡死。

测试的时候我会刻意做几件事：

• 连续跳转十个页面再返回，看会不会出现白屏或卡顿。
• 在列表页快速上下滑动，观察 setData 的频率。数据量大时一定要分页，别一次塞几百条。
• 用真机调试面板看内存曲线，如果每次返回列表内存都不降，说明有监听没解绑。

// 页面卸载时记得清理，这是最常见的泄漏源
onUnload() {
  clearInterval(this.timer)
  this.eventChannel && this.eventChannel.off('update')
  wx.offNetworkStatusChange(this.netHandler)
}

还有图片。测试时把手机切成弱网（开发者工具里能模拟，但真机更真实），看首屏图片是不是一张张往外蹦。该用 CDN 压缩的压缩，该加 lazy-load 的加上，别等用户投诉加载慢才回头改。

支付和登录，必须走真金白银

支付这块，我吃过一次大亏。测试环境用沙箱跑通了，正式环境一上，用户付完钱订单状态不更新。原因是回调地址配的是测试域名，正式环境压根没收到通知。

所以支付测试我的原则是：用真实金额跑通完整链路，哪怕只付一分钱。要验证的点包括：

• 支付成功后，前端轮询或回调能不能正确更新订单状态。
• 用户中途取消支付，页面状态是否回滚，会不会卡在“支付中”。
• 弱网下重复点击支付按钮，会不会生成两笔订单——这个一定要做防抖和幂等。

登录也是重灾区。微信授权、手机号快速验证、静默登录，三条路径都要单独测。特别是用户拒绝授权之后的降级逻辑，很多人只测了同意的那条路。

兼容性和审核，提前一周准备

兼容性测试不用铺得太开，但有几个点必须覆盖：

1. 深色模式。现在系统默认可能开着深色，你的白色卡片如果写死颜色，直接看不见字。
2. 大字体模式。老年用户会把系统字体调大，固定高度的容器会溢出。
3. 刘海屏和安全区。底部按钮被 Home 条挡住，是提审被拒的常见原因。

说到提审，测试阶段就要对照审核规范自查一遍。类目对不对、有没有诱导分享、用户隐私协议有没有弹窗确认，这些在测试期改成本最低，等被拒了再改，一来一回就是三五天。

我的经验是：功能开发占七成时间，测试和修 bug 占三成。如果谁告诉你小程序“写完就能上”，那他大概率没真正上线过几个项目。

最后说个心态问题。测试不是走流程，是站在用户角度找茬。自己测自己的代码容易手软，条件允许的话，找个没用过这产品的人，给他一台手机让他自己点，你在旁边看。他卡住的地方，就是你要修的地方。