
简介Katalon Recorder-脚本录制工具.zip 面向需要开展 Web 自动化测试的开发者与测试工程师尤其适合刚接触 Selenium 脚本录制、希望降低手工测试成本的人群。资源包共 4 个文件以 2 个 crx 浏览器扩展和 2 个 html 说明文档为主压缩包约 3.95MB其中 crx 用于在 Chrome 中安装录制插件html 则承载安装与使用指引便于快速上手。目前已有 1515 人学习下载具备一定参考热度。借助该工具读者可在浏览器中直接录制操作并生成可执行的 Selenium WebDriver 脚本再通过内置编辑器补充断言、循环等逻辑覆盖从简单回放到较复杂测试场景的需求配套说明文档也能帮助理解安装流程与基本用法适合作为自动化测试入门与日常脚本沉淀的实用工具包。1. 从手工点点点到脚本回放Katalon Recorder 到底省了哪段力气如果你做过 Web 自动化大概率经历过这个阶段打开浏览器F12 盯着 DOM 树一行行手写选择器跑一遍挂一遍改到怀疑人生。Katalon Recorder 这个工具解决的就是最枯燥的那一段——把你在页面上的点击、输入、跳转直接录成可回放的脚本导出成 WebDriver 能吃的格式。它本质上是一个浏览器侧的录制器加轻量回放引擎适合两类人一是刚接触自动化、想先看到「脚本长什么样」的新手二是需要快速把一批回归用例从手工转成脚本的老手。这个 zip 包拿到手核心价值不是「多了一个工具」而是把用例编写的前 70% 机械劳动压缩成录制动作你只需要在导出的脚本上做参数化和断言加固。下面按「装、录、导、改、排」这条线拆开讲中间会给出可直接抄的配置和代码。2. 录制原理与上手从安装到第一条可回放脚本2.1 录制器的工作模型它记的不是坐标是选择器很多人第一次用录制工具会误以为它记录的是鼠标坐标其实不是。Katalon Recorder 在录制时监听的是 DOM 事件每捕获一个动作它会同步计算该元素的定位策略——优先 id其次 name再退到 CSS 或 XPath。这个顺序很关键因为它决定了你导出的脚本稳不稳。如果页面元素有稳定的 id录出来的命令就是click | idsubmit-btn如果只有一层套一层的 div它可能给你生成一条又长又脆的 XPath页面结构一改就断。理解这一点之后录制时的操作习惯就要跟着变点击目标尽量选带语义属性的元素比如按钮上的># 1. 解压资源包到本地目录 unzip Katalon\ Recorder-脚本录制工具.zip -d katalon-recorder # 2. 打开浏览器扩展管理页 # Chrome/Edge 地址栏输入chrome://extensions 或 edge://extensions # 3. 打开右上角「开发者模式」点击「加载已解压的扩展程序」 # 选择上一步解压出来的目录含 manifest.json 的那一层加载成功后工具栏会出现录制按钮。点开面板新建一个测试套件Test Suite然后点录制。接下来在页面上完成一次登录输入用户名、输入密码、点登录、等首页加载出来。每完成一步面板里就会多出一行命令。录完点停止你会看到类似这样的命令序列open | https://example.com/login | type | idusername | testuser type | idpassword | Passw0rd! click | idlogin-btn | assertText | css.welcome-msg | 欢迎回来这里有个细节type命令的 value 字段是明文密码。录制阶段无所谓但导出脚本前一定要把这类敏感值替换成变量或环境变量否则脚本进了仓库就是一次泄露。我一般录完第一件事就是把所有密码、token 类的 value 改成${PASSWORD}这种占位符。2.3 回放与调试先看它卡在哪一条录完不要急着导出先在录制器里回放一遍。点 Play观察命令逐条变绿还是变红。变红的那条就是问题点常见的是等待不够——页面还没渲染完回放引擎就去找元素了。这时候在两个动作之间插一条pauseclick | idlogin-btn | pause | 2000 | assertText | css.welcome-msg | 欢迎回来pause的 target 是毫秒数。2000 表示强制等 2 秒。这是最粗暴但最有效的调试手段先确认「加了等待就能过」再去优化成显式等待。如果加了 pause 还是红那大概率是定位器本身失效了点开那条命令看 target 字段回到页面上用 F12 验证这个选择器还能不能选中元素。录制器的调试逻辑就这么朴素定位对不对、等待够不够两个问题占九成失败。3. 导出与二次开发把录制脚本变成能进 CI 的代码3.1 导出格式怎么选HTML、JSON 还是 WebDriver 代码录制器面板里点 Export通常能看到几种格式。选哪个取决于你的下游怎么用导出格式适用场景注意点HTML继续在录制器里回放、小团队共享不可版本化 diff不适合进 GitJSON程序化处理、自定义转换脚本结构清晰适合做二次解析WebDriver 代码Java/Python 等接入 Selenium 测试框架、进 CI需要补断言和等待不能直接跑如果你只是自己用HTML 够了。但只要涉及团队协作和持续集成直接导 WebDriver 代码。导出的 Python 版本大概长这样# 由录制脚本导出的 Selenium 代码节选需二次加工 from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC driver webdriver.Chrome() driver.get(https://example.com/login) # 录制生成的原始定位id 稳定时可直接用 driver.find_element(By.ID, username).send_keys(testuser) driver.find_element(By.ID, password).send_keys(Passw0rd!) driver.find_element(By.ID, login-btn).click() # 录制器不会自动生成显式等待这行要自己补 WebDriverWait(driver, 10).until( EC.text_to_be_present_in_element((By.CSS_SELECTOR, .welcome-msg), 欢迎回来) ) driver.quit()逻辑说明导出的代码保留了录制时的定位策略和操作顺序但它是「线性直译」没有等待、没有异常处理、没有数据驱动。参数说明上By.ID对应录制时的idBy.CSS_SELECTOR对应cssBy.XPATH对应xpath一一对应。你要做的是把send_keys里的硬编码值抽成变量把find_element换成带等待的封装。3.2 用 JSON 导出做批量转换一个可复用的解析脚本当你有几十条录制脚本要批量转成统一格式时一条条手改不现实。导成 JSON 后用脚本处理更划算。JSON 结构里每个测试用例是一个命令数组每条命令有command、target、value三个键。下面这个脚本把 JSON 里的type命令值替换成环境变量占位符import json import re # 读取录制器导出的 JSON with open(recorded_suite.json, r, encodingutf-8) as f: suite json.load(f) # 需要脱敏的字段关键词 SENSITIVE_KEYS [password, token, secret] def mask_value(command): 把敏感 type 命令的 value 替换成占位符 target command.get(target, ).lower() if command.get(command) type: for key in SENSITIVE_KEYS: if key in target: command[value] ${ key.upper() } return command # 遍历所有用例的所有命令 for case in suite.get(tests, []): case[commands] [mask_value(c) for c in case.get(commands, [])] with open(recorded_suite_masked.json, w, encodingutf-8) as f: json.dump(suite, f, ensure_asciiFalse, indent2) print(脱敏完成输出 recorded_suite_masked.json)逻辑说明脚本遍历 JSON 里每个测试用例的命令列表命中敏感关键词的type命令把 value 改成${PASSWORD}这类占位符。参数上SENSITIVE_KEYS按你项目实际字段增删ensure_asciiFalse保证中文断言不被转义成 unicode。跑完之后再写一个转换器把 JSON 映射成 pytest 或 unittest 的用例文件就能批量进 CI 了。这一步是录制工具真正产生规模价值的地方——录一次转一批。3.3 定位器加固把脆弱的 XPath 换成稳定选择器录制器生成的 XPath 经常是这种形态//div[idapp]/div[2]/div[3]/button。这种路径依赖层级前端一改布局就断。加固的思路是优先用属性定位。常见做法是推动前端在关键元素上加># 替换前层级 XPath脆弱 driver.find_element(By.XPATH, //div[idapp]/div[2]/div[3]/button).click() # 替换后语义属性定位稳定 driver.find_element(By.CSS_SELECTOR, [data-testidsubmit-order]).click()如果推不动前端加属性退而求其次用文本内容定位按钮//button[normalize-space(text())提交订单]。normalize-space去掉首尾空白避免因为空格差异匹配失败。再不行才用层级 XPath并且尽量锚定最近的稳定父节点而不是从根节点一路写下来。定位器加固是录制脚本能不能长期跑下去的分水岭录得快不代表跑得久。4. 避坑与排查录制回放里最容易翻车的五件事4.1 现象回放时元素明明在页面上却报找不到原因录制器默认的隐式等待时间偏短或者页面用了异步渲染元素在 DOM 里但还没可见。解决在失败命令前插pause确认是等待问题后导出代码里换成显式等待WebDriverWait配合visibility_of_element_located而不是无脑加固定 sleep。固定 sleep 会让整个套件越跑越慢显式等待只在需要时等。4.2 现象录制时点的是 A 按钮回放却点到了 B原因定位器命中了多个元素回放引擎取了第一个而页面顺序变了。解决检查 target 选择器是否唯一用 F12 的document.querySelectorAll数一下匹配数量。如果大于 1改用更具体的属性组合比如cssform#login button[typesubmit]。录制器不会帮你判断唯一性这个坑只能自己堵。4.3 现象脚本在本地跑得好好的进了 CI 就超时原因CI 环境没有图形界面或者窗口尺寸和本地不同导致元素不在可视区域。解决CI 里用 headless 模式启动并显式设置窗口大小driver.set_window_size(1920, 1080)。另外 CI 机器性能通常弱于本地超时阈值要适当放大别用本地调出来的 3 秒去卡 CI。4.4 现象中文断言在导出后变成乱码原因导出时编码没指定或者 JSON 序列化时用了默认的 ascii 转义。解决导出和读取都显式指定encodingutf-8JSON 写入加ensure_asciiFalse。如果已经乱码用json.load读回来重新写一遍就能恢复前提是原始字节没丢。4.5 现象录制器面板里命令顺序和实际操作对不上原因某些前端框架的事件是异步触发的录制器捕获顺序和视觉顺序有偏差。解决录完后手动调整命令顺序把open、wait这类前置命令提到正确位置。别迷信录制顺序它只是参考逻辑顺序得你自己理。我一般录完会通读一遍命令列表把明显错位的拖正再回放。5. 进阶技巧用变量和测试套件把录制脚本撑到生产可用录制器本身支持简单的变量机制在面板里可以定义${username}这类变量命令的 value 字段直接引用。这一步做完同一套脚本就能跑多组数据。具体做法是在测试套件级别定义变量表每条用例引用同一组变量名切换环境时只改编变量表不动脚本。导出成代码后对应的是把变量抽成 pytest 的parametrize或者读取外部 YAMLimport pytest import yaml # 从外部文件读测试数据实现数据驱动 with open(test_data.yaml, r, encodingutf-8) as f: cases yaml.safe_load(f)[login_cases] pytest.mark.parametrize(case, cases) def test_login(driver, case): driver.get(case[url]) driver.find_element(By.ID, username).send_keys(case[user]) driver.find_element(By.ID, password).send_keys(case[pwd]) driver.find_element(By.ID, login-btn).click() # 断言按用例预期结果走 assert case[expect] in driver.page_source参数说明cases是从 YAML 读出来的用例列表每条含 url、user、pwd、expect 四个字段。parametrize让 pytest 为每条数据生成一个独立测试失败时能精确定位是哪组数据挂了。这套结构配合录制器导出的定位器基本就是「录制打底、代码加固、数据驱动」的完整链路。还有一个容易被忽略的点录制脚本的维护成本会随用例数量线性上升所以别什么都录。稳定的核心流程录成脚本一次性的探索性操作就手工做。我自己的习惯是每录完一批脚本先跑三遍三遍都稳的才留下偶尔抽风的直接删掉重录——修一条脆弱脚本的时间往往够录三条新的。从那以后我每次导出脚本前都强制走一遍「脱敏、换定位、加显式等待」这三步少一步后面都要还债。希望帮到你。本文还有配套的精品资源点击获取