让测试从“写脚本”走向“沉淀工程能力”

Skill 驱动 自然语言 Playwright让测试从“写脚本”走向“沉淀工程能力”资深测试经理视角当 AI 不再是“随手写个脚本就跑”的玩具而是能理解业务、遵循工程规范、稳定落地的协作者测试团队才能真正摆脱低效维护的泥潭。一、痛点为什么“录制回放”和“一键生成用例”总是烂尾很多团队尝试过用自然语言生成自动化测试告诉 AI “点击编辑按钮修改名称保存”。结果往往是定位器脆弱AI 猜成button:has-text(编辑)但实际 DOM 是a classant-btn编辑/a下个版本就失效。无视工程结构配置、Page Object、登录态、环境变量全部硬编码在生成的临时脚本里。无法复用十个类似页面重复生成十份“野生代码”改一处业务规则要改十个地方。调试困难失败时只有堆栈没有上下文AI 也说不清当初为什么那样写。问题的本质不是 AI 能力不够而是缺少了一层“Skill技能包”来约束 AI 的行为边界与输出质量。二、核心理念Skill 驱动 自然语言 Playwright我们把整个工作流拆成三个角色角色职责产出自然语言测试人员说出业务意图“验证编辑按钮能正确打开抽屉并回显数据”Skill技能包沉淀交互规范、模板话术、工程约束、脚手架Page Object 模板、配置规范、多端开关策略、断言清单Playwright稳定执行 跨浏览器 追踪 报告可运行的 spec.ts、trace、html reportSkill 不是代码而是“元规范”——它告诉 Agent测什么范围怎么问交互模板怎么落到仓库文件结构、命名约定、登录态注入方式怎么打包校验lint、类型、并行策略Agent 在 Skill 的引导下将自然语言拆解成Page Object 定义 → 配置注入 → spec 用例 → 执行命令整个过程不再是“一次性推理”而是可重复的工程流水线。三、Skill 与 Playwright 的分工边界层级职责典型内容Skill交互流程、模板话术、列表/表单/弹窗等通用模块、用例脚手架、打包校验规则“所有弹窗统一用getByRole(dialog)等待”“编辑按钮若为a则改用getByRole(link)”“环境变量统一从.env读取”Playwright浏览器自动化、项目结构、CI 集成、trace/view trace、报告生成playwright.config.ts、fixtures、global-setup、yarn test、npx playwright show-trace简单说Skill 定规则Playwright 落执行。没有 SkillAI 只会写松散脚本没有 PlaywrightSkill 只是纸上谈兵。四、完整操作流程从自然语言到持续回归以下是一个典型“Skill 驱动 自然语言 Playwright”的闭环步骤步骤 1定义 Skill 库管理者/资深 QA 做一次在项目仓库中创建.playwright/skills/目录每个 Skill 是一个 Markdown 脚本片段。例如modal.skill.md# 弹窗/抽屉交互规范 - 识别弹窗类型Modal → roledialogDrawer → class 含 .ant-drawer - 定位器优先级getByRole getByTestId getByText - 关闭弹窗点击关闭图标或取消按钮勿用空白区域 close - 断言弹窗打开时 body 应有 aria-hidden 或对应 title 可见 - 代码模板见 templates/modal.spec.hbs步骤 2自然语言触发测试人员/业务人员在编辑器如 VSCode Copilot Chat / Cursor中直接写skill:crud 「编辑」按钮位于用户列表每一行的最后一列。点击后应打开一个抽屉(Drawer)标题为“编辑用户”并回显当前行的用户名和邮箱。修改用户名后点击保存表格应更新该行数据。使用 Playwright 生成测试。步骤 3Agent 按 Skill 解析并生成工程代码Agent 会从 Skill 库加载button.skill处理链接/按钮、drawer.skill、table.skill、crud.skill。生成 Page Object// pages/UserListPage.tsexportclassUserListPage{constructor(privatepage:Page){}getEditLink(rowText:string){returnthis.page.getByRole(link,{name:编辑}).first();// Skill 强制用 rolelink}getDrawer(){returnthis.page.locator(.ant-drawer);}asyncwaitForDrawerTitle(title:string){awaitthis.getDrawer().getByText(title,{exact:true}).waitFor();}}生成 spec 文件并自动注入登录态global-setup、使用环境变量BASE_URL。生成.env.example并提示填写。步骤 4执行与调试运行npm run test:editSkill 预定义的快捷脚本Playwright 执行用例自动录 trace 和截图。若失败Agent 读取 trace 并分析“定位到getByRole(button)未找到元素实际上 DOM 为a建议改为getByRole(link)”。工程师确认后Agent 自动修正 Page Object 并重新运行。步骤 5沉淀与复用修正后的定位方式回写进 Skill如button.skill新增规则“Ant Design 按钮若实际渲染为链接从 Button 组件改为 Link 组件时应同时匹配两种角色”。下次其他模块遇到同类 AntD 链接按钮Agent 直接选用正确定位器。五、实战案例“编辑”按钮的踩坑与修正背景一个 Ant Design 后台系统用户列表每行有一个“编辑”按钮点击后右侧滑出抽屉(Drawer)。测试人员用自然语言要求自动化。传统做法的痛苦流程30 分钟起步录制回放得到click .ant-btn:last-child→ 下个版本样式调整失败。手动改定位器发现 DOM 是a classant-btn尝试getByRole(button)找不到查文档、试getByText可能匹配多行。侧栏弹层等不到.ant-modal-title因为它是 Drawer 不是 Modal加sleep(2)不稳定换waitForSelector反复试。环境变量、登录态在多个文件散落换到 CI 又报错。Web 版和 H5 版两套脚本复制修改维护成本翻倍。Skill Playwright 的解决过程5 分钟闭环Step 1 - 自然语言触发skill:antd-table skill:drawer 测试编辑用户Step 2 - Agent 读取 DOM 结构Agent 调用 Playwright 的page.pause()或pickLocator能力实际 inspect 页面发现编辑元素a rolelink classant-btn编辑/a→不是 button。弹层 class.ant-drawer标题在.ant-drawer-title→不是 Modal。Step 3 - Agent 输出可执行方案Agent 在生成的代码中自动使用page.getByRole(link, { name: 编辑 })等待抽屉page.locator(.ant-drawer).getByText(编辑用户).waitFor()Step 4 - 执行一次成功Playwright 运行用例trace 录下整个过程。工程师确认通过。Step 5 - 反向沉淀到 SkillAgent 向工程师提问“发现当前页面使用了 Drawer 和 Link 按钮是否将这条规则加入团队的antd.skill中” 确认后Skill 更新此后所有类似场景优先匹配rolelink和.ant-drawer。对比结果传统方法30 分钟试错 下次同类问题重试。Skill Playwright5 分钟一次性解决 永久沉淀团队能力。六、落地 Skill 驱动的关键工程约束要避免 AI 生成“飘忽不定”的用例Skill 必须强制以下四点1. 配置集中化禁止在 spec 中写死 URL、账号、超时。Skill 强制BASE_URL取自.env或playwright.config登录态通过global-setup.ts复用不每次登录多端Web/H5通过环境变量TEST_TARGETweb|mobile切换而非if散落2. 分层强制Skill 模板要求specs/只描述“做什么”Given/When/Thenpages/封装定位器与交互fixtures/管理数据与请求 Mockutils/处理通用逻辑如等待条件3. 定位器优先级规则Skill 硬性规定getByRolegetByTestIdgetByText加 exact locator避免 CSS 类依赖并且给出反例禁止xpath、禁止动态id、禁止依赖nth-child4. 必须附带 trace / video 配置每个 Skill 生成的playwright.config.ts必须开启trace: on-first-retry和video: on保证失败时可回放 Agent 分析。七、总结从“AI 写脚本”到“团队沉淀可演进的能力”Skill 驱动 自然语言 Playwright 不是简单地把“生成脚本”这个动作自动化而是让不可靠的 AI 猜测变成遵循团队规范的可信产出让一次踩坑的经验变成永久有效的 Skill 规则让测试代码像产品代码一样有架构、有配置、有复用作为测试经理你不再需要反复 review 每个人生成的“野脚本”只需要维护好 Skill 库。新人一句自然语言就能产出符合团队标准、可调试、可继承的 Playwright 用例。从此测试自动化的核心矛盾从“写不出来”变成了“规则好不好”——这才是 AI 测试的正确演进方向。