关于AI书写测试用例，谈一下我的思考
-
- [一、先泼一盆冷水：AI 写出来的用例，很多是"废品"](#一、先泼一盆冷水：AI 写出来的用例，很多是"废品")
- 二、坑点一：盯着测试点标题，开始"脑补"测试范围
- 三、坑点二：步骤写得很完整，但执行不了
- 四、坑点三：预期结果"写得对"，但没法判断通过失败
- [五、只读需求是不够的：让 AI 先读历史，再写用例](#五、只读需求是不够的：让 AI 先读历史，再写用例)
- [六、我的建议：五步法，不让 AI 一步到位](#六、我的建议：五步法，不让 AI 一步到位)
- [七、提示词里一定要加的 8 条约束](#七、提示词里一定要加的 8 条约束)
- 八、谈谈测试工程师在AI时代的价值
最近这一年多，我在工作中深度参与了几个 AI 测试平台的建设, 踩过的坑不少，也沉淀了一些方法论。这篇文章想聊聊：AI 写测试用例到底靠不靠谱？它最容易在哪些地方"翻车"？以及我们该怎么设计流程，才能让它真正提效而不是帮倒忙。
一、先泼一盆冷水：AI 写出来的用例，很多是"废品"
现在让大模型根据需求文档生成测试用例，已经不是什么新鲜事了。随便找个 AI，把需求贴进去，说一句"帮我生成测试用例"，几分钟后你就能拿到几十条用例------标题规范、步骤齐全、预期结果写得有模有样。
看起来很美好，但真正拿去评审和执行，问题马上就暴露了：
- 有些用例看起来很专业，实际上根本执行不了；
- 有些步骤写得行云流水，但需求里压根没有这个依据；
- 有些预期结果读着没问题，但谁也说不清到底怎么算通过。
更麻烦的是，AI 只盯着当前这份需求，它不知道这个模块历史上踩过什么坑、哪些字段经常出线上问题、团队以前是怎么覆盖类似场景的。所以它写出来的往往是"需求说明书级别"的用例------很干净，但也很浅。
我个人的结论是：AI 写测试用例最大的风险，不是写得慢、写得少，而是它会批量产出"看起来像测试用例、实际上无法落地"的内容。 一旦这种内容混进用例库，提效工具就变成了返工素材。
AI写测试用例，我总结出了有以下几大坑。
二、坑点一：盯着测试点标题，开始"脑补"测试范围
这是 AI 犯的第一个、也是最隐蔽的错误。
举个例子，需求里只有一句话：
招聘者资料页支持修改联系电话。
AI 拿到这个测试点，很可能立刻给你扩写出一套"完整流程"：
- 进入个人中心
- 点击账号安全
- 输入新手机号
- 获取并输入短信验证码
- 点击保存，验证修改成功
读起来特别顺，特别像一个真实产品。但问题是------需求里根本没有"个人中心"，没有"账号安全"，也没有"短信验证码"。这些全是 AI 基于它见过的无数 App 脑补出来的。
这个坑最毒的地方在于：它不是一眼假。 写得越像真实系统，评审时越容易被一眼带过。等到执行阶段才发现：页面没这个入口、字段名对不上、流程和需求完全是两套东西。
所以我的做法是，坚决不让 AI 一步到位地"根据需求生成完整用例"，而是拆成两步：
- 先让 AI 输出测试点列表（只回答"要测什么"）；
- 再让它基于测试点逐条展开步骤，并且强制要求每个步骤都标注需求原文依据。
背后是一个很重要的原则：测试用例不是文学创作，不允许靠"合理想象"补全系统行为。
三、坑点二：步骤写得很完整，但执行不了
第二个高频问题：步骤太"虚"。
AI 特别喜欢写这种看起来正确、但没有操作细节的句子：
- "验证用户可以正常提交表单"
- "检查数据是否展示正确"
- "确认流程可以正常完成"
这些话放在测试方案里没问题，但放在用例步骤里就是废话。一条合格的测试步骤，执行人拿到之后应该明确知道：去哪个页面、点哪个按钮、填什么数据、触发什么动作。
我给自己团队定过一个很简单的判断标准：
如果一条步骤里只有"验证、检查、确认"这类动词，却没有明确的操作对象和输入数据，那它大概率不可执行，打回重写。
接口测试用例更容易被写虚。AI 经常给你来一句"调用接口，验证返回正确"------请求参数是什么？必填字段边界在哪？返回体里哪些字段是核心业务字段、哪些可以忽略？全都没说。
测试用例的价值不在于句子漂亮，而在于让执行人少猜一点、让自动化脚本能多承接一点。 这也是我们后来在做智能接口测试平台时，坚持把接口文档（入参约束、枚举值、依赖关系）作为结构化上下文喂给模型的原因------不给它这些，它只能写"正确的废话"。
四、坑点三：预期结果"写得对"，但没法判断通过失败
第三个问题更致命：预期结果不可验证。
AI 生成的预期结果，高频出现这些词：
- "系统正常返回"
- "页面展示正确"
- "数据符合预期"
- "流程处理成功"
读着没毛病，执行的时候测试同学还是得问：什么叫正确？什么叫成功？我看哪个字段？看哪个状态码？看哪条文案？
一个无法判断通过/失败的预期结果，就不是预期结果。
这一点在接口自动化里尤其关键。接口返回的 JSON 往往很长，里面有稳定字段，也有动态字段。AI 如果不区分字段类型，很容易给出错误的断言策略。我们实践中总结的规则是：
| 字段类型 | 举例 | 断言策略 |
|---|---|---|
| 业务状态字段 | code、message、核心业务状态 |
强断言（精确匹配） |
| 结构/存在性字段 | list 长度、字段存在、非空 |
弱断言（存在性/类型校验） |
| 动态字段 | 时间戳、动态 token、推荐排序 | 一般不直接断言固定值 |
这也是为什么我认为，AI 生成用例之后必须再加一道断言分析/用例评审环节------不是为了把流程搞复杂，而是为了把"看起来正确"变成"真的可判断"。
五、只读需求是不够的：让 AI 先读历史，再写用例
很多人做 AI 用例生成时，默认输入只有一个：需求文档。这个思路没错，但远远不够。
想想一个资深测试工程师写用例时，脑子里装的是什么？不只有当前需求，还有大量隐性上下文：
- 以前类似的需求是怎么测的；
- 哪些地方出过线上 bug；
- 哪些字段是核心字段、哪些边界容易漏；
- 哪些场景产品文档里没写、但业务上必须覆盖。
这些经验通常沉淀在历史用例库、缺陷记录、线上问题复盘里。如果 AI 完全接触不到这些信息，它生成的用例注定很"干净"，也注定很浅。
这正是 RAG（检索增强生成）在这个场景里的真正价值------不是让 AI 多引用几段资料装样子，而是让它在动笔之前，先找一找"这个需求像不像过去某个需求"。
举个真实例子。需求只有一句："商品列表页新增智能推荐入口"。只看这句话，AI 大概率只写：入口展示、点击跳转、无权限提示，三条完事。
但如果历史用例库能召回到相似需求------比如"列表卡片新增权益入口""列表项新增操作按钮""列表曝光埋点校验"------AI 就能补充出一批真正有实战价值的测试点：
- 列表为空时入口是否展示；
- 分页加载后入口是否重复渲染；
- 不同数据状态下入口的展示逻辑；
- 曝光/点击埋点是否上报；
- 灰度实验下是否命中正确策略。
这时候 AI 做的事情就更像一个测试工程师了：先找相似经验，再判断哪些可复用、哪些要调整、哪些不能套。
当然，RAG 也不是喂得越多越好。塞一堆无关用例进去，AI 一样会被带偏。比较合理的方式是：按业务模块、页面、接口、关键词、风险类型做定向召回，并要求 AI 说明"为什么参考这些用例"。 这样评审时每个补充测试点都有出处------要么来自需求，要么来自历史用例，要么来自缺陷经验------测试负责人可以判断合理性，而不是面对一堆凭空冒出来的用例干瞪眼。
六、我的建议：五步法，不让 AI 一步到位
把上面的思考串起来，是五个环节：
需求解析 → RAG召回 → 测试点设计 → 用例编写 → 用例评审- 需求解析：提取业务规则、页面字段、接口约束、限制条件，结构化成中间产物；
- RAG 召回：基于解析结果，检索相似需求、相似接口、历史缺陷和已有用例；
- 测试点设计：只确定"测什么"，不急着写步骤，测试点要标注来源（需求/历史/缺陷）；
- 用例编写：按测试点逐条展开步骤和预期结果，每步必须有依据；
- 用例评审：检查覆盖率、依据充分性、步骤可执行性、预期可验证性。
这个流程看起来比"一句话生成用例"慢，但返工量少得多。尤其在复杂业务里，中间过程越清晰、上下文越充分，AI 的输出越可控。 一步到位最大的问题是：AI 会跳过分析过程，而问题恰恰就藏在漂亮的表格和整齐的编号里。
七、提示词里一定要加的 8 条约束
如果只丢给 AI 一句"根据需求生成测试用例"，结果大概率不可控。下面这 8 条约束，固定在提示词模板里的：
- 禁止脑补：任何步骤必须能在需求原文或召回的历史材料中找到依据，找不到就标注"待确认"，不许编；
- 先点后例：先输出测试点列表，经确认后再展开为完整用例；
- 步骤可执行：每条步骤必须包含明确的操作对象、入口路径和输入数据；
- 预期可验证：预期结果必须写明具体的判断标准（字段、状态、文案、数值）；
- 断言分级：区分强断言字段和弱断言字段，动态字段不做固定值断言；
- 标注来源：每个测试点标注来源类型------需求原文 / 历史用例 / 历史缺陷；
- 覆盖边界：强制检查空值、极值、并发、权限、异常分支等边界场景；
- 输出不确定项：主动列出"需求描述模糊、需要找产品确认"的点，而不是默默选一个解释往下写。
这几条规则本身不复杂，但对 AI 很关键。因为大模型的默认目标是"尽快给出一份完整答案"，而测试工作的目标从来不是完整感，是可验证。
八、谈谈测试工程师在AI时代的价值
AI 以后一定会越来越会写测试用例------它会更懂需求、更懂业务、更熟悉各种测试模板。
但我不认为测试工程师的价值会因此消失。恰恰相反，经验会变得更重要，只是承载方式变了：
- 以前，经验体现在"我知道这个地方要测"；
- 现在，经验要沉淀成规则------哪些字段适合强断言、哪些场景容易漏边界、哪些步骤不允许脑补、什么样的预期结果才算可验证、哪些历史用例值得被召回。
如果这些规则只存在测试人员的脑子里，AI 就只能靠猜；只有当它们被写进提示词模板、评审清单、历史用例库和 RAG 检索流程里，AI 才能真正按照团队的测试方法论去工作。
所以与其焦虑"AI 会不会取代测试"，不如先动手做一件事：把自己脑子里的测试经验，变成 AI 能读懂、能执行的规则。 这大概就是 AI 时代测试工程师最确定的护城河。
以上是我基于实际平台建设经验的一些思考，难免有局限，欢迎在评论区交流你的做法。