测试工程师常用的 5 个 AI 提示词模板

我现在越来越少直接对 AI 说：“帮我写测试用例。”

不是因为它不能写。

而是这个问题太大、太松，AI 很容易给你一份看起来完整、实际上偏平均的答案。

正常场景有，异常场景有，边界值也有。但业务规则有没有拆清楚，状态有没有走到最后，接口依赖有没有闭合，它不一定会主动追。

我更喜欢把测试工作拆成几个小任务，再分别问 AI。

下面这 5 个模板，是我觉得测试工程师比较常用，也比较容易落到工作里的。

很多时候，AI 生成的用例浅，不是它不会写，而是我们一开始就让它跳到了“写用例”。

我现在更习惯先让它拆需求。

请先不要生成测试用例。请基于以下需求，帮我拆出：1. 业务目标；2. 核心业务规则；3. 涉及的对象和状态；4. 关键用户路径；5. 可能需要澄清的问题；6. 高风险点。请用测试工程师视角输出，不要只复述需求文字。

这个模板适合用在需求评审前。

它的价值不是直接产出用例，而是帮你把需求里的模糊地带先照出来。

我会重点看它列出的“澄清问题”。如果问题问得浅，说明需求理解还不够；如果它能问到状态、权限、数据来源、异常处理，后面再生成用例会稳很多。

如果直接说“生成测试用例”，AI 往往会按正向、反向、边界值平均铺开。

更好的方式，是先告诉它你希望按什么框架生成。

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

这个模板适合生成第一版用例。

但我会提醒自己：它只是初稿，不是终稿。

生成后还要再审一遍业务目标、状态拆分、边界条件、可执行性和风险优先级。

接口测试最容易被 AI 写成“单接口参数校验合集”。

但真实项目里，接口通常是链路的一部分。

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

这个模板适合接口文档已经比较清楚的时候。

如果接口文档不完整，我会先用第一个模板拆需求，再让 AI 反问缺失字段和依赖关系。

AI 写自动化脚本很快，但“能跑一次”和“能长期维护”是两回事。

所以我会让它先帮我审脚本。

请以测试开发评审视角检查以下自动化脚本。重点看：1. 定位方式是否稳定；2. 等待机制是否可靠；3. 测试数据是否独立、可清理；4. 断言是否验证到了业务结果，而不是只验证页面存在或接口返回成功；5. 失败时日志是否足够排查；6. 是否存在硬编码、重复代码和环境耦合。请输出问题清单、风险等级和修改建议。

这个模板适合 Playwright、Selenium、接口自动化、JMeter 脚本初稿。

我尤其会看断言。很多脚本不稳，不是因为不会写代码，而是没有想清楚到底要验证什么。

缺陷分析里，AI 很适合做材料整理。

比如从日志、复现步骤、接口返回、用户操作路径里整理线索。

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

这个模板我会用于缺陷初步分析和复盘前准备。

但最终定性，我不会直接交给 AI。

因为它不知道你们系统真实的历史改动、发布节奏、监控口径和业务优先级。它能帮你整理线索，但不能替你背锅，也不能替你拍板。

我不太喜欢把提示词写得玄乎。

真正有用的提示词，通常不是因为句子多漂亮，而是因为它把测试人的判断框架说清楚了。

你关心业务规则，它就更容易往业务规则上想。

你关心状态流转，它就不会只停在按钮和接口返回。

你关心风险优先级，它才会尝试告诉你哪些场景应该先测。

所以，提示词不是为了让 AI 变聪明。

更多时候，是为了让我们自己先想清楚：这次测试到底要看什么。

如果你也在用 AI 辅助测试，可以先从这 5 个模板里挑一个最贴近当前工作的，别一次全用。

用完以后再看一眼：它省掉的是整理时间，还是也帮你补到了真正的风险。