若依项目-接口测试这个系列上一篇我们解决了最基础的登录鉴权、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应为0rows为空数组。这里我想强调一点分页接口测试的断言不能只看接口有没有返回200一定要去校验返回结构里的total总数。我在项目中就遇见过列表总数错误的问题rows只有一页数据时看着是正常的但把total和数据库实际记录数一对比发现总数比实际多出很多原因是查询SQL里关联了角色表导致多表关联产生重复记录而分页count查询没做去重。这种问题如果不校验total单看列表数据根本发现不了。3.2 排序、SQL注入与字段白名单若依的列表接口一般支持orderByColumn和isAsc两个参数分别指定排序列和升降序。这里有两个测试重点。第一排序字段是否支持传多个列。若依前端默认传一个列名和一个排序方向但接口层面最好验证“传两个排序列”时参数是否能正确解析不会因逗号分割问题产生SQL异常。第二排序字段的SQL注入风险。虽然PageHelper对orderByColumn做了基础的处理但不同项目二次开发时写法不同我会专门用orderByColumnuser_id;drop table xxx、orderByColumn1 desc--这类载荷去测。规范的实现应该对排序字段做白名单校验或参数转义不规范的实现很可能直接拼接进SQL。这是接口安全测试里非常值得跑的一个用例风险极高。顺便说一句若依的isAsc参数在较新版本中已经支持多排序方向形如isAscasc,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里的业务提示。我见过不少测试脚本因为只断言了code200把校验失败这种明显不正确的行为误判成了通过。4.3 编辑与删除接口状态流转和级联逻辑编辑接口测试的重点是修改后的数据能否被查询接口正确返回、编辑时是否校验被修改字段的关联关系比如改部门父级时不允许把父级改成自己的子级、并发编辑时后提交是否覆盖先提交的数据。删除接口测试要注意的更多。以部门删除为例若依的业务规则是存在子部门时不允许删除存在用户时也不允许删除。测试用例要覆盖删一个没有任何子级和用户的部门、删一个带子部门的部门、删一个带用户的部门、批量删除混合有效和无效ID的部门。每次删除后都要去查询接口里确认对应数据确实不存在。这里我遇到过最典型的问题是企业项目二次开发的“逻辑删除”改造。原来若依的部门删除是物理删除后来有些项目为了数据安全改成逻辑删除添加了del_flag字段。改造完之后问题出现了删除部门接口返回成功但列表查询接口查不到数据因为查询条件自动拼了del_flag0。如果测试脚本不确认删除接口之后数据状态这个行为很难被发现。正确的断言应该是用数据库查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速查表下面这张表是我做若依接口测试过程中积累的高频问题分类遇到类似问题可以照这个思路去查症状可能原因排查方向所有接口返回401token未携带、token过期、Redis中token被清除检查请求头Authorization检查token有效期配置检查Redis是否设置了清理策略个别接口返回403当前角色没有对应权限标识检查角色的菜单分配检查PreAuthorize注解权限编码是否匹配返回code500参数错误、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全部错误。这些回归问题靠人肉测试很难全量覆盖但自动化跑一遍十几分钟就出结果。写到这里关于若依项目接口测试的第二篇内容就分享得差不多了。最后说点个人体会。接口测试做到后面真正拉开差距的不是工具熟练度而是能不能构建一套可持续复现的测试逻辑数据怎么准备、权限怎么设计、断言怎么覆盖、异常怎么排查。我在好几个项目里都见过类似的情况——接口测试文档写了厚厚一叠但实际执行时全靠手工点用例之间互相依赖数据一脏就跑不出结果。所以我个人强烈建议从第一天做接口测试就建立数据前缀规范和清理脚本宁可前期多花点时间也不要让测试数据成为后患。若依项目本身给开发者提供了很完整的权限体系和统一响应结构这其实是接口测试的天然好底子把它测透比只调通接口有价值得多。