1. 项目概述与练手价值1.1 为什么我推荐从“慕慕生鲜”切入接口测试做软件测试这一行尤其是刚入行或想转岗接口测试的朋友最头疼的事就是找不到合适的练手项目。要么是公司内部系统没法拿来公开操作要么是网上教程里的demo过于简单测来测去就是登录、查询那两三个接口根本覆盖不了真实业务里的各种场景。“慕慕生鲜”是一个模拟生鲜电商平台的后端接口项目包含用户注册登录、商品分类浏览、购物车管理、订单创建、模拟支付、地址管理等核心业务模块。之所以说它适合练手是因为它具备三个特征业务链路完整、接口数量适中、环境部署简单。第一个特征是业务链路完整。生鲜电商的核心闭环是“选购商品→加入购物车→提交订单→支付→订单状态流转”这中间涉及大量接口之间的数据关联。你在测试过程中会真正遇到“上一个接口返回的token怎么传给下一个接口”“下单接口依赖购物车里的数据购物车数据又要靠前面接口生成”这类实际工程问题。这些恰恰是接口测试的核心能力——不是单个接口调通就完事而是能把整条业务链路串联起来验证。第二个特征是接口数量适中。我数了一下慕慕生鲜整套后端接口大概在30个左右覆盖了用户、商品、购物车、订单、支付、地址六个大模块。这个量级非常合适接口太少了练不出深度接口太多又会淹没在环境搭建和接口梳理里反而没时间好好写用例。而且这些接口设计得很规范RESTful风格返回结果统一是JSON格式大多数接口都需要登录后的token鉴权能逼着你去处理鉴权问题。第三个特征是环境部署简单。项目采用前后端分离架构后端是SpringBoot框架前端是Vue。但练接口测试其实不需要关心前端长什么样直接把后端工程拉下来本地把MySQL数据库初始化好项目就能跑起来。实测下来从零开始到所有接口能正常调通大概只需要花一个下午。这个时间成本对于下班后想学习的人来说非常友好。1.2 接口测试在这个项目里能练出什么你可能会问接口测试和功能测试到底有什么区别我拿慕慕生鲜里的一个场景举例。比如用户下单这个功能页面上就是一个“提交订单”按钮功能测试点一下看订单有没有生成成功就完了。但接口测试要验证的是请求下单接口时参数传少了会怎样商品库存不足时接口返回什么token失效时接口是否拒绝访问同一件商品用两个账号同时下单库存会不会超卖说白了接口测试是站在服务端的视角看系统绕过界面直接和后台逻辑对话。它能发现很多界面操作很难发现的深层问题比如安全性漏洞、参数校验缺失、并发处理缺陷、数据一致性错误。慕慕生鲜这个项目在这些方面都埋了不少“坑”你测着测着就会发现噢原来这个接口没做参数校验、那个接口在并发场景下会出问题这些都是很真实的后端缺陷用来练习接口测试的思维方式再合适不过。另外这个项目也逼着你掌握接口测试的完整工作流梳理接口文档、设计测试用例、准备测试数据、搭建接口测试环境、执行测试、定位问题、输出测试报告。这一套流程走下来和真实工作中接触接口测试项目的节奏几乎一模一样。不管你是准备面试还是想在实际项目中上手接口测试这套思路都能直接迁移。2. 环境准备把慕慕生鲜快速跑起来2.1 技术栈概览与依赖清单在动手之前先搞清楚这个项目需要哪些基础组件。慕慕生鲜后端的核心技术栈是SpringBoot 2.x MyBatis Plus MySQL 5.7/8.0 Redis。Redis主要用于保存登录token和短信验证码所以如果Redis没启动登录和注册接口大概率会报错。你本机需要准备的东西如下JDK 1.8及以上Maven 3.6及以上如果不会用命令行直接用IDEA自带的Maven也行MySQL 5.7或8.0Redis服务端Windows和Mac都有对应的安装包接口调试工具建议Apifox后面细说一个能运行SpringBoot的IDEIntelliJ IDEA或Eclipse都行这里有几个安装上的注意事项。第一MySQL的编码格式建议统一设置为utf8mb4不然初始化SQL脚本里有emoji字符或者特殊符号时会报错。第二Redis不需要额外配置密码项目默认配置是本地无密码连接如果你本机Redis设置了密码需要去application.yml里改一下配置。第三数据库版本和驱动版本要匹配如果你用的是MySQL 8.0需要在pom.xml里确认mysql-connector-java的版本不能太低否则连接时会报“Public Key Retrieval is not allowed”的错误。2.2 初始化数据库与配置项目把项目代码拉下来之后第一步是初始化数据库。在项目根目录下一般会有一个sql文件夹里面放着初始化脚本比如seed.sql或者schema.sql里面既包含建表语句也包含基础的种子数据比如商品分类、商品信息、管理员账号。打开命令行登录MySQL执行以下命令mysql -uroot -p # 输入密码后进入mysql命令行 source /你的项目路径/sql/seed.sql;如果脚本执行没有报错可以用show tables;确认一下表是否创建成功。我比较习惯再执行一条select * from user limit 5;看看种子数据有没有正常插入因为有些脚本里插入语句如果有语法问题MySQL不会回滚会出现建表成功但数据为空的情况。接下来配置application.yml。你需要修改数据库连接信息、Redis连接信息这两个地方。数据库相关配置大概是这样spring: datasource: url: jdbc:mysql://localhost:3306/mumu_mall?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的数据库密码 redis: host: localhost port: 6379修改完之后启动项目。第一次启动会下载大量Maven依赖耐心等待即可。如果启动成功后控制台出现“Started MmApplication”之类的日志说明项目已经跑起来了。默认端口一般是8080你可以先访问一下http://localhost:8080/有些项目会返回一个欢迎页或错误页再用Postman或Apifox试着请求一个公开接口比如获取商品列表的接口看看是否有正常数据返回。2.3 环境自检清单很多初学者在环境这一块就卡住了我总结了一份自检清单按顺序排查基本能解决90%的环境问题。检查MySQL是否已启动navicat或命令行能否正常连接检查Redis是否已启动用redis-cli ping看看是否返回PONG检查项目启动日志中是否有数据库连接相关的报错如果你改了端口记得请求的时候也要用对应的端口确保项目启动没有异常后先用一个公开接口如获取商品列表测试连通性按这个顺序排查能省下不少折腾时间。等环境通了你的“慕慕生鲜”接口测试之旅才算真正开始。3. 接口梳理先看清被测对象再动手测试3.1 用户模块接口分析慕慕生鲜的用户模块是整个系统的基础几乎其他所有业务接口的调用都要求“先登录”。用户模块一般包含这几个接口发送短信验证码、注册、登录、获取用户信息、修改个人信息、退出登录。发送验证码接口是典型的“第一次做接口测试就会被卡住”的接口。原因有两点第一这个接口通常需要传手机号参数且会校验手机号格式第二验证码的存储是在Redis里的测试时需要去Redis查到这个验证码才能完成后续注册或登录流程。这里有一个非常实用的调试技巧测试环境下验证码可以直接从Redis里获取具体命令是进入Redis后执行keys *sms*或者keys *code*然后根据key找到对应的value值。这比去数据库翻记录还快。登录接口返回的数据结构很关键你要特别注意token字段的位置和名称。慕慕生鲜的登录接口返回格式一般类似这样{ code: 200, message: 操作成功, data: { token: eyJhbGciOiJIUzI1NiJ9.xxx.xxx, userInfo: { userId: 10001, nickname: 测试用户, phone: 13800138000 } } }后续几乎所有需要登录的接口都要在请求头里带上token这个字段。实际项目中常见的做法是放在Header的Authorization或自定义的header里具体名称要看接口文档。慕慕生鲜这里比较常规通常是Authorization: token值的格式但也有可能是token: token值。我通常的做法是先在登录接口的返回体里找到token的实际字段名再去接口文档里确认Header参数名称两手抓避免猜错。3.2 商品与购物车模块接口分析商品模块的接口相对简单主要是首页轮播图、商品分类列表、按分类查询商品列表、商品详情。这些接口大部分不需要登录适合用来做接口测试的“热身练习”。购物车模块就有意思了。它的核心特点是依赖登录态且操作路径比较固定。典型接口是加入购物车、查看购物车列表、修改购物车商品数量、删除购物车商品。这里有一个业务逻辑上的细节加入购物车接口通常接收两个关键参数——商品ID和购买数量。如果同一个商品ID已经存在于购物车中再次加入时系统应该是做“数量累加”而不是新增一条记录。这是一个很值得写进测试用例里的业务规则。购物车接口的返回数据也有特点一般是一个购物车商品列表的集合每个商品项里包含商品ID、名称、单价、数量、小计金额、是否选中等信息。接口测试时要注意验证加入购物车成功后查看购物车列表接口返回的商品数量是否与预期一致修改数量时如果传一个超过库存上限的数量系统是拒绝还是自动截断传入负数的数量接口会不会报错。这些都是购物车模块测试用例设计的重点。3.3 订单与支付模块接口分析订单模块是慕慕生鲜最核心、也最能体现接口测试深度的地方。订单相关的接口包括确认订单页信息获取、提交订单、订单列表查询、订单详情、取消订单、模拟支付。每个接口背后都有一堆业务状态要校验。提交订单是重中之重。它接收的参数非常复杂一般包括收货地址ID、用户的优惠券ID如果有、用户备注、从购物车中勾选的商品列表或直接从商品详情页购买的商品信息。这里就涉及到了“前置数据依赖”提交订单之前你必须在购物车中至少有一个选中的商品否则接口可能会返回“请先选择商品”之类的提示。模拟支付接口是订单模块里最经典的接口。它做的事情是接收订单号然后模拟第三方支付的回调过程。这里有一个很容易踩的坑支付接口通常需要传入支付方式比如余额支付、模拟微信支付、模拟支付宝支付和订单号。但支付完成后订单状态的变更并不是立刻反映到订单详情接口的中间可能存在一个异步回调的延迟。测试时如果你调完支付接口立刻查订单详情很可能会看到订单状态仍是“待支付”这不一定是你测试失败了而可能是异步任务还在处理中稍等一两秒再查一次就正常了。4. 测试用例设计业务链路反推接口用例4.1 单接口参数用例的四个维度单接口的测试用例设计我习惯从四个维度来补全正常参数、边界参数、异常参数、缺失参数。拿登录接口举例。正常参数比较容易理解正确的手机号和正确的验证码预期返回成功。边界参数就要动脑子了比如手机号这一项11位是正常长度那12位会怎么样10位会怎么样纯数字的11位但以0开头系统接不接受这些都是手机号这个字段的边界情况非常值得测试。异常参数可以是类型错误比如手机号传一个字符串“abc”或者验证码传一个负数。缺失参数最简单直接把请求体里某项去掉看看系统是返回友好的“参数不能为空”提示还是一堆难懂的堆栈异常。接口测试圈里有一句话叫“你不测异常参数线上就会帮你测”。很多真实生产环境的故障源头就是前端做了参数校验但后端接口没有做绕过前端直接调接口各种脏数据就进来了。慕慕生鲜这个项目里你会发现部分接口确实存在校验不完善的情况遇到这种问题一定要记录到测试报告里这比“接口调通”更重要——因为你发现了真实缺陷。4.2 从业务流程梳理集成用例单接口用例能保证每个接口本身工作正常但真实用户可不会只调一个接口。用户下单的完整操作路径是注册或登录→浏览商品→加入购物车→查看购物车→提交订单→支付订单→查看订单列表。这套流程对应的就是一条完整的接口调用链。集成用例设计的核心是参数传递。登录接口返回的token要传给后续所有需要鉴权的接口加入购物车接口返回后查看购物车接口能不能看到新增的商品订单金额等于商品单价乘以数量这个金额在提交订单接口返回的订单详情里对不对得上。我自己的做法是准备一份Excel表格把整条链路里每个接口用到的参数来源列出来比如“token取自登录接口返回值的data.token”“skuId取自商品详情接口返回值的data.id”做完这个依赖图整个链路的参数传递关系就一目了然了。链路用例里最容易被忽略的是数据清理。每执行一轮完整的下单流程数据库里就会多出一条订单记录、几条订单明细记录、购物车记录也会被清空。如果你反复执行同一套用例第一次可能是正常的第二次就可能因为“购物车里没有选中商品”而失败。所以每轮测试执行完要么走接口去清空购物车、取消订单要么直接对数据库做一轮清理保证测试环境的数据是可控的。4.3 测试数据准备的三种方式接口测试的数据准备通常有三种方式人工造数、接口造数、SQL造数。人工造数就是在界面上手动操作注册一个账号、添加几个商品到购物车。优点是直观缺点是慢而且不方便批量准备。接口造数是直接调用接口来生成数据比如注册接口本身就可以批量生成用户这种方式的效率比人工造数高很多。SQL造数是最快的直接往数据库表里insert数据比如要构造一个已经支付成功的订单直接改订单表和订单明细表的状态字段就行。实际测试中我推荐按这个优先级来组合使用能用SQL造数的场景尽量用SQL比如订单状态类的数据直接update一行记录的状态字段效率最高。需要验证接口全链路时用接口造数因为你本身就是在测接口。人工造数只在特定场景下才用比如要验证前端页面展示效果。这里要注意一个安全意识和责任边界的问题。在实际工作中测试环境的数据库你可以随便造数、改数但绝对不要在生产环境里用update语句去修改任何数据。在慕慕生鲜这个本地项目中你当然可以随意折腾但养成这个习惯很重要。5. 工具选型与实操Apifox为主JMeter为辅5.1 为什么首推Apifox接口测试工具五花八门Postman名气最大JMeter侧重性能国产的Apifox、Apipost也各有拥趸。我在椒盐生鲜项目上主推Apifox原因有三个。第一Apifox把“接口文档管理”和“接口测试”合在了一个工具里。你可以直接把项目的接口以文档形式维护在Apifox里然后每个接口旁边就能直接发起请求、编写断言不需要在Postman里导来导去也不用来回切换界面。这一点对做接口测试的人来说非常香因为接口测试的产出物之一就是接口用例文档文档和测试一体化能少做很多重复工作。第二Apifox的环境变量管理非常顺手。你可以配置“测试环境”“生产环境”等多套环境每套环境定义好baseURL和全局变量比如token、userId。在接口请求时用\{\{token\}\}这样的变量占位符切换环境时不需要改任何用例。这对多环境测试尤其方便。第三Apifox支持一键把测试用例保存为“测试场景”场景里的多个接口可以按照顺序依次执行并且支持在接口之间传递变量。这就特别适合做第五章里提到的链路测试。比如我先调登录接口取token再把token传递给下单接口整个过程不需要写一行代码界面操作就能配置完成。当然也不是说Postman不行。Postman的生态和社区资源更丰富但它的自动化能力分布在Collection Runner和Newman里配置起来没有Apifox那么直观。我个人的组合习惯是Apifox负责日常接口调试、用例维护、自动化回归JMeter负责需要并发压测的场景。5.2 在Apifox中配置环境与公共变量拿到慕慕生鲜项目后我建议先做两件事新建一条接口文档目录、配置好环境变量。接口文档不一定要照着某个标准文档整理按模块来就行。比如用户模块、商品模块、购物车模块、订单模块。每个接口下面把url、请求方式、请求参数、响应示例写清楚后续测试时直接在这里发起请求即可。环境变量主要配置三个baseUrl、token、userId。baseUrl填http://localhost:8080token和userId留空后面通过“从响应中提取变量”的方式自动赋值。Apifox里“提取变量”的功能在接口请求的“后置操作”中可以把它理解为当登录接口返回成功后从返回值JSONPath表达式定位到token字段的值然后写入环境变量。配置方式是在后置操作中添加一条“变量提取”变量名填token变量值来源选择“JSONPath”表达式填data.token。后续其他接口的Header里写{{token}}”即可Apifox会自动替换成真实值。5.3 接口调试实操以登录接口为例登录接口大概长这样。先用Apifox发起一个验证码请求POST /api/user/sendSmsCode Content-Type: application/json { phone: 13800138000 }如果Redis里有这个验证码对应的key接口会返回验证码发送成功的提示。现在去Redis执行一下redis-cli # 查找相关key keys *code* # 拿到key后读取value get sms:13800138000把value值记下来这就是当前手机号对应的验证码。然后用验证码调注册或登录接口POST /api/user/login Content-Type: application/json { phone: 13800138000, smsCode: 123456 }注意实际场景中要填从Redis里拿到的真实验证码我这里的“123456”只是举例。登录成功后返回的JSON里会有token按5.2节的方法配置一个后置变量提取把token和userId都存到环境变量里。到这里登录这块的准备工作就完成了。接下来你调试其他需要登录态的接口时在请求头里加一个Authorization或token的字段值填\{\{token\}\}Apifox发请求时就会自动把token变量替换成登录时存进去的值。5.4 用Apifox自动化跑通完整下单流程链路测试是接口测试的重头戏我用Apifox的“测试场景”功能跑通慕慕生鲜的下单流程步骤大概是这样的设置“发送验证码”接口传手机号。设置“登录”接口从Redis拿到验证码后填入参数。这一步使用上一步的同一个手机号。从登录响应中提取token和userId设置成全局变量。设置“获取商品列表”接口不需要登录从返回结果中提取第一个商品的productId。设置“加入购物车”接口需要登录把上一步的productId传入数量默认填1。设置“查看购物车”接口确认商品已加进去并从返回结果中取出cartItemId。设置“提交订单”接口传入地址ID、备注、来自购物车的商品数据。从订单提交成功的响应中提取orderId。设置“模拟支付”接口传入orderId。设置“查询订单详情”接口断言订单状态是否为“已支付”。把这些接口按顺序排列在一个测试场景里Apifox会自动在上一步和下一步之间传递变量。场景跑完后会生成一份测试报告包括每一步接口的状态码、耗时、断言结果。如果想测异常场景比如提交订单时传一个不存在的地址ID可以直接复制这个场景改一下参数再加入对应的断言变成反向下单流程。这里有一个很重要的断言习惯。很多人断言只看状态码是否等于200但真实项目中HTTP 200只代表服务端接收到了请求并正常返回了业务是否成功还要看响应体里的业务状态码。假如登录失败了但接口返回格式是{code: 500, message: 验证码错误}状态码仍然是200只看HTTP状态码断言会把用例误判成通过。所以断言一定要结合业务状态码和关键业务字段来写。我的判断标准是多层断言第一层断言code是否等于200第二层断言data.token是否存在第三层才可以是一个具体的金额或者状态值。5.5 用JMeter补一轮并发压测接口功能正常和接口在并发下正常是两码事。慕慕生鲜项目的订单模块非常适合做并发测试因为它是典型的读写多、共享数据多的模块。我用JMeter做一个简单的并发场景10个线程同时对一个商品下单看库存会不会超卖。JMeter的配置要关注几个点线程组设置并发用户数、循环次数HTTP请求默认值里填baseURL和公共Header添加一个“CSV数据文件”用来参数化手机号确保每个线程用的是不同账号再加一个“JSON提取器”把登录接口返回的token提取出来传给下单接口。还有一个JMeter核心知识点需要特别注意JMeter的“仅一次控制器”和“全局变量”配合使用可以保证多个HTTP请求共享同一个登录token。线程数和循环次数要根据业务来定。比如慕慕生鲜的商品库存假设就10件你模拟20个用户同时下单预期正确的结果是只有10个订单能支付成功其余订单应该显示库存不足。如果测试跑完发现订单全部成功那这个项目就存在“超卖”缺陷这就是并发压测能发现的最典型的业务逻辑问题。6. 常见问题与排查技巧实录6.1 验证码接口的验证码到底怎么拿这是新手必问的问题。在真实的短信服务里验证码会发到用户的手机上但测试环境里不可能每次都真的发短信。常见的替代方案有两种一是找开发在测试环境关闭短信发送直接在接口返回里返回验证码二是从Redis中间件里直接读取这也是我每轮测试时最常用的方式。在慕慕生鲜项目里你先调发送验证码接口然后打开Redis的终端输入keys *sms*或者keys *code*会看到一个类似sms:13800138000的key执行get sms:13800138000就能拿到当前的验证码。这里的验证码一般5分钟有效超时了重新发送一条就行。6.2 登录态失效与token过期接口测试执行到一半突然发现后续接口全部返回“未登录”或“token无效”这种情况基本就是token过期了。慕慕生鲜的token有效期一般配置在Redis里默认可能是两个小时但实际测试时可能因为等待时间过长、服务重启、Redis重启等原因导致token失效。解决思路是不要手动去换token而是让工具自动处理。Apifox的后置操作里可以做这样一个“自动重新登录”的流程先发一个获取用户信息的接口如果响应结果里的业务code不是200就重新调登录接口拿新token覆盖环境变量然后再重试原接口。虽然配置起来稍微有一点编码量但一旦配置好整条测试链路的健壮性会大幅提升。6.3 接口返回成功但数据没变的排查思路你可能会遇到这种情况登录接口返回200下单接口也返回200但登录后查看用户信息的接口返回的nickname还是旧的。这一类问题通常要从“缓存”和“调用链追踪”两个角度排查。先看缓存。慕慕生鲜用了Redis用户信息查询可能优先走了缓存。如果修改用户信息的接口只更新了MySQL没有同步更新Redis缓存那查到的就还是旧值。这时候去Redis执行keys userInfo*看看有没有对应的缓存直接删掉这个key再重新查询如果数据正常了就说明是缓存没更新导致的问题。这是后端非常常见的缺陷。再看请求ID和调用链。如果你使用的工具支持打印请求日志可以顺着日志看一下接口返回的数据到底是从哪个方法返回的、经过了几层缓存、有没有命中数据库。很多时候问题不在测试工具而在服务端逻辑本身。6.4 数据库与接口数据对不上下单接口返回的订单金额是99元但数据库里存的是109元这种问题我遇到过不止一次。排查方向一般是先去数据库看订单明细表和订单主表的数据差异再检查入参里的金额到底是从前端传的还是后端自己算的。其实这个场景正好反映了一个接口测试的重要原则接口返回和数据库落库是两个层面的事情。接口返回成功不代表落库数据正确。所以在测试用例设计阶段就要考虑“数据校验”这一层。查完接口响应之后用一条SQL去确认数据表中的关键字段也是正确状态这才是完整的闭环验证。7. 写在最后的实操心得慕慕生鲜这个项目我前后带过不少朋友一起练过每次都能看到一个共性的成长曲线最开始所有人都在折腾环境然后在一个个接口调通的过程中获得成就感最后真正拉开差距的是能不能从“调通接口”进化到“用接口用例去挖缺陷”。工具操作只是表面功夫接口背后的数据流转、状态变更、并发并发等因素才是真正值得深入研究的点。我个人在实战中养成的习惯是每测完一个模块就把这个模块里踩过的坑整理成一份自己的checklist。比如“登录接口注意token字段名”“提交订单前检查购物车是否有选中商品”“支付回调可能延迟断言前等待2秒”。这些看似零碎的笔记在以后做任何项目的接口测试时都能复用它们才是真正的经验积累。另外还想提一个容易被忽略的小技巧做链路测试之前先准备一份“测试数据速查表”把常用账号、常用商品ID、常用地址ID都记录在案。别小看这个动作它至少能帮你把每次执行用例的时间从十五分钟压缩到五分钟。慕慕生鲜的数据量和业务复杂度刚好合适用来练习这些接口测试的工程化习惯真的非常值得。