2026年了还有团队在手工维护测试用例Excel表我最近跟几个测试负责人聊天发现一个挺扎心的事实大部分团队对“AI提效”的理解还停留在让AI帮忙写点代码注释真正把AI接进测试用例生产链路的反而是那些规模不大的隔壁团队——他们用AI把功能测试用例的产出效率提升了差不多50%而且不是随便点点生成一下是实实在在把AI当成“测试设计合伙人”在用。这篇文章我不聊那些虚的AI概念直接把我自己带团队实操AI生成测试用例的过程、踩过的坑、以及现在稳定运行的流程全部摊开。如果你是测试工程师、测试开发或者正在被“手工补用例”折磨的研发负责人这篇文章应该能给你一套可以直接抄作业的落地思路。我会重点讲清楚AI到底能在测试用例的哪个环节真正省力以及为什么很多团队试了AI却说“没什么用”——问题通常不在AI身上而在你的使用方式和期望值上。1. 手动写测试用例的痛到底痛在哪1.1 用例设计的“脑力活”被干成了“体力活”很多人觉得写测试用例是件简单事不就是照着需求文档把输入、操作、预期结果列一遍吗但做过几年功能测试的人心里都清楚真正的难点根本不在“写”而在“想”——你要根据需求推导出正常流、异常流、边界值、分支组合、数据依赖还要考虑业务规则里的隐含条件。这些思考本该是测试用例最有价值的部分但落到实际工作中大部分时间反而花在了敲键盘上把脑子里想好的场景一条条敲进Excel敲完还要排版、归类、去重、关联需求编号。这个环节就是AI第一个能真正帮上忙的地方。AI擅长的事情就是把“自然语言描述”转成“结构化列表”而且速度极快。你把需求文档或者会议纪要丢给它让它按测试用例模板输出它能在几秒钟内给你一版覆盖了主流程、备选流程、异常流程的用例清单。这时候你的角色就从“打字员”变成了“审核员”把AI列出来的东西过一遍脑子删掉不合理的、补上遗漏的效率自然就上来了。1.2 覆盖率永远是纸面上的数字手工写用例还有一个隐藏痛点覆盖率统计基本靠拍脑袋。很多团队的用例库看起来几千条但真正跟代码逻辑对应的可能只有一小部分。尤其是当系统里存在大量分支判断、状态流转、权限组合的时候靠人力枚举总会漏漏掉的恰恰是线上最容易出问题的地方。AI在这个问题上有先天优势因为它可以“不厌其烦”地把组合场景穷举出来。我见过一个支付项目的例子手动写用例的时候支付方式的组合、优惠券类型、金额边界、用户等级这些维度叠在一起测试工程师写了两天也只覆盖了几十种组合。后来我们把维度列表扔给AI让它用正交法生成组合用例一下列出了两百多条有效组合去除重复和无效项之后还比人工枚举多发现了三个涉及优惠券叠加的边界问题。这种场景下AI不是替代人而是帮人把脑子里的“枚举能力”扩大了上百倍。1.3 需求变更是压垮用例库的最后一根稻草做过迭代型项目的人都有感触需求一变测试用例就要跟着改。今天改了接口字段明天调整页面交互你辛辛苦苦维护的Excel表很快变得面目全非。有些用例改了步骤忘了改预期结果有些用例根本没人再执行最终用例库变成了“僵尸库”。AI在这种场景下的价值在于“可快速重建”。传统做法是在旧用例上修修补补而AI的做法是根据最新需求重新生成一版用例再跟旧用例做对比合并。我们团队现在遇到需求变更不是先去翻旧用例而是先把变更后的需求描述喂给AI生成一个“增量用例集”然后人工比对变更影响范围把新增和修改的用例单独标记出来。以前这种变更评估大概要半天现在一两个小时就能搞定而且不会漏掉变更点。2. AI写测试用例的几种落地模式选错了就是白干2.1 模式一从需求描述直接生成用例LLM Prompt这是最基础的模式也是绝大多数人最先尝试的路径。操作很简单把一段需求描述扔给大模型让AI按“用例编号、前置条件、操作步骤、预期结果、优先级”这种字段输出表格。这个模式适合需求相对清晰、业务规则不复杂的模块尤其是内部管理系统、后台功能这种“表单列表”类的需求。但我要提醒一句直接从需求生成用例质量上限取决于你给AI的信息质量。如果你只丢一句话“用户登录”AI只能生成那些烂大街的登录用例如果你把字段校验规则、密码策略、锁定策略、验证码逻辑全部写清楚AI就能给出有针对性的用例。所以在这个模式里真正的工作量不在“点生成”而在“把需求描述写清楚”。我们团队的实操是先让AI扮演产品经理把原始需求拆成一条条“可测试的业务规则”然后再让它基于这些规则生成用例。拆规则这一步AI比直接生成用例更稳。2.2 模式二从代码仓库反向生成用例静态分析 AI如果你团队里有测试开发工程师手头代码质量也还行我更推荐第二种模式把代码变更的diff或关键方法喂给AI让它反推需要测试的行为。这个模式对单元测试和接口测试特别有效因为它本质上是让AI做了一次“代码阅读”。举个例子有一段代码是计算订单折扣的逻辑里面有几个if分支。把这段代码贴给AI问它“这段逻辑会有哪些分支每个分支应该验证什么”AI能把你漏掉的空指针、负值、零值、超大一类的边界条件列出来。很多Java项目里那些覆盖率死活提不上去的模块用这个思路补用例速度很快。不过我建议不要盲目让AI自动生成完整代码用例因为它可能生成一堆断言很弱、执行意义不大的“凑数用例”。更好的做法是让AI生成“测试场景列表”然后测试开发自己写落地代码这样质量最可控。2.3 模式三用AI Agent驱动Playwright自动写端到端用例这个模式是2025年之后特别火的方向也跟我们标题里那个“隔壁团队提效50%”直接相关。所谓AI Agent驱动Playwright简单说就是你给Agent一个目标比如“测试用户从下单到支付成功的完整流程”Agent会自己去分析页面结构、识别操作元素、生成Playwright脚本然后执行并自动校验结果。你不需要手工写定位符不需要猜XPathAgent会把整个流程跑给你看。实际落地的时候我们用的是“人工给步骤描述 Agent看页面写代码 人工审核跑批”的组合。比如我想写一个“注册-登录-下单”的用例我把业务动作描述一遍Agent会打开浏览器、逐项操作、遇到输入框就分析标签和placeholder遇到按钮就分析文本和可点击属性生成一套形如page.getByRole(button, { name: 登录 }).click()的代码。这一步比我之前手敲Playwright脚本快多了。但要注意AI生成的端到端用例对动态数据很敏感比如当前时间、随机数、短信验证码这些在脚本里特别容易因为环境差异而失败需要额外封装数据生成器。2.4 选型的判断标准时间、资源、团队水平这三种模式不是选最先进的而是选最合适的。我见过一个团队上来就搞AI Agent结果团队里没人会写代码Agent生成的Playwright脚本出了错也不会改最后全晾在那。我的建议判断标准很简单如果团队以手工测试为主、没有测试开发选模式一把需求拆解做好先用AI生成Excel用例集把覆盖率拉上去。如果团队有测试开发、代码质量尚可选模式二从代码和接口层面补场景重点补边界和异常。如果团队自动化基础扎实、已经用了Playwright或类似框架再上模式三让Agent帮你批量生产端到端脚本但一定要留出人工微调的时间。我可以直接说效率提升最明显的是模式三但前提门槛最高模式一最稳但提升幅度有限。隔壁团队说提效50%我猜他们大概率做的是模式三的端到端用例生成因为只有那个环节AI可以代替80%的重复劳动。手工设计用例本身很难被AI完全替代因为业务理解和对用户行为的判断还得出人来做。3. 实测让AI生成Playwright测试用例的完整流程3.1 第一步把需求文档结构化喂给AI之前先做这一步很多人让AI生成用例失败原因不是AI能力不行而是输入太烂。原始需求文档往往是散文式的夹杂着“尽可能”“通常”“可能”这种模糊词汇AI拿到这种输入生成出来的用例也必然是模糊的。所以我们在实际操作中会先把需求文档做一遍结构化处理产出“需求条目清单”。具体做法是把PRD逐段拆成三条要素操作对象、动作、业务规则。比如“用户在结算页可以修改收货地址切换后重新计算运费”我拆出来的条目就是操作对象收货地址动作切换业务规则切换后重新计算运费。每个模块拆完就得到一张十几行的条目表把这张表喂给AI让它基于每条规则生成测试用例。这样生成出来的用例跟需求有明确的映射关系覆盖率统计也变得顺手——有多少需求条目、有多少用例覆盖了它一拉就出来了。3.2 第二步写一段高质量的“用例生成提示词”提示词不需要花哨但一定要包含约束。我把自己反复打磨过的一个提示词骨架分享出来你们可以直接按这个结构替换业务信息你是一位资深测试工程师擅长功能测试用例设计。请根据以下需求条目生成测试用例。 需求条目 1. 输入框“手机号”规则必填、11位、支持正则校验 2. 按钮“获取验证码”规则点击后60秒内不可重复点击 3. 校验码输入框规则6位数字错误提示“验证码错误” 生成要求 - 按正常流、异常流、边界值分组 - 每条用例包含用例编号、前置条件、操作步骤、预期结果、优先级 - 操作步骤用给自动化测试看的格式化写法 - 不要重复覆盖同一条需求规则 - 输出为Markdown表格这里最关键的一句是“操作步骤用给自动化测试看的格式化写法”。如果你不加这句AI会输出“点击登录按钮”这种自然语言离自动化代码还有一步加了之后AI会倾向于用可操作的元素描述比如“点击登录按钮[namesubmit]”后面你让它转Playwright代码就顺畅多了。这步做完AI会给你一张用例表。你要做的不是直接拿去用而是先过一遍删除那些无意义的用例比如“验证码为空提示请输入验证码”这种地球人都知道的事合并重复用例然后用红笔标出你认为可能有坑的场景让AI基于你的标注再补充一版。这个“人机双向反馈”能让生成质量在第三轮之后明显提升。3.3 第三步让AI生成用例代码然后逐段校验用例表确认之后进入代码生成环节。我的习惯是让AI先出一版“骨架代码”也就是把每条用例的操作步骤翻译成Playwright的action链但不做任何复杂封装。比如正常运行时会生成这种def test_normal_purchase(self, page): page.goto(https://shop.example.com/login) page.get_by_label(用户名).fill(test_user) page.get_by_label(密码).fill(password123) page.get_by_role(button, name登录).click() page.get_by_role(button, name加入购物车).first.click() page.get_by_role(button, name去结算).click() page.get_by_role(button, name提交订单).click() page.expect_navigation(url**/order/success)拿到这版之后我不会着急跑而是逐段校验三件事一是元素定位是否足够稳定优先看getByRole和getByLabel如果发现某个定位用了大段CSS后代选择器我会让AI换成更易维护的方式二是断言是否覆盖了关键行为像登录成功、订单提交成功这种必须要有url或页面元素的断言不能只靠“没有报错”来判断三是是否缺少等待和网络空闲处理比如提交订单后页面跳转可能需要等待接口响应AI生成时往往默认一步到位我需要补充page.expect_response或者显式等待否则脚本在CI里会不稳定。校验完这版再把AI生成的全部用例合并到一个测试文件里用Playwright的trace查看器跑一遍记录每个步骤的action和网络请求。这一步会暴露不少问题比如某些用例之间相互依赖、登录状态没复用、数据没有隔离。我的建议是让AI生成用例的时候刻意要求它“每个用例独立不能依赖共享状态”否则跑歪了你得花两倍时间排错。3.4 第四步把AI生成的用例塞进CI持续迭代很多团队卡在这一步AI生成的用例本地跑通了放到CI里却天天红。原因一般是测试环境数据不稳定。早期我们也踩过这个坑后来总结出一套缓解方案所有涉及外部数据的用例统一走测试数据工厂比如注册用户、创建订单都用API预置而不是在UI里操作生成所有用例里不出现“期望固定时间”这种断言改成相对时间比较所有用例运行前先执行环境初始化脚本清空脏数据。还有一个比较重要的经验AI生成的用例在首次运行时最好标记为“冒烟候选”跑过两周稳定之后再纳入回归范围。我们团队现在的新用例流程是AI生成 → 本地人工审阅 → 冒烟跑三天 → 稳定后进回归。这三步平滑地解决了“AI生成的东西质量不稳定”的问题同时又不会让回归测试被一堆时好时坏的用例拖垮。4. 常见问题与排查技巧实录4.1 AI生成用例的三大“翻车现场”第一个翻车现场是“AI幻觉断言”。AI特别容易在预期结果里写“页面显示登录成功”这种没有落到具体元素的断言实际上页面上根本没有任何文案叫“登录成功”。这种断言跑起来是绿的因为Playwright默认只执行了操作没有校验结果——虚假的通过比失败更可怕。解决办法是要求AI在生成用例时必须给每个关键步骤配一个可以观测的UI状态变化比如某个toast文案、某个元素的disabled状态、某个跳转后的URL。如果AI给不了具体状态人工直接补。第二个翻车现场是“定位符串得太长”。AI为了保险经常生成一堆嵌套的CSS选择器比如div.container div.col-xs-12 form div.el-input:nth-child(2)一堆长选择器导致页面只要稍微调整布局用例就挂了。我们内部规定AI生成代码中禁止出现超过两层的CSS结构一律用getByRole、getByLabel或者显式test-id。有了硬性要求之后AI生成的脚本稳定性提升一大截。第三个翻车现场是“用例之间互相牵连”。AI有时会生成“先登录然后下单接着退款”这种长链路用例一旦中间某一步挂了后面全挂而且排查成本极高。现在我对AI的要求是一条用例只验证一个业务场景涉及多步时拆成多条通过API预置中间状态。这套原则让用例失败定位时间至少缩短了一半。4.2 排查思路先看断言再看元素定位最后看数据AI生成用例在CI挂了之后很多人的习惯是直接看截图看日志或者干脆“重跑一次看看能不能好”。我的经验是按照“断言 → 定位 → 数据”三层漏斗排查最好用。先看断言层是不是用例本身断言就不合理很多AI生成的用例断言写的是“页面包含某文案”但页面是异步渲染的文案出现前就已经断言了这种就换断言方式改成expect(page.locator(textxxx)).to_be_visible()并且加timeout2000等待。再看定位层元素是不是被遮挡、有多个匹配、或者iframe没切入AI生成的代码经常在iframe面前翻车因为普通定位根本定位不到iframe里的元素。我的做法是统一封装一个frame_locator方法让所有iframe相关操作都走它。最后才是数据层是不是前置数据没造好比如用例要求“已登录用户”但测试账号本身被禁用或者用例要下单商品库存为0。这类问题建议在用例开头做数据校验断言前置条件成立再开始跑而不是跑一半红掉。4.3 给AI当“质检员”人工抽检比例和回归策略AI生成的用例不能无脑全量进库否则你就是给自己挖坑。我建议第一次接入AI生成时人工抽检比例保持在70%以上也就是10条用例至少有7条是人工细看过、亲手改过定位符和断言的。随着AI生成质量稳定可以慢慢降抽检比例但始终不低于30%。这个抽检不是泛泛看一遍而是挑“高风险用例”——涉及支付、权限、数据变更的必须看。回归策略上我的做法是把AI生成的用例按“核心链路、重要功能、一般功能”三个级别打标。核心链路用例每天在CI里跑重要功能每周跑两次一般功能每周跑一次。这样既能保证AI生成的用例发挥作用又不会因为频繁跑低价值用例消耗太多维护成本。跑了一段时间之后把那些连续一个月零失败的用例标记为“稳定用例”减少检视频率把频繁失败的揪出来重点处理——往往这些用例背后藏着真实的产品缺陷就算不是也说明被AI生成的逻辑本身就不够稳。我实际操作下来的体会是AI辅助写测试用例这件事上限比我想象中高但下限也比很多团队想象中低。那些真正提效50%的团队不是把希望全押在AI上而是把AI当成一个需要人工调教的“实习生”——给它清晰的规则、审阅它的产出、帮它兜住低级错误然后它才越用越顺手。我自己现在每周写新用例的时间从两天降到了大半天剩余时间都花在了对场景的判断和对AI产出的审阅上这个模式我觉得是值得长期坚持的。如果你们团队正打算搞这件事我建议别一上来追求全自动化先从一个模块的用例生成跑起来把提示词标准和人工抽检流程定好再横向铺开——这样踩坑的代价最小成功率最高。