最近在研究 Gpt 5 mini自动识别用例 这个方向时我发现自己过去半年在测试团队里踩的坑、做的实验刚好能串成一条完整的经验链。先说清楚一点这里说的“自动识别用例”不是搞个 ChatGPT 套壳帮你随便写几条测试步骤而是把需求文档、界面状态、场景描述这些杂乱的原始输入交给轻量级模型自动拆解成结构化、可执行、能直接进测试管理系统的正式用例。这套东西跑通之后最直观的变化是一次原本要两天的用例设计压缩到半天更重要的是模型能帮你覆盖到人容易忽略的边界条件。这篇文章我会从方案设计、核心链路、两个典型落地场景自动驾驶场景和移动端 UI 场景一直讲到最小闭环的实操代码和避坑记录给正在考虑“用大模型替代一部分用例设计人力”的团队一个真实可参考的样本。1. 这个“自动识别用例”项目到底要解决什么问题1.1 测试用例设计的老大难用例设计这件事听起来门槛不高但实际做起来痛点非常集中。第一是需求歧义产品给一段半自然语言描述不同测试工程师理解出来的测试点能差出一倍第二是遗漏多尤其边界条件、异常流程、时序问题人脑在高压节奏下特别容易形成“路径依赖”翻来覆去就是那几条正常路径第三是口径不统一同一个登录功能三个老员工能设计出三种字段命名、三种优先级标准后面做自动化脚本对接的时候全是坑。这些问题的本质是“自然语言到结构化测试资产”的转换过程完全依赖个人经验而个人经验是不可复制、不可规模化的。所以当 Gpt 5 mini 这类轻量级大模型出现以后我最先想到的落地场景就是用它来做这个“转换层”让模型把非结构化输入转化成统一格式的用例字段把人的经验沉淀成 Prompt 里的规则和示例。这比让它直接写代码要靠谱得多因为用例生成的结果是可校验、可返工的错了最多改一条记录不会像代码 bug 那样埋在线程深处。1.2 为什么是 Gpt 5 mini而不是更重的大模型项目立项的时候团队内部也讨论过到底用哪个模型。最终锁定 Gpt 5 mini核心是三个理由。第一是单次推理成本足够低测试用例生成是一个高频调用的场景一个需求文档经常要拆成几百个片段逐段处理如果用重型模型整体 API 花费会直接吃掉自动化的收益第二是推理延迟可以压得很低交互式的用例生成工具要求用户在几秒内拿到结果Gpt 5 mini 在保持稳定输出格式的前提下能做到准实时响应第三是结构化输出能力这代轻量模型在 JSON 输出、字段约束上的表现已经够用而用例生成恰恰是最依赖结构化输出的场景。当然模型轻了不代表效果一定打折。实测下来在“识别测试点”这个任务上Gpt 5 mini 的处理逻辑更接近“模式匹配加规则外推”而不是创造新的测试理论。这对用例生成来说反而是优点——测试点识别本质上需要的是稳健而不是天马行空。你给它一段需求它能稳定输出“正常流程、异常输入、权限边界、性能预期”这几类测试点就已经完成了 80% 的工作。2. 整体链路设计从原始输入到可执行用例2.1 输入侧什么样的材料最容易让模型“识别出活儿”自动识别用例的第一步是定义输入是什么。很多团队一上来就把产品需求文档整本丢给模型结果输出质量非常差。问题不在模型而在输入颗粒度。大模型处理“一段连贯、单意图的文本”时效果最好比如“用户在登录页输入正确账号密码后点击登录应跳转首页”这种描述模型几乎不会出错。所以我的做法是先把需求拆解成“需求原子”一个需求原子只包含一个用户动作、一个前置条件、一个预期结果。这个拆解可以人工做也可以用模型先做一轮粗拆再人工快速校对。拆完之后每个需求原子会附带一批上下文标签比如“涉及角色、涉及页面、涉及数据约束、涉及异常分支”这些标签会直接进 Prompt辅助模型生成完整用例。这一步看起来繁琐但它是整个管线效果好坏的分水岭输入干净了后面模型输出才稳定。2.2 输出侧用例字段的标准化设计用例识别出来之后不能直接拿文本就完事必须转成一套固定的字段结构。我们自己内部定了一套最小集见下表字段字段说明示例case_id用例编号前缀加模块名login_001summary用例一句话摘要正确账号密码可登录precondition前置条件用户已注册且未锁定steps操作步骤数组格式[打开登录页,输入账号,输入密码,点击登录]test_data测试数据{“账号”:“tester01”,“密码”:“abc123”}expected预期结果跳转首页并显示用户昵称priority优先级 P0/P1/P2P0category用例类型正常流程/边界条件/异常流程/权限校验traceability关联需求原子编号REQ-001这套字段设计有几个讲究。steps 必须用数组不能是自然语言段落这样后续接自动化脚本时可以直接映射成关键字驱动的动作序列test_data 单独拆出来是为了方便做参数化的组合测试traceability 字段非常重要它把用例和上游需求原子绑在一起后续需求变更时能快速定位需要回归的用例这是纯人工设计时最容易漏掉的一环。2.3 识别引擎Prompt 才是真正的“业务逻辑”模型本身是一张白纸自动识别用例的能力全部来自你怎么组织 Prompt。很多新手以为 Prompt 就是一句话“帮我生成测试用例”这种用法输出的东西只能算“看起来像用例的文本”根本没有工程价值。我的做法是构建一个多层次的 Prompt 模板包含四块内容角色定义、任务说明、输出约束、输入材料。角色定义要具体到“你是一名有 8 年经验的测试架构师擅长 Web 和移动端功能测试”任务说明要把输入转化成什么讲清楚比如“请根据需求原子生成全套测试用例覆盖正常流程、异常输入、边界值、权限校验四类”输出约束必须给出 JSON 格式模板和字段说明最好配一个 Few-shot 示例最后是输入材料本身。这四块缺一不可少了输出约束模型就会发挥成散文少了角色定义模型生成的用例深度会明显不够。这套 Prompt 模板一旦调好基本可以复用到团队里 80% 的需求类型上。3. 两个典型场景的落地解析3.1 ISO 34505:2025 与自动驾驶场景用例识别最近行业内讨论比较多的 ISO 34505:2025《自动驾驶测试场景评价与用例测试生成》给自动驾驶测试领域定了一个比较明确的思路先对场景做可测性评价再根据评价结果生成测试用例。传统做法里场景工程师拿到一段自然语言描述比如“雨天前车在高速路突然切入本车道”需要人工去识别场景要素、设定参数范围、定义评价指标最后写成测试用例。这个过程的效率瓶颈很明显很多时间花在把场景描述翻译成结构化数据上。用 Gpt 5 mini 做这个识别链路就很顺手。模型把自然语言场景描述拆成场景六要素本车状态、目标物体、道路结构、环境条件、天气状况、通讯状态。上面那句话可以解析成本车速度 80-100km/h、目标物为前车且横向加速度大于 2m/s、道路为高速直道、环境光照正常、天气为雨天、通讯状态正常。再把这些要素映射到测试用例的步骤和数据参数就能生成一条完整的模拟器测试用例。这个解析过程完全符合标准里“场景评价”到“用例生成”的递进逻辑模型做的是要素抽取和参数建议人只需要做最终的确认和参数校准。这里要提醒一句ISO 34505 最核心的价值不是让你直接拿 LLM 一把梭而是它给出的场景表示方法非常适合作为 Prompt 输出层的模板。我个人的经验是把标准里的场景要素定义直接写进输出约束里让模型按标准格式回填这样生成的用例天然就和下游仿真工具的数据接口对得上不需要再做一次格式转换。标准是骨架模型是填肉的手两者结合才是这个场景的正确打开方式。3.2 AccessibilityService 与移动端 UI 用例识别移动端 UI 测试的自动识别用例是另一个我实际跑了很久的场景涉及的技术点是 Android 的 AccessibilityService。很多人对它的印象还停留在无障碍辅助功能但测试工程里我们更看重它的一点能够实时获取当前窗口的完整控件层级树包括控件的文本、ID、类型、可点击状态、坐标边界。这就是 UI 用例识别最理想的输入。典型做法是写一个测试专用的 AccessibilityService在 onAccessibilityEvent 里监听 TYPE_WINDOW_CONTENT_CHANGED 和 TYPE_VIEW_CLICKED 等事件拿到变化后的 ViewNodeInfo 树。然后把控件树的节点信息整理成一个扁平的交互控件清单每个控件附带“控件类型、资源ID、文本内容、是否可点击、是否可输入”等字段把这个清单丢给 Gpt 5 mini。模型要做的是识别出“哪些控件是有效的测试目标”“这些控件之间最合理的操作顺序是什么”“每一步操作的预期结果应该怎么描述”最终输出一条完整的 UI 流程测试用例。举个例子某次我们让模型分析登录页的控件树它自动识别出三个核心交互点账号输入框、密码输入框、登录按钮。然后它给出的用例覆盖了“空账号登录”“账号格式错误”“密码错误”“正确信息登录”四条路径而且每条路径的步骤都精确到了控件 ID。这个效果不是模型有多聪明而是我们给的控件清单信息足够干净模型做的是“从结构化信息归纳测试路径”这件事它的准确率自然就高。用 AccessibilityService 配合 LLM 做 UI 用例识别比纯截图 OCR 靠谱得多因为控件树里已经包含了自动化脚本直接需要的定位信息。4. 实操闭环用 Gpt 5 mini 搭建最小可用系统4.1 环境准备与模型调用封装实战部分我们用一个最小可用的闭环来跑通“需求原子 → 用例输出”的流程。环境上只需要 Python 环境和官方 SDK模型调用建议统一封装成一个函数方便替换模型版本和注入公共参数。下面是调用封装的核心代码import json from openai import OpenAI client OpenAI( api_keyyour_api_key, base_urlyour_base_url, # 如果用代理网关就填网关地址 ) def build_messages(system_prompt: str, user_content: str) - list: return [ {role: system, content: system_prompt}, {role: user, content: user_content}, ] def generate_cases(requirement_text: str, schema: dict) - dict: system_prompt ( 你是一名有8年经验的测试架构师负责将需求原子转化为结构化测试用例。 你必须严格按照提供的JSON格式输出不允许输出其他内容。 ) template json.dumps(schema, ensure_asciiFalse) user_content ( f需求原子如下\n{requirement_text}\n\n f请输出JSON格式必须为\n{template} ) resp client.chat.completions.create( modelgpt-5-mini, messagesbuild_messages(system_prompt, user_content), response_format{type: json_object}, temperature0.2, ) return json.loads(resp.choices[0].message.content)这段封装里有几个关键参数值得解释。response_format 强制 JSON 输出这在用例生成里是刚需否则模型偶尔会多给你一段“以下是生成的用例”之类的废话解析直接崩。temperature 设到 0.2是让模型在“稳定识别”和“适当泛化”之间取平衡设成 0 的话模型会过拟合到 Few-shot 示例的句式设太高的话字段值会飘。接口层面把 schema 作为参数传入是为了后续能根据业务模块动态切换输出模板比如自动驾驶场景用六要素 schemaUI 场景用控件树 schema。4.2 需求原子拆分与批量处理策略单个 Prompt 生成用例不稀奇真正有工程价值的是批量处理。这里我踩过的最大坑是“一次塞太多需求原子进去”。模型的上文窗口虽然大但塞越多内容输出里的字段覆盖就越不稳定经常出现漏生成某个需求原子用例的情况。最终的策略是“一原子一请求”一个需求原子对应一次模型调用并行度控制在 10 左右。需求原子拆分这一步我们最初也是让模型做后来发现这步必须人工或者半人工。原因是需求拆错的代价是连锁性的后面所有用例都可能沿着错误的方向生成。实际操作中我们保留了“模型粗拆、人工微调”的模式模型把需求文档切成句子级片段人工在界面上快速合并同义项、补充隐含条件完成一批 20 个原子的拆解一般 15 分钟足够。批量生成的 Python 代码逻辑也不复杂用 ThreadPoolExecutor 控制并发每个线程发送一个需求原子的生成请求结果写回本地 JSON 文件。实测下来 10 个并发请求的稳定性和速度最佳再往上会开始撞接口限流。生成完成后统一做一轮 JSON schema 校验凡是解析失败的结果回炉重新请求重试机制一定要带上不加的话一晚上跑完发现有几个用例字段错乱排查成本反而更高。4.3 从 UI 控件树到测试步骤的识别实现针对移动端场景我们写了一个轻量的 AccessibilityService核心功能就是把控件层树转化成结构化的候选元素列表然后交给模型。关键实现片段如下accessibility-service xmlns:androidhttp://schemas.android.com/apk/res/android android:accessibilityEventTypestypeWindowContentChanged|typeViewClicked|typeViewScrolled android:accessibilityFeedbackTypefeedbackGeneric android:accessibilityFlagsflagReportViewIds|flagRetrieveInteractiveWindows android:canRetrieveWindowContenttrue android:canPerformGesturestrue android:notificationTimeout100 /这里有两个配置值得注意。canRetrieveWindowContent 必须设为 true否则拿不到控件树flagReportViewIds 一定要加这样抓取到的控件节点才会带上 viewIdResourceName这是后面映射回自动化脚本的关键定位信息。拿到控件树之后我们只保留“可点击、可输入、可滚动、关键文本”这几类节点过滤掉无意义的布局容器这样喂给模型的控件数量通常能压缩到 10 个以内。控件清单传给模型后Prompt 里会附加一条要求每个操作步骤必须引用控件 ID预期结果必须基于控件状态变化来描述。模型返回的就是标准化的 UI 用例列表每条用例包含操作步骤数组和预期结果。这里有一个比较实际的技巧为了让模型识别出“登录成功应该跳转到首页”你需要把一些生命周期状态文本也放进控件清单比如“登录后出现的用户昵称控件”模型才能写出有判断依据的预期结果否则它只能写出“登录成功”这种无法验证的模糊预期。4.4 用例校验与人工兜底机制自动生成的用例必须有一个自动校验闸口不能直接进测试管理库。我们做了三层校验。第一层是格式校验字段是否存在、steps 是否为数组、test_data 是否为合法 JSON全部用脚本跑。第二层是重复识别对 summary 做相似度去重用简单的余弦相似度加阈值 0.85重复用例自动标记并合并。第三层是基于规则的风险兜底统计每个需求原子的用例数量如果某个原子生成的用例数量低于基线阈值比如正常流程、异常流程、边界值、权限校验四个类别中某类缺失就自动把它挂起进入人工复审队列。这三层校验跑完之后才轮到测试负责人做最终确认。实际执行下来第一版自动生成的用例里大约 20% 会被人工修改或补充主要集中在边界值设置和业务规则约束上。这个比例完全在可接受范围内因为它已经替团队省掉了 80% 的重复劳动。而且随着 Prompt 里积累的 Few-shot 示例越多这个人工修改比例还会继续下降。我自己的体会是不要追求“全自动免检”那是工程事故的温床正确的目标应该是“自动化完成粗活人工聚焦高价值判断”。5. 常见问题与避坑实录5.1 模型幻觉编造不存在的控件和业务规则自动识别用例最让人头疼的问题就是幻觉。模型会一本正经地生成一个“忘记密码”的用例哪怕你的需求文档里根本没提过这个功能。这种幻觉在移动端 UI 场景尤其危险因为模型看到登录页控件树会习惯性地把“注册、忘记密码”这类它训练数据里的常见入口补全到测试用例里。我们的处理办法是把可接受的业务对象清单直接写进 Prompt明确告诉模型“只允许使用以下清单中出现的控件和业务动作”这样能拦截掉大部分幻觉。还有一个有效手段是给模型增加“不知道就跳过”的许可。很多幻觉是因为模型非要凑够用例数量才产生的。我们在 Prompt 里明确写了一句“如果当前输入没有提供充分信息宁可不生成也不要猜测”这句话实测下来能把用例精度提高不少。测试场景不需要模型发挥创造力它需要的是克制和严谨这点和写代码完全不同。5.2 长上下文场景下的信息丢失需求文档一长模型就容易出现“记住开头忘了结尾”的问题尤其当输入里同时包含多个需求原子时后面的原子经常被生成得特别粗糙。这也是我们最终采用“一原子一请求”策略的原因。宁可多调用几次接口也要保证每次请求的输入足够聚焦。批处理时还要注意并行度的设计别一次开太多线程接口限流只是其一更重要的是并发太高时错误率也会上升返回的 JSON 偶尔会出现字段截断。如果确实需要让模型处理长文档我的建议是先做一个“摘要与切分前置模型”。让 Gpt 5 mini 先把长需求文本切成片段并对每个片段生成一个不超过 50 字的摘要然后由人工或规则引擎决定哪些片段需要生成用例。这套方案比直接硬塞长文本要稳定得多。记住一个原则给模型管道的输入宁短勿长信息的取舍应该在上游完成而不是指望模型在推理时自行筛选。5.3 用例重复率高覆盖空洞却没人发现自动生成的用例还容易两极分化同一个场景模型能给你生成一堆词面不同但实质相同的用例看起来数量很多实际覆盖度低。我们最开始跑出来的结果里登录功能 30 条用例有 15 条在测同一件事。后来加了相似度去重和类别分布校验情况才好转。具体做法是给每条用例打上 category 标签然后按需求原子统计类别分布比如“正常流程至少 1 条、异常流程至少 2 条、边界值至少 1 条”不达标就触发补充生成。这背后其实是覆盖率驱动的思路。不要让模型自由发挥而是把它当做一个“按类别补齐用例”的生成器。每次请求时把已生成的用例类别分布告诉他让他优先生成缺失类别的用例。这和保险行业“按危险类别定价”的逻辑一样先确定空的格子再让模型去填格子而不是让模型决定哪里该有格子。5.4 数据安全与隐私红线最后一条也是最重要的一条不是所有需求都能直接发给外部模型。尤其在自动驾驶、金融、医疗这类行业场景描述里往往包含内部道路数据、用户信息、未公开的业务规则。我们在项目里划了一条硬性红线凡包含可识别个人信息、核心算法参数、未发布产品型号的信息一律走脱敏流程或者私有化部署方案。Gpt 5 mini 这类轻量模型的好处是可以在私有环境部署成本相对可控这块在项目规划初期就应该考虑进去而不是等到数据出了事故再补救。另外日志也是一个容易忽视的泄露点。模型调用日志里如果记录了完整的 Prompt 内容那等于把业务数据又复制了一份。我们上线前把日志系统做了改造Prompt 和响应里的敏感字段统一打码只保留用例 ID 和耗时指标。自动识别用例这个工具越方便越要小心它带来的数据暴露风险这是整个工程里最难量化、但最不能省的一环。我个人在这一套“Gpt 5 mini 自动识别用例”方案里最大的心得是别把大模型当决策者只把它当“结构化翻译器”。测试用例设计的最终决策权应该始终留给人模型负责把杂乱信息转成统一格式、把遗漏的边界补上、把重复劳动消化掉。做好这个定位你会发现它带来的效率提升是实打实的而失控的风险也被控制在很小的范围内。后面我们还在试一个扩展方向把生成的用例直接对接自动化执行框架让用例从识别到执行全链路跑通这一步走顺了测试团队的工作方式可能真的要换一套打法了。