Katalon Studio 7.5.5 Windows安装配置与自动化测试环境搭建避坑指南

简介：Katalon Studio 是一款面向 Web 自动化测试的集成工具，基于 Selenium 与 Appium 框架构建，内置数百个预定义关键字，适合希望跳过环境搭建、快速上手自动化测试的开发者与测试人员。相比用 Python 加 Selenium 自行搭建测试环境，它开箱即用，支持 spy 与 record 方式捕获页面元素并生成脚本，也可用 Java 和 Apache Groovy 自行编写维护测试逻辑，并能从 CSV、Excel、数据库等数据源读取数据填充测试变量。资源包为 Windows 64 位 7.5.5 版本，共约 2000 个文件，以 918 个 html、587 个 js、441 个 jar 及 png、svg、css、dll、exe 等为主，涵盖界面资源、依赖库与运行组件，压缩包约 374.23MB。目前已有 1322 人学习下载，适合想系统掌握 Katalon 录制回放、元素定位与数据驱动测试的读者参考使用。

1. 从一次自动化测试环境翻车说起：Katalon Studio 7.5.5 到底该怎么装

上周帮一个测试团队排查 CI 流水线跑不起来的问题，折腾半天发现根因不是脚本写错了，而是 Katalon Studio 的版本和本机 JDK 对不上——他们装的是 7.5.5，机器上却挂着 JDK 17，启动直接白屏。这种坑我踩过不止一次。Katalon Studio 在 Windows 上的安装看着简单，解压、双击、等它自己初始化就完事，但真正决定你能不能跑通第一个 Test Case 的，是 JDK 版本、工作区路径、浏览器驱动这三件事有没有提前对齐。这篇笔记就按我自己的装机顺序，把 Katalon Studio 7.5.5 Windows 64 位版的完整落地过程拆开写一遍，从环境清单到验证跑通，中间该避的坑一个不落。如果你正准备在 Windows 上搭一套能稳定跑 Web UI 自动化的 Katalon 环境，照着走就行。

2. 装之前先把环境对齐：Katalon Studio 7.5.5 的版本与依赖清单

2.1 为什么 7.5.5 这个版本值得单独拎出来说

Katalon Studio 的版本迭代节奏不算慢，7.x 系列里 7.5.5 属于比较稳的一个节点。它内置的 Selenium 版本和 Groovy 引擎搭配得比较成熟，对 Chrome、Firefox、Edge 三大浏览器的驱动管理逻辑也基本定型了。我一般会建议团队在 Windows 上做自动化测试时，优先锁定一个 7.x 的稳定版本，而不是追最新版——新版本有时候会改内置驱动的下载策略，反而容易在离线环境里卡住。

7.5.5 这个包是 Windows 64 位的独立压缩包，解压即用，不需要走安装向导。这一点对运维来说其实是好事：没有注册表写入，没有系统级服务，迁移的时候整个目录拷走就能换机器。但“解压即用”不等于“解压就能跑”，它对运行环境有明确要求，下面这张表是我整理的最低配置和推荐配置对照。

这里最容易被忽略的是 JDK。Katalon Studio 7.5.5 官方推荐的是 JDK 8，你装 JDK 11 或 17 不是一定不行，但启动阶段就可能报Unsupported class file major version之类的错。我自己的习惯是：如果这台机器只用来跑 Katalon，就单独装一个 JDK 8，通过JAVA_HOME指向它，不去动系统默认的 JDK。

2.2 下载和解压：路径里别带中文和空格

拿到Katalon_Studio_Windows_64-7.5.5.zip之后，第一步是选解压路径。这一步看着无所谓，实际上后面很多玄学问题都跟路径有关。我一般会解压到类似D:\Tools\Katalon_Studio_7.5.5这样的纯英文、无空格路径下。原因有两个：一是 Katalon 内部有些脚本拼接路径时对空格处理不够健壮，二是工作区如果放在中文目录下，生成的报告文件名偶尔会乱码。

解压完成后，目录结构大致是这样的：

Katalon_Studio_7.5.5/ ├── Katalon Studio.exe # 主启动程序 ├── configuration/ # 配置文件目录 ├── features/ # 插件和功能模块 ├── plugins/ # 内置插件 ├── jre/ # 可选，部分版本自带 └── readme.txt

如果你下载的包里没有自带jre目录，那就必须依赖系统 JDK。判断方法很简单：双击Katalon Studio.exe，如果弹窗提示找不到 Java 或者直接闪退，就是 JDK 没配好。这时候别急着重装，先往下看环境变量的配置。

2.3 配置 JAVA_HOME 和 PATH：两个变量决定能不能启动

Katalon Studio 启动时会先读系统环境变量里的JAVA_HOME，找不到才会去 PATH 里翻java。所以最稳妥的做法是显式设置JAVA_HOME，指向 JDK 8 的安装根目录。

# 假设 JDK 8 装在 D:\Java\jdk1.8.0_301 # 在系统环境变量里新增： JAVA_HOME = D:\Java\jdk1.8.0_301 # 然后在 Path 里追加： %JAVA_HOME%\bin

设置完之后，开一个新的 cmd 窗口验证：

java -version # 期望输出类似： # java version "1.8.0_301" # Java(TM) SE Runtime Environment (build 1.8.0_301-b09)

如果java -version显示的版本不是 1.8，说明 PATH 里还有别的 JDK 排在前面。这时候要么调整 PATH 顺序，要么直接在 Katalon 的配置文件里指定 JDK 路径。后者更干净，适合机器上同时有多个 JDK 的情况。

提示：改完环境变量一定要新开命令行窗口验证，旧窗口读的还是旧变量，这个坑我见过太多次。

3. 首次启动与工作区配置：Katalon Studio 7.5.5 初始化实操

3.1 第一次双击之后会发生什么

环境变量配好之后，双击Katalon Studio.exe，正常情况会先弹出一个启动画面，然后进入工作区选择界面。Katalon 的工作区（Workspace）概念类似 Eclipse 的 workspace，用来存放你的项目、测试用例、对象库和报告。默认路径在C:\Users\你的用户名\Katalon Studio下，我一般会改成 D 盘或者项目盘下的独立目录，避免 C 盘被测试报告撑满。

工作区路径选定后，Katalon 会开始初始化插件和内置组件。这个过程第一次会比较慢，因为它在解压和注册内置的 Groovy 库、Selenium 依赖等。如果卡在某个进度条超过五分钟不动，大概率是 JDK 版本不对或者网络在尝试拉取在线组件。离线环境下可以在启动参数里加-noSplash和跳过在线检查的选项，但 7.5.5 的离线模式需要提前把插件包放好，这个后面排错章节再展开。

3.2 激活与离线模式的选择

Katalon Studio 7.5.5 启动后会要求登录账号激活。如果你所在的环境不能直连外网，可以选择离线激活方式，或者使用 Katalon 提供的免费版离线授权。这里要注意的是，7.5.5 的免费版功能已经覆盖了大部分 Web UI 自动化场景，包括录制、回放、对象库管理、测试套件执行，对中小团队来说够用了。

我一般会建议在首次启动时就把网络代理相关的配置检查一遍。Katalon 在configuration/目录下有个proxy.properties文件，如果公司网络需要走代理才能访问外网，就在这里配置。配置格式是标准的 Java properties：

# configuration/proxy.properties proxy.enabled=true proxy.server=your-proxy-host proxy.port=8080 proxy.username= proxy.password=

如果不需要代理，保持proxy.enabled=false即可。这个文件改完之后需要重启 Katalon 才生效。

3.3 创建第一个测试项目并验证环境

工作区初始化完成后，选择File -> New -> Project，给项目起个名字，比如DemoWebTest。项目类型选Web Testing，引擎选默认的 Groovy。创建完成后，Katalon 会自动生成一套目录结构：

DemoWebTest/ ├── Test Cases/ # 测试用例 ├── Object Repository/ # 页面元素对象库 ├── Test Suites/ # 测试套件 ├── Profiles/ # 环境配置 ├── Reports/ # 执行报告 └── Include/ # 公共脚本和关键字

到这一步，环境基本就绪了。但“能创建项目”不等于“能跑通用例”，真正的验证要等你打开一个浏览器、执行一条最简单的脚本。我一般会先建一个空用例，只做一件事：打开浏览器，访问一个页面，然后关闭。如果这一步能跑通，说明 JDK、浏览器驱动、工作区路径都没问题。

// Test Cases/SmokeTest import static com.kms.katalon.core.testobject.ObjectRepository.findTestObject import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI WebUI.openBrowser('') WebUI.navigateToUrl('https://example.com') WebUI.delay(2) WebUI.closeBrowser()

这段脚本的逻辑很直白：openBrowser启动默认浏览器，navigateToUrl打开目标页面，delay等两秒让页面加载完，最后closeBrowser收尾。如果执行时浏览器没起来，或者报No such driver之类的错，问题基本出在浏览器驱动上，下一章专门讲。

4. 浏览器驱动与执行配置：让 Katalon 真正跑起来

4.1 Chrome 驱动的自动匹配机制

Katalon Studio 7.5.5 内置了 WebDriverManager 的逻辑，理论上你不需要手动下载 chromedriver，它会根据本机 Chrome 版本自动匹配对应的驱动。但这个“自动”有两个前提：一是能访问驱动下载源，二是 Chrome 安装路径是标准的。如果公司网络限制了驱动下载，或者 Chrome 装在非默认路径下，自动匹配就会失败。

我一般会做两手准备：先让 Katalon 自动匹配一次，如果报错，就手动指定驱动路径。手动指定的方式是在项目设置里找到Execution -> Default -> WebUI -> Chrome，把Driver一项从Auto改成Custom，然后指向你本地已经下载好的 chromedriver.exe。

# 手动下载 chromedriver 后放到项目目录下 DemoWebTest/ └── Drivers/ └── chromedriver.exe # 在项目设置里指定路径： # Project -> Settings -> Execution -> Default -> WebUI -> Chrome # Driver: Custom # Driver Path: ${projectDir}/Drivers/chromedriver.exe

这里有个版本匹配的细节：chromedriver 的大版本号必须和本机 Chrome 的大版本号一致。比如 Chrome 是 120.x，chromedriver 也得是 120.x。版本对不上时，浏览器能启动但会在连接阶段超时，报session not created错误。

4.2 Firefox 和 Edge 的配置差异

Firefox 在 Katalon 7.5.5 里的驱动管理比 Chrome 要简单一些，因为 geckodriver 的版本兼容性更宽松。但 Firefox 的启动速度通常比 Chrome 慢，如果你做的是大批量用例执行，建议优先用 Chrome 或 Edge。

Edge 的情况比较特殊：Katalon 7.5.5 对 Edge 的支持依赖本机安装的 Edge WebDriver。Windows 10/11 自带的 Edge 是 Chromium 内核，驱动匹配逻辑和 Chrome 类似，但驱动文件名是msedgedriver.exe。配置方式和 Chrome 一样，在项目设置里把 Edge 的 Driver 从 Auto 改成 Custom 并指定路径即可。

4.3 执行测试套件时的参数取舍

当你把单个用例跑通之后，下一步通常是把它放进 Test Suite 里批量执行。Katalon 7.5.5 的 Test Suite 执行配置里有几个参数值得注意：

• 并行执行：在Test Suite -> Execution Information里可以设置并行模式。但并行执行对机器内存要求较高，每个浏览器实例大概吃 300-500 MB 内存，8 GB 的机器建议并行数不超过 3。
• 失败重试：Test Suite -> Retry里可以设置失败用例的重试次数。我一般设 1 次，避免因为网络抖动导致的偶发失败被误判为脚本问题。
• 超时设置：默认的页面加载超时是 30 秒，如果测试环境比较慢，可以在Project -> Settings -> Execution -> WebUI里把Default Page Load Timeout调到 60 秒。

// 在 Test Suite 的 setUp 里可以动态调整超时 import com.kms.katalon.core.configuration.RunConfiguration RunConfiguration.setWebDriverPreferencesProperty('pageLoadTimeout', 60) RunConfiguration.setWebDriverPreferencesProperty('scriptTimeout', 30)

这段代码的作用是在测试套件启动前，把页面加载超时改成 60 秒，脚本执行超时改成 30 秒。参数值根据你的测试环境响应速度来定，内网环境可以调小，公网环境建议调大。

5. 避坑与排查：Katalon Studio 7.5.5 装完跑不起来的五种情况

5.1 启动白屏或闪退

现象：双击Katalon Studio.exe后，启动画面一闪而过，或者停在白屏界面不动。

原因：最常见的是 JDK 版本不匹配。7.5.5 对 JDK 8 兼容最好，如果系统默认 JDK 是 11 或 17，启动阶段就会因为类文件版本不兼容而失败。其次是工作区路径包含中文或特殊字符，导致配置文件读写异常。

解决：先确认JAVA_HOME指向 JDK 8，然后在 cmd 里用java -version验证。如果 JDK 没问题，检查工作区路径，改成纯英文路径。还不行的话，删除工作区下的.metadata目录，让 Katalon 重新初始化。

5.2 浏览器启动后立即关闭

现象：执行用例时，浏览器窗口打开后瞬间关闭，控制台报Session not created或Chrome failed to start。

原因：chromedriver 版本和 Chrome 版本不匹配，或者 Chrome 的安装路径不是标准路径，导致 Katalon 找不到浏览器可执行文件。

解决：先确认 Chrome 版本（地址栏输入chrome://version），然后下载对应大版本的 chromedriver。如果 Chrome 装在非默认路径，在项目设置里手动指定 Chrome 的安装路径。

5.3 对象库元素找不到

现象：用例执行时报Element not found或NoSuchElementException，但手动打开页面明明能看到元素。

原因：页面加载没完成就开始查找元素，或者元素的定位属性在页面刷新后变了。Katalon 的默认等待策略是页面加载完成后立即查找，对动态加载的页面不够用。

解决：在查找元素前加显式等待。Katalon 提供了WebUI.waitForElementPresent关键字，可以指定等待时间和超时后的行为。

// 等待元素出现，最多等 10 秒 WebUI.waitForElementPresent( findTestObject('Object Repository/Login/btn_Submit'), 10 ) WebUI.click(findTestObject('Object Repository/Login/btn_Submit'))

waitForElementPresent的第一个参数是测试对象，第二个参数是超时秒数。如果元素在 10 秒内出现，脚本继续执行；超过 10 秒还没出现，就抛超时异常。这个关键字比硬编码delay更可靠，因为它会轮询检查，不会浪费时间。

5.4 报告生成失败或乱码

现象：测试执行完了，但Reports目录下没有生成报告，或者报告里的中文显示为乱码。

原因：报告生成依赖工作区的写入权限，如果工作区在系统保护目录下（比如C:\Program Files），写入会被拒绝。乱码问题通常是 JVM 的默认字符集不是 UTF-8。

解决：把工作区移到用户目录或 D 盘。字符集问题可以在katalon.ini里加一行-Dfile.encoding=UTF-8，强制 JVM 用 UTF-8 编码。

# katalon.ini 里追加 -Dfile.encoding=UTF-8

5.5 离线环境下插件加载失败

现象：在内网机器上启动 Katalon，卡在Loading plugins阶段，或者提示无法连接 Katalon Store。

原因：7.5.5 启动时会尝试连接在线插件仓库，离线环境下这个请求会超时。

解决：在configuration/目录下找到store.properties，把store.enabled改成false。如果之前已经下载过插件包，可以把插件放到plugins/目录下，Katalon 启动时会优先加载本地插件。

6. 装完怎么验证跑通：三条命令加一个习惯

环境装完、用例能跑之后，我一般会用三个动作来确认这套 Katalon Studio 7.5.5 是真的稳了，而不是“碰巧跑通一次”。

第一个动作是跑一个跨浏览器的冒烟用例。同一个脚本，分别在 Chrome、Firefox、Edge 上各执行一遍。如果三个浏览器都能正常打开页面、完成操作、关闭窗口，说明驱动配置没有遗漏。这一步能暴露很多单浏览器测试发现不了的问题，比如某个浏览器对 CSS 选择器的支持差异。

第二个动作是检查报告输出。执行完测试套件后，打开Reports目录，确认 HTML 报告能正常打开，里面的用例名称、执行时间、失败截图都完整。我见过报告目录生成了但内容是空的情况，原因是工作区磁盘满了，写入被静默截断。所以这一步不只是看报告有没有，还要看报告里的数据对不对。

第三个动作是模拟一次失败场景。故意把某个元素的定位改错，执行用例，确认 Katalon 能正确捕获失败、生成失败截图、在报告里标记为 Failed。这个动作的目的是验证失败处理链路是通的——很多时候环境装好了，但失败截图功能没配好，真出问题的时候拿不到现场信息，排查起来就是黑匣子。

// 验证失败截图是否生效的示例 import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI import static com.kms.katalon.core.testobject.ObjectRepository.findTestObject WebUI.openBrowser('') WebUI.navigateToUrl('https://example.com') // 故意找一个不存在的元素，触发失败 WebUI.click(findTestObject('Object Repository/NonExistent/btn_NotFound')) WebUI.closeBrowser()

执行这段脚本，预期结果是用例失败，并且在报告里能看到失败时的页面截图。如果截图是空白的或者没有生成，去Project -> Settings -> Execution -> WebUI里确认Take Screenshot on Failure是勾选状态。

从那以后，我每次在新机器上装完 Katalon，都会强制走一遍这三个验证动作，尤其是失败截图那一步。因为自动化测试的价值不在于“跑通”，而在于“跑挂的时候能告诉你为什么挂”。环境装得再顺，如果失败现场拿不到，后面排查的时间成本会翻倍。希望这套流程能帮你少走点弯路。

本文还有配套的精品资源，点击获取