1. 需求文档到 Playwright 用例卡点到底在哪Codex 测试实战这件事很多人第一反应是「让 AI 直接写脚本」。我试过直接丢一句「帮我给优惠券领取功能写 Playwright 用例」出来的东西看着像模像样跑起来全是坑定位器用 XPath、账号密码硬编码在代码里、断言只校验页面文案、接口路径靠猜。最后花在改脚本上的时间比自己从零写还多。问题不在 Codex 本身而在于输入太模糊。Codex 这类模型的能力边界很清楚你给它明确的上下文、边界条件、校验标准它能产出接近可用的初稿你给它一句模糊需求它只能还你一份「通用模板」。测试开发真正要做的是把需求文档拆成模型能消化的结构化输入再把模型输出收敛到项目规范里。这条链路我拆成五段需求验收点拆解、代码影响面扫描、测试点表格化、Playwright 脚本生成、CI 跑通与报错归因。每一段都有可复制的提示词模板和配置片段。模型调用统一走 TaoToken 的 Key一个 Key 管住 Codex 和后续可能接入的其他模型省得在多个平台之间来回切。适合谁看手上有需求文档、想把它转成可执行自动化用例的测试开发已经在用 Playwright 但脚本维护成本高的团队想把 AI 接进测试流程又怕产出不可控的人。下面按步骤走每步都给命令和配置跟着做能拿到一份能跑的用例文件。2. TaoToken 统一 Key 前置把模型调用收敛到一个入口在写第一行提示词之前先把模型调用的入口固定下来。测试流程里会反复调用模型拆需求、扫代码、生成脚本、分析报错如果每次都要换平台、换 Key、换计费方式流程根本跑不顺。TaoToken 的作用就是把这些调用收敛到一个 Key 上。先拿 Key。打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台创建 API Key。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 列表在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。创建时给 Key 起个能认出来的名字比如codex-test-flow方便后面在 CI 里区分环境。拿到 Key 之后接口地址统一用 https://taotoken.net/api 注意这个地址不带 UTM 参数是纯 API 端点。模型 ID 按你实际要用的填Codex 场景下常用的编码模型 ID 可以在模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 里先试跑确认确认能正常返回再写进配置。这里有个容易踩的坑很多人把 Key 直接写进项目里的.env然后提交到仓库。测试项目尤其危险因为 CI 日志、构建产物都可能带出 Key。正确做法是本地用.env.local加进.gitignoreCI 里用平台的环境变量注入。下面给一份本地配置片段路径放在项目根目录的.env.local# .env.local —— 本地开发用务必加入 .gitignore TAOTOKEN_API_KEYsk-你的Key TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_MODEL_ID你的模型ID # Playwright 测试环境变量 TEST_BASE_URLhttp://localhost:3000 TEST_USERNAMEtest_user TEST_PASSWORDtest_passCI 侧以 GitHub Actions 为例在仓库 Settings → Secrets 里加TAOTOKEN_API_KEY工作流里通过env注入不要写死在 yaml 里。这样本地和 CI 用的是同一套变量名脚本不用改。如果你后续要长期跑编码类任务、Agent 类任务可以看下 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 把额度规划清楚避免跑到一半 Key 限额了流程断掉。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 参数细节以文档为准。Key 管好之后模型调用就可以在脚本里统一封装成一个函数后面所有提示词都走这个入口。这一步不做后面每换一个模型就要改一遍代码测试流程根本没法沉淀。3. 可复制配置Codex 提示词模板 Playwright 配置片段这一段是整篇的核心给的是能直接复制粘贴的东西。分三块需求拆解提示词、脚本生成提示词、Playwright 配置文件。3.1 需求拆解提示词模板第一步不是写用例是让 Codex 站在测试视角读需求。提示词里明确禁止它直接写用例逼它先输出规则、风险点、分类。模板如下你先不要写测试用例。 请站在资深测试工程师视角阅读下面需求帮我做三件事 1. 列出这个功能的核心业务规则 2. 找出最容易出问题的风险点每个风险点说明为什么需要测 3. 按主流程、异常流程、边界场景、数据一致性、安全风险分类 要求 - 不要输出空泛内容 - 如果需求描述不完整列出需要追问产品的问题 需求如下 【粘贴具体业务需求】以优惠券领取为例模型会输出「单用户限领一次」「活动时间校验」「库存扣减」「重复领取限制」「接口幂等」这些规则。你要做的是人工复核哪些是需求里写死的哪些是模型补的常识。模型补的部分要回产品确认不能直接当验收标准。3.2 代码影响面扫描提示词需求拆完让 Codex 读项目代码定位功能链路。提示词里强调「不要改代码」只做定位请你先阅读当前项目中和优惠券领取相关的代码不要改代码。 重点帮我找 1. 前端页面入口 2. 领取按钮的交互逻辑 3. 调用的接口地址 4. 接口返回码和错误提示处理 5. 是否存在防重复提交逻辑 6. 是否有现成的测试用例或自动化脚本 最后输出涉及文件列表、主要调用链路、测试时最需要关注的风险点。模型输出的文件路径和接口链路必须人工复核。这一步的价值是省掉人工全局搜索的时间不是替代你理解代码。3.3 Playwright 脚本生成提示词这是最容易出垃圾的一步。约束必须写死框架、定位器优先级、环境变量来源、禁止硬编码。模板请根据下面测试点生成 Playwright 自动化脚本。 项目约束 1. 使用 playwright/test 2. 优先使用 getByRole、getByText、getByTestId 3. 不要使用 XPath 4. 测试环境地址从 TEST_BASE_URL 读取 5. 登录账号从 TEST_USERNAME、TEST_PASSWORD 读取 6. 不要写死真实域名、真实账号、真实 token 7. 领取成功后调用接口查询用户券包做二次断言 8. 代码拆成登录、进入活动页、领取优惠券、查询券包几个方法 测试点 【粘贴测试点表格】3.4 Playwright 配置文件片段项目根目录的playwright.config.ts重点是baseURL从环境变量读、CI 下开启重试和单 workerimport { defineConfig, devices } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 30_000, retries: process.env.CI ? 2 : 0, workers: process.env.CI ? 1 : undefined, reporter: process.env.CI ? [[html], [github]] : [[list]], use: { baseURL: process.env.TEST_BASE_URL, trace: on-first-retry, screenshot: only-on-failure, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] } }, ], });baseURL从TEST_BASE_URL读脚本里所有page.goto(/activity/coupon)都是相对路径本地和 CI 换环境只改变量不改代码。trace: on-first-retry在失败重试时留痕后面报错归因靠它。3.5 生成后的脚本长什么样模型按上面约束产出的初稿大致是这样注意定位器全是getByRole账号从环境变量读领取后走接口二次断言import { test, expect } from playwright/test; const baseUrl process.env.TEST_BASE_URL; const username process.env.TEST_USERNAME; const password process.env.TEST_PASSWORD; async function login(page) { await page.goto(${baseUrl}/login); await page.getByRole(textbox, { name: 账号 }).fill(username); await page.getByRole(textbox, { name: 密码 }).fill(password); await page.getByRole(button, { name: 登录 }).click(); await expect(page.getByText(首页)).toBeVisible(); } async function openActivityPage(page) { await page.goto(${baseUrl}/activity/coupon); await expect(page.getByText(优惠券领取)).toBeVisible(); } async function receiveCoupon(page) { await page.getByRole(button, { name: 立即领取 }).click(); } test(用户成功领取优惠券后券包中可以查询到该券, async ({ page, request }) { await login(page); await openActivityPage(page); await receiveCoupon(page); await expect(page.getByText(领取成功)).toBeVisible(); const response await request.get(${baseUrl}/api/user/coupons); expect(response.status()).toBe(200); const data await response.json(); expect(data.list.some(item item.couponName 活动优惠券)).toBeTruthy(); });生成后必做一步 Review提示词请你 review 上面的 Playwright 脚本重点检查 1. 是否存在不稳定定位 2. 是否依赖脏数据 3. 是否缺少等待或断言 4. 是否有账号、域名、token 等敏感信息 5. 是否适合接入 CI 执行 直接指出问题并给修改建议。这一步能拦掉大部分「看着能跑、实际不稳」的脚本。4. 验证请求本地跑通到 CI 通过记录配置和脚本都有了接下来是验证。分本地和 CI 两段。本地先装依赖npm init -y npm i -D playwright/test npx playwright install chromium把上面生成的用例存成tests/coupon.spec.ts.env.local填好变量。Playwright 默认不读.env需要装dotenv或在命令里注入。简单做法export $(grep -v ^# .env.local | xargs) npx playwright test tests/coupon.spec.ts --projectchromium跑通后终端会输出类似Running 1 test using 1 worker 1 passed (3.2s)如果失败先看test-results/下的截图和 trace再决定是脚本问题还是环境问题。本地通过后接 CI。GitHub Actions 工作流片段name: playwright-tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npx playwright install --with-deps chromium - run: npx playwright test env: TEST_BASE_URL: ${{ secrets.TEST_BASE_URL }} TEST_USERNAME: ${{ secrets.TEST_USERNAME }} TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }} TAOTOKEN_API_KEY: ${{ secrets.TAOTOKEN_API_KEY }} - uses: actions/upload-artifactv4 if: failure() with: name: playwright-report path: playwright-report/CI 里workers: 1是为了避免并发抢库存导致用例互相干扰等测试数据隔离做好再放开。跑通后 Actions 页面会显示绿色通过记录失败时 artifact 里有完整报告。验证模型调用是否正常可以在本地单独发一次请求确认 Key 有效curl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY | head -c 300返回模型列表说明 Key 和端点都通。这一步在 CI 里也可以加个前置检查Key 失效时快速失败不用等用例跑完才发现。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一段按真实报错来每个都给现象、原因、处理。401 Unauthorized。现象是请求模型接口返回 401或 CI 里提示鉴权失败。原因通常是 Key 没注入、Key 拼写错、或者环境变量名对不上。排查顺序先确认TAOTOKEN_API_KEY在当前 shell 里echo得出来再确认请求头是Authorization: Bearer key不是x-api-key最后确认 Key 没被控制台禁用。CI 里常见的是 secret 名字写错比如 yaml 里写TAOTOKEN_KEY但 secret 存的是TAOTOKEN_API_KEY。local proxy failed。现象是本地请求模型接口时报连接失败或代理错误。原因一般是本地网络环境有代理配置或者HTTP_PROXY/HTTPS_PROXY环境变量指向了不可用的地址。处理检查env | grep -i proxy把不需要的代理变量 unset 掉再跑。CI 环境一般没有这个问题本地开发机容易中招。reading choices 报错。现象是解析模型返回时抛Cannot read properties of undefined (reading choices)。原因是返回体结构和预期不一致可能是模型 ID 填错导致返回了错误对象也可能是请求体格式不对。处理先把原始返回console.log出来看结构确认choices字段存在再核对模型 ID 是否和模型对话页里试跑的一致。封装调用函数时加一层结构校验返回体没有choices就抛出带原始响应的错误方便定位。OAuth 相关报错。如果你用的是 Claude Code 这类带 OAuth 流程的工具报错通常出现在 token 刷新环节。现象是提示授权失效或回调失败。处理确认回调地址和工具配置一致重新走一次授权如果工具支持直接填 API Key 模式优先用 Key 模式少一层 OAuth 就少一类问题。Claude Code 接入可以参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 里的说明。Playwright 侧常见报错。expect(locator).toBeVisible() failed配合接口返回COUPON_STOCK_EMPTY说明测试环境库存为空属于测试数据初始化问题不是脚本 bug。处理在beforeEach里调测试数据准备接口重置库存或者用独立的测试账号和测试活动。Timeout exceeded多半是定位器不稳或页面没加载完优先换getByRole并加await expect(...).toBeVisible()显式等待别用waitForTimeout硬等。排查时把日志、接口返回、截图三样一起丢给 Codex提示词你是一名测试开发请分析下面 Playwright 自动化失败原因。 输出失败现象、最可能原因、属于脚本/环境/产品缺陷哪一类、需要进一步确认的信息、建议修复方案。 测试日志【粘贴】 接口返回【粘贴】 截图描述【粘贴】模型给的是初判最终定性还是人来拍板。6. 把流程沉淀下来Skill 规范与后续接入单次问答效率有限真正省时间的是把团队规范做成可复用的 Skill。Codex 支持用SKILL.md描述任务规范把测试点生成规则、Playwright 脚本规则、输出格式写进去之后不用每次重复交代。SKILL.md模板--- name: test-case-and-playwright description: 当需要根据需求生成测试点、测试用例或 Playwright 自动化脚本时使用。 --- # 测试用例与 Playwright 自动化规范 ## 一、测试点生成规则 必须覆盖主流程、异常流程、边界值、权限校验、幂等性、数据一致性、异常恢复。 重点业务专项订单重复提交、状态流转、金额一致性、优惠券重复领取、库存扣减、券包一致性、支付失败、回调重复、金额校验、权限越权、资源归属。 ## 二、Playwright 脚本规则 1. 统一使用 playwright/test 2. 优先 getByRole、getByText、getByTestId禁止 XPath 3. 环境地址、账号、密码、Token 全部从环境变量读取禁止硬编码 4. 核心业务必须补接口/数据库数据断言不依赖纯页面文案 5. 公共动作封装方法代码复用 6. 兼容 CI 执行无脏数据依赖 ## 三、输出格式 1. 测试点Markdown 表格 2. 脚本完整可运行代码 依赖说明 3. 附加依赖测试数据、环境变量配置、不稳定风险点把这份SKILL.md放进项目Codex 每次生成都会按规范走团队输出标准统一。新人接手也不用从头讲一遍规则。后续如果要接更多模型或工具Key 还是走 TaoToken 那一个入口Base URL 固定https://taotoken.net/api换模型只改 Model ID。模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 可以先试跑确认模型可用接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 查参数细节API Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。长期跑编码和 Agent 任务的话Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 能把额度规划清楚。最后留一个实操建议每次生成脚本后先跑一遍 Review 提示词再本地跑通最后才推 CI。三步顺序别省省了哪步都会在 CI 里加倍还回来。测试数据隔离这件事越早做越好等用例多起来再补改造成本会高很多。