关于AI书写测试用例谈一下我的思考一、先泼一盆冷水AI 写出来的用例很多是废品二、坑点一盯着测试点标题开始脑补测试范围三、坑点二步骤写得很完整但执行不了四、坑点三预期结果写得对但没法判断通过失败五、只读需求是不够的让 AI 先读历史再写用例六、我的建议五步法不让 AI 一步到位七、提示词里一定要加的 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 时代测试工程师最确定的护城河。以上是我基于实际平台建设经验的一些思考难免有局限欢迎在评论区交流你的做法。
关于AI书写测试用例，谈一下我的思考
关于AI书写测试用例谈一下我的思考一、先泼一盆冷水AI 写出来的用例很多是废品二、坑点一盯着测试点标题开始脑补测试范围三、坑点二步骤写得很完整但执行不了四、坑点三预期结果写得对但没法判断通过失败五、只读需求是不够的让 AI 先读历史再写用例六、我的建议五步法不让 AI 一步到位七、提示词里一定要加的 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 时代测试工程师最确定的护城河。以上是我基于实际平台建设经验的一些思考难免有局限欢迎在评论区交流你的做法。
