在测试团队里泡了这么多年，我一直有个执念：能不能让模型替我把几百条历史用例自动过一遍，挑出真正有价值的，顺便把缺失的异常场景补上。直到我试了Gpt 5 mini，这个想法才真正落地。Gpt 5 mini自动识别用例，不是一个炫技Demo，而是一套可以塞进日常迭代流程的实操方案：从需求文档、旧用例、缺陷记录里自动抽取用例要素、打标签、判优先级、补异常分支。这篇文章我会把整套方法、踩过的坑、调优数据全部摊开讲，适合正在做测试用例治理、想引入LLM但不知道从哪下手的QA和测试开发同学。
1. 被手工用例逼疯之后，我盯上了Gpt 5 mini
1.1 手工维护用例的三大痛点
先说痛点，不然你不会理解我为什么折腾这个东西。
第一个痛点是历史用例库基本是个“数据坟墓”。我们团队维护过一个跑了三年的核心交易系统，用例数量超过8000条。表面上看覆盖度很高，但真正去翻的时候发现：同一个支付超时场景，在六个模块里被写了十几遍，表述还都不一样；真正能对应到当前版本的用例可能只有一半；异常场景用例零零散散，有的模块覆盖率还行，有的模块基本为零。
第二个痛点是异常场景用例全靠个人经验“拍脑袋”。大家写用例的时候，第一反应永远是走通主流程，输入正确数据、点击正常按钮、得到预期结果。至于网络断开、重复提交、数据被并发修改、权限中途被收回这些事，很少有人会主动写。我统计过我们之前几个项目的用例库，异常场景用例占比普遍在25%到30%之间晃悠，而线上故障里真正因为主流程出问题的，占比其实很低，绝大多数都是边界条件和异常分支没覆盖到。
第三个痛点是评审会上说不清楚“这条用例到底要不要留”。每个人对用例价值的判断标准不一样，有人说要留全，有人说要精简，争了半天最后还是按资历拍板。我们需要一个相对客观的尺度。
1.2 为什么是Gpt 5 mini，而不是GPT-4o或者开源模型
选型这件事我纠结了差不多一周。先试了GPT-4o，确实聪明，识别质量和上下文理解都好，但成本摆在那里。我们每天要处理的用例素材大概有几千条，一条按几百个token算，一天就是一两百万token，用GPT-4o跑一天的费用，预算报表根本没法看。
又试了本地部署的Qwen和Llama系列，识别效果不是不行，而是对指令的遵循能力不够稳定。尤其在我让它输出严格JSON格式的时候，十次里面有两三次会擅自加字段或者改变嵌套结构，解析程序经常被搞挂。Gpt 5 mini在这方面的表现让我比较意外，它输出的JSON基本能一次解析通过，指令遵循的稳定性明显好于同级别的开源模型。
从成本和效果两个维度简单对比一下：
| 对比项 | Gpt 5 mini | GPT-4o | 本地开源小模型 |
|---|---|---|---|
| 单次调用成本 | 低 | 高 | 中（硬件成本） |
| 指令遵循稳定性 | 强 | 很强 | 中 |
| 复杂规则理解 | 中上 | 强 | 中 |
| 批处理吞吐 | 高 | 中 | 取决于算力 |
| 敏感数据出域 | 有 | 有 | 无 |
如果你的用例素材涉及特别严格的合规要求，不能出内网，那本地开源模型是唯一选择，这是硬约束。如果只是常规的业务系统，Gpt 5 mini在成本和效果之间是最平衡的选项。
1.3 “自动识别用例”到底自动化在哪一步
很多人一听“自动识别用例”，第一反应是让AI直接生成几百条用例。这个理解有偏差。我实际做的是从已有的素材里“识别”出用例要素，而不是凭空“编造”用例。整个流程拆成四个子任务：
- 抽取：从需求文档、接口说明、缺陷单、旧用例里抽取出前置条件、操作步骤、预期结果。
- 归一：把同一场景的不同表述合并成一条标准用例。
- 分类：给用例打上模块、优先级、场景类型（正常/异常）等标签。
- 补全：识别出明显缺失的异常分支，生成补充用例建议。
Gpt 5 mini在这四个子任务上的表现各有差异。抽取和分类做得最好，归一需要配合后处理，补全的准确率相对最低，需要人工重点复核。这个认知很重要——不要指望模型一步到位，而是把任务拆清楚，让它在能力最强的环节发挥作用。
2. Gpt 5 mini能识别什么、不能识别什么：能力边界实测
2.1 它真正擅长的三类识别任务
我用实际项目素材做了几十轮测试，总结出Gpt 5 mini在用例识别上真正靠谱的三类任务。
第一类是要素抽取。给它一段需求描述，比如“用户点击支付后，系统校验余额，余额不足则提示充值”，它能比较准确地抽取出前置条件（用户已登录、订单已生成）、操作步骤（点击支付、触发余额校验）、预期结果（余额充足时支付成功，不足时提示充值）。这个能力非常稳定，抽出来的字段基本可以直接入库。
第二类是意图分类与打标。给一堆从各个渠道收集来的文本片段，让它判断这段文本描述的是正常流程、边界条件、异常处理还是无关信息。实测分类准确率在85%左右。这个准确率已经足够作为初筛工具，把明显属于“正常流程”的用例和“异常场景”的用例分开。
第三类是相似度判断。给它两条用例，让它判断是不是在描述同一个场景。这个能力比我自己写的基于关键词的相似度算法靠谱得多。我之前用Jaccard相似度和编辑距离去重，同一个“支付超时”场景，因为描述词不同就被当成两条不同用例；Gpt 5 mini能理解语义层面的等价，识别准确率明显提升。
2.2 识别不准的重灾区
再说不准的部分，这部分更重要，能让你少交学费。
第一个重灾区是上下文超长的场景。Gpt 5 mini的上下文窗口虽然不小，但当你把一份几十页的需求文档整个塞进去，让它“找出所有异常场景”的时候，它会表现出两个问题：一是前面的内容记得清楚，中间和后段的内容容易被“遗忘”；二是它会倾向于只挑最明显的异常分支，那些藏在段落中间、需要推理才能发现的边界条件，很容易漏。
第二个重灾区是隐含业务规则。比如一个规则：“用户已经绑定了亲情卡的情况下，支付时优先从亲情卡扣款，亲情卡余额不足时再从主卡扣款”，这种规则型内容模型很难“识别”成一条测试用例，它需要你先明确告诉它这条规则的存在，它才能围绕规则拆出用例。也就是说，模型擅长从显性文本里抽取，不擅长从隐性规则里推导。
第三个重灾区是模糊表述。“系统在极端情况下性能下降”这种描述，Gpt 5 mini无法判断“极端情况”到底是什么。它识别出来也可能是“高并发下系统响应变慢”，但具体要到多大的并发量、多慢算异常，它给不了。它只能识别“这里好像有个异常点”，具体的量化边界必须靠人补。
2.3 上下文窗口的应对策略
针对上面说的长文本问题，我试过几种方案，最后稳定用的是“分块+聚焦”策略。
不把整个需求文档一次性塞进去。先把文档按功能模块切成段落，每个段落单独跑一次识别，跑完把结果汇总。这样能保证每一段内容都被模型完整“看到”，而不是被长上下文稀释掉。切分的时候要注意按语义边界切，不要在一句话中间切断。
另外一个有效动作是聚焦指令。不要问“这段文档里有哪些用例”，而是问“这段文档里描述了哪些可能被用户误操作或者外部环境干扰的场景”。加了这个明确指令后，模型输出的异常场景数量明显变多。这说明Gpt 5 mini不是识别不了异常，而是默认情况下它的“注意力”会优先放在主流程上。
3. 一套能直接抄走的Prompt模板与输出协议
3.1 输入侧：先把语料整理成它认识的样子
Gpt 5 mini对输入格式的敏感度比我们想象中高。同样一段内容，你用纯文本丢给它，和用结构化字段丢给它，识别效果能差出两到三成。
我最后定下来的输入格式是分字段传入：
requirement: 原始需求描述existing_cases: 已有的用例文本，可能有多条，用编号区分defect_records: 相关缺陷记录focus: 本次识别的关注点，比如“请重点关注支付流程的边界条件”output_format: 明确指定输出协议
这样做的好处有两个：一是模型不需要自己判断哪些内容属于哪一类，降低了理解成本；二是字段隔离之后，你可以在后处理时追踪每一条输出用例的来源，方便人工复核时回溯。
3.2 Prompt骨架：角色、任务、格式、示例四件套
我用了大概两个月时间迭代出一套比较稳定的Prompt模板。核心结构就四块：角色设定、任务描述、输出格式、示例。缺少任何一块，输出质量都会明显下降。
下面是我目前在实际使用的模板：
你是一名资深的测试用例设计工程师。你的工作是从给定的需求描述、历史用例和缺陷记录中，识别出有价值的测试用例，并按照统一格式输出。 任务要求： 1. 从输入材料中抽取所有可验证的行为描述，转化为测试用例。 2. 识别该功能的异常场景和边界条件，补充缺失的用例建议。 3. 每条用例必须包含前置条件、操作步骤、预期结果、场景类型。 4. 场景类型只能是：normal(正常流程)、boundary(边界条件)、exception(异常处理)。 5. 判断该用例的重要程度，返回 high、medium、low 三档。 输入材料： <requirement> {{requirement}} </requirement> <existing_cases> {{existing_cases}} </existing_cases> <defect_records> {{defect_records}} </defect_records> 请严格按照以下JSON格式输出： { "cases": [ { "id": "编号", "title": "用例标题", "precondition": "前置条件", "steps": ["步骤1", "步骤2"], "expected_result": "预期结果", "scenario_type": "normal/boundary/exception", "priority": "high/medium/low", "reason": "为什么识别出这条用例，引用了输入材料中的哪段内容" } ], "missing_scenarios": ["你认为输入材料中没有覆盖到，但应当补充的异常场景描述"] } 参考示例（注意，示例只是为了说明输出格式，不要照搬内容）： 输入：用户输入手机号，点击获取验证码，系统发送短信。 输出：{"cases": [{"title": "获取短信验证码", "precondition": "用户未登录", "steps": ["输入手机号", "点击获取验证码"], "expected_result": "系统发送短信", "scenario_type": "normal", "priority": "high", "reason": "输入材料中描述了获取验证码的主流程"}], "missing_scenarios": ["手机号为空时点击获取验证码", "手机号格式错误时点击获取验证码"]}这套模板里最关键的是最后那个示例。Gpt 5 mini对示例的依赖程度非常高，你给一个什么样的示例，它输出的风格和详略程度就会向那个方向靠拢。这也是我测试下来最有效的控制输出质量的手段。
3.3 输出侧：JSON与置信度
一开始我让模型自由输出文本，结果后处理简直是一场灾难。同一条用例，这次输出是把步骤放在列表里，下次就变成了用箭头分隔的长句子。后来我把输出严格限定为JSON，问题基本解决了。
不过单纯输出JSON还不够，我在每个输出项里加了一个reason字段，要求模型说明“为什么识别出这条用例，引用了输入材料中的哪段内容”。这个字段帮了大忙。人工复核的时候，不用再把原始材料翻出来对照，直接看reason，就能判断这条用例是不是模型“脑补”出来的。
还有一个实践经验：让模型输出一个confidence字段，取值范围0到1，表示模型对这条用例识别结果的自信程度。虽然这个置信度不能完全代表真实准确率，但它有排序价值——置信度低的用例，人工复核时优先看。我做过统计，置信度低于0.6的用例，人工复核后的被删率超过40%，高于0.8的用例，被删率只有不到10%。这个信号对分配人工精力非常有用。
3.4 批处理与去重的工程细节
跑批处理的时候有几个工程细节，不处理好会浪费大量时间和token。
第一个是温度参数。Gpt 5 mini的默认温度对翻译和对话比较友好，但对结构化识别任务偏高。我统一把温度设成了0.1甚至0，让输出尽可能稳定，不要“自由发挥”。实测下来，即便温度等于0，模型在遇到模糊场景时也会出现不同次运行输出不一致的情况，但概率大幅下降。
第二个是语义去重。就算模型本身能做相似度判断，一次跑几千条用例的时候，还是要加上程序层面的去重兜底。我的做法是对每一条输出用例生成一个基于关键动作的向量，然后用向量相似度聚类，相似度超过0.85的自动归并。这里L2距离阈值需要根据业务数据分布调节，我用的0.85是反复试出来的，你们要按自己的数据重新调。
第三个是分批大小。单次请求塞太多用例，模型会偷懒，输出质量明显下滑。我测试下来，一次请求处理10到15条用例左右是比较好的平衡点。超过20条之后，模型开始“只挑重要的说”，容易漏掉细节。
第四个是重试机制。Gpt 5 mini在处理长输出时偶尔会截断JSON。我对所有批处理请求加了一个简单的重试循环，如果JSON解析失败，自动把温度降低重试一次，再失败就降低输入规模重试。这一个小小的机制，让我的批处理的成功率从85%左右提升到了99%以上。
4. 异常场景用例占比：从24%提到61%的调优记录
4.1 为什么死磕这个数字
我先解释一下为什么异常场景用例占比这个指标这么重要。做过故障复盘的人应该都有印象，线上出问题，十次里面有七八次不是因为主流程没测，而是因为某个边界条件没覆盖到。支付回调重复通知、库存被并发扣成负数、超时之后用户又点了一次提交、第三方接口返回了极端数据——这些才是生产事故的主要来源。
我挑了这个指标作为我们这次自动化识别项目的核心优化目标。虽然自动识别并不能直接保证把这些缺陷全抓住，但如果识别的结果里正常场景占了绝大多数，说明这套方案没有提供额外价值，等于白做。
4.2 第一版结果：异常场景占比严重偏低
第一版跑出来的数据让我非常清醒。我选取了三个业务模块的需求文档和历史用例作为输入，让Gpt 5 mini做识别和补全。识别出来的用例一共286条，分布是这样的：
| 场景类型 | 用例数量 | 占比 |
|---|---|---|
| normal（正常流程） | 218 | 76.2% |
| boundary（边界条件） | 35 | 12.2% |
| exception（异常处理） | 33 | 11.5% |
正常场景占到四分之三还多。虽然这个比例比我们手工用例库原本的分布（异常场景占比25%左右）好一点点，但远远达不到我的预期。我想要的不是“比原来好一点”，而是让模型识别出人工容易遗漏的异常分支。第一版说明，模型默认的输出惯性跟我们人工写用例的惯性一模一样——都爱走主流程。
我分析下来，原因有三个。第一个是输入材料本身的偏向性。我们塞给它的历史用例和需求文档，正常流程的描述占了绝大多数，模型从中抽取，自然以正常场景为主。第二个是Prompt里对“异常场景”的定义太模糊。光说“识别异常场景”，模型并不知道你具体指哪些异常，它按自己的理解输出最常见的那几种。第三个是训练数据本身的分布问题。Gpt 5 mini在训练时看到的问答语料里，正常操作流程的文本量远大于异常处理的文本量，模型天然更会识别前者。
4.3 四招把异常场景占比拉上来
针对上面三个原因，我做了四轮调整，每一轮都能看到明显的效果变化。
第一招：给“异常场景”做可操作的定义。我在Prompt里不再笼统地说“异常场景”，而是写清楚异常场景包括哪几类，一共六类：输入类异常（为空、超长、格式错误、类型错误）、状态类异常（重复操作、逆序操作、资源不存在）、权限类异常（未登录、无权限、权限被收回）、数据类异常（并发修改、脏数据、数据被删除）、外部依赖异常（接口超时、网络中断、第三方返回异常）、系统资源异常（内存不足、磁盘满、连接池耗尽）。这六类定义直接写进Prompt，模型输出的异常场景不再是一个模糊的范围，而是可以归类的具体分支。
第二招：为每个正常用例强制生成异常配对。我修改了输出协议，在Prompt里明确要求：每识别出一条normal场景用例，必须同时生成不低于两条对应的boundary和exception场景用例。这个约束一加，异常场景的产出量立刻上来了。这其实是在利用Gpt 5 mini的指令遵循能力，把“补充异常用例”从可选动作变成强制动作。
第三招：引入历史缺陷记录作为异常场景的种子。我们自己的缺陷管理系统里有大量的真实故障描述，这些是最高质量的异常场景素材。我把每条缺陷描述压缩成“操作+条件+预期不符”的三段式，作为输入的一部分提供给模型。模型看到这些真实故障案例后，识别异常的能力有了质的提升，因为它不再需要凭空想象，而是可以基于真实的故障模式进行举一反三。
第四招：调整“缺失场景”的输出权重。原来missing_scenarios字段在输出结构里排最后，模型输出时经常只给一两条。我把这个字段移到输出结构的前面，并明确要求它输出至少五条。这个看似不起眼的位置调整，对输出数量的影响非常大，因为Gpt 5 mini对输出结构顺序是有敏感性的，排在前面的字段往往会被投入更多的注意力。
调整后的数据：
| 场景类型 | 用例数量 | 占比 |
|---|---|---|
| normal（正常流程） | 124 | 38.9% |
| boundary（边界条件） | 91 | 28.5% |
| exception（异常处理） | 104 | 32.6% |
异常场景（boundary加exception）合计占比61.1%。和第一版的23.7%相比，翻了近三倍。
4.4 人工复核与成本核算
数据好看归好看，关键在于这些自动识别出来的异常用例是不是真的有用。我组织了两个人对全部319条用例做人工复核，重点看三条标准：这条用例描述的步骤能不能复现、预期结果是否合理、是否存在明显的逻辑错误。
复核结果：可以通过的用例占76.2%；需要修改措辞和步骤描述才能用的占15.4%；完全不可用、属于模型幻觉的要剔除的占8.4%。对比正常场景的复核通过率（89%），异常场景的通过率偏低，这是因为异常场景往往需要业务知识支撑，模型容易在细节上“编”过头。
成本方面，我算了一笔账：三个模块的输入材料加在一起大概是12000个token，每次调用的输出为1500到2000个token，包括重试在内一共跑了几十次，总token消耗在十万左右。按Gpt 5 mini的API价格算，整个调优过程的测试成本只有几块钱人民币。这个成本优势是这套方案能持续跑下去的前提。
5. 这套方法论在其他用例场景的延伸用法
5.1 ISO 34505的思路给了我什么启发
研究这个项目的时候，我顺手看了ISO 34505:2025《自动驾驶测试场景评价与用例测试生成》的思路，里面关于从场景描述中抽取可测试要素、把连续语义切分成离散用例的框架，给了我很大启发。它强调的“场景覆盖度评估”和我们追求的“异常场景用例占比”本质上是同一件事：不是数量越多越好，而是分布要合理、要素要结构化。这套标准本身的落地方式不限于自动驾驶领域，其“先定义场景结构、再派生用例”的逻辑完全可以反过来指导通用软件的用例治理。我在项目里给每一类识别出来的场景都定义了必须包含的结构化字段，这个做法正是从ISO 34505的框架里借鉴过来的。
5.2 音视频C++封装层的用例提取
另一个实践案例是音视频SDK的C++封装层。这类代码的用例通常不在代码里，而在头文件注释和接口文档里。我用Gpt 5 mini去识别函数注释中的参数约束、返回值约定和错误码说明，自动生成针对每个接口的非法参数用例和边界值用例。
实测发现C++接口的错误处理逻辑比较明确，模型识别错误码枚举和返回值判断的效果很好。但要特别注意，代码注释里的语义模糊问题比需求文档更严重，同一个error_code在上下文中可能代表完全不同的含义。识别结果出来后，建议直接用编译器和静态分析工具验证一遍，不要直接信任模型的输出。这一步能把误报率降低一半以上。
5.3 AccessibilityService用例的自动识别
第三个延伸场景是Android无障碍服务（AccessibilityService）的用例识别。无障碍场景的用例有一个特点：它不仅需要验证功能正确性，还需要验证服务在什么情况下会被系统回收、超时不响应会触发什么保护机制、开启辅助功能后对主进程性能的影响。这些内容在普通需求文档里很难找到描述。
我的做法是收集无障碍服务相关的系统交互日志和崩溃堆栈，让Gpt 5 mini从中识别“系统在什么条件下收回了服务”这类异常场景。这类日志数据的格式比较统一，模型识别的难度反而不高，真正难的是把日志中的系统行为转换成可验证的用户操作步骤。这一层转换暂时还是需要人工介入的。理论上，这类识别和生成可以自动化，但因为涉及系统权限和用户安全预期，我的建议是把模型放在辅助定位、人工确认的位子上，不要把自动识别结果直接进测试计划。
5.4 哪些场景暂时别用它
最后说说不建议用Gpt 5 mini自动识别用例的场景，这些经验是我真金白银踩出来的。
首先是强合规场景。涉及金融交易、医疗数据、支付清算这些领域，用例的每条步骤和预期结果都可能要接受审计。目前模型识别结果的稳定性和可解释性还不足以支撑这样的要求，如果强行使用，人工复核成本甚至会超过手工编写成本。
其次是蕴含复杂状态机的场景。有些业务系统有比较复杂的流程状态流转，用例的正确性严重依赖前置状态。Gpt 5 mini在识别这类用例时，经常会把不同状态下的行为混在一起，导致生成的用例在真实系统上无法复现。
最后是对输出格式有严格要求的场景。如果你后续接的用例管理系统要求严格的字段枚举和层级关系，模型输出虽然能基本满足要求，但在边缘情况下总会出现字段值不在枚举内、层级嵌套错误之类的问题。这类问题不是不能解决，但需要额外写不少校验修正逻辑，要提前把这个成本算进去。
回到开头那个问题：Gpt 5 mini能不能自动识别用例？能，但要清楚它的边界在哪里。它最强的地方是用极低的成本，把散落在各个角落的用例素材粗筛一遍，挑出正常场景，标出异常分支，给出一个结构化、可评审的底稿。它做不了的事情也很明确：替代不了业务判断，替代不了最终的人工复核。我的实际体会是，把它当成一个不知疲倦、随叫随到的用例初筛实习生，而不是一个全知全能的测试专家。如果你刚开始尝试，建议从一个小模块的需求文档跑起，用文章里那套Prompt模板先跑一轮，重点看它输出的reason字段能不能说服你。如果连小模块都说服不了你，那就先别铺开到全局。
