还在手动F12抓包写测试？我用AI 10分钟搞定30个接口用例
前阵子公司来了个新项目，一堆接口要写自动化测试。
我打开 Postman，对着接口文档一个接一个地复制粘贴。写完第8个用例的时候，已经快11点半了。
旁边的开发哥们路过瞄了一眼："你都用 Cursor 写代码了，怎么测试脚本还手敲？"
我当时愣了一下。
说实话，之前还真没往这想。我以为 AI 只能辅助写业务代码，测试脚本这东西不一样。
但我试了之后才发现——我之前浪费的时间太多了。
AI不认识你的系统，真的
很多人一开始跟我一样，打开 Cursor 就喊一句"帮我写个用户登录的接口测试"。
AI 确实给你生成代码了。但里面的接口路径、请求参数都跟你的系统对不上。
为啥？
说白了就是：你系统长什么样子，大模型根本不知道。 它只会根据"常见模式"猜一个出来。猜出来的代码看起来像模像样，一跑就报错。
所以第一步，你得先把接口长什么样"喂"给 AI。
怎么喂？两条路。
路线一：有文档就丢文档
你们团队要是有 Swagger 文档、Postman Collection 这些东西，直接拖给 Cursor。
比如我就这么干过：
（Agent 模式）
@docs/api/user-api.md
根据上面的接口文档，帮我把用户注册接口的测试写了。
场景包含：正常注册、手机号格式不对、验证码错误、密码太短。
AI 读完文档后，路径、入参、返回值一清二楚。生成的代码第一次跑就能过，基本不用改。
但现实是——文档？不存在的。
路线二：F12 大法，最简单也最稳
我们公司的情况，API 文档永远是落后代码好几个版本的。
那怎么办？
我之前也是傻，一个一个接口去问开发："这个接口路径是啥？那个参数必填不？" 问到后来开发都怕了。
后来我想通了：浏览器里啥都有，你抓就行了。
操作很简单：
- 打开你要测的页面，按 F12，切到 Network 标签
- 正常操作一遍（比如注册个用户、下个订单）
- 找到那个请求，右键 → Copy → Copy as cURL
- 把抓到的信息粘给 Cursor
比如我抓了一个"提交工单"的接口，把 cURL 扔给 AI，再加一句功能描述：
"这是提交工单的接口，category 是必填的，attachments 可选。帮我写完整的测试用例。"
AI 拿到真实请求数据后，生成的测试代码基本一次过。
AI 还会"推理"你没说清楚的东西
这一点是我觉得最香的。
比如上面的工单接口，我其实没说 category 有哪些可选值、attachments 有没数量限制。
但 AI 自己就推出了这些测试场景：
- category 传一个不存在的值会怎样？
- attachments 传 0 个文件怎么处理？
- 工单标题超过 200 字呢？
- 同一用户短时间内多次提交呢？
有些场景我自己一开始都没意识到，它主动帮我覆盖了。
当然它也瞎猜过。 比如它觉得附件最多 5 个，其实我们系统上限是 10 个。这时候你直接纠正就行：
"附件上限是 10 个，不是 5 个。另外超过上限不是直接拒绝，是只保留前 10 个。"
AI 马上改过来，连带着相关的边界用例也一并调整。
这过程有点像你带一个实习生——它写草稿，你来 check。比从头写快太多了。
写到后面越来越快
当你写了第1个、第5个、第10个测试用例之后，你会发现一个事：
你给 AI 的说明越来越少。
第1个用例我几乎把所有信息都列出来了。到第10个，我说一句"照刚才的写法，再写个员工列表的查询测试"，它就搞定了。
为什么会这样？
因为 Cursor 在后台把你整个项目做了向量化（Embedding）。你写的每一个测试脚本，AI 都"看"过了。
当你写新用例时，它不是从零开始，而是通过语义检索找到项目里最相似的代码，照着风格帮你续写。
当然不是关键词匹配那么简单。
比如你先写了 test_submit_ticket.py，里面有个创建工单的流程。后面你说"帮我写审批工单的测试"，AI 自动就知道要先创建工单再审批，因为它从你之前的代码里理解了这个业务关系。
代码多了也有新问题
写到大概七八十个测试文件之后，我开始发现问题了。
同一个"创建工单"的操作，不同文件里写法不一样：
- A 文件直接
client.post("/api/v2/tickets", ...) - B 文件封了个
create_ticket()函数 - C 文件参数名都写错了（老版本遗留的）
AI 做语义检索时，可能找到的是 C 文件的旧代码，生成出来的新用例也跟着用错的参数名。
而且文件太多之后，噪音大了，AI 有时候反而找不准最相关的参考。
解决的办法也简单——分层。
三层架构，把代码"整理"给 AI 看
我把接口测试代码分了三层：
api/ → 每个接口只定义一次，全工程唯一入口
services/ → 多接口串联的业务流程，封装成公共方法
tests/ → 测试用例，只关心测试逻辑
具体怎么做的？
api 层：一个接口一个函数。比如工单模块：
# api/ticket_api.py
def create_ticket(client, title, category, content, attachments=None):
payload = {"title": title, "category": category, "content": content}
if attachments:
payload["attachments"] = attachments
return client.post("/api/v2/tickets", json=payload)
每个接口只在这里定义一次，测试文件绝不允许直接拼接接口路径。
services 层：把常用业务流程打包。比如"创建工单并确认已生成"这个两步操作，很多测试用例都用得到，直接封一个方法：
# services/ticket_service.py
def create_and_verify_ticket(client, title, category, content):
resp = create_ticket(client, title, category, content)
assert resp.status_code == 201
return resp.json()["data"]["ticket_id"]
tests 层就清爽多了：
from api.ticket_api import create_ticket
from services.ticket_service import create_and_verify_ticket
def test_create_ticket_success(api_client):
ticket_id = create_and_verify_ticket(api_client, "网络故障", "network", "无法上网")
assert ticket_id is not None
代码量没少，但结构清晰了。AI 再也不会从 100 个文件里找不到北。
最后一步：把规范"写死"给 AI
分层搞好了，但 AI 不知道这些规则。
下次你说"帮我写个测试"，它可能还是直接在测试文件里写 client.post(...) ，绕过你费心封装的 api 层。
怎么办？Rules 文件。
在 .cursor/rules/ 下建一个 .mdc 文件，把你项目的规范写进去：
---
description: 接口自动化编码规范
globs:
- "tests/**/*.py"
- "api/**/*.py"
- "services/**/*.py"
---
## 强制规范
1. 测试文件禁止直接调用 HTTP 客户端，必须用 api 层函数
2. 新增接口必须先在 api 层定义，再引用
3. 多步骤流程优先使用 services 层封装方法
4. 断言必须包含 状态码 + 核心业务字段
这个文件相当于你给 AI 写了一份"入职手册"。从此以后它生成的代码，自动就符合你的规范，不用你再逐行检查。
说点大实话
这套方法我用了大概三个多月了。
最开始那几周确实有点折腾。要搭三层架构、要写 Rules 文件、要纠正 AI 的瞎猜。
但架子上架之后，效率是真的起飞。
上周接了一个新模块，4 个接口、12 个场景的自动化用例——从抓包到写完，不到半小时。
以前这量够我搞一天的。
说到底，AI 生成测试代码的核心是知识管理。你的代码仓库、Rules 文件、API 层封装，这些全部是知识。AI 读取这些知识的方式就是语义检索。
你仓库里的东西越规范，AI 给出的东西就越靠谱。
Everything in git，真的不是一句口号。
你去试试。先从一个模块开始，抓一个接口给 AI 写。跑通了再继续。
踩坑了别慌，评论区聊聊，看看能不能帮你少走点弯路。
转给你那个还在手写接口测试的同事，让他也早点下班。
浙公网安备 33010602011771号