“AI不会写测试用例”这句话，我在太多复盘会上听过了。测试团队的负责人这样说，研发管理层也点头，最后的结论往往是“再等等，大模型还不成熟”。但说实话，这个结论下得有点冤枉现在的AI。我自己的项目里，已经用大模型辅助生成功能测试用例、接口测试用例，效率提升非常明显。真正让结果难看的，从来不是模型不会写，而是企业在输入、评估、落地这三件“人的事”上被卡住了。这篇文章想把这些实打实的经验拆开讲清楚，重点服务两类人：一类是正在带质量团队、想用AI做提效但不清楚从哪下手的测试负责人；另一类是刚接触AI编程和测试用例生成，想给自己找一套可复现方法的测试工程师。内容不绕弯子，直接说清楚AI生成测试用例这条路，问题到底出在哪，又该怎么解。
1. 先搞清楚：AI不会写测试用例，问题到底出在哪一层
1.1 工具早就“会写”了，“AI不会”更像一个伪命题
现在市面上的大语言模型、AI编程助手，写基础测试用例的能力已经超过很多人的预期。你给它一个明确的登录功能，它能按照功能测试的基本套路输出正常流、异常流、边界值、安全类的用例，格式规范，优先级也分得清楚。这在三年前还是不可想象的。真正的问题从来不是“AI懂不懂测试”，而是你交给它的材料、你给它设的边界、你验收它产出的方式，还停留在旧习惯里。
我做过一个很简单的对比实验：同一个AI，处理同一个模块，只改输入的详细程度，生成结果的质量差距可以达到“一眼能看出哪个能直接用”。这说明AI本身的能力并没有变化，变化的是喂给它的信息、约束和反馈机制。所以当团队把失败归因成“AI不会写测试用例”时，我通常会追问一句：你会给AI下需求吗？你会判断它写得对吗？它写的用例有没有被真正接进流程里？这三个问题一问，基本上就找到卡点了。
1.2 真正让你交付不了的三道关口
围绕AI生成测试用例这件事，大部分团队卡住的位置非常集中，我总结成三道关口。
第一道是输入关。需求文档含糊、用户故事只有标题没有验收标准、接口文档缺失、历史用例没有沉淀。AI在这种“半饥饿”状态下，只能靠通用知识硬写，产出的用例当然看起来像教科书目录，条条都对，但没有一条能直接指导某次具体测试。
第二道是评估关。团队没有一个统一的质量标尺，不知道什么样的AI生成用例算合格。于是有人凭感觉说“还行”，有人说“这不就是网上抄来的嘛”，最后谁也说服不了谁，试点推不下去。
第三道是流程关。就算AI生成的用例质量还不错，也融不进现有的迭代节奏。用例写好之后放哪、谁来评审、需求和代码变了之后怎么更新、AI多久再跑一次，这些问题没有人定义。AI生成用例变成了一次性的“炫技动作”，而不是持续运转的工程机制。
这三道关口，任何一道没打通，都会让“AI不会写测试用例”变成一个自我实现的预言。
2. 卡住你的第一件事：输入太“饿”，AI想写好也喂不饱
2.1 为什么AI生成的用例总是“正确的废话”
AI本质上是一个基于上下文做预测的系统。你给它的上下文越具体，它输出的内容就越贴近你的业务。反过来，如果上下文只有“请为登录功能生成测试用例”这句话，它就只能依赖训练数据里的通识，给你一套放之四海而皆准的模板。
这类用例有一个典型特征：看起来非常专业，有编号、有前置条件、有步骤、有预期结果，但你拿过去执行会发现，它测的全部是“用户名密码对了能不能登录成功”这种任何人用脚趾头都能想到的场景。真正有价值的边界条件、异常恢复、业务规则冲突、历史缺陷回归点，往往一个都没有。不是AI不想写，是你没告诉它这些规则存在。
我常用一个类比来解释这件事：AI就像一个能力很强但刚入职的新同事。你什么都不告诉他，让他自己写测试方案，他只能基于自己的经验写个大概；你把业务规则、模块边界、历史故障、用户习惯都讲清楚，他就能写出接近资深测试工程师的方案。问题在于，很多团队连一份像样的“入职说明”都拿不出来。
2.2 一个例子看懂“弱输入”和“强输入”的天壤之别
我用一个真实的场景来说明。假设要生成“邮箱密码登录”的测试用例。
弱输入的写法是：
请帮忙生成登录功能的测试用例。AI大概率会生成类似这样的内容：
- 用正确的邮箱和密码登录，断言成功。
- 用错误的密码登录，断言失败并提示错误。
- 邮箱为空时点击登录，断言提示邮箱不能为空。
- 密码为空时点击登录，断言提示密码不能为空。
不能说错，但这些用例拿到项目里，几乎占不到有效用例的20%。它覆盖不到真正的风险。
强输入的写法是：
功能模块：邮箱密码登录。 业务流程：用户在登录页输入邮箱和密码，点击登录按钮，调用后端登录接口；接口验证邮箱格式、密码长度、账号状态和密码错误次数；验证通过后返回token并跳转首页；失败时在页面上展示对应文案。 业务规则： 1. 邮箱格式必须符合RFC标准，且长度不超过64个字符。 2. 密码长度8到20位，必须包含字母和数字，不能包含连续三位以上相同字符。 3. 密码连续错误5次，账号锁定30分钟，锁定期间即使密码正确也不能登录。 4. 登录接口同一个IP每分钟最多请求30次，超出后触发图形验证码。 5. 账号状态包含正常、禁用、未激活三种，禁用和未激活账号不允许登录。 请基于以上规则，分别从功能、异常、边界、安全、兼容五个维度生成测试用例，重点覆盖业务规则中提到的字段限制、状态流转和频控逻辑。输出格式为：用例编号、前置条件、测试步骤、测试数据、预期结果、优先级。同样一个AI，在这种输入下生成的用例，基本会覆盖到“第5次输错密码后第6次输入正确密码，是否仍然锁定”“密码为17位但只含字母的用例”“账号停用状态下尝试登录的提示文案”这种有真实执行价值的场景。
这个差异不是AI能力带来的，完全是你给它信息的颗粒度带来的。所以测试团队要做的第一件事，不是追究AI行不行，而是把自己模块的需求信息整理成AI能看懂的“结构化投喂”。
2.3 可以直接抄的AI生成用例输入模板
结合我在多个项目里的经验，一个可复用的AI生成测试用例输入模板，应该包含五个板块：功能概述、业务流程、业务规则、测试范围偏好、输出格式要求。
【功能概述】 一句话描述这个功能模块的作用，以及它涉及的页面/接口/数据对象。 【业务流程】 按步骤描述一个完整业务从开始到结束的过程，包括用户操作、系统响应、依赖的外部服务或数据。 【业务规则】 逐条列出该模块涉及的校验规则、状态规则、权限规则、异常规则、频控规则等。 注意：规则的来源可以是需求文档、接口文档、产品补充说明、历史缺陷记录，越完整越好。 【测试范围偏好】 说明你希望覆盖哪些维度，例如：功能流程、异常输入、边界值、安全性、兼容性、性能约束。 也可以明确排除某些维度，避免AI展开无意义的发散。 【输出格式要求】 要求AI按指定字段输出，例如：用例编号、前置条件、测试步骤、测试数据、预期结果、优先级。 建议再补一句“如果发现业务规则中有冲突或信息缺失，请在用例后单独列出风险点”，这样AI会成为帮你找需求漏洞的助手，而不只是写文档的工具。很多团队把时间花在反复调提示词上，这其实走偏了。提示词只是骨架，真正有营养的是你往里面填的业务规则。填的内容，比问的方式重要一百倍。
3. 卡住你的第二件事：没有质量标尺，AI写得行不行没人能拍板
3.1 判断一份AI测试用例“行不行”的五个维度
AI生成用例很容易出现另一种极端：生成内容特别多，一次给出一百条，团队反而不知道该怎么验收。这时候如果组织内部没有一个统一的质量标尺，评审就会变成各说各话。
我建议用五个维度来评估一份AI生成的用例：
- 覆盖率：是否覆盖了核心业务流、异常流、所有业务规则中的边界点，以及历史缺陷的高发区域。
- 可执行性：每一步操作是否明确到可以直接照着做，前置条件和测试数据是否完整。
- 有效性：每条用例是否能验证一个明确的功能点或规则，而不是前后步骤重复、结论模糊。
- 业务贴合度：用词、术语、规则是否和当前业务一致，有没有张冠李戴。
- 去冗余度：是否存在大量重复场景，是否把同一条逻辑用三种方式反复描述。
这五个维度不需要做成特别重的流程，但至少在每个评审周期里要有一个人按这个框架给出结论。没有标尺之前AI生成用例质量好坏全凭感觉；有标尺之后，大家讨论的焦点会迅速从“你相不相信AI”转移到“这条用例覆盖了一个实际业务规则吗”，对话就健康了。
3.2 人机分工，不让人工当AI的“复核机器”
很多团队试点AI生成用例时，最容易犯的错是把AI写出来的用例直接丢给测试工程师一条条审核。结果工程师的负担比原来还重，最后得出一个结论：AI不但不能提效，还添乱。这个结论其实是分工出了问题。
我在项目里最常用的分工方式是“AI出初稿，人做编辑，人审主干”。AI负责大量的铺底工作：生成常规功能用例、按规则穷举边界组合、补充异常场景、格式化输出。人工负责三件事：第一，在AI产出的基础上删减合并，去掉不符合业务实际的废话用例；第二，补充只有人知道的隐性知识和历史项目经验，比如某个页面弹窗在特定浏览器上有已知问题；第三，对主流程和核心风险的用例做最终拍板，确保大方向不出错。
在这个分工下，人的角色不是“复核机器”，而是“主编”。AI负责稿件的量和覆盖，人负责质量和判断。很多团队抱怨AI生成用例之后还要一条条改，那是把AI理解成了“一键生成终稿”的工具。它本质上是一个可以把2天工作量压缩到2小时初稿、再让你花1小时精修的资源，而不是完全替代测试思考的黑盒。
3.3 小团队也能跑起来的用例验收闭环
小团队不需要搭建什么重型平台，一个共享文档加一个定期评审就能形成闭环。
我见过一个效率很高的做法：测试负责人每周评选3到5条“本周AI最佳用例”和“本周AI最无用例”，放在团队共享文档里。最佳用例用于沉淀输入模板的优点，告诉团队什么信息值得补进需求描述；最无用例用于反推模板的不足，比如某条AI用例完全偏离了业务，那大概率是某个业务规则没写清楚，而不是AI的问题。
这样一来，每次生成用例的验收就不只是交付了一批用例，而是顺带打磨了团队的需求表达能力和业务梳理能力。这个闭环跑上3到4个迭代之后，AI生成用例的一次性可用率会明显提高，因为喂给它的信息越来越完整，验收标准也越来越明确。这也是我做AI生成测试用例时最推荐的一个起步方式：不着急上工具和平台，先把“写用例前的人机分工”和“评审口径”立起来。
4. 卡住你的第三件事：流程没打通，AI生成的用例根本落不了地
4.1 把“生成用例”从一次性动作变成迭代中的持续动作
AI生成用例最常见的失败方式是“一次性试点”：某个版本快结束了，团队拿AI补写一批用例，看起来产出很厚，但下一次迭代没有任何机制能延续。用例更新不了，需求一改，AI生成的用例就成了过期的废纸。
我在项目中真正见效的做法，是把AI生成测试用例嵌进需求变更的节点。每次需求文档更新、接口定义调整或缺陷单归档时，就触发一次对这个模块的用例生成。触发的入口不一定是平台，也可以是迭代计划里的一个固定任务。比如每次sprint规划完成后，测试负责人抽出30分钟，把本轮需求的业务规则更新进输入模板，让AI重新生成受影响模块的用例，再快速评审骨干部分。30分钟换来的是一轮更新过的测试基线，比测试开始那天再临时补用例强太多。
这个动作能成立的前提，是输入模板不是一次性文档，而是跟着需求持续演进。每轮迭代更新的规则、新增的边界条件、新发现的缺陷点，都要定期回填到模板里。模板活了，AI生成的用例才是活的。
4.2 用例质量反馈回路，AI越用越懂你的业务
流程要真正打通的标志，是形成一条质量反馈回路：AI生成用例 → 人工评审筛选 → 执行阶段补充缺陷场景 → 回填输入模板 → 下一次AI生成时自动带上这些经验。
这条回路里最容易被忽略的是回填这一步。很多团队用AI生成了用例，执行时发现了几个之前没写进需求里的缺陷触发场景，改完代码就散了。这些场景其实是最值钱的资产，因为它们是你业务里真正容易出问题的地方。把这些场景转成业务规则描述，加进输入模板，AI在之后生成时就会自动优先覆盖这些区域。
我在一次接口测试的项目里，第一个版本AI生成的用例子有效覆盖率只在30%左右，我坚持把前两个迭代里线上出现的10个问题场景全部转成规则写回模板。到第三个迭代，AI生成用例的同类问题覆盖率达到七成以上。这不是AI变聪明了，是它开始掌握这个项目的“缺陷热力图”了。只要反馈回路不断，效率会持续提升。
4.3 落地时最容易翻车的三个细节
细节直接决定成败。我在项目落地时反复踩过一些坑，挑三个最典型的说。
第一个细节：不要全量生成，先按模块隔离。很多团队一上来就把整个项目的需求文档都喂给AI，要求一次性输出所有模块的测试用例。结果AI在长上下文里严重失焦，每个模块都写得很浅。正确做法是先挑一个需求最清晰、规则最多、回归成本最高的模块做试点，比如支付、权限、登录这类模块，把效果做出来再扩大范围。
第二个细节：注意用例的去重和归并。AI特别擅长用不同的表达方式描述同一个场景，比如“密码错误时提示文案是否正确”和“输入错误密码后点击登录，检查页面是否出现提示”，本质上是同一个功能点。指望AI自己完全去重不现实，所以模板里要明确规定“同一条业务规则只保留一条最高优先级用例”，并设定总体条数上限，比如“全模块不超过80条”，逼着AI做取舍而不是堆数量。
第三个细节：和现有测试管理工具打通，而不是另起炉灶。如果团队已经习惯用某一套测试管理平台管理用例，AI生成的用例必须能导出成团队熟悉的格式，最好还能带上需求ID和模块路径。不然AI用例生成得再好，工程师还是要在系统里手工复制粘贴，提效幅度会被砍掉一大半。数据在哪个工具里，人和流程就在哪个工具里沉淀，这个现实不能绕开。
5. 照着抄的落地路线图：从试点到推广的四周计划
5.1 四周试点计划表
如果你所在团队准备引入AI生成测试用例，又不知道怎么迈出第一步，建议直接按下面这个四周计划来执行。我拿它带过三四个团队，节奏相对稳。
| 阶段 | 时间 | 核心动作 | 产出物 |
|---|---|---|---|
| 第1周 | 准备 | 选定试点模块，收集现有需求文档、接口文档、历史用例，整理成AI输入模板的初版 | 一份结构化的模块信息包 |
| 第2周 | 生成 | 用AI生成试点模块的测试用例初稿，组织两轮快速评审，统计一次性可用率 | 一批标注修改过AI生成用例+问题清单 |
| 第3周 | 评估 | 定义五个维度的质量标尺，把评审结论和输入模板做对比，修订业务规则描述 | 一套可复用的输入模板+评估标准 |
| 第4周 | 铺开 | 扩大到一个完整迭代的需求范围，把AI生成嵌入迭代计划，正式对比提效数据 | 一份试点总结+推广建议 |
第1周最容易被低估。很多团队觉得“用AI还需要准备什么，拿需求文档直接喂就行”。但准备阶段的深度直接决定了后续三周的效果。你花一个下午把业务规则一条条列清楚，AI生成用例的质量会成倍上升，这个时间花得绝对值。
5.2 试点成功指标怎么定
试点之前就要定义“什么算成功”，否则第四周复盘又变成一场互相甩锅的会议。我建议用三组指标来评估。
第一组是效率指标：单模块用例编写时间从过去的多少小时，降到现在的多少小时；评审一次通过率是多少。第二组是覆盖指标：核心业务流覆盖率、历史缺陷回归覆盖率是否达到既定目标，比如核心流100%、历史缺陷回归80%以上。第三组是质量指标：新用例在后续测试中是否发现了至少1到2个需求文档里没写明、但实际存在的规则或边界问题。
有一点要特别注意：试点阶段不要用“缺陷发现数”作为唯一指标。AI生成本身不会凭空发现缺陷，它更大的价值是帮你提前把覆盖盲区补上。你把一张之前漏测的边界条件补进用例库，这本身就是收益。把指标定义清楚，试点团队就不会因为“AI没找到惊天大bug”而否定整个方向。
5.3 推广前先解决这三个问题
四周试点结束之后，如果效果不错，接下来要面对的问题就变成了“如何推广”。我建议在推广前先把三个问题解决掉，否则推广很快会变质成“全员命令使用AI”。
第一个问题：谁负责维护输入模板。AI生成用例的可持续性完全取决于模板的更新频率。试点阶段可以是测试负责人亲自维护，推广阶段必须把这个职责写进某个固定的角色定义里，不然过两个迭代模板就凉了。
第二个问题：不同模块的质量标准怎么对齐。不是所有模块都值得建一套完整的输入模板。核心业务模块、规则复杂的模块优先级高；页面简单、流程单一的模块，可以做简化模板，避免过度设计导致的流程负担。
第三个问题：老测试用例库怎么处理。AI生成用例不是要推翻已经沉淀的用例资产。比较务实的思路是：现有用例继续用，AI生成用于填补历史用例的缺口和需求变更后的增量。这样既不否认团队过去的沉淀，也能让新方法逐步占据增量空间。
6. 高频问题与排查技巧实录
6.1 高频问题速查表
在这类项目推进过程中，团队反馈最多的问题基本集中在下面几种场景里，我整理成了一张速查表，可以直接对照排查。
| 问题表现 | 根本原因 | 排查与解决 |
|---|---|---|
| AI生成的用例全是大路货 | 输入信息太少，业务规则没有结构化的描述 | 用输入模板重新整理需求，把业务规则逐条写清楚再去生成 |
| 用例太多，重复率极高 | 缺少条数限制和去重约束 | 在提示词中明确按规则分组，同一场景只保留最高优先级用例，并设置总条数上限 |
| 用例步骤无法执行 | 缺少界面元素、接口字段等细节 | 补充页面原型、接口定义、字段枚举等基础资料 |
| 评审时大家意见不统一 | 没有质量标尺 | 用覆盖率、可执行性、有效性、业务贴合度、去冗余度五维评分 |
| 生成结果时好时坏 | 模板不稳定，输入波动太大 | 把模板固化下来，每次只改描述业务信息的部分 |
| 团队不愿用AI产出 | 没有明确的人机分工 | 把AI定位成初稿生成器，人的工作是筛选编辑而非从头校验 |
6.2 三个反直觉但实测有效的经验
最后分享三个我在实际操作中总结出来的经验，它们多少都有点反直觉，但实测下来非常有用。
第一个经验是：好的提示词不是关键，好的业务知识清单才是关键。很多团队沉迷于学习各种“高级提示词”，但真正的高手都在打磨自己的业务规则库。你可以自己做个测试：把同一套输入模板用三个不同的大模型各跑一遍，你会惊讶地发现它们输出的质量差距，远小于你用同一模型跑“有规则”和“没规则”两种输入时的差距。所以把时间花在梳理业务上，比花在“提词工程”上更划算。
第二个经验是：给AI看几个“坏例子”。我在模板里专门加了一个板块，叫“历史缺陷场景”，每一条就是曾经在这个模块出过的事故描述。AI在生成用例时看到这些坏例子，就会刻意去覆盖类似的场景。这个做法对测试用例有效性的提升特别明显。它的原理也很简单：大模型的生成会参考上下文里的关联信息，你把风险场景写进上下文，它的注意力就会主动往那里偏移。
第三个经验是：初期不要让AI规划测试策略，先让它做执行级的用例生成。测试策略需要考虑优先级、风险、资源排期，这些东西目前的AI在多数企业场景下还容易给出正确的废话。但具体到“某个规则下应该验证哪几条用例”，它做得又快又好。与其指望AI帮你做测试计划，不如把它用在填充测试细节这种更适合它的环节上。把合适的事交给合适的角色，这才是AI生成测试用例能持续产生价值的根本原因。
个人在实际项目里体会最深的一点是：AI生成测试用例这件事，八成以上的功夫花在AI之外。输入信息、质量标尺、流程衔接，这三件看起来都是“老生常谈”的管理话题，但它们恰恰决定了AI这个新变量能否真正产生收益。如果你正在推这件事，别急着换工具、换平台，先把手头最熟悉那个模块的需求文档整理成一套结构化输入模板，再让AI去写一遍，你大概率会立刻感受到差异。等团队真正建立起“生成-评审-回填-再生成”的小循环，AI生成的用例会越用越顺手，到时候你回过头再看那句“AI不会写测试用例”，估计也会和我一样，笑着摇摇头。
