在实际项目开发中，我发现不少团队编写自动化测试时，最让人头疼的往往不是测试逻辑本身，而是如何将产品需求文档中的“边界条件”与“异常场景”快速、准确地转化为可运行的代码。手动逐条翻译既耗时又容易遗漏。有没有更聪明的办法？答案是：借助 Copilot 替你完成那部分重复劳动。

假设产品文档明确写明“用户登录失败时应显示红色错误提示，且不跳转页面”——你当然可以手动编写断言和截图逻辑，但花费 20 分钟实在不值得。下面这套工作流，正是用来解决这个问题的。

准备可被 Copilot 理解的需求上下文

在测试项目根目录下，新建一个 requirements_context.md 文件。这个文件只做一件事：从原始需求文档中提取与测试强相关的内容，其余背景介绍、UI 设计稿链接、会议纪要全部剔除。

具体提取什么？只保留那些带有明确行为约束的句子。例如：“密码错误时，前端必须返回 status: 401”“邮箱格式错误需高亮 input 框并显示‘邮箱格式不正确’”。每条需求单独成行，前面加一个短横线（-）。

这一步如果做得粗糙，Copilot 很容易生成大量无效断言——比如对“系统支持未来扩展”这种模糊描述，也会给你生成一个 expect().toBe(true)，那就闹笑话了。

用自然语言指令触发 Copilot 生成测试用例

打开一个空的 .spec.ts 文件，在第一行写下这样一段注释：

// 根据 requirements_context.md 中第3、5、7条需求，生成 Cypress E2E 测试，覆盖登录失败场景，包含截图和状态码校验

将光标停在下一行，按下 Ctrl+Enter（Windows）或 Cmd+Enter（Mac），Copilot 就会给出建议代码。如果首次生成的结果偏简单，直接在它生成的代码末尾追加一条注释：// 补充：检查错误提示是否为红色，CSS color 值必须是 #d32f2f，否则失败。Copilot 会基于这条新指令重写后续的断言逻辑。

注入真实数据驱动逻辑

方法一：使用 fixtures 文件注入变量

在 cypress/fixtures/ 下创建 login_failures.json，写入三组典型的错误数据。每组数据包含 email、password、expectedMessage 三个字段。这样一来，数据和测试逻辑就完全分离了，维护成本显著降低。

方法二：让 Copilot 自动生成参数化结构

在已有测试函数内部，将光标放在 it() 块起始大括号后面，输入：// 用 cy.fixture('login_failures').then(…) 改写为 forEach 循环，每组数据独立执行一次测试，并在失败时自动保存截图。Copilot 会帮你生成参数化的循环结构。

【必须先保存 login_failures.json 再执行此步】，否则 Cypress 运行时会报 ENOENT 错误，而且不会提示具体缺失的文件名，排查起来相当棘手。

方法三：动态构造 URL 参数绕过登录页（适用于已知 token 过期接口）

在 describe 块顶部添加一个常量：const EXPIRED_TOKEN = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...';。然后在 cy.visit() 之前插入 cy.request()，模拟携带该过期 token 的请求，捕获 401 响应体用于断言。这种方式可以绕过登录页，直接测试 token 过期场景。

绑定 CI 流程前的强制校验

在将测试用例提交到 CI 流程之前，必须提前完成以下几项校验。

第一步：在 package.json 的 scripts 中添加一条命令："test:ai-check": "npx ts-node ./scripts/validate-copilot-output.ts"。

第二步：创建 scripts/validate-copilot-output.ts 文件。该脚本将读取项目中所有 .spec.ts 文件，用正则表达式检查每个 it() 块是否包含：至少一个 cy.screenshot() 调用、一个 cy.get() + should('contain') 组合、以及一个 cy.request() 或 cy.intercept() 监听。

第三步：在 GitHub Actions 的 test job 最开头插入 - run: npm run test:ai-check。如果校验失败，工作流会直接中断，不会运行任何测试用例。这样一来，所有进入 CI 的测试脚本都强制满足了最基本的结构要求。