轻松生成 API 测试的自动化代码

这个系列前面几篇讲的多是 UI 方向。收尾这篇讲 API，因为它是这个垂类里最容易做成的一格，而理解它为什么容易，能反过来说明 UI 为什么难。

三个结构性优势

一、有 schema。 OpenAPI 文档给了字段名、类型、必填性、枚举值。这意味着生成用例时参数矩阵不用猜 —— 边界值直接从类型和约束推出来。

对比 UI：界面上有什么控件、点了会怎样，只能从截图或 DOM 里推断。

二、判据是确定性的。 状态码、响应体的字段和类型 —— 这些能程序判死。而 UI 那边大量断言最后要落到「页面上出现了某句话」，而那句话很可能是模型编的。

三、快几百倍。 我实测过 UI 那边的成本：一次视觉调用 85–90 秒，一条四步用例十六分钟。API 调用是几十毫秒级。 这个差距大到会改变整个设计 —— 能跑一万次的东西和只能跑几十次的东西，做法完全不同。

所以该怎么分工

有一派观点主张干脆别做 GUI —— 理由是让 agent 去看屏幕点坐标，是逼它模仿人的感知局限，而不是发挥它在结构化数据处理上的长处。这个论证有说服力，但那篇没有给出任何 GUI 与 CLI 的性能对比数字，所以它是个该认真考虑的假设，不是已被证明的结论。

我的判断是分工而不是二选一：

走 API 的： 造数据和前置条件（登录、建初始状态）、验数据正确性、需要高频跑的回归。

必须走 UI 的： 要测的就是界面本身（布局、可见性、交互反馈）—— 这类缺陷在 API 层不存在；以及没有 API 覆盖的用户路径。

把「造场景」和「验现象」分开，前者走程序，后者走界面。 现在很多项目每一步都走界面，等于把最贵的手段用在了最不需要它的地方（那 85 秒是怎么来的）。

生成 API 测试的实际做法

从 schema 出发，而不是从描述出发。 让模型读 OpenAPI，按字段类型和约束铺等价类和边界值 —— 这部分其实算法能做得比模型好，模型该做的是补那些 schema 表达不了的（业务规则、字段之间的依赖）。

要出处。 和 UI 那边一样的规矩：每条用例的依据要能指回 schema 的哪个字段或文档的哪一句。API 这边这件事更容易，因为 schema 本身就是可校验的锚点。

别让它编错误码。 这是 API 版本的「编造界面文案」：文档说了「参数非法返回 400」，模型可能写出「返回 {"code": "INVALID_EMAIL"}」—— 而那个具体的 code 值文档里从没出现过。

一个 API 层做不到的事

有个维度值得单独提，因为它容易被「API 更容易」这个结论掩盖：潜在的逻辑约束。

有份基准把这个列为被现有工作忽略的一个关键维度，举的例子是预订系统不能重复预订同一个位置。

这类约束的特点是：文档里不会写，schema 里也表达不了，但一旦被违反就是严重缺陷。 它只存在于业务常识里。

schema 给你的是形状，不是语义。 所以从 schema 生成的用例天然覆盖不到这一格 —— 这也是为什么每条用例的依据必须指得回原始材料，形状对不代表意思对。 —— 要覆盖它，得有别的信息源：领域知识、历史缺陷、或者干脆让人补。

一个该记住的成绩单

有基准专门测「让 agent 从需求拆出测试项再去查缺陷」这件事，十个模型没有一个 F1 超过 30%，最好的 26.4%。而且失败方式分成两派：要么误报率约 70%，要么召回低于 25%。

这个数决定了看这个方向的心态：现在不是「调优一下就能用」的阶段。API 这一格因为有 schema 和确定性判据会好一些，但没好到可以不看。

边界与代价

API 测试覆盖不了用户实际看到的东西。 接口全对而页面白屏，这种事天天发生。API 的容易是有代价的，代价就是它测不到那一层。

从 schema 生成的用例会很多，但未必有用。 这有实测：ULT 这个基准专门挑了 3909 个圈复杂度高、且做过去污染处理的真实 Python 函数（就是为了避开「拿训练集里见过的玩具函数刷分」），各家模型在上面的平均成绩是 —— 正确率 41.32%，语句覆盖 45.10%，分支覆盖 30.22%，变异得分 40.21%。

四个数里最该看的是最后一个。 变异得分量的是「代码被改坏了，测试能不能发现」—— 40.21% 意味着故意注入的缺陷有六成溜过去了。生成一堆能跑绿的用例很容易，生成能抓到问题的用例是另一回事。把每个字段的每个边界都铺一遍，能生成几百条 —— 而其中大部分覆盖的是同一条代码路径。数量不是覆盖度。

这一篇里的成本对比（85 秒 vs 几十毫秒）是我的实测，在一台本地跑 27B 模型的机器上。换成云 API 做视觉，差距会缩小，但数量级仍然在 —— 因为一次视觉调用要编码一张图，而一次 API 断言只要比较几个字段。