在测试团队里泡了这么多年我一直有个执念能不能让模型替我把几百条历史用例自动过一遍挑出真正有价值的顺便把缺失的异常场景补上。直到我试了Gpt 5 mini这个想法才真正落地。Gpt 5 mini自动识别用例不是一个炫技Demo而是一套可以塞进日常迭代流程的实操方案从需求文档、旧用例、缺陷记录里自动抽取用例要素、打标签、判优先级、补异常分支。这篇文章我会把整套方法、踩过的坑、调优数据全部摊开讲适合正在做测试用例治理、想引入LLM但不知道从哪下手的QA和测试开发同学。1. 被手工用例逼疯之后我盯上了Gpt 5 mini1.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 miniGPT-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正常流程21876.2%boundary边界条件3512.2%exception异常处理3311.5%正常场景占到四分之三还多。虽然这个比例比我们手工用例库原本的分布异常场景占比25%左右好一点点但远远达不到我的预期。我想要的不是“比原来好一点”而是让模型识别出人工容易遗漏的异常分支。第一版说明模型默认的输出惯性跟我们人工写用例的惯性一模一样——都爱走主流程。我分析下来原因有三个。第一个是输入材料本身的偏向性。我们塞给它的历史用例和需求文档正常流程的描述占了绝大多数模型从中抽取自然以正常场景为主。第二个是Prompt里对“异常场景”的定义太模糊。光说“识别异常场景”模型并不知道你具体指哪些异常它按自己的理解输出最常见的那几种。第三个是训练数据本身的分布问题。Gpt 5 mini在训练时看到的问答语料里正常操作流程的文本量远大于异常处理的文本量模型天然更会识别前者。4.3 四招把异常场景占比拉上来针对上面三个原因我做了四轮调整每一轮都能看到明显的效果变化。第一招给“异常场景”做可操作的定义。我在Prompt里不再笼统地说“异常场景”而是写清楚异常场景包括哪几类一共六类输入类异常为空、超长、格式错误、类型错误、状态类异常重复操作、逆序操作、资源不存在、权限类异常未登录、无权限、权限被收回、数据类异常并发修改、脏数据、数据被删除、外部依赖异常接口超时、网络中断、第三方返回异常、系统资源异常内存不足、磁盘满、连接池耗尽。这六类定义直接写进Prompt模型输出的异常场景不再是一个模糊的范围而是可以归类的具体分支。第二招为每个正常用例强制生成异常配对。我修改了输出协议在Prompt里明确要求每识别出一条normal场景用例必须同时生成不低于两条对应的boundary和exception场景用例。这个约束一加异常场景的产出量立刻上来了。这其实是在利用Gpt 5 mini的指令遵循能力把“补充异常用例”从可选动作变成强制动作。第三招引入历史缺陷记录作为异常场景的种子。我们自己的缺陷管理系统里有大量的真实故障描述这些是最高质量的异常场景素材。我把每条缺陷描述压缩成“操作条件预期不符”的三段式作为输入的一部分提供给模型。模型看到这些真实故障案例后识别异常的能力有了质的提升因为它不再需要凭空想象而是可以基于真实的故障模式进行举一反三。第四招调整“缺失场景”的输出权重。原来missing_scenarios字段在输出结构里排最后模型输出时经常只给一两条。我把这个字段移到输出结构的前面并明确要求它输出至少五条。这个看似不起眼的位置调整对输出数量的影响非常大因为Gpt 5 mini对输出结构顺序是有敏感性的排在前面的字段往往会被投入更多的注意力。调整后的数据场景类型用例数量占比normal正常流程12438.9%boundary边界条件9128.5%exception异常处理10432.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字段能不能说服你。如果连小模块都说服不了你那就先别铺开到全局。