AI生成测试用例+agent browser实现Web测试用例执行

"博友们～还在对着需求文档苦哈哈地手写测试用例？还在为了跑回归测试熬夜盯屏幕？👋 今天给大家安利一套**'王炸组合'**：用 AI 自动生成用例 + agent-browser 自动执行！不仅能读懂需求，还能像人一样操作浏览器。从此告别重复劳动，让测试效率直接起飞！🚀"

源代码到时脱敏后上传至GitHub~

本项目言简意赅：拉取需求文档基于其直接生成测试用例，再根据测试用例执行测试，最后生成测试报告以及缺陷清单。

下文是本项目使用agent-browser的相关操作原理。

生成测试用例提示词

代码下拉下来后在项目中实现

# Role
你是一位资深测试专家，拥有10年以上测试用例设计经验，精通功能测试、接口测试、性能测试、安全测试等全场景测试设计。

# Task
请根据链接中的需求文档（链接：xxx），严格使用项目中已有的@testwork-master/.cursor/skills ，尽可能多的生成不少于300条完整、全面的测试用例。

# Context
## 1. 测试用例格式要求

请按照项目中的 @testwork-master/.cursor/skills  规范，同时输出以下三种格式：

### Excel格式（.xlsx）

### Markdown格式（.md）

### JSON格式（.json）

## 2. 输出文件规范

根据项目规则，将文件输出到@testwork-master/docs/feishu 文件夹下对应位置，若无请进行补充创建

注意：用json文件用例转换为xmind用例（为实现标准化测试用例）

执行测试用例

使用工具：agent browser

你是测试用例执行专家，请你阅读参考.cursor中的执行测试用例规则，用我本项的agent-browser工具执行需求测试用例.md文档的Web端测试用例，跳过涉及app、接口、性能、无权限账号的测试用例。输出的测试报告以及缺陷清单放在需求文件夹/测试报告文件夹下。现在请你全量分批执行。

agent-browser

1. 简要概括

一句话概括：

agent-browser 是一个面向 AI Agent 的浏览器自动化 CLI，它让 Agent 可以像测试人员一样打开页面、读取页面结构、点击、输入、截图、断言，并最终输出可追溯的测试报告。

在当前项目里，agent-browser 不是单独的工具演示，而是已经接入到了"需求 → 用例 → 自动化执行 → 截图证据 → 测试报告 → 缺陷沉淀"的 Web 测试流程中。

2. agent-browser对比传统自动化

传统 Web 测试自动化通常有几个问题：

1. 脚本成本高

• 每个页面都要写选择器、等待、断言和数据清理逻辑。
• 页面一改，脚本经常要跟着改。

1. AI 直接操作浏览器缺少规范

• 如果只让 AI "看页面并操作"，很容易出现漏步骤、误点、结果不可追溯。
• 没有报告和截图时，执行结论不够可信。

1. 手工测试结果难沉淀

• 手工测完以后，很多页面操作经验、环境问题、组件坑点容易散落在聊天记录里。
• 下一次复测又要重新摸索。

agent-browser 的价值在于，它提供了一套命令行能力，让 AI Agent 能够稳定地进行浏览器操作，并把操作过程转化为可复用的测试资产。

3. agent-browser 是什么

agent-browser 是一个浏览器自动化 CLI，特点是：

• 使用命令行控制浏览器。
• 支持打开页面、点击、输入、上传、截图、执行 JavaScript、读取 DOM 信息。
• 通过 snapshot 输出页面可访问性树和元素引用，例如 @e2、@e33。
• 非常适合 AI Agent 使用，因为 Agent 可以先读取页面结构，再基于 ref 操作页面。
• 可以配合项目内规则，把测试动作、断言、截图和报告串起来。

在项目里，我们主要使用的是本地依赖版本：

{
  "devDependencies": {
    "agent-browser": "^0.27.0"
  }
}

4. 在本项目中的定位

当前项目的 README 已经把主流程定义为：

飞书需求 → 测试用例 → agent-browser 自动执行

也就是说，agent-browser 负责的是执行层：

需求文档
  ↓
测试用例
  ↓
Agent 读取执行规则
  ↓
agent-browser 打开页面并操作
  ↓
截图、断言、记录结果
  ↓
生成测试报告

项目里真正约束 agent-browser 使用方式的是：

.cursor/skills/web-browser-tester/SKILL.md

这个 skill 把 Agent 的角色限定为"测试工程师"，强调：

• 只执行测试，不擅自改需求。
• 主流程使用 agent-browser CLI。
• 不用 Playwright MCP 或 Cursor 内置 Browser 替代主流程。
• 输入优先读取可执行用例。
• 输出中文测试报告和截图证据。
• 真实执行，禁止编造通过或失败。

4.1 截取的部分skills

• 蒸馏沉淀

• 调用索引

• 硬性约束

5. 安装与初始化（使用项目时不需用，已安装好）

项目推荐使用本地 agent-browser.cmd，避免全局 PowerShell 脚本兼容问题。

首次使用：

cd d:\code\cursor\web-test
npm install
npm run setup

初始化过程会完成：

• 安装 agent-browser。
• 执行 agent-browser install，准备浏览器运行环境。
• 生成测试所需的基础资源，例如 tests/test-assets/。

项目内强调：

请使用项目内 node_modules\.bin\agent-browser.cmd，不要用全局 agent-browser.ps1。

原因是全局 PowerShell 入口可能导致参数兼容问题，例如 -i 参数无法正常识别。

6. agent-browser 常用命令

6.1 打开页面

agent-browser open "https://example.com"

在本项目里，打开 URL 前需要先从文档解析环境地址，不允许随手写死历史域名。

6.2 获取页面快照

agent-browser snapshot
agent-browser snapshot -i
agent-browser snapshot -i -c

常用的是：

agent-browser snapshot -i -c

含义：

• -i：只看可交互元素。
• -c：compact，输出更紧凑。

快照会返回类似 @e2、@e3、@e33 的元素引用，后续点击、输入都基于这些 ref。

• 关于ref

ref （引用标识符）是 agent-browser 为当前页面中每个可交互元素自动生成的唯一编号。

它的核心作用和工作方式如下：

• 作为精准"坐标" ：当 AI Agent 通过 snapshot 命令获取页面结构化的文本快照后，每个按钮、输入框、链接等可交互元素旁都会附带一个类似 @e33 的标记。这个 ref 就是该元素在页面中的唯一"身份证"。
• 用于直接操作 ：Agent 不需要像人类一样通过视觉识别按钮位置或编写复杂的选择器（如 CSS 或 XPath）。只需在 click、fill 等操作命令中直接引用这个 ref（例如 click "@e33"），工具就能精确定位并触发该元素。
• 解决"看不见"的问题：这种机制把视觉问题转化为文本匹配问题，极大降低了 AI 处理网页的难度，也避免了因页面样式变化或渲染差异导致的操作失败。

简单说，ref 就是 AI 操作网页元素的"快捷指令"，让自动化交互变得稳定、简洁且无需依赖视觉模型。

ref 是如何生成的

当你运行 snapshot 命令时，agent-browser 会：

1. 遍历 DOM 树 ，找出所有可交互元素（按钮、链接、输入框、下拉菜单、复选框等）。
2. 为每个符合条件的元素分配一个唯一编号 ，格式为 @e + 数字（如 @e1、@e2、@e33）。
3. 生成一份结构化文本快照，将元素及其 ref 一起输出。

注意 ：ref 不是固定的 CSS 选择器或 XPath，而是每次运行 snapshot 是动态生成的。同一页面在不同时间运行 snapshot，同一个元素的 ref 可能不同。

6.3 点击

agent-browser click "@e33"

注意在 PowerShell 里，ref 一定要加引号。

错误示例：

agent-browser click @e33

正确示例：

agent-browser click "@e33"

6.4 输入

agent-browser fill "@e2" "test@example.com"
agent-browser type "@e214" "测试文案"

区别：

• fill：清空后填入。
• type：模拟真实键盘输入，不清空原内容。

在 iView/Vue 表单里，如果要测试 maxlength，必须优先使用 type，不能直接用 JS 改 value。

6.5 快捷键

agent-browser press "Control+a"
agent-browser press "Enter"
agent-browser press "Tab"

6.6 上传文件

agent-browser upload "#ab-logo" "d:\code\cursor\web-test\tests\test-assets\logo.png"

本项目里上传通常会先通过 eval 给 input[type=file] 设置稳定 id，再用 upload 操作。

6.7 执行 JavaScript

agent-browser eval "document.title"

复杂 JS 不建议直接写在命令行里，推荐放到 tests/scripts/*.js 中，再读取执行。

6.8 截图

agent-browser screenshot "tests/artifacts/TC-xxx-fail.png"

项目规则要求：

失败必须截图。

截图路径通常放在：

tests/artifacts/
object/<业务对象>/artifacts/

7. 标准执行流程

项目内对 agent-browser 的使用定义了一套标准流程。

Step 1：解析任务范围

优先查找可执行用例：

tests/cases/*.md
object/*/case/*.md

如果用户指定了某个测试用例文档，则读取该文档，提取：

• 用例 ID
• 前置条件
• 执行步骤
• 预期结果
• 是否允许提交
• 是否需要特殊账号或 APP 环境

Step 2：检查工具与环境

agent-browser --version
cd d:\code\cursor\web-test

同时检查：

• SIT 账号是否可用。
• 测试资源是否存在。
• 目标 URL 从环境文档解析，不写死。

Step 3：登录目标系统

示例流程：

agent-browser open $loginUrl
Start-Sleep -Seconds 3
agent-browser snapshot -i -c
agent-browser fill "@e2" "<username>"
agent-browser fill "@e3" "<password>"
agent-browser click "@e5"
Start-Sleep -Seconds 5
agent-browser open $targetUrl

注意：

• @e2、@e3、@e5 只是示例，真实执行要以当次 snapshot 为准。
• 页面跳转、弹窗、抽屉打开后，ref 会变化，需要重新 snapshot。

Step 4：逐条执行用例

单条用例执行口径：

1. 记录开始时间。
2. 检查前置条件。
3. snapshot -i 获取当前页面可交互元素。
4. 根据用例执行 click、fill、type、upload、eval。
5. 对照预期结果做断言。
6. 失败截图。
7. 记录结束时间和结果。

结果只能使用：

通过 / 失败 / 部分通过 / 阻塞 / 跳过

Step 5：生成报告

报告要包含：

• 元信息。
• 执行环境。
• 用例来源。
• 执行范围。
• 汇总结果。
• 用例执行时间表。
• 分用例明细。
• 失败截图或证据路径。
• 缺陷清单。
• 未覆盖或阻塞原因。

Step 6：测后沉淀

如果执行中发现新问题，需要沉淀到：

• tests/reports/
• tests/artifacts/
• tests/references/
• tests/scripts/
• object/<业务对象>/reports/
• .cursor/skills/web-browser-tester/pitfalls.md

这样下次执行时，Agent 不需要重新摸索。

8. 实战案例：添加广告

近期最完整的 agent-browser 实战案例是：

object/添加广告/

8.1 需求背景

该需求的核心是：

• 支持在个股详情页展示。
• 广告位置新增 position=9。
• 支持展示范围：

• 全部个股
• 部分市场
• 部分行业
• 部分品类
• 部分股票
• 端接口 BarAdList 支持 position=9，且 code 必传。

8.2 用例规模

用例文件：

object/个股详情页新增小黄条/case/xxx测试用例.md

用例统计：

|------|-----|
| 类型 | 数量 |
| 总用例数 | 240 |
| 正向 | 134 |
| 逆向 | 87 |
| 异常 | 11 |
| 并发 | 8 |

8.3 agent-browser 执行范围

本轮主要通过 agent-browser 覆盖 Web 中台 UI：

• 进入 APP 广告配置列表页。
• 使用广告 ID 查询。
• 打开新建广告抽屉。
• 选择广告类型为小黄条。
• 选择广告位置为个股详情页。
• 验证展示范围类型。
• 验证部分市场枚举。
• 填写完整表单。
• 处理已有广告冲突。
• 提交待审核。
• 审核通过。
• 查看操作记录。

8.4 执行结果

报告文件：

object/个股详情页新增小黄条/reports/2026-07-13-个股详情页新增小黄条-Web端UI复测执行报告.md

执行结论：

部分通过

已跑通的主链路：

• AD002205：按授权下架，释放个股详情页小黄条位置。
• AD002207：通过 agent-browser 操作新建，提交待审核，并由审核人审核通过，当前状态待发布。

发现的主要缺陷：

|---------------|------|---------------------|
| 缺陷编号 | 严重程度 | 问题 |
| DEF-SDB-001 | 高 | 小黄条展示位置未显示"首页" |
| DEF-SDB-002 | 高 | 必填字段缺失时保存仍创建广告 |
| DEF-SDB-003 | 高 | 非小黄条广告类型仍可选择"个股详情页" |

这个案例体现了 agent-browser 的核心价值：

• 它不是只看页面截图，而是真实操作完成了新建、提交、审核链路。
• 每个失败点都有截图或报告证据。
• 对共享 SIT 数据的变更有记录，例如下架、创建、审核状态。

9. agent-browser 的优势

9.1 更适合 AI Agent

snapshot 可以把页面变成结构化文本，Agent 不需要靠视觉猜按钮位置，而是根据可交互元素 ref 操作。

示例：

agent-browser snapshot -i -c
agent-browser click "@e33"

9.2 比纯手工更可追溯

每轮执行可以留下：

• 命令序列。
• 用例 ID。
• 开始和结束时间。
• 截图。
• 失败原因。
• 数据变更。
• 缺陷清单。

9.3 比一次性脚本更灵活

传统脚本适合稳定路径，agent-browser + Agent 更适合半结构化场景：

• 页面还在变化。
• 用例需要边执行边判断。
• 抽屉、弹窗、动态表单比较多。
• 需要测试人员式的探索和复盘。

9.4 适合中台类页面

当前项目里的中台页面有大量典型模式：

• 左侧菜单。
• 筛选区。
• 表格。
• 分页。
• 更多筛选。
• 右侧抽屉。
• 下拉级联。
• 上传文件。
• 审核流转。
• 操作记录。

这些模式非常适合沉淀成 agent-browser 操作套路。

10. 踩坑与经验

项目里已经把典型坑记录到：

.cursor/skills/web-browser-tester/pitfalls.md

10.1 不要写死域名

问题：

换环境后仍 open 旧 host，导致登录失败或页面 404。

正确做法：

• 执行前读取环境文档。
• 用 $loginUrl、$targetUrl 变量。
• 报告里写清楚本次实际 host。

10.2 snapshot ref 会漂移

问题：

打开抽屉、切换 Tab、刷新页面后，@e33 可能不再是原来的按钮。

正确做法：

agent-browser snapshot -i

关键操作前重新 snapshot。

10.3 maxlength 不能用 eval 测

问题：

用 el.value += ... 再 dispatchEvent 会绕过 iView/Vue 的真实输入限制。

这会造成假失败。

正确做法：

agent-browser type "@e214" "真实输入内容"

10.4 PowerShell 中 ref 要加引号

错误：

agent-browser click @e2

正确：

agent-browser click "@e2"

10.5 中文 eval 容易出编码问题

复杂中文匹配建议：

• 用 Unicode 转义。
• 或把 JS 放到 tests/scripts/*.js。
• 或使用 snapshot ref 替代中文选择器。

10.6 级联选择要分步

问题：

同一个 eval 里连续选择广告类型、展示位置、广告形式，容易因为 DOM 未渲染完成失败。

正确做法：

选择广告类型
  ↓
等待
  ↓
选择展示位置
  ↓
等待
  ↓
选择广告形式

11. 与 Playwright 的区别

这里不是说 agent-browser 替代所有自动化工具，而是它在当前场景更适合 AI 驱动测试。

|--------|---------------------------|------------------|
| 对比点 | agent-browser | Playwright |
| 使用方式 | CLI 命令驱动 | 编写测试脚本 |
| 适合场景 | AI Agent 边看边操作、探索式执行、快速复测 | 稳定回归、长期自动化流水线 |
| 页面识别 | snapshot ref、语义元素、选择器 | locator、selector |
| 维护成本 | 前期低，依赖执行规则和沉淀 | 前期较高，但稳定后适合 CI |
| 当前项目定位 | 测试执行主流程 | 可作为后续稳定脚本化补充 |

本项目目前选择 agent-browser 作为主执行引擎，是因为我们很多需求还处在快速验证和复测阶段，更需要灵活执行、快速留证和沉淀流程。

12. 团队如何复用

后续团队使用时，可以按这个模板走：

12.1 准备测试材料

object/<需求名>/requirements/
object/<需求名>/case/

12.2 明确执行入口

例如中台页面：

menutree/中台-门户层级/portal-menu.md

12.3 让 Agent 执行

给 Agent 的指令可以是：

以测试工程师身份，用 agent-browser 执行 object/<需求名>/case/<测试用例>.md 中的 P0 用例。
要求真实执行、失败截图、输出中文报告。

12.4 查看产物

执行产物通常包括：

object/<需求名>/reports/
object/<需求名>/artifacts/

12.5 沉淀经验

如果遇到新组件、新坑、新命令序列，应补充到：

.cursor/skills/web-browser-tester/pitfalls.md
.cursor/skills/web-browser-tester/references.md
tests/scripts/

13. 当前不足

agent-browser 当前在项目里也有一些限制：

1. 依赖页面稳定性

• 页面 ref 会变化，需要重新 snapshot。

1. 复杂断言仍需脚本辅助

• 比如批量字段校验、接口返回解析、复杂 DOM 遍历，适合写到 tests/scripts/*.js。

1. 执行速度不一定比纯脚本快

• 它更强调真实操作和过程可解释，不是极限性能。

1. 对环境依赖明显

• 账号、权限、测试数据、审核流、APP 真机都会影响结果。

1. 需要规范约束 Agent

• 没有 web-browser-tester 这类规则时，Agent 容易跳步骤或过度推断。

ok，本篇内容就到这里，如果有不足或者需要优化的地方欢迎各位大佬在评论区指点江山~