Codex 浏览器验收怎么做？用 Playwright 检查筛选、空状态和错误反馈

Codex 浏览器验收怎么做？用 Playwright 检查筛选、空状态和错误反馈

让 Codex 验收前端页面，先准备一组输入和对应预期，再要求它在浏览器里实际操作，记录看到的反馈、截图和复现步骤。日期筛选至少检查有结果、无结果、输入错误三种情况；还要检查加载、失败和翻页后的条件保留。构建成功只能证明代码通过构建，页面能否完成操作要在运行时确认。

项目已有 Playwright 时，可以沿用测试环境；Codex 也可以使用当前已连接的浏览器工具。Playwright 官方建议围绕用户可见行为编写测试，并优先使用角色、标签等定位方式。Playwright 测试实践

开始前固定页面和测试数据

以订单列表的日期筛选为例，先记录本次待验收版本、本地页面地址和演示数据。准备两笔处于不同日期的订单，再选一个确实没有订单的时间段。样本应来自测试环境，避免为了验收产生真实收费订单。

还要说清时间口径：筛选的是创建时间还是付款时间，结束日期是否包含当天。否则 Agent 点完页面，也无法判断“结果对不对”。

给 Codex 一份可以执行的任务

打开指定本地订单页，使用测试数据验收日期筛选。
逐项操作表格中的条件，记录实际反馈。
检查点击筛选后的加载状态、失败提示和重试入口。
筛选后翻页，再返回第一页，检查条件是否保留。
桌面和手机宽度各走一次主要流程。
问题附输入、复现步骤与截图，区分通过、失败和未执行。

如果浏览器打不开，先记录具体错误并检查服务地址。如果登录状态失效，停在登录这一步。不要把未执行的页面路径写进“通过”列表，也不要跳过界面直接从接口数据推断按钮能用。

自动化用例要断言页面结果

项目已经使用 Playwright Test 的，可以把稳定操作留下来。下面是“无结果”场景的写法示例，页面地址、字段标签和测试日期需要替换为项目实际值：

test('无订单时显示空状态', async ({ page }) => {
  await page.goto('/orders');
  await page.getByLabel('开始日期').fill('2026-08-01');
  await page.getByLabel('结束日期').fill('2026-08-02');
  await page.getByRole('button', { name: '筛选', exact: true }).click();
  await expect(page.getByText('没有符合条件的订单')).toBeVisible();
});

这段示例假定已配置测试登录和 baseURL，并且该日期范围在测试数据中为空。重点是点击后断言用户看到的空状态。Playwright 的异步断言会等待预期条件，不必靠固定休眠赌页面什么时候更新。断言说明

慢请求和失败也要有可见反馈

在受控测试环境里模拟请求延迟与失败，检查按钮有没有处理中状态、用户能否区分“还在加载”和“查询失败”，恢复后能否继续操作。网络失败时不要把旧结果当成新结果，页面应让人看懂当前数据状态。

对于手机布局，除了看截图，还要实际点击日期输入框和筛选按钮。屏幕宽度模拟适合检查拥挤和遮挡，真实手机的输入法、触摸和滚动体验需要另外体验。

验收报告还应写出哪些情况没有执行。比如只有桌面浏览器、无法验证手机输入法，就把它留作真实设备检查；服务不可用而使用了模拟响应，则记录模拟覆盖了哪些状态。这样下一位同事接手时知道还需要补什么。

留下能接着修的问题记录

一条好记录可以这样写：“在订单页选择无订单日期，点击筛选后仍显示上次结果；预期显示空状态；附页面截图、版本和时间。”接手的人不用重新猜测试条件。

涉及偶发失败时，可保存 Playwright trace，回看操作、页面快照和请求时间线。Trace Viewer适合沿着失败步骤检查原因。日志与截图对外分享前，移除登录信息和业务数据。

修复后用同一组输入复查受影响路径，报告写出实际执行的环境和结果。如果任务还包含页面改版，可接着用Product Design 的现有页面改造流程；任务反复扩展，则先整理Codex 任务范围与用量。

经常用 Codex 开发和验收项目，可在 China Models 订阅服务查看已有账号的订阅与开票套餐。