做接口测试这几年我经常被人问同一个问题“有没有适合练手的实战项目”这个问题的难点在于项目太简单测完等于没测项目太复杂环境都搭不起来更别提跑通流程了。直到我花了一个周末把一个叫“慕慕生鲜”的电商类项目完整撸了一遍从接口梳理、环境搭建到用例设计、脚本跑通整个过程非常顺畅。如果你正在学接口测试或者准备面试想找个高含金量的项目经验这个项目值得当作你的主力练手对象。慕慕生鲜是一个前后端分离的商城系统核心业务围绕“生鲜商品交易”展开包含用户、商品、购物车、订单、支付等典型电商模块。它的接口设计规范、业务链路完整、数据流转清晰既能练Postman、Apifox这类工具的基础操作又能练JMeter的并发场景还能顺带把接口自动化测试的整套思路摸清楚。简单说这是我目前见过最适合从入门到进阶一条龙练下来的接口测试项目。1. 项目整体拆解为什么慕慕生鲜适合当练手项目1.1 前后端分离架构对测试人员意味着什么慕慕生鲜采用前后端分离架构后端基于Spring Boot提供RESTful API接口前端用Vue开发页面两者通过JSON格式的数据进行交互。这种架构是目前企业内部最主流的开发模式也是接口测试能独立于UI测试存在的前提。站在测试角度前后端分离带来两个直接变化一是接口有独立的文档和调试入口你可以完全不关心页面长得什么样直接对服务端发起请求、校验响应二是接口的职责边界更清晰同一个接口可能被多个页面复用。比如说用户登录后获取token这个接口在Web端、小程序端、App端都会用到接口本身的逻辑完全一致。这对接口测试工程师来说是个好消息。因为你不需要打开浏览器、不需要操作页面元素只要拿着接口文档就能覆盖大部分核心业务功能。而且一旦接口层验证通过前端的很多问题可以直接定位到渲染逻辑而非服务端逻辑排查效率能提高一大截。这也是为什么现在很多测试团队会把接口测试作为回归测试的第一道防线。1.2 核心业务模块与接口分布慕慕生鲜的接口可以按照业务模块分成几个大类每个模块对应一组关联紧密的接口。用户模块注册、登录、获取用户信息、修改个人信息、收货地址管理。这是所有业务的入口登录后返回的token会作为后续请求的凭证。商品模块商品列表分页查询、商品分类、商品详情、搜索商品。商品数据是商城系统的核心数据源所有交易行为都围绕商品展开。购物车模块加入购物车、修改购物车商品数量、删除购物车商品、查询购物车列表。购物车本质是订单的“预选区”接口逻辑虽然简单但和下单流程紧密关联。订单模块创建订单、订单列表、订单详情、取消订单、确认收货。这是整个项目中业务状态流转最复杂的模块各种状态边界值特别适合设计测试用例。支付模块发起支付、支付回调。在实际项目中支付会对接第三方支付平台但在练手项目里通常会用模拟支付接口代替这对测试来说反而更友好因为你不需要真实的支付账号也能跑通全流程。从接口测试的角度看这个模块划分最大的价值在于它完整覆盖了一套电商交易主链路——用户登录后浏览商品把商品加入购物车从购物车生成订单最后完成支付。整个链路涉及多个模块的接口串联和参数传递这正好是接口测试从单接口测试走向场景测试的绝佳训练内容。1.3 为什么选择电商类项目练接口测试很多人练手喜欢做Todo List、图书管理这类极简项目但我个人不太推荐。原因很简单项目业务量太小你练到的只是接口测试的表层操作Postman发个请求、看个响应就结束了涉及不到复杂的业务逻辑和接口关联。电商类项目是更好的选择。首先电商涉及的角色多访客、注册用户、管理员不同角色对接口的访问权限不同这就能练到鉴权测试。其次电商的业务状态多订单有未支付、已支付、已发货、已完成、已取消等状态每种状态之间的切换有严格的业务规则这就能练到状态流转测试。最后电商的数据关系复杂商品有库存限制用户有余额限制订单要关联用户和商品接口之间不是孤立存在而是强依赖的这就能练到接口依赖和场景串联。还有一个非常实际的原因电商是面试中最高频的业务场景。你在简历上写“熟悉电商项目接口测试”面试官会默认你理解基本的交易流程对话很容易展开。反过来你要是写个待办事项项目面试官连追问的兴趣都不大。2. 环境搭建实战从零跑通慕慕生鲜后端服务2.1 本地环境准备清单在开始接口测试之前你得先把项目跑起来。慕慕生鲜的环境搭建不算复杂但有几个前置条件需要提前装好。JDK 1.8及以上版本用于运行Spring Boot后端服务。版本最好不要太低很多新依赖对JDK版本有硬性要求。MySQL 5.7或8.0用于存储业务数据。项目里一般附带SQL脚本导入后就有完整的表结构和初始数据。IDE工具推荐IDEA或Eclipse。IDEA对Spring Boot的支持更友好接口调试、依赖管理都方便很多。接口测试工具Postman、Apifox二选一。Postman是国际通用工具Apifox更贴合国内习惯并且自带接口文档管理新手用Apifox上手更快。如果项目有Redis依赖还需要提前安装Redis用于缓存token、商品信息等热点数据。这里有个经验之谈环境版本最好先看项目的README文档或pom.xml里的依赖声明不要自己凭感觉装最新版。比如MySQL 8.0的驱动和5.7的驱动在URL配置上是有差异的直接拿网上旧教程的配置去连新版本数据库很容易踩坑。2.2 初始化数据库与启动服务数据库初始化和服务启动是整个项目跑起来的核心步骤按照下面这个顺序操作基本不会出大问题。第一步创建数据库。用Navicat或命令行工具连接本地MySQL执行CREATE DATABASE IF NOT EXISTS mumu_fresh DEFAULT CHARACTER SET utf8mb4指定utf8mb4字符集避免中文数据乱码。第二步导入SQL脚本。在项目根目录找到.sql文件通常是init.sql或者sql文件夹下的多个脚本文件。整个导入过程会创建用户表、商品表、购物车表、订单表等核心数据表并插入演示数据。导入完成后随便查一张表能返回数据就说明数据库这一趴没问题。第三步修改配置文件。打开application.yml或application.properties确认数据源配置里的URL、用户名、密码是否和本地环境一致。重点检查数据库URL中的时区参数比如serverTimezoneAsia/Shanghai没有这个参数MySQL 8.0会报时区错误。第四步启动后端服务。在IDEA中运行主启动类观察控制台日志。看到类似Tomcat started on port(s): 8080的日志输出说明服务已经启动成功。如果端口被占用可以在配置文件中修改server.port为其他值比如8081。第五步验证接口连通性。在浏览器直接访问http://localhost:8080/你的项目上下文路径/接口路径或者用Postman发一个最简单的GET请求比如获取商品分类列表。能返回JSON数据说明整个链路已经打通。2.3 接口文档在手测试不慌项目跑通之后第一件事不是急着动手测而是先把接口文档研究明白。慕慕生鲜这类完整项目基本都会配套接口文档可能是Swagger自动生成的在线文档也可能是Markdown格式的离线文档。如果是Swagger启动服务后访问http://localhost:8080/swagger-ui.html就能看到当前服务所有接口的列表包括请求方法、请求路径、参数含义、响应结构。这个在线文档最大的好处是支持直接在页面上调试你可以先在这里把每个接口调通再回到Postman或Apifox里组织用例。如果是离线文档我建议你先把文档里的公共响应结构提炼出来。慕慕生鲜的接口通常统一返回一个Result对象包含code状态码、message提示信息、data业务数据三个字段。code为200表示成功不为200时data可能为nullmessage里带出错原因。理解这套公共结构你在写断言的时候就能做到通用化处理。看文档时还要重点关注请求头。登录接口成功后返回的token在后续请求中需要放在Header的Authorization字段里携带服务端通过拦截器校验token是否有效。这是典型的JWT令牌鉴权机制你不仅要知道怎么带token还要知道不带token、带错误token、token过期这几种情况下服务端分别返回什么这些都是接口测试必写的用例。3. 核心接口实操拆解一条业务主链路的完整测试过程3.1 用户注册与登录拿token是第一步用户模块是整个测试流程的起点因为后续所有需要鉴权的接口都依赖登录后拿到的token。我先给你拆一下登录接口的完整请求结构。登录接口通常是一个POST请求路径类似/api/user/login请求体采用JSON格式。需要传account和password两个字段account既可以是用户名也可以是手机号password是经过MD5加密后的密码串。响应体里除了用户基本信息外还会有一个token字段这个token就是后续所有需要登录状态的接口的通行证。在Postman里实操时我建议你设置一个环境变量叫baseUrl值为http://localhost:8080再设置一个环境变量叫token值为空字符串。登录成功后通过脚本自动提取token。Postman的Tests标签页里加上这段代码var jsonData pm.response.json(); if (jsonData.code 200) { pm.environment.set(token, jsonData.data.token); pm.test(登录成功返回token, function() { pm.expect(jsonData.data.token).to.not.be.empty; }); }这样后续请求的Header里直接引用{{token}}就不用手动复制粘贴了。这个思路放到Apifox里也成立只是写法略有差异逻辑完全一样。登录接口的用例设计除了正常的账号密码匹配外重点要注意这几类场景密码错误时返回什么状态码账号不存在时返回什么提示参数为空时是返回400还是业务错误码连续登录失败多次后是否有验证码策略。这些异常场景在面试里很常考因为最能体现你对接口的思考深度。3.2 商品列表与商品详情理解查询参数和响应结构商品模块的接口比较适合新手练手因为它不涉及复杂的状态变更纯粹是查询逻辑。但越是简单的接口越能验证你的基本功比如参数拼接、分页处理、字段类型校验。商品分页列表接口一般是GET请求路径类似/api/goods/list通过Query参数传pageNum和pageSize控制分页。既然项目里包含分类维度可能还要传categoryId做分类筛选。响应数据通常包含total总记录数、list当前页商品数据列表、pageNum、pageSize这些字段。测试这个接口时有一个细节特别值得关注不传pageNum和pageSize时服务端是否有默认值以及传入pageNum为0或负数时服务端是直接报错还是自动纠正为第一页。很多项目在处理分页参数时不够严谨如果你能发现这种边界问题提一个高质量的Bug在团队里的印象分会直线上升。商品详情接口一般是GET请求路径类似/api/goods/detail/{id}把商品ID作为路径参数传给服务端。测试点主要围绕传一个不存在的ID时返回什么传非数字类型比如abc时服务端是否有参数类型转换异常商品ID缺失时路由是否匹配到404。这个接口用来练接口关联特别合适。你可以从商品列表接口的响应里提取一个商品的ID传参给商品详情接口验证列表页取到的ID确实能打开对应详情页。这就模拟了用户在页面上从列表进入详情的真实操作比单纯分别测两个接口更有价值。3.3 购物车操作与下单流程接口联动的经典场景购物车和下单流程是慕慕生鲜整个项目里接口关联性最强的一段也是我认为最值得花精力研究的重点。这里的核心逻辑是购物车接口影响订单创建的数据来源订单接口又反过来控制购物车中商品的去向接口与接口之间的数据依赖非常明确。购物车加入接口通常是POST请求路径类似/api/cart/add请求体里传goodsId和goodsCount。这里有个很典型的测试点同一个商品重复加入购物车是数量累加还是新增一条记录两种设计都有其合理性关键是服务端的行为要符合需求文档的约定。下单接口是整个链路的重头戏路径通常是POST /api/order/create请求体包含购物车选择的商品项、收货地址ID、用户备注等字段。下单成功后的响应里会返回订单ID和订单编号这个订单编号在后续的支付流程里会被继续使用。我在测试下单接口时踩过一个很典型的坑创建订单时没有校验购物车中的商品是否处于上架状态。也就是说如果商品已经被下架但购物车里还有这个商品的记录直接下单依然能成功。从业务逻辑上讲这肯定是不合理的从接口测试的角度讲这就是一个值得记录和上报的真实缺陷。这类问题只有当你把购物车和订单两条接口链路串起来测时才能发现单测一个购物车接口、单测一个订单接口都测不出来。3.4 模拟支付回调把状态流转补齐支付接口在实际项目中对接的是微信支付、支付宝这类第三方平台但在慕慕生鲜这种练手项目里通常是用一个模拟支付接口来代替。支付接口的路径一般类似POST /api/pay接收订单编号作为参数支付成功后订单状态从“待支付”变为“已支付”同时扣减对应商品的库存。测试支付接口时存在一个天然的难点真实情况下支付结果是由第三方平台回调通知服务端的测试环境没有第三方平台怎么模拟这个回调解决办法是项目自带模拟支付接口或者提供一个管理员端的“标记已支付”入口。发起支付请求后通过查询订单详情接口确认订单状态确实从1转变成了2这就是我们常说的“结果验证”。如果你想把支付回调的测试做得再专业一点还可以关注这样的细节同一笔订单重复支付时第二次支付是直接返回成功还是报“订单已支付”支付成功后再次取消订单系统是否拦截支付失败后订单状态是否保持不变。这些场景都和资金安全挂钩属于电商项目里优先级很高的测试场景。4. 接口测试用例设计从“能通”到“测得全”4.1 单接口维度的用例设计方法接口测试用例设计很多新手只会写“正常传参返回成功”这一条这远远不够。在慕慕生鲜这个项目里我建议你按照下面这个维度去打散每个接口的测试用例基本就能覆盖绝大部分风险点。第一个维度是正常场景。参数合法、前置条件满足验证接口能按需求文档返回正确的数据结构和业务逻辑结果。比如登录接口正常返回token商品列表正常返回分页数据。第二个维度是参数维度。包括必填参数缺失、参数类型错误、参数长度超限、参数值不在枚举范围内。比如注册接口的密码字段长度到底是6到20位还是8到16位需求文档必须定义清楚没有定义的地方就是你提Bug或者找开发确认的切入点。第三个维度是业务规则维度。接口不仅仅是参数的转发背后还有具体的业务逻辑。比如下单接口要考虑库存不足、购物车为空、商品已下架这些业务状态是否被正确处理。第四个维度是权限维度。一类是未登录状态访问需要登录的接口看服务端是否返回未认证的提示另一类是普通用户访问管理员接口看服务端是否做了角色校验。很多线上安全事故的根源就是接口只做了登录校验没做权限控制。第五个维度是容错维度。请求头缺省、请求体JSON格式错误、Content-Type错误、服务端异常时返回的HTTP状态码是否符合预期。这类用例覆盖的是服务端的健壮性往往最容易在这些地方挖出真实Bug。拿商品详情接口举例一个比较完整的用例清单长这样用例类型用例描述预期结果正常场景传入存在的商品ID返回200data中包含商品详情正常场景传入已下架商品的ID返回200data中包含下架标记参数异常传入不存在的商品ID返回业务错误码提示商品不存在参数异常传入非数字ID如abc返回400或业务错误码服务端无500报错参数异常不传商品ID返回404或参数缺失提示权限验证不携带token访问返回401或未认证提示容错验证请求一个不存在的路径返回404服务端日志无堆栈异常4.2 多接口场景维度的用例设计方法单接口用例覆盖的是每个接口自身的正确性但真实用户操作永远是跨接口的。接口场景用例的价值在于验证多个接口串联起来后数据流转和状态变更是否符合预期。场景用例的设计方法可以遵循“用户核心操作路径”这个思路。电商项目里最核心的路径就是注册→登录→浏览商品→加入购物车→提交订单→进行支付→查看订单状态。在这个路径上每一步的输入都依赖上一步的输出比如登录依赖注册的用户信息下单依赖购物车的商品数据支付依赖订单编号。具体设计时我推荐用“三步法”第一步梳理业务路径画出一条主链路上的所有接口节点。画出接口之间的数据依赖关系比如哪个接口的哪个响应字段会成为下游接口的请求参数。第二步为每个依赖关系设计验证点。比如下单接口依赖购物车数据那就要验证购物车为空时下单是否被拦截购物车有商品但商品库存发生变化时下单按哪个库存去校验。第三步补充分支路径和异常路径。比如支付成功后主动取消订单先取消订单再支付验证服务端是否处理了这种时序错乱。这些场景最容易暴露状态机设计的漏洞。4.3 测试数据准备与清理的经验接口测试的数据准备经常被忽略但做起来很影响效率。在慕慕生鲜项目里我习惯在数据库层面准备一套专门的测试数据而不是复用初始化自带的演示数据防止相互干扰。用户数据方面至少准备一个正常用户、一个被禁用的用户、一个没有任何订单的新注册用户。商品数据方面至少准备一个正常上架且库存充足的商品、一个库存为0的商品、一个已下架的商品。订单数据方面则可以构造待支付、已支付、已发货、已完成、已取消几种状态的订单各一份。测试数据的清理同样重要。每跑完一轮接口测试数据库里会积累大量脏数据比如反复下单产生的订单记录、反复注册产生的测试账号。如果不清理下一次测试时会因为历史数据干扰导致用例失败。我的做法是在MySQL里单独建一个测试库每次执行完整接口回归前重新导入初始SQL脚本保证环境是干净可复现的。5. 主流接口测试工具在慕慕生鲜中的实战应用5.1 Apifox玩法文档、调试、自动化一把梭Apifox是目前国内测试圈最常用的接口工具之一它在慕慕生鲜这种前后端分离项目里的天然优势是既可以直接导入Swagger接口文档生成接口列表又能在工具里直接调试还能把调试好的用例固化下来做接口自动化回归。如果你手上有Swagger的在线JSON地址直接用Apifox的导入功能选择“导入Swagger/IETF/OpenAPI”类型填上项目启动后的Swagger地址所有接口会自动同步进Apifox自动带好URL、请求方法、参数结构。这个功能能省掉你大量手动录入接口的时间。在Apifox里做接口关联和Apifox的自动化套件功能对接是我比较推荐练的一条路线。创建一个自动化测试场景按顺序把登录、商品列表、加入购物车、下单这些接口加进去配置好数据传递规则比如把登录接口返回的token赋值给后续接口的AuthorizationHeader就能一键跑通完整业务链路。这其实就是最轻量级的接口自动化测试不用写一行代码。5.2 Postman核心技巧环境变量与断言管理如果你是先学Postman那环境管理和断言脚本是绕不开的两块。Postman里所有请求都必须建立在环境变量的基础上否则测试环境和生产环境切换时会非常痛苦。在慕慕生鲜项目里我建议创建两个环境local和dev。local对应本地环境baseUrl是http://localhost:8080dev对应测试服务器环境baseUrl换成测试服务器的IP或域名。两个环境只有baseUrl不同其他所有接口路径保持相对路径写法这样切换环境只需要改一个下拉框。写断言是Postman最有价值的地方。我一直认为没有断言的接口测试就不叫测试因为你只是用工具发了个请求然后用肉眼看了下返回这在自动化语境下毫无意义。最基础的断言至少包括状态码断言、业务状态码断言和关键字段断言三层// 第一层HTTP状态码断言 pm.test(HTTP状态码为200, function() { pm.response.to.have.status(200); }); // 第二层业务状态码断言 pm.test(业务状态码为200, function() { var jsonData pm.response.json(); pm.expect(jsonData.code).to.eql(200); }); // 第三层关键字段断言 pm.test(订单编号不为空, function() { var jsonData pm.response.json(); pm.expect(jsonData.data.orderNo).to.not.be.empty; });这三层断言分别验证了服务端是否正常响应、业务逻辑是否成功、返回值是否完整每一层都值得单独断言不要把不同层面的检查混在一起。5.3 JMeter并发测试动手模拟一场秒杀接口测试做到一定程度单接口的功能验证已经满足不了需求了你得想办法证明接口在并发情况下依然是稳定可靠的。慕慕生鲜的下单接口非常适合拿来练JMeter的并发测试因为下单涉及到库存扣减是天然的并发敏感操作。JMeter做并发测试的基本步骤是在测试计划中新建线程组配置线程数为50、Ramp-Up时间启动所有线程所需时间为2秒、循环次数为5这样就模拟了50个用户同时进行5轮操作添加HTTP请求把下单接口的路径、请求方式和请求体配置好由于下单接口需要登录态先在单独的一个HTTP请求里调用登录接口通过JSON提取器把token提取出来再用HTTP Header管理器在后续请求里传递这个token最后添加查看结果树和聚合报告运行后重点观察聚合报告里的响应时间、错误率和吞吐量。有一点必须特别注意如果你用同一批测试账号并发下单服务端可能因为同一用户并发操作而报错这是正常的不代表项目有Bug只能说明这个接口没有做用户维度的并发控制。真正要验证的是不同用户并发下单时库存数量扣减是否准确。怎么验证库存是否被正确扣减简单有效的做法是把并发请求数设置得略高于商品库存数比如商品库存是10件你让20个用户同时下单跑完后查看数据库里这个商品的库存字段。如果库存变成了0或负数说明接口存在超卖风险如果服务端在库存不足时正确返回了“库存不足”的提示说明并发控制做得到位。这个实验做完你对并发压力下接口测试的理解会比看十篇文章都深。6. 常见问题与排查技巧实录6.1 数据库连接报错怎么排查环境搭建阶段最常见的问题集中在数据库连接。启动后端服务时如果控制台报错Caused by: java.sql.SQLException: The server time zone value说明MySQL时区没设置正确在JDBC连接URL里加上serverTimezoneAsia/Shanghai就能解决。如果报错Access denied for user一般是你配置文件中数据库用户名或密码和你本地MySQL的实际账号不一致把application.yml里的spring.datasource.username和spring.datasource.password改成你MySQL的真实账号密码。还有一类问题是端口冲突控制台报错Port 8080 was already in use。用netstat -ano | findstr 8080命令Windows或lsof -i:8080命令Mac/Linux查出占用端口的进程杀掉对应进程或者干脆换个端口启动项目。6.2 请求返回数据与文档不一致怎么办这算是接口测试中非常有价值的一种情况。文档里写的是商品列表接口的响应data应该包含商品销量字段但实际返回里根本没有。有两个排查方向一是看服务端日志确认请求确实到了对应的Controller方法二是直接查数据库确认表里是否有这个字段。如果表里没有字段说明要么是数据库脚本版本不对要么是文档与代码已经不一致。遇到这种情况正确的处理是口头和开发确认后在接口文档或测试记录中标记为“文档待更新”或“疑似缺陷”。接口测试有一个很重要的产出物就是接口文档的正确性保障因为线上联调时前端和后端都依赖接口文档文档和代码不一致会引发大量沟通成本。6.3 登录接口成功但下单接口返回401只看现象的话很多人会认为是服务端鉴权有问题。但实际上90%的情况是token没有正确传递到下单接口。排查步骤有固定的顺序首先在登录接口响应里确认token是否真的返回了然后在Postman或Apifox里跳到下单接口的Headers页签看看Authorization字段的值到底是{{token}}字面量还是被正确替换成了真实token最后看变量的作用域如果登录接口里保存token的环境变量设置错了比如保存到全局变量但引用的是环境变量后面接口引用时自然取不到值。这个问题的排查思路本身就很有价值它教会了你做接口测试时要随时保持对数据流向的敏感。一旦某个接口返回鉴权失败优先检查前置接口的输出是否被正确传递到了当前接口的输入里。6.4 接口测试数据污染导致用例失败当你重复跑同一套接口用例时偶尔会遇到第一次成功第二次失败的情况。比如注册接口第一次用一个新手机号注册成功第二次再用同一个手机号注册服务端提示“手机号已存在”于是用例失败了。这类问题的根因不是接口Bug而是测试数据没有做好隔离属于用例设计层面的疏漏。解决办法有两个方向一是设计可重复执行的数据策略比如注册手机号采用时间戳动态生成的方式让每次运行都使用不同的手机号二是写好环境清理机制在测试执行前或执行后把生成的用户、订单等测试数据清理掉。在慕慕生鲜这个项目里批量删除数据用一条DELETE SQL就能搞定但对于大型项目必须考虑通过接口或管理后台操作来清理这条思路越早养成越好。我个人的习惯是把数据准备和数据清理直接写进自动化脚本的前置步骤和后置步骤里确保用例具备可重复执行的能力。这个能力是接口用例能不能纳入持续回归的关键指标。写在最后的几点心得慕慕生鲜这个项目前前后后我用它带过不少新人也用它自己做过技术复盘。我最大的感受是接口测试这件事项目的选择比努力更重要。一个好项目会让你自然地经历完整的测试思考过程读文档、理链路、找依赖、设计用例、跑接口、做断言、看结果、排查问题。这个过程走完一遍你收获的不只是会点几下Postman而是一整套接口测试的方法论。如果你刚接触接口测试不用急着把每个接口都测一遍先沿着“登录→查商品→加购物车→下单→支付”这条主线跑通再逐步扩展。等你把慕慕生鲜的接口全测过一遍再回头看自己最开始问的“接口测试怎么学”答案早就在你手上了。最后分享一个实用的小建议在慕慕生鲜项目里做接口测试时可以在本地新建一个txt文档专门记录每个接口的测试数据、预期结果和实际结果的差异。别小看这份记录它既是你的测试报告底稿也是你面试时最有说服力的项目输出物。很多人面试讲接口测试讲得空洞就是因为只有操作没有积累而这份记录就是你区别于其他候选人的地方。