最近不少测试同学都在讨论AI生成测试用例这个话题。有的团队直接用ChatGPT、Cursor或者专门的AI测试用例生成平台让AI按需求描述输出一版用例结果拿回来一看结构确实漂亮步骤也清晰但真拿着去执行的时候总差点意思——要么断言写得太模糊要么边界条件完全漏掉更离谱的是AI会一本正经地描述一个系统里根本不存在的按钮。所以“AI生成测试用例怎么人工审核”就成了绕不开的实操问题。这篇文章不聊虚的直接讲清楚AI生成的测试用例到底有哪些坑、人工审核该按什么流程走、不同维度用例功能、接口、安全、登录分别该盯哪些重点以及怎么避免AI幻觉对用例质量的污染。适合正在试用AI辅助测试的QA、测试开发也适合想给团队搭建“AI生成人工审核”流程的测试负责人。1. 为什么AI生成的测试用例必须先过一遍人工审核很多团队上AI生成测试用例初衷是省时间。AI确实快给一段需求描述几十秒就能输出几十条用例省掉从0到1的起草成本。但省时间的前提是“有人兜底”。AI生成用例不是终态只是初稿它有三个绕不开的缺陷。1.1 AI生成的测试用例看着全其实暗藏三类坑第一类坑叫“结构完整但内容失真”。AI很擅长模仿测试用例模板前置条件、测试步骤、预期结果写得有模有样但里面的细节可能是它自己脑补的。比如需求里说的是“用户输入手机号”AI默认手机号是11位但实际项目里可能支持港澳地区8位号码再比如需求写“上传图片”AI自动生成“支持jpg/png格式”而实际系统只允许jpg。这些细节不人工核对执行时就是一堆失败用例。第二类坑叫“覆盖率高但深度不足”。AI能覆盖正常流程、异常流程、权限校验这些常见维度但等价类划分、边界值选取、业务规则组合这些靠“业务理解”才能做好的事它做得并不好。比如金额字段只测了正整数漏了0、负数、小数、超大数、科学计数法列表分页只测了第一页漏了最后一页和空数据场景。表面看AI生成了50条用例真正有价值的可能只有20条。第三类坑最隐蔽叫“幻觉”。AI会把不存在的功能写进用例比如系统根本没有“记住密码”选项AI却生成了一条“勾选记住密码后重新打开App验证登录状态”的用例再比如AI把接口返回字段名写错导致断言根本无法对上。这类用例如果直接流到执行环节纯属浪费人力甚至误导开发修一个不存在的bug。1.2 审核不是“重写”而是“过滤补全校准”听到这里有人会问既然AI生成这么多问题为什么还要用我的看法是AI的价值在于“批量出稿”人工的价值在于“判断和修正”两者根本不是替代关系。人工审核的定位应该是三道工序。第一道叫过滤把幻觉用例、重复用例、无效用例直接删掉或标记废弃这一步能砍掉大约30%到40%的垃圾条目。第二道叫补全AI漏掉的边界条件、业务规则冲突、异常场景由审核人手动补充进去。第三道叫校准把模糊的步骤改清晰把不明确的预期结果改成可验证的断言把缺失的前置条件和测试数据补上。换句话说审核人是“主编”AI是“实习生”。实习生交来的稿子主编当然要改但不是全部推翻重写而是圈出问题、改掉硬伤、补充视角。这样才能既享受AI的效率又不牺牲用例质量。1.3 哪些测试用例可以放心交给AI哪些必须谨慎不是所有测试用例都适合AI生成这一点审核前就要有判断。拿我自己的经验来说低风险、高重复、强规范的用例可以大胆让AI生成然后快速审核。典型的是接口字段校验用例、登录页面的基础输入校验、表单必填项校验、CRUD的常规操作路径。这类用例有固定套路AI生成的准确率很高人工只需要扫一眼关键断言。高风险、强业务、多系统交互的用例就必须谨慎。典型的是涉及订单金额计算的用例、优惠券叠加规则、支付回调状态流转、多角色权限交叉场景。这类用例依赖业务知识AI很容易“想当然”。比如AI可能默认所有优惠券都能叠加但业务规则是“满减券和折扣券互斥”。这种场景下AI生成的用例只能当参考大纲审核人必须用真实业务规则逐条校正。另外还要警惕一点如果需求文档本身写得就很模糊AI生成的用例质量会更差。那种情况下审核的重心反而要先放在“需求澄清”上而不是急着改用例。需求都飘着用例改得再精细也是空中楼阁。2. 人工审核的高效流程先结构化再逐条过人工审核最怕的是拿到AI生成的用例就从头到尾一条条看看完整个人都麻了。没有结构化的审核流程很容易漏掉关键问题而且效率低。2.1 审核前准备明确准入标准和测试需求上下文开始审核之前有两件事必须先做。第一件事是准备需求基线把需求文档、原型图、接口文档、验收标准全部放在手边。AI生成用例时往往只看了一段模糊的需求描述它看到的上下文远不如审核人完整。审核人手里有完整的需求文档才能判断AI生成的用例是否偏航。第二件事是确定“可接受标准”。也就是什么样的用例算合格这可以做成一份内部checklist。比如是否覆盖正常流程是否覆盖主流程分支是否包含至少一条异常输入用例预期结果是否明确可验证是否包含前置条件和测试数据要求如果AI生成的用例能通过这份checklist基本可以进入执行通不过的才需要逐条修改。这份checklist最好根据实际项目不断迭代比如支付类项目要加“金额精度是否一致”登录类项目要加“是否包含锁定策略验证”接口类项目要加“断言是否包含状态码和关键业务字段”。有了checklist审核就不再是凭感觉而是有依据的流程。2.2 核心审核五步法我习惯把审核拆成五步按顺序走下来基本不会漏大问题。第一步做整体通读。先花5分钟把AI生成的用例从头到尾扫一遍不要急着改。扫的过程中重点感受三点用例是否覆盖了需求的各个功能点是否明显存在大量重复是否出现了与系统现状完全不符的内容这一步能筛掉最明显的幻觉和重复相当于拿到医生写的报告先看个大概而不是直接盯着某个指标。第二步对照需求逐条核对功能点。拿需求文档里的功能列表逐项和用例比对。比如需求里有“修改密码”“忘记密码”“退出登录”三个功能点AI只生成了“修改密码”和“退出登录”漏了“忘记密码”就标记缺失需求里说“支持第三方账号登录”AI默认只写了手机号登录也标记缺失。这一步主要解决覆盖率问题。第三步用设计方法补全边界。针对AI生成的用例主动用等价类划分、边界值分析、错误推测方法去检查。比如接口有个参数“pageSize”AI生成的用例只测了pageSize10和pageSize20就应该补上0、-1、字符串、超大值、空值这些边界。这是AI最薄弱的地方也是人工审核最能体现价值的地方。第四步逐条检查步骤和断言的“可执行性”。所谓可执行是指一个不了解系统的新人照着用例也能操作。AI经常写出“输入有效用户名”“点击相应按钮”这种话这种描述等于没说。审核时要改清楚用户名具体是什么是phone字段还是email字段按钮名称是什么是“登录”还是“立即登录”断言是“系统提示成功”还是“跳转到首页且右上角显示用户名”。第五步标注优先级和依赖关系。AI有时会把优先级标混把核心流程标成P2把边缘场景标成P1。审核时要根据业务风险重排优先级顺便标注用例前置依赖。比如“下单用例”依赖“登录用例”的先执行“使用优惠券用例”依赖“创建优惠券”的前置数据。这些标注在自动化执行时尤其重要。2.3 审核结果的记录与反馈闭环审核完不能把结果憋在肚子里尤其是AI生成的用例一定要把修改记录反馈给AI形成闭环。怎么反馈最简单的做法是准备一份“常见审核修改记录”每次审核后把AI的错误类型、修改方式、正确示例整理出来作为后续生成时的few-shot样本。比如上次AI总是把“提现金额必须为100的倍数”写成“提现金额任意”就把这个错误和修正后的正确描述写进提示词下次生成就会好很多。这里有个小技巧与其让AI完全自由发挥不如在生成阶段就给它约束。比如明确告诉AI“只生成与需求文档相关的用例不得虚构功能”“所有预期结果必须描述为可验证的表现”“每条用例必须包含前置条件和测试数据要求”。生成端多花10秒审核端就能省10分钟。3. 不同维度测试用例的审核重点AI生成的测试用例通常不区分功能、接口、安全这些维度一股脑全给你。审核时如果眉毛胡子一把抓效率很低。建议按维度分开审每个维度盯不同的关键点。3.1 功能测试用例审核最容易忽略的是业务规则边界功能测试用例是AI最擅长生成也最容易出问题的领域。AI能列出“点击按钮→输入内容→点击提交→验证结果”这种标准路径但业务规则边界是它的死穴。举例来说一个“注册”功能AI会生成输入正确信息注册成功输入已存在用户名注册失败两次密码不一致注册失败必填项为空注册失败。看起来已经不错了但业务规则里如果写了“用户名不能包含特殊字符”“密码必须包含大写字母和数字”“手机号不能以0开头”AI大概率会漏掉或者只写一部分。审核功能用例时我建议重点看三块一是业务规则是否有遗漏这个只能靠审核人对照需求文档逐条查二是状态流转是否完整比如订单从“待支付”到“已支付”到“已发货”AI可能只测了正常流转漏了“支付成功后回调失败”这种分支三是并发和重复操作比如用户快速点击两次“提交订单”AI基本不会主动生成这种用例需要人工补上。另外一个容易忽略的点是“前置数据和系统状态”。功能用例的执行往往依赖环境的初始化数据AI生成的用例经常不写这一步。比如“验证已支付订单可以申请退款”前提是环境里有一条已支付的订单这条数据怎么来是通过预置SQL还是通过界面操作创建审核时必须把数据准备步骤补上否则用例落到执行阶段根本没法跑。3.2 接口测试用例审核参数、边界和鉴权一个都不能少接口测试用例是AI生成质量相对较高的领域因为接口测试有明确的协议规范、参数列表和返回结构AI学习起来更容易。但正因为接口测试偏技术审核时更需要关注细节。接口用例审核我锁定的第一个重点是参数组合。AI通常能对单个参数做边界值测试但对参数之间的组合关系不够敏感。比如一个查询接口参数有“开始时间”和“结束时间”AI只会分别测这两个字段的边界但漏了“开始时间晚于结束时间”这个组合场景。再比如“城市ID”和“业务类型ID”存在依赖关系时AI不会主动生成“城市ID属于北京但业务类型ID只允许上海使用”的冲突用例。这类组合逻辑必须人工补。第二个重点是鉴权和权限。AI生成的接口用例往往默认用户已登录不关心token怎么来、过期了怎么办、无权限角色能否访问。审核时要补上未登录访问接口返回什么token过期后刷新token的机制是否验证普通用户请求管理员接口是否被拦截越权访问他人数据是否被禁止。说白了接口测试不能只测“正常请求”鉴权体系是安全底线。第三个重点是断言设计。AI生成的接口用例预期结果经常写得像散文——“返回成功”“数据正确”“提示异常”。这种断言没法落地。审核时要把断言改写成具体的检查点HTTP状态码是否为200响应中的code字段是否为0data.total是否大于0错误信息是否包含指定的errorMsg。断言的颗粒度决定了这条用例能不能直接转成自动化脚本。3.3 安全类测试用例SQL注入、登录用例审核的严谨性安全类用例是最不能完全信任AI的领域。AI可能会生成类似“输入含有SQL注入字符的字符串验证系统是否报错”这样的用例但这远远不够。因为安全测试讲究的是“在正确的位置用正确的方法”不是随便塞一个单引号就叫SQL注入测试。先说SQL注入登录测试用例。审核时要关注的不是“有没有测试SQL注入”而是“注入点是否合理”“数据是否脱敏”“是否覆盖常见注入类型”。比如在一个登录接口上不仅要测用户名参数和密码参数还要注意把注入载荷放在URL编码后的位置和JSON结构体中是否表现一致。同时AI生成的载荷可能包含真实的系统目录路径、真实的表名信息这类敏感数据在用例文档里必须脱敏处理不能直接明文贴到用例库里。另一个关键是登录测试用例的完整性。AI生成的登录用例常见问题包括只测正常登录和密码错误漏了账号锁定策略只测输入校验漏了验证码时效只测单点登录成功漏了会话并发和退出后重放只测手机验证码正确场景漏了验证码过期、验证码错误超过次数限制、同一验证码多次使用等。更要警惕的是安全用例涉及实际攻击载荷如果团队的安全水位不够高建议不要直接把AI生成的载荷脚本贴进用例库而是把它作为“设计参考”。审核人需要判断这条用例能不能在当前测试环境安全执行有没有可能污染数据库执行后如何恢复数据这些风险评估比用例本身更重要。4. AI测试用例中的“幻觉”排查与工具实操前面反复提到“幻觉”这是AI生成测试用例最让测试人员头疼的问题。这一章展开说清楚幻觉的具体表现以及怎么在审核中用工具和提示词技巧把幻觉压制到最低。4.1 什么是AI幻觉在测试用例里的具体表现AI幻觉可以简单理解成AI在生成内容时为了“回答得像那么回事”编造了它认为合理但实际不存在的信息。在测试用例场景里幻觉有三种典型表现。第一种是虚构功能和字段比如系统压根没有“记住密码”选项AI在用例里写了接口文档里没有callbackUrl字段AI在断言里用了这个字段。第二种是编造业务规则比如需求里没提“同一手机号只能注册一个账号”AI却生成了“重复手机号注册时提示已被占用”你以为测的是系统行为实际上测的是AI的想象。第三种是臆造数据格式比如AI默认日期格式是“YYYY-MM-DD”但系统实际要求“YYYY/MM/DD”这类用例执行时必然失败但又没有定位价值。排查幻觉最直接的方法是把AI生成的用例和需求文档、接口文档放在一起交叉比对。需求文档里没有提到的功能点接口文档里没有定义的字段用例里出现了就要高度怀疑是幻觉。核对时不要只看用例标题还要看步骤和断言里的每一个细节。4.2 如何用提示词工程减少AI幻觉与其在审核阶段费力排查幻觉不如在生成阶段就减少幻觉。AI生成测试用例的幻觉很大程度上是因为提示词给的信息太少。给AI一个模糊的需求标题它就只能靠训练数据里的“常识”来脑补细节脑补越多幻觉越多。所以我建议生成用例的提示词至少包含这几层信息系统模块和功能点列表、用户角色说明、核心业务规则、已知的字段约束、明确要求“不得虚构”。拿登录功能举例提示词可以写成你是资深测试工程师。请为“手机号验证码登录”功能设计测试用例。 约束条件 1. 手机号仅支持中国大陆11位号码以1开头。 2. 验证码为6位数字有效期5分钟单日最多发送10次。 3. 用户连续输错5次验证码账号锁定30分钟。 4. 只测试上述需求中描述的功能不得虚构其他功能。 5. 每条用例必须包含前置条件、操作步骤、预期结果。加了这些约束后AI生成用例的幻觉量会明显下降。不是说完全不会出现但至少它“脑补”的空间被压小了。对审核人来说好审核的前提是好生成这个思路很关键。另外迭代反馈也很有效。第一次生成后把审核中发现的幻觉示例和正确写法整理成“修订说明”放进提示词让AI学习修正。我试过连续三轮反馈之后AI生成的登录用例基本不需要大改幻觉率从最初的40%降到5%左右。这说明AI生成测试用例这件事本身的“调教成本”并不高关键是要形成反馈闭环。4.3 审核时如何用好AI Agent、Cursor这类工具提升效率审核AI生成的测试用例不一定非要靠纯人力。市面上常见的AI Agent和AI编程工具如果用法对路也能帮上忙。我常用的一个做法是把AI生成的用例导入到支持AI辅助审阅的工具里让AI先做一轮“自动预审”。比如让Cursor或者支持批量提示词的AI Agent读取用例文档按照预设的规则去标记可疑项。给它的规则可以是“找出步骤中出现的、需求文档中不存在的功能描述”“找出预期结果中没有具体行为描述的用例”“找出重复覆盖的用例”。这样AI先把明显问题标出来审核人再对着标记逐条确认效率能提升不少。这里要提醒一句AI预审的结果只能当线索不能当结论。因为预审AI也是AI它可能在标记问题的同时又制造新的幻觉。比如它看到用例里写了“验证用户能收到短信”就标记“需求文档没有提到短信”但实际上短信是产品另一个模块的环节。所以AI预审的定位永远是“缩小审核范围”不是“替代审核”。用AI Agent做审核还有一个很实用的场景生成“需求追踪矩阵”。把AI生成的用例按功能点打标后自动汇总成一张“功能点vs用例覆盖”的表格哪个功能点用例稀疏一目了然。这样审核人就能快速定位覆盖盲区而不是在几十条用例里一条条数。5. 常见问题与排查技巧实录AI生成测试用例加上人工审核这套模式在实践中会遇到一些重复出现的问题。我把常见问题和对应的排查思路整理成一份速查表方便团队直接对照。5.1 常见问题速查表现象可能原因排查与处理建议AI生成的用例明显偏离需求需求描述不完整提示词上下文太少在提示词中补充功能清单和业务规则审核时对照需求文档逐项核对大量用例步骤重复需求里多个功能点本身相似AI未做合并审核时按功能点归类先将重复用例合并再检查是否有必要拆成不同数据组合预期结果写得太笼统提示词未约束断言格式在提示词中要求“预期结果必须描述可验证表现”审核时逐条改写成具体检查点用例中出现了需求里不存在的功能AI幻觉脑补了系统行为先核对需求文档确认不存在则直接删除将幻觉案例加入反馈约束后续生成接口用例缺少鉴权验证AI默认接口都“已登录”审核时单独过一遍鉴权 checklist未登录、无权限、token过期、越权访问登录用例覆盖不足AI只做常规输入校验和成功路径用错误推测法补充验证码过期、验证码错误次数限制、账号锁定、并发会话安全测试用例携带敏感信息AI使用真实路径或明文载荷生成用例对用例中的敏感信息统一脱敏安全载荷只做设计参考不在用例库明文保存审核太耗时缺少checklist逐条从头读先按设计方法快速扫描边界再按优先级抽查对耗时过长的用例标记优化提示词这张表不是一次就能建全的每跑完一个项目的“AI生成人工审核”都可以往表里增加一条。后面团队再遇到类似问题直接在表里查不用重新踩坑。5.2 审核成本控制既要质量也要效率最后想聊一下审核成本。很多人不敢用AI生成测试用例就是担心审核比从零写还慢。这个担心有一定道理如果审核流程设计得不好确实可能得不偿失。所以控制审核成本本质上是两件事让AI生成更可用的用例以及让审核操作更有节奏。我的经验是分两层。第一层按用例风险等级分配审核深度。P0级别的核心流程用例一条条过步骤、断言、数据准备全查P2级别的边缘场景用例抽查20%重点看有没有幻觉和明显错误其余的批量扫描只统计覆盖率和缺失项。这样一来审核时间能压到从零手写用例的三分之一左右。第二层对AI生成的“可复用性”做评价形成团队的“AI用例质量分”。每次审核完给这一轮AI生成的用例打个分数比如“可直接执行占比50%”“需修改占比35%”“废弃占比15%”。连续打几轮分之后就能清楚知道当前提示词方案和业务场景的匹配度。匹配度低就回头优化提示词匹配度高就可以逐步加大AI生成的用例比例把人工精力集中在真正的业务难点上。从我自己的实践看AI生成测试用例这套模式跑通之后团队在常规用例上的产出速度至少提升了一倍而核心用例的质量并没有下降甚至因为人工审核环节更聚焦反而把以前容易遗漏的业务边界补得更全了。最后再分享一个我踩过几次坑之后养成的习惯审核AI生成的测试用例时永远保留一份“原始生成版本”不要直接在原文档上覆盖修改。这样既能随时对比AI和人工的差异也方便沉淀反馈给它做优化。只要把“AI生成人工审核”当成一条需要持续调优的流水线而不是一次性动作这套流程就会越跑越顺。