前一阵子有朋友跟我吐槽说他们团队的接口测试用例全靠手工维护后端一改字段测试脚本就“哗啦”倒一片。我跟他讲赶紧试试把 Cursor 和 Apifox 的 MCP Server 接起来让 AI 直接读接口定义、生成自动化测试用例。他半信半疑地试了一下结果当天下午就把之前攒了两周的活干完了。这也是我想写这篇文章的原因Cursor Apifox MCP Server 这套组合解决的不是“能写脚本”的问题而是“写脚本之前要准备半天接口信息”的问题。它能做什么一句话讲清楚让 AI 通过 MCP 协议实时读取 Apifox 里的接口文档、参数结构、响应示例然后基于这些真实数据生成可运行的 API 自动化测试用例整个过程从配置到出脚本快的话 5 分钟就能跑通第一版。这篇文章适合谁看如果你是测试开发、后端开发或者需要自己维护接口测试的全栈工程师而且正在被“接口文档和测试代码脱节”“用例维护成本高”这类问题折磨那这套玩法值得你花十分钟读完。1. 这套方案到底解决什么问题1.1 写API自动化测试的日常有多折腾先回忆一个特别常见的场景你打开 Apifox找到某个接口复制它的 curl 命令去 Postman 或者代码里手动拼一个 requests 请求。然后呢你还要盯着接口文档里的字段说明一个一个把参数名敲进去敲完还得自己构造边界值、异常值写断言。接口少还好说一旦接口数量上到几十上百个这套流程就变成纯粹的体力劳动。更麻烦的是接口频繁变动。后端今天改个字段明天加个参数你辛辛苦苦维护的测试脚本可能一夜之间就红了。你去翻 Apifox 里的最新文档发现代码里的 url、参数名全都对不上。这时候你就得人工去 diff 接口变更再把变更同步到测试代码里这个过程极其枯燥而且极其容易漏改。所以这事的核心痛点不是“不会写测试代码”而是“获取接口最新信息、理解接口结构、再翻译成代码”这个过程太慢了。而 Ai 擅长的事情恰恰是从结构化的信息里生成代码但前提是它得能拿到准确、最新的接口定义。这就是 MCP Server 存在的意义。1.2 MCP是什么为什么它让“5分钟生成测试用例”成为可能MCP 全称是 Model Context Protocol直译过来是“模型上下文协议”。你可以把它理解成 AI 世界里的“USB 接口标准”。以前要给 AI 插一个外部能力得单独给它写一套插件、调一套 API各家还不互通。MCP 出来以后工具提供方只要按统一协议做一个 ServerAI 客户端比如 Cursor就能直接发现并使用这些工具不需要额外开发适配层。在这套架构里Cursor 是 MCP Host负责跟用户对话、调度 AIApifox MCP Server 是 MCP Server负责把 Apifox 项目里的接口列表、接口详情、测试用例等能力暴露给 AIAI 在需要的时候会调用这些工具就像你打开 Apifox 界面点来点去一样只不过操作者从人换成了 AI。为什么说这让“5分钟生成测试用例”成为可能因为以前 AI 写接口测试只能靠你喂它 curl 或 JSON 示例喂少了它瞎猜喂多了你累。现在 AI 自己就能“看见” Apifox 里的完整接口定义路径、方法、参数、响应结构一目了然。它拿到这些信息后生成代码就是顺理成章的事。这等于把一个需要人肉搬运信息的环节变成了 AI 自动完成的一步。1.3 为什么选Cursor和Apifox这对组合市面上的 AI 编码工具有不少支持 MCP 的也不止 Cursor 一家。但 Cursor 的优势在于它对 MCP 生态的接入做得比较顺滑配置好之后直接在对话里就能调用工具而且它在生成多文件、批量处理代码的场景下表现稳定适合像“生成一整个测试目录”这样的任务。Apifox 作为 MCP Server 的提供方优势就更明显了它本身就是接口管理工具项目里的接口文档、环境、测试用例都是现成的而且结构非常清晰。把它暴露给 AIAI 拿到的不是一段零散的 curl而是带字段类型、校验规则、响应示例的完整定义。有了这些细节生成的用例才真正测得到点子上而不是像很多“AI 生成测试”那样空有壳子。选这对组合还有一层原因它们正好覆盖了“接口信息从哪来”“测试代码在哪生成”这两个关键环节中间通过 MCP 打通省的还是你自己去搬数据。2. 动手前要准备什么2.1 版本与账号准备开始之前先确认你手头的东西齐不齐。首先得有一台装了 Cursor 的电脑建议用 0.5 版本以上MCP 功能在旧版本里要么隐藏得深要么干脆没有新版在设置里直接能找到入口省去很多麻烦。Cursor 本身可以免费下载安装如果你想让 AI 生成质量更高、上下文窗口更大建议开个 Pro 订阅但这不是硬性要求你先用免费额度试跑通流程也行。其次你需要一个 Apifox 账号并且已经创建了一个项目项目里至少有 1 个接口数据。最好这个接口是有完整请求参数和响应示例的这样 AI 生成用例的时候才有足够的素材否则它只能凭空编那就失去意义了。如果 Cursor 界面是英文看起来不太习惯你也可以到 Cursor 的 Settings 里把语言切到中文。这不影响 MCP 功能纯粹是使用体验问题我一般是英文界面用惯了但不少读者反馈中文界面更顺手这个按你自己习惯来。2.2 拿到Apifox的MCP Server地址和TokenApifox MCP Server 不是装在本地的插件它是一个远程服务你需要做的是拿到接入地址和访问凭证。打开 Apifox 客户端进入「账户设置」或「个人中心」找到「API 访问令牌」相关的入口创建一个新的 Token。注意这个 Token 不是你在浏览器登录用的密码而是一个专门给第三方工具调用的密钥生成之后只显示一次记得立刻复制保存。Token 的权限建议按最小化原则来如果你只是生成测试用例那给只读权限就够了。如果后面想把 AI 生成的用例回存到 Apifox可能需要开“测试用例写”权限。这块我用下来的经验是一开始授权别给太大跑通流程后再按需扩容避免 Token 泄露造成太大风险。MCP Server 的访问地址通常在 Apifox 官方文档里能找到规范格式类似https://mcp.apifox.com/mcp不过它会随版本调整你配置之前去官方文档确认一下当前地址。2.3 在Cursor里配置MCP Server打开 Cursor进入 Settings找到 MCP 相关配置项。Cursor 支持两种配置方式一种是 Global MCP Server对所有项目生效另一种是 Project MCP Server只对当前项目生效。我建议测试工程单独建一个目录然后给这个目录配置 Project MCP Server这样不会污染其他开发项目的上下文。点击“Add New MCP Server”或者“Edit MCP Config”会打开一个 JSON 配置文件。你需要在里面填上 Apifox MCP Server 的信息一个典型的配置长这样{ mcpServers: { apifox: { url: https://mcp.apifox.com/mcp, headers: { Authorization: Bearer 你的_APIFOX_TOKEN } } } }几点注意这个文件对 JSON 格式非常敏感少一个逗号都会导致 MCP 加载失败。如果你手写配置务必确认最后一项后面没有多余的逗号。Authorization里的 Bearer 后面有一个空格这也是经常被漏掉的地方。如果你们公司内部网络有代理或者防火墙策略可能需要在这里额外配置代理参数否则远程 MCP Server 可能连不上。2.4 验证MCP连接是否正常配置好之后重启 Cursor。重启完成后打开 MCP 配置面板正常情况下你会看到 apifox 这个 Server 的状态变成了绿色并且能看到它暴露出来的一系列工具列表类似get_project_list、get_api_list、get_api_detail、save_test_case这样的名字。工具名的前缀可能因为 Apifox 版本更新有变化但一般命名都比较直观。光看状态还不够直接在 Cursor 的对话窗口里问一句“请帮我列出 Apifox 当前项目里的所有接口。”如果 MCP 链路正常AI 会调用工具并返回接口列表。如果它说“我没有找到相关工具”那基本可以断定配置或者加载环节出了问题回上一节排查。3. 实战让Cursor生成第一份测试用例3.1 先让AI“看看”你有哪些接口配置完成之后不要急着让 AI 写代码先让它熟悉一下你的接口数据。你可以这样发指令请调用 Apifox MCP Server 的工具列出我当前项目里的所有接口包括接口名称、请求方法、请求路径。这时候 Cursor 的 AI 会调用get_api_list这类工具去 Apifox 拉取接口列表并返回给你。你会看到类似这样的输出登录接口POST /api/v1/auth/login获取当前用户信息GET /api/v1/user/profile新增宠物POST /api/v1/pets查询宠物列表GET /api/v1/pets有了这个清单你就能挑一个接口让它深入分析。我习惯先拿一个接口做样例跑通了再批量生成不要一上来就让 AI 一次生成几十个接口的用例那样一旦方向跑偏排查起来会非常痛苦。3.2 生成GET接口的pytest脚本我拿“查询宠物列表”接口举例子。在对话里继续发指令请调用 Apifox MCP Server 获取“查询宠物列表”接口的完整定义包括请求参数、响应结构然后生成一个 pytest 测试脚本用 requests 库发送请求断言接口返回 200 且响应体是数组。正常情况下AI 会先调用get_api_detail拉取接口详情然后基于返回的真实字段生成脚本。生成的代码大概长这样import requests BASE_URL https://api.example.com def test_get_pets(): resp requests.get(f{BASE_URL}/api/v1/pets, timeout5) assert resp.status_code 200 assert isinstance(resp.json(), list)这段代码看起来简单但注意一个关键点这里面的BASE_URL和接口路径是 AI 从 Apifox 的接口定义里读出来的不是你手动复制给它的。如果接口定义里带了环境变量或域名前缀AI 会结合这些信息来生成比驼背到看截图再手打准确得多。如果你项目里用了环境区分比如 dev、test、prod可以再让 AI 把BASE_URL改成从环境变量读取方便后续在 CI 里切换。3.3 生成带鉴权的POST接口脚本接下来看一个复杂一点的场景POST 接口而且需要带 Token。继续发指令获取“新增宠物”接口的详细参数生成一个 pytest 脚本。要求先调用“登录接口”获取 Token再用这个 Token 去调用“新增宠物”接口对参数进行正常值和异常值的断言。这里 AI 会做两件事一是读取两个接口的定义二是自动生成有依赖关系的测试代码。输出可能是这样import requests BASE_URL https://api.example.com def get_token(): resp requests.post( f{BASE_URL}/api/v1/auth/login, json{username: test, password: 123456}, timeout5, ) assert resp.status_code 200, flogin failed: {resp.text} return resp.json()[access_token] def test_create_pet_success(): token get_token() payload {name: momo, species: cat, age: 2} resp requests.post( f{BASE_URL}/api/v1/pets, jsonpayload, headers{Authorization: fBearer {token}}, timeout5, ) assert resp.status_code 201 assert resp.json()[name] momo def test_create_pet_missing_name(): token get_token() payload {name: , species: cat, age: 2} resp requests.post( f{BASE_URL}/api/v1/pets, jsonpayload, headers{Authorization: fBearer {token}}, timeout5, ) assert resp.status_code 400是不是有点意思你想要的“登录后拿 token 再调业务接口”这个逻辑AI 直接通过读接口定义就理解了。它能理解的原因在于Apifox 接口里定义了登录接口的响应字段而它通过 MCP 拿到了这个字段名才敢在代码里写resp.json()[access_token]。这里面最花时间的代码逻辑AI 几秒钟就生成了。3.4 让测试用例支持数据驱动接口测试跑多了你会发现最值钱的不是“200 走一遍”而是各种参数组合正常值、边界值、异常值、缺失值。手写这种用例太啰嗦但让 AI 生成一点都不费劲。你可以接着发指令把上面的“新增宠物”用例改成数据驱动使用 pytest.mark.parametrize参数列表覆盖正常创建、name为空、species非法、age为负数、age类型错误 这几种情况并在断言里校验对应的 HTTP 状态码。AI 很快会给你一份类似于下面这样的代码import pytest import requests BASE_URL https://api.example.com pytest.mark.parametrize( payload, expected_status, [ ({name: momo, species: cat, age: 2}, 201), ({name: , species: cat, age: 2}, 400), ({name: momo, species: dragon, age: 2}, 422), ({name: momo, species: cat, age: -1}, 422), ({name: momo, species: cat, age: two}, 422), ], ) def test_create_pet_with_parametrize(payload, expected_status): resp requests.post( f{BASE_URL}/api/v1/pets, jsonpayload, timeout5, ) assert resp.status_code expected_status这里我要多两句嘴数据驱动不是魔法你给 AI 的“参数覆盖”覆盖得越清楚它生成的数据越有用。你可以在指令里直接告诉它“name 为空应该返回 400”“age 负数应该返回 422”它就会照着这个预期写断言而不是自己去猜接口的校验规则。如果你想偷懒也可以让它“按常见边界情况生成”但务必把生成的用例过一遍依据接口的真实校验规则修正。3.5 把生成的用例回存到ApifoxCursor 生成完代码之后你可能还希望把这些用例沉淀在 Apifox 里方便团队一起看、后续在 Apifox 里直接跑。Apifox MCP Server 一般提供了保存或更新测试用例的能力你可以在对话里说把刚才生成的“新增宠物”数据驱动用例保存到 Apifox用例名称叫“新增宠物-参数校验用例集”。AI 会尝试调用保存用例的工具把相关测试步骤写到 Apifox。这一步能不能成功取决于你分配给 Token 的权限够不够。如果当前 Token 只有只读权限AI 会提示保存失败这时候你需要在 Apifox 里新增一个有写权限的 Token然后在 Cursor 配置里更新。需要注意的是不要让你生成的用例无脑覆盖 Apifox 里已有的手工用例建议让 AI 先查一下有没有同名用例有的话再确认是否覆盖。4. 几个让生成质量翻倍的提示词技巧4.1 提示词里要把“输出物”说清楚很多人用 AI 生成测试代码指令就一句话“帮我写个测试。”然后 AI 就给你写个简单的 GET 请求回来了。问题不是 AI 不行而是你的输出物定义不够清楚。一个合格的测试生成指令至少要包含这几个要素目标接口是哪个用接口名称或路径指明避免 AI 抓错接口。使用的测试框架是什么比如 pytest、JUnit、TestNG你说清楚 AI 就不会跑偏。断言逻辑要覆盖什么状态码、响应字段、响应时间、错误信息。需要哪些前置条件登录、数据库造数、Mock 数据等。举个例子同样是“写个测试”下面这句话的效果会好很多请使用 pytest requests 为 POST /api/v1/pets 接口生成测试脚本。测试数据放在 test_data.csv 里通过 pytest 的 data fixture 读取。用例需要覆盖响应状态码 201 和 400 两种断言场景并在 setup_module 中完成登录获取 token。你看看AI 拿到这种指令生成出来的代码基本可以直接往项目里放。4.2 让AI先读文档再写代码这是一个非常容易被忽略的环节。有时候 AI 生成的代码接口路径、参数名和 Apifox 里的不一样不是因为 AI 笨而是因为它在上下文里根本没有足够信息。我自己的习惯是生成代码之前一定让 AI 先调用 MCP 工具读接口详情然后把它读到的关键信息复述一遍确认无误后再生成代码。你可以这样说调用 MCP 获取“新增宠物”接口的请求参数和响应结构先用自然语言总结一下参数类型、必填项和响应码然后再生成测试代码。这一步会让 AI 的执行路径变长但质量明显更稳。它相当于让 AI 在“看图写话”之前先“看图描述”避免漏看关键字段。4.3 控制工具调用范围避免上下文爆炸MCP 让 AI 有能力读取大量信息但不代表你该让它一次全读出来。举个例子如果你让 AI“读取项目全部接口并生成测试”它可能会一口气调用几十次工具把上万行接口定义塞进上下文然后 AI 就开始“上下文混乱”生成到后半段质量急剧下降。所以我的建议是分批次处理。先列接口清单然后挑需要测试的接口一批 3 到 5 个逐个获取详情感知一下再生成代码。如果接口特别多生成测试时就让 AI 先输出骨架再逐个填充细节不要一口吃成胖子。还有一个相关的经验Cursor 对话窗口里不要放太多无关历史记录。当你准备生成大规模用例时可以新开一个对话让 AI 从头开始只关注当前这批接口的上下文。这样能明显减少接口串台的概率。5. 常见问题与排查实录5.1 Cursor连不上MCP Server这是配置过程中我见过最多的问题。现象是 MCP 面板里 apifox 的状态一直是红叉或者对话里提示 connect failed。排查步骤通常是这样先确认 URL 是否填写正确有没有多写了空格、少写了斜杠。确认 Token 是否复制完整注意 Authorization header 里的 Bearer 后面必须有空格。确认 Cursor 版本支持远程 MCP Server太老的版本可能没这个功能。如果你在公司网络环境里检查是否有代理策略限制必要时在配置里加上网络代理相关参数。我自己踩过的一个坑是配置完没重启 Cursor导致 MCP Server 一直没加载。后来养成习惯改完配置先重启再问 AI问题少了很多。5.2 400 invalid schema for function 报错这个报错在热词里很显眼实际使用中也确实不少人遇到。它的本质是AI 在调用某个 MCP 工具时传过去的参数格式不符合工具定义的 schema导致服务端校验失败。这里我遇到过的情况包括多传了不存在的字段、把字符串传成了数字、嵌套参数漏层等等。处理方法我总结为三条让 AI 先查看工具的参数定义再组织入参不要凭猜。你可以说“请先查看这个工具的参数 schema确认无误后再调用”。如果是 Apifox 接口里某个字段类型更新了但 AI 读到的信息滞留在之前的上下文里建议新开对话重试。检查 Cursor 和 Apifox MCP Server 的版本如果一方升级后接口协议变了更新另一方往往能解决问题。这类报错不用慌它不是说你操作错误而是说你给的“插头”和“插座”没对齐对齐了就好。5.3 生成的用例一跑就挂这一条太常见了。AI 生成的代码质量再高也逃不过环境差异。常见原因BASE_URL不对Apifox 里配置的环境域名和你本地网络环境不通。接口本身需要请求头比如Content-Type: application/jsonAI 有时候默认 requests 会自己加实际没加。登录用的测试账号密码不合法导致获取 token 失败。断言状态码和 Apifox 接口文档里的响应码不一致比如文档写的 201实际返回 200。我的建议是先用 Apifox 手动发一次请求确认接口在当前环境下能跑通、返回结构是什么样的再把真实返回信息给 AI 看让它对照着调整代码。这一步看着笨但比让 AI 盲猜高效得多。5.4 Token鉴权与环境变量相关问题有些项目里Token 不是直接放在代码里而是通过环境变量注入的。AI 默认生成的可能是硬编码 token这在本地测试还行一旦要提交到 CI 或者多人协作就有泄露风险。你可以让 AI 改成这种写法import os TOKEN os.getenv(API_TOKEN, )然后你运行测试之前在命令行里export API_TOKENxxx。这样测试代码里不会出现密钥Apifox 生成的 Token 也控制在自己手里。如果你要在 CI 里跑把API_TOKEN配置到 CI 的 Secret 变量里即可。5.5 常见问题速查表我在磨合这套方案的时候整理过一张速查表你可以直接收藏现象可能原因处理方式MCP 工具列表不出现URL/Token配置错误或未重启检查配置重启 Cursor对话里提示 connect failed网络策略/代理拦截检查网络环境、代理设置400 invalid schema工具入参格式不匹配让AI先读schema再调用或更新版本接口列表读不到Token权限不足在Apifox重新生成有权限的Token生成的代码连不上接口BASE_URL或请求头错误先在Apifox手动调试再对照生成代码里出现硬编码Token生成时未指定环境变量方案改用os.getenv读取环境变量结尾的实操体会这套流程跑顺之后我自己最大的体会是它真正省下来的不是“写代码”的时间而是“对齐接口信息”的时间。以前测试开发和后端沟通接口变更要么是截图、要么是文档链接然后手工同步到测试脚本。现在直接把 Apifox 的定义暴露给 AI相当于给 AI 装了一双眼睛它能自己看到接口长什么样再动手写测试。最后再分享一个小技巧批量生成测试用例之前先在 Apifox 里把接口文档补全特别是请求参数、响应示例这些字段。接口文档质量越好AI 生成的测试用例就越贴近真实场景。反过来如果接口文档本身就缺斤少两那 MCP 再强也拿不到好素材。用好了这套链路你完全可以做到“接口一变测试用例跟着变”的联动效果。