企业官网建设流程全解析

写自动化测试脚本写了快十年，我最常被问的问题之一就是：“有没有什么办法，能让我不用手写代码，先把脚本跑起来？”

有，而且不只一种。今天要聊的KatalonRecorder，就是其中一个相当顺手的选择。它是个浏览器插件，可以在Chrome和Firefox里直接录制你的操作步骤，生成可回放的自动化测试脚本。对于刚入门的测试新人，或者需要快速产出回归脚本的团队，这个工具能把“录制脚本”这件事的门槛降得很低。

本文我会从安装、录制、回放、调试、导出一整套流程讲透，也会把我在实际项目中踩过的坑一并整理出来。不管你是刚接触UI自动化的小白，还是已经用Selenium、JMeter做过脚本的老手，这篇教程都能给你一些可以直接用的东西。

1. KatalonRecorder是什么，能干什么

很多人第一次听到KatalonRecorder，会以为它是Katalon Studio的附属品，但实际上它更像是一个轻量级的“录制器”兼“脚本运行器”。它基于Selenium IDE的衍生思路，把浏览器操作记录下来，转换成一条条命令，然后按顺序回放。你不需要安装庞大的IDE，不需要配置复杂的工程结构，一个浏览器插件就够了。

它的典型使用场景有三个：

• 快速冒烟测试：新版本上线前，把核心路径录一遍，回放看看有没有报错。
• 回归测试脚本的起点：先录制，再导出成Katalon Studio或Selenium脚本，在完整框架里继续增强。
• 演示和验证：给开发或产品演示某个Bug复现步骤，录一遍比写文字描述直观得多。

我见过不少团队用它做“转身就走”的临时脚本，也见过有团队把它作为正式自动化框架的前置工具。无论哪种用法，它解决的核心问题都是一样的：把“手工操作”转换为“可重复执行的步骤”，而这个转换过程不需要你写一行代码。

和JMeter录制脚本的思路做对比，可能会更好理解。JMeter通过HTTP代理服务器抓取浏览器请求，生成的是协议层的脚本，关心的是每个请求的URL、参数、响应时间。而KatalonRecorder录制的是UI层的操作，关心的是你点了哪个按钮、输入了什么文本、页面产生了什么变化。一个偏性能测试，一个偏功能测试，两者本质不同，但“录制然后回放”这个思路是一脉相承的。

所以在学习KatalonRecorder的时候，如果你有JMeter的基础，很多概念是可以迁移的，比如断言、变量、等待条件，你都会觉得眼熟。

1.1 为什么不用手工点点点

很多人会问：我为什么要花时间录脚本？手工测一遍不就完了。

手工测试的问题在于“不可重复”。你今天点了十个步骤验证了一个流程，下周这个流程又改了一版，你要重新点十个步骤。如果这个流程要覆盖三个浏览器、两组测试数据，那就要点六次。人一旦重复做机械操作，就会疲劳，疲劳就会漏操作。录制脚本的价值不是“代替你测试”，而是“代替你重复”。

而且录制脚本这件事本身就在倒逼你把流程梳理清楚。你要录一个下单流程，就必须明确先点什么、后点什么、每一步的输入是什么、预期结果是什么。这个梳理过程，对你理解业务逻辑是有帮助的。

1.2 KatalonRecorder的定位与边界

当然，它也不是万能的。这里要先把丑话说在前面。KatalonRecorder适合处理流程清晰、界面相对稳定的场景。如果你的系统每天都在改前端结构，或者大量使用Canvas、SVG这类自定义渲染元素，录制脚本就会很痛苦。它也不适合用来做性能测试，那是JMeter的主场。

所以我的建议是：把它放在工具链里，和JMeter、Selenium等配合使用，各管一段。它擅长的是快速生成功能测试脚本，而不是包揽所有测试工作。

2. 环境准备与插件安装

KatalonRecorder的使用非常简单，准备工作只需要一个支持它的浏览器和一个插件的安装。

2.1 下载与安装

以Chrome为例，直接在Chrome网上应用店搜索Katalon Recorder，找到Katalon Studio出品的那个插件（注意认准蓝底白字的图标，别装错），点击“添加至Chrome”完成安装。Firefox用户则到Firefox Add-ons里搜索同名插件安装。

安装完成后，浏览器右上角会出现KatalonRecorder的图标。首次点击图标，会出现一个授权提示，授权内容大致是允许插件读取和修改当前页面数据，以及管理下载任务。这两项权限是录制和回放的基础，不用太担心安全性问题，本质和Selenium IDE一样。但我还是会建议在非生产环境、或者专门用来做测试的浏览器配置里使用它，不要在你的日常主力浏览器里长期开着录制权限。

2.2 界面布局

打开KatalonRecorder，你会看到一个简洁的主界面。它和Katalon Studio甚至JMeter都有几分相似，分几个区域：

• 左侧是测试用例列表（Test Cases），你的所有脚本都放在这里。
• 中间上方是命令编辑区（Commands），每一条录制下来的操作都以命令的形式展示。
• 中间下方是命令参数区，当你选中某条命令，可以在这里修改它的Target、Value等参数。
• 右侧是日志和参考区，回放时会输出日志。

整体布局和Selenium IDE非常接近，如果你用过Selenium IDE，几乎可以零成本上手。

2.3 录制前的浏览器设置

录制之前，我建议你先做两件事：

第一，把浏览器缩放比例设为100%。这个问题很多人会忽略。浏览器缩放会影响页面元素的位置和可见性，虽然录制的定位大多依赖DOM属性而不是坐标，但缩放异常的情况下，插件的元素高亮和点击模拟偶尔会出问题。

第二，准备一套干净的测试环境。所谓干净，是指数据库里没有干扰数据，没有弹窗、公告等干扰元素。比如录制一个登录脚本，如果页面上有上一次输入的账号密码自动填充，录制时会多出一些多余的键盘输入动作，回放时就会不稳定。

如果页面有强制更新的公告弹窗，这类元素会挡住后续的点击操作，录制脚本可能会把点击弹窗关闭按钮也录进去。一旦弹窗不再出现，脚本就会报错。所以录制前把弹窗处理掉，或者准备一个稳定版本的环境，是省心的重要前提。

3. 完整录制一个脚本：从创建到回放

下面我们进入正题，完整走一遍录制脚本的流程。我这里以一个“浏览器登录并新建一条待办事项”的流程为例，这个场景覆盖了文本输入、按钮点击、列表验证等常见操作，适合演示。

3.1 创建测试用例

打开KatalonRecorder插件界面，在左侧Test Cases区域点击右键，选择“New Test Case”，给它起个名字，比如“login_and_create_todo”。这个名字建议用英文加下划线，避免一些系统对中文命名兼容性不好。

创建好之后，你可以先不急着录制，先想清楚这个脚本的流程节点。这一步很重要，比打开录制按钮重要得多。你可以在备注里写下：打开首页、输入用户名、输入密码、点击登录、点击新建、输入标题、保存、验证列表出现该标题。这个清单就是后面录制时的操作大纲。

3.2 开始录制与操作

点击KatalonRecorder界面上方的红色圆点“Record”按钮，插件会打开一个新的浏览器标签页，从这一刻起，你在该标签页里的所有操作都会被记录下来。

在打开的页面里，我通常会先手动刷新一下，确保页面是从初始状态开始加载的。然后按照之前梳理的流程，执行登录、点击新建、填写表单、保存。每执行一步，你切回KatalonRecorder窗口，就能看到对应的命令已经自动生成。

录制过程中有一个经验：操作速度不要太快。每完成一步，稍微停顿一两秒再继续下一步。原因很简单，录制器捕捉的是浏览器事件流，如果点击和输入间隔太短，某些框架的防抖机制可能把中间状态合并掉，导致回放时无法复现当时的DOM状态。实测下来，步骤之间停顿1秒以上，脚本稳定性明显提升。

整个流程走完后，点击红色按钮旁边的“Stop”停止录制。此时你的“login_and_create_todo”用例下，应该已经有一串命令了，大概长这样：

• open: https://your-app.com
• click: id=username
• type: id=username, value=testuser
• click: id=password
• type: id=password, value=your_password
• click: xpath=//button[text()='登录']
• ...

3.3 脚本结构与命令详解

你可能已经注意到，录制器把“点击输入框”“输入文本”拆成了两步：click和type。这个设计是合理的，因为很多前端框架在click之后才会激活输入框的编辑状态，直接type不一定会命中。

每条命令最关键的是Target字段。它决定了脚本去页面上找哪个元素。录制器默认会优先选择id、name等稳定属性，找不到时才退而求其次用XPath。这个优先级策略你可以通过点击命令的Target下拉框手动调整，后面我会专门讲定位问题。

Value字段则是输入的内容，也可以是变量。比如登录脚本的密码，如果每个环境密码不同，你可以把它替换成变量。

录制完成后，我建议你逐条过一遍命令列表，重点确认两点：有没有因为误操作多录了不相干的步骤；有没有页面跳转导致的中间状态步骤，这类步骤在回放时往往不稳定，可以考虑删掉。

3.4 回放你的第一个脚本

脚本录好了，是不是能跑，回放一下就知道。点击KatalonRecorder界面上方的绿色三角形“Play”按钮，插件会自动在新的浏览器页签里按顺序执行所有命令。

第一次回放大概率会出问题，这是正常现象，不要慌。最常见的状况是元素找不到、等待超时、或者页面跳转太快导致下一步找不到目标。这些问题的排查方法我会在第5节专门讲，这里你要做的是先看懂右侧日志区输出的信息。

日志区会显示每一步命令的执行状态：绿色通过、红色失败、黄色警告。点击某条日志，可以跳转到对应的命令。如果你看到一条命令执行花了很长时间，说明等待条件可能有问题，可以考虑在前后加上等待命令。

回放成功的标志是浏览器自动完成了整个流程，并且最终页面状态和手工操作的结果一致。如果你的脚本是登录后新建待办，那么回放结束后，待办列表里应该出现那条新数据。

我已经被这个问题坑过很多次了。所以我的习惯是，回放脚本之前，先把测试环境的数据清一遍，至少保证上一次运行产生的数据不会影响本次断言。

4. 回放、调试与脚本优化

录制的脚本能跑通只是第一步。真实项目中，你录制的脚本大概率会遇到各种不稳定因素，这时候就需要手动调试和优化了。这一节讲的就是怎么把“能跑的脚本”变成“稳定能跑的脚本”。

4.1 添加等待命令

录制时，你的操作速度是人手的速度，人与人之间还有思考时间。但回放时，脚本的执行速度是机器速度，一条命令执行完立刻执行下一条。中间一旦出现页面跳转或异步请求，下一条命令就会扑空。

解决这个问题有两种方式：

第一种是设置全局等待时间。在KatalonRecorder的选项设置里，可以找到“Timeout”相关配置，把默认等待时间设长一点，比如5000毫秒。这种方式简单粗暴，但缺点是每条命令都会等这么久，脚本效率很低。

第二种是手动添加等待命令。在需要等待的步骤之前，插入一条waitForElementPresent命令，让脚本等待某个元素出现后再继续。比如登录后，等待“新建按钮”出现再点击。这种方式更精准，也是我推荐的做法。

插入方法很简单，在命令列表里选中某条命令，右键选择“Insert New Command”，然后在下拉框里选择需要的命令类型。

4.2 添加断言命令

录制脚本自己跑完不报错，不代表结果是正确的。比如登录流程，脚本执行了，但如果登录失败，页面停在登录页，脚本一样可以走完所有命令（只是可能找不到后面的元素而报错）。为了让脚本有价值，必须加入断言。

KatalonRecorder提供了几种断言命令，最常用的是assertTextPresent和assertElementPresent。

• assertTextPresent：断言页面上出现了指定文本。比如登录成功后的欢迎语，或者新建待办成功后列表里的文案。
• assertElementPresent：断言某个元素存在。比如“退出登录”按钮是否渲染出来。

在回放的时候，如果断言失败，脚本会立即停止并标红。这一步是脚本从“录制玩具”走向“可用测试资产”的分水岭。

4.3 参数化与变量使用

录制的脚本目前写死了一套输入。但实际项目中，你很可能要用几组不同的数据来测试同一个流程。这时候变量就派上用场了。

KatalonRecorder支持在Value字段里使用${变量名}的格式。在前面的某个步骤中，可以通过storeText、store等命令把值存到变量里，后续步骤再引用。

举个例子：你先打开一个“用户详情页”，从页面上抓取用户名存在变量username里，然后用这个变量去执行搜索。这样脚本就具备了一定的数据驱动能力，不再是一个“一次性脚本”。

如果你后续把脚本导出到Katalon Studio，这些变量还可以和外部数据源（比如Excel或数据库）对接，变成真正的数据驱动测试脚本。这一步的扩展空间非常大，也是KatalonRecorder最有价值的进阶用法。

4.4 脚本优化的几个方向

录制脚本像不像炒菜？第一次是凭感觉把菜做熟，好吃不好吃看运气；优化之后才是真正掌握火候。

我在优化脚本时主要看三个方向：

第一个方向是“定位优先级”。录制生成的定位方式不一定是最优的。比如它可能录了一个很长很长的绝对路径XPath，这种定位在页面结构调整时非常容易碎。我会手动替换成id、name，或者语义化的相对XPath。这个优化能让脚本的生命周期延长不少。

第二个方向是“去掉无用命令”。录制过程中经常会产生一些对流程没有意义的中间命令，比如点击一下空白处、滚动一下页面、输入框聚焦等。这些命令不仅拖慢脚本速度，还是潜在的不稳定因素。我会逐条审视，能删就删。

第三个方向是“分组与注释”。KatalonRecorder允许在脚本中添加注释命令，用来标记“这里是登录步骤”“这里是新增待办步骤”。脚本一长，注释的价值就体现出来了。特别是你要把脚本交接给同事的时候，注释比任何口头说明都实在。

5. 脚本导出与后续应用

录制、调试、优化都做完了，你的脚本已经能稳定回放了。下一步就是考虑怎么把它融入到更大的测试体系里。KatalonRecorder支持多种导出格式，这是它相比很多“只能自嗨”的录制工具最大的优势之一。

5.1 导出格式一览

在命令区域空白处右键，选择“Export”，你会看到一系列导出选项：

• Katalon Studio (*.groovy)
• Selenium JUnit 4 (*.java)
• Selenium TestNG (*.java)
• Selenium Python (*.py)
• Selenium WebDriver C# (*.cs)
• Groovy (*.groovy)
• 甚至还有Jason格式的导出

这意味着你录制的脚本可以无缝接入已有的测试框架。我们团队就经常这么干：先用KatalonRecorder快速录制一个复杂流程的脚本，导出成Python版本，然后在自己的Pytest框架里继续扩展数据驱动、截图报告等功能。录制器相当于一个“脚本生成器”，帮我们省掉了从零开始写定位和操作的时间。

5.2 导出到Katalon Studio

如果你用的是Katalon全家桶，那更方便。导出的Groovy脚本可以直接放到Katalon Studio的Test Case目录下进行二次开发。Katalon Studio自带的Keywords、Test Suite管理、报告系统，都比你裸用浏览器插件要完整得多。

要注意的是，导出后的脚本通常还需要少量调整。因为KatalonRecorder生成的是通用代码，而Katalon Studio的脚本运行环境有自己的对象仓库和关键字体系。最常见的调整是把硬编码的元素定位方式替换成对象仓库中的对象，或者替换成Katalon的内置关键字。

5.3 录制工具的横向对比

既然聊到了录制，顺便把几款主流工具摆在一起说说。

Selenium IDE：和KatalonRecorder很相似，也是浏览器插件，支持录制和回放。优点是社区认知度高，Selenium的原生粉丝自带熟悉度。缺点是后续导出和框架整合上略显单薄，如果你只是需要快速录制一个脚本它足够用，但想在完整框架下继续做复杂控制，就会觉得限制多。

JMeter：偏协议层，录制的是HTTP请求。它的价值在于性能测试，能模拟大量并发。但如果你关注的是页面元素和交互逻辑，JMeter给不了你那个维度的反馈。你可以在KatalonRecorder里录一条功能路径脚本，再到JMeter里配一组并发请求，两者验证的是完全不同的象限。

KatalonRecorder：我认为它站在一个折中位置。它比Selenium IDE多了更多的导出选择，比JMeter更贴近UI操作。适合作为团队自动化测试“从0到1”的切入点，也适合作为已有框架的脚本预生成工具。

5.4 和JMeter录制思路的联动

有JMeter基础的朋友可能会有个疑问：我在KatalonRecorder里录的脚本，能不能直接变成JMeter的脚本？答案是不能，因为两者录制的东西本质不同，一个是UI操作，一个是HTTP请求。

但它们的思路可以互相借鉴。我在实际项目中经常两条线并行：用JMeter录制脚本验证接口层的核心链路并发能力，用KatalonRecorder录制脚本验证UI层的关键流程可用性。接口层和UI层的测试结果互相印证，可以更快定位是前端问题还是后端问题。比如JMeter跑接口全通，但KatalonRecorder跑UI用例失败，那大概率问题出在页面渲染或前端逻辑，而不是服务端接口。

顺便说一句，如果你之前只接触过JMeter录制HTTPS脚本，可能会对证书、代理配置这些事有印象。KatalonRecorder没有这些烦恼，它直接跑在浏览器里，不需要代理，也不需要证书配置。这也是它的一个省心之处。

6. 常见问题与排查技巧实录

这一节是纯拿经验说话。下面这些问题，都是我和同事在实际项目里遇到过、花时间踩平过的坑，整理成一个速查表给你。

6.1 回放时“元素找不到”怎么办

元素找不到，是录制脚本回放时最高频的错误。原因可以归为四类：页面还没加载完、定位表达式失效、元素被遮挡、元素在iframe或新窗口里。

排查思路我按顺序走：

• 先看日志里报错的是哪条命令，然后手动打开页面确认这个元素当前是否存在。
• 如果存在，很可能只是时机问题。在报错命令前加waitForElementPresent，一般就好了。
• 如果不存在，可能是定位失效。打开浏览器开发者工具，重新复制一个正确的定位表达式，替换Target字段。
• 若元素存在但被遮挡，比如被弹窗盖住，需要在脚本里先处理弹窗，或者选择强制点击命令（但这是下策，我一般不推荐）。

iframe真是录制工具的老大难。录制时可以正常定位，回放时元素就是找不到，就是因为目标元素在iframe里，而脚本没有先切换进iframe。KatalonRecorder在切换上下文上做得不算直观，遇到这种情况，需要在脚本中增加selectFrame命令。我建议你在录制时如果发现页面结构里有明显的iframe标签，提前做好记录，回放失败时优先检查这一项。

6.2 录制命令数量明显多于实际操作

比如你只点了三次按钮，结果录下来十八条命令。这种情况通常是因为页面里的某些事件触发了元素的高亮、聚焦、点击动画。部分框架对每个交互会派发多个事件，录制器把这些事件都记录下来了。

处理方式很简单：删掉明显多余的命令。我的标准是：删除不会影响后续步骤的元素高亮命令、聚焦命令、CSS样式变更命令。保留涉及输入、点击、跳转、表单提交的关键命令。

6.3 页面打开后脚本报“连接失败”或“无法打开”类错误

这一类一般不是脚本逻辑问题，而是网络环境或页面本身加载问题。录制和回放时的网络环境最好一致，尤其是有登录态的站点。回放如果在一个新的浏览器上下文里进行，原来的登录态可能不存在，需要脚本先完成登录，再进入业务页面。

另外，如果你的目标页面是HTTPS协议且证书不受信任，回放时浏览器会拦截。这和JMeter录制HTTPS脚本时遇到的证书问题思路类似，你需要提前在浏览器里信任该证书，或者使用一个已经配置好证书的浏览器配置文件。

6.4 常见问题速查表

6.5 一个容易忽略的细节：数据状态

脚本跑通了，也不是说就一劳永逸了。很多脚本的回放结果取决于测试环境的数据状态。

比如你录制的是删除流程，脚本第一次跑把那条数据删了，第二次跑就没有数据可删了，脚本就会失败。又比如你录制的是新建操作，每次跑都会新增一条数据，时间长了测试环境里堆满垃圾数据，也会影响后续测试。

这个问题我在前面的章节提过，但因为它太重要，值得再强调一次。一个稳定的自动化测试脚本，必须做到对数据有准备、有管控。你可以写一段前置脚本来清理数据，也可以设计脚本时让每一步不依赖特定数据的存在。

我自己做UI自动化测试的时候，一直遵循一条原则：数据准备和用例执行分离。录制脚本时就把测试数据的准备步骤考虑进去，要么在脚本开头执行，要么通过调用接口干净地准备。这样脚本的复用性会高很多。

写在最后的几点体会

KatalonRecorder这个工具，说复杂不复杂，说简单也不简单。它好上手，是因为录制功能把繁琐的定位和编码门槛给抹掉了；它不简单，是因为一个真正稳定、可维护的自动化脚本，依然需要你对定位策略、等待条件、数据管理这些东西有深入理解。

我个人的建议是：不要把它当成一个“录完就跑”的一次性工具，而是把它当成你自动化测试工具箱里的一个高效起点。先用它把流程摸清、把脚本录通、把业务规则验证明白，然后再根据你的实际框架需要，导出、扩展、强化。

最后再分享一个小技巧：录制之前，先在纸上把流程画一遍，搞清楚每一步的输入、操作和预期结果。这个准备工作花五分钟，却能帮你减少至少半小时的调试时间。很多看着复杂的问题，其实在动手前就已经能避免大半了。