测试工程师用 Claude :它修得了选择器,修不了你的需求理解

测试架构这行有个一直没解决的尴尬:开发一周能写完的功能,QA 写测试要追两周。 你越想把覆盖率补齐,这个口子张得越大。所以当 Claude Code 加上 Playwright 这套东西开始能自己写测试的时候, QA 圈子是真的盯着看。但我想先泼一句:它确实改变了一些事, 但改变的不是你想的那部分。这篇我就把半年用下来, 真省事的、被吹过头的、和压根没动的,分开说清楚。先看 QA 的时间都花哪了第一张图那三个数字,是这事的起点。回归测试吃掉 QA 差不多一半工时; 手写测试用例占了 IT 预算里近 40% 的重复劳动; 团队花在修选择器、改定位器上的时间能占到 sprint 的三到四成。这三件事的共同点很明显——重复、机械、按既定模式走。 凡是有这个特征的活,AI 工具都能啃。这也是为什么 QA 是最早被 AI 编码工具规模化盯上的工种之一,不是因为 QA 简单, 是因为 QA 的工作量里有一大块是已知模式的重复执行。但你注意这张图里没有什么:测试策略、风险评估、 这个版本到底放不放行。这些不在图里,因为这些不是重复劳动, 是判断。判断这部分,后面会说,AI 接不了。考虑到国内订阅Claude确实有点困难参考一下靠谱的网站claudemax.shopPlaywright 那三个 Agent,各管一段现在 QA 用 Claude 的主流方式,不是直接跟 Claude 聊天让它写测试, 而是 Claude Code 配 Playwright 官方那三个内置 Agent。 第二张图画的就是它们的分工。Planner实时探查你的应用,产出一份人能读的 Markdown 测试计划。 注意它的输出是计划不是代码。这一步你应该看一眼—— 它对 UI 结构理解得不错,但经常漏业务规则,因为业务规则不在 DOM 里。Generator把那份 Markdown 计划转成可执行的.spec.ts。 它有个我挺看重的特性:边写边对着运行中的应用验证选择器和断言, 不是凭空编 Playwright 的 API。早期的 AI 测试生成器最烦人的就是 幻觉出一个根本不存在的断言方法,Generator 这点改进是实在的。Healer跑测试套件,挂了就重放失败步骤、看当前 UI、定位等价的新元素、 给个补丁。这个争议最大,单独开一节讲。装这套 Agent 用 Playwright 的init-agents命令:​bash给项目生成三个 Agent 的定义文件npx playwright init-agents --loopclaude​--loop后面跟你用的 AI 工具。具体可选值和 flag 以 playwright.dev/docs/test-agents 的当前文档为准——这个 CLI 还在迭代, 我不想让你抄一个过时的参数。还有一条官方提醒值得记:每次升级 Playwright,这些 Agent 定义都要重新生成一遍, 因为新版会带新的工具和指令。VS Code 里要用这套 agentic 体验,需要 VS Code v1.105 以上 (那个版本去年 10 月 9 号发的),低于这个版本跑不起来。Healer 到底能修什么——这是全文最该看的一张图第三张图是我特意做的,因为自愈测试这个词被用得太飘了。微软自己的基准数据:Healer 在选择器型失败上大概 75% 出头的成功率。 听起来很美。但请把选择器型失败这五个字看清楚。测试失败有好几种。UI 改版了、按钮挪了位置、class 名变了—— 这类是选择器失效,Healer 能修四分之三左右,这是它的主场。但还有几类:等待没设对导致的竞态、真正的逻辑 bug、后端返回的数据变了。 后两类,Healer 基本不碰,成功率个位数。而且这件事你得想明白——逻辑 bug 导致的测试失败, 那个失败本来就是测试在干正事。它失败,是因为你的产品真的坏了。 你要是让 AI 把这种失败修绿,那不叫自愈,那叫掩盖事故。所以 Healer 的准确定位是:它省的是维护工时,不是测试创建, 更不是测试本身的价值判断。行业里有句话我觉得说得对—— 真正从 Agent 受益最大的,是那些原本花三四成 sprint 在修选择器上的团队。 如果你的 UI 很稳定、测试套件也不大,这套东西的搭建和管理成本 可能还不值当。配置上有个细节能省你不少麻烦。playwright.config.ts里:​typescript import { defineConfig } from playwright/test;export default defineConfig({ testDir: ./tests, // 先让 Playwright 自己重试,处理真·flaky,再轮到 Healer retries: 2, // JSON reporter 产出机器可读结果,Agent 能解析 reporter: [ [json, { outputFile: test-results/results.json }], [html], ], use: { baseURL: http://localhost:3000, trace: on-first-retry, }, });​retries: 2这行不是随便加的。它让 Playwright 先自己重试两次, 把真正的偶发性 flaky 过滤掉,再让 Healer 出手。 不加的话,Healer 会跑去修一个其实没坏、只是偶发抖了一下的测试, 越修越乱。JSON reporter 是给 Agent 用的——它要解析结构化结果 才知道哪些挂了、为什么挂。一段能跑的测试,顺便说说它生成的东西长什么样为了不空谈,放一段标准的 Playwright 测试,这是能直接跑的:​typescript import { test, expect } from playwright/test;test(用户用正确密码能登录进 dashboard, async ({ page }) { await page.goto(/login);// 用 role 和 label 定位,不用 CSS class——这是 2026 年的方向 await page.getByLabel(邮箱).fill(userexample.com); await page.getByLabel(密码).fill(correct-password); await page.getByRole(button, { name: 登录 }).click();// 断言跳转和页面内容 await expect(page).toHaveURL(/.*/dashboard/); await expect( page.getByRole(heading, { name: 欢迎回来 }) ).toBeVisible(); });​注意这里用的是getByRole、getByLabel,不是page.locator(.btn-primary)这种 CSS 选择器。这是有讲究的。2026 年 Playwright 测试的方向,是从data-testidcheckout-btn这种死绑 ID, 转向让 Agent 按语义找元素——页面底部那个绿色的、 写着完成购买的主按钮。这跟你叫一个真人 QA点提交按钮是一个道理, 他不会问你要 CSS 选择器,他看一眼页面就知道点哪个。基于 role 的定位天然更稳:你 UI 改版,class 名天天变, 但那个提交表单的按钮这个语义不变。Generator 生成的测试 如果用了一堆硬编码 CSS 选择器,下次部署就脆给你看。这里有个前提坑要说:如果你项目没有 Page Object Model, AI 生成的测试大概率会塞一堆硬编码选择器、内联测试数据、 和不靠谱的等待。解决办法很简单——喂一个你写好的 page object 样例给 Generator 当参考,它会照着你的项目结构来。 上下文这东西,你给多少,它还多少。把它接进 CI:用 CLI,别一上来就上 MCP第四张图讲的是个实操选择。Claude Code 连 Playwright 有两条路: Playwright CLI,或者 Playwright MCP。MCP 的方式是把可访问性树快照、有时候还有截图,传给 AI 让它看页面。 探索式测试、互动调试,这个顺手。但截图非常烧 token, 长会话会明显变慢、变贵。CLI 的方式 token 消耗大概是 MCP 的四分之一。TestDino 给自家产品 搭测试生成管线的时候,对比下来选了 CLI——他们公开的数字是 一段 20 行的 prompt,15 分钟产出 3 个 page object 加一个完整 spec。我的建议:结构化的、批量的测试生成管线,用 CLI; 需要 Claude 看着 UI 互动调试的场景,才上 MCP。别因为 MCP 听起来更高级就默认用它,长会话的账单会教你做人。社区里有个现成的 QA 技能包,neonwatty 那个qa-skills, 覆盖了桌面、移动、多用户流程,装法是:​bash先装 Playwright CLI(全局,一次性)npm install -g playwright/clilatest playwright-cli install再装 qa-skills 这个 Claude Code 技能包claude plugin marketplace add neonwatty/qa-skills claude plugin install qa-skillsneonwatty-qa​它有个/setup-profiles命令我觉得设计得好:它给每个用户角色 开一个有头浏览器,你手动登录(OAuth、2FA 这些它不碰,你自己来), 登录后的会话状态存到.playwright/profiles/。 配置文件.playwright/profiles.json提交进 git, 但登录凭证那些.playwright/profiles/*.json是 gitignore 掉的。这个分法是对的——配置该共享,凭证不该进仓库。 要是哪个工具让你把 storageState 直接 commit,你得警惕。它接得了什么,接不了什么用半年,我把它分三类。它干得好的:从已有代码生成单元测试和测试用例、 用 Playwright CLI 做探索式测试、根据最近代码改动做风险点的回归范围圈定、 给质量留痕(截图、trace 这些证据)。这些活的本质都是 对照已知的东西执行,它不累、不烦、不会因为是第八遍看同样的页面就走神。被吹过头的:自愈测试。Healer 修的是选择器型失败, 75% 那个数字只对这一类成立。把它说成测试套件能自己长期维护、 不用人管,是误导。它能减轻维护负担,做不到无人值守。它接不了的:测试策略——哪些场景值得测、风险在哪、 这个边界情况要不要覆盖。还有最关键的那个判断:这个版本到底能不能上线。这是 QA 这个岗位存在的理由, 也是 AI 给不了的东西。一份测试管理工具的指南里有句话说得很实在: 它是助手,不是替代;测试策略、通过与否的判断、放行的决定, 还是你的。我自己的体感,跟一份有六个月对照数据的项目复盘对得上: 速度提升几乎全来自样板代码——夹具、CI 脚本、page object 骨架。 涉及该怎么测、测到什么程度的判断,速度基本没变, 因为那部分本来就卡在人的脑子里。几条实在建议要我给还没上手的 QA 几条建议:先把 Page Object Model 立起来,再让 AI 生成测试。 没有 POM,它生成的东西就是一堆硬编码选择器,下次部署全脆。playwright.config.ts里retries: 2留着,让真·flaky 先被 重试过滤掉,别让 Healer 去修没坏的测试。生成出来的测试,优先用getByRole、getByLabel这种语义定位, 少用 CSS class 选择器。这不是洁癖,是 UI 一改版你就知道区别。逻辑 bug 导致的测试失败,别让任何 AI 去修绿。 那个失败是测试在报警,你要的是修产品,不是修测试。最后,把 AI 当成一个手很快但需要带的初级 QA。 它能把你从写夹具、补样板里捞出来,让你有时间去想 这个功能真正的风险在哪。这是好事。 但带新人你都知道——你可以让他干活,不能让他替你签放行。 那个名字得是你的。