TestZeus Hercules：功能测试写 Gherkin，让 AI Agent 去跑冒烟流程

功能测试同学最熟的东西，不是代码，而是测试步骤。

比如一个发版前冒烟流程，手工用例通常长这样：

• 打开登录页
• 输入测试账号
• 点击登录
• 进入商品列表
• 搜索商品
• 加入购物车
• 提交订单
• 校验订单创建成功

这类用例写在测试平台里没问题，但每次发版都手点一遍，很容易变成重复劳动。传统自动化又要求写 Playwright、Selenium、selector、等待策略，很多功能测试同学不一定有时间维护。

TestZeus Hercules 的切入点是：把 Gherkin 风格的测试步骤交给 AI testing agent 去执行。

先说实践场景

假设你负责一个后台系统，明天要发版。

你手里有 3 条必须回归的冒烟流程：

• 管理员登录后能看到首页
• 创建一条商品配置并保存
• 搜索刚创建的数据并进入详情页

原来怎么做？

• 手工打开页面
• 按用例点一遍
• 截图留证据
• 发现失败后录屏或写复现步骤
• 下个版本再重复一遍

Hercules 的实践思路是：把这些步骤写成 Gherkin，让 Agent 去浏览器里执行，并输出截图、日志、视频、JUnit XML 或 HTML 报告。

30 秒结论

TestZeus Hercules 对应的是功能测试、UI/E2E 测试和冒烟回归。

官方 README 里写到，它把简单易写的 Gherkin steps 转成全自动 E2E tests，不需要编码技能；它还提到支持 UI、API、安全、可访问性、视觉验证等方向。

AI 参与的测试动作是：

• 读取自然语言/Gherkin 步骤
• 规划浏览器操作
• 执行页面点击、输入、校验
• 生成执行证据
• 在复杂场景下调用 Playwright 或自定义 Python 脚本

收益判断必须说清楚：下面的提效拆解是基于官方能力做的工程推导，不是官方承诺的提效数据，也不是社区普遍评价。

下面这张是 GitHub 仓库首页截图，用来证明项目主页、仓库归属和官方入口真实存在。它只作为仓库事实截图，不作为社区评价或效果数据使用。

原来怎么做，工具介入后少做什么

不用 Hercules 时，功能测试转自动化通常卡在这里：

• 测试步骤在用例平台里，自动化脚本在代码仓库里，两边不同步
• 页面 selector 不稳定，脚本维护成本高
• 功能测试写得出步骤，但不一定愿意写 Playwright
• 自动化失败后，还要手工补截图、日志、复现说明

Hercules 介入后，可以减少的动作是：

• 少把手工用例逐句翻译成代码
• 少从零维护一套页面操作脚本
• 少手工截图和整理执行证据
• 少把“用例步骤”和“自动化脚本”分成两套语言
• 少让功能测试同学在 selector 上消耗时间

这里要注意：它不是替代测试设计。Gherkin 写得含糊，Agent 执行也会含糊。

最小验证怎么做

不要一上来跑复杂交易流程。

第一条用例可以只做登录冒烟。

示例 feature：

Feature: 登录冒烟Scenario: 测试账号可以登录后台Given 打开后台登录页面When 输入用户名"qa_demo"And 输入密码"qa_password"And 点击登录按钮Then 页面应该显示"工作台"

官方 README 给出的安装方式是：

pip install testzeus-hercules playwright install --with-deps

运行时需要指定输入文件、输出目录、测试数据路径和模型配置，例如官方示例中有：

testzeus-hercules --input-file opt/input/test.feature --output-path opt/output --test-data-path opt/test_data --llm-model gpt-4o --llm-model-api-key sk-proj-k.......

第一轮只验证四件事：

• 它能不能按 Gherkin 打开页面
• 能不能找到输入框和按钮
• 能不能输出截图/报告
• 失败时 QA 能不能复现和判断

AI 具体参与哪一步

这里的 AI 不是给你写一段“看起来像测试”的文本。

它参与的是执行链路：

• 读 Gherkin 步骤
• 理解页面目标
• 操作浏览器
• 在必要时处理页面变化
• 生成证据

更适合 QA 的用法是：先把现有手工冒烟用例改成 Gherkin，而不是让 AI 自己发明测试用例。

例如：

Scenario: 商品创建后可以搜索到Given 管理员已经登录后台When 打开商品管理页面And 创建商品"QA自动化商品001"And 回到商品列表And 搜索"QA自动化商品001"Then 列表中应该展示这个商品

这类用例本来就是功能测试每天维护的东西。AI 只是把执行动作接过去。

提效点拆解

第一，用例语言更接近功能测试。

功能测试同学更容易 review Gherkin，而不是 review 一堆 locator 和 await。

第二，冒烟路径可以沉淀成执行资产。

原来每次发版都手点登录、创建、查询。现在至少可以把最稳定的 3 条路径交给 Agent 跑，再人工看失败和证据。

第三，失败证据更完整。

Hercules README 提到输出路径里包括 JUnit XML、HTML report、proofs、network logs、screenshots、videos 等结构。对 QA 来说，这比口头说“我这边复现了”更容易交给开发定位。

第四，复杂步骤仍可落回脚本。

官方 README 里也展示了可以从 Gherkin 调用自定义 Python 脚本，并获得 Playwright API 能力。也就是说，纯自然语言不够稳定时，可以把关键动作固化成脚本。

QA 仍然要自己判断什么

第一，哪些用例适合交给 Agent。

稳定、短、路径清晰的冒烟用例适合；强依赖验证码、短信、支付、第三方跳转的流程不适合第一批。

第二，Gherkin 是否可执行。

“检查页面正常”这种描述太宽泛。要写成“页面应该显示某个文案、某个按钮、某个结果”。

第三，失败是不是缺陷。

Agent 点错、页面慢、测试数据脏，都可能导致失败。QA 仍然要看截图、视频和日志判断。

第四，账号和测试数据安全。

不要把真实账号、token、客户数据写进 feature 或 test data。

总结

Hercules 更像是“让功能测试用自己的语言写冒烟路径，再让 AI Agent 去执行”。

它的实践价值不是让 AI 自己决定测什么，而是把已有手工用例变成更容易重复执行、留证据、进入回归的资产。

建议第一轮只做一件事：

• 选 1 条登录冒烟
• 写成 Gherkin
• 跑一次
• 看报告和截图
• 人工判断失败是否可复现

如果这条链路稳定，再扩展到创建、搜索、详情页这类主流程。不要一开始就幻想把全部手工测试自动化。

参考链接：

• TestZeus Hercules GitHub：https://github.com/test-zeus-ai/testzeus-hercules