做测试的朋友应该都有过这种经历需求评审一开就是一下午版本排期紧得像拉满的弓功能上线前用例还没写完急得恨不得把键盘啃了。我自己就经常在想如果有个帮手能把我脑子里那些反复盘过的“正常流程、异常分支、边界值、场景组合”一口气列出来哪怕先给个初稿让我改也能省下大把时间。于是我开始认真研究“不写代码怎么让 AI 帮你自动写测试用例”。先说结论这个事完全可行而且门槛比你想的低得多。你不需要会 Python不需要会写接口脚本也不用懂什么自动化框架。你只需要把需求说清楚把规则讲明白AI 就能给你产出一份像模像样的测试用例初稿。剩下你要做的就是用自己多年的测试直觉去审核、补充、修正。这篇博文我就把我的完整思路、实操步骤、提示词写法和踩过的坑一次性全部分享出来。无论你是刚入行的测试新人还是被繁琐用例折磨多年的老手这套方法都能让你从“写用例”变成“审用例”。1. 先把思路捋清楚AI 写测试用例到底靠什么1.1 AI 生成测试用例的本质是“语言模式匹配”很多人第一次听说让 AI 写测试用例脑子里冒出来的画面是AI 自动打开某个系统自己点点点然后把用例记下来。这不对。目前你我在电脑前能免费或低成本用到的 AI 助手本质上都是大语言模型。它不懂你系统的真实界面也没法真的去点击按钮、输入数据。它擅长的是读文字、理解文字、生成文字。那它凭什么能写测试用例凭的是海量训练数据里沉淀下来的“测试思维模式”。你想想看一个经验丰富的老测试员带新人时是怎么教的新人说“测一下登录功能”老测试员会说“别光测正确用户名密码能登录你想想如果密码错了呢用户名不存在呢输入为空呢密码前后都有空格呢连续输错5次会不会锁定”这些套路本质上就是测试行业的通用智慧。大语言模型在训练阶段读过海量的技术文档、软件需求、测试博客、开源项目文档它把这些测试智慧以一种数学规律的形式“内化”了。当你用自然语言描述一个功能需求时它并不是真的理解了你系统的业务逻辑而是在做高概率的语言接龙——根据你的描述预测出最像“一个测试同行会写出来的用例”的内容。这个思考角度很重要。它决定了你该怎么使用 AI你不要指望它会“思考”出隐藏的业务规则你要把规则喂给它它才能给你匹配出对应的测试条目。1.2 与传统写用例方式的核心差异传统模式下我们写测试用例是这么个流程看需求文档 - 自己脑补各种场景 - 对照页面原型或接口定义 - 手动在 Excel、TestLink、禅道等工具里逐条敲文字。这个流程最大的痛点是“脑补”阶段特别费神。你要保证覆盖正常流、异常流、边界值、权限控制、数据校验、并发场景漏掉一个就可能上线出事故。而 AI 恰恰最擅长做“发散列举”。所以我建议的替代模式是需求文档 关键规则描述 - AI 全面列举场景 - 你人工筛选和补充业务细节。这种模式下AI 负责“广度”你负责“深度”和“准确度”。别指望 AI 一次给出来就能直接用那是不可能的。我试用过几十次之后得出的结论是AI 生成用例的合格率大概在 60% 到 70% 之间这意味着它有大量需要人修改的地方。但你从零开始写 100 条用例可能需要 3 小时而审改 AI 生成的 100 条用例最多 40 分钟。这就是它最大的价值——把你不值得花的时间抢回来。提示这段话是整个方法论的基石。你如果理解不了“AI 只是发散枚举工具不是业务专家”后面很可能被它输出的看似专业实则荒谬的用例带沟里去。2. 准备工作把需求“翻译”给 AI 听2.1 为什么你的提示词没效果我发现绝大多数人玩不转 AI 写用例问题不是 AI 太笨而是需求描述太差。你如果只甩一句“帮我写个登录功能的测试用例”AI 给你的东西基本不能看全是网上随便一搜就能找到的通用模板。比如它会给你写“验证正确的用户名和密码能够成功登录”“验证错误的用户名提示错误信息”。这些用例写得没错但毫无信息量——没有具体的错误提示文案没有边界长度没有锁定策略没有验证码交互逻辑。这种用例拿去做测试跟没测一样。问题的根源在于你给 AI 的信息量决定了它输出的含金量。你只给了“登录功能”四个字它只能还你一套“登录功能基本测试模板”这是常识。但如果你描述了具体的需求上下文它能给出的用例水平会直接升一个档次。2.2 把需求拆成“三段式”描述我实践下来最好用的提示词框架是“三段式”背景、规则、要求。第一段背景。告诉 AI 你测的是一个什么系统模块是什么面向什么用户。这么做不是废话而是给它一个选择测试策略的锚点。同样是“提交订单”B2B 后台和 C 端商城用户端的用例侧重完全不同前者重审批流、权限项后者重优惠计算、库存扣减、体验顺畅度。第二段规则。这是整段提示词最重要的一截你要把需求文档里跟功能相关的所有业务规则、数据约束、权限要求都列出来。比如“优惠券仅限新用户领取”“优惠券有效期自领取后 30 天内有效过期自动失效”“每个用户同一个活动只能领取一张”。哪怕需求文档里已经有这些内容你也得把它用更简洁的语言转述一次。为什么因为直接让 AI 读文档它也读不全而且不同 AI 工具对超长文档的解析质量参差不齐你亲手提炼规则它就省去理解环节直接进入用例生成环节。第三段要求。说清楚你要什么格式的用例。我建议明确要求包含用例编号、用例名称、前置条件、测试步骤、测试数据、预期结果、优先级。如果你要录入禅道或 TestLink建议在一开始就说“请用表格形式输出字段为上述七项”。除了三段式我还习惯在提示词最后加一句“如果规则描述中可能存在歧义请向我提问确认后再生成”很多时候 AI 会在输出前追问几个关键业务问题这能帮你提前发现需求文档里的模糊处——真的会我实测过好几次它问的问题比产品经理还细。2.3 选对 AI 工具比想象中重要做这个事市面上的主流大语言模型都行。我在不同项目里分别试用过几款通用型 AI 助手的 Web 版平时用来写测试用例免费版基本够了。选工具时我主要看三个点一是上下文长度。测试用例往往一次要生成几十条如果模型上下文太短输出到一半就断体验很割裂。选那种单次能处理几千字以上输入输出的。二是对中文的理解力。有的模型英文很强中文生成的用例总是翻译腔什么“预期的结果应当是成功的登录”看着就头疼。选中文语料更充分的。三是表格生成稳定性。我要求的输出是表格而有的模型在长表格输出时会中途丢失部分列。如果你发现 AI 生成的表格字段经常对不齐建议直接让它换用 markdown 表格格式然后自己复制到 Excel 里清洗一下。如果你是非测试人员比如产品经理想快速了解一个功能要测啥也完全可以照着这套思路来。AI 生成的用例对你来说就是一张“功能体检清单”。3. 实操演示从一句话到完整用例集3.1 功能场景示例新用户优惠券我拿最近在做的某电商平台“新用户优惠券”功能来走一遍完整流程。为了让你看得更清楚我先演示一个不合格的提问。“帮我写一下新用户优惠券功能的测试用例。”AI 大概率会生成验证新用户可以领取优惠券、验证非新用户不能领取、验证优惠券可以正常使用等。每一条都像白开水没有输入数据没有规则细节优先级也乱标优先级最高的居然是“验证新用户能领到券”实际经验告诉我们这种全项目最核心的场景反而应该是基础优先级。接下来是我实际使用的完整提示词背景我在测试一个 C 端电商 App 的营销模块有一个“新用户专享优惠券”活动。前端页面路径我的 - 领券中心 - 新用户专享。现在需要你帮我设计覆盖全面、可直接落地的功能测试用例。业务规则新用户指从未在该平台下过单且从未领过该活动券的用户。活动期间每个用户限领 1 张面额为 20 元的全场通用券满 100 元可用。优惠券有效期为领取之日起 7 天过期不可用。优惠券与限时折扣不可叠加系统自动选择优惠金额较大的方案。若用户在领券时网络异常客户端需要提供去支付页时仍然展示券的兜底逻辑以服务端发券为准。优惠券领取成功后将 5 分钟内发放至“卡包-优惠券”列表如超过 5 分钟未到账需提示用户稍后刷新查看。请输出测试用例以 Markdown 表格呈现字段包括用例编号、用例名称、前置条件、测试步骤、测试数据、预期结果、优先级。优先级分为高、中、低。请确保覆盖正常流程、异常流程、边界场景以及可能的兼容性场景。我把它发给 AI 后得到的是一个相当完整的用例表格。我数了一下它一口气列出了 38 条用例。这里我不逐一抄录重点看几条有信息量的。它写的一条前置条件是“该用户已被系统标记为非新用户需通过后台配置实现”测试步骤里居然写到“先使用该用户完成一笔任意金额订单再回到领券中心点击领取”预期结果是“提示‘您已参加过本活动’且不发放优惠券”。这就比通用模板强很多了因为它结合了我在规则里写的“新用户”定义。还有一条覆盖了业务规则 5 的异常场景“下单支付成功后未领取到优惠券再次进入领券中心页面显示该优惠券为已领取状态”预期结果为“用户进入支付页选择优惠券时系统能自动勾选该券并抵扣”。这条是 AI 根据规则 5 和 2 自己串联起来的逻辑是对的。当然它也犯了不少错。比如第 12 条写“网络断开时点击领取按钮预期提示‘网络异常请重试’”这个写法就不够严谨。实际情况中离线状态下点击领券按钮的文案提示是由客户端本地控制的不同版本可能不一致更稳妥的预期结果是“页面出现加载失败提示或客户端网络异常提示且用户可以在网络恢复后重新发起领券同一用户仍只能领取一次”。AI 看不到这种细节它只会按通用经验写。这就是我说“60 分及格剩下靠人改”的原因。3.2 接口规则示例注册功能的边界条件如果你是测接口的同样可以这么玩而且效果更好因为接口测试用例更依赖参数化输入。很多同学写接口用例时只写“正常传参成功”“必填项缺失报错”弄得像是从填空题里抄的。AI 反而更擅长枚举边界值。我建议的提示词背景我需要对用户注册接口进行黑盒测试接口定义如下POST /api/v1/user/register入参为 username、password、email、verification_code其中 username 是手机号。已知规则手机号必须是 11 位且以 1 开头第二位需在 3、5、7、8、9 内。密码长度 8-20 位必须同时包含数字和字母不能包含用户名连续三位子串。email 格式需符合标准正则但允许该字段为空空时按账号登录处理。verification_code 有效期为 5 分钟每个手机号 10 分钟内最多发送 3 次验证码验证码错误超过 5 次后当天不可再发送。同一手机号仅能注册一次注册成功后再次注册返回错误码 10001。请针对该接口生成边界值和异常流测试用例重点关注手机号格式边界、密码长度边界、验证码过期以及并发注册的场景。输出字段用例编号、一级场景、测试数据JSON 格式、预期返回码、预期响应信息。我拿到 AI 输出后里面有几条让我印象特别深一条是“username 为 138123456710位时预期返回错误提示 手机号格式不正确”这个属于基础边界大多数有经验的测试也能想到。但 AI 还顺带写了“username 为 13812345670校验位不符的11位时预期提示手机号格式不正确”以及“username 为 12812345678第二位为 2时提示手机号格式不正确”这个其实是需求规则里隐含的。如果当初我只在需求文档里写一句“手机号需合法”这些用例就得我自己凭经验一条条补。更妙的是并发注册那条它给出的测试数据是“两个并发请求同时携带相同的 username 发起注册”预期结果是“一个成功一个返回 10001 且数据库不产生重复记录”。这条指引我去问开发了并发唯一性怎么保证答复是“数据库唯一索引 应用层分布式锁”我不问这个点就漏了。3.3 提示词迭代技巧让 AI 把草稿越改越细一次生成往往不够用。我的习惯是分两轮来第一轮按“广度优先”让它把所有可能的场景都列出来第二轮挑重点场景让它“钻透”。具体做法是这样收到第一版用例后我会挑选出几个高风险点追加一条指令“针对用例编号 TC-014 优惠券领取成功但未到账系统异常状态下服务端已发券成功但客户端未展示领取结果请继续深挖以下场景用户在页面中途退出后重新进入时如何触发补发逻辑用户误关 App 后再次打开卡包页展示的优惠券是否实时更新如果调用查询接口超时客户端有没有兜底展示”这种追问式对话能把 AI 从一个“通用枚举器”变成“被测系统的专属分析器”。而且第二轮产出的用例往往比第一轮更有价值因为它是基于第一轮的上下文进行推理的AI 已经“记住”了你系统的一些细节设定给出的分析会更贴边。注意当 AI 开始生造你从未提及过的文案、规则、字段时你要警惕。比如我遇到过 AI 自己虚构了一个“该券每人限领一次且需当日用完”的规则我根本没有提过“当日用完”。这可能是它的训练语料中大量优惠券规则里高频出现类似的描述被“顺嘴”带出来了。遇到这种务必删掉或找需求确认。4. 常见问题与避坑实录AI 踩过的那些坑我替你先踩了4.1 为什么 AI 写的用例“看着像那么回事一执行就废”这是新手最容易中招的点。AI 生成的用例经常缺关键要素最典型的是测试数据特别模糊。它写“输入一个不存在的手机号”“不存在的手机号”具体是什么是一串数字吗还是空格还是 0还是包含中文的字符串你拿到手还得自己去补数据。我的解决办法是在提示词里加一条强制约束“每条测试数据必须具体到可直接执行不允许出现‘正确的’‘无效的’‘不存在的’这类抽象描述必须给出实际值。”加了这条之后AI 的输出质量会有肉眼可见的提升很多模糊表达直接被过滤掉了。4.2 AI 脑补需求细节怎么办前面提到过AI 为了回答得完整会不自觉补全你认为没制定的规则。它在训练资料里读到的常规测试用例都是完整覆盖各种场景的一旦你给的规则太少它就只能“猜”。举个例子我让它测一个“分享赚佣金”的功能只说了“分享成功后好友注册可得积分”它居然生成了一条“好友注册后 24 小时内完成首单分享人可获得额外 5 元佣金”实际上我们产品根本没有这个规则。这在业务上是个严重错误。处理方式很直接第一轮生成后拿 AI 的用例逐条和需求文档对照凡是没有现依据的条目全部删掉或标为“待确认”。如果你发现自己每次都要删很多大概率是你提示词里的业务规则写得太少了。试着回到需求文档把数字类型的规则比如“满100减20”“每人限领3张”“有效期7天”尽可能多地填进去。4.3 用例数量失控怎么收敛AI 有时会给你生成一个超大体量的用例集80 条起步全项目级功能直接干到 200 条以上。这其实不怪它因为你给它的指令是“确保全面”它只能按字面意思往多了写。有用吗有一半是有用的但另有一半是重复或者过于犄角旮旯的场景全部录入用例系统会污染统计指标。我现在会在提示词里加一段“冗余控制”“相同业务规则下相似测试场景只保留最有代表性的一条。出现重复时合并同类项并保留更严格的那条。最终输出用例数量控制在 40 条以内。”用这个约束后输出数量基本能落到 35 到 50 条之间属于刚刚好。4.4 优先级永远是个玄学AI 对优先级的判断基本不可靠。它经常会把“验证正常领取成功”标为“高”把“优惠券过期后用户仍能看到券但不可用”标为“中”。实际上做过几年测试的人都知道过期券不可用一旦出错就是资金风险级别的线上事故必须是高优先级。所以我现在的做法是AI 输出的优先级直接忽略我自己过一遍后统一重标。我更看重的是它帮我找全场景而不是替我判断重要性。4.5 我的独家避坑清单最后分享几条文字版的经验都是我实际操作中总结出来的。第一版本迭代时把上一版本的提示词保存成模板下次改动只用替换规则段落效率和一致性都会高很多。第二不要让 AI 一次性同时生成“功能用例接口用例兼容性用例”混在一起它会顾此失彼。宁可分成三次提问每次聚焦一个测试类型。第三AI 生成的用例建议过一遍“Negative Testing 四板斧”能不能不发请求能不能乱传参数能不能超范围传参能不能依赖已删数据这四个方向 AI 靠自己写不全你手动补一补就齐活了。5. 进阶玩法让 AI 从一次性工具变成你的测试助理5.1 用“对话式迭代”把一次性生成变成持续打磨很多人得到一份用例就算完事了这是白白浪费了 AI 的能力。其实它的价值在于陪你反复打磨。我常用的一个玩法是把 AI 生成的用例复制回去然后说“请检查以上用例中是否有遗漏的权限校验场景”或者“如果这个功能要兼容 iOS 16 和 Android 11 及以下版本请补充系统差异可能导致的用例”。这种逐步加需求的对话能让用例集越来越贴近真实项目。更实用的一招把历史线上缺陷报告的描述片段喂给 AI让它基于这些“前科”生成回归测试用例。它的思路和人工专家基本一致凡是出过大问题的地方一定要回归重点关照。5.2 建立自己的提示词模板库我现在的习惯是每测完一个模块就把这次用的提示词保存下来存进一个私有的文档库里。文件命名按项目、功能、类型来区分比如“电商后台-促销活动-接口测试提示词”。下次遇到相似功能的模块直接把规则换掉复用10 秒钟就能生成一个新项目的用例初稿。这个库积累到十条以上之后你基本就再也不想从零开始写用例了。5.3 未来可以继续延伸的方向现在这个方案有个前提就是“输出用例给人看”。如果你想更进一步把 AI 生成的用例自动转换成可执行脚本其实也有一脉相承的套路——你再让 AI 把用例表格翻译成 pytest 或 JMeter 脚本结构自己稍作填充就能用于自动化回归。也就是说这个思路往深了走其实是在给自动化测试铺路。如果你已经在用在线聊天式的 AI 助手最快上手的方式就是今天讲的“三段式”提示词。先别管什么高阶方法论找一个你最熟悉的模块按我说的写背景、列规则、要表格跑一次你就懂我在讲什么了。我个人实际用下来最大的感受是AI 帮写用例最爽的不是“快”而是它敢给出你想不到但合理的组合场景。我工作五六年自认为边界值想得挺全但它有几次给出来的场景确实让我愣了几秒。从那以后我就不再把它当“自动生成工具”了更像是一个永远不嫌烦的结对测试伙伴。文章最后一个实用建议下周你手头有新模块要测别马上打开 Excel。先花 15 分钟整理需求规则建一个简易提示词把 AI 生成的结果和你自己写的初稿对比一下大概率你会舍不得丢掉 AI 那一版。