企业官网建设流程全解析

微信小程序已经成了绝大多数公司产品矩阵里绕不开的一环，但很多软件测试人员一拿到小程序需求，还是习惯性地按普通 App 的套路去测。其实小程序是个非常特殊的混合体：表面上是网页技术，实际又被微信这套宿主环境层层约束，切换后台、分享回流、分包加载、基础库兼容这些问题，普通 web 测试和原生 App 测试都不会遇到。这篇东西我就把日常在项目里反复验证过的小程序测试点整理成一份能直接照着用的清单，从功能到性能，从兼容性到自动化，尽量把容易踩坑的地方都说明白。

适用对象我直接说透：如果你刚转行做软件测试，这份清单可以帮你快速建立小程序测试的全局视野；如果你已经测过一阵子小程序，这里的排查技巧和自动化方案应该能帮你解决几个实际痛点；如果你是面试前临时抱佛脚，那第六章的面试应答思路也能直接拿去用。

1. 为什么小程序测试是一块独立的领域

1.1 双线程架构决定了测试关注点

微信小程序不是传统意义上跑在浏览器里的网页，也不是原生 App。它运行在一套双线程架构上：渲染线程负责界面绘制，逻辑线程负责业务逻辑和数据处理。渲染层用的是一套精简过的 WebView 环境，逻辑层则是 JavaScript 引擎，两者通过微信客户端内部的消息机制通信。

这个架构带来的直接影响，就是你测试时不能只看页面显示正常不正常，还得关注数据传递的时机、接口回调的时序、页面切换时的状态残留。举个例子，在页面 A 发一个请求，用户立刻切到页面 B，等请求返回后再回页面 A，页面 A 里的 setData 是否还能正常触发渲染？这种问题在普通网页里基本不用管，在小程序里却是真真实实会出现的历史遗留 bug。

我在实际项目中踩过一次很典型的坑：一个列表页面在 onLoad 阶段请求数据，用户快速下拉刷新，两个请求并发返回后，列表数据被旧数据覆盖，页面出现闪烁。后来排查发现是逻辑层在渲染层尚未完成初始化时就发出了第二次 setData，底层通信被丢弃。这种问题就要求测试人员在设计用例时必须考虑用户高频操作下的异步时序陷阱。

另外，小程序有明确的上传包体积限制，主包加分包的总大小不能超过一定阈值，这个我在后面性能章节细讲。总之，理解了双线程机制，你就知道为什么有些 bug 只在真机上出现，为什么有些问题必须靠微信开发者工具的调试器才能定位。

1.2 小程序测试的六大维度

常规的 App 测试维度，到了小程序这里基本都要重新拆解一遍。我长期实践下来，把小程序测试归纳成六个方向：

• 功能测试：登录授权、页面路由、缓存存储、转发分享、支付流程、各类业务组件（表单、购物车、地图、扫码等）。
• 兼容测试：微信版本、基础库版本、iOS/Android/鸿蒙系统、不同屏幕尺寸、不同手机厂商定制系统。
• 性能测试：冷启动/热启动耗时、首屏渲染速度、包体积、内存占用、请求耗时和并发。
• 网络接口测试：接口功能、异常返回、弱网环境、超时重试、请求拦截和报文分析。
• 安全测试：登录态校验、敏感信息存储、越权访问、非法参数注入、内容安全检测（小程序对 UGC 有强制内容安全要求）。
• 自动化测试：核心链路回归、UI 自动化脚本、接口自动化 pipeline。

这六个维度不是每条都需要做到一百分，测试人员在排优先级时要结合业务形态和项目阶段。比如刚上线的 MVP 版本，功能链路和支付流程是命门，兼容性可以只覆盖主流机型；到了稳定期，兼容维度就要扩大覆盖面，自动化也得跟上。

2. 功能测试点：先搞定用户必走的几条链路

2.1 登录授权链路

小程序最常用的登录方式是微信授权，但这里的坑比想象中多。微信的授权体系这几年经历了多次调整，早期版本可以直接弹窗获取用户头像昵称，后来改成了必须引导用户手动点击按钮才能触发授权弹窗，再往后又有了头像昵称填写能力。测试时必须确认当前项目依赖的具体 API 版本。

登录链路的核心测试点如下：

1. 首次进入：未登录状态下，页面是否允许游客浏览，还是强制跳转到登录页。
2. 点击授权按钮：用户点击授权后，是否能正确获取到微信登录凭证（code），并将 code 传给后端换 token。
3. 拒绝授权：用户点“拒绝”之后，页面提示是否友好，有没有死循环，有没有卡在登录页无法退出。
4. 授权成功后的页面回跳：从登录页返回首页，用户数据是否已经完整，个人中心的头像昵称是否展示正确。
5. token 过期：后端 token 过期后，小程序再次发起业务请求时，前端是否自动拦截并重新静默登录。
6. 手机号授权：很多电商类小程序需要获取手机号，测试要关注用户拒绝手机号授权后能否继续用其他方式登录，手机号解密失败时的异常处理。
7. 多端互踢/多设备登录：同一个微信账号在另一台手机登录后，原设备的小程序是什么表现，是需要重新授权还是直接报错。

这里我特别想提醒一件事：code 换 token 的接口是有时效性的，微信返回的登录凭证有效期很短，如果测试时发现偶尔登录失败，先看看是不是测试环境网络慢导致 code 过期，而不是一上来就报 bug。我在项目里遇到过好几次“怪 bug”，最后都是因为测试环境接口响应超过 5 秒。

2.2 页面生命周期和路由栈

小程序页面生命周期和 Web 页面完全不同。它包含 onLoad、onShow、onReady、onHide、onUnload 五个核心阶段，再加上 onPullDownRefresh、onReachBottom 这两个和交互相关的回调。测试用例设计时至少要考虑以下场景：

• 冷启动：完全杀掉微信进程后重新进入小程序，页面是否回到首页，还是自动恢复上次浏览的页面。
• 切后台：按 Home 键把微信切到后台，过 5 分钟再回来，页面数据是否刷新，登录态是否还在。
• 页面栈深度：小程序页面栈最多支持 10 层，测试时连续跳转超过 10 个页面，第 11 次跳转会失败，有些项目没有做路由拦截就会直接白屏。
• Tab 切换：有 tabBar 的小程序，在 tab 间频繁切换，各页面的输入框内容和滚动位置是否保留。
• 返回行为：从二级页面返回到列表页，列表页的数据是否需要重新加载，位置是否重置，如果处理不当用户会发现“刚翻到第 3 屏，返回后回到第 1 屏”。
• 分享进入：用户通过好友分享的卡片进入小程序，走的不是正常首页路径，而是直达某个业务页，此时该页面的参数是否齐全，登录态是否有，返回按钮应该回到首页还是没反应。

我在实际测试中见过一个非常隐蔽的 bug：从分享卡片进入活动页，登录后直接跳转到首页，用户按返回键却退出了小程序而不是回到首页。原因是开发者把 redirectTo 和 navigateTo 用混了，导致页面栈里根本没有上一层页面。这类问题靠看代码不好发现，必须靠测试用例覆盖到分享入口。

2.3 本地缓存与数据一致性

小程序的本地缓存通过 Storage API 实现，分为同步（setStorageSync）和异步（setStorageSync）两种。缓存容量单个 key 上限有 1MB，整体上限 10MB，超出后会写入失败。测试点包括：

• 写入与读取一致性：写入对象后立即读取、退出页面再进入读取、杀掉小程序进程后再读取，三种情况下数据是否一致。
• 缓存类型：String、Object、Array 等不同数据格式是否都能正常存取。
• 空间上限：构造一个超限场景（比如循环写大字符串），观察是否会抛异常、是否提示用户清理缓存。
• 清理机制：小程序是否有“清除缓存”按钮，清除后页面数据是否完全重置，未持久化的数据是否会残留。
• 版本升级：小程序发版后，老版本缓存的字段结构和新的数据结构不兼容，是否做了兼容处理。
• 过期时间：小程序 Storage 本身没有过期机制，但很多业务状态（如用户签到信息、活动弹窗）需要控制有效期。这个有效期是开发自己在代码里实现的，测试时要验证跨天、跨周这类时间边界。

举个例子，商品详情页把用户上次浏览的尺码选择存在了本地缓存，用户在另一个设备上下单，结果选中的却是上次设备上的尺码。这类问题在原生 App 里一样会有，但小程序因为入口太轻、使用频率太高，出现的概率更大，必须专门设计跨设备场景的缓存用例。

2.4 购物车场景的详细测试点

购物车是电商类小程序最常见的核心模块，面试也爱问，我直接给一份能落地的购物车测试点清单。这套打法不止适用于购物车，任何带列表选中和金额计算的模块（比如预约结算、多选操作）都能复用：

1. 商品列表展示：不同状态商品（有货、缺货、失效商品）的展示规格、置灰效果、是否还能修改数量。
2. 单选/全选逻辑：全选后个别商品缺货是否自动取消选中；取消全选后再次全选，选中状态是否正确；单选和全选的互斥联动。
3. 数量加减：在库存上限和下限边界操作，数量为 1 时减号是否置灰；数量达到库存上限时是否给出提示且不允许继续加。
4. 删除商品：删除单个商品、批量删除、删除最后一件商品后是否有空态提示。
5. 金额计算：单个商品小计（单价 x 数量）、全选总金额、优惠券抵扣、满减活动、运费叠加，每一种组合都要算一遍。特别注意浮点数计算误差，电商客户端通常会用分单位整数计算，测试时用 0.1、0.3 这类小数商品单价验证是否有 0.30000000000000004 这种问题。
6. 价格变化：商品价格在服务端被修改后，用户本地购物车里的金额是实时刷新还是保留下单前的价格，下单时的金额校验是否生效。
7. 库存校验：用户加购后库存被其他用户买完，提交订单时系统是否拦截并给出“库存不足，请修改商品数量”的提示。
8. 结算跳转：从购物车进入确认订单页，购物车列表、金额汇总、商品选中状态是否无缝传递。

购物车模块最容易出现的问题其实是数量并发：用户在两个页面同时进入购物车修改数量，提交订单后服务端校验失败，前端有没有把失败原因明确展示出来。这个测试点如果你能在面试时讲出来，会比单纯背用例值钱得多。

2.5 分享、支付和位置这类“微信绑定”功能

小程序和微信生态深度绑定，有几个功能是普通 App 不需要测的：

分享到聊天/朋友圈

小程序分享分为主动分享（右上角菜单）和被动分享（页面内按钮）。测试点包括：分享卡片标题和缩略图是否正确、分享出去的页面参数是否完整、好友点击后能否打开正确页面、未登录用户通过分享进入的权限控制、分享卡片图片大小超限是否报错。

微信支付

小程序的支付流程是前端调起 wx.requestPayment，后端拉起预支付单。测试点核心是：点击支付后参数正确性、支付成功后的页面跳转和订单状态更新、支付取消/中途退出、支付超时、余额不足时错误提示、重复回调（同一笔订单支付成功的回调被多次触发，会不会重复加积分/加库存）。

重复回调这个问题我强烈建议你们重点测。微信支付回调失败后会重试，如果后端没有做幂等处理，就会出现用户只付了一笔钱但账户充值记录多了一条。这个 bug 在测试环境里因为模拟回调太多，曾经直接导致所有测试账号的余额全乱掉。

位置服务

涉及地图、附近门店、配送地址的功能，需要测试：用户拒绝授权位置后的页面表现、定位不精确时的地图展示、切换城市后的重新定位、位置信息是否能被正确回传到后端。

3. 兼容性测试：小程序最让人头疼的坑

3.1 iOS、Android 与鸿蒙的差异化表现

小程序跑在不同的系统上，表现差异比原生 App 还大，因为同一套代码被不同的 WebView 环境解释。我从实际测试中总结出的高频差异点如下：

• iOS 键盘与输入框：iOS 原生键盘弹出时会顶起页面，如果页面没有做适配，输入框会被挡住或者页面变形。还有 iOS 输入框首字母自动大写的问题，需求方如果要求小写输入，测试得验证关闭 autoCapitalize 是否生效。
• Android 返回键：Android 手机有实体/手势返回键，从某个页面按返回键，是小程序内部返回上一页，还是直接退出小程序，各厂商定制 ROM 还会不一样。
• iOS 和 Android 的缓存策略：同一份数据请求，iPhone 上更容易出现本地缓存过期不刷新，Android 上更容易出现请求重复发送。遇到页面数据更新不及时，大概率就是系统缓存差异。
• 鸿蒙系统：随着鸿蒙设备增多，小程序在鸿蒙上的兼容测试已成为必做项。常见问题包括：顶部导航栏高度异常、地图组件渲染闪黑、某些 canvas 接口不可用、摄像头扫码调起失败。我在 2024 年的某电商项目里就遇到过鸿蒙设备上小程序内嵌 h5 页面白屏的情况，原因是该 h5 页面依赖的一个 Web API 在鸿蒙内置浏览器里不支持，最终只能更换方案。
• 刘海屏和灵动岛：小程序自定义导航栏时，状态栏高度获取不准确会导致页面内容被遮挡。测试手机里必须包含至少一部刘海屏和一部挖孔屏机型。
• 视频播放：小程序里用 video 组件播放视频，iOS 上默认全屏播放，Android 上默认内联播放，这个体验差异需要产品决策。
• 网络请求失败率：有段时间 iOS 机型网络请求失败率很高，排查后是 App Transport Security 策略和微信基础库版本共同作用的结果。测试时如果 iOS 请求失败率异常，先用同一个 WiFi 在 Android 上对比验证，再判断是代码问题还是微信环境问题。

3.2 微信基础库版本冲突

微信小程序的 API 能力依赖基础库版本。同一个小程序在最新版微信和旧版微信里的表现可能完全不同。兼容测试的重点是：

• 项目在微信开发者工具里明确设置了最低基础库版本（比如 3.0.0），测试需要覆盖最低版本、主流版本、最新版本三档。
• 旧基础库不支持的新 API，使用前是否有版本判断逻辑（wx.canIUse 的判断）。
• 上线新功能后，老版本微信用户进入小程序，是否出现白屏或接口报错，有没有降级处理。
• 微信基础库版本可以在微信任意聊天框里输入#加特定指令查看，测试时我通常会准备一台不升级微信的老手机专门做低版本兼容验证，效果非常好。

3.3 机型覆盖策略和外部真机

做兼容测试不可能覆盖所有机型，要按优先级分层：

1. 核心层：iOS 最新两款机型 + Android 主流旗舰机（覆盖最新系统版本），这部分通常由公司内部测试设备完成。
2. 重要层：至少一台低端 Android 机（比如 4G 内存、老旧骁龙芯片）、一台鸿蒙设备、一台有大屏/折叠屏特性的设备。
3. 外围层：用线上用户机型分布数据，挑选 Top 10 机型做额外验证。也可以通过第三方云测试平台批量跑兼容脚本，成本低很多。

我在项目里验证过的具体建议是：兼容性测试最好放在功能稳定之后再做全量，不然功能还在频繁变动，兼容报告出来全是无效数据还浪费设备资源。

4. 性能测试：小程序卡顿是测试问题还是优化问题

4.1 启动与首屏渲染耗时

小程序性能问题最直观的就是打开时白屏时间过长。测试手段如下：

1. 用微信开发者工具的Audits 面板跑一次自动化体检，里面会给出首屏加载时间、资源加载耗时、渲染性能得分等指标，还会直接指出哪些 JS 文件体积过大、哪些接口响应过慢。这是性能测试的第一道闸，基本每次发版前都要跑一遍。
2. 用真机工具手动录屏，从点击图标到页面首帧渲染完成计算冷启动耗时。冷启动和热启动的差异测试要分开记录：冷启动指微信进程被杀后重新进入小程序，热启动指小程序还在后台直接切回。
3. 检查懒加载是否生效。长列表页面是全部渲染还是只渲染可视区域，图片是原图加载还是压缩图，这些都能通过开发者工具的 Network 面板直观看到。

这里有个容易被忽略的点：首屏性能不止看数据花多久，还要看数据回来之后页面要处理多久。有些页面接口 200ms 就返回了，但数据量太大，setData 同步给渲染层就要卡 1 秒。测试时千万不要只盯着接口耗时，要拿秒表卡整个流程。

4.2 包体积与分包加载

微信对小程序包体积有硬性限制：主包不能超过 2MB，整个小程序（主包+分包）不能超过 20MB（具体数值微信官方会调整，测试前确认最新限制）。这个限制的核心原因不是存储，而是首次加载时需要下载整个主包，包越大启动越慢。

测试人员在包体积这块的职责是：

• 发版前检查开发者工具里的代码包体积报告，有没有出现“主包体积接近上限”的告警。
• 验证分包加载逻辑是否生效：进入主包内的首页，不会额外加载分包资源；进入某个分包页面时，是否能正常拉取分包并展示页面。
• 验证分包预下载是否按需触发。微信支持在特定时机预下载分包，测试时要模拟用户从首页进入活动页的全流程，观察分包是否提前加载完成，从而减少页面等待时间。
• 验证图片是否大量使用了本地打包资源，而不是 CDN 链接。本地图片体积过大是包体积超标的头号元凶。

分包的问题我提醒一句：如果开发把公共组件放到了分包里，而主包页面也引用了这个组件，就会出现运行时找不到模块的报错。这种报错在工具里可能正常，但在真机上才会崩。测试必须包含分包专项用例。

4.3 内存与滚动流畅度

性能测试不能只盯加载速度，还要观察长时间使用后的表现：

• 打开一个图片密集型列表页，反复上下滑动 20 分钟，观察页面是否越来越卡，微信内存占用是否持续增长。
• 在同一会话里不断执行“进入列表页 - 查看详情 - 返回”操作，检查是否有页面没有销毁，导致内存泄漏。
• 视频类小程序播放视频时，退出页面后视频是否还在播放声音，后台是否还在持续消耗资源。
• 在低端 Android 设备上反复切换 tab，观察是否出现白屏或者黑屏闪动。
• 页面卡顿和渲染帧率可以用开发者工具的Trace 面板记录，测试时直接导出一段滑动操作的 trace 文件，让开发一眼看到掉帧时间点。

这里我给一个非常实用的测试技巧：性能测试用录屏 + 软件看帧率。启动耗时、滚动卡顿这些问题，录屏文件导入工具里逐帧分析，比嘴硬说“我觉得卡”要专业得多，开发也更愿意认账。

5. 网络接口与安全测试：数据链路是根本

5.1 接口功能与异常返回

小程序后端接口测试的核心思路和普通接口测试一致，但要额外注意微信环境带来的特殊性：

• 所有业务请求是否都携带了正确的登录凭证。
• 接口返回的状态码是否区分了业务失败（如 code 非 0 表示业务失败）和系统异常（如 HTTP 500）。
• 接口超时和网络断开时，前端是否有 Toast 或 error 提示，还是长时间转圈。
• 弱网环境下（3G 网模拟），请求是否正常超时并触发重试，重试后会不会产生重复数据。
• 下拉刷新和上拉加载时，接口是否重复请求、数据是否叠加而非替换。
• 分页接口在最后一页没有数据时，前端是否停止发送请求（很多项目会在这里出现死循环请求）。
• 用户快速切换页面前发出的旧请求，返回后是否被丢弃，是否还会错误地更新新页面的数据。

这些点测试起来最有效的方式是用抓包工具先看清请求链路，然后通过断点或 mock 修改接口返回值来模拟异常。微信开发者工具里的“本地调试”模式支持自定义返回结果，这个功能非常适合搞接口异常测试，比一遍遍改后端代码快得多。

5.2 小程序弱网与信号切换测试

移动端小程序使用场景里，用户经常在地铁、电梯、地下车库这些信号不稳定的环境。测试方法：

• 把真机 wifi 关掉只用移动数据，在弱信号区域操作核心功能。
• 在飞行模式开关前后分别操作，观察断线重连和数据恢复逻辑是否正常。
• 模拟从 wifi 切换到 4G/5G 的过程，小程序正在上传图片或支付时，网络切换会触发请求失败，这时页面提示和重试机制很重要。
• 使用云真机平台的网络模拟功能，可以设定特定的丢包率和延迟，比线下找弱网场景更可控。

弱网测试最容易发现的问题是：请求发送时断网、应用没有任何超时机制，用户在恢复网络后再次点击按钮时，之前的请求又突然返回并触发页面异常。这种不确定 bug 很难复现，但它的根因基本就是前端缺少对请求去重和过期丢弃的处理。

5.3 抓包定位小程序问题

小程序抓包和普通网页抓包不太一样，因为小程序的请求不走系统 WebView 的常规代理配置，要额外设置。常用的方案是：在电脑上启动一个 HTTP 代理监听端口（比如 8888），手机 wifi 手动设置代理指向该端口，同时安装信任证书，这样电脑端抓包工具就能看到小程序发出的 HTTPS 请求。

我平时用的抓包工具主要是 Fiddler 和 Charles。Fiddler 免费且脚本能力强，Charles 在移动端请求树上更好看，看哪个顺手就用哪个。需要特别说清楚的是：小程序基于微信环境，抓包前一定要在微信的“调试”配置里打开调试开关，并把代理设置正确，否则请求是不走代理的（在开发者工具和手机上的配置方式略有不同）。另外微信小程序的很多请求走了私有的通信协议，常规抓包工具可能看不到全部内容，那就需要在开发者工具里直接看 Network 面板，或者让后端同学把请求日志拉出来配合排查。

注意：修改代理和抓包必须在你自己有权测试的测试环境进行，不要拿这个能力去做任何未经授权的数据获取，合规底线不能碰。

5.4 安全测试要点

安全这块我挑几个小程序场景特有的点：

• 登录态校验：登录后的接口，后端是否正确校验了 token 的有效性，直接删掉 token 后发起请求是否被拒绝。
• 越权访问：普通用户通过修改参数去访问其他用户的数据（比如把订单号改成别人的单号），后端是否校验了数据归属。
• 参数篡改：请求里的金额、数量、优惠券 ID 等字段，前端改动后是否可以提交成功。
• 内容安全：小程序内用户发布的评论、昵称等 UGC 内容，是否接入了微信的内容安全检测接口，违规内容是否能及时拦截。
• 敏感信息存储：用户身份证、手机号、银行卡号有没有明文存储在本地缓存或者请求参数里，应该做脱敏展示。
• 代码包防篡改：小程序发布时是否启用了代码保护，反编译工具读出来的代码是否可读。

安全测试建议用“不信任前端”的思维来做：默认所有前端传参都不可信，所有关键数据都要在服务端二次校验。这一点并不需要很强的前端功底，测试人员只要多想想“如果我是攻击者，我会怎么改这个值”，就能设计出一批有效的安全用例。

6. 自动化测试与常见问题排查

6.1 小程序自动化方案对比

小程序自动化测试在行业里已经非常成熟，主流的方案有三类：

• 微信官方 miniprogram-automator：这是最接近底层的方案。通过它可以直接控制小程序模拟器或真机，执行点击、输入、获取页面数据等操作，还能拿到页面元素的完整结构。适合做 UI 自动化回归。
• miniprogram-simulate：官方出品的组件测试工具，可以在 Node 环境里隔离测试单个自定义组件，适合组件级单测。
• Puppeteer / Playwright 方案：这种做法是把小程序跑在 Chromium 内核里（通过小程序的 web 化构建），用浏览器自动化工具驱动。适合做纯页面级的回归，但不能覆盖微信原生能力。

我在实际项目里的推荐组合是：组件级单测用 miniprogram-simulate，核心业务链路回归用 miniprogram-automator 配合 Node 脚本，再把这些脚本串进 CI 流水线。没条件上整套 CI 的团队，至少可以用 miniprogram-automator 把登录、购物车结算、支付回调这几条核心链路做成每日冒烟测试，能在很大程度上兜住低级回归 bug。

6.2 自动化脚本的实操要点

写小程序自动化脚本有几个要避开的坑：

1. 定位元素优先用 id 或自定义属性。小程序的 view 组件经过编译后，class 名称可能被混淆，用 class 定位非常脆弱。
2. 异步等待必须到位。小程序渲染是异步的，点击按钮后页面不会立刻变化，脚本里要封装 waitFor 方法循环检查元素出现，而不是硬写 sleep。
3. 真机调试和模拟器行为不完全一致。模拟器里能过的脚本，换真机跑可能因为网络慢、弹窗提示、键盘弹出等问题挂掉，所以自动化脚本至少要有一次在真机上的执行记录。
4. 微信授权弹窗是脚本杀手。脚本跑在真机上时，微信授权弹窗无法通过 automator 直接点击，通常的做法是准备一个已经授权过的测试微信号，或者用开发者工具关闭授权弹窗。

6.3 常见问题排查表

我把过去几年微信小程序测试里遇到频率最高的 10 个问题整理成一张速查表，排查顺序和应急处理一并放在里面：

这张表不是让你背答案，关键是掌握排查思路：先判断问题是前端还是后端、是系统还是微信环境，再逐层缩小范围。遇到“偶发”问题，先想是不是时序问题；遇到“只有部分机型出现”的问题，先想是不是兼容问题；遇到“线上复现不了”的问题，先看有没有录屏、抓包、日志三件套。

7. 小程序测试资源的编排建议

7.1 新人如何快速上手小程序测试项目

如果你是刚接手一个小程序项目，我的建议是不要一开始就埋头点页面，先用一个下午做这三件事：

• 第一，把微信开发者工具装好，导入手