Codex 测试实战：从需求分析到自动化用例落地

核心定位：AI 不是替代测试，而是接管测试工作中重复、耗时、机械的脏活累活，成为测试开发高效协作搭子。

本文以优惠券领取功能为实战场景，完整拆解基于 Codex 的标准化测试工作流：需求拆解→代码影响分析→测试点设计→自动化脚本落地→故障归因→团队规范沉淀，全程可直接复刻落地。

一、核心认知：Codex 在测试工作中的正确用法

日常使用 Codex 做测试，最大误区是直接让 AI 生成用例、写脚本，最终产出内容空洞、不贴合业务、无法落地。

核心原则：

  • 模糊任务 = 虚假通用结果

  • 明确上下文、边界条件、校验标准 = 高效落地成果

Codex 的核心价值：替代重复劳动，测试人员负责风险决策、边界判断、业务校验。

二、实战场景：优惠券领取功能

2.1 需求背景

用户进入活动页可领取优惠券，核心规则：

  • 单个用户仅限领取一次

  • 优惠券包含活动时间、库存数量、使用门槛限制

  • 异常场景需展示对应提示：未登录、活动未开始/已结束、库存不足、重复领取

2.2 传统测试痛点

手动梳理测试点、排查代码影响范围、编写自动化脚本、分析报错日志，流程繁琐、重复度高、耗时久。

三、完整落地流程（五步标准化工作流）

第一步：AI 需求拆解，先梳理规则再写用例

禁忌操作：一上来直接提问「帮我写测试用例」。

标准提示词（可直接复制）：

你先不要写测试用例。
请站在资深测试工程师视角，阅读下面需求，帮我做三件事：
1. 列出这个功能的核心业务规则
2. 找出最容易出问题的风险点
3. 按主流程、异常流程、边界场景、数据一致性、安全风险进行分类

要求：
- 不要输出太空泛的内容
- 每个风险点都要说明为什么需要测
- 如果需求描述不完整，请列出需要追问产品的问题

需求如下：
【粘贴具体业务需求】

本次场景核心关注风险点：

  • 用户登录状态校验

  • 活动时间有效性校验（未开始/进行中/已结束）

  • 优惠券库存数量校验

  • 用户重复领取限制

  • 多端并发领取是否存在漏洞

  • 领取后库存扣减、用户券包数据一致性

  • 接口幂等性、重复请求防护

  • 前后端双重校验（避免前端置灰、后端无校验的漏洞）

核心重点：不只是校验页面提示，必须校验后端数据状态。

第二步：AI 代码扫描，定位功能影响范围

通过 Codex 读取项目代码，快速梳理功能链路，替代人工关键词检索，大幅提升效率。

标准提示词（可直接复制）：

请你先阅读当前项目中和“优惠券领取”相关的代码，不要改代码。
重点帮我找：
1. 前端页面入口
2. 领取按钮的交互逻辑
3. 调用的接口地址
4. 接口返回码和错误提示处理
5. 是否存在防重复提交逻辑
6. 是否有现成的测试用例或自动化脚本

最后输出：
- 涉及文件列表
- 主要调用链路
- 你认为测试时最需要关注的风险点

人工校验要点：AI 输出的文件路径、接口链路必须人工复核，不可完全依赖。

第三步：生成标准化测试点（含校验方式）

基于需求规则+代码链路，生成带场景、操作、预期结果、验证方式的完整测试点，兼顾页面、接口、数据库三层校验。

标准提示词（可直接复制）：

基于上面的需求和代码影响范围，请帮我生成测试点。

要求：
1. 不要写成长篇大论
2. 按模块分类
3. 每个测试点包含：场景、操作、预期结果、验证方式
4. 验证方式要区分：页面验证、接口验证、数据库/数据状态验证
5. 重点补充并发、重复请求、库存扣减、用户券包一致性场景

输出为 Markdown 表格。

核心测试点示例

场景 操作 预期结果 验证方式
正常领取 登录用户点击领取优惠券 提示领取成功，券包新增对应优惠券，库存正常扣减 页面提示 + 接口查询券包 + 数据库库存校验
重复领取 已领取用户再次点击领取 提示已领取，无数据变更 页面提示 + 接口返回码校验
库存不足 优惠券库存为0时点击领取 提示优惠券已领完，库存、用户券包无变更 页面提示 + 数据库库存校验
多端并发领取 同一用户多端同时点击领取 仅可领取一次，数据无重复 接口响应校验 + 用户券包数量校验
活动未开始 活动开始时间前点击领取 提示活动未开始，领取失败 页面提示 + 后端接口校验
活动已结束 活动结束后点击领取 提示活动已结束，领取失败 页面提示 + 后端接口校验

人工补充业务测试点（关键）：

  1. 重复快速点击领取按钮，前端是否做禁用防重

  2. 绕过前端页面，直接调用后端领取接口，校验后端防重逻辑是否生效

第四步：生成可落地 Playwright 自动化脚本

明确项目框架、编码规范、环境配置约束，避免 AI 生成垃圾脚本、硬编码敏感数据。

标准提示词（可直接复制）：

请根据下面测试点生成 Playwright 自动化脚本。

项目约束：
1. 使用 @playwright/test
2. 优先使用 getByRole、getByText、getByTestId
3. 不要使用 XPath
4. 测试环境地址从 TEST_BASE_URL 读取
5. 登录账号从 TEST_USERNAME、TEST_PASSWORD 读取
6. 不要写死真实域名、真实账号、真实 token
7. 领取成功后，需要调用接口查询用户券包做二次断言
8. 代码要拆成：登录、进入活动页、领取优惠券、查询券包几个方法

测试点：
【粘贴上述测试点】

AI 生成可运行脚本初稿

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 执行

请直接指出问题，并给出修改建议。

第五步：AI 辅助自动化报错日志归因

自动化用例失败后，无需人工逐行排查，交给 Codex 快速定位问题类型（脚本/环境/产品缺陷）。

标准提示词（可直接复制）：

你是一名测试开发，请分析下面 Playwright 自动化失败原因。

请输出：
1. 失败现象
2. 最可能原因
3. 是脚本问题、环境问题，还是产品缺陷
4. 需要进一步确认的信息
5. 建议修复方案

测试日志：
【粘贴日志】

接口返回：
【粘贴接口返回数据】

截图描述：
【页面截图信息】

报错分析示例：

报错：expect(locator).toBeVisible() failed，接口返回 COUPON_STOCK_EMPTY 优惠券已领完

AI 分析结论：脚本预期领取成功，实际测试环境优惠券库存为空，属于测试数据初始化问题，非代码缺陷、非脚本问题。

四、团队规范沉淀：将测试经验做成 Skill

单次问答效率有限，沉淀团队通用 Skill，无需重复交代规则，统一团队输出标准。

SKILL.md 通用规范模板

---
name: test-case-and-playwright
description: 当需要根据需求生成测试点、测试用例或 Playwright 自动化脚本时使用。
---

# 测试用例与 Playwright 自动化规范
## 一、测试点生成规则
必须全覆盖场景：
1. 主流程
2. 异常流程
3. 边界值
4. 权限校验
5. 幂等性
6. 数据一致性
7. 异常恢复

重点业务专项校验：
- 订单：重复提交、状态流转、金额一致性
- 优惠券：重复领取、库存扣减、用户券包一致性
- 支付：支付失败、回调重复、金额校验
- 权限：越权访问、资源归属校验

## 二、Playwright 脚本规则
1. 统一使用 @playwright/test
2. 优先使用 getByRole、getByText、getByTestId，禁止使用 XPath
3. 环境地址、账号、密码、Token 全部从环境变量读取，禁止硬编码
4. 核心业务必须补充接口/数据库数据断言，不依赖纯页面文案断言
5. 公共动作统一封装方法，代码复用
6. 脚本兼容 CI 自动化执行，无脏数据依赖

## 三、输出格式要求
1. 测试点：统一 Markdown 表格格式
2. 自动化脚本：输出完整可运行代码，附带依赖说明
3. 附加说明：依赖测试数据、环境变量配置、不稳定风险点

五、实战踩坑总结（避坑必看）

  1. 禁止无上下文生成接口：未提供接口文档、代码链路时，AI 会自行猜测接口路径，极易出错，必须先读代码再生成脚本

  2. 禁止硬编码敏感信息：账号、密码、Token、域名必须从环境变量读取，规避安全风险

  3. 禁止仅断言页面文案：核心业务必须校验后端数据、库存、用户数据一致性，页面展示可伪造，底层数据才是核心

  4. 禁止超大任务一次性交付：拆分任务分步执行：需求分析→风险梳理→测试点生成→脚本编写→代码Review，小任务输出质量更高

  5. 禁止完全依赖 AI 结果：AI 负责初稿输出，测试人员必须人工校验业务风险、边界场景、数据逻辑

六、最终总结

Codex 在测试工作中的核心价值，不是替代测试工程师，而是标准化、自动化测试全流程的重复工作。

高效落地核心口诀：

  • 先分析需求风险，再出测试点

  • 先扫描代码链路，再写自动化

  • 强制三层校验：页面+接口+数据

  • 沉淀团队规范，统一输出标准

  • AI 做机械执行，人做风险决策

（注：部分内容可能由 AI 生成）

# 需求分析 # 自动化 # 网络
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

每天 1000 万 Token，免费云端 AI 编程平台 MonkeyCode 上手指南

avatar AI编程社区
cover

AI Agent 的真相：水面之下，90% 是工程

avatar AI编程社区
cover

ChatGPT、Codex实战：为什么AI写代码以后，真正变慢的是测试和验证？

avatar AI编程社区