关于AI书写测试用例，谈一下我的思考

最近这一年多，我在工作中深度参与了几个 AI 测试平台的建设, 踩过的坑不少，也沉淀了一些方法论。这篇文章想聊聊：AI 写测试用例到底靠不靠谱？它最容易在哪些地方"翻车"？以及我们该怎么设计流程，才能让它真正提效而不是帮倒忙。

一、先泼一盆冷水：AI 写出来的用例，很多是"废品"

现在让大模型根据需求文档生成测试用例，已经不是什么新鲜事了。随便找个 AI，把需求贴进去，说一句"帮我生成测试用例"，几分钟后你就能拿到几十条用例——标题规范、步骤齐全、预期结果写得有模有样。

看起来很美好，但真正拿去评审和执行，问题马上就暴露了：

• 有些用例看起来很专业，实际上根本执行不了；
• 有些步骤写得行云流水，但需求里压根没有这个依据；
• 有些预期结果读着没问题，但谁也说不清到底怎么算通过。

更麻烦的是，AI 只盯着当前这份需求，它不知道这个模块历史上踩过什么坑、哪些字段经常出线上问题、团队以前是怎么覆盖类似场景的。所以它写出来的往往是"需求说明书级别"的用例——很干净，但也很浅。

我个人的结论是：AI 写测试用例最大的风险，不是写得慢、写得少，而是它会批量产出"看起来像测试用例、实际上无法落地"的内容。一旦这种内容混进用例库，提效工具就变成了返工素材。

AI写测试用例，我总结出了有以下几大坑。

二、坑点一：盯着测试点标题，开始"脑补"测试范围

这是 AI 犯的第一个、也是最隐蔽的错误。

举个例子，需求里只有一句话：

招聘者资料页支持修改联系电话。

AI 拿到这个测试点，很可能立刻给你扩写出一套"完整流程"：

1. 进入个人中心
2. 点击账号安全
3. 输入新手机号
4. 获取并输入短信验证码
5. 点击保存，验证修改成功

读起来特别顺，特别像一个真实产品。但问题是——需求里根本没有"个人中心"，没有"账号安全"，也没有"短信验证码"。这些全是 AI 基于它见过的无数 App 脑补出来的。

这个坑最毒的地方在于：它不是一眼假。写得越像真实系统，评审时越容易被一眼带过。等到执行阶段才发现：页面没这个入口、字段名对不上、流程和需求完全是两套东西。

所以我的做法是，坚决不让 AI 一步到位地"根据需求生成完整用例"，而是拆成两步：

1. 先让 AI 输出测试点列表（只回答"要测什么"）；
2. 再让它基于测试点逐条展开步骤，并且强制要求每个步骤都标注需求原文依据。

背后是一个很重要的原则：测试用例不是文学创作，不允许靠"合理想象"补全系统行为。

三、坑点二：步骤写得很完整，但执行不了

第二个高频问题：步骤太"虚"。

AI 特别喜欢写这种看起来正确、但没有操作细节的句子：

• “验证用户可以正常提交表单”
• “检查数据是否展示正确”
• “确认流程可以正常完成”

这些话放在测试方案里没问题，但放在用例步骤里就是废话。一条合格的测试步骤，执行人拿到之后应该明确知道：去哪个页面、点哪个按钮、填什么数据、触发什么动作。

我给自己团队定过一个很简单的判断标准：

如果一条步骤里只有"验证、检查、确认"这类动词，却没有明确的操作对象和输入数据，那它大概率不可执行，打回重写。

接口测试用例更容易被写虚。AI 经常给你来一句"调用接口，验证返回正确"——请求参数是什么？必填字段边界在哪？返回体里哪些字段是核心业务字段、哪些可以忽略？全都没说。

测试用例的价值不在于句子漂亮，而在于让执行人少猜一点、让自动化脚本能多承接一点。这也是我们后来在做智能接口测试平台时，坚持把接口文档（入参约束、枚举值、依赖关系）作为结构化上下文喂给模型的原因——不给它这些，它只能写"正确的废话"。

四、坑点三：预期结果"写得对"，但没法判断通过失败

第三个问题更致命：预期结果不可验证。

AI 生成的预期结果，高频出现这些词：

• “系统正常返回”
• “页面展示正确”
• “数据符合预期”
• “流程处理成功”

读着没毛病，执行的时候测试同学还是得问：什么叫正确？什么叫成功？我看哪个字段？看哪个状态码？看哪条文案？

一个无法判断通过/失败的预期结果，就不是预期结果。

这一点在接口自动化里尤其关键。接口返回的 JSON 往往很长，里面有稳定字段，也有动态字段。AI 如果不区分字段类型，很容易给出错误的断言策略。我们实践中总结的规则是：

这也是为什么我认为，AI 生成用例之后必须再加一道断言分析/用例评审环节——不是为了把流程搞复杂，而是为了把"看起来正确"变成"真的可判断"。

五、只读需求是不够的：让 AI 先读历史，再写用例

很多人做 AI 用例生成时，默认输入只有一个：需求文档。这个思路没错，但远远不够。

想想一个资深测试工程师写用例时，脑子里装的是什么？不只有当前需求，还有大量隐性上下文：

• 以前类似的需求是怎么测的；
• 哪些地方出过线上 bug；
• 哪些字段是核心字段、哪些边界容易漏；
• 哪些场景产品文档里没写、但业务上必须覆盖。

这些经验通常沉淀在历史用例库、缺陷记录、线上问题复盘里。如果 AI 完全接触不到这些信息，它生成的用例注定很"干净"，也注定很浅。

这正是 RAG（检索增强生成）在这个场景里的真正价值——不是让 AI 多引用几段资料装样子，而是让它在动笔之前，先找一找"这个需求像不像过去某个需求"。

举个真实例子。需求只有一句：“商品列表页新增智能推荐入口”。只看这句话，AI 大概率只写：入口展示、点击跳转、无权限提示，三条完事。

但如果历史用例库能召回到相似需求——比如"列表卡片新增权益入口"“列表项新增操作按钮”“列表曝光埋点校验”——AI 就能补充出一批真正有实战价值的测试点：

• 列表为空时入口是否展示；
• 分页加载后入口是否重复渲染；
• 不同数据状态下入口的展示逻辑；
• 曝光/点击埋点是否上报；
• 灰度实验下是否命中正确策略。

这时候 AI 做的事情就更像一个测试工程师了：先找相似经验，再判断哪些可复用、哪些要调整、哪些不能套。

当然，RAG 也不是喂得越多越好。塞一堆无关用例进去，AI 一样会被带偏。比较合理的方式是：按业务模块、页面、接口、关键词、风险类型做定向召回，并要求 AI 说明"为什么参考这些用例"。这样评审时每个补充测试点都有出处——要么来自需求，要么来自历史用例，要么来自缺陷经验——测试负责人可以判断合理性，而不是面对一堆凭空冒出来的用例干瞪眼。

六、我的建议：五步法，不让 AI 一步到位

把上面的思考串起来，是五个环节：

需求解析 → RAG召回 → 测试点设计 → 用例编写 → 用例评审

1. 需求解析：提取业务规则、页面字段、接口约束、限制条件，结构化成中间产物；
2. RAG 召回：基于解析结果，检索相似需求、相似接口、历史缺陷和已有用例；
3. 测试点设计：只确定"测什么"，不急着写步骤，测试点要标注来源（需求/历史/缺陷）；
4. 用例编写：按测试点逐条展开步骤和预期结果，每步必须有依据；
5. 用例评审：检查覆盖率、依据充分性、步骤可执行性、预期可验证性。

这个流程看起来比"一句话生成用例"慢，但返工量少得多。尤其在复杂业务里，中间过程越清晰、上下文越充分，AI 的输出越可控。一步到位最大的问题是：AI 会跳过分析过程，而问题恰恰就藏在漂亮的表格和整齐的编号里。

七、提示词里一定要加的 8 条约束

如果只丢给 AI 一句"根据需求生成测试用例"，结果大概率不可控。下面这 8 条约束，固定在提示词模板里的：

1. 禁止脑补：任何步骤必须能在需求原文或召回的历史材料中找到依据，找不到就标注"待确认"，不许编；
2. 先点后例：先输出测试点列表，经确认后再展开为完整用例；
3. 步骤可执行：每条步骤必须包含明确的操作对象、入口路径和输入数据；
4. 预期可验证：预期结果必须写明具体的判断标准（字段、状态、文案、数值）；
5. 断言分级：区分强断言字段和弱断言字段，动态字段不做固定值断言；
6. 标注来源：每个测试点标注来源类型——需求原文 / 历史用例 / 历史缺陷；
7. 覆盖边界：强制检查空值、极值、并发、权限、异常分支等边界场景；
8. 输出不确定项：主动列出"需求描述模糊、需要找产品确认"的点，而不是默默选一个解释往下写。

这几条规则本身不复杂，但对 AI 很关键。因为大模型的默认目标是"尽快给出一份完整答案"，而测试工作的目标从来不是完整感，是可验证。

八、谈谈测试工程师在AI时代的价值

AI 以后一定会越来越会写测试用例——它会更懂需求、更懂业务、更熟悉各种测试模板。

但我不认为测试工程师的价值会因此消失。恰恰相反，经验会变得更重要，只是承载方式变了：

• 以前，经验体现在"我知道这个地方要测"；
• 现在，经验要沉淀成规则——哪些字段适合强断言、哪些场景容易漏边界、哪些步骤不允许脑补、什么样的预期结果才算可验证、哪些历史用例值得被召回。

如果这些规则只存在测试人员的脑子里，AI 就只能靠猜；只有当它们被写进提示词模板、评审清单、历史用例库和 RAG 检索流程里，AI 才能真正按照团队的测试方法论去工作。

所以与其焦虑"AI 会不会取代测试"，不如先动手做一件事：把自己脑子里的测试经验，变成 AI 能读懂、能执行的规则。这大概就是 AI 时代测试工程师最确定的护城河。

以上是我基于实际平台建设经验的一些思考，难免有局限，欢迎在评论区交流你的做法。