测试用例这玩意儿，看着不起眼，却是整个质量体系的承重墙。需求文档一改，用例跟着返工；版本节奏一快，用例根本写不完；更麻烦的是，有些人辛辛苦苦写了几百条，评审时还是被挑出一堆“这个场景怎么没覆盖”。我做测试这几年，最花时间的环节从来不是执行，而是动手写用例之前的设计过程。现在主流大模型产品已经能做到一件很实际的事：你只需要把需求描述扔给它，它就能输出一份结构完整、覆盖了等价类、边界值、异常分支的测试用例草稿。整个过程不需要写一行代码，不需要懂编程语法，只要你会提需求、会看结果、会做取舍，就能把写用例的时间压缩一半以上。这篇文章就是来聊这件事的：不写代码，怎么让 AI 帮你自动写测试用例，以及中间有哪些坑必须绕开。
注意一点：我说的“不写代码”，不是让你彻底放弃思考，而是把“从需求到用例”这件重复性很强的工作交给 AI 完成，你专注在最关键的地方——需求是否正确、场景是否完整、结果能不能用。下面直接上干货。
1. 先想明白：AI 替你写的到底是什么
1.1 手工写用例的真正痛点在“设计”而不是“打字”
很多人以为写用例费时间是因为打字慢，其实不是。真正费时间的是“设计”：拿到一段需求，先要理解业务规则，再要想有哪些正常路径、哪些异常路径、哪些边界条件、哪些隐含约束。比如一个最简单的“用户登录”，表面上就一个功能，实际拆起来至少包含：账号不存在、密码错误、密码连续错几次锁定、锁定后多久解锁、验证码过期、重复提交、网络超时、异地登录提醒、账号禁用……这些场景全靠人脑一个个想，既考验经验，也考验耐心。
更现实的问题是，手工写用例时，人的注意力会疲劳。写到第 30 条的时候，脑子里想的和需求文档上写的已经对不上了，漏测就成了必然。我见过不少团队，用例数量看起来很多，但覆盖率一评估，核心的正常流程写了七八遍，异常流程和边界条件反而一片空白。这也就是为什么 AI 辅助生成用例的切入点，不是替你打字，而是替你做“穷举”和“模板化拆分”。
1.2 AI 写用例的本质是“需求翻译”和“模式套用”
必须泼一盆冷水：AI 并没有真正理解你的系统，它也不会打开你的软件去点按钮。它做的是两件事。
第一件事是“需求翻译”。你给它一段自然语言描述，比如“用户可以用手机号和密码登录”，它会把这个描述拆成主语、动作、对象、条件，然后转化成测试动作：输入手机号、输入密码、点击登录、验证跳转结果。
第二件事是“模式套用”。大模型在训练过程中读过海量测试用例文本，它知道一份“标准测试用例”长什么样，也知道测试设计里那些经典方法——等价类划分、边界值分析、场景法、错误推测法。它不一定懂你业务里的业务规则，但它知道“数字输入通常要测 0、负数、小数、超长数字”这类通用规则。于是它就把这些通用模式套到你给的特定需求上，批量产出用例。
所以人机分工其实很清晰：你负责提供需求上下文、业务规则、验收标准，AI 负责按套路产出初稿，你再负责审校和取舍。理解了这个底层逻辑，后面所有操作就都说得通了——为什么必须把需求写清楚，为什么 AI 输出的东西不能直接交付，为什么多轮追问比一次生成更靠谱。
2. 不写代码也能驱动 AI 做测试设计的四种方式
2.1 方式一：把需求文档“喂”进去，让它直接产出结构化用例
这是最基础、也最好上手的用法。你需要做的，就是把需求描述复制粘贴到对话框里，然后告诉 AI 你想要什么。注意：不是只丢一句话，而是把功能背景、涉及角色、业务规则、限制条件都给它。
我常用的提示词长这样：
我有一段关于XX功能的需求描述，请你基于这段描述，帮我生成一份测试用例。 要求： 1. 每条用例包含：用例编号、所属模块、用例标题、前置条件、测试步骤、预期结果、优先级。 2. 覆盖正常流程、异常流程、边界值、权限校验四类场景。 3. 如果需求中某些条件描述不清晰，先用"待确认"标注，不要自行假设。 4. 输出格式使用 Markdown 表格。 以下是需求描述： [粘贴需求内容]这段提示词的效果非常直接。AI 会按你给的字段结构输出一张用例表格，而且因为加了“待确认”这个约束，它会在需求含糊的地方主动标出来，而不是瞎编。这个细节非常重要，它相当于给 AI 安装了“自知之明”模块。
2.2 方式二：设定“测试专家”角色，强制它按方法论出题
有时候你想让 AI 不只生成用例，还想让它用专业测试方法论来设计。这时候要给它做角色设定，把方法名称直接写进去，它会按方法论的框架去思考。
我常用的设定是这样：
你是一位有十年经验的测试设计专家，精通等价类划分、边界值分析、判定表、场景法和错误推测法。 现在要测试的功能是：用户注册。 请你分别使用等价类划分和边界值分析，产出测试用例草稿。 要求：先列出你划分的等价类和边界值依据，再输出用例表格。加了“先列出依据”这一步，AI 就不再只是机械地输出条目，而是会告诉你“它为什么这么测”。这个过程对新手特别有帮助，相当于免费请了一位老师傅在旁边讲解测试设计的逻辑。
2.3 方式三：让 AI 当“需求拷问官”，反向补全场景
这个思路很多老手都不知道：与其直接让 AI 写用例，不如先让它审需求。在需求不完整、描述含糊的时候，AI 最擅长做的就是“挑毛病”。你可以这样问它：
请对以下需求做测试视角的评审，列出所有会导致测试用例无法设计的漏洞和歧义。 例如：字段未定义边界、角色权限未说明、异常状态未覆盖、数据要求不明确。 每条问题请说明：问题描述、为什么影响测试、建议补充什么信息。这个模式特别适合在需求评审会之前使用。我习惯提前把 PRD 丢给 AI，让它生成一份“测试风险清单”，然后带着这份清单去和产品对需求。你会发现，很多以前要靠经验才能发现的死角，AI 能帮你提前挖出来。比如“密码错误多少次锁定”这个数字，需求里如果没写，AI 会直接标出来，而不是替你假设一个 5 次。这才是真正的“不写代码”也能参与测试设计。
2.4 方式四：让 AI 批量生成测试数据
写用例是一件事，造数据又是另一件事。很多测试用例卡在一个地方：数据造不出来，用例就是纸上谈兵。AI 在造测试数据这件事上简直是天赋点满。你只需要给它字段规则和需求约束，它就能批量产出。
举例来说，你要测试一个“报名年龄限制在 18 到 60 岁”的功能，可以直接让 AI 生成一张数据表：
请为"年龄字段"生成一组测试数据，要求覆盖： 1. 有效等价类：18岁、60岁、25岁； 2. 无效等价类：17岁、61岁； 3. 边界值：18岁、17岁、60岁、61岁； 4. 特殊值：空值、0、负数、小数、字母、超长数字、含空格的数字。 每条数据给出输入值和预期结果，并用表格输出。这样一份数据表拿过去，基本不需要再动脑想数据。需要注意：AI 生成的测试数据只能作为“候选数据”，涉及真实业务规则（比如身份证校验、手机号段、地区编码）时，一定要用业务样例数据二次校验，否则容易被表面正确、实际不合规的数据坑到。
3. 一个完整实例：从一段需求描述到一份可评审的登录用例
3.1 先准备一段“能看”的需求素材
为了让整个流程更可感知，我用一个最常见的功能——用户登录——来完整演示。假设需求文档里写的是这样一段话：
用户可以使用手机号和密码登录系统。登录成功后跳转到首页。 密码连续输入错误 5 次，账号会被锁定 30 分钟。 锁定期间即使输入正确密码也不能登录，需等待 30 分钟自动解锁。 账号支持"记住我"功能，勾选后 7 天内免登录。注意，即便是这么短的需求，里面隐藏的测试点也已经非常多。现在看 AI 如何逐层拆解。
3.2 第一轮：生成用例主干
我直接把需求粘进去，配上最开始那个通用提示词，AI 输出的结果节选如下（只展示关键几条）：
| 编号 | 模块 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 优先级 |
|---|---|---|---|---|---|---|
| TC001 | 登录 | 正确手机号和密码登录成功 | 用户已注册 | 输入正确手机号，输入正确密码，点击登录 | 登录成功，跳转首页 | P0 |
| TC002 | 登录 | 手机号未注册 | 无 | 输入未注册手机号，输入任意密码，点击登录 | 提示“账号不存在” | P1 |
| TC003 | 登录 | 密码错误 | 用户已注册 | 输入正确手机号，输入错误密码，点击登录 | 提示“密码错误” | P1 |
| TC004 | 登录 | 空手机号或空密码提交 | 无 | 手机号为空，密码为空，点击登录 | 按钮置灰或提示“请输入手机号/密码” | P2 |
这四条只是主干，但已经覆盖了“成功、失败、空值”三个方向。你肯定已经意识到：很多东西它还没写，比如锁定、解锁、记住我。这正是下一步要做的。
3.3 第二轮：追边界、追异常、追权限
第一轮输出之后，我继续追问：
请检查上面这些用例，再补充三类场景： 1. 关于密码错误5次锁定的边界：第4次、第5次、第6次、锁定期间、解锁后重置的状态； 2. 关于"记住我"：勾选后关闭浏览器再打开、跨设备是否生效、7天过期边界； 3. 关于安全和并发：同一账号多端登录、密码输错后是否有验证码、频繁请求是否被限制。这一轮追问之后，AI 会抛出大量你只靠肉眼想不到的用例。比如：
- 连续输入 4 次错误密码后，第 5 次输入正确密码，是否还能正常登录（关键：计数什么时候清零）；
- 账号锁定后，输入正确密码是否提示“锁定”而不是“密码错误”；
- 锁定状态下进行密码找回，是否还能用旧密码登录；
- 勾选“记住我”后，卸载重装 App，免登录是否失效；
- 同一账号在手机端登录状态下，PC 端再登录，手机端是否被踢下线。
这些场景很多是从需求和开发实现的交界处“挖”出来的。单独靠人想，容易漏，但 AI 按“异常和边界”的方向穷举时，能帮你补上大片盲区。
3.4 第三轮：收敛成团队可用的交付格式
穷举完之后，最后一步是收敛。我会对它说：
请把以上所有用例合并去重，删除与需求无关的内容，调整优先级， 按标准字段输出完整用例表：编号、模块、用例标题、前置条件、测试步骤、预期结果、优先级。 其中锁定的边界值必须覆盖第4次、第5次、第6次和第30分钟解锁前后。这轮输出就是可以拿去做用例评审的交付物了。到这一步，你已经完成了从一段 50 个字的需求描述，到一份包含几十条可评审用例的全过程，全程没写一行代码。如果换成手写，这个量级至少需要半天，AI 辅助下半小时内基本搞定。
4. 结构化提示词的核心技巧：角色、背景、任务、格式、约束
4.1 提示词五要素拆解
用过几轮之后你会发现，AI 输出的质量很大程度上由提示词决定。同样一个 AI，有人让它写出来的用例能直接用，有人写出来的全是正确的废话。差别就在于提示词有没有把下面五件事说清楚。
角色：你是一位资深的测试设计专家，擅长黑盒测试和边界分析 背景：我正在测试一个[XX类型]的业务系统，用户角色包括普通用户和管理员 任务：请针对[XX功能]生成一份覆盖正常、异常、边界、权限的测试用例 格式：用Markdown表格输出，字段包含编号、模块、用例标题、前置条件、测试步骤、预期结果、优先级 约束：只能基于我提供的需求生成，需求中未提到的功能不要自行添加；优先级划分要明确角色让 AI 调用对应领域的知识库；背景让它理解业务上下文；任务明确目标；格式约束输出结构；约束防止它跑偏。这五要素里，最容易被忽略的是“背景”。只给一句“帮我写登录测试用例”和告诉它“这是一个电商后台管理系统，包含买家、卖家和平台管理员三种角色”，输出质量会完全不同。AI 理解的业务上下文越丰富，生成用例的贴合度越高。
4.2 多轮追问：一次生成只是开始
新手最常见的误区是把 AI 当单选题，问一次就结束，拿到结果不满意就重来。其实 AI 对话最适合的是“渐进式追问”。我习惯采用“主干 → 边界 → 异常 → 收敛”四轮节奏，每一轮都以上一轮结果为基础。
追问时有一个很好用的句式：“请检查上面生成的内容，然后用列表抓出遗漏。特别是以下方向：数据边界、时序竞争、权限绕过、第三方依赖、性能异常。”这种指令会让 AI 主动进入“查漏补缺”模式。实测下来，第二轮追补的用例通常比第一轮还多，质量也更高，因为它的思考方向被强制聚焦到了高价值盲区。
4.3 把 AI 训练成团队内部的“习惯”
如果你长期负责某一类系统，不要每次重新写提示词，而是把整个测试模板固定下来。做法是：先让 AI 生成一份“通用用例模板”，然后保存下来，之后每次生成新功能用例时，直接把模板内容和新的需求描述一起贴给它。
我举个例子，一个标准的“通用字段校验模板”包含：必填校验、类型校验、长度校验、格式校验、重复提交校验、权限校验、特殊字符校验、边界值校验。每次接到新需求，只要把需求中实际用到的字段列出来，让 AI 按模板覆盖，它就能快速套出大部分用例。这个习惯的价值在于，团队里的用例风格会趋于统一，评审效率也会明显提升，不再出现“同一个功能，三个人写三套不同字段结构”的混乱情况。
5. 不写代码，如何让用例真正“跑”起来
5.1 把 AI 生成的用例接入测试管理流程
用例生成只是第一步，真正让它在项目里发挥价值，要把它接入测试管理流程。我建议走一遍这样的链路：AI 生成用例草稿 → 测试负责人评审修改 → 补录需求追踪关系 → 导入测试管理平台 → 分配给执行人。
导入字段时要注意，AI 输出的字段通常只有纯文本，但很多测试管理平台要求“用例标题”和“测试步骤”分开维护，步骤还可能拆成“步骤编号、动作、预期”。所以我在提示词阶段就有意固定字段，让 AI 直接输出平台兼容的格式。如果平台只接受 Excel 格式，可以让 AI 输出 CSV 或者表格后手动粘贴到在线表格里，再批量导入。这个环节不需要编程，但需要细心，别在导入阶段把用例编号弄乱。
5.2 再进一步：低代码录制回放工具和 AI 写用例的关系
说完文本用例，顺便聊一下“不写代码做自动化”。很多人会问：AI 都能写用例了，能不能顺带把自动化脚本也写了？答案是：如果真的一行代码不会，最稳妥的路线是用录制回放类工具，而不是让 AI 直接生成脚本。AI 生成的是“做什么”的测试设计，录制回放工具完成的是“怎么做”的自动化执行。这两件事不是一回事。
录制回放工具的原理是：你手动操作一遍界面，工具记录操作步骤，然后自动重放。很多这类工具都有导入测试步骤的入口，你可以把 AI 生成的用例步骤直接作为手工操作脚本，按顺序录进工具。这样，整个链路就变成了：AI 写测试设计 → 人工评审 → 录制回放工具实现自动化。全程不需要懂编程语言。
需要提醒的是：不是所有用例都适合自动化。登录这类高频率、稳定路径的用例很适合；而涉及视觉验证、复杂业务规则判断的用例，当前阶段仍然是人工执行更可靠。别为了“自动化”而自动化，用例本身的价值永远是第一位的。
6. 常见问题与避坑实录
6.1 为什么 AI 生成的用例有时“不能用”，问题出在哪
AI 生成用例踩坑太正常了，下面这份问题清单基本覆盖了大多数情况：
| 常见表现 | 原因 | 应对方法 |
|---|---|---|
| 用例内容太泛，全是“输入有效数据，验证结果正确” | 提示词里缺少具体字段和边界约束 | 把字段规则、数据类型、长度上限写进提示词 |
| 格式混乱，字段一会儿有、一会儿没有 | 没有指定输出格式和字段清单 | 在约束里写死字段：编号、模块、标题、前置条件、步骤、预期、优先级 |
| 生成了需求里不存在的功能 | AI 自行脑补 | 加一条约束：只能基于提供的需求生成，未提到内容不得添加 |
| 异常场景覆盖不足 | 一次生成只走了正常路径 | 使用多轮追问，明确要求覆盖边界、异常、权限 |
| 用例数量爆炸，大量重复 | 没有去重和合并要求 | 最后加一轮收敛指令：合并去重、删除无关内容、按优先级排序 |
这些问题的根源，都不是 AI 不行，而是“需求输入不完整”和“提示词约束不够”。你在提示词里写得越具体，AI 的产出越可用。
6.2 适合 AI 生成与必须人工介入的边界在哪里
经验沉淀下来，我总结了一条简单的分工线：
适合 AI 生成的，通常是“结构化强、通用规则明确”的内容，比如字段校验、增删改查正常流程、登录鉴权、边界值、数据格式错误、权限角色矩阵、回归测试素材。这类用例套路固定，AI 产出质量高，人只需要审。
需要人工深度介入的，通常是“强业务规则”和“强上下文”的内容，比如复杂的促销计算规则、跨系统数据一致性、法律法规合规要求、真实用户使用习惯、历史遗留系统的隐性逻辑。AI 不知道你系统的“历史包袱”，也不可能从一段描述里猜出最新的业务补丁，这部分必须由最懂业务的测试人员把关。
最平衡的状态是：AI 产出 70% 通用模板化用例，人聚焦解决 30% 高难度业务场景，然后全量过一遍评审。这个比例在实践中既保证了覆盖率，也控制了人力成本。
6.3 三条必须记住的安全与协作红线
第一，不要把敏感信息直接贴给 AI。真实账号、手机号、身份证号、密钥内部数据，在不确定是否安全的情况下，一律脱敏后再使用。测试数据就用虚构的、符合规则的假数据。
第二，AI 生成的用例不能作为终稿。它唯一的身份是“草稿”和“提示器”。凡是涉及验收、发布、合规的用例，必须经过评审确认，并且和需求版本做好绑定关系。
第三，需求变更后，不要手动在旧的 AI 输出上小改。我吃过这个亏：新增了一个字段，以为在旧用例上补两条就完事了，结果漏掉了字段组合的连带场景。正确做法是把变更后的完整需求重新喂给 AI，让它重新生成，再对比差异。这样才接得住变化，也不容易漏。
另外多说一句：AI 的工作成果能不能被团队接受，关键不在工具，在于你有没有一套“AI 生成 → 人工评审 → 模板沉淀 → 复用优化”的闭环。没有这个闭环，AI 只会是偶尔玩玩的新鲜玩意儿；有了这个闭环，它才真正变成团队产能的一部分。
我自己实际用了半年多，最深的体会是：AI 没有让测试变简单，它只是把“从零开始”变成了“从 70 分开始”。我不需要再面对空白页面冥思苦想，但我要花更多精力去质疑、去验证、去改进。一开始总觉得 AI 生成的内容不够好，多试几轮之后才明白，不够好恰恰是因为我给它的输入还不够清晰。后来我养成一个习惯：每次让 AI 写用例之前，先让它用三句话复述一遍它理解到的需求。如果复述错了，说明我的需求描述有问题，这时候改描述，比生成完了再推翻重来要高效得多。这个小习惯，是这段时间实操下来最值得分享的一条经验。
