现在有一种流行做法：把测试用例交给 AI，通过堆叠大量规则、提示词、约束条件，试图让 AI 一次性产出 “完整”“漂亮” 的用例。看起来效率很高，但真正落到一线测试执行中，往往是一种本末倒置。

所以会有社区小伙伴这样的疑问

测试用例不是规则的堆砌，也不是 AI 的命题作文。
它是测试人员对项目流程、需求理解、前置准备、环境熟悉之后，形成的质量保障思路。
用大量规则驱动 AI 生成用例，看似省事，实则把测试工作中最有价值，也是真正能缩短测试执行时间的部分让了出去。

一、规则无法替代测试人员对项目的真实理解

这类方案最核心的理念是：
把测试经验、方法论、业务踩坑显式落盘成规则文件，让 AI 按规则生成用例。
比如它可能会展示 AI 通过关联分析发现 “新功能与已有模块的关系未定义”，并追问产品经理：“新功能与已有模块是什么关系？替换、并存还是子集？”

这个追问看起来很有水平，但仔细一想，这不就是一个测试人员拿到需求后最基本的条件反射吗？ 任何一个稍微熟悉项目的测试人员，看到 “与现有功能一样” 这种描述，第一反应就是追问关系、兼容性、迁移路径。这不是 AI 的功劳，这是测试人员的基本功。

问题在于，当测试人员自己写用例时，这些追问是自然发生的，而且能结合现场情况实时调整。 而用 AI 生成用例时，测试人员需要先把这些 “基本功” 总结成规则，再让 AI 去匹配规则，最后 AI 输出的结果还要人工审核。绕了一大圈，效率真的更高吗？？？

更重要的是，实际项目中的很多问题无法通过文档规则解决。 需求文档缺失、口头需求、临场变更、环境不稳定、开发临时改方案……这些一线常态，AI 靠规则是处理不了的。规则是静态的，项目是动态的。测试人员真正的价值，是在混乱中找到测试重点，而不是依赖一套僵化写死的规则库。

二、AI 生成的用例 “漂亮但不可执行”

这类方案展示的 AI 生成用例，通常格式规整、步骤清晰、预期结果明确，还带了优先级和关联用例参考，看起来貌似非常专业。

但真正拿去执行，问题就来了：

• 前置条件理想化。 比如 “已登录系统，具备相关权限”“当前空间数量未达上限”。这些条件在真实测试环境中可能需要花费大量时间准备，甚至根本不存在对应的测试账号或数据。
• 操作步骤与实际系统不一致。 AI 生成的步骤可能基于通用模板或旧版需求，实际界面、入口、按钮名称可能已经变了。测试人员拿到用例后，还得先花时间核对 “这个页面是不是长这样”“这个按钮还在不在”。
• 断言点模糊或错误。 比如 “状态显示为正常/可用”，但实际系统可能没有这个状态字段。AI 是根据规则猜的，不是根据实际系统写的。
• 关联用例参考是历史代码，但历史代码本身可能已经过时。 有些方案会引用历史自动化用例作为参考，但这份代码是否还反映当前版本的行为？测试人员还得去读代码才能确认。

结果是，测试人员拿到 AI 生成的用例后，需要花大量时间去理解 AI 的思路，判断哪些能执行、哪些不能执行，再翻译成可操作的步骤。 这个时间，往往并不比自己直接写用例短，甚至更长——因为你还要先理解一个 “外人” 的思路。

可执行性是测试用例的生命线。一条不可执行的用例，写得再漂亮，也只是文档垃圾。而 AI 生成的用例，恰恰最容易在 “可执行性” 上翻车。

三、规则越多，噪音越大，重点越容易被淹没

这类方案往往花很大篇幅讲知识库和规则的分层加载、按需命中，试图解决 “规则一多就塞爆上下文” 的问题。但规则多带来的问题远不止 token 消耗，更严重的是噪音。

AI 有一个特点：联想能力很强。你给它越多规则，它越容易发散，生成大量看似相关、实则无用的用例。

比如规则库里有 “任何字符串字段都要查长度边界”“任何输入字段都要查特殊字符、SQL 注入、XSS”。
于是 AI 就会忠实地为每一个输入框都生成这类用例，不管这个输入框：

• 是否对外暴露；
• 是否在本期需求范围内；
• 是否已经有前端控件限制；
• 是否属于内部管理系统，安全风险极低。

更常见的是，有些功能根本还没有实现，AI 也会根据规则 “猜” 出一堆用例。 结果用例集越来越臃肿，执行成本越来越高，维护越来越困难。测试人员需要花更多精力去过滤无效用例，反而偏离了真正的测试重点。

有些方案强调 “测试点是廉价的，用例是昂贵的”，所以设计了人工卡点在测试点阶段过滤。但问题是，如果测试点本身就充满了噪音，人工卡点也救不了你。 测试人员面对一份几百条的测试点清单，要逐条判断哪些该留、哪些该删，这个工作量并不比直接写用例轻松多少。

四、重点不是模型判断的，是项目判断的

这类方案的规则库里往往有 “业务规则”，比如 “某个模块新增了某种能力，必须验证某个关联功能”。这个设计看起来很聪明，但问题在于：业务规则本身需要人工总结，而总结的粒度往往跟不上项目变化。

一个项目的测试重点，不是由规则决定的，而是由以下因素决定的：

• 当前版本的核心业务目标是什么（这个很卵鬼嗨重要）；
• 哪些功能是客户最关注的（一线背锅的小伙伴们应该理解）；
• 哪些模块历史上出过严重问题；
• 哪些接口是联调的重灾区；
• 哪些场景是性能瓶颈；
• 哪些改动可能影响数据一致性。

这些重点，是测试人员深入理解业务、了解项目背景、和开发产品反复沟通之后，才能识别出来的。它无法被简化为一张规则表。

AI 根据规则判断的 “重点”，往往是通用的、平均的。比如它通常认为登录、权限、输入校验、异常处理很重要，于是大量生成这类用例。但实际项目的重点，可能完全不在这些地方。核心盈利项目的测试，本质就是验证业务功能是否正常，没有那么多高大上的场景。 如果按照 AI 判断的重点去分配测试精力，很可能在通用场景上浪费大量时间，而真正重要的业务风险却被忽略。

五、“自学习闭环” 是理想化，实际维护成本极高

这类方案往往还强调 “知识回流闭环”：评审通过的需求、生成的用例都会回流知识库，供以后复用。听起来很美好，但实际执行起来，问题很大。

首先，AI 生成的内容质量参差不齐，回流反而污染知识库。 如果每次生成的用例都归档，那么知识库里会积累大量无效、过时、甚至错误的用例。这些 “脏数据” 会让后续的 AI 检索和生成效果越来越差。

其次，知识库需要持续人工维护。 规则要更新，文档要整理，历史用例要筛选。这本身就是一份不小的维护工作。对于一线测试人员来说，时间本来就很紧张——沟通、推进、执行、排查问题，哪一样不比维护规则库重要？让测试人员把时间花在维护一套复杂的规则库上，本身就是一种资源错配。

最后，“自学习” 的前提是 “有东西可学”。 但如果项目本身迭代快、需求变化大，历史用例和规则很快就不再适用，学到的都是 “过时知识”。这种情况下，闭环不仅没有价值，还可能成为负担。

六、AI 的正确位置：用例编写前的参考准备与编写后的完善，编写中要属于个人

我不是反对 AI 参与测试用例工作。我反对的是把 AI 当成用例生成的主笔，用大量规则去驱动它产出用例集。

AI 更适合的位置，是在用例编写前和编写后。

编写前，可以让 AI 提供思路和参考。比如：

• 对于一个需求，AI 可以列出常见的测试维度和风险点；
• 对于一个功能模块，AI 可以给出一些通用用例模板；
• 对于历史类似需求，AI 可以辅助回忆可能遗漏的场景。

这时 AI 的价值是 “启发”，而不是 “替代”。

编写后，可以让 AI 根据你写的用例，提出一些你可能没想到的点。比如：

• 你覆盖了正常流程，AI 提醒你补充异常流程；
• 你关注了功能正确性，AI 提醒你关注数据一致性；
• 你写了主路径用例，AI 提醒你补充边界条件和兼容性场景。

这时 AI 的价值是 “查漏补缺”，而不是 “主导设计”。

测试用例的主体，仍然应该由测试人员根据项目实际情况编写。 写用例的过程，本身就是测试人员梳理项目流程、理解需求、做测试前置准备、熟悉前置环境的过程。省掉这个过程，后面的执行、沟通、推进都会变得更加困难。

七、那些把 AI 用例生成吹上天的人，我说了很多次了，他们根本就不做一线测试的工作

现在很多人把 AI 用例生成说得天花乱坠，动不动就甩出一堆规则、提示词、工作流，号称可以大幅提升测试效率。有些方案还会说 “完整版在课程套餐里”“更多细节在社群中”，这种话术和很多培训课程如出一辙：先展示一个看起来很美的 demo，然后告诉你 “想要完整版就付费”。

我无意质疑任何人的能力或动机，但我想说：真正在一线做过复杂项目测试的人，很少会这么吹 AI 生成用例。

一线测试面对的现实是：

• 需求文档不完整，甚至没有需求文档，只有设计稿；
• 功能做了一半，接口还没联调；
• 环境不稳定，数据造不出来；
• 开发临时改方案，测试计划跟着变；
• 项目重点随时调整，昨天重要的今天可能不重要。

这些场景下，AI 基于规则生成的用例，基本派不上用场。规则是静态的，而一线项目是动态的、混乱的、充满不确定性的。那些把 AI 用例生成包装成 “万能解决方案” 的人，很多并没有真正在一线待过，或者只是为了培训讲故事。他们讲的是理想环境下的 AI，而不是真实项目里的 AI。

结语

测试用例的价值，不在于数量多少、格式多漂亮、规则多复杂，而在于：

• 是否真实反映了业务风险；
• 是否具备可执行性；
• 是否帮助团队提前发现问题（帮助你自己甩锅）

用大量规则去驱动 AI 生成测试用例，是把手段当成了目的。看起来效率很高，实际上本末倒置。

让测试回归测试，让 AI 回归辅助。测试用例，终究应该由最了解项目的人来写。