告别脆弱的选择器测试：Approxima 开源了一个用自然语言写测试用例的 Agent 平台

还在为 CSS 选择器漂移导致的测试失败加班？有人把测试用例写成了自然语言，让 AI Agent 在真实浏览器里跑。

你有没有过这种经历：改了个按钮的 class 名，CI 里 40 个 E2E 测试全红了。点进去一看，产品功能完全正常，只是选择器变了。然后你花 2 小时更新测试里的选择器——这 2 小时本来可以用来写功能。

这是今天 E2E 测试的两难困境：

1. 自己维护脚本化 E2E 套件：测试通过硬编码的 CSS 选择器指向 DOM。产品每天都在变，选择器漂移，测试在什么都没坏的时候失败。覆盖率追不上 AI 辅助开发的速度。
2. 把测试交给托管的 AI QA 平台：脆弱性问题好了一些，但你的测试、历史和发布信心都活在别人的服务器上，完全受制于人。

Approxima 的思路是：两半都可以修好。用意图（intent）而非选择器写测试——"把商品加入购物车，验证总价更新"——DOM 变了测试不会漂移。加上它是开源的（MIT 协议），你可以自托管，永远自己掌控。

项目刚在 GitHub 上开源，地址：github.com/Approxima-AI/Approxima-OSS。

本文提纲

1. 核心概念：Journey 和自然语言测试
2. Goal Mode：给个目标，Agent 自己探索步骤
3. Skills：像搭积木一样复用测试步骤
4. Self-healing：步骤和 UI 对不上了？Agent 自动修正
5. Shadow Runs：A/B 测试 Agent 本身
6. 技术架构：三层分离，可独立部署
7. 和传统 E2E 测试的对比
8. 实际使用中的注意事项

核心概念：Journey 和自然语言测试

Approxima 的基本单元叫 Journey——一个有序的纯英文步骤列表：

1. Click "Sign in"
2. Enter $TEST_EMAIL in the email field
3. Enter $TEST_PASSWORD in the password field
4. Click "Submit"
5. Verify the dashboard shows "Welcome back"

Agent 在真实浏览器（Chromium）中逐步执行，每步操作后截图，然后视觉验证步骤是否通过，再进入下一步。你可以把多个 Journey 组成 Suite，按 cron 定时跑，或从 dashboard 手动触发。

和传统测试的根本区别在于：你描述的是意图（intent），不是操作细节。Agent 自己决定点哪里、怎么输入、如何验证。

Goal Mode：给个目标，Agent 自己探索步骤

如果你不知道（或不想关心）具体步骤是什么，可以用 Goal Mode：

Agent 进入探索模式，在你的应用里摸索直到完成目标，然后把发现的步骤写回 Journey，立刻触发一次验证运行来证明这些步骤可复现。从那以后，它就作为普通的确定性 Journey 运行。

这个功能特别适合：
- 新功能刚上线，还没写测试——先用 Goal Mode 探索一遍，步骤自动生成
- 复杂的用户流程，手动写步骤太繁琐
- 快速验证核心路径是否通畅

Skills：像搭积木一样复用测试步骤

Skill 是可复用的步骤序列。比如"登录"这个操作在 20 个 Journey 里都要用到：

Skill: Login
  1. Enter email
  2. Enter password
  3. Click submit

Journey 引用它时只需一个步骤："Login"。Skill 在运行时内联展开，所以更新一个 Skill 就更新了所有引用它的 Journey。

更聪明的是：Goal Mode 是 Skill-aware 的。Agent 探索出来的步骤如果匹配已有 Skill，会自动折叠成 Skill 引用而非重复步骤。

Agent 发现的路径:
  1. Enter user@test.com in email field  → 折叠为 "Login" skill
  2. Enter password123 in password field  → 折叠为 "Login" skill
  3. Click submit button                  → 折叠为 "Login" skill
  4. Click "New Project"                 → 保留为独立步骤
  5. Enter "My Project" in name field    → 保留为独立步骤

Self-healing：步骤和 UI 对不上了？Agent 自动修正

当你的应用改了，步骤描述和实际 UI 不匹配时，Agent 不是直接报错失败——它会推断步骤应该是什么，并在运行结果中报告修正后的步骤。

这些修正建议以 inline suggestion 的形式出现在 dashboard 的 Journey 编辑器里，一键接受或忽略。一个模糊的步骤可能被拆成多个精确的步骤。建议在上浮到用户之前经过 LLM 审查，过滤掉琐碎的措辞变化和选择器噪音。

实际场景举例：

原步骤: "Click the blue submit button"

UI 变化: 按钮颜色从蓝色改成了绿色，文字改成了 "Continue"

Agent 建议:
  "Click the 'Continue' button"
  → 一键接受 ✅

Shadow Runs：A/B 测试 Agent 本身

这个功能挺有意思——你可以 A/B 测试 Agent 的 prompt。

Agent 是版本化的，每个版本活在独立的文件夹里。想试 v2 prompt？注册为 beta 版本，开启 AUTO_SHADOW_ENABLED。每次真实运行都会自动派生一个 Shadow Run，用 beta Agent 跑同一个 Journey。Admin 面板用配对统计比较两个群体的表现。

这意味着你可以：
- 科学地评估 prompt 改动是否真的提升了 Agent 准确率
- 切换 LLM 提供商（比如从 Gemini 换到 Claude）之前先做对比
- 持续迭代 Agent 行为，有数据支撑而非靠感觉

技术架构：三层分离，可独立部署

MERMAID_BLOCK_0

三层可以独立部署。官方日常用的栈是 Neon (Postgres) + Cloudflare Workers + Railway + AWS S3 + Gemini，但都不是必须的。

Agent 的浏览器驱动方式值得注意：

• 点击操作：Agent 从截图识别目标元素，但实际操作的是 DOM 元素而非像素坐标。优先级：Role → Text → CSS Selector
• 截图验证：默认截取整个视口 (1280x720)，也支持 400x400 的局部裁切来检查细节
• LLM 推理：每步操作后截图，LLM 视觉验证是否通过

和传统 E2E 测试的对比

核心取舍很明确：你牺牲了一些运行速度和 LLM 费用，换来的是极低的维护成本和自愈能力。对于频繁迭代的产品，这个取舍通常是值得的。

实际使用中的注意事项

1. 密钥安全

文档里有一段很诚实的说明：Agent 登录你的应用时，密钥值必须发给云端 LLM（因为 LLM 决定输入什么）。加密和脱敏只控制"值在哪里落盘"，无法阻止"值被发给模型"。所以：

Approxima 中使用的密钥应该用于测试工作区——那种丢了也不心疼的环境。

2. LLM 成本

每个步骤都需要 LLM 推理（看截图 + 决定操作 + 验证结果）。一个 10 步的 Journey 大约需要 10+ 次 LLM 调用。建议：
- 用 Gemini 做主力（便宜），Anthropic/OpenAI 做 fallback
- 核心路径用 Journey Mode（确定性），新功能用 Goal Mode（探索性）
- 善用 Skill 复用，减少重复步骤的 token 消耗

3. 无内置认证

当前版本没有用户认证系统。Dashboard 和 API 对能访问到它的人完全开放。需要在 localhost、私有网络或自己的认证代理后面运行。

4. 快速上手

git clone https://github.com/Approxima-AI/Approxima-OSS && cd Approxima-OSS
npm install
npx playwright install chromium
npm run build

# 配置数据库和 API
DATABASE_URL="postgresql://..." npm run db:migrate -w api
cp api/.dev.vars.example api/.dev.vars
cp web-runner/.env.example web-runner/.env
# 填入 LLM API key、S3 配置等

# 启动
npm run dev:api          # API :8787
npm run dev:web-runner   # Runner :3002
npm run dev:frontend     # Dashboard :3000

打开 http://localhost:3000，创建应用，写第一个 Journey——或者直接给个目标让 Agent 自己探索。

总结

Approxima 解决的核心问题是：E2E 测试的维护成本不应该随产品迭代速度线性增长。

它用"意图而非选择器"的思路，加上 Agent 的自愈能力和目标探索模式，让测试编写和维护的门槛大幅降低。代价是运行速度和 LLM 费用，但对于追求覆盖率但 QA 人力有限的团队来说，这种"Agent 即测试员"的范式是一个值得认真评估的方向。

你团队的 E2E 测试维护痛点是什么？有没有试过 AI 驱动的测试方案？评论区聊聊。觉得有用就点个赞，让更多 QA 和开发看到这个工具。

参考文档与链接

项目相关
- Approxima-OSS GitHub 仓库 — 开源代码、文档和快速开始指南
- Approxima 官方网站 — 产品主页和托管服务

相关技术和工具
- Playwright 官方文档 — 浏览器自动化引擎
- Drizzle ORM — 数据库 ORM 和迁移工具
- Hono.js — 轻量级 Web 框架，用于 API 层
- Cloudflare Workers — Serverless 部署平台

AI 测试领域参考
- Anthropic Computer Use — Claude 的计算机使用能力
- OpenAI: A practical guide to building agents — Agent 构建实践指南
- Google: Modern Testing Practices — Google 测试博客
- Playwright: Accessibility-first testing — 无障碍优先的测试方法

CI/CD 集成
- GitHub Actions: Playwright — Playwright 在 GitHub Actions 中的集成
- Testcontainers — 容器化测试环境管理

作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。