AI 可以用于测试工作，但不建议只用一句 “帮我写测试用例”。

这个输入太宽泛，容易得到一份结构完整但风险不聚焦的结果。

更实用的做法是把测试工作拆成几个任务：需求拆解、用例生成、接口场景、自动化脚本审查、缺陷分析。

下面是 5 个可以直接复制改造的模板。

1. 需求拆解模板

适用场景：需求评审前、用例设计前。

请先不要生成测试用例。

请基于以下需求，帮我拆出：
1. 业务目标。
2. 核心业务规则。
3. 涉及的对象和状态。
4. 关键用户路径。
5. 可能需要澄清的问题。
6. 高风险点。

请用测试工程师视角输出，不要只复述需求文字。

需求内容：
{粘贴需求文档或需求片段}

评审重点：

• 是否识别出业务规则，而不只是页面操作。
• 是否拆出对象状态。
• 是否提出可用于需求评审的问题。
• 是否识别权限、数据、异常和状态流转风险。

2. 测试用例生成模板

适用场景：生成第一版测试用例初稿。

请基于以下需求生成测试用例。

要求：
1. 先按业务规则分组，不要只按页面操作分组。
2. 每条用例包含前置条件、测试步骤、测试数据、预期结果。
3. 覆盖正常流程、异常流程、边界值、状态切换、权限差异。
4. 标注 P0/P1/P2 优先级，并说明原因。
5. 不要写“验证功能正常”“验证系统稳定”这类不可执行描述。

需求内容：
{粘贴需求}

生成后建议继续人工检查：

• 是否覆盖业务目标。
• 状态是否拆开。
• 边界是否只有数字边界。
• 预期结果是否可观察。
• 优先级是否符合项目真实风险。

3. 接口测试场景模板

适用场景：接口文档较清楚，需要设计接口测试或接口自动化场景。

请不要只按单接口生成用例。

请按业务链路整理接口测试场景，重点补充：
1. 字段依赖：字段来自哪个前置接口，哪些需要动态提取。
2. 鉴权与越权：未登录、token 异常、角色权限、用户数据越权。
3. 幂等和重复请求：重复提交、超时重试、回调重放。
4. 异常返回：HTTP 状态码、业务错误码、错误结构、数据不变性。
5. 状态流转：接口调用后的订单、库存、权益、消息等后续校验。

每条场景请包含：
前置条件、接口链路、请求数据来源、关键断言、后续校验接口、风险等级。

接口文档：
{粘贴接口文档}

评审重点：

• 是否存在只能看、不能跑的纸面场景。
• 是否说明字段来源和动态提取。
• 是否覆盖越权、幂等、异常返回和状态流转。

4. 自动化脚本审查模板

适用场景：审查 AI 生成的 Playwright、Selenium、接口自动化、JMeter 脚本初稿。

请以测试开发评审视角检查以下自动化脚本。

重点看：
1. 定位方式是否稳定。
2. 等待机制是否可靠。
3. 测试数据是否独立、可清理。
4. 断言是否验证到了业务结果，而不是只验证页面存在或接口返回成功。
5. 失败时日志是否足够排查。
6. 是否存在硬编码、重复代码和环境耦合。

请输出问题清单、风险等级和修改建议。

脚本内容：
{粘贴脚本}

评审重点：

• 是否只验证了 “能跑”，没有验证业务结果。
• 是否依赖固定数据或固定环境。
• 失败后是否能定位原因。
• 是否便于后续维护。

5. 缺陷分析模板

适用场景：缺陷初步分析、复盘前材料整理。

请基于以下缺陷信息，帮我整理：
1. 复现路径。
2. 相关接口和关键参数。
3. 可能影响的数据状态。
4. 从日志或返回值中能确认的事实。
5. 仍需要补充验证的信息。
6. 可能的原因假设。

请把“已确认事实”和“推测原因”分开，不要直接下最终结论。

缺陷信息：
{粘贴缺陷描述、日志、接口返回、截图文字}

评审重点：

• 事实和推测是否分开。
• 是否指出还需要补充的证据。
• 是否遗漏影响范围、数据状态和复现条件。

使用建议

提示词不是固定咒语，而是测试思路的外化。

如果希望 AI 输出更接近真实测试工作，关键不是把话写得更长，而是把判断框架写清楚：

• 先讲业务规则。
• 再拆对象状态。
• 补异常和边界。
• 明确断言和后续校验。
• 最后看风险优先级。

AI 适合节省整理时间，但最终是否可用，仍然要由测试人审一遍。