社区首页 >专栏 >为什么说只发送接口说明给LLM要求生成单接口用例是在“耍流氓”？

为什么说只发送接口说明给LLM要求生成单接口用例是在“耍流氓”？

Antony

发布于 2025-02-03 14:02:05

1090

文章被收录于专栏：软件测试那些事软件测试那些事

目前在LLM赋能测试的场景中见到比较多的是基于LLM来生成[单]接口的自动化测试用例，也就是针对某个特定接口实现一次完整的接口入参和预期结果的生成。这也是所有后续更高阶和复杂的自动化测试用例的基础步骤。

而常见的方案是将某个接口的OpenAPI spec发送给LLM，要求生成接口一次调用的入参和预期结果。

实际项目中，真有这么轻松吗？入参有效吗，用例能执行通过率怎么样？

以下是笔者梳理的真实项目中可能遇到的问题

序号	类别	问题	说明
1	入参	OpenAPI某个接口的schema中的某个入参字段的声明类型与实际使用中的类型不一致	典型如某个入参字段定义为string，其实是对象甚至是List 对象。如果LLM只是按照schema的声明来生成入参，这些用例顶多只能作为覆盖同一个异常等价类的测试用例。
2	入参	OpenAPI的spec中缺失了约束Validator	Spring提供的validator机制可以对接口入参进行一些有效性校验，例如字段长度、数字大小、日期格式等等。类似的，这些内容的缺失也会造成生成用例的有效性大大降低。
3	入参	有效业务枚举值的缺失	与前一问题类似，LLM能理解String类型的类型边界，如 null, ‘ ’ 等表示空的情况并将其作为测试用例入参。但是如果该String类型字段在业务上用“1”表示男“2” 表示女其余均为无效值。此类数据也不包括在OpenAPI的schema当中，LLM也无从知晓。
4	入参	入参之间的约束/勾稽关系	简单如省和市两个字段，很显然有一个某个市必须和其归属的省对应。此类的内容往往出现在接口的需求规格中，而不是OpenAPI schema中。

前面围绕着入参提出了4个问题，接着从出参/预期结果和用例执行的角度再来4个问题。

5	出参	某个接口出参中包含了泛型	典型如在接口返回时统一做了封装，使用类似ResponseResult等封装类型，其中有一个 Object data 或者T data的字段才是原始的接口方法返回类型，具体类型是运行时决定的。同上类似，只按照schema来生成预期结果的话，也会造成预期结果和实际结果不一致的问题。
6	出参	ERROR CODE	一个接口会有哪些error code, 尤其是采用类似上一案例中的ResponseResult类的场景下，通常发生业务层面的问题时，在HTTP层统一返回status code 200, 而是通过这个类的error_code/error_msg字段来表示真正的业务异常。因此，从出参的角度考虑接口测试的完备性时，对于这类error code的全覆盖也是一个值得考虑的实践。问题在于，这个ERROR CODE List在哪里？LLM显然是不知道的，因为OpenAPI schema里面没有。
7	出参	（断言）通常只能保证生成入参形式上有效，预期结果都是幻觉	由于只给了OpenAPI schema, 并没有提供对应接口的实现方法的代码，LLM无从得知某个入参组合之下，被测应用的真实处理结果，因此预期结果都是靠猜测的。当然现实项目中，仅仅给实现方法也是不够的，因为还有很多外部依赖。给了方法来做的话，其实就是笔者常说的把单接口自动化测试当成大号的单元测试来做的思路了。
8	执行	入参与被测环境的基础数据不匹配	譬如用户、产品、订单号、日期等数据如果通过LLM生成，即使格式上与被测应用完全一致了，也可能因为此类相关的数据在被测环境的数据库中不存在或者不一致，导致用例执行失败。