企业官网建设流程全解析

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.0
• Redis服务端（Windows和Mac都有对应的安装包）
• 接口调试工具（建议Apifox，后面细说）
• 一个能运行SpringBoot的IDE（IntelliJ 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?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/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:8080；token和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都记录在案。别小看这个动作，它至少能帮你把每次执行用例的时间从十五分钟压缩到五分钟。慕慕生鲜的数据量和业务复杂度刚好合适，用来练习这些接口测试的工程化习惯，真的非常值得。