把 PRD 交给 AI，再让它生成测试用例和自动化脚本，这条链路已经有了可用雏形。霍格沃兹测试开发学社在 AtomGit 开源社区把 AI IDE + MCP（Model Context Protocol）的工作方式概括为“需求文档 → 测试用例 → 自动化脚本”。
链路能接通，不代表可以无人值守。需求写得含糊，模型只会更快地产出一批含糊的用例；断言没定清，脚本跑通也无法证明业务正确。
先圈定一条真实业务链路
IBM 对端到端测试的定义很直接：从头到尾检查应用程序的工作流，确认整体功能是否正常。它比只检查单个函数或接口更全面，但额外的覆盖也有代价。因此，IBM 的 E2E 最佳实践首先强调测试范围和真实场景。
以“用户登录”为例，PRD 里只有 username 和 password 两个字段还不够。测试人员还要写清：正常路径包含哪些操作，字段为空或输入错误时系统应怎样响应，成功与失败分别以什么结果作为判定，这条流程从哪里开始、到哪里结束。
这些信息缺失时，AI 只能自行补全业务假设。生成的用例可能格式完整，却和产品真正的验收口径对不上。先把范围圈准，再谈脚本生成。
验收规则要先于脚本
阿里云开发者社区的相关文章把测试工作的变化概括为“教 AI 怎么思考”。落到项目里，就是把模糊需求改写成可检查的验收规则。
一份适合交给 AI 的规则，通常要包含这些内容：
- 功能与范围：要验证哪段业务，哪些内容暂不覆盖。
- 输入与前置条件：字段、数据状态和必要依赖是否清楚。
- 操作路径：用户操作或接口调用按什么顺序发生。
- 验收断言：出现什么结果才算通过，失败时应看到什么。
- 边界与异常：空值、错误值和状态切换如何处理。
规则可以写在 Markdown，也可以放进团队已有的结构化配置。格式并非重点，关键是每条用例都能找到对应的需求和断言。
在此基础上，AI 再去扩展正向、反向和边界场景，并按项目现有框架生成脚本。这样得到的是有依据的测试草稿，而不是凭模型猜测拼出来的用例集合。
把生成过程拆开，方便检查
一口气要求 AI 从整份 PRD 生成所有脚本，出了问题很难定位。更稳妥的做法，是把交付过程拆开：
- 先收齐上下文：提供 PRD、接口文档、已有测试代码、执行方式和项目约束。AI IDE 能看到什么，取决于实际接入的资料和工具。
- 先生成用例草稿：检查需求是否遗漏，正向、反向和边界场景是否合理，删除重复或没有业务价值的组合。
- 确认断言后再写脚本：避免模型围绕错误的验收口径继续扩写代码。
- 先跑冒烟路径：确认脚本能执行、依赖可用、失败信息能够定位到具体步骤。
- 再接入 CI/CD：把执行日志和失败原因作为下一轮修订的上下文，但最终修改仍要经过人工确认。
AI IDE + MCP 可以帮助模型接入文档、代码和测试工具，但能否走到自动执行，仍受现有测试框架、环境和权限限制。工具没有接通时，所谓“自动生成测试流”往往只停留在代码草稿阶段。
亮眼数据不能直接套到 E2E
测试之家相关文章提到，微软在 Visual Studio 和 VSCode 中集成了基于 Transformer 架构的 AI 测试插件，面向 C# 和 Java 等语言生成测试代码。
文中的某金融科技项目采用相关工具后，单元测试用例生成效率提升了 4 倍，代码覆盖率从 62% 提升到 89%。在“跨境支付汇率计算”场景中，原本需要资深测试工程师用 2 天梳理的内容，AI 在 15 分钟内生成了包含 27 种参数组合的测试用例集。
这些数字说明，AI 在参数组合扩展、边界场景补充和单元测试代码生成上已经能节省大量重复劳动。但它们不能直接证明，从 PRD 到 E2E 脚本再到 CI/CD 的整条链路也能获得同等收益。
同样，来源标题中的“80%”是提问式表达，不宜直接拿来做团队产能承诺。单元测试生成快，并不等于跨系统、跨状态的业务流程已经可以自动验收。
评审盯住业务，不只看能不能跑
AI 生成脚本后，人工评审至少要守住几处容易失真的地方。
断言是否有业务含义。 “请求成功”或“页面正常”通常过于宽泛。验收结果需要对应 PRD 中的明确规则，否则脚本即使通过，也无法说明功能符合要求。
范围是否失控。 E2E 适合覆盖关键业务链路和真实场景，不适合把所有参数组合都塞进同一条流程。参数级组合可以交给更靠近接口或单元层的测试处理。
脚本是否可维护。 检查命名、注释、依赖和失败信息是否清楚，并要求生成结果遵循项目已有的测试框架。只追求“当前能跑”，后续需求变化时很容易留下难以修改的代码。
复杂状态是否被明确建模。 对订单支付、履约、售后这类多状态流程，可以先列出状态和转换条件，再让 AI 生成各状态下的测试场景，整体顺序仍由测试框架控制。把全部逻辑塞进一段生成脚本，定位失败会很困难。
需求与脚本是否同步。 PRD 变化时，先更新验收规则，再让 AI 调整用例和脚本。只手工修改最终代码，会让需求、用例和脚本逐渐脱节。
测试工程师要交付的是“正确”的定义
AI 适合接手重复的场景扩展、参数组合和脚本初稿。测试人员仍要决定哪些风险值得测、什么结果算通过、哪些异常绝不能放过。
判断这套工作流是否可用，也不该只看生成了多少用例。更实际的标准是：需求能否追到对应断言，脚本能否在现有环境执行，失败能否回到清晰的业务规则。
手写代码会减少，但范围设计、规则表达和评审不会消失。把这些部分做扎实，AI 才能真正接过机械劳动，而不是批量制造新的维护任务。
