测试用例这玩意儿看着不起眼却是整个质量体系的承重墙。需求文档一改用例跟着返工版本节奏一快用例根本写不完更麻烦的是有些人辛辛苦苦写了几百条评审时还是被挑出一堆“这个场景怎么没覆盖”。我做测试这几年最花时间的环节从来不是执行而是动手写用例之前的设计过程。现在主流大模型产品已经能做到一件很实际的事你只需要把需求描述扔给它它就能输出一份结构完整、覆盖了等价类、边界值、异常分支的测试用例草稿。整个过程不需要写一行代码不需要懂编程语法只要你会提需求、会看结果、会做取舍就能把写用例的时间压缩一半以上。这篇文章就是来聊这件事的不写代码怎么让 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登录正确手机号和密码登录成功用户已注册输入正确手机号输入正确密码点击登录登录成功跳转首页P0TC002登录手机号未注册无输入未注册手机号输入任意密码点击登录提示“账号不存在”P1TC003登录密码错误用户已注册输入正确手机号输入错误密码点击登录提示“密码错误”P1TC004登录空手机号或空密码提交无手机号为空密码为空点击登录按钮置灰或提示“请输入手机号/密码”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 写用例之前先让它用三句话复述一遍它理解到的需求。如果复述错了说明我的需求描述有问题这时候改描述比生成完了再推翻重来要高效得多。这个小习惯是这段时间实操下来最值得分享的一条经验。 
长河君 · 2026/10/19 15:05:41 · 阅读 1.2k 不写代码，用AI自动生成测试用例的完整实战指南
测试用例这玩意儿看着不起眼却是整个质量体系的承重墙。需求文档一改用例跟着返工版本节奏一快用例根本写不完更麻烦的是有些人辛辛苦苦写了几百条评审时还是被挑出一堆“这个场景怎么没覆盖”。我做测试这几年最花时间的环节从来不是执行而是动手写用例之前的设计过程。现在主流大模型产品已经能做到一件很实际的事你只需要把需求描述扔给它它就能输出一份结构完整、覆盖了等价类、边界值、异常分支的测试用例草稿。整个过程不需要写一行代码不需要懂编程语法只要你会提需求、会看结果、会做取舍就能把写用例的时间压缩一半以上。这篇文章就是来聊这件事的不写代码怎么让 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登录正确手机号和密码登录成功用户已注册输入正确手机号输入正确密码点击登录登录成功跳转首页P0TC002登录手机号未注册无输入未注册手机号输入任意密码点击登录提示“账号不存在”P1TC003登录密码错误用户已注册输入正确手机号输入错误密码点击登录提示“密码错误”P1TC004登录空手机号或空密码提交无手机号为空密码为空点击登录按钮置灰或提示“请输入手机号/密码”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 写用例之前先让它用三句话复述一遍它理解到的需求。如果复述错了说明我的需求描述有问题这时候改描述比生成完了再推翻重来要高效得多。这个小习惯是这段时间实操下来最值得分享的一条经验。