AI帮我们写测试用例这件事大概从两年前开始就被反复提起。起初大家都很兴奋——把需求描述扔给大模型几秒钟就能生成十几条流程完整的用例覆盖了主路径、异常路径甚至连边界值都给你标好了看上去比很多刚入行的测试同学写得还像样。但真正用起来之后越来越多团队开始发现一个尴尬的事实AI写的测试用例“初看惊艳落地就翻车”。不是某一条用例写得不对而是整套用例放在真实项目里总有一种“隔靴搔痒”的感觉。核心业务链路漏了、状态流转判断错了、数据库约束没覆盖、权限矩阵缺了一半……而这些恰恰是测试用例最有价值的部分。我说一句可能得罪人的话拿ChatGPT、Claude、DeepSeek挨个试过之后你会发现它们都能写出“看起来很有道理”的用例但都解决不了一个根本问题——它们不理解你的业务不理解你的系统更不理解你这次迭代真正担心的是什么。这篇文章不打算劝退任何人。AI写测试用例依然是目前效率提升最明显的场景之一但前提是你要搞清楚它擅长什么、不擅长什么以及怎么在流程里给它加上约束和校验。我会把这些年踩过的坑、试过的方法、以及一套我自己在用的协同策略完整拆开来讲希望能帮你少走一段弯路。1. AI写测试用例为什么初看惊艳、落地就翻车1.1 翻车现场实录每条用例都“正确”合起来却没法用先说一个真实项目里的例子。当时我们做一个电商后台的订单退款流程改造涉及原路退回、余额退回、优惠券返还、积分调整四个并行动作。我让AI基于一段需求描述生成测试用例它非常流畅地给出了28条用例结构完整步骤清楚预期结果也写得像模像样。但评审的时候问题就出来了。28条用例里居然没有一条覆盖“退款金额大于订单实付金额”的拦截校验没有一条考虑“优惠券在退款前已过期”的处置逻辑也没有一条覆盖“退款过程中用户同时发起部分退款”的并发场景。这些恰恰是这次改造里最容易出事故的地方。AI生成的用例不是“错”而是“浮”——它像一份模板化的产品说明书把需求里的字面流程翻译成了测试步骤却完全丢失了对业务约束、异常链路和历史经验的理解。这类翻车现场太常见了。我总结了一下AI生成的测试用例普遍有三类硬伤漏测核心风险它不知道这次代码改动最容易挂掉的是哪一块不会基于变更影响面去分配测试重心。用例粒度失衡要么把一条用例拆成十个小步骤要么把多条完全独立的路径揉在一起执行和定位问题时非常别扭。预期结果模糊大量用例的预期结果是“页面提示错误”“处理失败”“校验不通过”这类定性描述没有具体的规则细节自动化断言时根本没法落地。1.2 模型没变笨是测试用例对上下文深度的要求没有上限很多人觉得AI“越来越不靠谱”是模型的生成能力倒退了。实际不是。ChatGPT、Claude、DeepSeek这些模型在语言组织和逻辑推理上并没有明显退化。真正的问题是测试用例这个任务的特殊性把模型在“业务上下文理解”上的短板完全暴露了。测试用例的本质是什么是把“业务需求 系统行为 质量风险”三者压缩成一组可执行的验证动作。它要求写用例的人至少掌握三方面的上下文业务规则这个功能在真实业务里有哪些隐含约束。比如退款不能超过原支付金额比如优惠券一旦核销就不能再解绑这些通常不会写在需求文档里而是散落在产品经理的脑子里、老代码的判断逻辑里、甚至线上事故报告里。系统实现数据库字段的唯一约束、异步任务的执行顺序、缓存的失效策略、权限模型是RBAC基于角色的访问控制还是ABAC基于属性的访问控制。这些决定了一条用例应该前置哪些数据准备、绕过哪些机制。历史经验这个模块以前在哪出过事、哪个字段经常被改坏、哪条链路和外部系统的对接最脆弱。这是测试用例最有价值的部分但对模型来说是完全不可见的信息。大模型训练时见过海量的通用软件场景所以它能很好地生成“像一个测试用例”的内容但训练数据里没有你这家公司的业务规则、没有你系统的表结构、更没有你过去一年踩过的坑。它只是在用概率补全一段“看起来合理的文本”而不是在为你当前这个系统设计验证方案。这就是为什么AI写测试用例会出现“越来越不靠谱”的感觉早期你拿一些简单的CRUD增删改查界面去试模型确实表现得不错因为它见过足够多类似的页面和表单但当你把真实项目里那些充满历史包袱和业务规则的复杂模块扔给它时它就原形毕露了。不是模型变笨了是任务的复杂度上去了而模型的“上下文深度”跟不上。2. ChatGPT、Claude、DeepSeek 写测试用例的共同瓶颈2.1 上下文窗口只是“装得下”不等于“理解得好”先说一个最常见的误区上下文窗口越大AI就越靠谱。从数据上看现在主流模型都支持几十万甚至上百万token的输入把整个需求文档、接口文档、表结构全部塞进去不是问题。但真正用过你就知道上下文窗口只是“装得下”模型在长文本里做信息检索和逻辑保持的能力远没有我们期待得那么强。我做过一个实验把一个包含36个接口、11张表、8个状态流转的生产模块完整喂给模型让它生成全量测试用例。前十几条还算正常但随着对话变长它开始忘记前面已经定义过的字段约束把状态机里的状态名称搞混甚至生成了一条和它自己前面写过的用例相矛盾的步骤。这不是个例而是长上下文下注意力分散的典型表现。测试用例任务尤其吃上下文一致性——一个状态机从“待支付”到“已关闭”中间不能跳过“超时取消”这个动作一条字段的边界值在用例A里定了在用例B里就不能变。模型在短文本里做这种逻辑保持很容易但一旦上下文变成几十页的产品文档和接口定义它的表现就会断崖式下降。所以我的一个实操经验是不要贪心把整个项目资料一次性扔给模型。宁可把需求拆成功能点一次聚焦一个场景让模型在小上下文里把逻辑保持做好也不要图省事“大锅烩”。2.2 模型对等价类划分和边界值的理解是“纸面”的等价类划分、边界值分析、因果图、判定表这些测试用例设计方法在教科书里早就写清楚了大模型的训练数据里也大量包含这些内容。所以当你让AI写测试用例时它通常会很乖地给出“最小值、略小于最小值、正常值、略大于最大值、最大值”这种边界用例看起来很专业但真正落地时会发现很多是无效的。举个例子一个年龄输入框范围是18到60岁。AI会给你生成17、18、30、59、60、61这几条边界用例看起来没毛病。但如果这是一个会员注册系统出生日期是从身份证号里解析出来的那么真正需要考虑的边界不是“年龄18岁”而是“证件类型为身份证时出生日期是否在effective日期之后”“当天生日算不算已满18岁”“闰年2月29日出生的人怎么算”这些由业务规则派生出来的边界。模型不知道这些它只会套用通用边界值公式。问题出在模型的“纸面理解”上。它知道等价类划分这个方法本身但不知道如何针对“这个具体系统”的约束来设计有效划分。比如数据库层面有唯一键那么等价类的关键就不只是输入值的区间还要考虑已存在数据的组合状态比如某个字段是枚举值那么等价类就应该基于枚举的取值范围而不是类型判断。这些都需要人脑结合系统实现去深化AI给不了。我的建议是把AI生成的边界用例当作一个“提醒清单”而不是最终答案。你要做的是顺着它的边界枚举逐一去追问系统实现中的真实约束把纸面边界转成业务边界和代码边界。2.3 模型无法感知代码变更的影响面回归用例越补越虚测试用例分两类——一类是验证新功能是否按需求实现的“功能用例”一类是验证已有功能没有被改坏的“回归用例”。AI在生成功能用例上表现还算及格在回归用例上基本是瞎蒙。原因很直接模型看不到你的代码diff变更记录。哪怕你把它接上代码仓库让它读取变更文件它也缺少对“模块间依赖关系”的全局判断。一次改动表面上只动了订单查询接口的一个排序字段实际上可能影响依赖这个接口的三个上游系统的数据展示顺序。一个经验丰富的测试工程师看到这个diff会本能地意识到下游的“订单列表导出”“对账单生成”“用户端订单详情页”都需要回归但模型只能看到“排序字段变了”然后机械地生成一条“验证排序是否正确”的用例。这就导致AI生成的回归用例呈现出一种“虚胖”状态数量很多看着覆盖率挺高但真正涉及核心链路的用例没几条反而在无关紧要的地方堆了一堆重复用例。更麻烦的是AI生成的回归用例缺乏“优先级”的判断它不知道一条用例如果失败了会造成多大的影响所以它给出的所有结果都是返回值无法帮助团队在有限时间内决定测什么、不测什么。这其实是AI写测试用例最致命的短板测试的价值在于风险控制而风险评估依赖对系统变更的理解这是模型目前最不擅长的事。所以如果你指望AI帮你解决回归测试的漏测问题趁早打消这个念头。2.4 主流模型横向对比各有优势但都没解决业务对齐问题我用同样一个“订单取消”模块的需求描述让ChatGPT、Claude、DeepSeek分别生成测试用例对比下来各有各的特点但共同问题也非常明显。模型相对优势在测试用例场景的主要短板ChatGPT语言组织能力强用例步骤清晰对常用测试设计方法掌握全面容易“一本正经”地生成套话用例默认值填得漂亮但缺少对系统约束的追问Claude长文档理解相对更稳复杂业务描述下能保持较好的逻辑一致性输出用例偏“保守”边界场景和异常场景的枚举激进程度不够DeepSeek中文理解好对国内开发者习惯的表述方式更贴近生成用例相似度高多条用例之间存在同质化容易凑数但这三家的共同瓶颈是一样的模型只凭需求描述做“文本转换”缺少对系统实现细节的追问能力。你不会看到任何一个模型主动问“这个字段在数据库里是否有唯一约束这个状态流转是否有定时任务在驱动这个按钮在权限为Draft角色的时候到底是否展示”它只会顺着你给的描述往下写。这也解释了为什么很多团队换了好几个模型测试用例的质量并没有本质提升——因为问题不在选哪个模型而在于“输入信息的完整性”和“人机协作的方式”。模型只是引擎你得给它加一个外部的知识底座并配置好校验环节它才能在真实项目里发挥价值。3. 把AI当“模板引擎”别当“业务专家”提示词与协同策略3.1 角色重构AI负责结构和枚举人负责判断和价值使用AI的正确姿势是把它的能力限制在它真正擅长的地方。我踩过很深的一个坑就是一开始把AI当成“测试专家”来用期望它给出完整的测试方案、风险分析和用例设计结果每次都要花大量时间去修正和补充累到自己。后来我想明白了一件事AI擅长的是“从已有的描述中提取信息、按照模式生成结构、穷举常见的测试场景”最不擅长的是“理解业务隐含规则和判断测试优先级”。所以我现在把AI定位成“模板引擎 穷举机”具体分工是这样AI负责根据输入的需求描述生成用例骨架、补充常见的边界值和异常值枚举、按指定格式填充字段、把重复性的书写工作快速完成。人负责深入核对业务规则、补充AI没见过的历史问题场景、删减无效用例、标记优先级、决定哪些用例要进自动化回归集。这个角色重构看起来简单实际带来的改变是巨大的。当我不再期望AI“一锤定音”而是把它当成一个帮我把想法快速落成文字的助手整个流程顺畅了很多而且最终用例的质量是由我把控的AI只是帮我提高了起草速度。3.2 一个我用着顺手的结构化提示词模板既然AI不理解业务那就靠外部输入把业务信息尽可能喂给它。我在写提示词时会强制自己按照固定的结构组织信息这比任何“神奇提示词”都管用。下面这个模板我用了大半年在多个项目里都验证过效果你可以直接拿过去改成自己的版本你是一名资深测试工程师。请基于我提供的业务规则和系统约束生成功能测试用例。 【模块名称】 订单取消流程 【业务规则】 1. 订单状态为待支付/已支付/已发货/已完成/已取消 2. 只有“待支付”和“已支付”状态允许取消 3. 已支付订单取消后原路退款到支付账户退款T1到账 4. 使用优惠券的订单取消后优惠券退回有效期不延长 5. 订单金额为0时不允许取消 【已知系统约束】 1. 订单字段 order_status 使用枚举值存储 2. 取消操作写入 opt_log 表需要前置用户登录态 3. 退款调用 pay_gateway 的 void 接口有幂等控制 生成要求 1. 覆盖正常路径、业务规则边界、异常输入、权限场景 2. 每条用例包含用例ID、前置条件、测试步骤、预期结果 3. 对每条用例标注优先级P0核心链路/P1重要/P2一般 4. 请额外补充你认为需要和产品确认的模糊规则点这个模板的核心在于“业务规则”和“系统约束”两个部分。这些信息不是从模型里生成的而是你从需求文档、代码逻辑、DB设计里提炼出来的。你填进去的信息越精确AI输出的用例就越贴地气。尤其是最后一条“请额外补充你认为需要和产品确认的模糊规则点”这个技巧很实用——模型基于训练数据能识别出需求描述里的漏洞帮你把“没说清楚的地方”提前暴露出来这些地方往往是测试用例设计时的关键模糊点。3.3 人机协同闭环生成、补充、分级、回归有了靠谱的提示词还需要一个固定的人机协同流程来保证质量。我现在团队里推的闭环是四步走第一步“生成”把需求描述、接口文档、规则清单一次性交给模型基于上面的模板生成初版用例集。这一步的产出可能有一堆无效内容不要紧。第二步“补充”这是最关键的一步。我会把AI生成的用例当作检查清单一条一条过一遍在脑子里问三个问题这条用例的核心业务价值是什么如果说不上来大概率是无效用例。这个场景以前有没有出过事故如果出过那这次迭代有没有覆盖到这条用例需要的前置数据在当前测试环境能不能造出来如果造不出来那这条用例再漂亮也执行不了。第三步“分级”把用例按照P0、P1、P2分好级这个判断只能人来完成。AI可以建议优先级但你得基于本次迭代的风险重排一次。我的经验是P0用例控制在总量的20%以内否则说明用例设计没有抓住重点。第四步“回归”把P0用例关联到自动化回归集里P1和P2用例保持手工执行的灵活性。每次代码变更时先更新P0用例集确保核心链路永远在自动化保护之下。这个闭环最大的价值是让AI的工作变成整个测试设计流程中的一个“草稿生成环节”而不是“主导环节”。你可以利用AI快速产出80%的常规内容把精力集中在20%最有价值的风险判断上。4. 复杂迭代需求下AI生成测试用例的管理、复用与维护4.1 从“写用例”到“经营用例”难的是跨项目维护单一项目里使用AI生成测试用例只要把提示词和协同流程做对效果很快能看到。但真正让我头疼的是当这些用例散落在不同项目组、不同迭代周期、不同测试环境里整个测试用例的管理、复用和维护会变成一场噩梦。我见过最典型的失控场景是这样项目A组的测试同学用AI生成了一套用例项目B组的同学在另一个项目里也生成了一套两套用例里覆盖了同一个业务模块但步骤描述一个用的是“后台管理端”一个用的是“Admin控制台”同一个字段在两套用例里叫“退款金额”和“refundAmount”。时间一长没人说得清哪套用例是更新的哪套是失效的。等到两个项目要合并迭代时用例没法直接对齐只能人工逐条比对。这里我想强调一个观点测试用例不是一次性产物而是需要持续经营的核心资产。AI降低了写用例的“初始成本”但并没有降低维护成本反而因为生成速度太快每次迭代都会产出大量新用例如果缺乏管理机制整个用例仓库会迅速膨胀、重复、失准。4.2 模块化仓库 标签体系 动态优先级针对这个问题我试过很多方案最后沉淀下来的核心做法可以概括为三个关键词模块化仓库、标签体系、动态优先级。模块化仓库是指把测试用例按照“业务模块 功能点”的粒度组织而不是按照项目组织。比如有一条用例是验证“订单取消后优惠券退回”它应该归属于“订单域-取消-优惠券处理”这个模块而不是“XX项目二期-迭代三”。这样做的好处是多个项目在复用这条用例时不需要复制粘贴只需要引用模块ID。标签体系是让用例具备“组合查询”的能力。常用的标签维度包括业务风险等级、关联接口、关联数据表、自动化状态、最近变更时间、负责人。你可以用标签快速过滤出“所有P0且已自动化的订单域用例”然后基于这个集合做回归清单。动态优先级是指用例的优先级不是一次定死的而是随着迭代和线上事故动态调整。每次线上出问题我会先把这个事故关联的用例找出来把它的优先级提到P0并且检查AI生成的新用例里有没有覆盖类似场景。用AI辅助补全这类“踩坑用例”特别有效——只要把事故报告的核心信息提炼成业务规则模型就能很快生成一批类似后果的验证场景。这三个机制组合起来才能让AI生成的大量用例真正沉淀为可持续复用的资产而不是变成一座越堆越高的垃圾山。4.3 基线用例与增量用例分离策略跨迭代维护还有一个很实用的思路把用例集拆成“基线用例”和“增量用例”两部分。基线用例是那些验证核心业务逻辑、每次发布都必须回归、几乎不随需求变动的稳定性用例。它应该保持精简我的习惯是核心产品每个模块保留10到20条基线用例覆盖最重要的主路径和关键异常路径。增量用例则是每次迭代根据需求变化新增的那部分用例。这部分使用AI生成尤其合适因为增量功能的边界相对清晰你只需把本次迭代的需求规则描述给AI它就能快速生成一套初版用例然后你按之前的协同流程去完善。在实际管理时我会把基线用例放在一个受控的目录里任何改动都走评审流程增量用例放在迭代版本空间里发布后将增量用例中复用价值高的合并进基线用例其余归档。这个策略的好处是让用例仓库的增长是“有进有出”的不至于因为AI生成速度快而导致仓库无限膨胀。我在带团队时发现大多数用例维护崩溃的起点就是只增不删、只加不整理。4.4 从用例到自动化脚本AI辅助的落地路径除了用例本身的管理还有一个重要环节是自动化脚本的转化。现在也有很多团队在尝试“上传测试用例让AI自动生成Playwright自动化脚本”的Agent方案我自己的体验是这条路可行但风险比纯用例生成大得多。AI生成自动化脚本最大的问题在于定位表达selector的稳定性。大模型会根据界面结构的常规写法猜测元素定位符比如猜一个按钮的text值或者id但如果真实页面的DOM结构和它猜的不一致脚本就废了。我自己踩坑的经历很多后来总结出两个改善方向第一个方向是“用例前置环境标准化”。如果测试环境里总是能稳定构造出某些数据状态AI生成的脚本就可以避开复杂的数据初始化逻辑直接聚焦业务操作。这需要我们维护一套工厂造数接口在生成脚本之前先把数据准备好。第二个方向是“AI生成脚本草稿 人工修定位”。与其指望AI一次性输出可运行的完整脚本不如让它生成80%的步骤和断言结构然后把元素定位部分交给工程师补充和修校。还有一个更务实的做法是反过来先手工录制一段Playwright代码片段记录下真实的元素定位信息再让AI基于这些定位信息补全完整的测试场景。这样既保留了AI生成业务逻辑的能力又绕开了它虚构定位符号的问题。我始终觉得AI在自动化测试上真正的价值不是取代工程师写脚本而是加速“从用例到可执行代码”的翻译过程。但这个翻译链条里每个环节都需要人工把关尤其是那些和真实界面绑定的部分盲目相信AI会带来很大的维护痛苦。5. 常见问题排查与避坑技巧5.1 高频问题速查表为什么AI生成的用例总是不好用很多朋友问我为什么我给AI喂了完整需求它生成的用例还是浮在表面我把常见的原因和排查方向整理成了一张表方便你对照检查。问题现象常见根因优化方向用例看着全面但总是漏掉核心业务约束输入的业务规则太笼统只提了“支持退款”没说“退款金额上限”把系统约束、代码判断条件显式写进提示词边界用例全是“数字±1”类缺少业务边界提示词里没有强调“基于业务规则派生边界”增加“请识别业务规则中的边界条件”的约束生成大量同质化用例有效信息密度低模型在凑数输入信息的区分度不够把功能点拆细一次只针对一个场景生成回归用例覆盖不到本次改动影响面AI看不到代码变更也没有模块依赖图谱人工判断变更影响圈定回归范围后再生成用例在长对话中前后矛盾上下文太长模型注意力稀释拆分对话一次生成一组用例并导出保存自动化的步骤无法稳定执行元素定位是AI猜测的与真实DOM不匹配基于录制回放的定位信息来约束脚本生成5.2 排查链路先看输入再谈模型遇到AI生成用例质量差的时候我的排查顺序永远是先看输入再换模型。同样一段需求描述用ChatGPT生成一次、Claude生成一次、DeepSeek生成一次你会发现它们各自的风格不同但“是否理解业务约束”这一项的差距没那么大。所以第一步永远是检查自己给模型的信息。我在自检时常用一个方法把自己写的需求描述给一个刚入职的新同学看问他能不能不看任何代码就设计出可靠的测试用例。如果连人都做不到那说明输入太薄AI做不好完全正常。这时候要做的不是换模型而是回去补充业务规则、系统约束和已知坑点。第二步才是切换模型。每个模型的长处不太一样我之前提过Claude的长文档稳定性好些ChatGPT的结构化输出格式更易解析DeepSeek的中文表达更自然。你可以针对当前的用例类型去选模型比如长流程的用例交给Claude需要严格字段格式化的交给ChatGPT中文业务文档的直接用DeepSeek。但这种选择是调优不是救命输入的问题不解决换哪个模型都不治本。5.3 独家技巧用代码变更记录反向校验AI生成的回归用例最后分享一个我自己摸索出来的小技巧对提升回归用例的有效性特别有帮助。每次迭代的代码合入请求Pull Request或Merge Request里都会有文件变更列表。我会把这份变更列表下载下来提取出变更涉及的关键词比如“OrderService”“RefundStatus”“serialVersionUID”这样的类名和方法名然后把它们作为“系统约束”的一部分喂给AI让它在生成回归用例时优先覆盖和这些变更点相关的调用方。更深入一点的做法是人工快速浏览变更代码识别出“被修改的方法被谁调用了”这个调用关系是目前AI最难自己推理出来的。你只需要基于这个调用链让AI帮你生成“验证这些调用点没有挂掉”的回归用例。举个例子你看到OrderService.cancel()的入参从Long改成了CancelRequestDTO那所有调用这个方法的地方都需要回归。把“OrderService.cancel入参变更涉及调用方A、B、C”写进提示词AI生成的用例基本上就命中要害了。这个技巧本质上是用“人的判断”补足“AI看不到的调用关系”让AI在正确的影响范围里发挥它的文本生成能力。我用了这种方法之后回归用例的漏测率明显下降而且AI生成的用例不再是泛泛的“虚胖”清单而是一份有针对性的风险验证计划。说实话AI写测试用例这件事我现在的态度已经从“兴奋”变成了“务实”。它真的能大幅减轻测试设计的重复劳动尤其是那些模板化的枚举和格式化的场景描述但对测试用例里最核心的业务判断和风险取舍它给不了短期内也给不了。与其抱怨AI不靠谱不如把它放对位置——让AI当我们的高效打字员和场景策划师而我们负责把真正有价值的业务规则一颗一颗嵌进用例里去。这两件事配合好AI写测试用例就不再是空中楼阁而是切实可用的日常工具。