夜雨聆风👇 【本文剧透 / 你将看到】
最近我一直在使用我自己的测试用例生成平台，让它帮我生成测试用例。
整体来说看起来是没有大问题的。
有模块。有步骤。有预期结果。甚至还会分正常场景、异常场景、边界值场景。
这不就是测试人梦寐以求的“自动写用例”吗？
但我使用了一段时间后发现一个问题：
它写得很完整。
但它不一定真的懂业务（即使给它业务背景文档，但是也无法全部给到它，因为同一个业务可能又涉及到其他多个业务）
这也是我现在对 AI 生成测试用例的真实态度：
能用，但不能直接用。
AI 更适合当一个测试助理，帮我们生成初稿、补充思路、整理结构、查漏补缺。
但最后要不要采用、风险有没有覆盖到、这条用例有没有价值，还是得靠测试工程师自己判断。
一句话说就是：
AI 不是替你测试，而是帮你更快进入高质量思考。
AI 写测试用例，确实很爽
先说实话。
AI 写测试用例这件事，确实爽。
以前我们拿到一个需求，通常要先做几件事：
读 PRD 拆功能点 梳理主流程 补异常场景 考虑边界值 再想权限、数据状态、上下游影响
如果需求很长，光是从 0 开始整理测试点，就已经很费脑子。
尤其是那种文档写得很“产品语言”的需求。
你看完以后知道它大概想做什么，但要真正拆成可执行的测试用例，还得自己在脑子里翻译一遍。
AI 在这个环节就很好用。
你把需求丢给它，经过测试点拆解skill，它很快就能生成一版测试点： （关于测试点拆解skill，可见这篇文章：我是怎么把“拆测试点”这件事，做成一个可复用 Skill 的）
功能点拆解 正常流程整理 基础异常场景补充 边界值提醒 用例格式标准化 从 0 到 1 搭一个框架
它最大的价值，不是替你一步到位写完所有用例。
而是帮你把空白页填起来。
对测试来说，这个帮助其实很大。
因为最痛苦的往往不是修改，而是从 0 开始。
空白页真的会让人脑壳疼。
但它最大的问题是：看起来很完整
AI 写出来的测试用例，最危险的地方不是它写得差。
而是它写得太像真的了。
格式很标准。语言很专业。分类也很清楚。甚至每条用例都有步骤和预期结果。
但这些都不代表它真的覆盖了风险。
很多时候，AI 生成的内容会有一种“表面完整感”。
看起来什么都有。
但关键问题可能没覆盖到。
比如一个普通的商品发布功能，AI 可能会写：
商品发布成功 商品编辑成功 商品下架成功 商品标题为空校验 商品图片格式校验 商品价格不能为空 商品详情保存成功
这些场景当然没错。
但如果放到二手奢侈品交易业务里，这就远远不够了。
它可能漏掉：
鉴定状态变化 寄卖和回收业务差异 商品价格审核规则 不同角色的操作权限 历史 Bug 高发链路 库存、订单、支付之间的状态联动 后台审核后，前台展示是否实时更新 商品状态变化后，搜索结果是否同步
这些才是真正容易出问题的地方。
AI 可以补很多通用场景。
但它不一定知道你们公司的真实业务规则（这需要大量的历史沉淀知识库，这现在应该是每个公司想要使用AI但是无法完全推展开的痛点）。
更不知道你们系统以前哪里炸过。
所以我现在看 AI 生成的测试用例，会先提醒自己一句：
格式正确，不代表测试有效。
AI 最容易漏掉的 5 类测试点
我自己用下来，发现 AI 生成测试用例时，最容易漏掉这 5 类内容。
1. 业务隐性规则
很多业务规则，其实不会完整写在 PRD 里。
比如：
哪些状态不能逆流转 哪些字段虽然不是必填，但业务上必须校验 哪些操作只有特定角色能做 哪些状态下按钮应该隐藏，而不是置灰 哪些流程虽然页面能点，但业务上不允许操作
这些东西，往往是测试、产品、研发在长期协作里慢慢形成的共识。
AI 如果只看 PRD，很难知道这些隐性规则。
它能看见“写出来的需求”。
但看不见“没写出来的业务经验”。
2. 历史 Bug 场景
AI 不知道你们系统以前哪里老出问题。
但测试工程师知道。
比如：
某个字段经常空指针 某个接口高峰期容易超时 某个页面兼容性特别差 某个流程上线前经常返工 某个状态流转以前出现过脏数据 某个按钮重复点击会产生重复提交
这些历史 Bug 场景，往往是测试里特别重要的回归点。
但如果你不告诉 AI，它大概率不会主动想到。
所以用 AI 写用例时，我会特别关注：
它有没有覆盖历史问题。
如果没有，这一版用例只能算基础初稿。
还不能放心。
3. 上下游联动
AI 很容易只看当前页面。
但真实测试不能只看当前页面。
比如商品发布成功之后，不只是看发布页面有没有提示成功。
还要继续看：
商品会不会出现在列表里 搜索能不能搜到 用户端展示是否正确 后台审核状态有没有同步 库存有没有变化 后续下单流程是否受影响 价格修改后，订单侧有没有同步 商品下架后，用户端是否还可见
很多 Bug 都不是出在当前操作本身。
而是出在状态传递、数据同步、上下游联动里。
AI 如果没有完整业务链路，很容易只写“当前页面测试”。
但测试工程师要看的是整条链路。
4. 真实数据状态
AI 生成的测试用例，通常都很理想化。
但我们真实测试环境里，数据经常一点都不理想。
可能有：
脏数据 老数据 边界数据 数据状态不一致 特殊账号权限 历史版本遗留数据 线上回流数据 被其他人改过一半的数据
有时候，一个功能在干净数据下没问题。
但一遇到历史数据，就开始出妖怪。
这类问题，AI 很难凭空帮你想到。
因为它不知道你们测试环境里那些“祖传数据”的脾气。
这个就很真实。
测过的人都懂。
5. 优先级判断
AI 可以生成很多用例。
但它不一定知道哪条最重要。
它可能会把“按钮文案是否展示正确”和“支付金额是否计算正确”放在差不多的位置。
但测试工程师不能这么看。
我们要判断：
哪些是 P0 主流程 哪些是上线必测 哪些是高风险链路 哪些是低风险场景 哪些适合自动化覆盖 哪些必须人工重点验证 哪些可以放到回归阶段
测试用例不是越多越好。
而是要有重点。
真正值钱的不是“写了多少条”。
而是你知道哪里最容易出问题，哪里最值得测。
那 AI 生成的测试用例，到底应该怎么用？
我的建议是：
不要一上来就让 AI 直接生成完整测试用例。
可以分几步来。
第一步：先让 AI 拆测试点
不要急着要完整表格。
先让它帮你拆测试点。
先不要生成详细测试用例。
为什么要这样？
因为先看测试点，更容易判断有没有漏方向。
如果方向都漏了，后面生成再多详细用例也没用。
就像地图一开始就画错了，走得越认真，偏得越远。
第二步：再让 AI 按公司的格式生成初稿
当测试点确认差不多之后，再让 AI 生成完整用例。
比如固定成这样的格式：
模块 用例标题 前置条件 操作步骤 预期结果 优先级 测试类型 备注
这样生成出来的内容，更容易同步到飞书文档、测试管理平台，或者后续整理成表格。
这里有一个小技巧：
一定要告诉 AI 你的格式要求。
不要让它自由发挥。
AI 一自由发挥，就容易写得很“好看”，但不一定好用。
第三步：人工做一次测试评审
AI 写完之后，千万别直接复制粘贴。
一定要人工评审。
重点看这些问题：
主流程有没有漏 异常场景够不够 权限场景有没有 数据状态是否真实 是否结合历史 Bug 预期结果是否可验证 操作步骤是否能真的执行 优先级是否合理 有没有只写了页面校验，没写链路影响
我特别想说一句：
AI 写完用例，不代表测试完成。
测试工程师评审完，才开始靠谱。
第四步：让 AI 反向查漏
评审完一版之后，还可以让 AI 继续当“评审人员”。
比如这样问：
你现在作为测试评审人员，请检查上面这批测试用例可能遗漏哪些场景。
重点从权限、边界值、状态流转、异常数据、历史缺陷风险、上下游影响几个角度检查。
这个方法挺好用。
因为第一次让 AI 生成，它是站在“产出者”的角度。
第二次让它评审，它会换一个视角帮你挑问题。
虽然它依然不能完全替代人工判断，但很适合做查漏补缺。
我一般会把它当成一个“不会累的测试助理”。
让它多帮我扫几遍。
测试工程师真正不能交给 AI 的部分
AI 可以帮我们做很多事。
比如：
整理 归纳 生成 查漏 改格式 补充通用场景
但有些事情，不能完全交给它。
比如：
判断风险 理解业务 设计验证路径 识别关键链路 决定测试优先级 对上线质量负责
AI 可以生成用例。
但它不会替你承担质量风险。
上线后如果出了问题，不会有人说：
“没关系，是 AI 没写到。”
最后还是要回到测试自己身上。
所以我觉得，AI 时代测试工程师的价值，不是被削弱了。
反而更清晰了。
以前我们可能花很多时间在整理、复制、格式化这些事情上。
现在这些可以让 AI 多做一点。
我们把精力放回真正重要的地方：
风险判断。业务理解。场景设计。质量兜底。
这才是测试真正值钱的部分。
所以，AI 生成的测试用例能不能直接用？
我的答案是：
能用，但不能直接用。
它适合帮我们：
生成初稿 补充思路 整理格式 提醒边界场景 做第一轮查漏
但它不适合替我们做最终判断。
对测试工程师来说，最好的用法不是复制 AI 的答案。
而是把 AI 当成一个很快的测试助理。
它帮你铺底稿。你负责兜质量。
AI 负责提速。
人负责判断。
这可能才是目前最靠谱的协作方式。
最后也想问问大家：
如果让 AI 帮你写测试用例，你最担心它漏掉哪类场景？欢迎大家一起交流讨论！👏🏻
