专为 Claude Code 和 Playwright MCP 打造的 YAML 配置如何改变了我们的测试工作流程,让自动化测试变得人人可用
如果你曾经维护过大型 Playwright 测试套件,你一定知道其中的痛苦。数百行 JavaScript 代码散布在数十个文件中,硬编码的值在环境变化时就会崩溃,测试逻辑复杂到只有原作者才敢修改。
如果我告诉你有更好的方法呢?一种任何人都能读懂、天生易维护、功能强大足以处理复杂工作流程的测试编写方式?
让我们来认识 专为 Claude Code 设计的基于 YAML 的 Playwright 测试 —— 一个正在改变团队自动化测试方式的范式转变,它结合了 Claude Code 的 AI 能力和 Playwright MCP 的浏览器自动化技术。
让我们坦诚面对传统 Playwright 测试的问题:
// 传统 Playwright 测试 - 50+ 行代码
test('完整订单流程', async ({ page }) => {
await page.goto('https://example.com');
await page.fill('[data-testid="username"]', 'user123');
await page.fill('[data-testid="password"]', 'pass456');
await page.click('[data-testid="login-btn"]');
await expect(page.locator('h1')).toContainText('仪表盘');
// ... 还有 40+ 行点击、填写、断言的代码
// ... 到处都是硬编码的值
// ... 测试之间无法复用
});
问题所在:
现在想象一下用 YAML 编写的同样测试:
# test-cases/order.yml
tags:
- smoke
- order
- checkout
steps:
- include: "login"
- "点击第一个商品的添加到购物车按钮"
- "点击第二个商品的添加到购物车按钮"
- "点击右上角购物车图标"
- "输入姓名"
- "输入姓氏"
- "输入邮政编码"
- "点击继续按钮"
- "点击完成按钮"
- "验证页面显示 感谢您的订单!"
- include: "cleanup"
立即的好处:
常见工作流程变成了构建块:
# steps/login.yml
steps:
- "打开 {{BASE_URL}} 页面"
- "在用户名字段填入 {{TEST_USERNAME}}"
- "在密码字段填入 {{TEST_PASSWORD}}"
- "点击登录按钮"
- "验证页面显示 Swag Labs"
编写一次,到处使用。告别复制粘贴的疯狂。
不同环境?没问题:
# .env.dev
BASE_URL=https://dev.example.com
TEST_USERNAME=dev_user
# .env.prod
BASE_URL=https://example.com
TEST_USERNAME=prod_user
相同的测试,不同的环境。自动切换。
只运行你需要的测试:
# 只运行冒烟测试
/run-yaml-test tags:smoke
# 运行订单 AND 结账测试
/run-yaml-test tags:order,checkout
# 运行冒烟 OR 关键测试
/run-yaml-test tags:smoke|critical
不再需要在你只改了登录流程时运行整个测试套件。
自动生成的 HTML 报告包含:
使用 YAML 测试之前:
使用 YAML 测试之后:
这个专为 Claude Code 和 Playwright MCP 设计的 YAML Playwright 测试框架由几个关键组件组成:
├── .env.dev # 开发环境
├── .env.test # 测试环境
├── .env.prod # 生产环境
├── steps/
│ ├── login.yml # 认证流程
│ ├── cleanup.yml # 清理程序
│ └── navigation.yml # 常见导航
├── test-cases/
│ ├── order.yml # 电商订单流程
│ ├── user.yml # 用户管理
│ └── search.yml # 搜索功能
框架自动:
include
引用{{BASE_URL}}
)基于 YAML 的测试之美在于其简单性。以下是开始使用的方法:
# 安装 Claude Code (如果尚未安装)
# 访问: https://claude.ai/code
# 为 Claude Code 安装 Playwright MCP
claude mcp add playwright -- npx -y @playwright/mcp@latest
# 克隆 YAML 测试框架
git clone https://github.com/terryso/claude-code-playwright-mcp-test.git
cd claude-code-playwright-mcp-test
your-project/
├── .env.dev # 环境配置
├── steps/ # 可复用步骤库
├── test-cases/ # 你的测试用例
├── screenshots/ # 测试产物
└── reports/ # 生成的报告
# test-cases/login.yml
tags:
- smoke
- auth
steps:
- "打开 {{BASE_URL}} 页面"
- "用户名填入 {{TEST_USERNAME}}"
- "密码填入 {{TEST_PASSWORD}}"
- "点击登录按钮"
- "验证登录成功"
# 在 Claude Code 中使用内置命令
/run-yaml-test file:test-cases/login.yml env:dev
# 或者使用标签过滤运行
/run-yaml-test tags:smoke env:dev
几小时内,你就会拥有比以前编写的任何测试都更易维护的测试。魔法通过 Claude Code 的 AI 理解你的自然语言步骤并由 Playwright MCP 执行为浏览器操作来实现。
# 多条件
/run-yaml-test tags:smoke,login|critical
# 特定环境执行
/run-yaml-test tags:order env:prod
steps:
- "将商品 {{PRODUCT_NAME}} 添加到购物车"
- "设置数量为 {{QUANTITY}}"
- "应用折扣码 {{DISCOUNT_CODE}}"
我们正在走向这样一个世界:
基于 YAML 的 Playwright 测试不仅仅是一个工具——它是一种哲学。它相信测试应该对团队中的每个人都是清晰的、可维护的和可访问的。
问:这与 Cucumber 等现有解决方案相比如何? 答:虽然 Cucumber 需要学习 Gherkin 语法和步骤定义,但这个 YAML 测试框架通过 Claude Code 的 AI 直接使用自然语言解释意图。无需步骤定义映射 - Claude Code 理解你想要做什么。
问:测试调试怎么办? 答:Claude Code 提供详细的执行日志,Playwright MCP 在失败时捕获截图,你还能获得映射回 YAML 步骤的清晰错误消息。AI 上下文有助于快速识别问题。
问:能与 CI/CD 集成吗? 答:当然可以。框架生成标准退出代码和多种报告格式( HTML 、JSON 、XML ),实现无缝 CI/CD 集成。
问:如何处理复杂断言? 答:Claude Code 的 AI 让自然语言断言出人意料地强大:"验证页面包含'谢谢'"、"验证购物车总计等于 ¥43.18"、"验证购物车中有 2 件商品"。AI 理解上下文和意图。
问题不在于这种方法是否更好。问题是:你愿意在脆弱、复杂的测试上浪费多少时间?
开始你的 YAML 测试之旅:
# test-cases/ecommerce-flow.yml
tags: [e2e, purchase, critical]
steps:
- include: "login"
- "搜索商品 '{{PRODUCT_NAME}}'"
- "添加到购物车"
- "查看购物车"
- "结账"
- "填写收货信息"
- "选择支付方式"
- "确认订单"
- "验证订单成功"
# test-cases/user-registration.yml
tags: [smoke, registration]
steps:
- "打开注册页面"
- "填写用户信息"
- "同意条款和条件"
- "提交注册"
- "验证邮箱"
- "验证注册成功"
# test-cases/hybrid-test.yml
tags: [api, ui, integration]
steps:
- "通过 API 创建测试数据"
- include: "login"
- "在 UI 中验证数据显示"
- "执行 UI 操作"
- "通过 API 验证后端状态"
准备好用 Claude Code 和 Playwright MCP 改变你的测试工作流程了吗?测试自动化的未来是可读的、可维护的,并且对每个人都是可访问的。
🔗 立即开始: https://github.com/terryso/claude-code-playwright-mcp-test
你当前 Playwright 测试的最大痛点是什么?基于 YAML 的测试配合 Claude Code 如何为你的团队解决这个问题?
1
kneo 1 天前 ![]() yaml as code 就是最大的痛点。不想多说。AI 生成的帖子,是第二大痛点。
|
![]() |
3
iyaozhen 23 小时 53 分钟前 ![]() 不知道为啥喜欢用 yaml 维护,做过的都知道,太垃圾了。描述性太差。比如要加入 if for 逻辑,又是新学一套语法。当然你可以文本描述让 AI 去做
而且你说的缺点也不是 yaml 能解决的。 - 简单操作被埋没在样板代码中。你 yaml 不封装 login 也一样呀,代码也可以封装 login - 环境变化就会导致一切崩溃。这个和 yaml 也没关系,主要是 AI 视觉理解带来的优势 - 复制粘贴导致维护噩梦。yaml 怎么避免这个问题?写的人自己没有设计,还不是一样 - 技术门槛。这个更是一直以来的一个误区,以为只要降低编写门槛就行,甚至没有降低,以为不写代码就行。其实不然,写 case 只占小部分时间,大部分时间是沉默的维护成本。那为什么维护成本高,说白了是写的人差,没有很好的设计,比如前面的 login 没有封装。只是降低写 hello word 的成本没有意义,还是得有编程思想 - 逻辑分散,更和 yaml 没啥关系,使用 yaml 也解决不了这个问题 |
![]() |
4
zeusho871 23 小时 35 分钟前
遇到页面大的 token 爆炸 之前尝试过用 browser-use 做爬虫。。。一个页面算下来 5 毛钱 害
|
5
terryso OP @iyaozhen 你搞错重点了, 重点在 Playwright MCP 和 Claude Code
1. Playwright MCP 在加载网页的时候给每一个元素动态增加了 ref id, 这给 AI 去操作元素的精确度极高, 测试通过率很高 2. Claude Code 可以在后台用无头模式在后台跑很久, 我试过 2, 30 个用例没什么问题 3. 而且用例是用自然语言写的, 很复杂的用例也能写出来, 而且就算你 UI 元素的选择器变了, 也很少需要维护, AI 会自己重新发现对应的 ref id 4. yaml 只是为了组合步骤给 AI 看而已, 用自然语言写用例可以少写而已 |
![]() |
7
iyaozhen 6 小时 17 分钟前
@terryso #5 没搞错。Playwright MCP+Claude Code 肯定没问题。这个绝对赞同,我也是用类似的方案,也认为是未来的趋势
但我看你行文都是“使用 YAML 测试之后”、“YAML 革命”等。感觉特别强调 yaml ,个人经验来看这个不太好。应该还是代码为主、yaml 为辅。 再直接一点类似 midscenejs 这种代码形式更好(长期维护角度) ``` await aiAction('逐一点击所有记录。如果某个记录包含文本"completed",则跳过它'); ``` 当然你宣传角度这样是没问题。主要是实际来看,我们团队一批人专职写 UI 自动化都没做的很好,甚至很差。本质还是维护成本高,强调 “写的时候” 低门槛甚至会成为长期维护的阻碍 |
9
terryso OP @iyaozhen 其实 midscenejs 我也用过, 但是
1. 它需要自己提供 API Key, 没法直接利用上我的订阅帐号 2. 我已经测试过通过 AI 分析你的自然语言步骤 + Playwright MCP, 已经完全可以很准确的模拟你想要的手工操作, 没必要再搞代码. 关键是 Playwright MCP 能动态加 ref 的机制, 操作元素异常准确. 3. midscenejs 并没有在实际访问网页的时候, 给网页的所有元素都动态假如 ref, 而是通过大模型分析得到页面元素选择器来操作, 这有时候会不准. playwright mcp 就没这个问题, 它是动态给每个元素加 ref, 操作元素非常准确. 4. 我用 yaml 只是组合步骤, 为了少些重复的步骤而已. 可能文章写得有问题, 重点没搞好. 5. 其实我现在的写法也是类似 await aiAction('逐一点击所有记录。如果某个记录包含文本"completed",则跳过它'); 这样, 只不过连 await aiAction 都省了, 就直接 '逐一点击所有记录。如果某个记录包含文本"completed",则跳过它' 这样而已. |
10
map1e 5 小时 0 分钟前
同在考虑爬虫方向,也遇到了大页面 token 花销太大的问题,想把人工分析页面这块省下来
|