1. 为什么我决定让 AI 来碰测试用例这块硬骨头做开发这些年写测试用例一直是我又爱又恨的环节。爱的是它确实能兜住不少回归问题恨的是纯手工写用例既费时间又容易陷入思维定式——你脑子里默认的那套正常流程往往就是漏掉边界情况的根源。前段时间手上有个不算大的项目一个内部用的数据导入导出模块功能不复杂但涉及字段映射、格式校验、批量处理这些容易出幺蛾子的地方。我当时的想法很简单与其自己一条条抠用例不如让 AI 先给我打一版草稿我再基于草稿去补和验证。这个思路听起来像是偷懒但实际跑下来我发现AI 在测试用例设计这件事上的价值不在于替你想全而在于逼你想全。它会从一些你压根没考虑过的角度切入比如空值、超长字符串、并发写入、编码格式这些。你要做的不是照单全收而是把它当成一个不知疲倦、但缺乏业务上下文的初级测试工程师你负责把关和补充。这篇内容我打算把整个实战过程拆开讲清楚怎么给 AI 喂上下文、怎么让它产出结构化的用例、怎么从用例里反推出隐藏 Bug、以及我在这个过程中踩过的坑和总结出的提示词套路。适合有一定开发或测试基础、想把这套方法用到自己项目里的人参考。全程围绕一个真实的小项目展开不讲空理论。2. 给 AI 喂什么料决定了它吐出来的用例质量2.1 别一上来就让它写测试用例我见过很多人用 AI 写用例的方式就是甩一句帮我给这个登录功能写测试用例然后拿到一堆输入正确用户名密码能登录输入错误密码不能登录这种废话。问题不在 AI在于你没给它足够的约束条件。测试用例的质量高度依赖于你对被测对象的描述精度你描述得越模糊它给的东西就越泛。我的做法是先整理一份被测对象说明书包含几个关键部分功能边界、输入输出定义、业务规则、已知的约束条件。拿我这个数据导入模块举例我会告诉 AI这个模块接收 CSV 文件字段有姓名、手机号、邮箱、注册时间四个手机号要求 11 位数字邮箱要符合常规格式注册时间格式是 YYYY-MM-DD单次导入上限 5000 条重复数据按手机号去重。把这些说清楚之后它产出的用例才有针对性。2.2 上下文要分层给不要一次性倒完我试过一次性把所有信息塞进一个提示词里结果 AI 反而抓不住重点产出的用例结构混乱。后来我改成分层给第一层给功能概述和业务规则让它先理解这个模块是干什么的第二层给具体的字段约束和边界条件第三层才让它开始设计用例。这种递进式的对话方式产出的用例质量明显更稳定。具体操作上我会先发一段功能描述让它用自己的话复述一遍确认理解无误然后再发字段约束最后才下设计测试用例的指令。多花两轮对话的时间但省下来的返工时间远不止这些。2.3 提示词里必须明确的几个要素经过多次调整我总结出一套比较稳的提示词结构包含这几个要素角色设定让它扮演一个有五年经验的测试工程师熟悉边界值分析和等价类划分输出格式明确要求用表格输出包含用例编号、测试场景、前置条件、输入数据、预期结果、优先级覆盖维度要求覆盖正常流程、边界值、异常输入、并发场景、数据一致性五个维度约束条件明确告诉它不要编造不存在的字段不要假设未定义的业务规则提示角色设定这一步很多人会忽略但实测下来它对输出质量的影响非常明显。加上资深测试工程师这个角色后AI 产出的用例在边界值覆盖上会明显更细致。2.4 一个可以直接抄的提示词模板我把当时用的提示词整理了一下你可以直接改成自己项目的版本你现在是一名有五年经验的软件测试工程师擅长边界值分析、等价类划分和场景法设计用例。 被测功能数据导入模块 功能描述接收用户上传的 CSV 文件解析后写入数据库支持去重和格式校验。 字段约束 - 姓名1-50 个字符不允许为空 - 手机号11 位数字不允许为空作为去重依据 - 邮箱符合常规邮箱格式允许为空 - 注册时间格式 YYYY-MM-DD允许为空 请按以下要求设计测试用例 1. 用表格输出列包含用例编号、测试场景、前置条件、输入数据、预期结果、优先级 2. 覆盖正常流程、边界值、异常输入、并发场景、数据一致性五个维度 3. 不要编造未定义的字段或业务规则 4. 优先级用 P0/P1/P2 标注这套模板跑下来AI 给出的用例基本能覆盖七八成的场景剩下的靠人工补充。3. AI 产出的用例里哪些是真金哪些是水分3.1 它擅长的地方边界值和异常输入AI 在边界值这块确实比我手动想得全。比如手机号字段我自己写用例可能就写个11 位正常号码和位数不对但 AI 会给你列出10 位、11 位、12 位、全 0、全 9、含字母、含特殊符号、含空格、前后带空格、中间带空格、Unicode 数字字符等等。这种穷举式的思路人工做起来很枯燥但 AI 几秒钟就给你列完了。异常输入也是它的强项。CSV 文件本身就有很多坑字段数不匹配的行、引号未闭合、换行符在字段内、BOM 头、不同编码格式、空文件、只有表头没有数据行。这些场景 AI 基本都能想到而且会给你标注出预期结果。3.2 它容易翻车的地方业务逻辑和状态依赖AI 最大的短板是缺乏业务上下文。它不知道你们系统里注册时间不能晚于当前时间这种隐含规则也不知道同一个手机号在软删除后重新导入算不算重复这种业务决策。这些用例它要么不写要么写错。我遇到过一个典型情况AI 设计了一条用例说导入重复手机号时应该报错并终止整个导入。但实际业务规则是跳过重复行继续导入其余数据最后给出跳过条数统计。这就是典型的业务逻辑缺失导致的用例错误。所以 AI 产出的用例凡是涉及业务规则的都必须人工过一遍。3.3 怎么快速筛出有价值的用例我的筛选方法是按维度分类处理用例维度AI 产出质量处理方式边界值高直接采用少量补充异常输入高直接采用正常流程中结合业务补充业务规则低全部人工重写并发场景中需结合架构验证数据一致性低人工设计为主按这个分类过一遍效率比逐条看高很多。边界值和异常输入这两块基本可以直接进用例库业务规则和数据一致性这两块必须自己动手。3.4 一个反直觉的发现AI 的错误用例反而有价值有几次 AI 给出的用例预期结果是错的但恰恰是这些错误让我发现了需求文档里没写清楚的地方。比如它假设邮箱为空时应该报错但实际需求是允许为空。这个分歧点提醒我需求文档里对邮箱是否必填确实没有明确说明后来我去找产品确认发现这是个真实的需求遗漏。所以我现在看 AI 用例时会特别关注那些预期结果和我的直觉不一致的条目这些往往指向需求或设计上的模糊地带。4. 从用例到 Bug我是怎么挖出那个隐藏问题的4.1 那个隐藏 Bug 的发现过程项目上线前的回归测试阶段我拿着 AI 产出的用例逐条跑。大部分用例都通过了但有一条关于CSV 文件字段内包含换行符的用例引起了我的注意。AI 设计的预期结果是应正确解析该字段换行符作为字段内容的一部分保留。我跑了一下发现解析确实没报错但导入后的数据里那个字段的内容被截断了换行符后面的内容全丢了。这个问题在正常测试流程里极难发现因为没人会想到往姓名字段里塞换行符。但 CSV 规范里字段内容用双引号包裹时是可以包含换行符的。我们的解析逻辑用的是简单的按行分割没有处理引号内的换行导致数据被截断。4.2 这个 Bug 为什么隐蔽它的隐蔽性来自三个层面第一触发条件特殊需要字段内容包含换行符且用引号包裹第二不报错程序正常执行完毕只是数据悄悄丢了第三影响范围有限只有特定格式的文件才会触发。如果没有 AI 那条用例这个 Bug 大概率会带到生产环境等到某个用户上传了带换行的数据才发现。4.3 顺着这条线索又挖出的问题发现这个 Bug 之后我顺着 CSV 解析这条线又查了几个相关场景结果又发现两个问题一是字段内容包含逗号且未用引号包裹时解析会错位二是文件末尾没有换行符时最后一行数据会被丢弃。这两个问题都是同一类根因——解析逻辑过于简单没有严格遵循 CSV 规范。这三个 Bug 后来我统一用一套更健壮的解析逻辑修复了核心改动是引入了一个状态机来逐字符解析而不是按行分割。修复后重新跑了一遍 AI 产出的全部用例包括那些之前没触发的边界用例确认都通过了。4.4 从这次经历总结的排查思路这次挖 Bug 的经历让我形成了一个习惯拿到 AI 产出的用例后重点跑那些看起来不太可能发生的场景。正常流程的用例大家都会测真正有价值的是那些极端场景。具体来说我会优先跑这几类字段内容包含特殊字符换行、逗号、引号、制表符文件格式边界空文件、只有表头、超大数据量、末尾无换行编码相关BOM 头、GBK 编码、UTF-8 带 BOM并发写入同一批数据这几类场景是 Bug 的高发区也是 AI 用例最能发挥价值的地方。5. 让 AI 持续产出高质量用例的几个实操技巧5.1 用多轮对话代替一次性生成一次性让 AI 生成所有用例质量往往不如分多轮。我的做法是第一轮让它生成正常流程和边界值用例第二轮专门生成异常输入用例第三轮生成并发和数据一致性用例。每轮之间我会把上一轮的结果反馈给它让它避免重复同时基于已有用例做补充。这种迭代方式的好处是每轮的上下文更聚焦AI 不会因为信息过载而产出泛泛的用例。实测下来分三轮生成的用例总数比一次性生成多出约 40%而且覆盖维度更均衡。5.2 让它自己评审自己的用例生成完用例后我会追加一轮指令请以测试评审的角度检查上述用例是否存在遗漏、重复或预期结果不合理的地方并给出补充建议。这一轮经常能补出一些之前漏掉的场景比如它自己会发现没有覆盖文件大小超过限制的情况。这个自我评审的机制本质上是用 AI 的另一个视角来查漏补缺。虽然它评审出来的问题不全是有效的但筛一遍之后总能有收获。5.3 把用例转成可执行的测试脚本用例设计完之后我还会让 AI 把表格里的用例转成 pytest 或 Playwright 的测试脚本。这一步能进一步验证用例的可执行性——如果某条用例 AI 写不出对应的脚本往往说明这条用例的描述本身就不够清晰。比如那条发现 Bug 的换行符用例转成脚本时 AI 写了一个构造带换行 CSV 内容的 fixture这个 fixture 后来直接被我复用到回归测试里了。用例和脚本之间的这种转换其实是对用例质量的一次二次校验。5.4 建立用例库让 AI 基于历史用例生成新用例项目做多了之后我建了一个用例库把每次 AI 产出的高质量用例存下来。下次做类似功能时我会把历史用例作为参考喂给 AI让它基于已有模式生成新用例。这样产出的用例风格更统一覆盖维度也更稳定。这个做法特别适合同一类功能反复出现的场景比如各种表单提交、文件上传、数据导出。有了历史用例做锚点AI 的产出质量会明显上一个台阶。6. 这套方法用下来我的几点真实体会6.1 AI 是放大器不是替代品用了这段时间我最大的感受是AI 在测试用例设计上的角色是放大器它放大的是你原本的测试思维。你如果本身对边界值、等价类这些方法有理解它能帮你把这些方法执行得更彻底你如果本身测试思维就薄弱它产出的东西你也判断不了好坏。所以别指望它能替代测试设计能力它替代的是那些重复性的、穷举性的体力活。真正的判断、业务理解、风险识别还是得靠人。6.2 提示词的投入产出比极高我在这套方法上花时间最多的部分就是调提示词。一开始产出的用例质量很一般后来逐步加上角色设定、输出格式约束、覆盖维度要求、禁止编造规则这些约束质量提升非常明显。花半小时调提示词能省下几个小时的用例编写和返工时间这个投入产出比相当划算。6.3 隐藏 Bug 的发现是意外之喜但也在情理之中那个换行符 Bug 的发现表面上看是运气但仔细想想也在情理之中。AI 的穷举式思维天然会覆盖到那些人类容易忽略的极端场景而 Bug 恰恰就藏在这些场景里。你让 AI 把边界铺得足够宽踩中 Bug 的概率自然就上去了。6.4 后续可以继续深挖的方向这套方法目前我用在功能测试用例设计上比较多后面我打算往两个方向扩展一是让它基于接口文档自动生成接口测试用例二是结合代码覆盖率报告让它针对未覆盖的分支补充用例。这两个方向都需要把 AI 和现有的测试工具链打通工作量不小但价值应该挺大。另外一个小技巧如果你用的是支持插件的 IDE可以找一些能直接调用大模型的插件把用例生成这一步嵌到开发流程里写完功能顺手就生成一版用例草稿比事后专门抽时间做效率高很多。 
长河君 · 2026/10/26 17:25:32 · 阅读 1.2k AI辅助测试用例设计实战：从提示词到隐藏Bug挖掘
1. 为什么我决定让 AI 来碰测试用例这块硬骨头做开发这些年写测试用例一直是我又爱又恨的环节。爱的是它确实能兜住不少回归问题恨的是纯手工写用例既费时间又容易陷入思维定式——你脑子里默认的那套正常流程往往就是漏掉边界情况的根源。前段时间手上有个不算大的项目一个内部用的数据导入导出模块功能不复杂但涉及字段映射、格式校验、批量处理这些容易出幺蛾子的地方。我当时的想法很简单与其自己一条条抠用例不如让 AI 先给我打一版草稿我再基于草稿去补和验证。这个思路听起来像是偷懒但实际跑下来我发现AI 在测试用例设计这件事上的价值不在于替你想全而在于逼你想全。它会从一些你压根没考虑过的角度切入比如空值、超长字符串、并发写入、编码格式这些。你要做的不是照单全收而是把它当成一个不知疲倦、但缺乏业务上下文的初级测试工程师你负责把关和补充。这篇内容我打算把整个实战过程拆开讲清楚怎么给 AI 喂上下文、怎么让它产出结构化的用例、怎么从用例里反推出隐藏 Bug、以及我在这个过程中踩过的坑和总结出的提示词套路。适合有一定开发或测试基础、想把这套方法用到自己项目里的人参考。全程围绕一个真实的小项目展开不讲空理论。2. 给 AI 喂什么料决定了它吐出来的用例质量2.1 别一上来就让它写测试用例我见过很多人用 AI 写用例的方式就是甩一句帮我给这个登录功能写测试用例然后拿到一堆输入正确用户名密码能登录输入错误密码不能登录这种废话。问题不在 AI在于你没给它足够的约束条件。测试用例的质量高度依赖于你对被测对象的描述精度你描述得越模糊它给的东西就越泛。我的做法是先整理一份被测对象说明书包含几个关键部分功能边界、输入输出定义、业务规则、已知的约束条件。拿我这个数据导入模块举例我会告诉 AI这个模块接收 CSV 文件字段有姓名、手机号、邮箱、注册时间四个手机号要求 11 位数字邮箱要符合常规格式注册时间格式是 YYYY-MM-DD单次导入上限 5000 条重复数据按手机号去重。把这些说清楚之后它产出的用例才有针对性。2.2 上下文要分层给不要一次性倒完我试过一次性把所有信息塞进一个提示词里结果 AI 反而抓不住重点产出的用例结构混乱。后来我改成分层给第一层给功能概述和业务规则让它先理解这个模块是干什么的第二层给具体的字段约束和边界条件第三层才让它开始设计用例。这种递进式的对话方式产出的用例质量明显更稳定。具体操作上我会先发一段功能描述让它用自己的话复述一遍确认理解无误然后再发字段约束最后才下设计测试用例的指令。多花两轮对话的时间但省下来的返工时间远不止这些。2.3 提示词里必须明确的几个要素经过多次调整我总结出一套比较稳的提示词结构包含这几个要素角色设定让它扮演一个有五年经验的测试工程师熟悉边界值分析和等价类划分输出格式明确要求用表格输出包含用例编号、测试场景、前置条件、输入数据、预期结果、优先级覆盖维度要求覆盖正常流程、边界值、异常输入、并发场景、数据一致性五个维度约束条件明确告诉它不要编造不存在的字段不要假设未定义的业务规则提示角色设定这一步很多人会忽略但实测下来它对输出质量的影响非常明显。加上资深测试工程师这个角色后AI 产出的用例在边界值覆盖上会明显更细致。2.4 一个可以直接抄的提示词模板我把当时用的提示词整理了一下你可以直接改成自己项目的版本你现在是一名有五年经验的软件测试工程师擅长边界值分析、等价类划分和场景法设计用例。 被测功能数据导入模块 功能描述接收用户上传的 CSV 文件解析后写入数据库支持去重和格式校验。 字段约束 - 姓名1-50 个字符不允许为空 - 手机号11 位数字不允许为空作为去重依据 - 邮箱符合常规邮箱格式允许为空 - 注册时间格式 YYYY-MM-DD允许为空 请按以下要求设计测试用例 1. 用表格输出列包含用例编号、测试场景、前置条件、输入数据、预期结果、优先级 2. 覆盖正常流程、边界值、异常输入、并发场景、数据一致性五个维度 3. 不要编造未定义的字段或业务规则 4. 优先级用 P0/P1/P2 标注这套模板跑下来AI 给出的用例基本能覆盖七八成的场景剩下的靠人工补充。3. AI 产出的用例里哪些是真金哪些是水分3.1 它擅长的地方边界值和异常输入AI 在边界值这块确实比我手动想得全。比如手机号字段我自己写用例可能就写个11 位正常号码和位数不对但 AI 会给你列出10 位、11 位、12 位、全 0、全 9、含字母、含特殊符号、含空格、前后带空格、中间带空格、Unicode 数字字符等等。这种穷举式的思路人工做起来很枯燥但 AI 几秒钟就给你列完了。异常输入也是它的强项。CSV 文件本身就有很多坑字段数不匹配的行、引号未闭合、换行符在字段内、BOM 头、不同编码格式、空文件、只有表头没有数据行。这些场景 AI 基本都能想到而且会给你标注出预期结果。3.2 它容易翻车的地方业务逻辑和状态依赖AI 最大的短板是缺乏业务上下文。它不知道你们系统里注册时间不能晚于当前时间这种隐含规则也不知道同一个手机号在软删除后重新导入算不算重复这种业务决策。这些用例它要么不写要么写错。我遇到过一个典型情况AI 设计了一条用例说导入重复手机号时应该报错并终止整个导入。但实际业务规则是跳过重复行继续导入其余数据最后给出跳过条数统计。这就是典型的业务逻辑缺失导致的用例错误。所以 AI 产出的用例凡是涉及业务规则的都必须人工过一遍。3.3 怎么快速筛出有价值的用例我的筛选方法是按维度分类处理用例维度AI 产出质量处理方式边界值高直接采用少量补充异常输入高直接采用正常流程中结合业务补充业务规则低全部人工重写并发场景中需结合架构验证数据一致性低人工设计为主按这个分类过一遍效率比逐条看高很多。边界值和异常输入这两块基本可以直接进用例库业务规则和数据一致性这两块必须自己动手。3.4 一个反直觉的发现AI 的错误用例反而有价值有几次 AI 给出的用例预期结果是错的但恰恰是这些错误让我发现了需求文档里没写清楚的地方。比如它假设邮箱为空时应该报错但实际需求是允许为空。这个分歧点提醒我需求文档里对邮箱是否必填确实没有明确说明后来我去找产品确认发现这是个真实的需求遗漏。所以我现在看 AI 用例时会特别关注那些预期结果和我的直觉不一致的条目这些往往指向需求或设计上的模糊地带。4. 从用例到 Bug我是怎么挖出那个隐藏问题的4.1 那个隐藏 Bug 的发现过程项目上线前的回归测试阶段我拿着 AI 产出的用例逐条跑。大部分用例都通过了但有一条关于CSV 文件字段内包含换行符的用例引起了我的注意。AI 设计的预期结果是应正确解析该字段换行符作为字段内容的一部分保留。我跑了一下发现解析确实没报错但导入后的数据里那个字段的内容被截断了换行符后面的内容全丢了。这个问题在正常测试流程里极难发现因为没人会想到往姓名字段里塞换行符。但 CSV 规范里字段内容用双引号包裹时是可以包含换行符的。我们的解析逻辑用的是简单的按行分割没有处理引号内的换行导致数据被截断。4.2 这个 Bug 为什么隐蔽它的隐蔽性来自三个层面第一触发条件特殊需要字段内容包含换行符且用引号包裹第二不报错程序正常执行完毕只是数据悄悄丢了第三影响范围有限只有特定格式的文件才会触发。如果没有 AI 那条用例这个 Bug 大概率会带到生产环境等到某个用户上传了带换行的数据才发现。4.3 顺着这条线索又挖出的问题发现这个 Bug 之后我顺着 CSV 解析这条线又查了几个相关场景结果又发现两个问题一是字段内容包含逗号且未用引号包裹时解析会错位二是文件末尾没有换行符时最后一行数据会被丢弃。这两个问题都是同一类根因——解析逻辑过于简单没有严格遵循 CSV 规范。这三个 Bug 后来我统一用一套更健壮的解析逻辑修复了核心改动是引入了一个状态机来逐字符解析而不是按行分割。修复后重新跑了一遍 AI 产出的全部用例包括那些之前没触发的边界用例确认都通过了。4.4 从这次经历总结的排查思路这次挖 Bug 的经历让我形成了一个习惯拿到 AI 产出的用例后重点跑那些看起来不太可能发生的场景。正常流程的用例大家都会测真正有价值的是那些极端场景。具体来说我会优先跑这几类字段内容包含特殊字符换行、逗号、引号、制表符文件格式边界空文件、只有表头、超大数据量、末尾无换行编码相关BOM 头、GBK 编码、UTF-8 带 BOM并发写入同一批数据这几类场景是 Bug 的高发区也是 AI 用例最能发挥价值的地方。5. 让 AI 持续产出高质量用例的几个实操技巧5.1 用多轮对话代替一次性生成一次性让 AI 生成所有用例质量往往不如分多轮。我的做法是第一轮让它生成正常流程和边界值用例第二轮专门生成异常输入用例第三轮生成并发和数据一致性用例。每轮之间我会把上一轮的结果反馈给它让它避免重复同时基于已有用例做补充。这种迭代方式的好处是每轮的上下文更聚焦AI 不会因为信息过载而产出泛泛的用例。实测下来分三轮生成的用例总数比一次性生成多出约 40%而且覆盖维度更均衡。5.2 让它自己评审自己的用例生成完用例后我会追加一轮指令请以测试评审的角度检查上述用例是否存在遗漏、重复或预期结果不合理的地方并给出补充建议。这一轮经常能补出一些之前漏掉的场景比如它自己会发现没有覆盖文件大小超过限制的情况。这个自我评审的机制本质上是用 AI 的另一个视角来查漏补缺。虽然它评审出来的问题不全是有效的但筛一遍之后总能有收获。5.3 把用例转成可执行的测试脚本用例设计完之后我还会让 AI 把表格里的用例转成 pytest 或 Playwright 的测试脚本。这一步能进一步验证用例的可执行性——如果某条用例 AI 写不出对应的脚本往往说明这条用例的描述本身就不够清晰。比如那条发现 Bug 的换行符用例转成脚本时 AI 写了一个构造带换行 CSV 内容的 fixture这个 fixture 后来直接被我复用到回归测试里了。用例和脚本之间的这种转换其实是对用例质量的一次二次校验。5.4 建立用例库让 AI 基于历史用例生成新用例项目做多了之后我建了一个用例库把每次 AI 产出的高质量用例存下来。下次做类似功能时我会把历史用例作为参考喂给 AI让它基于已有模式生成新用例。这样产出的用例风格更统一覆盖维度也更稳定。这个做法特别适合同一类功能反复出现的场景比如各种表单提交、文件上传、数据导出。有了历史用例做锚点AI 的产出质量会明显上一个台阶。6. 这套方法用下来我的几点真实体会6.1 AI 是放大器不是替代品用了这段时间我最大的感受是AI 在测试用例设计上的角色是放大器它放大的是你原本的测试思维。你如果本身对边界值、等价类这些方法有理解它能帮你把这些方法执行得更彻底你如果本身测试思维就薄弱它产出的东西你也判断不了好坏。所以别指望它能替代测试设计能力它替代的是那些重复性的、穷举性的体力活。真正的判断、业务理解、风险识别还是得靠人。6.2 提示词的投入产出比极高我在这套方法上花时间最多的部分就是调提示词。一开始产出的用例质量很一般后来逐步加上角色设定、输出格式约束、覆盖维度要求、禁止编造规则这些约束质量提升非常明显。花半小时调提示词能省下几个小时的用例编写和返工时间这个投入产出比相当划算。6.3 隐藏 Bug 的发现是意外之喜但也在情理之中那个换行符 Bug 的发现表面上看是运气但仔细想想也在情理之中。AI 的穷举式思维天然会覆盖到那些人类容易忽略的极端场景而 Bug 恰恰就藏在这些场景里。你让 AI 把边界铺得足够宽踩中 Bug 的概率自然就上去了。6.4 后续可以继续深挖的方向这套方法目前我用在功能测试用例设计上比较多后面我打算往两个方向扩展一是让它基于接口文档自动生成接口测试用例二是结合代码覆盖率报告让它针对未覆盖的分支补充用例。这两个方向都需要把 AI 和现有的测试工具链打通工作量不小但价值应该挺大。另外一个小技巧如果你用的是支持插件的 IDE可以找一些能直接调用大模型的插件把用例生成这一步嵌到开发流程里写完功能顺手就生成一版用例草稿比事后专门抽时间做效率高很多。