1. 从“手动点断手”到“脚本跑断腿”聊聊小程序UI自动化的真实起点做微信小程序测试的人应该都经历过那种“点来点去”的日子。小程序页面状态多、弹窗乱入、登录态一失效就要重新扫码测试回归一遍下来少说也得半小时。尤其是做电商、社区、工具类小程序改一个组件或者调一个接口可能就把之前的核心流程带崩了。我前前后后带过好几个小程序项目踩了无数坑之后终于把UI自动化这套东西跑通并沉淀了下来。这篇就是给那些正准备入坑小程序UI自动化的人看的也顺带聊聊我在实践中踩过的那些经典“坑”和最终稳定运行的方案。很多人以为小程序UI自动化很难搞其实现在的技术工具链已经相当成熟了。关键在于选对方案并且理解微信小程序自身的运行机制。小程序不像普通H5那样你在浏览器里拿到一个URL就能用Selenium开搞。它的页面结构是基于自研的渲染引擎有双线程模型跟常规的Web DOM并不完全一致。所以我们得先搞清楚小程序UI自动化的核心链路是什么再谈怎么写用例。我实测下来目前主流的做法可以分成三条路线一是微信官方提供的miniprogram-automator二是基于Appiumminicap等方式去做真机层面的驱动三是部分第三方云测平台自己封装的SDK。三条路线各有优劣需要按项目阶段去做取舍。这篇文章会重点讲透我常用的“官方SDK本地开发者工具”的落地方式这个方案对大多数中小团队来说是成本最低、见效最快、也最容易维护的。在动手之前我想先给你打个预防针UI自动化测的从来不是“业务逻辑”而是“页面表现流程”。如果你的项目页面结构不稳定、组件乱写、没有良好的语义化命名那不管用什么框架用例都会写得极其痛苦。所以做UI自动化本质上是反推研发团队去规范页面结构间接提升代码质量这个价值甚至比“发现BUG”本身更重要。2. 方案选型为什么我推荐miniprogram-automator而不是Appium2.1 迷你版官方驱动到底解决了什么问题miniprogram-automator是微信官方在开发者工具基础上做出来的一套Node.js SDK。它对外提供了一套类似于操作浏览器的API我们可以用它启动微信开发者工具、打开指定的小程序项目、控制页面跳转、获取页面数据、触发点击事件然后做断言。它的本质是“通过开发者工具的自动化接口去驱动小程序”。跟Appium这种通用移动端自动化框架比官方驱动有个先天优势它走的是微信开发者工具内置的调试通道不需要你处理各种设备连接问题也不需要你关心UIAutomator或者XCTest底层差异。而且它可以直接拿到小程序的Page实例、组件数据这对断言内部状态来说非常友好——直接比对data字段比在页面上扒文案方便多了。我最早其实是在Appium上折腾的那时候小程序还没有跨平台成熟方案得用webview切换的奇技淫巧稳定性一言难尽。后来微信官方出了miniprogram-automator果断迁过来了测试脚本量大概是原来的三分之二维护成本更是直线下降。2.2 三条技术路线的对比谁更适合你这里我直接放一张我整理的对比表方便你做初步决策方案运行环境稳定性上手成本适用场景miniprogram-automator微信开发者工具较高低开发自测、常规UI回归、CI环境Appium webview调试真机/模拟器一般高需要覆盖真机设备特性的场景云测平台SDK云真机取决于供应商中大规模兼容性回归、远程设备矩阵如果你只是想把现有小程序的“核心功能冒烟测试”和“常规回归测试”跑起来那最优先选官方驱动。而如果你要追的是“微信版本升级兼容性”“不同安卓机型上的页面渲染”那Appium体系还是有存在的必要只是成本也高得多。我自己团队的做法是本地、CI统一跑官方驱动定期再抽一批真机交给云测平台去做兼容性回归。2.3 为什么把开发者工具“装进流水线”是关键默认情况下微信开发者工具就是个IDE你需要手动打开、手动编译、手动操作。而UI自动化要跑起来第一步就是让工具能被“命令行控制”也就是把开发者工具当成一个可编程的运行时环境来使用。微信开发者工具本身提供了一个命令行工具cli可以通过类似cli auto --project 项目路径 --auto-port 9420的方式启动自动化端口。自动化测试脚本再通过这个端口连接进入项目环境。需要注意的是只有微信开发者工具登录了微信账号且打开了“服务端口”开关外部脚本才能连上。这一点是新手踩坑最多的地方。具体的选择逻辑其实很简单哪个工具能稳定地被脚本控制、能稳定的保活、能在无人值守环境下重启哪个就值得作为自动化的承载平台。桌面版微信开发者工具虽然需要一个GUI环境但在Linux CI机器上也可以通过一些显示虚拟化方案跑起来比如Xvfb这个后面我会展开讲。3. 环境搭建把工具、项目和SDK三者串起来3.1 从零初始化一份可以跑通的自动化工程我一般会用一个独立的Node项目来维护所有UI自动化用例然后通过npm script去控制执行。这个项目只做UI自动化相关的事情和被测小程序项目本身分开。第一步需要安装miniprogram-automator作为依赖用npm或者yarn都行。npm init -y npm install miniprogram-automator --save-dev第二步需要确认微信开发者工具的版本。用官方SDK时我强烈建议你用最新稳定版工具因为有些自动化接口和编译能力会随开发者工具更新而变化。项目里有个project.config.json要确保其中的appid是你自己在公众平台申请的真实AppID或者测试号。第三步手动打开一次微信开发者工具并导入小程序项目。这一步是为了让工具记住项目并且允许后续命令行自动打开。同时确保在“设置 - 安全设置”里开启了“服务端口”。如果没开启后面连接时会直接报错提示你无法连接自动化端口。3.2 启动/连接开发者工具的自动化通道现在要跑一个最小化冒烟脚本。先确认路径开发者工具CLI在macOS上通常位于/Applications/wechatwebdevtools.app/Contents/MacOS/cli在Windows上则类似C:\Program Files (x86)\Tencent\微信web开发者工具\cli.bat。可以先手动执行一下自动化启动命令cli auto --project /path/to/your/miniprogram --auto-port 9420这个命令会打开项目并监听9420端口。接着在Node脚本里通过miniprogram-automator连接const automator require(miniprogram-automator); async function run() { const miniProgram await automator.connect({ wsEndpoint: ws://localhost:9420, }); // 拉取当前页面栈 const page await miniProgram.reLaunch(/pages/index/index); await page.waitFor(500); // 做点什么 const title await page.$(.page-title); console.log(await title.text()); await miniProgram.close(); } run();跑起来后如果能在控制台看到页面里某个元素的文本内容说明环境串起来了。这一步能通后续就等于打通了任督二脉下面的用例编写、数据层断言、组件交互全都可以在这个通道上做。提示connect时如果提示连接失败优先检查1. 开发者工具是否打开了自动化端口2. 项目是否已经导入3. 端口号是否一致。这几步占了环境问题中的八成。3.3 把自动化工具跑在Linux CI服务器上如果你们团队已经把自动化用例放到CI里跑那大概率会遇到一个问题Linux服务器上没有桌面环境微信开发者工具是GUI程序怎么让它跑起来我实验出来的稳定方案是安装Xvfb用虚拟显示去承载开发者工具。在Ubuntu上可以执行sudo apt-get install -y xvfb Xvfb :99 -screen 0 1280x800x24 export DISPLAY:99然后再执行开发者工具的启动命令。实测下来稳定性还不错。只是一定要在CI配置里预留足够的启动时间别一启动就立刻执行connect最好增加重试机制因为开发者工具冷启动有时会需要好几秒。另外建议在CI里把开发者工具安装为独立版本和本地日常开发使用的版本隔离。否则每次CI强制更新或者日常手动升级工具都可能导致自动化运行环境被意外改变非常难受。4. 核心实操页面跳转、元素定位和断言到底怎么写4.1 页面对象Page和数据生命周期的理解小程序页面和传统Web页面有个本质区别小程序的逻辑层和渲染层是分开的。UI自动化在驱动页面的时候能看到的数据其实是从逻辑层同步过去的因此拿到element之后执行点击、输入等操作最终触发的是框架里的setData等动作。用官方SDK操作页面时通常先拿Page对象再拿元素// 直接通过 reLaunch 打开页面 await miniProgram.reLaunch(/pages/goods/list); const page await miniProgram.currentPage(); // 通过 .$ 找到元素 const goodsItem await page.$(.goods-item); await goodsItem.tap();这里有个细节currentPage()拿到的是当前显示的页面对象如果你调用reLaunch之后立刻调用currentPage()有可能因为页面切换动画还没结束导致拿不到正确的页面。可以考虑加一个等待或者使用waitFor的方式等待页面关键元素出现。另外小程序的页面也是一层一层挂载的navigateTo可以叠加栈reLaunch会清空栈。编写用例时如果你只是想在当前栈基础上跳到一个新页面做测试可以使用navigateTo但要注意用例跑完后要把页面栈跳回来或者重新启动避免对后续用例造成干扰。4.2 定位元素的方式选择器、文本、自定义属性小程序官方驱动支持通过CSS选择器来定位元素这个能力是真的香。我们可以用.class、#id、[data-testidxxx]、甚至::text(文案)这类伪选择器。看官方文档时你可能见过一些$方法但我强烈建议在团队里统一约定“自动化测试专用定位属性”比如>const page await miniProgram.currentPage(); const loginBtn await page.$([data-testidlogin-btn]); await loginBtn.tap(); // 也可以在元素上做文本判断 const userName await page.$(.user-name); console.log(await userName.text());如果实在没有合适属性也可以使用文本选择器。文本选择器的写法比较特殊比如page.$(view[data-testidxxx])会用CSS路径而page.$$(text首页)这种写法也能在某些版本中生效但稳定性一般所以只建议用作文本断言的辅助方式。4.3 弹窗、组件、原生控件的“不可控”问题小程序里一旦涉及到原生组件像某些输入框、地图、视频、canvas、textareaUI自动化的可操作性会肉眼可见地下降。这个问题不仅存在于官方SDK也存在于其他方案中。原生组件在很多版本里是显示在webview之上的普通元素选择器根本捕捉不到。我的经验是优先在业务侧把这类控件替换成可测试的封装组件或者给原生组件包一层容器暴露操作按钮等替代交互。比如地图选点、日期时间选择等都可以通过数据注入或者隐藏按钮的方式去绕过原生控件。另外很多小程序项目用了第三方组件库比如Vant Weapp、TDesign等。这些组件内部往往渲染多层结构不能直接用文字断言。不过组件是自带行为事件的可以配合“页面数据”的变化来验证组件交互是否生效。这也回应了前面那个观点小程序UI自动化的核心不一定全在UI上很多数据响应逻辑通过page.data()去断言更靠谱。const page await miniProgram.currentPage(); const initialData await page.data(count); // 点击加号按钮 await (await page.$([data-testidincrease-btn])).tap(); await page.waitFor(200); const newData await page.data(count); // 断言 if (newData ! initialData 1) { throw new Error(点击加号后count未变化); }这里验证的是数据层状态比单纯看页面文案稳定得多尤其适合表单、列表筛选、计数类交互。5. 进阶实战把UI自动化跑进日常CI流程5.1 在Jenkins/GitLab CI中接入完整回归脚本很多团队一开始只在本地手动跑一下UI自动化脚本但真正的价值点在于接入CI让每次提测、每次发布前都自动跑一遍核心回归。我在Jenkins上做过一个流水线大概的步骤是从Git拉取被测小程序代码。使用Node脚本执行依赖安装。初始化XvfbLinux环境。启动微信开发者工具的自动化模式。运行测试用例用的Jest runner。生成测试报告并归档。关闭开发者工具清理进程。下面这段是Jest runner里测试文件的简单例子const automator require(miniprogram-automator); describe(小程序购物车流程, () { let miniProgram; beforeAll(async () { miniProgram await automator.launch({ projectPath: process.env.MP_PROJECT_PATH, port: 9420, }); await miniProgram.reLaunch(/pages/home/home); }); afterAll(async () { await miniProgram.close(); }); it(添加购物车后角标数量变化, async () { const page await miniProgram.currentPage(); await (await page.$([data-testidadd-cart-btn])).tap(); await page.waitFor(500); const badgeText await (await page.$(.cart-badge)).text(); expect(badgeText).toContain(1); }); });这里有个经验如果启动开发者工具的过程比较慢导致Jest在beforeAll里连接失败可以在外面封装一个启动等待函数循环等待端口可用。5.2 用例分组与冒烟/全量回归策略UI自动化最忌讳的就是“一个失败全盘崩”所以要建立用例分组的习惯。我从实践中总结的分组策略是分组范围执行时机smoke登录态、首页加载、核心路径跳转每次代码提交后的快速检查regression所有核心业务用例每日夜间定时跑page-detail针对某个页面的专项测试页面改动频繁或上线前特批时执行在Jest里可以用testPathPatterns来匹配分组的文件比如npx jest --testPathPatternstests/smoke这样日常提交只跑冒烟夜间才跑全回归兼顾效率和稳定性。5.3 与小程序“体验版”和“开发版”发布流程的配合这里多说一句热词里很多人会问“体验版二维码在哪”“线上小程序怎么拿源码”。从测试的角度讲UI自动化建议统一跑“开发版”或当前本地构建出来的代码包不要去跑线上“正式版”。原因是线上环境和本地代码包不一定同步也无法随意注入环境变量或者开启调试模式。我们团队的做法是在CI构建出小程序包后先把构建产物自动导入开发者工具跑完自动化用例再走提审或上传体验版流程。这样能保证测试的就是即将发布的那个包把“测试包和发布包不一致”的坑提前避掉。6. 常见问题与排查技巧实录6.1 开发者工具连不上端口不通这基本是新手第一个遇到的墙。现象是connect调用后长时间未连接或直接报Error: connect ECONNREFUSED。排查思路检查开发者工具的“设置 - 安全设置 - 服务端口”是否开启。检查命令行启动参数里的端口是否和connect里的端口一致。检查是否有多个开发者工具实例占用同一端口建议把其他实例先关掉。在CI环境注意跨容器访问时IP不能写成localhost要按实际网络配置来写。多数情况下以上四步就能解决八成连不上问题。6.2 运行一段时间后页面元素定位失败这种情况比较诡异用例前面执行正常跑到十几分钟后开始大面积失败。经验是开发者工具长时间运行会占用大量内存或者页面栈/缓存越来越多导致样式错乱。我的办法是跑完每组用例后主动重启开发者工具或者给整个自动化任务设置定时重启。在CI上我直接封装了“执行前自动kill已存在的开发者工具进程再重新拉起来”的逻辑。最终效果很稳。6.3 点击元素偶发失效tap没有反应这通常不是代码问题而是操作太快了。小程序的渲染和逻辑之间有个异步链路数据更新后组件不一定马上可点击。我总结的稳定写法是“三步走”async function stableTap(page, selector) { const element await page.$(selector); await element.waitFor(); await page.waitFor(300); await element.tap(); await page.waitFor(300); }虽然看起来有点傻但这类固定小延时能很大程度提升点击成功率。如果你不想写死延时也可以改成循环尝试如果点击之后页面没有预期变化就再点一次直到超过重试次数。6.4 页面里存在多个相同>const cards await page.$$([data-testidgoods-card]); if (cards.length 2) { throw new Error(商品列表数量不足); } const secondCard cards[1]; await secondCard.tap();需要注意$$返回的元素是数组你在运行时把它当成普通元素用会报错建议多打印一下数组长度避免选择器没匹配到任何节点。6.5 自动化脚本不稳定偶发失败因素汇总这里是我实际跑自动化过程中总结的“不稳定来源”清单不稳定因素影响程度应对方式开发者工具版本升级高锁定自动化专用工具版本网络请求耗时波动中对接口进行mock或增加等待策略页面渲染动画时长中统一等待关键元素出现测试数据残留高执行前重置用户数据和后端状态组件库内部行为差异中尽量用数据断言替代纯UI断言用例执行顺序影响高每个用例独立启动或清理登录态这份清单基本是每个做小程序UI自动化的人都绕不开的坑。提前知道能帮你避免很多“玄学问题”。7. 关于“小程序签名/抓包/多端适配”等延伸问题的思考在热词里总能看到“微信小程序签名”“微信小程序抓包”这类疑问。签名和抓包虽然不直接属于UI自动化范畴但它们往往会在实践中冒出来。比如你要调试自动化脚本里某个请求的返回可能需要临时抓包你要校验某些登录态的签名逻辑也会对自动化用例构造数据造成阻碍。我可以分享的经验是小程序UI自动化的数据准备阶段我们通常不会依赖前端页面走真实登录流程而是通过后端接口直接造token、再注入到小程序缓存中。但小程序内部的请求可能会有签名校验这类校验一般需要研发侧提供一个“测试签名模式”或者提供一份可复用的签名生成工具库。别指望UI自动化去破解签名那是没意义的。另外如果你在开发“小程序a跳转小程序b”的流程UI自动化能不能覆盖可以覆盖一部分。比如点击跳转按钮后校验跳转动作是否被触发但真要验证目标小程序的落地页还是要进入目标小程序去继续跑另外一套自动化工程。这个边界要提前想清楚别在一个工程里塞太多跨小程序场景否则维护成本会成倍上升。还有一点容易被忽略真机上小程序顶部导航栏高度、安全区适配和开发者工具里看到的并不完全一样。虽然UI自动化主要跑在开发者工具里但如果有“导航栏自定义”这类功能建议额外在真机上抽测一遍因为自动化脚本只能保证逻辑链路没问题没法完整代替真机渲染验证。8. 绕不开的性能与稳定性跑UI自动化也要把“资源账”算清楚UI自动化看着只是“点一点”实际上消耗的资源一点都不少。开发者工具本身就吃内存一个复杂小程序项目同时打开几个页面后电脑风扇疯狂转是常态。如果你们团队只有一台共享测试机要安排好多套用例的并行节奏别在同一时间搞十几条任务否则会把机器拖死。我这边把UI自动化分成了两档日常快速回归控制在2到3分钟内跑完冒烟用例夜间全量回归控制在20分钟左右。超出这个时间范围后用例产出效率和稳定性都会下降。一个任务超过30分钟我建议就开始考虑是否需要拆分成多个任务或减少用例深度了。另外测试报告也值得关注。很多人跑完UI自动化只看“通过了没”但真正有价值的其实是失败截图、页面调用日志、控制台报错。miniprogram-automator里可以用page.screenshot()截图遇到断言失败时自动保存截图并attach到报告里能省去一大截排查问题的时间。async function screenshotOnFail(page, testName) { const screenshot await page.screenshot(); require(fs).writeFileSync(./reports/${testName}.png, screenshot); }把这段逻辑集成到Jest的afterEach里只要用例失败就自动截图定位问题的效率会直线上升。9. 最后一个经验把UI自动化当“产品”来运营而不是一次性脚本很多人搭好框架、写完用例、跑通一版后就万事大吉了但过了一两个月用例开始大面积失效然后又觉得自动化是负担。这里我想说一个能长期运转的小程序UI自动化体系必须有持续的运维投入。我目前的做法是每周固定抽一小时做“用例健康度巡检”。巡检内容包括哪些用例最近连续失败、哪些页面元素被改了导致选择器失效、哪些业务流程发生了调整、哪些用例可以合并或移除。同时我会让研发在代码评审时同步关注是否影响到了>
1. 从“手动点断手”到“脚本跑断腿”聊聊小程序UI自动化的真实起点做微信小程序测试的人应该都经历过那种“点来点去”的日子。小程序页面状态多、弹窗乱入、登录态一失效就要重新扫码测试回归一遍下来少说也得半小时。尤其是做电商、社区、工具类小程序改一个组件或者调一个接口可能就把之前的核心流程带崩了。我前前后后带过好几个小程序项目踩了无数坑之后终于把UI自动化这套东西跑通并沉淀了下来。这篇就是给那些正准备入坑小程序UI自动化的人看的也顺带聊聊我在实践中踩过的那些经典“坑”和最终稳定运行的方案。很多人以为小程序UI自动化很难搞其实现在的技术工具链已经相当成熟了。关键在于选对方案并且理解微信小程序自身的运行机制。小程序不像普通H5那样你在浏览器里拿到一个URL就能用Selenium开搞。它的页面结构是基于自研的渲染引擎有双线程模型跟常规的Web DOM并不完全一致。所以我们得先搞清楚小程序UI自动化的核心链路是什么再谈怎么写用例。我实测下来目前主流的做法可以分成三条路线一是微信官方提供的miniprogram-automator二是基于Appiumminicap等方式去做真机层面的驱动三是部分第三方云测平台自己封装的SDK。三条路线各有优劣需要按项目阶段去做取舍。这篇文章会重点讲透我常用的“官方SDK本地开发者工具”的落地方式这个方案对大多数中小团队来说是成本最低、见效最快、也最容易维护的。在动手之前我想先给你打个预防针UI自动化测的从来不是“业务逻辑”而是“页面表现流程”。如果你的项目页面结构不稳定、组件乱写、没有良好的语义化命名那不管用什么框架用例都会写得极其痛苦。所以做UI自动化本质上是反推研发团队去规范页面结构间接提升代码质量这个价值甚至比“发现BUG”本身更重要。2. 方案选型为什么我推荐miniprogram-automator而不是Appium2.1 迷你版官方驱动到底解决了什么问题miniprogram-automator是微信官方在开发者工具基础上做出来的一套Node.js SDK。它对外提供了一套类似于操作浏览器的API我们可以用它启动微信开发者工具、打开指定的小程序项目、控制页面跳转、获取页面数据、触发点击事件然后做断言。它的本质是“通过开发者工具的自动化接口去驱动小程序”。跟Appium这种通用移动端自动化框架比官方驱动有个先天优势它走的是微信开发者工具内置的调试通道不需要你处理各种设备连接问题也不需要你关心UIAutomator或者XCTest底层差异。而且它可以直接拿到小程序的Page实例、组件数据这对断言内部状态来说非常友好——直接比对data字段比在页面上扒文案方便多了。我最早其实是在Appium上折腾的那时候小程序还没有跨平台成熟方案得用webview切换的奇技淫巧稳定性一言难尽。后来微信官方出了miniprogram-automator果断迁过来了测试脚本量大概是原来的三分之二维护成本更是直线下降。2.2 三条技术路线的对比谁更适合你这里我直接放一张我整理的对比表方便你做初步决策方案运行环境稳定性上手成本适用场景miniprogram-automator微信开发者工具较高低开发自测、常规UI回归、CI环境Appium webview调试真机/模拟器一般高需要覆盖真机设备特性的场景云测平台SDK云真机取决于供应商中大规模兼容性回归、远程设备矩阵如果你只是想把现有小程序的“核心功能冒烟测试”和“常规回归测试”跑起来那最优先选官方驱动。而如果你要追的是“微信版本升级兼容性”“不同安卓机型上的页面渲染”那Appium体系还是有存在的必要只是成本也高得多。我自己团队的做法是本地、CI统一跑官方驱动定期再抽一批真机交给云测平台去做兼容性回归。2.3 为什么把开发者工具“装进流水线”是关键默认情况下微信开发者工具就是个IDE你需要手动打开、手动编译、手动操作。而UI自动化要跑起来第一步就是让工具能被“命令行控制”也就是把开发者工具当成一个可编程的运行时环境来使用。微信开发者工具本身提供了一个命令行工具cli可以通过类似cli auto --project 项目路径 --auto-port 9420的方式启动自动化端口。自动化测试脚本再通过这个端口连接进入项目环境。需要注意的是只有微信开发者工具登录了微信账号且打开了“服务端口”开关外部脚本才能连上。这一点是新手踩坑最多的地方。具体的选择逻辑其实很简单哪个工具能稳定地被脚本控制、能稳定的保活、能在无人值守环境下重启哪个就值得作为自动化的承载平台。桌面版微信开发者工具虽然需要一个GUI环境但在Linux CI机器上也可以通过一些显示虚拟化方案跑起来比如Xvfb这个后面我会展开讲。3. 环境搭建把工具、项目和SDK三者串起来3.1 从零初始化一份可以跑通的自动化工程我一般会用一个独立的Node项目来维护所有UI自动化用例然后通过npm script去控制执行。这个项目只做UI自动化相关的事情和被测小程序项目本身分开。第一步需要安装miniprogram-automator作为依赖用npm或者yarn都行。npm init -y npm install miniprogram-automator --save-dev第二步需要确认微信开发者工具的版本。用官方SDK时我强烈建议你用最新稳定版工具因为有些自动化接口和编译能力会随开发者工具更新而变化。项目里有个project.config.json要确保其中的appid是你自己在公众平台申请的真实AppID或者测试号。第三步手动打开一次微信开发者工具并导入小程序项目。这一步是为了让工具记住项目并且允许后续命令行自动打开。同时确保在“设置 - 安全设置”里开启了“服务端口”。如果没开启后面连接时会直接报错提示你无法连接自动化端口。3.2 启动/连接开发者工具的自动化通道现在要跑一个最小化冒烟脚本。先确认路径开发者工具CLI在macOS上通常位于/Applications/wechatwebdevtools.app/Contents/MacOS/cli在Windows上则类似C:\Program Files (x86)\Tencent\微信web开发者工具\cli.bat。可以先手动执行一下自动化启动命令cli auto --project /path/to/your/miniprogram --auto-port 9420这个命令会打开项目并监听9420端口。接着在Node脚本里通过miniprogram-automator连接const automator require(miniprogram-automator); async function run() { const miniProgram await automator.connect({ wsEndpoint: ws://localhost:9420, }); // 拉取当前页面栈 const page await miniProgram.reLaunch(/pages/index/index); await page.waitFor(500); // 做点什么 const title await page.$(.page-title); console.log(await title.text()); await miniProgram.close(); } run();跑起来后如果能在控制台看到页面里某个元素的文本内容说明环境串起来了。这一步能通后续就等于打通了任督二脉下面的用例编写、数据层断言、组件交互全都可以在这个通道上做。提示connect时如果提示连接失败优先检查1. 开发者工具是否打开了自动化端口2. 项目是否已经导入3. 端口号是否一致。这几步占了环境问题中的八成。3.3 把自动化工具跑在Linux CI服务器上如果你们团队已经把自动化用例放到CI里跑那大概率会遇到一个问题Linux服务器上没有桌面环境微信开发者工具是GUI程序怎么让它跑起来我实验出来的稳定方案是安装Xvfb用虚拟显示去承载开发者工具。在Ubuntu上可以执行sudo apt-get install -y xvfb Xvfb :99 -screen 0 1280x800x24 export DISPLAY:99然后再执行开发者工具的启动命令。实测下来稳定性还不错。只是一定要在CI配置里预留足够的启动时间别一启动就立刻执行connect最好增加重试机制因为开发者工具冷启动有时会需要好几秒。另外建议在CI里把开发者工具安装为独立版本和本地日常开发使用的版本隔离。否则每次CI强制更新或者日常手动升级工具都可能导致自动化运行环境被意外改变非常难受。4. 核心实操页面跳转、元素定位和断言到底怎么写4.1 页面对象Page和数据生命周期的理解小程序页面和传统Web页面有个本质区别小程序的逻辑层和渲染层是分开的。UI自动化在驱动页面的时候能看到的数据其实是从逻辑层同步过去的因此拿到element之后执行点击、输入等操作最终触发的是框架里的setData等动作。用官方SDK操作页面时通常先拿Page对象再拿元素// 直接通过 reLaunch 打开页面 await miniProgram.reLaunch(/pages/goods/list); const page await miniProgram.currentPage(); // 通过 .$ 找到元素 const goodsItem await page.$(.goods-item); await goodsItem.tap();这里有个细节currentPage()拿到的是当前显示的页面对象如果你调用reLaunch之后立刻调用currentPage()有可能因为页面切换动画还没结束导致拿不到正确的页面。可以考虑加一个等待或者使用waitFor的方式等待页面关键元素出现。另外小程序的页面也是一层一层挂载的navigateTo可以叠加栈reLaunch会清空栈。编写用例时如果你只是想在当前栈基础上跳到一个新页面做测试可以使用navigateTo但要注意用例跑完后要把页面栈跳回来或者重新启动避免对后续用例造成干扰。4.2 定位元素的方式选择器、文本、自定义属性小程序官方驱动支持通过CSS选择器来定位元素这个能力是真的香。我们可以用.class、#id、[data-testidxxx]、甚至::text(文案)这类伪选择器。看官方文档时你可能见过一些$方法但我强烈建议在团队里统一约定“自动化测试专用定位属性”比如>const page await miniProgram.currentPage(); const loginBtn await page.$([data-testidlogin-btn]); await loginBtn.tap(); // 也可以在元素上做文本判断 const userName await page.$(.user-name); console.log(await userName.text());如果实在没有合适属性也可以使用文本选择器。文本选择器的写法比较特殊比如page.$(view[data-testidxxx])会用CSS路径而page.$$(text首页)这种写法也能在某些版本中生效但稳定性一般所以只建议用作文本断言的辅助方式。4.3 弹窗、组件、原生控件的“不可控”问题小程序里一旦涉及到原生组件像某些输入框、地图、视频、canvas、textareaUI自动化的可操作性会肉眼可见地下降。这个问题不仅存在于官方SDK也存在于其他方案中。原生组件在很多版本里是显示在webview之上的普通元素选择器根本捕捉不到。我的经验是优先在业务侧把这类控件替换成可测试的封装组件或者给原生组件包一层容器暴露操作按钮等替代交互。比如地图选点、日期时间选择等都可以通过数据注入或者隐藏按钮的方式去绕过原生控件。另外很多小程序项目用了第三方组件库比如Vant Weapp、TDesign等。这些组件内部往往渲染多层结构不能直接用文字断言。不过组件是自带行为事件的可以配合“页面数据”的变化来验证组件交互是否生效。这也回应了前面那个观点小程序UI自动化的核心不一定全在UI上很多数据响应逻辑通过page.data()去断言更靠谱。const page await miniProgram.currentPage(); const initialData await page.data(count); // 点击加号按钮 await (await page.$([data-testidincrease-btn])).tap(); await page.waitFor(200); const newData await page.data(count); // 断言 if (newData ! initialData 1) { throw new Error(点击加号后count未变化); }这里验证的是数据层状态比单纯看页面文案稳定得多尤其适合表单、列表筛选、计数类交互。5. 进阶实战把UI自动化跑进日常CI流程5.1 在Jenkins/GitLab CI中接入完整回归脚本很多团队一开始只在本地手动跑一下UI自动化脚本但真正的价值点在于接入CI让每次提测、每次发布前都自动跑一遍核心回归。我在Jenkins上做过一个流水线大概的步骤是从Git拉取被测小程序代码。使用Node脚本执行依赖安装。初始化XvfbLinux环境。启动微信开发者工具的自动化模式。运行测试用例用的Jest runner。生成测试报告并归档。关闭开发者工具清理进程。下面这段是Jest runner里测试文件的简单例子const automator require(miniprogram-automator); describe(小程序购物车流程, () { let miniProgram; beforeAll(async () { miniProgram await automator.launch({ projectPath: process.env.MP_PROJECT_PATH, port: 9420, }); await miniProgram.reLaunch(/pages/home/home); }); afterAll(async () { await miniProgram.close(); }); it(添加购物车后角标数量变化, async () { const page await miniProgram.currentPage(); await (await page.$([data-testidadd-cart-btn])).tap(); await page.waitFor(500); const badgeText await (await page.$(.cart-badge)).text(); expect(badgeText).toContain(1); }); });这里有个经验如果启动开发者工具的过程比较慢导致Jest在beforeAll里连接失败可以在外面封装一个启动等待函数循环等待端口可用。5.2 用例分组与冒烟/全量回归策略UI自动化最忌讳的就是“一个失败全盘崩”所以要建立用例分组的习惯。我从实践中总结的分组策略是分组范围执行时机smoke登录态、首页加载、核心路径跳转每次代码提交后的快速检查regression所有核心业务用例每日夜间定时跑page-detail针对某个页面的专项测试页面改动频繁或上线前特批时执行在Jest里可以用testPathPatterns来匹配分组的文件比如npx jest --testPathPatternstests/smoke这样日常提交只跑冒烟夜间才跑全回归兼顾效率和稳定性。5.3 与小程序“体验版”和“开发版”发布流程的配合这里多说一句热词里很多人会问“体验版二维码在哪”“线上小程序怎么拿源码”。从测试的角度讲UI自动化建议统一跑“开发版”或当前本地构建出来的代码包不要去跑线上“正式版”。原因是线上环境和本地代码包不一定同步也无法随意注入环境变量或者开启调试模式。我们团队的做法是在CI构建出小程序包后先把构建产物自动导入开发者工具跑完自动化用例再走提审或上传体验版流程。这样能保证测试的就是即将发布的那个包把“测试包和发布包不一致”的坑提前避掉。6. 常见问题与排查技巧实录6.1 开发者工具连不上端口不通这基本是新手第一个遇到的墙。现象是connect调用后长时间未连接或直接报Error: connect ECONNREFUSED。排查思路检查开发者工具的“设置 - 安全设置 - 服务端口”是否开启。检查命令行启动参数里的端口是否和connect里的端口一致。检查是否有多个开发者工具实例占用同一端口建议把其他实例先关掉。在CI环境注意跨容器访问时IP不能写成localhost要按实际网络配置来写。多数情况下以上四步就能解决八成连不上问题。6.2 运行一段时间后页面元素定位失败这种情况比较诡异用例前面执行正常跑到十几分钟后开始大面积失败。经验是开发者工具长时间运行会占用大量内存或者页面栈/缓存越来越多导致样式错乱。我的办法是跑完每组用例后主动重启开发者工具或者给整个自动化任务设置定时重启。在CI上我直接封装了“执行前自动kill已存在的开发者工具进程再重新拉起来”的逻辑。最终效果很稳。6.3 点击元素偶发失效tap没有反应这通常不是代码问题而是操作太快了。小程序的渲染和逻辑之间有个异步链路数据更新后组件不一定马上可点击。我总结的稳定写法是“三步走”async function stableTap(page, selector) { const element await page.$(selector); await element.waitFor(); await page.waitFor(300); await element.tap(); await page.waitFor(300); }虽然看起来有点傻但这类固定小延时能很大程度提升点击成功率。如果你不想写死延时也可以改成循环尝试如果点击之后页面没有预期变化就再点一次直到超过重试次数。6.4 页面里存在多个相同>const cards await page.$$([data-testidgoods-card]); if (cards.length 2) { throw new Error(商品列表数量不足); } const secondCard cards[1]; await secondCard.tap();需要注意$$返回的元素是数组你在运行时把它当成普通元素用会报错建议多打印一下数组长度避免选择器没匹配到任何节点。6.5 自动化脚本不稳定偶发失败因素汇总这里是我实际跑自动化过程中总结的“不稳定来源”清单不稳定因素影响程度应对方式开发者工具版本升级高锁定自动化专用工具版本网络请求耗时波动中对接口进行mock或增加等待策略页面渲染动画时长中统一等待关键元素出现测试数据残留高执行前重置用户数据和后端状态组件库内部行为差异中尽量用数据断言替代纯UI断言用例执行顺序影响高每个用例独立启动或清理登录态这份清单基本是每个做小程序UI自动化的人都绕不开的坑。提前知道能帮你避免很多“玄学问题”。7. 关于“小程序签名/抓包/多端适配”等延伸问题的思考在热词里总能看到“微信小程序签名”“微信小程序抓包”这类疑问。签名和抓包虽然不直接属于UI自动化范畴但它们往往会在实践中冒出来。比如你要调试自动化脚本里某个请求的返回可能需要临时抓包你要校验某些登录态的签名逻辑也会对自动化用例构造数据造成阻碍。我可以分享的经验是小程序UI自动化的数据准备阶段我们通常不会依赖前端页面走真实登录流程而是通过后端接口直接造token、再注入到小程序缓存中。但小程序内部的请求可能会有签名校验这类校验一般需要研发侧提供一个“测试签名模式”或者提供一份可复用的签名生成工具库。别指望UI自动化去破解签名那是没意义的。另外如果你在开发“小程序a跳转小程序b”的流程UI自动化能不能覆盖可以覆盖一部分。比如点击跳转按钮后校验跳转动作是否被触发但真要验证目标小程序的落地页还是要进入目标小程序去继续跑另外一套自动化工程。这个边界要提前想清楚别在一个工程里塞太多跨小程序场景否则维护成本会成倍上升。还有一点容易被忽略真机上小程序顶部导航栏高度、安全区适配和开发者工具里看到的并不完全一样。虽然UI自动化主要跑在开发者工具里但如果有“导航栏自定义”这类功能建议额外在真机上抽测一遍因为自动化脚本只能保证逻辑链路没问题没法完整代替真机渲染验证。8. 绕不开的性能与稳定性跑UI自动化也要把“资源账”算清楚UI自动化看着只是“点一点”实际上消耗的资源一点都不少。开发者工具本身就吃内存一个复杂小程序项目同时打开几个页面后电脑风扇疯狂转是常态。如果你们团队只有一台共享测试机要安排好多套用例的并行节奏别在同一时间搞十几条任务否则会把机器拖死。我这边把UI自动化分成了两档日常快速回归控制在2到3分钟内跑完冒烟用例夜间全量回归控制在20分钟左右。超出这个时间范围后用例产出效率和稳定性都会下降。一个任务超过30分钟我建议就开始考虑是否需要拆分成多个任务或减少用例深度了。另外测试报告也值得关注。很多人跑完UI自动化只看“通过了没”但真正有价值的其实是失败截图、页面调用日志、控制台报错。miniprogram-automator里可以用page.screenshot()截图遇到断言失败时自动保存截图并attach到报告里能省去一大截排查问题的时间。async function screenshotOnFail(page, testName) { const screenshot await page.screenshot(); require(fs).writeFileSync(./reports/${testName}.png, screenshot); }把这段逻辑集成到Jest的afterEach里只要用例失败就自动截图定位问题的效率会直线上升。9. 最后一个经验把UI自动化当“产品”来运营而不是一次性脚本很多人搭好框架、写完用例、跑通一版后就万事大吉了但过了一两个月用例开始大面积失效然后又觉得自动化是负担。这里我想说一个能长期运转的小程序UI自动化体系必须有持续的运维投入。我目前的做法是每周固定抽一小时做“用例健康度巡检”。巡检内容包括哪些用例最近连续失败、哪些页面元素被改了导致选择器失效、哪些业务流程发生了调整、哪些用例可以合并或移除。同时我会让研发在代码评审时同步关注是否影响到了>
