基于G-V-R模型的LLM单接口用例生成7步法

测试用例生成的G-V-R模型

在之前笔者梳理的单元测试《基于LLM的单元测试生成，你在第几级？》一文中，提到了浙大团队在论文中提出的G-V-R模型，也就是生成G-验证V-修复R，最终得到可编译、可执行、有断言的单元测试用例。而通常的LLM生成测试用例的方案往往也只是停留在生成环节，甚至只是测试点的生成而已，并没有形成闭环。

而笔者认为在自动化测试生成的过程，也应该是这样的一个G-V-R模型。如无论是类似Fuzz Test的单接口自动化测试或者是多接口组装的场景用例，生成的用例，无论是步骤、入参以及预期结果，甚至是（文件）格式或者是（代码）语义等，都只是LLM基于给定信息的推理，是一种基于概率的猜测，需要来自真实物理世界的验证来对生成结果进行一个反馈，进而修正其中可能存在的问题。

由于单元测试通常生成的是代码，编译和执行依托于工具也非常方便，因此编译、执行、报告过程可以非常顺滑地完成。而接口自动化测试则相对复杂一些。以下是基于G-V-R模型笔者梳理的单接口用例生成7步法。

**API测试用例生成流程**

1)首先由Agent指定任务和接口, 如果是接口Fuzz测试或者是异常测试用例生成，则需要配套的提示词，具体见本文的LLM上下文部分。

2)接着通过RAG/Tool从多数据源召回知识，这部分是整个方案的核心，这也是笔者一直认为的LLM赋能软件工程AI4SE，其实拼的是数据，底层其实是数字化能力。

3)随后结合输入和预期结果，由LLM生成用例，这是API BOY们都懂的部分。

4)生成的用例经Agent导入用例文件或平台，5）由测试平台、工具执行用例。LLM生成的只是文本，经过提取之后转成JSON导入测试平台，或者是代码写入代码文件，并通过工具平台来执行并拿到执行结果。

6)再经LLM进行结果分析，这部分目前已经有不少团队在实践了，也就是基于LLM的测试用例结果分析和失败案例修复。笔者也写过一篇《测试用例执行日志全链路收集-智能化测试结果分析关键技术之一》文章谈到了这个过程中的一项基础能力。

7)最后由Agent提交正式用例。 如本文开头讲过的，如果只是将3）的结果经过步骤4）之后提交到用例平台，只是完成了生成(G)的部分，还需要人工进行确认和修订，并不是一个完整的必须拿，因此需要补上步骤5-6，并且可能需要多次的执行和修正。

**API定义知识库**

接口定义涵盖接口申明（包括接口、结构体申明如结构体A和B，以及结构体中各字段是否必填、Validator、业务枚举值等字段申明）、类型申明（如类型甲、乙）等内容。

目前的方案是用向量库来存放和召回接口定义数据，但是笔者觉得这部分数据更像一个图，用点、边来表述更为合适。后续也会POC图数据库的方案，欢迎搞过的读者留言指导。

**接口用例生成时 LLM 所需的上下文信息**

如之前所述，整个方案成功的关键是数据。以生成环节为例，除了接口定义之外，需要去批发来以下各种数据。

2）数据库表知识，用于上下文控制或者是断言，通常可以是从基线数据库中导入向量数据库的建表语句。

3）样例：测试用例的样例（setup/teardown,公共变量等）、接口调用样例（一些特殊场景）。

4）设计规则： 如等价类划分、异常等价类提取的规则和样例等。这部分建议和接口定义部分的业务枚举值等内容分开管理，以具备通用性。

5）动态数据： 从数据库等外部数据源动态查询的数据。

以上只是接口生成部分的数据，如果是用例结果验证和修复的环节，需要另外去组织如用例执行日志、服务端日志等数据。

随着上下文工程概念的火热，笔者单独为用例生成的上下文画了如下的一张图，将前述数据组织成Prompt。由于提示词长度受限，可能还需要有长度评估和数据遴选/压缩处理的逻辑，以确保在有限的上下文内把话说正确、说完整。

读到这里了，点个赞呗