Katalon Recorder实战指南：从浏览器录制到Selenium脚本落地

简介Katalon Recorder 是一款面向 Web 自动化测试的 Chrome 脚本录制工具适合测试工程师与自动化测试初学者能显著降低 Selenium 脚本编写门槛解决手工回归测试步骤繁琐、易遗漏的问题。该压缩包共包含 4 个文件katalon-recorder-selenium.crx 和 Infinity 新标签页增强插件.crx 两个浏览器扩展组件以及 how-to-install.html 与安装说明.html 两份安装指导文档整体大小仅 3.95MB轻量易部署。已有 1515 人学习下载配套文档对拖拽安装、扩展启用、录制启动到脚本编辑的各环节均有清晰说明。安装后可在 Chrome 中直接录制网页操作并回放自动生成可编辑的 Selenium WebDriver 脚本支持添加断言、循环等高级逻辑生成的脚本还能按需适配 Java、Python 等语言环境方便后续维护扩展。同时内置的 Infinity 插件可优化新标签页与书签管理兼顾测试与日常浏览器使用是一份面向实战的轻量自动化测试入门材料。1. Katalon Recorder是什么从浏览器插件到脚本资产的第一站先说结论Katalon Recorder 不是一个 IDE 式的重型自动化平台而是一个藏在浏览器里的脚本录制工具。它把你在 Chrome 或 Firefox 上的点击、输入、选择、滚动等操作录成可回放的脚步文件然后一键导出成 Java、Python、JavaScript 等 Selenium 代码。很多团队第一次接触它不是因为要搞多复杂的框架而是因为手上有一批重复的 Web 验收用例又不想为这点事去搭一套完整工程。它解决的是「把手工操作变成可重复执行脚本」的问题。适合三类人还没引入自动化测试、想先从录制切入的测试人员需要快速为老系统补冒烟用例的维护者以及想对比 Selenium 几种语言写法、需要一个代码生成器的开发。它和 Katalon Studio 的关系是Recorder 是 Chrome 扩展Studio 是独立桌面应用两者共享同一套录制回放内核但 Studio 带关键字驱动和完整报告体系Recorder 走得是轻量、导出、交给外部框架这条路。这篇文章里我会把从安装到避坑的一条完整路径讲清楚重点是你在真正落地时会遇到的边界问题。2. 搭好录制环境安装插件、认清录制界面的三个关键区2.1 插件安装与浏览器兼容Chrome 和 Firefox 的做法Katalon Recorder 作为浏览器扩展安装入口有两个Chrome Web Store 和 Firefox Add-ons 商店直接搜 Katalon Recorder 即可。如果你所在的内网环境访问不了应用商店常见做法是由同事从装了插件的浏览器里导出 CRX / XPI 文件再拖进目标浏览器手动添加但要注意Chrome 从 2023 年起对非白名单来源的 CRX 安装限制更严格首次安装时要在扩展管理页打开「开发者模式」才能拖进去而且这类离线安装的扩展在浏览器升级后有失效风险稳妥起见公网环境直接从应用商店装。安装后浏览器右上角会出现 Katalon 图标。点击图标弹出的主界面自上而下分成三个区域录制控制栏、测试步骤列表、底部的日志输出。控制栏左侧是地址输入框右侧是 Record、Play、Stop 三个按钮。中间步骤列表默认显示「Command / Target / Value」三列这个概念继承自 Selenium IDE是后面手动修脚本的基础。底部日志在排错时特别有用回放失败后先看这里它会明确告诉你某个步骤是定位不到元素还是等待超时。安装装好后先别急着录。Chrome 和 Firefox 的安全策略会让扩展默认处于「仅点击时读取网站数据」状态如果你在页面上点击后发现步骤没被记录很可能是扩展权限没放开。取捷径打开插件详情页把「读取站点数据」设为「在所有网站上」如果只针对测试环境录也可以只在指定站点上启用这样更稳。# 用 npm 做点准备工作后面导出脚本时可能用到依赖 npm init -y npm install selenium-webdriver这里装的是 Selenium JS 版本的官方绑定。导出代码时如果选 JavaScript 格式就会用到它。Python 格式则对应 pip install seleniumJava 格式对应在 Maven 里引依赖。录制工具本身不装这些包但你要在本地跑导出脚本语言生态的 driver 是必须的。记住Katalon Recorder 只负责「记录和生成」执行能力取决于你选的 Selenium 绑定与浏览器驱动。2.2 三个关键设置慢速模式、测试延时与启动 URL录制前必须动一下设置否则后面回放十有八九翻车。点击界面右上角的「Settings」按钮重点关注三个项Slow Execution 慢速模式默认关闭开启后回放时每一步之间会有更长间隔。首次回放强烈建议打开尤其是目标系统有列表加载、弹窗特效、Ajax 刷新的场景。它的本质是给每一步之间插入固定等待时间而不是靠显式等待动态判断页面是否就绪所以定位慢但稳。Execution Timeout 执行超时默认是 60000ms60 秒指单条命令最长等待时长。内网系统响应快这个值可以不调但如果你录的是页面里嵌了地图、报表等重型模块的系统建议调到 120000ms否则回放时只是页面个别资源加载慢单步就会判定失败。Launch URL 启动地址这里填被测系统的首页地址。填上后每次回放第一步就是自动打开这个地址并等待加载省去手动输入 URL 的步骤。同时录制时如果切到了新域名插件会弹窗提示你确认是否允许记录跨域动作这是我后来才注意到的细节。表格里我列一下常用配置参数参数默认值建议值影响Execution Timeout60000 ms60000 ~ 120000 ms单步命令等待元素出现的最长时间Slow Executionfalse首轮回放开 true每步间插入额外等待稳定但慢Launch URL空被测系统首页回放时自动导航到该地址Test Delay0 ms某些版本为循环间延时300~500 ms控制步骤间的固定延时注意参数里的常见认知误区Execution Timeout 不是「整个用例的超时」而是每个单条命令内部去找元素、校验状态时的上限。你看到某一步卡了很久才报错不是用例超时而是这步走到了超时的临界值。想从整体控制用例跑多久是另一个层面的做法。2.3 理解 Command / Target / Value 的录制产物结构录制出来的每个步骤本质上都是 Selenium 风格的动作描述。Command 列是动作类型常见有 open打开地址、click点击元素、type输入文本、select下拉选择、verifyText校验文本等等。Target 列是目标元素的定位默认会生成 XPath 或者 CSS 选择器Value 列是附带参数比如 type 时输入的文本内容。这个结构有一个隐藏优点你不需要全部依赖录制器。比如录制时点的是一张图片按钮录出来可能是 click xpath//div[3]/img这个 XPath 在回归时脆得不行。手动改 Target 才是录制的真正价值所在——把录制生成的定位方式换成有业务语义的 CSSclick cssbutton[data-testidsubmit-btn]。这个写法在插件里直接改 Target 列即可生效。回放的原理是Play 按钮启动后插件把 Target 列里的定位表达式抛给 Chrome 的 Debugger 协议去查找对应的 DOM 节点找到后触发对应的原生事件。它不是靠模拟 JS 直接调用元素方法而是按用户操作的事件序列去触发。这个机制决定了它录出来的脚本在事件监听严格的前端框架React/Vue下回放率通常更高因为触发的都是浏览器真实事件。3. 从录制到导出的完整流转把操作变成代码资产3.1 第一次录制的完整路径从打开到回放成功我建议第一次录制时找一个带登录框和几个表单字段的普通页面按下面五步走第一步点击 Katalon Recorder 图标在 Launch URL 里填上被测页面的地址点击 Record 按钮。地址栏会自动跳到该页面此时右上角显示「Recording」。第二步按平时的操作走一遍输入用户名、密码、点击登录、点击菜单、翻一页列表。不要快每个动作之间停顿 1 秒左右。录制时会发现步骤列表里每一步操作都对应生成一条记录。第三步停止录制点击 Save 按钮给用例起名。第四步点击 Play 回放同时观察页面。首次回放开启 Slow Execution。第五步回放结束看顶部状态绿色对勾表示通过红色表示失败失败的步骤会高亮。这五步里最容易出问题的是第二步和第四步录入时手速太快插件有时会漏掉中间的一次 click导致回放顺序和你预期的操作序列不一致。这不是 bug而是页面在极短时间内发生多次 DOM 变更插件从 Debugger 协议拿到的节点信息出现竞争。解决方法是录慢一点重要步骤之间至少间隔 500ms 以上这也是为什么 Test Delay 参数要留一个几百毫秒的原因。录制后的步骤列表不只是一个记录它本身也是可编辑的。右键任意步骤可以插入新步骤、删除步、修改 Target。回放不是只能从头跑到尾从步骤列表右键选「Play From Here」可以从指定步骤开始执行。这在调试某个步骤失败时特别有用不必从首步重跑省掉前面的登录、导航时间。// 回放失败后最常用的调试方式把步骤切成两段跑 // 上面线以上的步骤 OK从失败步右键 → Play From Here // 如果直接通过说明问题出在前置状态的依赖上和失败步本身无关上面这段话是一个操作注释不是要执行的代码。它的意义在于逻辑隔离如果单独执行失败步能通过那就是前一个步骤造成了页面状态变化导致元素可见性、位置变了。这种情况常见于点击后出现 loading 遮罩、弹窗或列表重排后元素顺序变化。3.2 导出到 Selenium四种主流语言的选择与代码结构录制回放只是第一步Katalon Recorder 真正被频繁使用的原因是它能把步骤导出成多语言的 Selenium WebDriver 代码。在界面右上角点 Export 按钮会出现一个语言列表Java (JUnit/TestNG)、Python (unittest)、C# (NUnit)、JavaScript (WebDriverJS)、Ruby、Katalon Studio 格式、Robot Framework 格式等。我选导出语言时一般遵循一组决策逻辑团队现有技术栈是什么就导什么如果团队没有明确技术栈找 CI/CD 里跑得最顺的语言。Java 在覆盖率、依赖稳定性和并发执行上最强适合企业长期沉淀Python 脚本最轻适合个人快速验证功能和做小范围的监控JavaScript 则和 Node 技术栈天然接近适合直接嵌到已有的 Node 项目中。下面放一段 Python(unittest) 导出代码的核心结构加了中文注释说明每块职责import unittest from selenium import webdriver from selenium.webdriver.common.by import By class TestRecordedScript(unittest.TestCase): def setUp(self): self.driver webdriver.Chrome() # 这里会要求本机有 ChromeDriver self.driver.implicitly_wait(10) # 全局兜底等待不是录制里的超时 def test_recorded_case(self): driver self.driver driver.get(http://your-app.com/login) driver.find_element(By.ID, username).send_keys(demo) driver.find_element(By.ID, password).send_keys(demo123) driver.find_element(By.CSS_SELECTOR, button[typesubmit]).click() self.assertEqual( driver.find_element(By.TAG_NAME, h1).text, 欢迎回来 ) def tearDown(self): self.driver.quit() if __name__ __main__: unittest.main()注意这段代码里有两个重要差异一个是 setUp 里的implicitly_wait(10)这是 Selenium WebDriver 的全局等待策略指查找任何元素时最多等待 10 秒另一个是录制器里那个 Execution Timeout它只作用于录制器脚本回放时的单条命令。两者不是一回事。导出代码后不要再沿用录制器的等待模型要根据目标框架的要求设置合适的等待方式。一般建议是页面加载用 WebDriverWait expected_conditions而不是固定 sleep 或者全局隐式等待。导出后还要做一件事检查导出的find_element系列是否和你本地的 Selenium 版本兼容。Selenium 4 的早期版本把find_element_by_xpath废弃了统一用find_element(By.XPATH, …)方式。你在导出后如果看到 IDE 报错先看是否是这个原因不要急着改定位表达式。3.3 导出代码跑不起来driver 版本、路径与浏览器升级的三角关系导出代码本地运行常见的第一个坑是浏览器驱动版本不匹配。Chrome 升级后ChromeDriver 必须对应到相同主版本否则抛session not created异常。这一瞬间会让人怀疑是录制的脚本有问题实际上和脚本无关。解决办法去 ChromeDriver 下载页找到与你浏览器版本一致的 driver或者直接用 Selenium ManagerSelenium 4.6 以上自带自动发现并下载匹配版本无需手动管理。第二个坑是环境变量。Python 脚本直接运行时会去 PATH 里找 chromedriver本地没配置就报WebDriverException: Message: chromedriver executable needs to be in PATH。有两种解决一种把 driver 所在目录加进 PATH另一种是代码里显式声明 driver 路径from selenium.webdriver.chrome.service import Service service Service(/usr/local/bin/chromedriver) driver webdriver.Chrome(serviceservice)第三个坑是浏览器沙箱权限。在 Linux CI 容器里跑 Chrome 常遇到selenium.common.exceptions.WebDriverException: Message: unknown error: Chrome failed to start: exited abnormally原因是容器内没有特权Chrome 默认启动方式受限。常见做法是给 ChromeOptions 加--no-sandbox与--disable-dev-shm-usage。这个参数只在 CI 容器环境需要本地 Windows/macOS 通常不用。# 容器环境运行示例 options webdriver.ChromeOptions() options.add_argument(--headlessnew) # 无头模式 options.add_argument(--no-sandbox) # 容器内降权 options.add_argument(--disable-dev-shm-usage) # 容器共享内存过小导致崩溃这一步是在告诉读者导出脚本只是起点你还会面对浏览器环境衍生的问题。Katalon Recorder 导出的代码基本是模板化的能一次跑通说明环境干净跑不通十有八九是 driver 或沙箱问题跟录制逻辑无关。别急着改脚本先检查环境类是错误。4. 避坑清单Katalon Recorder 实践中的五次翻车与换路4.1 现象回放时点击无效但手工操作正常录制时点击某个 Tab 标签页插件记录的是click xpath//div/ul/li[3]。回放走到这步显示成功但页面没有任何响应后续步骤因找不到下一页元素而失败。原因这个 Tab 用了 CSS :hover 展开或 JS 监听 mouseenter 事件而录制时插件生成的 XPath 指向的是文字节点所在的li标签而非真正绑定了事件处理函数的子元素。回放虽然精确点击了坐标位置对应的元素但没触发绑定在其它元素上的事件。解决把 Target 从xpath//div/ul/li[3]改成cssli:nth-child(3) a让事件绑定元素本身成为点击目标。如果还不行改用clickAt命令并在 Value 里指定点击的坐标偏移比如1,5模拟点击到元素内部偏中心位置。4.2 现象回放在 iframe 内操作时定位失败页面上有内嵌 iframe 的富文本编辑器录制时明明能输入文字回放却在 type 步骤上报元素不可见。原因Katalon Recorder 的录制过程会把 iframe 内的元素记录成正常 DOM 路径但回放时 WebDriver 默认上下文是顶层 document不会自动切进 iframe。解决导出代码后手动加切换逻辑或者录制时手动插入selectFrame命令。Target 填 iframe 的 name 或 index。之后的步骤操作完再插入selectFrame relativetop回到主文档。# 处理 iframe 的标准写法Python 导出调整示例 driver.switch_to.frame(editor_iframe) driver.find_element(By.TAG_NAME, body).send_keys(预期文本) driver.switch_to.default_content() # 回到外层避免后续定位失效4.3 现象同一脚本这次跑过下次跑挂失败点还是随机步骤随机失败最常见的位置是列表页和弹窗出现后的那一步。原因录制时页面是瞬时状态回放时前端异步加载完成时间和录制时不同。没有等待机制的脚本会提前去点一个还没渲染出来的元素。解决不要依赖录制器默认等待导出代码后用WebDriverWait替换隐含等待。凡是录制器里对应click/type的步骤前面加一条显式等待等待条件是「目标元素可点击」而不是固定 sleep。4.4 现象导出 Java 代码跑不起来报错「Cannot find symbol」代码里出现findElement(By.xpath(...))本地 Maven 工程却提示这个方法是旧 API找不到对应 symbol。原因导出模板默认按某个 Selenium API 版本生成但本地依赖引入了 Selenium 4 之后的版本旧接口被移除或标记为 deprecated。解决把代码生成上可能需要的 API 对齐到项目依赖版本数据库层面可以全局替换findElement(By.XPATH, ...)的调用方式。如果不想改代码把 pom.xml 里的 Selenium 版本固定到 3.141.59 过渡版本。4.5 现象录制脚本换到另一台电脑回放全挂脚本文件拷到新机器打开回放所有步骤都报元素定位失败但页面打开正常。原因Katalon Recorder 是以屏幕分辨率和浏览器缩放比例来辅助计算元素位置的部分场景另一台电脑屏幕缩放Windows 缩放 150%不同导致浏览器窗口内布局偏移。而 Target 里的绝对 XPath 没有变化但页面响应式布局改变了元素渲染位置。解决录制环境固定浏览器缩放比例推荐 100% 窗口大小并且用例回放前用命令driver.manage().window().maximize()统一窗口尺寸。如果是绝对定位问题可以把 Target 都改成带业务语义的 CSS。5. 进阶用 Katalon Recorder 搭建可持续维护的脚本体系5.1 数据驱动一次录制多组数据跑通录制器本身没有数据循环能力但导出到 Java/Python 后模板代码天然支持参数化。把录制脚本里硬编码的用户名、密码、订单号替换成变量用循环读取 CSV 或 Excel 里的数据就完成了数据驱动的最小实现。导出到 Python 后可以这样扩展import csv from selenium import webdriver from selenium.webdriver.common.by import By with open(testdata.csv, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: driver webdriver.Chrome() driver.get(http://your-app.com/login) driver.find_element(By.NAME, username).send_keys(row[username]) driver.find_element(By.NAME, password).send_keys(row[password]) driver.find_element(By.TAG_NAME, button).click() # 每跑完一组数据关闭浏览器避免脏数据互相干扰 driver.quit()这样就不需要为每个用户造一个录制脚本维护成本降下来。陷阱是登录后的状态清理多组数据在同一个浏览器实例里跑会导致 session 串号频繁退出登录或更换用户信息慢建议每组数据独立起一个 driver。5.2 定时无人值守从手动回放到 CI 触发导出后的脚本可以挂到 Jenkins 或 GitLab CI 上跑。做法是把脚本放进仓库CI 里配置执行命令例如python -m unittest test_login.py再配合cron或 Webhook 触发。java 项目里常用 TestNG 导出的格式因为它的断言流程和报告产出更成熟。如果是 Python用 pytest pytest-html 插件能生成可读的 HTML 报告。这里有一个容易被忽略的细节无人值守跑 UI 脚本失败后的截图是定位问题的关键。建议在 tearDown 里加上截图与 driver 日志输出。from selenium.webdriver.common.by import By import datetime def take_screenshot_on_failure(driver): ts datetime.datetime.now().strftime(%Y%m%d_%H%M%S) driver.save_screenshot(f/tmp/failure_{ts}.png)截图文件名带时间戳保留现场。如果脚本夜间跑挂了第二天查报告先看截图比看一堆堆栈日志直观。5.3 验证你的脚本是否足够健壮减员测试与重复跑批判断脚本质量不能只看跑通一次。我常用的验证手法是两个第一把录制器生成的用例连续跑三遍如果三遍都过再去动别的第二故意把测试环境中网络限速或页面渲染变慢再跑一遍这时没做显式等待的脚本会比较快暴露问题。做完这两个验证再约管理评审落地计划。这条实践的背后逻辑是脚本录制工具的价值不在录制那一下而在「录完后的改动量」——改动越少说明录制质量越高。我自己的习惯是每周五下午固定检查本周新增录制的脚本逐个回放一遍录完就归档进仓库。Katalon Recorder 没有历史版本回滚能力你改错一步保存后想恢复只能靠自己的版本管理。所以我拿到任何录制脚本第一件事是把导出的代码提交到 Git之后改的每一版都留痕。没有版本管理的录制脚本改了定位表达式后想回头却回不去那才是最绝望的。希望这条思路能帮到你也欢迎拿这套流程去你项目里跑一次真实的试用。本文还有配套的精品资源点击获取