Apifox 使用方式与典型场景
四、使用方式与典型场景
示例一：后置脚本断言 + 提取 token。登录接口跑通后，把返回的 token 写进环境变量，后续接口用 {{token}} 引用，避免手工复制：
// 后置脚本：断言状态码与业务码
pm.test("HTTP 状态码为 200", function () {
pm.response.to.have.status(200);
});
pm.test("业务码为 0", function () {
const body = pm.response.json();
pm.expect(body.code).to.eql(0);
});
// 提取 token 写入当前环境，后续接口直接 {{token}}
const body = pm.response.json();
pm.environment.set("token", body.data.token);
// 把整个响应存成临时变量，方便排查
pm.variables.set("lastLoginResponse", JSON.stringify(body));示例二：多接口串联 + 数据驱动。把「登录 → 创建订单 → 查询订单 → 取消订单」串成一个测试场景，订单号通过变量在步骤间传递；再用一份 CSV 做数据驱动，一次跑多组参数：
// 步骤 2「创建订单」的后置脚本：把订单号传给后续步骤
const body = pm.response.json();
pm.environment.set("orderId", body.data.orderId);
// 步骤 3「查询订单」的请求里直接引用
// GET {{baseUrl}}/api/orders/{{orderId}}
// 步骤 4「取消订单」前置脚本：做一次防御性校验
pm.test("订单号已就绪", function () {
pm.expect(pm.environment.get("orderId")).to.be.a("string").and.not.empty;
});
// 数据驱动：在场景里挂一份 CSV，列名即变量名
// username,password,expectCode
// demo01,Passw0rd,0
// demo02,WrongPass,401示例三：OpenAPI 双向同步。后端已经用注解生成了 OpenAPI 文件的项目，可以导入 Apifox 生成接口与文档；此后若在 Apifox 侧改了定义，再导出 OpenAPI 交给后端做代码生成，形成闭环。
# 把导出的 OpenAPI 文件放进仓库，供两侧共同引用
curl -s http://localhost:8080/v3/api-docs -o openapi.json
# CI 里做一次契约校验：先起服务拿到最新 OpenAPI，
# 再与仓库里的版本比对，有差异就让流水线失败
diff <(jq -S . openapi.json) <(jq -S . docs/openapi.json)适合与不适合的场景：Apifox 适合团队协作、接口数量多、需要文档与实现保持同步、且要做接口回归的项目；也适合前后端分离、后端未就绪时需要 Mock 先行的团队。不太适合的场景有两类：一是纯个人、只偶尔发几个请求，用轻量工具更快；二是接口含大量非 HTTP 协议（gRPC 流式、WebSocket 长连接、消息队列）的系统，调试仍要回到专用工具上。安全提醒：接口调试凭据（token、Cookie、数据库连接串）不要提交进代码仓库，全部走环境变量与流水线密钥管理；自动化测试要打向测试环境，不要指向生产；如果测试涉及第三方系统，需事先取得对方授权。
