深度|AI生成的用例到底能不能用?TestHub用例生成与生成质量分析实战!

写在前面

最近在群里看到很多同学在讨论“AI生成的用例到底能不能用”、“用例生成质量”、“哪个模型适合生成用例”这些话题，觉得挺有意思的，今天就结合我自己用 TestHub 从“需求->用例->执行”的项目实战案例，来深入聊聊这个话题。

先说结论：AI生成的用例绝对可以用，放心大胆地用！

一、用例生成质量和什么有关？如何提高？

在开始讲解案例之前，我们不妨先来思考一个问题：用例生成质量和什么有关？

在搞懂了这个问题后，才能有针对性地提高用例生成质量。

像上面截图中同学所讨论的，有同学说和模型关系不大。那如果我说，千问3 VS ChatGPT5.4，你觉得哪个生成出来的质量高？

有同学说千问要比DeepSeek生成质量高。那如果我说千问生成时所用提示词和需求都比较笼统，而DeepSeek模型参数虽然没有千问强，但是需求较为完善、提示词也非常专业，这时候你又觉得哪个生成出来的用例质量较高呢？

所以，基于以上，我们可以粗略地得出一个结论，用例生成质量不是和某个因素有关，而是与多方面均有联系：

智能体本身：例如AI IDE、测试平台、龙虾、AI问答页面；
提示词：提示词越专业，智能体就能得到更精确的指导和约束，SKills本质上也是一种高级提示词；
模型：毫无疑问，参数更高、综合能力更强的模型生成的用例质量也就越高；
需求：也是无比重要的一点，需求写得不清不楚，前后矛盾，再强大的模型也“巧妇难为无米之炊”。

好了，基于以上思考，我们又可以推导出：

在其中3个因素条件相同的情况下，我们就可以测试出另外1个因素的质量（例如：同一个模型、同一份提示词、同一份需求，用cursor、龙虾、测试平台，来分别生成用例，就可以测试出哪个智能体更胜一筹）；
理论上智能体越好用、提示词越专业、模型越强、需求越完善，生成的质量就越高。

那如何提高用例生成质量，自然也就有了答案。

二、TestHub用例生成实战

很多人觉得 TestHub 生成出来的用例质量效果非常好，基本拿来就用；也有人觉得生成效果一般。下面我就结合TestHub用例生成功能，来实战演示生成出来的用例质量到底怎么样！

先说条件背景：

需求文档：我这里用的是我们项目中真实的「版本迭代」的需求文档（隐私信息已打码）；
大模型：硅基流动的GLM 5.1 + MiniMax 2.5的用例生成模型组合；
提示词：用的是系统默认提示词，没有修改过。

PS：大模型额度不足的可以薅一下硅基流动的羊毛，注册、实名认证后就送 16 元额度，用来生成用例的话够用很久了。拉新也会赠送双方均等额度。注册链接：

https://cloud.siliconflow.cn/i/FB4BZiFO

2.1用例生成行为配置

2.1.1 配置用例生成模型

首先进入配置中心-AI用例生成配置-用例模型配置，配置模型。这里最好选择上下文大点、综合能力相对强一点的模型。需要配置两项，一个是用例编写，一个是用例评审模型。

对于模型配置各字段释义不了解的，可以参考这个视频（界面较之前有改版，但字段释义通用）：

2.1.2 配置提示词

系统已经提供了两套较为专业的提示词，一套是用例编写提示词，一套是用例评审提示词。首次进入可以点击“加载默认提示词”，即可自动加载。当然你也可以选择自己编写、修改，或是用其他AI生成后复制粘贴过来添加。

2.1.3 配置生成行为

这里主要是配置生成行为，例如：是否开启AI评审，生成和评审超时时间设置，默认流式输出还是完整输出。

2.2 使用AI生成用例

当然，首次进入用例生成页面会自动检测配置项，如果配置项不完整的话，会弹出引导配置弹框，点击“去配置”即可自动跳转到上面几个对应配置页面。

2.2.1 输出模式设置

如果配置项齐全的话，则会进入用例生成页面。顶部是输出模式设置：

实时流式输出：模拟打印机效果，实时打印；
完整输出：完成后一次性展示，会有等待，需求越大，等待时间越长。

生成行为中配置的是哪个默认模式，进入此页面后就默认停留在哪个模式选项上，支持手动切换。

无论哪种输出模式，都是支持异步生成的，哪怕流式输出过程中不小心退出了页面，任务也会继续进行，完成后可以在AI生成用例记录页面中查看到。

2.2.2 上传需求

系统支持四种类型的需求上传：

手动输入的需求；
上传需求文档，支持TXT、Markdown、Word、PDF等多格式文档上传（预告一下： 星球版下一版更新将支持100+文件格式解析、OCR图片需求识别等功能）
知识库需求：支持知识库需求召回，使用召回的内容匹配生成指定维度需求的测试用例；
Axure解析需求：调用多模态模型自动解析 Axure 原型链接中的文本说明和交互流程图；

这里我选用的是Word格式的需求文档。

2.2.3 开始生成用例

文档上传后，会自动提取文档内容，拆解测试点，开始生成用例。整个过程分为4个环节：

需求分析：提取文档内容，进行需求分析，拆解测试点；
用例编写：调用AI用例编写模型+用例编写提示词，开始生成用例；
用例评审：调用AI评审模型+用例评审提示词，对上一步生成的用例进行评审，给出评审意见和补充用例；
生成完成：打印基于生成+评审意见综合改进后的最终版用例；

2.2.4 查看生成的用例

用例生成页面分为三个部分：

实时生成内容：也就是调用AI用例编写模型+用例编写提示词生成的用例内容；
AI评审意见：调用AI评审模型+用例评审提示词，对上一步生成的用例给出的评审意见和补充用例；
最终版用例：基于生成+评审意见综合改进后的最终版用例；

我这里一共生成了55条用例。生成完成后，可以保存到记录，也就是导入到传统的用例管理列表；也可以下载到Excel。

前面也说了，用例生成是异步执行的，哪怕流式输出过程中不小心退出了生成页面，任务也会继续进行。所以查看生成的用例可以在用例生成页面实时查看，也可以在用例生成记录详情中查看。

用例生成记录详情，支持单个/批量采纳、弃用、编辑。采纳就是导入到用例管理列表；弃用就是删除该条用例；编辑就是支持手动修改该条用例。

2.2.5 测试用例管理

综上的话，传统的用例管理列表数据来源就有4个：

用例生成时点击底部的保存到测试用例；
生成完成后点击用例生成记录的采纳或批量采纳用例；
使用Excel批量导入用例；
手动创建编写的用例；

三、AI生成的用例到底能不能用？

演示完了 TestHub 的用例生成和用例管理功能，下面就来基于上面TestHub生成的“消息中心-6.6.4.1”的用例，对比需求文档，再结合实际执行过程中的反馈，来逐一拆解AI生成的用例质量怎么样？到底能不能用？用例采纳率是多少？

说实话，这个版本的需求前期我没有过多人为介入去分析，只是需求下来时粗略了解了一下。等到编写用例时，直接丢给TestHub去生成。而后，由于转测比较早，我就对着业务系统，边执行、边标记，再边对比需求文档，查缺补漏。

先来看一张标记总览和数据统计吧。这个版本的迭代需求一共生成了55条用例，通过实际执行、标记后：

绿色：表示用例可采纳、且执行通过---47条；
红色：表示用例可采纳、但出现了bug，执行不通过---3条；
蓝色：表示用例不可采纳、描述有问题，与需求不一致---5条（后面会细分析为什么理解得有偏差）；
黄色：表示有遗漏场景，是我手动补充的---5条（后面会细分析为什么有遗漏）；

绿色执行通过的就不细分析了，下面重点来看红色执行失败（描述没问题、程序出现了bug）、蓝色（理解有偏差、描述有误）以及黄色（遗漏场景）的用例。

3.1 执行失败的用例分析（红色）

执行不通过的一共有3条用例，发现了2个bug。前两条属于第1个bug对应的场景，后1条属于第二个bug对应的场景。

下面我们来对比需求、实际执行结果来看看为什么会出现执行不通过的情况。

需求文档中写的很清楚，有个“优先级排序”的字段最多支持3位数字，此时AI生成出来覆盖了2个场景，一个是输入999的最大三位数场景，一个是输入1000的四位数场景。所以两条用例是没问题的。

但是在实际执行过程中，我发现页面上最多只能输入2位，最大输入99，输入100时就脱焦红字提示。所以这里是因为开发没有完全按照产品的需求来进行开发，判断属于bug。

第二个bug，需求文档描述得也很清楚：短信签名这块下拉框，如果是A模板，则可以选择1、2、3这三个选项，但是如果是B模板，就只能选1选项（置灰不可选）。这块逻辑还是不变的，如果主、备通道有B模板，这块还是只能限制选1选项（也就是说只要有通道包含B模板的，短信签名都置灰、不能下拉选择、默认1选项）。

这个需求，从我们人为角度介入，可以拆分成以下场景：

主备通道均为A模板---短信签名下拉框可自由选1、2、3选项；
主备通道均为B模板---短信签名下拉框置灰不可选、默认1选项；
主通道A模板，备用通道B模板---短信签名下拉框置灰不可选、默认1选项；
主通道B模板，备用通道A模板---短信签名下拉框置灰不可选、默认1选项；

对比下面AI生成的用例可以看出来，与我们人为介入分析出来的场景完全一致。

但是我在实际执行用例、测试过程中，却发现“主备通道均为A模板”这个场景执行不通过，短信签名下拉框仍为置灰、默认1选项、不可选状态。也就是说开发人员在开发时忽略了这个场景，再次判定为bug。

至此，也就是说在这个迭代版本下，AI 生成的用例一共发现了两个bug。

3.2 描述有问题的用例分析（蓝色）

蓝色标识用例不可采纳、描述有问题，一共出现了 5 条。下来就来细分析一下，为什么AI输出的有偏差。究竟是需求描述得有问题还是 AI 理解得有问题。

通过细分析后，TC26、TC39、TC42属于同一类“数据展示范围”的问题（切换通道、弹框筛选条件，都提到了备用通道）；TC53、TC55 为一类问题。

为了清楚说明这些“问题用例”，我们还需要再对比一下需求文档。

通过查看需求文档，我们就会发现，它所表达的意思就是：当点击切换通道按钮，会弹出一个弹框，这个弹框中展示的模板数据：

必须要有备用通道（只有主通道，没有备用通道不展示）；
必须为短信类型，且模板必须审核通过（不是短信类型、不是审核通过的不展示）；

这么一对比，事态就清晰了：

TC26：我个人认为前提条件不够充分，它的场景是验证“验证批量切换弹窗显示数据完整性”，但是前提条件中只提到了“1. 已登录系统；2. 存在带备用通道的短信模板”，并没有提到“模板状态审核通过”；
TC39：这个场景是“验证批量切换-不存在备用通道时的提示”，前提条件2是“模板未配置备用通道”，这个场景不成立！这个模板根本不会展示在这个列表中；
TC42：与 TC39 一样，前提条件2也是“勾选模板A（可正常切换）和模板B（无备用通道）”，同样地，模板 B 也根本不会展示在这个列表中；

就当我怀疑为什么AI 会犯这类低级理解错误时，我又向下翻了翻需求文档，其中有个额外规则说明“实锤”了，原来是产品的需求描述前后矛盾！前边的描述是“弹框展示的必须是有备用通道的模板”，到了后边又补充了一句“该模板不存在备用通道时，提示 xxx”，实际上就是把不存在备用通道的模板也列入了切换弹框可以展示的数据范围！

这确实是难为 AI 了......这波我站 AI ！

这个反面教材也恰好印证了我们前面说的：用例生成质量和需求文档质量有很大关联！所以前期需求评审就显得尤为重要，也就是我们常常说的“测试左移”。

实际执行过程中也发现了 bug：开发没有带上过滤条件，展示了所有状态的模板，不管有没有审核通过。

而 TC53、TC55 的场景来源则很莫名其妙，完全因为 AI 胡诌。我通篇仔细阅读了需求文档中关于这个部分的描述，仅增加了一个“模板id”的筛选条件，很简单，就一句话，完全没有提到“当前通道”这个筛选条件，也没有提到“导出”的事情，并且发送日志的截图上也没有展示“当前通道”和“导出”按钮。不知道 AI 从哪里诌来的“验证发送日志检索-当前通道筛选”、“验证发送日志导出功能”这两个场景......