很多测试新人问过我同一个问题：“接口测试我看了好多教程，Postman、Apifox都会点点，但一到面试聊项目就卡壳，感觉自己练的东西都是散的，怎么办？”
这个问题太普遍了。看教程学的是工具按钮，不是业务链路。真正的接口测试，不是对着一个公开接口发几次请求、看返回200就完事，而是要理解接口背后的业务关系、数据流转、权限控制和异常场景。
我带人练手时最常推荐的一个项目，就是慕慕生鲜。这套前后端分离的生鲜电商系统，几乎把真实业务里接口测试要遇到的所有典型场景都覆盖到了：注册登录、商品浏览、购物车、下单、支付、地址管理、订单查询，接口之间还有真实的数据依赖和状态流转。花一两周时间把它跑通、测透，你对接口测试的理解会从“会调接口”上升到“会测业务”。
这篇文章我就把整个练手过程拆开讲：项目怎么跑起来、接口有哪些、用例怎么设计、工具怎么选、关联接口和登录态怎么处理、自动化怎么落地、以及我实际踩过的坑。内容不算短，但每一步都是可以直接照着做的。
1. 慕慕生鲜为什么是“测试新人友好型”项目
1.1 业务闭环完整，接口之间有真实的数据流转
公开的免费接口，比如天气查询、快递查询，你测来测去就那么一两个请求，参数翻来覆去也就是那几个字段。这类接口最大的问题是：没有业务上下文。你测不出接口跟接口之间是怎么配合的，也感受不到“数据从哪里来、到哪里去”。
慕慕生鲜不一样。它的接口是一整条业务链路的切片：
- 用户先注册登录，拿到身份凭证；
- 然后浏览首页、查看商品分类、进入商品详情；
- 选好商品加入购物车；
- 填写收货地址，提交订单；
- 订单生成后做支付；
- 支付完可以在订单列表里看到订单状态的变化。
这在真实业务里就是一条完整的“人货场”链路。放在接口测试里，价值在于：接口之间是有依赖关系的，不登录就下不了单，购物车里没商品就提交不了订单，订单状态会随着支付动作从“待支付”变成“已支付”。这种依赖关系，才是接口测试真正要练的核心能力。
我见过很多人测接口喜欢“单打独斗”，测登录就只测登录，测订单就只测订单。遇到慕慕生鲜这种有关联的项目，一下就露馅了——因为你会发现，不先处理好登录态、不先从商品接口拿到数据，订单接口根本没法测。
1.2 技术栈主流，练手的同时就在积累面试素材
这套项目常见的形态是：前端用Vue，后端用Spring Boot，数据库用MySQL，接口风格是RESTful，数据格式是JSON，身份认证靠token。这套组合在当下的企业级项目里太常见了，尤其是前后端分离的互联网业务系统。
你在练这个项目的过程中，接触到的每个环节都是面试里高频出现的话题：
- 接口返回的状态码代表什么含义；
- GET、POST、PUT、DELETE 分别用在什么场景；
- 登录后的token是怎么产生、怎么传递、怎么校验的；
- 数据库表结构和接口返回字段的对应关系是什么样的。
比如你去面接口测试岗，面试官问“你在项目中怎么处理接口依赖”，你不能只说“我用Postman定义了一个环境变量”。你得讲清楚：哪个接口的哪个返回字段被提取出来了，存到了什么变量里，后续哪个接口又把变量拼到了请求参数里，如果拿不到这个变量会发生什么。
这些如果只靠想象很难讲出细节，但如果你真的拿慕慕生鲜实操过一遍，这就是你亲身做过的事情，怎么问都有话说。
1.3 数据完全可控，能造出任何你想测的边界数据
练手项目最大的优势不是它能跑，而是你拥有完全的控制权。真实业务里的数据你不能乱改，但这个项目从数据库到后端代码都是你的，你可以随意折腾。
举个我常用的例子：你把商品库存改成0，然后去调用提交订单接口，看看后端会不会正确拦截“库存不足”；你把商品价格改成0.01，下单看看金额计算有没有问题；你把用户余额改成负数，看支付接口会不会报错。这些边界数据，在真实项目里你可能要申请半天权限都不一定能改，但在自己本地环境里，一条SQL就搞定。
这种能力对测试思维的训练特别重要。很多人测接口永远只测“正常情况”，因为脑子里没有“异常数据”的意识。而用自己可控的项目练手，你会慢慢养成一个习惯：每个接口都先问一句，如果我往里面塞一个不正常的数据，系统会怎么反应？这个习惯一旦养成，比学会一百个工具技巧都值钱。
2. 把项目本地跑起来：环境搭建与首次连通
2.1 从零开始的前后端启动步骤
先说环境要求。这套项目常见的运行环境是：JDK 8或更高版本、Maven 3.x、MySQL 5.7或8.0、Node.js 10以上。不需要都是最新版，稳定能用就行。我见过有人为了跑项目去装最新的JDK 21，结果项目本身用的是JDK 8的写法，反而编译不过，纯属给自己挖坑。
整体启动流程分四步：
初始化数据库：项目里一般会附带一个
.sql文件，里面是建库、建表的语句，还有一些基础数据。用Navicat或者命令行把它导入到MySQL里就行。这一步最常见的问题是导错了库，比如SQL脚本里写的是CREATE DATABASE xxxx，但你手动建了一个别的名字的库，导致后端连不上。配置后端数据库连接：打开后端项目里的
application.yml（有的版本叫application.properties），把数据库地址、用户名、密码改成你自己的。这里有个容易忽略的点：检查MySQL的时区配置，很多版本后端启动时报错就是因为时区不对，比如serverTimezone=Asia/Shanghai。启动后端服务：在IDEA里打开后端项目，等Maven把依赖下载完，运行启动类。后端默认端口常见的是8080，如果被占用会启动失败，换一个端口或者关掉占用进程都可以。
启动前端项目：在VSCode或命令行里打开前端项目目录，执行
npm install安装依赖，然后npm run serve启动开发服务器。前端开发服务器的端口一般跟后端不一样，常见的是8081、3000之类。npm install如果慢得离谱，把镜像切到国内的npm镜像源，速度能快好几倍。
2.2 首次连通性验证：绕过页面，直接用接口确认服务活着
很多初学者喜欢依赖前端页面来判断后端是否启动成功。页面能打开不代表后端接口就是通的，更不代表数据库连接没问题。我的习惯是：跑起来之后，先用接口工具直接调一次最基础的请求。
以我手头这个版本的慕慕生鲜为例，第一步我会去调一个不需要登录的公开接口，比如获取首页轮播图或者获取商品分类列表。这类接口路径通常一眼能看出来，比如/api/index或者/api/goods/list之类，具体以你拿到代码里的Controller注解为准。
验证步骤可以按照下面这个表来做：
| 验证项 | 方式 | 预期结果 |
|---|---|---|
| 后端进程存活 | 浏览器直接访问后端根路径或静态资源路径 | 页面有返回或接口返回JSON |
| 数据库连接正常 | 调用一个真的会查表的接口，如商品列表 | 返回正常的业务数据，而不是500错误 |
| 前端能访问后端 | 在前端页面操作一下，看网络请求是否返回正常 | 浏览器Network面板中接口响应正常 |
这一步花不了十分钟，但特别值。因为后面所有的测试都建立在一个前提之上：环境本身是健康的。如果你一上来就闷头写用例，写到一半发现接口全部超时，到头来还要回头排查环境，浪费的时间更多。
3. 接口全貌与测试用例设计：先有地图再动手
3.1 先盘清楚项目到底有哪些接口
拿到项目之后，先别急着打开Postman乱调。第一件事是把这个项目的接口清单梳理出来。怎么梳理？打开后端的Controller层代码，一个Controller对应一个模块，里面的每一个方法对应一个接口。
慕慕生鲜常见的接口模块大概是下面这个结构（不同版本会有差异，但整体思路一致）：
| 模块 | 核心接口 | 主要方法 | 是否需要登录 | 典型职责 |
|---|---|---|---|---|
| 用户 | 发送验证码、注册、登录、获取用户信息 | POST/GET | 部分需要 | 管理用户身份 |
| 首页 | 轮播图、分类列表、热门商品 | GET | 否 | 展示运营内容 |
| 商品 | 商品列表、商品详情、搜索 | GET | 否 | 商品浏览 |
| 购物车 | 加入购物车、购物车列表、修改数量、删除 | POST/GET/PUT/DELETE | 是 | 管理预购商品 |
| 收货地址 | 地址列表、新增地址、设为默认 | GET/POST/PUT | 是 | 收货信息维护 |
| 订单 | 提交订单、订单列表、订单详情、取消订单 | POST/GET | 是 | 交易核心 |
| 支付 | 发起支付、查询支付状态 | POST/GET | 是 | 支付流转 |
梳理出来的表格，就是你的测试地图。哪块做了、哪块没做、哪些接口有依赖关系，一目了然。
3.2 从接口设计反推测试点：方法、参数、鉴权、状态
接口清单有了，接下来要做的就是设计测试点。很多人卡在这一步，不知道一个接口到底要测什么。我常用的方法是按下面这个顺序过一遍，每个维度都能拆出一批用例。
第一，请求方法对不对。接口定义的是POST，你用GET去调，系统会不会正确拒绝？返回的是405还是其他提示？反过来，如果接口定义的是GET，你用POST去调，能不能调通？这一类用例是很多人会漏掉的，但面试官很爱问。
第二，参数校验全不全。必填参数不传、传空字符串、传超长字符串、传非数字类型、传负数、传不存在的ID，每种情况系统的响应是否符合预期？注意这里不是看“报不报错”，而是看报错信息是否友好、HTTP状态码是否合理、有没有返回堆栈信息把后端代码细节暴露出来。
第三，鉴权逻辑严不严。慕慕生鲜里购物车、订单这些模块是要登录的。你直接不带token去调，系统返回什么？带一个伪造的token去调，又返回什么？把token放到Query参数里而不是Header里，系统认不认？这些都是安全维度的重要测试点，也是真实项目中接口测试必不可少的一部分。
第四，业务状态流转对不对。这个是慕慕生鲜这类业务项目特有的价值。比如：一个已经支付的订单，能不能再次支付？一个已经取消的订单，能不能再取消一次？把商品下架之后，购物车里还能不能正常结算？这类用例测的已经不只是接口本身，而是整个系统的业务逻辑。
第五，异常场景突不突。网络层面我们不容易模拟，但数据层面的异常很容易构造。比如让两个用户同时买同一个商品、库存只有1件但两个人都下单成功，后端有没有超卖问题。这类场景在慕慕生鲜上完全能造出来，测的时候也特别能练功力。
3.3 用例整理成文档，别只写在脑子里
我强烈建议，哪怕你是个人练习，也要把设计好的测试用例整理到表格里。一个简单的用例模板就够用：
| 用例编号 | 所属模块 | 接口名称 | 前置条件 | 请求方法 | 请求参数 | 预期结果 |
|---|
为什么要这么麻烦？两个原因。第一，写文档的过程本身就是在逼你想清楚每个细节，很多人在脑子里“觉得”自己会了，一落笔才发现连“前置条件”都说不清楚。第二，这份文档后面可以直接转化为自动化用例，每一行就是一个测试数据，到时候不用重新返工。
我自己带新人时有个规定：没有用例文档，不允许碰接口测试工具。因为工具是执行者，文档才是设计者。顺序不能反。
4. 工具选型：Apifox 还是 Postman
4.1 两个工具的核心差异对比
Postman 是接口测试工具里当之无愧的老大哥，资料多、社区大、功能全。Apifox 是近年国内团队做的“一体化工具体”，把接口文档、接口调试、Mock、自动化测试都塞到了一个工具里，对中文用户极其友好。
两个工具的核心差异我整理了一张表：
| 对比维度 | Postman | Apifox |
|---|---|---|
| 中文支持 | 一般 | 原生中文 |
| 接口文档 | 独立功能，配合API平台使用 | 调试时自动生成文档 |
| Mock数据 | 需要配置 | 内置支持 |
| 自动化测试 | Runner + 脚本 | 场景测试，更直观 |
| 团队协作 | 需要登录账号同步到云端 | 国内服务器，协同体验更好 |
| 学习资料 | 极多 | 比较多，官方文档也很全 |
| 存量案例 | 很多公司还在用 | 新团队和国内项目用得越来越多 |
4.2 学习阶段我的建议
如果是从零开始学，我建议你主力用 Apifox，但也要把 Postman 装一个，至少熟悉它的操作逻辑。原因是两者都有可能在面试或工作中遇到。
有一点你需要明确：工具切换带来的学习成本并不高，你真正要掌握的是那些“通用能力”——环境变量怎么用、集合怎么组织、断言脚本怎么写、批量数据怎么跑。这些概念在两个工具里完全相通，只是菜单位置不同。
我见过有人因为公司用Postman就不学Apifox，或者因为自己喜欢Apifox就看不上Postman，这种工具崇拜没有任何意义。面试官问的是你会不会测接口，不是问你站哪个工具阵营。
5. 最容易翻车的环节：登录态、验证码与参数关联
5.1 登录态管理：token 自动传递的三种姿势
慕慕生鲜这类前后端分离项目，登录后后端会返回一个token，后续需要权限的接口都靠这个token来识别身份。练手阶段最容易犯的错，就是从登录接口响应里把token复制出来，然后粘到下一个接口的Header里。
这招能用，但不能只会这招。因为真实项目里token是有过期时间的，每次手动复制粘贴根本来不及，而且如果用例里还有“登录用户A操作订单，再登录用户B查看订单”这种多用户场景，来回切换会让你崩溃到怀疑人生。
正确的做法是让工具自动管理token。以Apifox为例，流程是这样的：
- 定义一个环境变量，比如叫
token； - 在登录接口的后置操作里，编写一个脚本，从响应数据中提取token，写入环境变量；
- 在需要鉴权的接口里，Header设置成
Authorization: {{token}}或者项目要求的键名。
脚本大概长这样：
// 假设登录接口返回结构是 { "code": 0, "data": { "token": "xxxx" } } const json = pm.response.json(); if (json.code === 0) { pm.environment.set("token", json.data.token); console.log("token提取成功：" + json.data.token); } else { console.log("登录失败：" + JSON.stringify(json)); }Postman的写法类似，只是菜单路径和函数名稍有区别。核心逻辑完全一样：先取响应内容，再提取字段，再存环境变量。
这一招练会了，你才算是迈入接口自动化的门槛。
5.2 验证码从哪来：先搞清楚项目的实现方式
验证码是很多初学者练习时第一个卡住的地方。真实项目里短信验证码是接运营商服务的，这种教学项目不会真花这个钱，所以通常用的是以下几种方式之一：
- 验证码固定，项目配置里写死了一个万能验证码；
- 验证码直接打印在后端控制台；
- 项目里有开关，可以在配置中关闭验证码校验。
拿到项目第一步先看后端代码和配置，找到验证码的处理方式。如果是打印在控制台，那你就注册之前先调一次“发送验证码”接口，然后去后端控制台把这个人的验证码抄过来填进用例。如果是固定验证码，那就省事了，所有用例统一用它就行。
自动化的时候要更聪明一点。如果项目支持，可以把验证码也做成自动提取：发送验证码接口的响应里如果直接返回了验证码字段（有的教学项目为了方便确实这么干），那就在脚本里把验证码也存入环境变量，注册接口直接引用。这样整条链路就能做到“一键跑通”。
5.3 接口参数关联：让数据在接口之间流动起来
慕慕生鲜最有练习价值的地方就在于它的接口参数是强关联的。你不做参数关联，用例就跑不通。
典型链路是这样的：
- 先调用商品列表接口，从返回里提取第一个商品的id；
- 把商品id拼到“加入购物车”的请求参数里；
- 调用购物车列表，拿到购物车记录id；
- 提交订单时使用这个购物车id；
- 订单提交成功后提取订单号，查询订单详情，验证数据跟前面下的一致。
每一步都可能出问题。比如提取的商品id是空、购物车里没加进去导致下单失败、订单号和预期对不上。但恰恰是这些问题，逼着你去搞懂接口间数据传递的每个细节。把这条链路跑通之后，你对接口测试的认知会上一个台阶——因为你已经不只是“测单个接口”，而是在测接口间的集成质量了。
6. 从手动用例到自动化回归：数据驱动与常见坑
6.1 用数据驱动把一条用例变成几十条
手动测试做到一半，你自然会想：这些用例能不能让它自己跑？这时候就要引入数据驱动。
数据驱动的核心思路是：同一个接口，用不同的参数组合去调用，用一套逻辑去断言。最常见的做法是准备一份CSV或JSON文件，里面放多组测试数据，让Apifox或Postman逐行执行。
比如登录接口，你可以准备这样几组数据：
| 用例标题 | 手机号 | 验证码 | 预期结果 |
|---|---|---|---|
| 正常登录 | 13800138000 | 123456 | 登录成功，返回token |
| 验证码错误 | 13800138000 | 000000 | 登录失败，提示验证码错误 |
| 未注册手机号 | 13900139000 | 123456 | 登录失败，提示用户不存在 |
| 手机号为空 | 123456 | 参数校验失败 | |
| 验证码为空 | 13800138000 | 参数校验失败 |
在Apifox的自动化测试里，用“数据源”功能导入这个文件，再把断言写成对“预期结果”字段的比对，一组数据就会变成一条用例。这部分你手动点五个接口要五分钟，数据驱动跑一遍只要几秒钟，而且每次回归都用得上。
6.2 我实际跑这套项目时踩过的几个坑
有一说一，再好的练手项目，跑起来也会有各种小毛病。这里说几个我在慕慕生鲜项目上真实遇到过的坑，你提前知道了能少走弯路。
坑一：重新导入SQL后接口报“表不存在”。一次我把数据库表结构改乱了，想重新导一遍SQL，结果后端日志一直报某张表不存在。后来发现是SQL脚本里建表的顺序有问题，导到一半报错中断，后面的表全没建进去。解决方法是先删掉整个库，再一次性重新导入，不要在报错后继续。
坑二：前端页面能登录，接口直接调却一直401。这个坑特别有代表性。前端能调通，说明后端是好的，问题出在你对请求的理解上。用浏览器的开发者工具看一下前端实际发出的请求，你会发现有的项目token不是放在Authorization头里，而是放在一个自定义的键里，或者叫token，或者叫satoken之类的。你按网上的通用教程放了Authorization，后端当然不认。这种问题一定要学会用浏览器抓包看真实请求，这是接口测试的基本功。
坑三：订单提交成功了，订单列表却查不到。这个通常是用户身份串了。你提交订单用的是用户A的token，查询订单列表的时候却用了用户B的token，那当然查不到。这也是为什么我前面强调要做token自动管理——在手动操作下这种情况很难发现，你复制token时很容易搞混，让人误以为接口有bug。
坑四：并发提交订单，系统生成了两笔订单。这个严格来说不算坑，而是很重要的测试发现。用JMeter或者Apifox的并发功能，让同一用户同时提交两次订单，有的版本没有做接口幂等处理，就会创建两笔一模一样的订单。在真实业务里，用户手抖连点了两次“提交订单”就会遇到这个问题。这恰恰是这个练手项目最有价值的地方——它不是假项目，是真的能测出业务缺陷的。
我把这些问题的排查思路整理成一张表，你遇到类似情况可以照着定位：
| 现象 | 可能原因 | 定位思路 |
|---|---|---|
| 接口全部超时 | 后端没启动/端口不对/防火墙拦截 | 看后端日志，端口占用，浏览器直接访问后端地址 |
| 接口返回500 | 数据库连接问题/代码报错 | 查后端日志堆栈，确认数据库密码库里有没有数据 |
| 登录返回账号密码错误 | 验证码没配对/数据库里的用户状态异常 | 去库里查用户表，确认这条用户数据存在 |
| 能登录但下单失败 | token字段传递错误/购物车为空/商品库存不足 | 抓包看前端真实请求头和参数，逐段复核链路 |
| 订单状态一直不变化 | 支付回调没有触发/后端没处理支付通知 | 确认支付接口是否真正被调用成功，订单状态流转逻辑对应哪个接口 |
6.3 练完之后，这份经验如何迁移到真实项目
慕慕生鲜练完之后，千万别觉得这就完事了。你在这个项目里学到的方法论，是完全可以平移到公司项目里的。
比如你练会了环境变量管理token，那到了真实项目里，不管对方用的是JWT还是Sa-Token，思路都一样，只是解析响应的字段名变了。你练会了数据驱动，到了真实项目里就能跟开发说“我把这个接口的20组边界数据都跑了一遍”，而不是说“我用工具调通了”。你练过并发下单发现重复数据，以后在真实项目里就会主动想到幂等性测试。
这些才是练手项目真正带给你的东西。
我在实际带人的过程中，最明显的体会是：认认真真把一个业务闭环项目测透的人，跟只翻教程不动手的人，聊起接口测试完全是两种状态。前者能讲出具体的接口路径、参数格式、异常现象，后者只能说出一堆名词。
如果你已经买好了Postman或者Apifox，但一直不知道拿什么项目练手，我建议你直接下载一套慕慕生鲜，按这篇文章的路线走一遍。最后再分享一个小技巧：每条用例跑通之后，试着把同样的请求原样重放两遍，看看系统对重复操作的容忍度。很多测试新人忽略的幂等测试，就是从这样一个不起眼的小动作开始的。
