我做过一个统计：写一个接口的测试脚本，真正花在”测试设计”上的时间大概只占两成，剩下八成花在哪儿了？

抄接口地址、拼请求参数、组装请求头、写断言、处理鉴权token、调格式……这些活没有技术含量，但你不干就没法往下走。

直到有一天，我把接口文档直接喂给了AI。

从一份Swagger文档说起

那次我们要测一个新上线的订单服务，二十多个接口，文档是一份Swagger导出的JSON。

以前我的做法是：打开文档，一个接口一个接口地看，看完之后打开Postman，手动建请求，填参数，设环境变量，写断言。一个接口从看到跑通，平均十五分钟。二十多个接口，一天就交代了。

这次我把整份Swagger文档扔给了AI，跟它说：”按这个接口文档，帮我生成pytest的接口测试脚本，每个接口至少覆盖正常路径和一个边界异常，公共参数（token、环境地址）用配置文件管理。”

AI给我的东西让我愣了一下：二十多个接口的测试脚本，一次性生成，每个接口有正常请求、有边界值断言、有异常状态码校验，公共部分抽成了fixture。

我不能说它完美——有些业务字段的取值它猜得不对，有些断言写得太宽泛。但骨架是完整的，我只需要往里面填业务逻辑。

一天的工作量，压缩到了两个小时。

AI能做和不能做的

用了一段时间，我摸清了AI在接口测试这件事上的能力边界。

AI能做的：

解析接口文档——不管是Swagger、OpenAPI还是手写的Markdown，它都能读懂结构，提取出请求方法、路径、参数、返回值。

生成请求代码——按你指定的框架（pytest、requests、HttpRunner都行），生成可运行的请求代码，参数化、配置管理、断言都带上。

覆盖基础场景——正常路径、必填参数缺失、类型错误、边界值，这些”教科书场景”它自动覆盖。

AI不能做的：

业务逻辑校验——它不知道”订单金额不能为负”这种业务规则，你得告诉它。

组合场景设计——”先创建订单再取消再查询”这种跨接口的业务流，需要你来设计，AI只负责实现。

数据依赖处理——接口B的入参依赖接口A的返回值，这种串联逻辑AI能写，但依赖关系得你描述清楚。

简单说：AI负责把”设计”变成”代码”，但”设计”本身还得你来。

三个让效果翻倍的用法

一、一次喂一批，别一个一个喂

接口测试最大的效率提升来自”批量”。你一个接口一个接口地喂给AI，和一个文档整体喂给它，效率差很多。

因为接口之间往往有关联——公共参数、鉴权方式、错误码定义。整体喂给AI，它能自动识别这些公共部分，统一管理，生成的代码结构比你手动组织的还规范。

二、给它一套你满意的”样板脚本”

如果你已经有一套写得不错的接口测试脚本，把它作为样例给AI看。告诉它：”按这个风格和结构来生成。”

AI模仿能力很强，给了样板之后，它生成的代码会贴合你的项目习惯，后期的修改量会小很多。

三、让它帮你维护，不只是写

接口变了，测试脚本要跟着改。这种维护工作最烦——不是写新东西，是改老东西，还容易漏。

我现在接口一变更，就把新文档和旧脚本一起扔给AI：”接口变了这些字段，帮我更新脚本，保持其他部分不变。”它改完我过一遍，比我自己逐行找差异快得多。

一个必须注意的坑

AI生成的接口测试脚本，有一个地方特别容易出问题：鉴权。

接口测试的鉴权方式五花八门——有的用token，有的用签名，有的用cookie，有的用AK/SK。AI生成代码时，经常把鉴权部分简化处理，比如直接写死一个token，或者用一个它假设的签名算法。

这种问题跑起来不报错，但请求会被服务端拒绝，你以为脚本有问题，其实是鉴权没对上。

所以每次AI生成完接口脚本，我第一件事就是检查鉴权部分：token从哪来、怎么刷新、签名算法对不对、过期了怎么办。

鉴权对了，脚本就通了一半。

写在最后

接口测试这件事，真正有价值的部分是”设计测试场景”——哪些字段组合容易出问题、哪些业务流需要覆盖、哪些异常情况上线后可能发生。

但这些有价值的工作，以前被大量体力活淹没了。你光是把脚本写出来就耗尽了精力，哪还有心思去想”这个接口还能怎么测”。

AI帮我砍掉了那八成体力活，让我把精力集中在真正有判断价值的两成上。

接口测试不是”写得快”就行，是”想得全”才行。AI让我有时间去想了。

下篇预告：AI辅助性能测试——分析瓶颈、生成压测脚本，让压测不再玄学