UI Recorder 实战：基于录制回放的低门槛Web自动化测试方案

1. 项目概述UI Recorder 到底解决了什么问题做Web端测试的同学应该都有过这种经历手工测试点来点去一天下来眼睛花了、手腕酸了回归用例还有一大堆没跑完。想上自动化又绕不开那套学习曲线陡峭的框架——写定位器、处理等待、维护用例光是环境搭建就能劝退一半的人。UI Recorder 的出现本质上就是把自动化测试的门槛从会写代码降到了会点浏览器。它的核心思路非常简单直接你在浏览器里的每一次操作它都帮你记录下来自动翻译成测试脚本。脚本不是那种只能自己看的临时品而是结构清晰、可以直接交给团队维护的正式代码。我第一次看到生成的用例时第一反应是这比我手写的整洁多了。它的解决方案一句话总结用录制的低成本换取脚本的可维护性再用脚本的可复用性抵消录制带来的脆弱性。适合谁刚接触自动化的新人想快速给项目补上回归测试的团队以及对脚本维护成本敏感的技术负责人。不需要太深的编程基础但如果你懂一点JavaScript后面玩断言、玩数据驱动的时候会顺手很多。从我实际使用的体感来说UI Recorder 最打动我的不是录制本身而是它生成的代码质量。很多录制工具的问题是能跑但没法看代码冗余一堆UI Recorder 在这一点的处理上明显用了心。它生成的脚本结构合理变量命名清楚注释也到位新人和老人接手都不难受。2. 核心设计思路拆解为什么录制回放这条路能走通2.1 录制回放和手写脚本的差别在哪传统自动化测试为什么要学起来痛苦因为你要同时掌握三件事定位器语法比如 XPath 和 CSS、等待策略、测试框架本身的API。对于一个只负责功能验收的测试人员来说这三座大山没一座好翻。UI Recorder 的思路是把我懂技术这个问题先放到一边让工具替你做技术活。它通过浏览器插件或者远程调试协议去监听你的操作鼠标点击、键盘输入、页面跳转、滚动、甚至文件上传全部捕获然后自动映射成对应的Selenium或者WebDriver API调用。但这里有个关键点录制不是录完就完事。你录制的是一次操作路径但这个路径要能稳定回放靠的是脚本里的定位策略和等待机制。UI Recorder 在这部分的处理方式是尽量给每个操作元素生成稳定的定位表达式配合内置的智能等待把最容易翻车的两个环节提前做了兜底。2.2 和市面上的录制工具横向比区别在哪我早期用过一些录制回放工具说实话体验并不理想。有的录完没法改UI一变化整条用例报废有的生成的是私有格式离开了工具就跑不了。UI Recorder 聪明的地方在于它绑定的是 Selenium 生态生成的脚本就是标准的 Selenium 脚本你完全可以脱离录制器用原生方式去改、去跑、去集成到测试平台里。打个比方有些录制工具给你的是一张地图但地图是加密的必须用它的浏览器才能看。UI Recorder 给你的是一张普通地图你用任何一辆车都能按着地图跑。这种不绑架用户的设计其实是很高的产品理念。另外它的多浏览器支持也不错。Chrome 肯定是亲儿子Firefox 也能跑还有 Electron 应用也能测。对于现在很多前端项目用 Electron 打包桌面应用的团队来说这一个点就足够了。3. 环境准备与安装从零开始搭建可用的录制环境3.1 需要准备哪些基础工具动手之前先把基础环境捋清楚。UI Recorder 本身是 Node.js 生态里的工具所以 Node 环境是第一步。建议直接装 Node 的 LTS 版本不要追新稳定压倒一切。装完之后npm 就跟着一起有了。第二个是 Chrome 浏览器。虽然 Firefox 也能用但我在实际项目里绝大部分场景都是 Chrome因为 Chrome DevTools 协议的兼容性最好录制和回放的稳定性都比 Firefox 高一个档次。Electron 应用的话需要额外处理一下启动参数后面细说。第三个是 Java 环境。这个很多新手会在意为什么录个脚本还要装 Java因为 Selenium Server 是用 Java 写的UI Recorder 的回放引擎需要依赖它启动浏览器。装上 JDK 8 以上的版本就行不用太纠结版本我用的是 JDK 11跑得很稳。3.2 一步步装好环境安装步骤不复杂但每一步都有坑我踩过所以帮你标出来。第一步安装 Node.js。到官网下载安装包一路下一步没什么好说的。装完验证一下node -v npm -v能看到版本号就说明这一步过了。如果提示node 不是内部或外部命令那是环境变量没配好Windows 用户去系统设置里把 Node 的安装目录加到 PATH 里。第二步初始化项目目录。建议不要一股脑装在全局给每个项目单独建一个目录依赖隔离后面维护不头疼。mkdir uirecorder-demo cd uirecorder-demo npm init -y第三步安装 UI Recorder 和相关依赖。npm install uirecorder mocha -g npm install uirecorder这里有个细节我建议-g全局装一份让uirecorder命令可以直接在终端里调用同时在项目本地也装一份保证回放时的依赖版本一致。第四步安装 Selenium Standalone。UI Recorder 有内置的安装命令uirecorder --install这个命令会自动下载 Selenium Server 和对应版本的浏览器驱动。注意要保证网络通畅它需要从仓库拉文件。下载过程可能有点慢耐心等就好。装完检查一下uirecorder --version能显示版本号就说明核心环境已经通了。3.3 一个容易忽略的细节Chrome 和驱动的版本匹配这里专门提醒一下Chrome 的版本和驱动版本必须匹配否则回放的时候浏览器起不来或者启动起来就报错。UI Recorder 的--install命令会自动处理这个匹配但如果你的 Chrome 后来升级了驱动没跟上就会出问题。我遇到过一次Chrome 自动更新之后回放脚本时浏览器闪退控制台报ChromeDriver only supports Chrome version XX。查了半天最后删掉驱动重新执行uirecorder --install解决的。提示如果你所在团队统一管控浏览器版本建议固定 Chrome 的自动更新策略否则每隔一阵子就要重新匹配一次驱动。4. 核心实操录出第一条可维护的测试用例4.1 从启动录制器开始环境就绪后我们就可以正式开始录。在项目目录下执行uirecorder --start它会启动一个录制配置页面让你填写一些基础选项包括项目名称、是否覆盖本次录制等。填完确认后会自动拉起一个 Chrome 窗口这个窗口就是你的录制现场。你在里面做的每一次操作都会被记录下来。这里有一个新手最容易疑惑的点那个配置页面的项目名称到底有什么作用它实际上是用来组织测试用例文件的比如你在页面上填了 user_login 那么录制完生成的测试文件就会归到和登录相关的用例组里。命名的时候建议带上模块名比如module_login、module_register方便后面按模块跑测试。启动录制后你会看到 Chrome 窗口右上角有一个录制面板记录着当前录制的操作数。这时候先不要急着乱点心里过一遍你的测试场景比如输入账号、输入密码、点击登录、断言页面跳转。操作顺序越接近真实用户脚本的可读性越高。4.2 录制操作时的注意事项之前提到UI Recorder 会为每个操作元素生成定位表达式但如果我们录制的时候不小心录出来的定位器可能不够稳定。根据我的经验下面几条很关键第一给元素加上稳定标识再录。如果被测系统是你们自己团队的最好给关键表单元素加上id或者>uirecorder --run它会读取配置启动浏览器把录制的操作按顺序重放一遍。第一次回放如果有失败大多数情况就是定位或者等待问题。UI Recorder 会输出详细的执行日志哪一步失败了失败原因是什么一目了然。别急着烦躁这是最正常的环节。我在第一次回放时遇到的典型问题页面上有个弹窗动画实际弹窗延迟了 1 秒回放时断言执行太早结果失败。这种问题通过给用例加step延时或者调整等待策略就能解决。UI Recorder 支持在录制时主动插入延时步骤右键加上等待元素出现的操作效果比固定 sleep 高到不知道哪里去了。这个点要特别强调一下固定 sleep 是最笨的等待方式。我们在实际编写脚本时尽量使用条件等待——等某个元素出现、等某段文字变化、等某个按钮可点击。UI Recorder 内置的智能等待能覆盖大部分场景个别特殊场景可以手动插入waitFor类型的步骤。5. 进阶玩法把用例做得更符合工程化要求5.1 参数化一条用例跑多组数据录制脚本的优势是入门快但如果你想做数据驱动直接改生成的代码比重新录制要高效得多。UI Recorder 生成的脚本是标准 JavaScript所以参数化处理完全自由。举个例子登录用例假如录制时用的是账号 testuser现在想用 user1、user2、user3 分别跑一遍直接把用例体里的input那行的值抽出来变成变量即可加一层循环或者用 Mocha 的动态生成用例方式都可以实现数据驱动。有一点要注意改了代码之后最好先单条跑一遍再放量跑。因为录制时的操作顺序可能对特定数据有依赖比如账号 user1 注册过、账号 user2 没注册过场景预期就不一样了。参数化之前把数据的分支逻辑想清楚。5.2 多浏览器并行从单浏览器到矩阵测试UI Recorder 本身支持多浏览器的配置可以同时跑 Chrome 和 Firefox 的用例矩阵。这在做跨浏览器兼容性回归的时候特别有用比手工去一个个浏览器点一遍靠谱多了。配置上在项目配置文件里把desktop那段的browserName列表里加上chrome和firefox就行。跑起来之后它会给每个浏览器单独拉起一个会话。要注意的是并行跑测试时本机的 CPU 和内存占用会明显上升如果你的机器配置一般建议要么减少并行数要么直接上 CI 分布式执行。并行执行最常见的坑是资源竞争。比如两条用例同时在同一个测试环境里操作A 用例删除了某条数据B 用例恰好在等那条数据出现双双超时失败。这种问题不是脚本问题是数据隔离问题。解决办法是在用例的beforeEach里做好前置数据的准备保证每条用例都有独立的初始状态。5.3 与 CI 集成让用例定时无人值守地跑如果你已经跑到这个阶段说明你不满足于本地手动跑用例了。把 UI Recorder 的用例集成到 CI 流水线里思路和普通 Node.js 项目的 CI 集成没什么区别。核心命令是npm run test前提是在package.json里配好脚本{ scripts: { test: uirecorder --run } }CI 上跑 UI Recorder 有几个环境准备步骤有些同学会在这一步卡住。首先是 Linux 环境下需要有显示服务。CI 机器一般没有显示器但浏览器要渲染就必须有。解决办法是用xvfb或者 headless 模式。UI Recorder 对 headless 模式的支持不错Chrome 的 headless 模式下照样可以录和跑。然后是浏览器驱动的问题。CI 机器上最好也执行一次uirecorder --install保证驱动和浏览器版本匹配。有些团队直接把驱动放到制品库统一分发减少每次执行时的下载时长。5.4 移动端如果是 App 的 H5 页面怎么办有些场景是测 App 内嵌的 H5 页面。这里的思路比较特殊UI Recorder 录的是浏览器操作而 App 内嵌的 WebView 本质上还是基于 WebKit 渲染的页面。实操上一般会先在桌面浏览器里把 H5 页面的用例录好然后在移动端的 WebView 里做兼容验证。需要注意的是移动端 WebView 的 touch 事件和桌面 click 事件有细微差异回放的成功率取决于页面对事件的绑定方式。如果要真正自动化测 App 原生控件UI Recorder 就不太适合了它有自己清晰的边界——专注 Web UI 自动化。这个定位其实是件好事正因为足够聚焦它才能在 Web 领域做得很透。6. 常见问题速查我实际踩过的坑都在这了6.1 回放时找不到元素怎么办这是 UI Recorder 使用途中最高频的问题没有之一。Element Not Found或者NoSuchElement的报错90% 的原因就是定位器写死了但页面元素发生了变化。处理思路是分层的。首先是定位策略的问题。生成的脚本里定位器可能是 CSS 选择器也可能是 XPath。如果页面结构没有变那可以去检查一下是不是有 iframe。iframe 里的元素需要先切换进入否则无论如何都定位不到。UI Recorder 对 iframe 的处理有时候不够自动需要在脚本里手动加一步切入 iframe 的操作。其次是动态元素的问题。比如列表项在刷新前后 ID 会变化这种场景就不适合用绝对 ID 定位而应该找一个稳定的父级容器通过层级关系去定位。改脚本的时候优先用语义化的 CSS 选择器减少对 XPath 的依赖维护性会好一些。还有就是隐式等待和显式等待的配置。在 UI Recorder 生成的脚本里默认已经加了智能等待机制但如果页面加载特别慢可以适当增大等待时间。切换等待时间的话一般优先调单条用例的配置不要一上来把全局配置拉满不然失败一条用例要等十几秒才报错排查效率更低。6.2 回放时浏览器总是闪退这个问题我遇到过的场景是Chrome 自动更新之后和驱动版本不匹配。解决办法很简单重跑uirecorder --install让它重新下载匹配的驱动。还有一个常见诱因是系统内存不足并行跑用例的时候特别容易出现。如果浏览器打开后直接崩溃留意一下任务管理器里的内存占用关掉不相关的大程序再跑。6.3 录制时操作被漏记有时点击某个按钮后录制面板上的操作数没有增加。这种情况多数是因为那个按钮不是标准 HTML 元素或者监听的鼠标事件用的是mousedown而不是click。处理办法是录制时用键盘操作代替鼠标点击比如用Tab键聚焦按钮然后回车触发UI Recorder 对键盘事件的捕获通常更稳定。6.4 生成的脚本在别的电脑上跑不了这就是典型的在我机器上好好的问题。差在哪里大概率是依赖版本不一致。你在本地装上了一个版本的 chromedriver同事机器上是另一个就会出现环境差异。规避方法是在项目的package.json里锁定所有依赖的版本号用npm shrinkwrap或者直接提交 lock 文件。另外在团队内部统一 Node 版本和 Chrome 版本能省下很多环境排障的时间。6.5 断言失败但页面看起来是对的这个情况比较隐蔽。页面是对的但断言失败大概率是断言的目标选错了。比如你要断言用户名字段显示为张三但页面上有多个元素包含了张三文字字段旁边有一个隐藏的span里也藏着张三可能导致选择器选中了隐藏元素。这时候把定位器写得更精确比如限制:visible或者用文本定位器去匹配可见元素。7. 抛砖引玉UI Recorder 后续怎么玩玩顺了基本的录制回放UI Recorder 对你来说就不是一个玩具工具了而是一个能真正支撑业务回归的自动化测试底座。你可以基于它做更多延伸比如配合代码覆盖率工具分析测试盲区或者把脚本回归到每个发布前自动触发甚至做成一个简易的测试平台让非技术同事也能通过录制来补充用例。我个人的体会是自动化测试工具的价值不在于工具本身多强大而在于它能不能把团队里非技术成员的能力上限拉高。UI Recorder 在这件事上做得很好录制带来的低门槛、Selenium 脚本带来的生态、加上 Node.js 带来的工程化基础设施这条链路相当顺。最后再分享一个小技巧在录制脚本时请务必保证被测页面是你精心准备的、干净的初始状态。曾经我偷懒没清浏览器缓存直接开录录完发现脚本里多了一堆无用操作后面整整花了一个小时删冗余步骤。录制前花半分钟清一下数据、关掉无关弹窗后面能省半天时间。