北京小程序开发：测试这关别糊弄

上周去中关村见一个客户，做企业服务的，小程序已经上线两周了。我随手点开他们的表单页，输入一个手机号，提交——白屏。再试一次，转圈转了十秒，最后弹了句“网络异常”。客户在旁边挺尴尬，说这个页面平时没人用。可问题是，这个页面是给销售填线索用的，一天几十条。上线两周，丢了多少条，没人算得清。

这事在北京不算少见。做小程序的门槛低，很多团队把精力全压在功能实现上，测试环节能省就省。但小程序跑在微信里，网络环境、机型、基础库版本、授权状态，变量比传统 Web 多得多。今天聊聊北京小程序开发里，测试这件事该怎么认真对待。

小程序测试，和你想的不太一样

不少从 Web 转过来的开发者，习惯性觉得测试就是点一遍流程。但小程序的运行环境有它的特殊性：

• 基础库版本碎片化。微信基础库版本更新频繁，用户端版本参差不齐。你在开发者工具里调好的 API，在老版本上可能直接不存在。
• 授权与登录态。用户拒绝授权、授权过期、切换账号，这些状态组合起来能出不少幺蛾子。我们给北京一家连锁餐饮做小程序时，就遇到过用户换微信号登录后，购物车数据串到另一个人身上的问题——缓存 key 没和 openid 绑定。
• 网络环境复杂。地铁里、电梯里、商场地下车库，弱网和断网重连是常态。提交订单这种关键动作，没做幂等和重试，重复下单的投诉就来了。
• 真机与模拟器的差异。开发者工具里的表现，和真机经常对不上。尤其是 iOS 和 Android 的差异，字体渲染、滚动行为、键盘弹起后的页面位置，都得真机验证。

我们内部的一套测试清单

知码客做小程序定制开发这几年，慢慢攒了一份测试清单，每次交付前逐项过。挑几条关键的说说：

功能路径：主流程和“歪路”都要走

主流程谁都会测。真正容易漏的是异常分支：支付中途取消、支付成功但回调没到、表单提交时断网、页面返回后数据没刷新。我们给北京一家做教育培训的客户做报名小程序，测试时专门模拟了“支付成功但页面没收到通知”的场景，结果发现订单状态要等用户手动下拉刷新才更新。后来加了轮询和页面 onShow 时的状态同步，才踏实。

兼容性：机型清单要固定

不用测几百台，但要有代表性。我们的做法是固定一组机型：一台较老的 Android（比如几年前的千元机）、一台主流 Android、一台 iPhone 老机型、一台新 iPhone，再加一台 iPad。每次发版前在这几台上跑一遍核心路径。北京这边用户机型分布比较杂，商务人群 iPhone 比例高，但下沉场景的 Android 老机型也不能忽略。

性能：别只看首屏时间

小程序性能有几个容易忽视的点：

• setData 的数据量。一次传几 MB 的列表数据，页面直接卡死。要分页、要裁剪字段。
• 图片资源。没压缩的图、没走 CDN 的图，首屏加载能拖到十几秒。
• 页面层级。小程序页面栈最多十层，navigateTo 用多了会出问题，该用 redirectTo 的地方别手软。

// 反例：一次性 setData 整个大列表
this.setData({ list: hugeArray })

// 正例：分页加载 + 只传必要字段
const page = hugeArray.slice(offset, offset + 20).map(item => ({
  id: item.id,
  title: item.title,
  cover: item.cover
}))
this.setData({ [`list[${offset}]`]: page })

上线前的“最后一公里”

提审之前，有几件事必须确认：

1. 体验版在真机上完整走一遍，包括登录、支付、分享、订阅消息。
2. 检查所有 request 域名是否已配置到后台白名单，别等审核被拒才发现。
3. 隐私协议和用户信息收集说明是否齐全。这两年微信对隐私合规查得严，北京这边尤其明显，企业客户对合规要求高。
4. 埋点和错误监控是否生效。上线不是终点，线上出问题要能第一时间知道。

说点实在的

测试这件事，投入产出比其实很高。一个白屏 bug 丢掉的线索，可能比测试花的时间值钱得多。我们在北京做小程序开发，接触的客户里，有不少是之前找别家做完、上线后问题不断，再找过来重构或者补测试的。返工的成本，往往比一开始就认真测要高。

知码客的信念是“知码识途、匠心铸客”。代码是写给用户看的语言，测试就是确保这句话没说错。北京做小程序的公司不少，但愿意在上线前多花两天把边角场景跑一遍的，未必多。如果你正在推进一个小程序项目，不妨问问你的开发团队：测试清单在哪？真机测了几台？异常分支覆盖了吗？这几个问题，比看 demo 更能说明问题。