本职是测试工程师，写用例是日常。去年开始把 AI 掺进流程里，现在我的做法是：AI 负责初稿和穷举，人负责判断和取舍。速度确实快了，但直接照搬它的产出，测试报告会很难看。这篇把真实流程拆开讲，包括我踩过的三个坑。
先说结论：AI 擅长哪段，不擅长哪段
测试用例的本质是「输入 + 操作步骤 + 预期结果」。前两样 AI 写得又快又全，第三样经常出问题——预期结果需要业务知识，模型没有你的业务上下文，它给的预期往往笼统到没法执行。
所以分工是这样的：正常流程和边界条件的初稿交给 AI，异常场景让 AI 穷举我来筛，涉及业务规则和数据状态的预期结果自己补。这三条记住了，后面全是细节。
我的实际流程，四步
第一步，喂需求，不给代码。把 PRD 或者需求描述整理成纯文本给 AI，明确告诉它平台（Web 还是 App）、测试类型（功能/兼容/安全）、用例格式。注意别把公司内部代码和真实用户数据直接贴进公网模型，脱敏是底线。
第二步，先要大纲再要用例。直接说「帮我写登录模块的测试用例」，拿到的往往是一堆粒度混乱的条目。我的提示词固定是两轮：先让它列测试点和场景分类，我确认没问题，再让它在每个场景下展开用例。多花一轮对话，返工少一半。
第三步，异常场景单独追问。正常流程 AI 写得不错，但异常场景容易漏。我会追问：「登录模块还有哪些容易被忽略的异常场景？」它通常会补出验证码过期、密码连续错误锁定、第三方登录回调超时这类，补完覆盖率能上一个台阶。
第四步，预期结果逐条过。AI 写的预期经常是「登录成功」四个字，这没法执行。我会把涉及业务规则的条目挑出来，自己补上具体状态：比如「连续错 5 次锁定 30 分钟，期间提示文案为 XX，数据库 user 表 status 字段变为 2」。这一步不能省。
一个能直接抄的提示词
第二轮展开用例时，我用这个模板（可按需替换需求内容）：
「你是一名资深测试工程师。以下是某 Web 系统登录功能的需求描述：[贴需求]。请按『用例编号 / 模块 / 前置条件 / 操作步骤 / 预期结果 / 优先级』的格式，为每个测试点写出详细用例。要求：预期结果必须写到可执行的粒度（页面提示、字段校验、数据状态变化）；边界值要给出具体数字；不要写『正常』『成功』这类笼统描述。」
关键是最后那句否定式约束。不加的话，十有八九给你「登录成功，进入首页」这种句子。
踩过的三个坑
坑一：把 AI 的输出当完整覆盖。有次我直接把 AI 生成的 60 条用例导进测试管理平台，评审时老测试工程师一眼看出缺了「多端同时登录互踢」的场景。AI 的覆盖率是「看起来全」，不是「真的全」。需求评审该提的问题，一个都不能少问。
坑二：预期结果带幻觉。AI 有时会编造不存在的提示文案，甚至编一个系统里根本没有的错误码。所以预期结果里凡是具体的文案、数字、状态码，我一律和需求文档或开发确认过才保留。
坑三：用例粒度忽粗忽细。同一次输出里，有的条目一行写完，有的拆成五个步骤。后来我在提示词里强制了格式模板，才算稳定下来。粒度不齐的用例，执行估时全乱。
省下来多少时间
拿一个中等复杂度的模块来说（40 到 60 条用例的量）：以前纯手写加自审要大半天，现在 AI 出初稿 10 分钟，我逐条修正和补业务预期 40 分钟上下，整体大概省一半时间。但有个前提：需求文档本身写得清楚。需求本身模糊时，AI 只会放大模糊，这时候老老实实先找产品对齐。
一句话收尾：AI 把用例编写从体力活变成了审核活。活儿是变轻了，但审核的人得知道自己到底在审什么。
相关阅读：我用 AI 做数据分析的 3 个真实场景、我用AI做了这5件事，每个月省下20小时。面试季的朋友也可以看下之前整理的 AI 面试提示词。