若依项目-接口测试这个系列，上一篇我们解决了最基础的登录鉴权、Token获取和用户信息核对，算是把接口测试的门票拿到了手里。但说实话，业务接口测试和登录态测试完全不是一个量级——登录通了只是入场，真正值钱的是把权限控制、数据隔离、分页边界、异常链路这些细节全部验证到位。这一篇我打算聚焦实战：若依项目里业务接口究竟怎么测、权限和数据范围怎么设计测试场景、测试数据要如何准备和清理，以及我把这些接口跑了一圈之后踩过的那些坑。适合已经能手动调通若依接口、想进一步把测试做深做透的开发者，也适合正准备给项目搭接口自动化测试的同学参考。
1. 接口测试从调通到验证，差的是思路不是工具
1.1 若依项目接口测试的三个层次
先给一个总体的判断。很多人做接口测试，第一步是开postman、apifox，把接口调通，看到返回200就觉得自己测完了。这只能算最浅的一个层次。我在接触多个若依项目之后，把接口测试分成三个层次。
第一层，调通。验证接口是否存在、请求能否成功、鉴权是否生效。这一层最基础，通常花不了多少时间。
第二层，业务逻辑验证。验证接口的行为是否符合业务规则。比如新增用户时用户名重复会不会被拦截，编辑部门时父级部门能不能选自己，删除角色时引用该角色的用户会怎么处理。这些都涉及参数校验、状态流转、唯一性约束和业务依赖关系。
第三层，安全边界验证。验证接口在权限和数据范围上的表现。比如A部门的管理员能不能查到B部门的数据，普通用户能不能直接通过拼接URL拿到管理端接口的数据，删除接口能否被越权调用。这一层是若依这类后台管理系统最值得测、也最容易出问题的地方。
大多数接口测试做不好，不是工具不会用，而是思路停留在第一层。后面所有小节，我都会围绕第二层和第三层展开。
1.2 登录态只是入场券，数据准备才是分水岭
登录态相关的内容，上一篇已经写过，这里简单回顾一个点：若依项目的登录流程通常涉及验证码、用户名密码校验，登录成功后会返回一个token，后续请求需要在请求头中带上Authorization: Bearer <token>。这个token的有效期默认是30分钟，配置在application.yml的token.expireTime字段。实测下来，token快过期时接口会返回401，这时候需要重新登录获取新token。
但真正让我觉得接口测试开始变难的是数据准备。很多业务接口不是独立存在的，而是强依赖关系链。你测试新增用户，得有部门、角色、岗位数据打底；你测试编辑用户的接口，得先有一条用户记录；你测试删除部门，得考虑部门下是否还有用户或子部门。如果这些数据靠手工在界面上点，效率极低，而且容易污染正式环境。我的做法是分三类准备：
- 静态基础数据：像数据字典类型、系统参数配置、部门树结构，测试前一次性准备，整个测试周期内基本不变。
- 动态业务数据：每次测试前按需创建，命名统一加可识别前缀，例如
test_dept_、test_user_，方便后续回溯和清理。 - 临时边界数据：专门用来测各种边界和异常场景的，比如超长字符串、负数分页、不存在的部门ID，用完即清。
这些数据准备的思路，是保证接口测试可持续复现的前提。没有数据准备和清理方案，接口测试做一次两次还可以，做几十个用例之后必然乱套。
2. 权限与数据隔离：若依接口测试最容易踩的深水区
2.1 方法级权限的测试设计
若依的权限控制基于RBAC模型，核心是角色-菜单-权限标识的关联关系。在接口层，权限控制通常通过@PreAuthorize注解实现，典型的写法是@PreAuthorize("@ss.hasPermi('system:user:list')")。也就是说，每个敏感接口都会绑定一个权限标识，当前登录用户所拥有的角色如果没有包含这个权限标识，请求就会被拦截，返回403。
测试时，我们的核心目标是验证权限拦截的有效性。这里最忌讳的做法是只用超管账号把接口跑一遍就结束——这样做等于完全没有测试权限。我习惯这样设计权限测试矩阵：
- 超管账号：应能访问全部接口，响应结果是业务处理后的正常数据。
- 授权角色账号：只拥有目标接口对应的权限标识，访问应成功。
- 未授权角色账号：拥有其他模块的权限，但不包含目标接口的权限标识，访问应返回403。
- 完全无权限账号：只登录但不绑定任何业务角色，访问应返回403。
- 匿名请求：不携带token直接访问，返回401。
这套矩阵跑下来，基本能把“有没有做好接口权限校验”这个问题测清楚。很多项目的漏洞就出在某个内部管理接口忘记加注解，结果权限矩阵一测就暴露了。
另外提醒一点，@PreAuthorize里的权限校验是方法级别的，但若依在部分接口的按钮级控制上还会结合前端v-hasPermi指令做显隐控制。这个属于前端验证，后端接口测试必须绕过前端直接测接口，才能验证真正的后端防线。
2.2 数据权限：同一份接口代码，不同人看到不同数据
如果说方法级权限是“能不能访问”，数据权限就是“访问到哪些数据”。若依的数据权限通过@DataScope注解实现，在业务SQL中动态拼接过滤条件。数据范围主要分五档：全部数据权限、自定义数据权限、本部门及以下数据权限、本部门数据权限、仅本人数据权限。
我在测试数据权限时遇到过最典型的bug是这样的：同一个“用户列表”接口，用部门A的管理员登录，理应只能看到部门A及其子部门下用户的数据；但实际返回结果中把全部用户都带出来了。排查发现是SQL中@DataScope拼接的条件没有生效，因为数据范围配置本身是取当前用户角色里的data_scope字段，而测试账号的角色数据范围没有配置正确。这类问题用“同接口、多账号、对比结果”的方式非常好定位。
具体操作上，我会准备一个部门结构相对清晰的测试环境，比如：总公司下有华东分部，华东分部下有上海团队和杭州团队。然后为每个层级各造一个管理账号，分别测试同一接口：
- 总公司管理员：应看到所有部门数据。
- 华东分部管理员：应看到华东、上海、杭州的数据。
- 上海团队负责人：仅能看到上海团队的数据。
- 如果角色配置为“仅本人”，则只返回自己创建或所属自己的记录。
跑完这些用例之后，用结果集和预期对一遍，数据权限的边界立刻一清二楚。这里我强烈建议把“越权访问”当成一等测试用例去设计，而不是只测“权限之内”的正常路径。比如用上海团队负责人的账号，尝试通过接口的deptId参数直接指定华东分部的ID去查询数据，看后端是否无视数据权限直接返回。若依的设计里@DataScope应该会自动拼接过滤条件，保证无论如何都查不出范围外的数据；但如果实现有漏洞，这种越权查询极容易发生。
2.3 实测案例：用户管理模块的权限测试
拿若依项目里最常见的“用户管理”模块举例。涉及的接口有：用户列表查询、获取用户详情、新增用户、编辑用户、删除用户、重置密码、修改状态。每个接口都有对应的权限标识，比如system:user:list、system:user:query、system:user:add、system:user:edit、system:user:remove。
我一般会把用例写成一张测试矩阵表，横轴是接口，纵轴是不同角色账号，字段为“预期状态码/预期行为”。实践下来的核心结论是：
- 用户列表查询，每个角色的返回数据集必须严格符合其数据范围。
- 新增用户，无
add权限返回403；有权限但未配置部门时，部门下拉框相关逻辑可能报错。 - 编辑用户，最容易被忽略的是修改角色时是否校验“当前用户能否分配高权限角色”，若依在分配角色时建议用
checkUserAllowed和checkRoleAllowed做了控制，这个也要测。 - 删除用户，需要验证不能删除当前登录用户、不能删除超级管理员，而且批量删除时部分ID不存在的处理逻辑。
这些细节，文档里不会全写出来，但接口测试恰恰需要把每个业务规则固化成断言。
3. 列表接口的分页、排序与条件组合测试
3.1 分页参数：别以为pageNum传1就完事
若依的分页是基于PageHelper实现的，在Controller层通过startPage()方法启动分页，然后MyBatis的查询自动追加LIMIT语句。分页参数是pageNum和pageSize。测试分页接口，我建议至少覆盖下面这些场景：
- 第1页、第2页、第3页的切换，验证数据不重复、不遗漏。
pageSize取边界值，比如1、10、50，以及超过默认上限的大值。pageNum传0、负数、非数字、超大值。这里的预期行为是：PageHelper对pageNum小于1的情况通常会修正为1，但具体行为要看项目有没有做参数校验，如果项目里写了@NotNull和@Min注解，行为就不同。- 最后一页再往后翻一页，返回的列表应为空，但
total保持不变。 - 筛选条件不命中任何数据，返回的
total应为0，rows为空数组。
这里我想强调一点：分页接口测试的断言，不能只看接口有没有返回200，一定要去校验返回结构里的total总数。我在项目中就遇见过列表总数错误的问题，rows只有一页数据时看着是正常的，但把total和数据库实际记录数一对比，发现总数比实际多出很多，原因是查询SQL里关联了角色表导致多表关联产生重复记录，而分页count查询没做去重。这种问题如果不校验total，单看列表数据根本发现不了。
3.2 排序、SQL注入与字段白名单
若依的列表接口一般支持orderByColumn和isAsc两个参数，分别指定排序列和升降序。这里有两个测试重点。
第一，排序字段是否支持传多个列。若依前端默认传一个列名和一个排序方向，但接口层面最好验证“传两个排序列”时参数是否能正确解析，不会因逗号分割问题产生SQL异常。
第二，排序字段的SQL注入风险。虽然PageHelper对orderByColumn做了基础的处理，但不同项目二次开发时写法不同，我会专门用orderByColumn=user_id;drop table xxx、orderByColumn=1 desc--这类载荷去测。规范的实现应该对排序字段做白名单校验或参数转义，不规范的实现很可能直接拼接进SQL。这是接口安全测试里非常值得跑的一个用例，风险极高。
顺便说一句，若依的isAsc参数在较新版本中已经支持多排序方向，形如isAsc=asc,desc，如果项目升级过框架版本，这里也是回归测试的重点。
3.3 条件组合查询：从单条件到多条件的排列组合
列表接口通常支持多个查询条件，常见的有状态、时间范围、关键字模糊搜索、部门等。组合查询的测试思路不是把所有组合都跑一遍——组合数量是指数级的，不现实。我的做法是先测每个单条件的正确性，再测2~3个高频组合场景，最后测“全条件叠加”场景。
以操作日志查询接口为例，条件包括：操作人、操作模块、操作类型、状态、开始时间、结束时间等。我会先单独测每个条件：比如只按操作人查，返回的数据里操作人字段都应该匹配；只按时间范围查，返回数据的时间字段都应该落在范围内。然后测组合：操作人+操作模块+时间范围。实测中发现过一个经典bug：只传beginTime不传endTime时，接口直接报错或返回全部数据，因为SQL里对时间范围做了BETWEEN x AND y拼接，而空值没有单独处理。
时间范围测试还有一个坑：若依的前端组件传的时间通常精确到毫秒，而后端处理有时会丢精度，导致查询结果边界不对。比如查询结束时间设为2024-12-31 23:59:59，如果接口内部用字符串直接拼接，数据库里2025-01-01 00:00:00的记录也可能被包含进来。这个细节在完工后的验收测试阶段特别容易爆发。
4. 增删改接口的完整实操：以部门管理为蓝本
4.1 数据准备与清理规范
增删改接口的测试很讲究执行顺序，因为每条测试用例会改变系统状态。我用的典型流程是：初始化数据->执行操作->断言结果->数据清理。每个步骤都要有明确的脚本或接口调用，而不是靠手工点。
以部门管理为例，我会在数据库中直接插入测试部门数据，也可以调用“新增部门”接口来制造数据。两种方式各有优劣：
- 数据库直插：效率高、不受权限限制，适合批量准备基础数据。但绕过接口后无法验证接口本身的幂等性和状态流转。
- 接口创建：模拟真实用户操作，能顺带验证新增逻辑。但需要为每个前置条件准备父部门等数据，链路较长。
实际项目中我通常是混用的：用直插准备静态基础数据，用接口调用准备动态业务数据。清理数据时统一用SQL删除或通过接口删除，优先选择接口删除，这样数据清理动作本身还能再回归一次删除接口。
4.2 新增接口测试：规则比200重要
一个合格的新增接口测试，至少覆盖以下断言：
- 必填字段缺失时返回提示信息，HTTP状态码可能是200，但业务返回码是500或自定义错误码。这里注意不能只断言HTTP状态码，若依的业务响应统一放在
code字段里，HTTP状态码通常始终是200。 - 字段长度、类型、格式校验，比如手机号格式、邮箱格式、状态字符枚举。
- 唯一性校验，用户名、部门名称等字段重复时应有明确错误提示。
- 父子关系合法性，新增部门时父部门ID必须存在且不能是自身。
特别值得说明的是若依的业务错误层级。它封装了统一返回结果，异常会通过全局异常处理器捕获，返回AjaxResult对象，结构为{code: 500, msg: "操作失败", data: null}。但校验类异常可能返回{code: 500, msg: "岗位编码已存在"}这样的提示。这就意味着断言时不能只看code等于200就判通过，而是要认真核对msg里的业务提示。我见过不少测试脚本因为只断言了code==200，把校验失败这种明显不正确的行为误判成了通过。
4.3 编辑与删除接口：状态流转和级联逻辑
编辑接口测试的重点是：修改后的数据能否被查询接口正确返回、编辑时是否校验被修改字段的关联关系（比如改部门父级时不允许把父级改成自己的子级）、并发编辑时后提交是否覆盖先提交的数据。
删除接口测试要注意的更多。以部门删除为例，若依的业务规则是存在子部门时不允许删除，存在用户时也不允许删除。测试用例要覆盖：删一个没有任何子级和用户的部门、删一个带子部门的部门、删一个带用户的部门、批量删除混合有效和无效ID的部门。每次删除后都要去查询接口里确认对应数据确实不存在。
这里我遇到过最典型的问题是企业项目二次开发的“逻辑删除”改造。原来若依的部门删除是物理删除，后来有些项目为了数据安全改成逻辑删除，添加了del_flag字段。改造完之后问题出现了：删除部门接口返回成功，但列表查询接口查不到数据，因为查询条件自动拼了del_flag=0。如果测试脚本不确认删除接口之后数据状态，这个行为很难被发现。正确的断言应该是：用数据库查del_flag的变化，或者用“获取部门详情”接口验证返回的是否是“已删除”状态提示。
4.4 实操流程实录：从Apifox到回归用例
下面分享一套我用Apifox组织增删改接口测试的实际流程，可操作性强，照着做就能上手。
第一步，新建一个接口测试文件夹，按模块分目录，例如“部门管理”。文件夹内按“新增-查询-编辑-查询-删除-确认”的顺序排列用例。
第二步，在环境变量里配置基础请求参数，包括baseUrl和token。在登录接口所在的分组里，编写一条在测试套件运行前自动执行的登录用例，把返回的token写入环境变量。
第三步，新增部门用例：请求参数用测试数据标识，比如部门名称用“测试部门_20250120_001”。断言部分需要同时验证：code等于200、返回的data包含新部门ID、再次查询部门列表时新部门出现在第一页或能被查询条件命中。
第四步，编辑部门用例：修改名称和排序，断言修改后的数据被查询接口正确返回。
第五步，删除用例：先删除一个无子级的部门，验证成功；再删除一个前面新建的、包含子级的部门，验证返回对应的失败提示。
第六步，清理用例：把数据库里所有名称带测试部门_前缀的脏数据统一清理掉，防止影响后续测试。
这套流程跑下来，部门管理的接口行为就被完整覆盖了。而且Apifox的测试记录可以随时回放，每次回归只要改一下环境变量重新执行就行。
5. 异常链路与并发场景：接口测试的另一半战场
5.1 重复提交和幂等性测试：后端不设防就是灾难
前端框架很容易做到点击一次后禁用按钮，但接口测试必须绕过前端防护，直接模拟重复提交。最直接的方式是在短时间窗口内对同一个新增接口发送两次完全相同的请求。如果第二次返回创建成功，就说明接口没有做幂等控制。真实业务中用户网络抖动导致前端重试时，重复创建的风险就真实发生了。
测试时我一般先发一次正常请求记录返回ID，然后立刻再发一次相同payload的请求。预期结果有两种：好的实现是第二次请求被拦截，返回“数据已存在”提示；一般的实现是返回创建成功，但会暴露设计缺陷。另一个相关的场景是并发注册相同用户名的账号，如果数据库对用户名字段没有唯一索引，并发请求就会创建出多条同名记录。这个可以通过JMeter或脚本并发调用验证。
5.2 Token失效、刷新与并发token的坑
Token失效处理是接口自动化测试最常用的场景。若依默认token有效期30分钟，测长链路时很容易在用例执行中途遇到401。我的做法是在测试脚本里做“401后自动重新登录”的逻辑：当响应为401时，调用登录接口获取新token，把环境变量更新后重放失败请求。
但这里有一个更隐蔽的坑：如果测试脚本并发执行，多个线程同时检测到401，会同时发起登录请求，各自拿到不同的新token写入环境变量，导致部分请求用的token和登录会话不匹配。解决方法是把token更新过程加锁，或者干脆在测试前预估用例执行时间，提前统一刷新token。
另外，若依在新版本中支持“token续期”。如果登录后一直有请求在调用，token过期时间会动态延长。如果只停留在这个机制上不做处理，测试时长超过30分钟的用例集就会随机失败。实测下来的经验是：不要把token失效完全寄托在续期上，长用例集要么拆分成可以独立登录的短任务，要么在测试入口统一重新登录。
5.3 事务回滚与数据一致性验证
若依的Service层默认有事务管理，批量删除、批量导入等接口一旦中途出错应该整体回滚。测试这类接口时，我会人为构造一个必然出错的数据项，混在正常数据中间，然后观察批量操作结果：如果接口报错，数据库里正常的那部分数据是否也被回滚了；有没有出现“部分成功、部分失败”但返回码仍然是成功的情况。
一个典型的测试用例是批量导入用户：准备10条用户数据，其中第8条故意写成手机号格式错误。符合预期的行为是导入失败，全部10条都不落库；如果导入接口返回了“存在N条成功”的信息而数据库里只有前7条数据时，就说明接口对“部分成功”的处理不符合预期。这类问题在生产环境很常见，因为业务方无法接受用户导入后还要手动核对哪些成功了哪些失败了。
6. 常见问题与排查技巧实录
6.1 高频Bug速查表
下面这张表是我做若依接口测试过程中积累的高频问题分类，遇到类似问题可以照这个思路去查：
| 症状 | 可能原因 | 排查方向 |
|---|---|---|
| 所有接口返回401 | token未携带、token过期、Redis中token被清除 | 检查请求头Authorization；检查token有效期配置；检查Redis是否设置了清理策略 |
| 个别接口返回403 | 当前角色没有对应权限标识 | 检查角色的菜单分配；检查@PreAuthorize注解权限编码是否匹配 |
| 返回code=500 | 参数错误、SQL异常、空指针 | 看后端日志堆栈；检查参数类型和格式 |
| 列表total和实际数量不一致 | 查询SQL多表关联产生重复记录 | 检查count语句是否去重；检查关联条件 |
| 分页数据错乱 | 排序字段缺失或默认排序不稳定 | 给SQL增加稳定的order by聚合字段 |
| 删除后数据仍可查询 | 逻辑删除未过滤 | 检查del_flag拼装条件；检查有无查询接口漏加过滤 |
| 新增返回成功但查不到 | 事务没提交或写错表 | 用数据库直接查记录；检查数据源指向 |
| 批量操作部分失败无提示 | 事务未整体回滚 | 检查Service事务注解；检查批量SQL执行策略 |
6.2 日志与数据库：用后端日志定位接口问题
接口测试如果只看着响应体猜原因，效率很低。我通常把后端日志和数据库查询作为左膀右臂。若依项目里可以临时打开MyBatis的SQL日志打印，在application.yml中把对应mapper包的日志级别调整为debug，这样每次接口调用都会输出实际执行的SQL。配合日志排查，很多问题能一眼定位：分页SQL的limit是否正确拼接，数据权限的过滤条件有没有加到where子句里，逻辑删除条件到底有没有带出来。
数据库侧我习惯在测试环境用数据库客户端开一个查询窗口，随时盯着测试数据的增删改状态。接口请求结束之后，立刻手动执行一条SELECT确认数据落库与否，比反复看接口响应靠谱得多。
6.3 从手工测试到自动化回归
接口测试做到最后，一定会走向自动化回归。对于若依项目，我建议用Apifox或Postman等工具先把接口用例沉淀下来，结构上按模块建目录、按场景写断言、用环境变量管理token和服务器地址。维护一段时间后，可以接入CI流程，在代码提交后自动触发接口回归，发现接口行为异常时由流水线通知相关开发者。
自动化回归的价值，在于每次后端改动都可能波及关联接口。我最常遇到的是改了一个权限标识名称，导致所有引用该标识的接口403；或者改了一个查询SQL，导致另一个模块的列表total全部错误。这些回归问题靠人肉测试很难全量覆盖，但自动化跑一遍十几分钟就出结果。
写到这里，关于若依项目接口测试的第二篇内容就分享得差不多了。最后说点个人体会。接口测试做到后面，真正拉开差距的不是工具熟练度，而是能不能构建一套可持续复现的测试逻辑：数据怎么准备、权限怎么设计、断言怎么覆盖、异常怎么排查。我在好几个项目里都见过类似的情况——接口测试文档写了厚厚一叠，但实际执行时全靠手工点，用例之间互相依赖，数据一脏就跑不出结果。所以我个人强烈建议，从第一天做接口测试就建立数据前缀规范和清理脚本，宁可前期多花点时间，也不要让测试数据成为后患。若依项目本身给开发者提供了很完整的权限体系和统一响应结构，这其实是接口测试的天然好底子，把它测透，比只调通接口有价值得多。
