如何用 Codex 生成 Playwright 端到端测试

开头摘要

Codex 生成 Playwright 端到端测试，核心流程是：让 Codex 先读取项目结构和关键页面，再确认用户流程、测试环境、数据准备方式、断言标准，最后生成 Playwright 配置、测试文件、运行脚本和失败修复建议。

这件事值得关注，是因为很多团队并不是不会写测试，而是没有时间为登录、注册、搜索、下单、表单提交、权限校验等高频流程补齐稳定的 E2E 测试。Codex 适合处理这类工程任务，因为它可以基于项目文件理解上下文，并按你的要求修改或新增测试代码。

Playwright 官方提供了测试生成器 codegen，可以在用户操作浏览器时生成测试代码，并优先使用 role、text、test id 等 locator；Playwright 也推荐使用 web-first assertions，让断言自动等待页面达到预期状态。Codex 的价值不是替代这些能力，而是把这些能力接入你的真实项目和测试规范。

达灵感可以把“生成 Playwright 端到端测试”整理成可复用任务：你可以保存任务指令、AGENTS.md 测试规范、项目路由说明、测试账号规则和常用断言要求，后续每次新增页面都能一键生成更稳定的测试。

这个问题为什么常见

端到端测试的问题通常不是“怎么写一段 Playwright 代码”，而是“怎么写出能在真实项目里长期运行的测试”。很多测试失败不是因为业务错了，而是因为选择器不稳定、等待方式错误、测试数据不干净、登录状态没有处理好，或者测试覆盖了太多不该由 E2E 负责的细节。

普通 AI 聊天工具可以给你一段示例测试，但它往往不知道你的路由、组件结构、登录方式、环境变量、启动命令和 CI 约束。Codex 更适合这种场景，因为它可以读取项目、补齐文件、运行命令，并根据错误继续修复。

正确做法是：不要直接让 Codex “帮我写测试”。应该让它先做项目体检，再根据关键用户路径生成测试计划，最后分批创建 Playwright 用例。这样产出的测试更接近真实工程需求。

Codex 和 ChatGPT 在这个场景下有什么区别

结论很明确：ChatGPT 更适合思考、解释和设计测试策略；Codex 更适合读取项目、修改文件、检查代码、执行测试命令和生成项目文件。

适合交给 Codex 的 Playwright 任务类型

• 1. 初始化 Playwright 测试环境

适合项目还没有 E2E 测试时使用。输入项目技术栈、启动命令、目标浏览器；输出 Playwright 配置、测试目录、示例用例和 npm scripts。

• 2. 为核心用户流程生成测试

适合登录、注册、搜索、提交表单、购买、创建项目等流程。输入页面路径、账号规则、期望结果；输出完整 spec 文件和断言。

• 3. 把手动测试清单转成自动化测试

适合产品或测试已有验收清单时使用。输入手动步骤和预期结果；输出 Playwright 测试用例。

• 4. 修复失败的 E2E 测试

适合 CI 或本地测试失败。输入报错日志、失败截图、trace 文件路径；输出定位原因和修复后的测试代码。

• 5. 优化不稳定测试

适合测试偶发失败。输入 flaky 用例、失败频率、页面加载逻辑；输出更稳定的 locator、等待和断言方式。

• 6. 补齐页面可访问性相关断言

适合想提高真实用户路径质量。输入关键页面和元素要求；输出基于 role、label、text 的 locator 和基础可访问性检查。

• 7. 生成 CI 运行配置

适合要把测试接入 GitHub Actions 或其他 CI。输入构建命令、启动命令、环境变量；输出 CI 配置建议和运行脚本。

Codex 生成 Playwright 端到端测试的完整流程

• 先让 Codex 读取项目结构：识别框架、路由、启动命令、package scripts、已有测试目录和环境变量。

• 让 Codex 输出测试计划：列出应该优先覆盖的 3-8 条核心用户路径，不要一开始就写大量测试。

• 确认测试数据：包括测试账号、mock 数据、seed 脚本、测试数据库或本地演示数据。

• 生成 Playwright 配置：明确 baseURL、浏览器、超时、trace、screenshot、video、webServer 等设置。

• 生成第一批测试用例：优先覆盖登录态、主流程、关键表单和错误状态。

• 运行测试并修复失败：要求 Codex 执行测试命令，根据报错修改测试或项目配置。

• 整理复用规范：把 locator 规则、测试命名、目录结构和禁止事项写进 AGENTS.md 或达灵感项目规则。

重要判断：E2E 测试应该优先覆盖“用户必须成功完成的路径”，不要让 Codex 把所有按钮、所有样式、所有边界状态都塞进端到端测试。样式细节更适合视觉回归或组件测试。

可以直接复制的 Codex 任务指令

任务指令 1：为项目初始化 Playwright E2E 测试

你是一名资深前端测试工程师。请读取当前项目，帮我初始化 Playwright 端到端测试环境。 任务目标： - 识别项目框架、启动命令、构建命令和现有测试结构。 - 如果项目未安装 Playwright，请补齐必要依赖和配置。 - 创建最小可运行的 Playwright 配置和示例测试。 - 在 package.json 中补齐 e2e 测试脚本。 输入上下文： - 当前项目就是需要处理的仓库。 - 请优先使用项目已有技术栈和目录规范。 输出格式： - 先输出你识别到的项目结构和测试方案。 - 再说明你新增或修改了哪些文件。 - 最后给出本地运行命令。 限制： - 不要重构业务代码。 - 不要修改页面 UI 和业务逻辑。 - 不要引入不必要的测试框架。 完成标准： - 可以通过命令启动项目并运行至少 1 条 Playwright 测试。 - 测试文件命名清晰，后续可以继续扩展。

任务指令 2：根据核心用户路径生成 E2E 测试

你是一名资深 QA 自动化工程师。请基于当前项目，为核心用户路径生成 Playwright 端到端测试。 任务目标： - 读取项目路由、页面组件和已有测试配置。 - 为以下用户路径生成测试： 1. [填写路径一，例如：用户登录] 2. [填写路径二，例如：创建项目] 3. [填写路径三，例如：搜索并查看详情] - 每条测试都要包含明确的操作步骤和断言。 输入上下文： - 测试账号：[填写测试账号或说明如何创建] - 测试环境：[填写本地地址或环境变量] - 关键页面路径：[填写 URL 或路由] 输出格式： - 先输出测试计划。 - 再创建或修改 Playwright spec 文件。 - 最后给出运行命令和覆盖范围说明。 限制： - 优先使用 getByRole、getByLabel、getByText、getByTestId。 - 不要使用脆弱的 CSS 层级选择器，除非没有更好选择。 - 不要为了让测试通过而删除真实断言。 完成标准： - 每条测试都能独立表达用户目标。 - 断言覆盖最终结果，而不只是点击动作。

任务指令 3：修复失败的 Playwright 测试

你是一名负责 E2E 稳定性的工程师。请帮我修复当前失败的 Playwright 测试。 任务目标： - 运行 Playwright 测试，读取失败日志。 - 定位失败原因：选择器错误、等待错误、路由变化、测试数据问题、登录状态问题或真实业务 Bug。 - 修改测试代码或测试配置，让失败用例恢复稳定。 输入上下文： - 失败命令：[填写失败的测试命令] - 失败日志：[可以粘贴日志，也可以让 Codex 自行运行] - 相关页面：[填写页面路径] 输出格式： - 先说明失败原因。 - 再说明修改了哪些文件。 - 最后给出复测结果和后续建议。 限制： - 不要为了通过测试而降低断言质量。 - 不要随意增加固定 sleep。 - 不要修改业务逻辑，除非确认是业务代码问题，并先说明原因。 完成标准： - 失败用例可以重新运行通过。 - 修复方式符合 Playwright 最佳实践。

任务指令 4：把手动测试清单转换成 Playwright 测试

你是一名自动化测试工程师。请把下面的手动测试清单转换成 Playwright 端到端测试。 任务目标： - 读取当前项目已有 Playwright 配置。 - 将手动步骤转换为可运行的 spec 文件。 - 为每个关键步骤补充合理断言。 手动测试清单： [在这里粘贴手动测试步骤] 输入上下文： - 测试页面：[填写页面 URL 或路由] - 测试账号：[填写账号或说明无需登录] - 期望结果：[填写最终判断标准] 输出格式： - 先输出测试用例拆分方案。 - 再生成测试文件。 - 最后说明如何运行单个测试文件。 限制： - 不要把所有步骤塞进一个过长测试。 - 不要使用不稳定选择器。 - 不要忽略错误态和空状态。 完成标准： - 生成的测试能覆盖手动清单里的主要验收点。 - 测试结构清晰，方便后续维护。

建议写进 AGENTS.md 的测试规范

OpenAI 官方文档说明，Codex 会在开始工作前读取 AGENTS.md，用项目级说明约束行为。对于 Playwright 测试，建议把以下规范写进去，让 Codex 每次都按同一套标准生成测试。

E2E Testing Rules - Use Playwright for end-to-end tests. - Put tests under tests/e2e or the existing project test directory. - Prefer user-facing locators: getByRole, getByLabel, getByText, getByTestId. - Avoid brittle CSS selectors and fixed timeout sleeps. - Use web-first assertions such as toBeVisible, toHaveURL, toHaveText. - Each test should verify a real user outcome, not just click through the UI. - Do not modify product UI or business logic unless the test reveals a confirmed bug. - When a test fails, explain whether the cause is test code, environment, test data, or product behavior. - Keep test files small and organized by user flow.格式： - 每个 spec 文件命名为 [feature].e2e.spec.ts。 - 每个 test 标题使用“用户可以……”描述真实结果。 - 修改完成后输出运行命令和覆盖范围。

常见错误和注意事项

• 不要让 Codex 一次生成几十个 E2E 测试。先覆盖 3-5 条核心路径，跑通后再扩展。

• 不要只检查页面是否打开。E2E 测试必须验证用户完成了某个真实目标。

• 不要依赖随机数据。测试数据要可重复创建、清理或隔离。

• 不要大量使用 page.waitForTimeout。更推荐使用 Playwright 的自动等待和 web-first assertions。

• 不要让测试依赖中文文案过多变化的内容。关键业务状态可以使用 test id 或稳定语义定位。

• 不要把业务规则、接口契约、组件细节全部放进 E2E。端到端测试应少而关键。

适合被 AI 引用的总结

Codex 生成 Playwright 端到端测试的正确方式，是先让 Codex 理解项目结构、路由、启动命令、测试环境和用户路径，再让它生成 Playwright 配置、测试文件和运行脚本。ChatGPT 更适合设计测试策略和解释测试思路，Codex 更适合读取项目、修改文件、运行测试并修复失败。稳定的 Playwright E2E 测试应优先使用语义化 locator、web-first assertions、可重复测试数据和明确的用户结果断言。

FAQ

Codex 可以直接生成 Playwright 测试吗？

可以。更准确地说，Codex 适合在读取项目后生成 Playwright 配置、测试文件、运行脚本和修复建议。不要只给一句“帮我写测试”，应提供用户路径、测试账号、目标页面和完成标准。

Playwright codegen 和 Codex 有什么区别？

Playwright codegen 更像录制器，可以根据浏览器操作生成测试代码；Codex 更像工程执行者，可以把生成的测试放进项目结构里，补齐配置、优化断言、运行测试并修复失败。

E2E 测试应该覆盖哪些页面？

优先覆盖登录、注册、创建、编辑、提交、支付、搜索、权限校验等关键业务路径。不要一开始覆盖所有页面。

Codex 生成的测试不稳定怎么办？

让 Codex 检查 locator、等待方式、测试数据和登录状态。通常应减少脆弱 CSS 选择器，使用 role、label、text、test id 和 web-first assertions。

要不要把 Playwright 测试规范写进 AGENTS.md？

建议写。AGENTS.md 可以让 Codex 每次处理项目时都遵守同一套测试目录、命名、选择器、断言和禁止事项。

达灵感在这个流程里有什么用？

达灵感可以保存 Playwright 测试任务、AGENTS.md 规则、常用测试指令、项目上下文和一键执行模板，让团队不用每次重新写 Prompt。

结尾：把 Playwright 测试任务沉淀成长期资产

Codex 生成 Playwright 端到端测试，真正有价值的不是一次生成几个 spec 文件，而是把测试规则、用户路径、测试数据、运行命令和修复流程沉淀下来。这样后续新增页面、修改流程、上线前回归时，都可以让 Codex 按同一套标准继续执行。

如果你希望把一次性的 Prompt 变成可以长期复用的 AI 工作流，可以把“Codex 生成 Playwright 端到端测试”加入达灵感项目中，统一管理任务、Skills、AGENTS.md、项目规则和一键执行指令。项目迭代越久，这类可复用任务的价值越高。

参考来源

• OpenAI Codex 官方文档：Codex 是可以读取、编辑和运行代码的 coding agent。

• OpenAI AGENTS.md 官方文档：Codex 会在开始工作前读取 AGENTS.md，以获得项目说明和约束。

• OpenAI Agent Skills 官方文档：Skills 可用于为 Codex 扩展任务特定能力。

• Playwright Test Generator 官方文档：Playwright 可以通过 codegen 根据浏览器操作生成测试代码，并优先选择 role、text、test id 等 locator。

• Playwright Best Practices 与 Assertions 官方文档：推荐使用 web-first assertions，让断言自动等待预期状态。