AI生成测试用例能用吗？五个维度评估用例质量

1. 为什么要较真AI 生成测试用例的现状与边界“AI 写的测试用例你敢直接用吗”——这个问题我过去半年被问了很多次几乎每次跟同行聊到 AI 辅助测试都会落到这个点上。从功能测试用例到接口测试用例再到根据 PRD 自动生成一整套用例集AI 生成测试用例这件事本身已经不新鲜了真正让团队纠结的是生成出来的东西到底能不能进测试资产库还是只能当个参考草稿用。先说一个我自己的判断结论AI 生成测试用例能不能用不取决于生成工具而取决于团队有没有一套稳定的判断方法。工具负责产出人负责判断这两者之间缺了后者AI 写得再好你也不敢放心把它们跑在核心业务上。要理解这套判断方法得先搞清楚两件事第一AI 生成测试用例的工作流程是什么样的第二它在什么场景下容易“翻车”。把这俩搞明白了后边的判断维度才不是空谈。1.1 从 PRD 到用例AI 到底做了什么我见过很多团队第一次用 AI 生成测试用例时的场景把产品需求文档粘贴进对话框敲一句“帮我生成功能测试用例”几秒钟后拿到几十条用例一看格式挺规整边界值、等价类、异常场景都有第一反应是“这也太省事了”。但如果你逐条细看就会发现里面有不少经不起推敲的地方。这背后的原因在于AI 生成测试用例的过程本质上是在做三件事理解需求文本、识别可测点、套用测试设计模式生成用例列表。理解需求文本这件事跟人去做需求评审完全不一样。人会结合业务背景、用户使用习惯、历史踩坑经验去理解“用户点击提交按钮后系统弹出提示”这句话会自然地想点击提交时如果网络断了怎么办重复点击会不会产生重复订单提示文案是弹窗还是页面内嵌但 AI 在生成时更倾向于在文本表面上展开它擅长把一句描述拆解出“正常路径 异常路径 边界情况”的框架却不一定理解你们系统的真实状态流转。识别可测点这一环AI 的水平取决于它被哪种生成模式驱动纯文本驱动、接口定义驱动、代码分析驱动产出的用例质量差得非常多。至于套用测试设计模式这是 AI 最拿手也最容易被误导的地方。等价类划分、边界值分析、状态转换等经典方法在大量公开测试文档里都有标准化的表达方式AI 学得滚瓜烂熟所以它生成的用例一般“看起来很像那么回事”。问题在于模式套得太顺就容易生搬硬套——比如一个纯展示型的页面它也给你整一堆输入校验用例一个几步就完事的查询功能它能给你列出 20 条边界组合。搞清楚这个底层的运作方式之后你就能理解一个关键点AI 生成用例的质量天花板跟它对需求上下文的理解深度强相关。给它一段孤零零的需求描述和给它一份包含业务规则、接口定义、历史缺陷记录的资料包生成结果完全不是一个量级。1.2 AI 生成用例的三种常用模式我在不同团队里见过大家使用 AI 生成测试用例的方式基本可以归纳为三种模式每种模式对应的最高质量上限不一样判断方法和侧重点也不一样。第一种是纯需求驱动模式也是最常见的用法。把 PRD、需求描述、会议纪要喂给 AI让它生成功能测试用例。这种模式胜在门槛低产品需求文档现成就有不需要额外的工程化配置。缺点是它完全依赖需求文档的完整度如果需求文档本身写得含糊AI 生成的用例就很容易在需求原文的空洞里“自由发挥”。第二种是接口驱动模式适用于接口测试用例的设计。把 OpenAPI/Swagger 文档、接口定义导入 AI 工具让它分析每个接口的参数、返回值、状态码生成接口测试用例。这种模式生成的用例规范性很强因为接口定义是结构化的AI 理解起来难度比自然语言低很多。但它同样有盲区——接口之间的业务流转关系、鉴权逻辑、数据一致性要求仅看单个接口定义是看不到的。第三种是代码驱动模式让 AI 结合源码分析来生成测试用例。这需要把代码库上下文提供给 AI或者使用带有代码检索能力的 AI Agent。这种模式生成用例的精准度最高因为它能基于实际实现逻辑发现一些需求文档里没写到的分支条件但也最容易出现“过度绑定实现细节”的问题——用例跟当前代码耦合太紧需求一变、代码一改用例就大面积失效。判断 AI 生成用例能不能用先要识别你现在用的是哪种模式因为每种模式的“高风险点”不一样。需求驱动模式的坑在需求理解偏差接口驱动模式的坑在业务流断裂代码驱动模式的坑在过度耦合。这些风险不识别清楚直接套一套通用判断标准效果会大打折扣。1.3 为什么 AI 写的用例“看着对用着废”我见过一个很典型的案例。有个团队让 AI 根据某商城系统的需求文档生成“购物车结算”功能的测试用例AI 列出了 30 多条包含正常结算、购物车为空结算、商品库存不足结算、优惠券抵扣结算、结算中断网络异常等场景。乍一看覆盖面挺全但测试人员执行起来才发现问题所有用例的预期结果都写着“系统提示结算成功”或“生成订单”没有一条校验订单金额计算是否正确。这个例子非常能说明问题——AI 生成用例最大的风险不是“场景不够多”而是“场景铺得很开深度的校验点却远远不够”。为什么会这样因为 AI 在处理“结算”这个动作时更容易理解的是“点击按钮 → 出现结果”这一显性的流程而“订单金额 商品金额 - 折扣 运费”这类业务规则尤其是带有分段逻辑、优先级顺序的规则它是很难从需求文本中完整提炼出来的。另外一个让“看着对用着废”的原因是 AI 在生成用例时容易把“可执行的动作”和“可验证的结果”混为一谈。它能把操作步骤写得很详细打开页面、选择商品、填写数量、点击结算。但到预期结果这一栏经常出现“系统正确显示订单信息”“流程正常完成”这类话。这种预期结果在执行时没法做校验你拿到手里测不测都一样等于没有这条用例。再加上业务领域知识的缺失AI 生成的用例经常在“伪精确”和“真模糊”之间反复横跳。所谓伪精确是它会把某些参数写得特别具体比如金额“99.99 元”、数量“100 件”看起来精确但是不是有效边界值它自己并不清楚。所谓真模糊是它会把关键业务术语一带而过比如“校验用户身份有效性”“验证权限配置”具体校验什么、怎么才算有效它不展开。所以要判断 AI 生成的测试用例能不能用核心不在于“它写得好不好”而在于“你有没有一套流程把它从头到尾检查一遍”。接下来要讲的这套判断方法就是干这件事的。2. 判断方法五个维度评估 AI 生成用例能不能用这套判断方法是我结合多个团队的实际应用经验总结出来的一套“AI 生成测试用例质量评估框架”。它不依赖任何特定工具也不管你是用 ChatGPT、国产大模型还是专门的测试 AI 平台只要照着这五个维度去评估就能对 AI 生成的用例集有个相对客观的判断。五个维度分别是需求覆盖率、断言质量、数据构造合理性、预期结果可验证性、冗余与冲突。每个维度单独看解决一个问题合在一起就能形成一张可以给用例集打分的评估表。2.1 需求覆盖率先数清需求点再谈覆盖判断 AI 生成的测试用例能不能用第一个要看的不是用例数量而是覆盖率。这个维度说起来简单做起来很容易跑偏。很多人一听说覆盖率第一反应就是去数“需求文档里有 10 个功能点用例覆盖了 8 个覆盖率 80%”。但这样数出来的覆盖率水分很大。问题在于需求覆盖率的统计口径是什么。是按功能模块数算还是按需求条目数算还是按业务规则数算我见过一个团队PRD 里明确写了“优惠券使用规则满 100 减 20不可与其他优惠叠加每个订单限用一张”。AI 生成的用例里确实有“使用优惠券下单”的用例看起来覆盖了这个功能点。但仔细对照需求会发现AI 漏掉了“不可与其他优惠叠加”这条关键业务规则——它把优惠券当成独立功能测了没有把“优惠券 满减活动”的组合场景设计进去。要解决这个问题建议用需求点拆解法来建立覆盖基准。收到 AI 生成的用例集后先把需求文档拆成最小可验证的功能点每个功能点用“动作 业务规则 结果”三要素描述清楚。比如“优惠券使用”这个功能点可以拆出如下几个需求点满足使用条件时优惠券可正常抵扣不满足使用条件时提示不可用原因不可抵扣与其他优惠满减、折扣同时满足时按规则取优先级最高的优惠同一个订单中同一张优惠券不可重复使用优惠券过期时下单不能使用并给出相应提示拆完之后把 AI 生成的用例逐一映射到这些需求点上。你会发现一个非常普遍的现象第一个和第二个需求点往往覆盖得不错第三个起就开始频繁遗漏。为什么会这样因为前两个是线性规则照着需求描述就能套出来第三个涉及优惠叠加的优先级判断需要理解业务意图AI 在最原始的需求驱动模式下很难生成这种用例。覆盖率评估的最终产出不是给一个“80%”的百分比而是要标出哪些需求点是完全没覆盖到的。这些没覆盖到的点就是你需要手动补齐的核心用例。判断 AI 生成用例能不能用覆盖率的底线是所有涉及金额计算、权限控制、状态流转的关键需求点不能被遗漏。这类规则一旦漏测上线出问题的概率极高。2.2 断言质量能验证结果的断言才算数第二维度看断言质量这也是 AI 生成用例里最薄弱的一环。这里说的断言不是指自动化测试代码里的 assert 语句而是用例里“预期结果”这一栏的内容质量——你拿到这条用例执行完之后靠什么判断结果是正确的。AI 生成的预期结果有几个高频通病。第一个是高概率出现“应该”类描述比如“系统应该提示操作成功”“页面应该跳转到订单列表”。这种话写在用例设计文档里作为概述没问题但作为可执行的预期结果等于没有。第二个通病是断言停留在页面表现层比如“提示框显示成功”“按钮变为置灰状态”完全没提数据层的变化。第三个通病是把“无报错”当断言——“接口返回 200无异常信息”这就是典型的无效断言。那什么样的断言才算合格我总结了一个简单的三层断言模型可以拿它来套 AI 生成的每一条用例。第一层是状态层断言验证系统响应状态是否符合预期。比如接口返回 200、页面跳转成功、订单状态变为“待支付”。这层断言必须有但仅有这层远远不够。第二层是数据层断言验证数据的变化是否正确。比如下单成功之后数据库订单表的金额字段是否等于商品单价乘以数量优惠券使用后库存表里该券的剩余数量是否减一修改用户名后用户基本信息表里的对应字段是否更新。这层断言是 AI 最常漏掉的而业务风险的集中区恰恰就在这层。第三层是规则层断言验证业务规则的执行结果是否正确。比如满 100 减 20 的优惠券用于 150 元的订单实付金额应该是 130 元两个优惠叠加时系统选择了规则指定的那个而不是随机选一个。这层断言需要测试人员深入理解业务规则AI 在没有得到明确提示时几乎不可能生成。判断断言质量的时候可以直接做一个简单动作把 AI 生成用例里的“预期结果”列全部摘出来凡是出现“正常”“成功”“正确显示”“无异常”“合理”这类模糊词的一律标记为“弱断言”。统计一下弱断言在所有用例中的占比。如果超过 40%这套用例集就不具备直接进入测试执行阶段的条件必须先做断言补强。2.3 数据构造合理性测试数据决定用例成败第三个维度关注的是测试数据。AI 生成用例的时候会在操作步骤里带入测试数据比如用户名、手机号、金额、数量、日期等。这些数据看起来是那么回事但仔细一看很多数据根本不满足用例的设计意图。拿登录功能的测试用例举例。AI 生成的用例里有一条“输入正确的用户名和密码点击登录系统提示登录成功”。这里有个非常普遍的问题它不会告诉你“正确的用户名和密码”具体是哪个账号。你说这条用例能执行吗能但需要测试人员自己去造数据。你说这是大问题吗单看一条不算大但整套用例里如果三分之一都是这种“数据待补充”的状态执行效率会大打折扣。更麻烦的是数据与用例意图不匹配的情况。比如设计“用户已注册但未激活邮箱尝试登录”这条用例时AI 生成的操作步骤是“输入正确的用户名和密码点击登录”预期结果是“系统提示邮箱未验证登录失败”。从场景设计角度这条用例的思路是对的但操作步骤里的测试数据写得很含糊没说明要用“已注册但未激活邮箱的账号”。执行的人拿到这条用例如果随手用一个已激活的账号去测结果反而是登录成功然后就觉得 AI 生成的用例有问题。数据不匹配责任还真不一定在 AI 身上但从判断方法的角度来说这条用例就是不合格的——因为它没有把测试数据的前置条件描述清楚。所以评估测试数据构造合理性时我会重点看三个点第一用例是否明确了测试数据的前置条件账号状态、环境状态、数据准备步骤第二输入的数据是否能够支撑用例的验证意图测库存不足就得有库存不足的商品数据第三数据是否具备可执行性涉及的账号、权限、测试环境是否真实存在或可快速创建。这一维度稍微特殊一些因为即使 AI 生成的用例数据不够精确只要前置条件清楚、意图明确测试人员补数据并不费劲。反过来如果数据看起来精确、实际不可用这种“伪精确数据”反而比“模糊数据”更影响判断。看到用例里写了“输入 999999 个商品数量”就头大——表面上是做了边界值分析可你得先确认系统允不允许填这个数量也别指望这个数据能轻易造出来。2.4 预期结果可验证性拒绝“系统提示成功”第四个维度选的是预期结果的可验证性跟第二个维度断言质量有联系但角度不一样。断言质量解决的是“预期结果写得够不够深入”而可验证性解决的是“预期结果的判定标准和验证手段是什么”。举一个最典型的例子。AI 生成的用例里预期结果写“系统正确计算订单总金额”。你拿到这条用例怎么判断系统算得对不对你需要有一份手工计算好的金额作为参照也需要明确“正确计算”的具体判定标准——如果计算方式是商品总价减优惠加运费那得先把每部分的数值算出来才能判断最后的总金额对不对。可验证性还涉及验证成本的问题。有些用例的预期结果是可验证的但验证成本很高。比如一条关于异步任务的用例预期结果是“任务执行成功后系统更新任务状态”。要看这个结果可能需要直接查数据库或者在后台管理页面查看任务日志。如果 AI 生成的用例里没有给出任何验证路径的提示测试人员执行到这一步就得自己去探索怎么查看任务状态一条用例的执行时间可能是其他用例的好几倍。在判断预期结果可验证性的时候我常用的方式是逐条问三个问题第一这条用例执行完毕后我们通过什么手段知道结果是对的还是错的第二如果结果出现偏差我们能不能明确说出来偏差在哪儿第三验证这个结果需要什么前置条件数据准备、工具、权限、环境这三个问题里任何一个答不上来这条用例的可验证性就不过关。有一种情况需要额外留意AI 生成用例时可能给出“预期结果参见需求文档”之类的表述。这是最不可验证的表达方式——需求文档本身不是预期结果它是设计的输入。如果预期结果需要“参见”才能明确那说明这条用例就没把结果写明白需要人工补全。2.5 冗余与冲突重复用例比缺用例更隐蔽最后一个维度是判断用例之间的冗余与冲突。这个维度不像前四个那么显眼但处理不好会直接影响测试执行阶段的体验。AI 生成用例的冗余问题不在于它生成了太多条用例而在于它会把“看起来不同、实际测的是同一件事”的用例反复输出。举一个真实例子某团队让 AI 生成“用户注册”的测试用例它一口气写了 20 多条其中“手机号格式错误”“手机号长度不足”“手机号包含非数字字符”“手机号为空”各算一条。执行时发现前端校验里手机号的正则规则只有一条这四种输入在这个正则规则面前走的是同一个校验分支失败提示也是一样的。从用户视角看这可以算不同场景但从代码覆盖和业务规则覆盖角度看这就是 4 条测同一逻辑的用例。我并不是说这种细分的用例不能留。如果要做一个严谨的输入校验测试矩阵分开写也有价值。关键在于团队成员需要识别出这类用例属于“同一规则的不同输入样本”而不是“4 个独立需求点的测试用例”。否则你在统计覆盖率时会被虚假的覆盖数量带偏以为注册模块测得很充分实际核心的“验证码发送频率限制”规则反而一条用例都没覆盖。冲突问题则更严重。AI 生成用例时由于它没有全局记忆可能在前一条用例中假设“用户已登录”在后一条用例中同样的操作又假设“用户未登录”。这种冲突如果不仔细排查执行时就会浪费大量时间在环境重置上。还有一种冲突更隐蔽前一条用例验证的是 A 业务规则后一条用例的步骤序列会修改同样的数据状态两条用例单独执行都通过但按顺序连续执行时后一条会受前一条影响而失败。这不是执行问题而是用例设计本身存在状态依赖冲突。对冗余与冲突的评估我建议采用抽样审查而不是全量审查——把 AI 生成的用例按功能模块分组每组里随机抽 20% 仔细检查对比操作步骤、前置条件和预期结果看看有没有上述问题。抽样比例不用太高因为这类问题通常呈区域性分布某个模块冗余多另一个模块可能极少。五个维度都讲完了我通常会把它们合成一张评估表给 AI 生成的用例集做一个量化的“准入判定”。每个维度满分 20 分总分 100 分。覆盖率低于 15 分、断言质量低于 10 分、可验证性低于 10 分的直接打回重新生成或人工改写总分低于 60 分的只能当参考草稿用不能进入测试资产库总分在 60 到 80 分之间的补强后可以选用80 分以上的基本可以低成本整理后直接执行。判断方法这种东西不能靠感觉一旦用量化的方式去卡团队里的分歧会大大减少。3. 实操流程给 AI 生成用例做一次系统性审核讲完判断维度接下来要解决的是操作路径。很多团队听完这套方法觉得有道理但真到了要落地的时候不知道从哪里下手。这一节我把完整的实操流程走一遍从拿到 AI 生成用例到最终决定“能不能用”一共四步每一步都有可以直接照着做的动作。3.1 第一步建立功能清单做覆盖勾稽在开始逐条审 AI 生成的用例之前先做一件看似无关却最重要的事情把需求文档转成一份功能清单。功能清单不需要复杂的工具一张电子表格就够。把需求文档里的功能模块拆出来每个模块再拆成最小功能点功能点下面标注业务规则。拿一个电商后台的“商品上下架”功能举例功能清单大致长这样商品上架填写商品信息保存后商品状态为“待审核”商品上架审核通过后商品状态变为“已上架”前台可见商品上架审核驳回时需填写驳回原因商品状态变为“已驳回”商品下架已上架商品下架后前台不可见后台仍可编辑商品下架已下架商品再次上架时需重新走审核流程拆完功能清单之后拿着 AI 生成的用例逐条做勾稽。每条用例标注它覆盖了功能清单里的哪个功能点。这步做下来AI 生成用例集的覆盖地图就出来了。哪几个功能点底下堆了十几条用例哪几个功能点底下一条都没有一目了然。这一步看起来费时间但我可以负责任地说它是对 AI 生成用例做判断的过程中投入产出比最高的一步。因为 AI 生成的用例往往量大且散没有功能清单做锚点你很容易陷入“看着每条都还行、整体却不知道缺什么”的状态。而功能清单一旦建立缺什么、多什么自己就浮现出来了。3.2 第二步逐条反向提问过滤无效用例建立覆盖勾稽关系之后进入逐条过滤环节。我称之为反向提问法——不是问“这条用例有什么问题”而是反过来问“这条用例到底在验证什么”。把 AI 生成的每一条用例翻出来问自己一个问题如果删掉这条用例有没有可能漏掉一个线上 bug如果答案是没有可能那这条用例大概率是无效的或者冗余的可以标记待删。这个提问方式看起来有点狠但它非常有效。以 AI 生成的用例里常见的“浏览器兼容性用例”为例——“在 Chrome 浏览器下打开页面功能正常”。删掉它会不会漏掉线上 bug大概率不会因为你们团队的兼容性策略早就固定了不需要单独列一条用例。再比如“点击页面空白区域无响应”——删掉它会不会漏 bug通常也不会。这类用例就是典型的“正确但无用”的占位用例留着不坏事但会稀释整个用例集的专注度。反向提问过了之后还有一类用例需要特别留意AI 生成的用例里有些描述得非常具体比如“输入手机号 13800138000 登录”但完全没有上下文说明为什么是这个手机号。这类“凭空的精准”反而可疑。遇到这种情况反向提问同样好用——删掉这条用例会不会漏掉 bug如果会那你需要做的事不是保留它而是补全它把这个手机号对应的账号状态、前置条件、预期结果全部标注清楚。逐条过滤做完之后你会得到一个“保留清单”和“待删清单”。待删清单先不要直接删留着做记录等整套用例定稿时再统一清理。这样中间如果发现有误删的还可以找回来。3.3 第三步与核心手写用例交叉对比第三步的核心目的是用团队已有的“测试经验库”去校验 AI 生成的用例。任何一个成熟团队都会有自己长期沉淀下来的一批核心手写用例——它们往往不是按需求文档生成的而是根据历史线上问题、用户投诉、开发争议整理的“经验用例”。这批用例是团队最宝贵的测试资产。交叉对比的方式很简单把 AI 生成的用例和手写核心用例放在一起按功能模块逐一对照。对照时重点找两样东西第一手写用例里有、但 AI 用例里没有的场景第二两边都有、但对业务规则理解不一致的地方。第一样东西好理解历史问题沉淀出来的用例AI 在没有拿到历史数据的情况下几乎不可能原样生成。比如某支付模块去年上线时出现过“用户重复点击支付按钮导致重复扣款”的线上问题团队为此加了一条用例“支付请求未返回时连续点击支付按钮 5 次系统只允许首次请求生效”。这种用例 AI 几乎不可能自动生成它需要了解过去的缺陷背景。交叉对比时如果 AI 生成的用例集里没有这类经验用例没关系这是正常的你只需要确认手写用例没有因为引入 AI 生成的用例而被冲掉。第二样东西需要特别注意。AI 生成的用例和对需求的理解是“从文档出发”的而手写经验用例是“从真实行为出发”的两者对同一个业务规则的理解可能不一样。遇到不一致的地方不要急着说谁对谁错去跟产品经理和开发确认需求原文以实际需求和用户价值为准统一口径。这个过程本身就是一次有价值的需求对齐。做完这一步你基本能确定一件事AI 生成的用例集在“广度”上有多少增量价值在“深度”上有多少差距。我的经验是AI 生成的用例在“广度”上通常能给你带来惊喜它会覆盖一些你们团队平时没想到的异常组合尤其是一些参数组合维度的用例。这是一大价值点——AI 的优势本来就不是替代你的经验而是帮你把经验覆盖不到的地方铺开。3.4 第四步给用例打质量分做准入判断最后一步是把前面几个维度的判断结果汇总成一个可执行的结论。我在 2.5 节里提到的五维打分表在这里派上用场。按 2.1 到 2.5 的五个维度给 AI 生成的用例集逐项打分。打分的时候不要一个人闷头打我把这个环节设计成一个小型评审会参与的人包括用例审核者、功能对应的测试负责人、必要时叫上产品经理。评分规则提前定好每个维度按“缺陷数”而非“主观感受”来扣分。比如覆盖率维度功能清单里 20 个关键需求点漏了 3 个覆盖率就是 85%折算下来对应分值就是 17 分。这样评分的过程本身也是一次测试用例质量审计比单纯凭感觉决定“能不能用”要靠谱得多。分数出来后的准入规则我在前文给过一个参考总分 60 分以下退回重写60 到 80 分补强后使用80 分以上整理后直接进测试资产库。这里需要强调一下“退回重写”不是把 AI 生成的用例发给 AI 让它重新生成一遍而是把评审中发现的缺口整理成更明确的输入条件再让 AI 重新生成或补充。如果把问题原封不动地再发一遍得到的答案大概率还是原来那批有同样问题的用例。实操流程走完之后我对“AI 生成的测试用例能不能直接用”这个问题有了一个更准确的回答没有天然能用或不能用的区别背后一定需要一套“生成—评审—补强—准入”的闭环流程。AI 的价值在于把用例初稿的生成成本降到一个极低的位置而测试团队的价值在于用专业的判断方法把初稿改造成真正能守护业务质量的测试资产。4. 常见问题与团队落地经验判断方法讲完之后再集中聊一聊我在实际落地过程中遇到的典型问题和一些可以避开的坑。这一部分内容比较零散但每条都来自真实的执行现场比前面的框架更接地气。4.1 AI 生成用例的典型问题速查表先做一张速查表把最常见的几类问题、表现和调整方向整理出来方便你在实际评审时快速定位。问题类型典型表现可能原因处理方法断言弱化预期结果写“系统提示成功”“操作正常”AI 基于通用流程生成的用例范式缺少业务校验逻辑按“状态层 数据层 规则层”补强断言场景泛化用例操作步骤语焉不详如“填写合法数据”AI 不会自动感知具体系统字段约束在前置条件里明确字段规则后重新生成需求理解偏差用例覆盖了表面功能遗漏关键业务规则输入的需求文本不够完整或需求本身有歧义用功能清单做覆盖勾稽人工补齐遗漏冗余堆叠大量用例指向同一个校验逻辑生成时按输入值展开而不是按规则分支展开用“反向提问法”过滤无效用例数据失真出现不真实的账号、金额、编码AI 基于概率生成测试数据无法感知真实环境审核测试数据前置条件标注真实数据来源状态冲突用例间存在前置状态依赖未声明清楚AI 对全局用例集的状态流转缺少统筹按功能模块抽样审查标注执行顺序依赖这张表不用背核对的次数多了自然就会形成条件反射。刚上手的时候建议把这张表打印出来评审时对着看能少走不少弯路。4.2 用断言模板给 AI 补上“测试嗅觉”前面反复提到AI 生成用例的断言质量普遍偏弱。这个问题如果只靠人工在评审时一条条补效率低而且一批用例和另一批用例的补强质量参差不齐。我的建议是提前准备好一套断言模板把模板作为生成要求的一部分发给 AI从源头提升断言质量。所谓断言模板就是针对不同类型的功能预先定义“预期结果至少包含哪些要素”。功能类用例的断言模板我常用的结构是“操作成功标识 数据变化 下一步状态”三要素组合。比如订单提交的用例预期结果写成“提交成功并展示订单编号订单状态变为待支付库存数量扣减 1同时生成一条待支付通知记录”。这样写出来的断言执行时至少有据可查。接口类用例的断言更结构化一些我常用的格式是“状态码 响应体关键字段 数据库数据 幂等性”。举个例子用 AI 生成“创建订单接口”的测试用例时可以在生成要求里写明每条接口用例的预期结果必须包含四部分——HTTP 状态码期望值、响应体里的关键字段期望值比如 orderId 不为空、amount 等于请求参数计算值、落库后订单记录的关键字段值、以及相同请求重复提交时的响应差异。把断言模板给 AI 之后你再去评审生成的用例会发现它写出来的预期结果结构完整得多。虽然最后合不合格还得靠人来判断但至少从“泛泛而谈”变成了“有骨架的草稿”返工成本低很多。4.3 优化 Prompt 的三个关键动作很多人以为 AI 生成测试用例效果不好是模型能力不行。实际上大部分情况下是输入太简陋。我见过的最常见的用法是直接丢一句“帮我生成这个模块的测试用例”然后期待 AI 能像资深测试一样做出完美的需求分析和用例设计。这不现实因为它对你的系统、你的业务、你的风险偏好一无所知。要让 AI 生成用例的质量值得被判断得先把生成条件给到位。这里分享优化 Prompt 的三个关键动作都是可以直接照抄的经验。第一把角色和任务边界写清楚。不要只说“你是资深测试工程师”要说明你希望它做什么、不做什么。我会这样写你是一名功能测试工程师请根据下述需求文档设计测试用例只设计用例不要输出测试计划、不要给出代码实现也不要修改需求本身。任务边界越清楚AI 生成的越不会跑偏。第二给出可用的业务规则和约束条件。把需求文档里的关键业务规则摘出来放在 Prompt 里比让它自己去读长文档更有效。比如“优惠规则订单满 100 减 20单笔订单最多使用一张优惠券优惠券不可与秒杀活动叠加”——这类规则明确写进 PromptAI 在生成用例时才会把相关场景设计完整。第三指定输出的格式和粒度。我习惯在 Prompt 末尾加上这样一段固定要求每条用例必须包含用例编号、用例名称、前置条件、测试步骤、测试数据、预期结果、优先级其中预期结果必须包含数据校验规则测试数据必须说明数据创建方式和前置状态。用这套格式去约束输出生成的用例集在结构上就齐整很多后边的评审工作也轻松得多。4.4 团队推行的最小化落地路径最后聊一下怎么在团队里把“判断方法”真正推行下去。我见过不少团队听完方法很兴奋但回到工位上就不知道怎么动了。原因很简单方法听着不错却没有一个轻量的切入点。我推荐的最小化落地路径是挑一个中低复杂度的功能模块做试点不要一上来就铺到整个系统。这个模块最好满足三个条件——需求相对稳定、业务规则清晰、风险影响可控。比如后台管理里的“用户列表查询”功能先拿它练手。流程是这样把该功能的需求文档整理好用前面讲的 Prompt 优化方法让 AI 生成一套用例然后用五维评估表打分做覆盖勾稽找出手写用例和 AI 用例的差异最后把审核结论整理成一份简短报告。这个试点周期控制在两三天以内目标不是做出完美用例而是让团队完整地走一遍“生成—评审—补强—准入”的流程积累对 AI 生成用例的体感。试点跑完之后再根据结果决定是否推广到更多模块。我这里要提醒一点不要指望第一次试点的结果就非常理想。AI 生成用例的质量跟输入资料的完整程度、Prompt 的设计水平、评审标准的一致性都是正相关的。第一次大概率只能拿到 60 分左右的用例集没关系重点是流程能不能跑通。第二、第三次再逐步优化等评估表用顺了判断时间会大幅缩短团队对 AI 生成用例的接受度也会真正提升上来。我最后再说一句个人的体会。AI 生成测试用例这件事真正的价值不在于“让 AI 写用例人就不用写了”而在于“把用例设计从人脑里的隐性经验变成流程里可复制、可评估、可迭代的显性资产”。你问 AI 写的用例敢不敢直接用答案其实取决于你手里的判断方法足够不够硬。方法硬了AI 生成的内容就是你的翅膀方法不硬它写多少条都只是看起来热闹。先把判断方法搭起来再谈放心用 AI这个顺序不能反。