AI + Playwright 自动化测试，为什么很多人卡在第一条可运行脚本？

最近很多测试、前端、全栈同学都在尝试一件事：

把需求丢给 AI，让它直接生成 Playwright 自动化测试脚本。

听起来很顺。

尤其是后台系统、管理端、ERP、HR SaaS、内部 OA、审批系统这类项目，页面结构相对稳定，业务路径也比较清晰，理论上很适合用 AI 批量补 UI 自动化。

但真正动手后，问题很快就来了。

不是 Playwright 不好用。

也不是 AI 完全不会写代码。

真正卡住大多数人的，是不知道怎么把测试场景讲清楚。

很多人给 AI 的提示词只有一句：

帮我写一个 Playwright 自动化测试。

这句话太空了。

AI 只能猜页面结构，猜按钮文案，猜登录方式，猜断言点，最后生成出来的代码看着像那么回事，实际一跑就报错。

后台系统自动化的难点，从来不只是“点一个按钮”。

它真正考验的是：

页面怎么进、登录态怎么复用、元素怎么定位、弹窗怎么处理、异步怎么等待、失败怎么断言、测试数据怎么清理、脚本怎么接入 CI。

AI 生成脚本的上限，不取决于模型多聪明，而取决于你把测试场景描述到什么颗粒度。

这也是为什么，同样是用 ChatGPT、Codex 或其他 AI 编程工具，有的人能快速生成一批可维护脚本，有的人只能得到一堆不可运行的示例代码。

目录

1. AI 会写 Playwright 了，但很多团队还是补不动 UI 自动化
2. 问题不在工具，而在测试场景没有被工程化描述
3. 一条高质量 Playwright 提示词，应该包含哪些关键信息
4. 企业后台常见场景，可以直接复用哪些模板
5. 光有提示词还不够，还要有工程落地规范
6. 把提示词沉淀成资产，才是自动化测试提效的关键
7. 未来的测试工程师，拼的是“会不会指挥 AI 干活”

一、AI 会写 Playwright 了，但很多团队还是补不动 UI 自动化

很多公司都有类似的系统：

管理后台、订单系统、CRM、ERP、HR SaaS、财务结算平台、内部 OA、审批系统、数据报表系统。

这些系统有一个共同特点：

页面不算复杂，但数量很多。

大部分页面都是列表、查询、表单、弹窗、详情、导入、导出、权限控制。

从自动化测试角度看，这类系统非常适合 Playwright。

因为 Playwright 对现代 Web 应用支持比较完整，可以处理登录、跳转、新标签页、弹窗、文件上传下载、网络请求等待等场景。比如下载场景中，Playwright 可以在点击前监听 download 事件，再获取下载文件；网络场景中，也可以监听、修改或 mock 页面请求。([Playwright][5])

但很多团队做不起来。

原因很现实。

页面太多，手写脚本成本高。

业务变化快，脚本容易坏。

测试同学不一定熟悉前端结构。

前端同学不一定知道怎么设计测试断言。

AI 出现后，大家以为问题会被解决。

实际情况是，AI 只是降低了写代码的门槛，但没有自动补齐测试设计能力。

你让 AI 写“登录测试”，它会给你一段登录代码。

但它不知道你的系统有没有验证码。

不知道登录后是跳首页、工作台，还是保留原路径。

不知道用户名输入框是 placeholder、label，还是自定义组件。

不知道登录成功后应该校验菜单、头像、权限，还是接口返回状态。

所以很多脚本最后变成这样：

能看，不能跑。

能跑一次，不能稳定跑。

今天能跑，明天页面一改就全挂。

UI 自动化不是把人工操作翻译成代码，而是把业务路径、页面状态和断言规则固化成工程资产。

二、问题不在工具，而在测试场景没有被工程化描述

很多人第一次用 AI 生成 Playwright 脚本，会踩一个坑：

只描述“做什么”，不描述“怎么验”。

比如：

帮我写新增用户的自动化。

这句话对人来说能理解。

但对 AI 来说，信息严重不足。

它至少需要知道：

页面地址是什么？

是否需要登录？

新增按钮叫什么？

弹窗还是抽屉？

字段有哪些？

哪些字段必填？

提交成功提示是什么？

提交后数据在哪里校验？

是否需要清理测试数据？

失败提示怎么判断？

是否有二次确认？

是否会请求后端接口？

这些信息不补齐，AI 只能靠猜。

而企业后台最怕的就是“猜”。

因为后台系统里有大量定制组件。

同样是输入框，可能是普通 input，也可能是 Select、TreeSelect、Cascader、DatePicker、AutoComplete。

同样是提交成功，可能是 toast，也可能是弹窗关闭，也可能是列表刷新，也可能是状态变更。

同样是详情页，可能当前页跳转，也可能新开标签页，还可能右侧抽屉打开。

所以，真正有价值的提示词，不是“让 AI 写代码”。

而是把测试场景拆成稳定的工程输入。

这也是 Playwright 提示词模板的价值。

它不是为了让 AI 随便写一段代码。

而是让 AI 按照测试工程师的思路写代码。

三、一条高质量 Playwright 提示词，应该包含哪些关键信息

很多低质量提示词都有一个共同问题：

太像需求口述，不像工程输入。

比如：

帮我测一下订单列表。

这句话缺少上下文。

换成工程化描述，应该变成：

帮我为订单列表页面生成 Playwright 测试脚本。页面路径是 xxx。需要复用登录态。进入页面后校验标题、查询区域、表格、分页。输入订单号后点击查询。等待 loading 消失。结果有数据时校验表格第一行包含订单号；无数据时校验空状态文案。代码使用 JavaScript，选择器优先使用 getByRole、getByText、getByPlaceholder，不要使用超长 CSS。未知选择器用 TODO 标记。

差别很大。

前者让 AI 猜。

后者让 AI 执行。

Playwright 官方也推荐优先使用贴近用户感知的定位方式，例如 getByRole，并且通常要带上可访问名称来精准定位元素。Locator 也是 Playwright 自动等待和重试机制的核心。([Playwright][2])

一条高质量 Playwright 提示词，至少要包含 10 类信息。

核心不复杂。

把“我要测什么”变成“AI 可以执行什么”。

把“页面应该正常”变成“哪些元素出现才叫正常”。

把“登录成功”变成“URL 变化、菜单可见、头像可见、无错误提示”。

把“查询成功”变成“loading 消失、表格有数据或空状态正常、分页正常、无请求失败提示”。

好的自动化脚本，不是代码写得多，而是断言点选得准。

四、企业后台常见场景，可以直接复用哪些模板

下面这套模板，适合刚开始接触 Playwright 的前端、测试、全栈开发。

也适合手里有后台系统、管理端、ERP、HR SaaS、内部 OA，需要批量补 UI 自动化的人。

使用方式很简单：

把占位符替换成你系统里的真实信息。

再把提示词喂给 ChatGPT、Codex 或其他 AI 编程工具。

统一占位符说明

{{BASE_URL}}              网站地址
{{LOGIN_PATH}}            登录页路径
{{PAGE_PATH}}             业务页面路径
{{PAGE_NAME}}             页面名称

{{USERNAME_ENV}}          用户名环境变量名
{{PASSWORD_ENV}}          密码环境变量名
{{USERNAME_INPUT_HINT}}   用户名输入框提示词
{{PASSWORD_INPUT_HINT}}   密码输入框提示词
{{LOGIN_BUTTON_TEXT}}     登录按钮文字

{{BUTTON_TEXT}}           按钮文字
{{KEYWORD}}               查询关键字
{{SEARCH_INPUT_HINT}}     查询输入框提示词
{{SEARCH_BUTTON_TEXT}}    查询按钮文字

{{FORM_FIELD_NAME}}       表单字段名
{{SUCCESS_TEXT}}          成功提示语
{{CREATE_BUTTON_TEXT}}    新增按钮文字
{{DIALOG_TITLE}}          弹窗标题
{{SUBMIT_BUTTON_TEXT}}    提交按钮文字

{{DETAIL_TARGET_TEXT}}    详情目标文本
{{EDIT_BUTTON_TEXT}}      编辑按钮文字
{{DELETE_BUTTON_TEXT}}    删除按钮文字
{{CONFIRM_BUTTON_TEXT}}   确认按钮文字

{{UPLOAD_BUTTON_TEXT}}    上传按钮文字
{{EXPORT_BUTTON_TEXT}}    导出按钮文字
{{IMPORT_BUTTON_TEXT}}    导入按钮文字

{{MENU_TEXT}}             菜单名称
{{ROLE_NAME}}             角色名称
{{ERROR_TEXT}}            错误提示语

提示词 1：万能母版

适合先生成一个完整骨架。

你现在是一个资深 Playwright 自动化测试工程师。

请帮我为网站 {{BASE_URL}} 生成一个可直接运行的 Playwright 测试 demo，使用 JavaScript 编写。

要求如下：

1. 如果当前仓库已经有 Playwright 项目，请复用现有配置；如果没有，请补齐最小可运行项目结构。
2. 测试代码写成一个完整的 spec 文件，文件名清晰，例如 tests/{{PAGE_NAME}}.spec.js。
3. 所有关键步骤都加中文注释，方便阅读和二次修改。
4. 优先使用稳定定位方式：getByRole、getByLabel、getByPlaceholder、getByText、getByTestId。
5. 不要优先使用容易失效的超长 CSS 路径和 nth-child。
6. 增加基础断言：页面标题正常、URL 正常、核心元素可见、无明显报错文案、主要内容区域渲染成功。
7. 如果页面可能新开标签页，请兼容当前页跳转和 popup 两种情况。
8. 如果网站需要登录，请使用 .env 或 process.env 读取账号密码，不要把真实密码写死在代码里。
9. 如果需要复用登录态，可以生成 storageState，但要提醒我把登录态文件加入 .gitignore。
10. 如果你无法真实访问该网站，也请先生成可运行模板，把需要我替换的选择器和文本集中标记成 TODO。
11. 最后告诉我运行命令，例如 npm test、npm run test:headed、npx playwright show-report。
12. 不要只给思路，要直接给完整代码。

业务目标：

- 网站：{{BASE_URL}}
- 页面：{{PAGE_NAME}}
- 核心动作：打开页面、执行操作、检查页面显示是否正常
- 需要覆盖：登录、查询、表单、弹窗、结果校验

提示词 2：登录流程模板

登录脚本是后台自动化的地基。

这个模板重点解决账号密码不能写死、验证码不能瞎编、登录态需要复用的问题。

请帮我为公司内部网站 {{BASE_URL}} 编写一个 Playwright 登录流程测试，使用 JavaScript，直接输出完整可运行代码。

登录信息要求：

- 登录页：{{LOGIN_PATH}}
- 用户名从 process.env.{{USERNAME_ENV}} 读取
- 密码从 process.env.{{PASSWORD_ENV}} 读取
- 用户名输入框关键词：{{USERNAME_INPUT_HINT}}
- 密码输入框关键词：{{PASSWORD_INPUT_HINT}}
- 登录按钮文字：{{LOGIN_BUTTON_TEXT}}

测试步骤要求：

1. 打开登录页并等待页面加载完成。
2. 校验登录页标题、Logo、登录表单是否正常显示。
3. 输入用户名和密码，点击登录按钮。
4. 如果页面有验证码、短信码、二次确认，请在代码里预留 TODO 注释，不要瞎编。
5. 登录成功后断言：URL 发生变化、首页/工作台/菜单栏可见、当前用户名或头像可见。
6. 额外校验页面没有“账号或密码错误”“系统异常”“请求失败”等明显错误提示。
7. 如果登录成功，保存 storageState，方便后续测试复用登录态。
8. storageState 文件可能包含 cookie/token，请提醒我加入 .gitignore，不要提交到代码仓库。
9. 关键代码必须加中文注释。
10. 如果实际选择器未知，请给我一个带占位符的模板版本，并把需要我替换的地方写清楚。

提示词 3：查询 / 搜索 / 结果校验模板

后台系统最常见的页面，就是列表查询。

这个模板重点处理有数据、无数据、loading、分页、重置几类情况。

请帮我为网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面编写一个 Playwright 查询测试，直接输出完整可运行代码。

页面信息：

- 页面地址：{{PAGE_PATH}}
- 查询输入框提示词或标签：{{SEARCH_INPUT_HINT}}
- 查询按钮文字：{{SEARCH_BUTTON_TEXT}}
- 查询关键字：{{KEYWORD}}

测试步骤要求：

1. 进入 {{PAGE_NAME}} 页面，检查页面标题、面包屑、查询区域是否正常显示。
2. 在搜索框中输入 {{KEYWORD}}，必要时再选择下拉框、日期、状态筛选项。
3. 点击“{{SEARCH_BUTTON_TEXT}}”按钮。
4. 等待 loading 消失，再校验结果区域是否正常渲染。
5. 不要使用固定 sleep，优先等待元素状态、接口响应或 loading 消失。
6. 结果可能有两种情况：有数据时表格/列表至少有一条记录；无数据时空状态文案正常显示。
7. 校验结果中的关键列、关键文本、分页、总数、无报错提示是否正常。
8. 如有“重置”按钮，顺便写一个重置查询条件并恢复默认状态的断言。
9. 代码里加中文注释，选择器尽量稳健。
10. 不要只给伪代码，请直接输出完整 spec 文件。

提示词 4：表单新增 + 弹窗模板

企业后台大量操作都发生在弹窗或抽屉里。

新增场景不能只测“点提交”，还要关注必填校验、成功提示、列表回显。

请帮我为网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面生成一个 Playwright 自动化脚本，场景是“点击新增按钮，打开弹窗/抽屉，填写表单并提交”。

页面信息：

- 页面地址：{{PAGE_PATH}}
- 新增按钮文字：{{CREATE_BUTTON_TEXT}}
- 弹窗标题：{{DIALOG_TITLE}}
- 需要填写的字段：{{FORM_FIELD_NAME_1}}、{{FORM_FIELD_NAME_2}}、{{FORM_FIELD_NAME_3}}
- 提交按钮文字：{{SUBMIT_BUTTON_TEXT}}
- 成功提示语：{{SUCCESS_TEXT}}

测试步骤要求：

1. 进入页面后，先校验列表区域和“{{CREATE_BUTTON_TEXT}}”按钮可见。
2. 点击新增按钮，断言弹窗或抽屉成功打开，标题为“{{DIALOG_TITLE}}”。
3. 填写表单，文本框、下拉框、日期、单选框、复选框都请按常规 Playwright 写法处理。
4. 提交前增加必填项校验。
5. 提交后等待成功提示“{{SUCCESS_TEXT}}”出现。
6. 断言弹窗关闭或状态恢复正常。
7. 回到列表页后，校验新建的数据出现在表格/列表中。
8. 如果页面会弹出二次确认框，请一并处理并校验按钮点击后的结果。
9. 如果新增数据会污染环境，请预留 afterEach 清理逻辑或 TODO 注释。
10. 整个脚本必须带中文注释，并尽量写成我只替换字段名和按钮名就能复用的模板。

提示词 5：列表页 + 详情页 + 返回模板

详情页容易出现两类问题：

一种是跳转后页面白屏。

另一种是返回列表后状态丢失。

这个模板适合验证完整浏览路径。

请帮我写一个 Playwright 测试，验证网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面，从列表进入详情，再返回列表的完整流程。

要求：

1. 打开 {{PAGE_PATH}} 页面并确认列表加载完成。
2. 点击第一条记录或指定文本“{{DETAIL_TARGET_TEXT}}”进入详情页。
3. 同时兼容当前页跳转和新标签页打开两种情况。
4. 在详情页校验：标题、编号、状态、正文区域、操作按钮是否显示正常。
5. 执行一个轻量交互，例如展开更多信息、打开预览弹窗、切换标签页。
6. 返回列表页后，再次确认列表仍然正常显示，没有白屏、报错、空白数据。
7. 如果列表页有查询条件或分页状态，请校验返回后状态是否保留。
8. 代码直接给完整版本，包含中文注释和必要断言。

提示词 6：编辑流程模板

编辑不是简单复用新增。

编辑要关注数据回填、修改保存、列表同步。

请帮我为网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面生成一个 Playwright 编辑流程测试，使用 JavaScript，输出完整可运行代码。

页面信息：

- 页面地址：{{PAGE_PATH}}
- 目标数据文本：{{DETAIL_TARGET_TEXT}}
- 编辑按钮文字：{{EDIT_BUTTON_TEXT}}
- 弹窗或抽屉标题：{{DIALOG_TITLE}}
- 需要修改的字段：{{FORM_FIELD_NAME}}
- 提交按钮文字：{{SUBMIT_BUTTON_TEXT}}
- 成功提示语：{{SUCCESS_TEXT}}

测试步骤要求：

1. 进入页面并等待列表加载完成。
2. 查找包含“{{DETAIL_TARGET_TEXT}}”的目标记录。
3. 点击该记录对应的“{{EDIT_BUTTON_TEXT}}”按钮。
4. 校验编辑弹窗或抽屉打开，并确认原始数据已正确回填。
5. 修改字段“{{FORM_FIELD_NAME}}”的值。
6. 点击“{{SUBMIT_BUTTON_TEXT}}”提交。
7. 等待成功提示“{{SUCCESS_TEXT}}”。
8. 校验弹窗关闭，列表刷新后展示修改后的内容。
9. 如果没有找到目标数据，请在代码中预留 TODO，提示需要先创建测试数据。
10. 代码必须包含中文注释、稳定选择器、必要断言。

提示词 7：删除 + 二次确认模板

删除场景不能只测按钮。

要重点验证二次确认、取消删除、确认删除、列表状态变化。

请帮我为网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面生成一个 Playwright 删除流程测试，使用 JavaScript，直接输出完整可运行代码。

页面信息：

- 页面地址：{{PAGE_PATH}}
- 目标数据文本：{{DETAIL_TARGET_TEXT}}
- 删除按钮文字：{{DELETE_BUTTON_TEXT}}
- 确认按钮文字：{{CONFIRM_BUTTON_TEXT}}
- 成功提示语：{{SUCCESS_TEXT}}

测试步骤要求：

1. 进入页面并等待列表加载完成。
2. 定位包含“{{DETAIL_TARGET_TEXT}}”的目标记录。
3. 点击目标记录对应的“{{DELETE_BUTTON_TEXT}}”按钮。
4. 校验二次确认弹窗正常出现。
5. 先覆盖一次“取消删除”场景，确认数据仍然存在。
6. 再次点击删除，并点击“{{CONFIRM_BUTTON_TEXT}}”确认。
7. 等待成功提示“{{SUCCESS_TEXT}}”。
8. 校验目标数据不再出现在当前列表中。
9. 如果删除后数据进入回收站或状态变更，请在代码中预留 TODO 注释。
10. 如果当前环境不允许真实删除，请改成 mock 或测试环境专用数据。
11. 代码必须加中文注释，选择器尽量使用 getByRole、getByText、locator 组合。

提示词 8：分页 / 排序 / 表格列校验模板

很多后台系统的核心信息都在表格里。

表格测试不能只判断“表格出现了”。

还要判断列、行、分页、排序是否正常。

请帮我为网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面编写一个 Playwright 表格校验测试，使用 JavaScript，输出完整代码。

页面信息：

- 页面地址：{{PAGE_PATH}}
- 表格关键列：{{TABLE_COLUMN_1}}、{{TABLE_COLUMN_2}}、{{TABLE_COLUMN_3}}
- 排序列：{{SORT_COLUMN}}
- 分页文案或分页区域关键词：{{PAGINATION_TEXT}}

测试步骤要求：

1. 打开页面并等待表格加载完成。
2. 校验表格标题、表头、关键列是否显示。
3. 校验表格至少存在一行数据；如果无数据，则校验空状态正常。
4. 如果存在分页，点击下一页并校验页码变化或数据刷新。
5. 如果存在排序列，点击排序并校验排序图标或数据顺序变化。
6. 校验页面没有“请求失败”“系统异常”“加载失败”等错误提示。
7. 对 loading 状态做等待处理，不要使用固定 sleep。
8. 输出完整 spec 文件，并添加中文注释。

提示词 9：文件上传模板

上传场景最容易被忽略。

尤其是内部系统里的 Excel、CSV、图片、附件上传。

请帮我为网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面生成一个 Playwright 文件上传测试，使用 JavaScript，输出完整可运行代码。

页面信息：

- 页面地址：{{PAGE_PATH}}
- 上传按钮文字：{{UPLOAD_BUTTON_TEXT}}
- 上传文件路径：{{UPLOAD_FILE_PATH}}
- 成功提示语：{{SUCCESS_TEXT}}

测试步骤要求：

1. 进入页面并校验上传区域或上传按钮可见。
2. 点击“{{UPLOAD_BUTTON_TEXT}}”或直接定位 input[type=file]。
3. 使用 Playwright 的 setInputFiles 上传 {{UPLOAD_FILE_PATH}}。
4. 校验文件名在页面上显示。
5. 如果上传后需要点击提交按钮，请预留 {{SUBMIT_BUTTON_TEXT}}。
6. 等待上传成功提示“{{SUCCESS_TEXT}}”。
7. 校验页面没有格式错误、大小超限、上传失败等提示。
8. 如果系统限制文件类型，请在代码中预留 TODO，用于补充异常文件上传测试。
9. 代码必须包含中文注释和必要断言。

提示词 10：导入 / 导出模板

导入导出是后台系统高频功能。

这类脚本重点不在 UI 点击，而在下载事件、文件名、提示语、导入结果。

请帮我为网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面生成一个 Playwright 导入导出测试，使用 JavaScript，输出完整代码。

页面信息：

- 页面地址：{{PAGE_PATH}}
- 导入按钮文字：{{IMPORT_BUTTON_TEXT}}
- 导出按钮文字：{{EXPORT_BUTTON_TEXT}}
- 导入文件路径：{{IMPORT_FILE_PATH}}
- 成功提示语：{{SUCCESS_TEXT}}

测试步骤要求：

1. 进入页面并确认列表区域加载完成。
2. 点击“{{EXPORT_BUTTON_TEXT}}”前，先监听 download 事件。
3. 校验下载文件成功生成，文件名或扩展名符合预期。
4. 点击“{{IMPORT_BUTTON_TEXT}}”，选择 {{IMPORT_FILE_PATH}} 文件。
5. 如果有导入确认弹窗，请完成确认操作。
6. 等待导入成功提示“{{SUCCESS_TEXT}}”。
7. 校验导入结果区域、成功条数、失败条数或错误明细是否正常显示。
8. 如果导入是异步任务，请预留轮询任务状态的 TODO。
9. 不要使用固定等待时间，优先等待事件、接口响应或页面状态变化。
10. 输出完整 spec 文件，带中文注释。

提示词 11：菜单权限 / 角色权限模板

权限测试是企业后台很重要的一类场景。

它不是只看按钮在不在，而是验证“看得到、点得动、不能越权”。

请帮我为网站 {{BASE_URL}} 生成一个 Playwright 权限校验测试，使用 JavaScript，输出完整代码。

权限信息：

- 角色名称：{{ROLE_NAME}}
- 登录账号环境变量：process.env.{{USERNAME_ENV}}
- 登录密码环境变量：process.env.{{PASSWORD_ENV}}
- 需要访问的菜单：{{MENU_TEXT}}
- 业务页面地址：{{PAGE_PATH}}
- 不应该出现的按钮或菜单：{{FORBIDDEN_TEXT}}

测试步骤要求：

1. 使用指定角色账号登录系统。
2. 登录成功后校验当前用户信息或角色信息。
3. 校验菜单“{{MENU_TEXT}}”是否可见，并能正常进入页面。
4. 进入页面后校验该角色可见的按钮、列表、查询区域。
5. 校验不应出现的按钮或菜单“{{FORBIDDEN_TEXT}}”不可见。
6. 如果直接访问无权限页面地址，应校验 403、无权限提示或自动跳转。
7. 校验页面没有白屏、接口异常、权限绕过等明显问题。
8. 代码必须加中文注释，并把角色账号、密码通过环境变量读取。

提示词 12：异常提示 / 表单校验模板

只测成功路径，自动化价值会很有限。

企业后台更需要验证错误提示是否准确。

请帮我为网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面生成一个 Playwright 异常校验测试，使用 JavaScript，输出完整代码。

页面信息：

- 页面地址：{{PAGE_PATH}}
- 操作按钮文字：{{BUTTON_TEXT}}
- 表单字段：{{FORM_FIELD_NAME}}
- 预期错误提示：{{ERROR_TEXT}}

测试步骤要求：

1. 进入页面并打开目标表单或操作区域。
2. 不填写必填项，直接点击“{{BUTTON_TEXT}}”。
3. 校验必填提示是否出现。
4. 输入非法格式数据，例如过长文本、特殊字符、错误日期、错误金额。
5. 校验页面展示“{{ERROR_TEXT}}”或对应字段错误提示。
6. 修正为合法数据后，再次提交并校验错误提示消失。
7. 不要让测试数据污染线上环境，如有必要请加 TODO 标记。
8. 代码必须包含中文注释、稳定选择器、清晰断言。

提示词 13：网络请求监听 / 接口断言模板

UI 自动化不能完全只看页面。

很多问题发生在接口层。

Playwright 可以同时做页面断言和接口响应断言。它支持监听、处理和修改浏览器发出的网络请求，也可以通过 waitForResponse 这类能力等待指定接口响应。([Playwright][6])

请帮我为网站 {{BASE_URL}} 的 {{PAGE_NAME}} 页面生成一个 Playwright 网络请求监听测试，使用 JavaScript，输出完整可运行代码。

页面信息：

- 页面地址：{{PAGE_PATH}}
- 触发操作按钮：{{BUTTON_TEXT}}
- 目标接口关键词：{{API_KEYWORD}}
- 成功提示语：{{SUCCESS_TEXT}}

测试步骤要求：

1. 进入页面并等待页面加载完成。
2. 在点击“{{BUTTON_TEXT}}”前，使用 page.waitForResponse 监听包含 {{API_KEYWORD}} 的接口。
3. 点击按钮触发请求。
4. 校验接口响应状态码为 200 或业务成功状态。
5. 校验页面出现“{{SUCCESS_TEXT}}”。
6. 如果接口失败，要校验页面是否出现合理错误提示，而不是白屏或无反馈。
7. 代码中不要写死完整接口地址，优先使用关键词匹配。
8. 输出完整代码，并添加中文注释。

提示词 14：测试数据准备 / 清理模板

企业后台自动化最容易翻车的地方，不是按钮定位。

而是测试数据。

没有数据，脚本跑不起来。

数据重复，脚本跑不稳定。

数据不清理，环境越跑越脏。

请帮我为 Playwright 自动化测试生成一套测试数据准备和清理方案，使用 JavaScript。

业务场景：

- 页面：{{PAGE_NAME}}
- 测试对象：{{DATA_OBJECT_NAME}}
- 创建数据接口关键词：{{CREATE_API_KEYWORD}}
- 删除数据接口关键词：{{DELETE_API_KEYWORD}}
- 页面地址：{{PAGE_PATH}}

要求：

1. 使用 beforeEach 或独立 helper 准备测试数据。
2. 优先通过 API 创建测试数据，不要完全依赖 UI 新增。
3. 每条测试数据都加唯一标识，例如 e2e_时间戳_随机数。
4. 测试结束后使用 afterEach 清理数据。
5. 如果清理失败，要输出明确日志，方便排查。
6. 不要操作生产环境真实数据。
7. 如果接口信息未知，请用 TODO 标记需要补充的接口地址、参数和鉴权方式。
8. 输出完整示例代码，并说明如何在 spec 文件中复用。

提示词 15：CI / Trace / 失败截图模板

脚本本地能跑，不代表团队能用。

真正落地时，必须接入 CI。

Playwright 支持 retries 配置，失败用例可以重试；Trace Viewer 可以回放测试过程，适合定位 CI 中偶发失败问题。([Playwright][7])

请帮我为现有 Playwright 项目补充 CI 执行配置和失败诊断能力。

要求：

1. 生成 playwright.config.js 配置示例。
2. 配置 baseURL、storageState、trace、screenshot、video、retries。
3. CI 环境下开启 trace: 'on-first-retry'。
4. 失败时保留截图、视频、trace 文件。
5. 生成 npm scripts，例如 test、test:headed、test:debug、test:report。
6. 如果使用 GitHub Actions 或 Jenkins，请给出对应配置示例。
7. 不要把账号密码写死在配置文件里，统一从环境变量读取。
8. 最后说明失败后如何查看 HTML report 和 trace。

提示词 16：Playwright 脚本重构成 Page Object 模板

脚本多了以后，最大问题不是能不能写出来。

而是能不能维护。

这时就需要把重复逻辑抽成 Page Object。

请帮我把下面这个 Playwright 测试脚本重构成 Page Object 模式，使用 JavaScript。

重构要求：

1. 保留原有测试逻辑和断言，不要改变业务行为。
2. 把页面操作封装到 pages/{{PAGE_NAME}}Page.js。
3. 把测试用例保留在 tests/{{PAGE_NAME}}.spec.js。
4. 登录逻辑如果重复，请抽成独立 helper 或复用 storageState。
5. Page Object 中的方法命名要清晰，例如 gotoPage、searchByKeyword、openCreateDialog、submitForm。
6. 所有关键方法添加中文注释。
7. 选择器集中管理，不要散落在测试用例里。
8. 如果发现原脚本里有不稳定等待、超长 CSS、硬编码账号密码，请顺手优化。
9. 最后输出重构后的完整文件结构和每个文件代码。

原始脚本如下：

{{PASTE_YOUR_CODE}}

五、光有提示词还不够，还要有工程落地规范

很多人拿到提示词之后，会马上开始批量生成脚本。

这个动作没错。

但如果没有工程规范，脚本很快会变成另一种负担。

页面一改，脚本全挂。

测试数据重复，脚本不稳定。

登录态过期，整批用例失败。

失败日志看不懂，只能重新跑。

这些问题不是 AI 能自动解决的。

需要测试开发把底层规则先定好。

1. 选择器规范：不要把页面结构写死

后台系统最常见的问题，是使用超长 CSS 选择器。

比如：

#app > div > div:nth-child(2) > div > div > table > tr:nth-child(1)

这种选择器看起来精准，实际非常脆。

页面布局一变，脚本就挂。

更推荐的优先级是：

getByRole
getByLabel
getByPlaceholder
getByText
getByTestId
locator + filter
短 CSS

如果团队能推动前端在关键元素上补 data-testid，自动化稳定性会提升很多。

这不是测试一个人的事情。

这是前端、测试、产品一起把“可测试性”补上。

2. 登录态规范：能复用，但不能乱放

后台系统几乎都需要登录。

每条用例都登录一遍，效率低，也容易触发风控、验证码、短信码。

更合理的方式，是通过一次登录生成 storageState，后续用例复用登录态。

但这里有一个坑：

storageState 里可能包含 cookie、token 等敏感信息。

所以它不能随便提交到代码仓库。

应该加入 .gitignore，并且在 CI 里通过安全变量或独立账号重新生成。

3. 测试数据规范：不要污染真实环境

新增、编辑、删除这类用例，如果直接操作真实数据，很容易出事故。

比较稳的做法是：

测试环境单独跑。

测试账号单独建。

测试数据加统一前缀。

用例执行前造数。

用例执行后清理。

清理失败要打印日志。

比如所有自动化数据统一加前缀：

e2e_user_20260427_001
e2e_order_20260427_001
e2e_role_20260427_001

这样排查、清理、过滤都方便。

4. 等待规范：不要靠 sleep 赌运气

很多脚本不稳定，是因为写了太多固定等待。

比如：

await page.waitForTimeout(3000)

这类写法短期能跑，长期不稳。

网络快的时候浪费时间。

网络慢的时候照样失败。

更好的方式是等待明确状态：

await expect(page.getByRole('table')).toBeVisible()
await page.waitForResponse(response => response.url().includes('/list') && response.status() === 200)
await expect(page.getByText('加载中')).toBeHidden()

自动化测试不是等得越久越稳定。

而是等得越准确越稳定。

5. CI 规范：没有报告，就没有闭环

本地能跑，只是第一步。

真正有价值的 UI 自动化，应该进入 CI。

至少要做到：

每次合并前跑核心用例。

每天定时跑回归用例。

失败后保留截图、视频、trace。

报告能被研发和测试一起查看。

失败用例有人分析、有人归因、有人修复。

否则自动化只会变成一个“偶尔跑一下”的脚本集合。

六、把提示词沉淀成资产，才是自动化测试提效的关键

很多人用 AI 写脚本，是一次性使用。

今天让 AI 写一个登录。

明天让 AI 写一个查询。

后天让 AI 写一个新增。

每次都从零开始描述。

这种用法能提效，但提效有限。

更好的方式，是把提示词当成团队资产沉淀下来。

后台系统的 UI 自动化，本质上有大量重复模式。

登录态复用是一类。

列表查询是一类。

表单提交是一类。

弹窗抽屉是一类。

权限校验是一类。

导入导出是一类。

异常提示是一类。

网络请求断言是一类。

测试数据准备和清理也是一类。

这些场景不应该每次重新写提示词。

应该形成一套团队内部的 Prompt Library。

这里的关键不是“AI 替代测试”。

而是测试工程师把经验前置到模板里。

例如：

哪些元素定位方式更稳定。

哪些等待方式容易导致 flaky。

哪些断言必须有。

哪些操作要兼容 popup。

哪些场景不能污染数据。

哪些异常提示不能忽略。

哪些登录态不能提交仓库。

哪些失败信息必须保留 trace。

这些东西，才是测试工程师的经验价值。

真正值钱的不是某一条自动化脚本，而是能持续生成高质量脚本的方法。

一个成熟团队，后面甚至可以把模板进一步分层：

这样一来，AI 不再是“临时帮你写代码的工具”。

它更像一个可以按团队规范执行的自动化脚本生成器。

七、未来的测试工程师，拼的是“会不会指挥 AI 干活”

Playwright 本身不是新概念。

AI 生成代码也不是新鲜事。

真正发生变化的是：

自动化测试的门槛正在下降，但测试工程能力的要求正在上升。

以前写 UI 自动化，很多时间花在查 API、写定位、调脚本。

现在这些事情，AI 可以帮你完成一大部分。

但 AI 不能替你判断：

这个场景到底该不该自动化。

这个断言是否足够有效。

这个脚本失败是产品 bug，还是测试脚本不稳定。

这个页面更适合 UI 测试，还是接口测试。

这个用例是否应该进入 CI。

这个测试数据是否会污染环境。

这些判断，依然需要工程经验。

所以，未来测试工程师的能力会发生一次迁移。

从“我会不会写脚本”，迁移到“我能不能设计出高质量测试任务”。

从“我会不会点页面”，迁移到“我能不能把业务路径变成自动化资产”。

从“我会不会用工具”，迁移到“我能不能让 AI 按工程规范稳定产出”。

这对在校生、初级工程师、中级工程师的启发也不一样。

在校生不要只停留在“Playwright 怎么安装”。

更应该理解一个后台系统有哪些典型测试场景。

初级工程师不要只满足于“AI 帮我生成了一段代码”。

更要学会改选择器、补断言、处理等待、读懂失败日志。

中级工程师不能只把 AI 当代码助手。

更应该把登录态、测试数据、Page Object、CI、报告、失败截图、网络断言这些工程能力串起来。

因为企业真正需要的不是“会写几个脚本的人”。

而是能把自动化测试持续跑起来、持续维护下去、持续发现问题的人。

AI 让脚本生成变快了，但也会更快暴露测试设计能力的差距。