若依框架接口测试实战：从登录到用户列表查询

1. 环境准备与工具选择为什么我推荐Apifox大家好我是老张在前后端联调和接口测试这块摸爬滚打十来年了。今天咱们不聊那些虚的架构设计就聊点实在的怎么快速上手把一个现成的开源后台管理系统——若依RuoYi的接口给测明白。很多新手朋友一听到“接口测试”就觉得头大又是抓包又是写脚本的其实没那么复杂。咱们今天的目标就一个从登录开始一路畅通无阻地拿到用户列表数据。工欲善其事必先利其器。我试过市面上不少接口测试工具Postman、JMeter、国产的Apifox、ApiPost都用过。最后为什么选择Apifox来演示呢原因很简单对新手友好功能集成度高。Postman固然强大但很多高级功能需要付费而且环境变量、文档管理对于刚接触的朋友来说有点复杂。Apifox把接口调试、文档生成、Mock数据、自动化测试都整合在了一起界面也更符合咱们国人的操作习惯。最关键的是它处理Cookie和Token这类鉴权信息非常直观这点在测试若依这种自带鉴权体系的框架时能省下不少功夫。当然工具只是手段核心是理解流程。你手头有Postman或者其他顺手的工具完全没问题操作逻辑都是相通的。在开始之前请确保你的若依后端服务已经跑起来了。我这里本地启动的地址是http://localhost:8081你的端口号可能是8080或者其他根据你自己的配置来。怎么判断服务启动成功了呢最简单的方法打开浏览器访问http://localhost:8081换成你的端口能看到若依的登录页面那就说明后端服务一切正常咱们可以开始动手了。2. 第一步搞定验证码——登录前的“敲门砖”若依框架为了安全默认的登录接口是必须携带图形验证码的。这算是我们测试路上的第一个小关卡。很多朋友在这一步就卡住了不知道这个验证码从哪里来怎么处理。别急我们一步步拆解。首先我们要明白一个关键点这个验证码不是让你用人眼去看然后手动输入的。那是给前端用户用的。我们做接口测试需要的是程序化地获取并传递验证码。若依框架很贴心地为我们提供了一个专门的接口来获取验证码信息。这个接口就是GET http://localhost:8081/captchaImage你用Apifox或者任何工具发送一个简单的GET请求到这个地址。你会收到一个JSON格式的响应大概长这样{ code: 200, msg: 操作成功, data: { captchaEnabled: true, uuid: f8c5d1d0e12a4c7a9b3c6d8e7f4a5b6c, img: data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7 } }这个响应体里藏着三个宝贝。第一个是captchaEnabled告诉你验证码功能是否开启默认是开的。第二个是uuid这是一个唯一标识符它是这次验证码会话的“身份证”后面登录时必须原样传回去服务器要靠它来核对你是刚才申请验证码的那个人。第三个是img一个Base64编码的图片字符串。这个图片就是图形验证码本身理论上你可以把它解码成图片看看内容但我们做自动化测试不需要。那么验证码的文本也就是图片上显示的“0”、“1”、“2”这些数字在哪里呢这里就是若依框架的一个设计特点验证码的答案并不在接口响应里直接返回而是存到了Redis里。Redis是一个内存数据库若依用它来临时存放“uuid”和对应的“正确验证码文本”。所以我们需要去Redis里根据刚才拿到的uuid值把对应的code找出来。怎么找如果你本地安装了Redis的桌面管理工具比如Another Redis Desktop Manager连接上本地的Redis服务就能在数据库里看到一个以captcha_codes:开头的键后面跟着的就是你的uuid。点进去它的值就是验证码文本。如果没有桌面工具也可以用命令行。打开终端输入redis-cli进入Redis命令行然后执行命令keys captcha_codes:*找到你的键再用get 你的完整键名获取值。这一步相当于拿到了登录的“临时密码”。3. 核心步骤登录接口与Token获取实战拿到了“敲门砖”uuid和“临时密码”验证码code现在我们就可以正式“敲门”了——调用登录接口。登录接口是几乎所有后续操作的基础因为它会返回一个至关重要的东西Token令牌。登录接口的地址是POST http://localhost:8081/login注意这是一个POST请求并且需要携带一个JSON格式的请求体Body。这个Body里就装着我们的登录凭证。根据若依框架的默认配置超级管理员的用户名是admin密码是admin123。那么我们构造的请求体应该是这样的{ username: admin, password: admin123, code: 0, uuid: f8c5d1d0e12a4c7a9b3c6d8e7f4a5b6c }这里要特别提醒一下username和password就是你的登录账号密码。code字段填的就是我们上一步从Redis里查出来的那个验证码文本比如可能是“0”、“1”、“2”这样的数字。这里是个大坑我见过不少新手朋友直接把接口响应里的code: 200的值填进去那肯定登录失败啊那个code是状态码不是验证码。uuid字段必须一字不差地填我们调用/captchaImage接口时返回的那个uuid值。请求体准备好后直接发送。如果一切参数正确你会收到一个成功的响应响应体里会包含一个token字段。这个Token就是一串长长的、看似乱码的字符串它是服务器颁发给你的“临时通行证”。在接下来的一段时间内Token有过期时间你访问其他需要权限的接口时只要出示这个Token服务器就认为你是合法用户。实测下来登录成功返回的数据结构类似这样{ code: 200, msg: 操作成功, data: { token: eyJhbGciOiJIUzUxMiJ9.eyJsb2dpbl91c2VyX2tleSI6IjJiZDI0ZjM0LTk5MzYtNGU2YS1iNjZhLTZjMzE4OWU2Y2Q2YSJ9.4X6qgL0sDx...很长的一串 } }请务必妥善保存这个token值我们马上就会用到它。你可以把它复制到Apifox的“环境变量”里或者暂时记在记事本上。至此最关键的登录环节就完成了我们已经拿到了通往若依系统内部数据的“钥匙”。4. 使用Token测试查询接口以用户列表为例好了通行证Token到手咱们可以去系统里“逛逛”了。我们来测试一个非常常见且有用的接口查询系统用户列表。这个接口通常用于管理系统中的用户信息。用户列表查询接口的地址是GET http://localhost:8081/system/user/list注意这是一个GET请求。但是如果你直接发送大概率会收到一个“401 Unauthorized”或者“未登录”的提示。为什么呢因为你没有告诉服务器你是谁没有出示你的通行证。在HTTP协议中携带Token最常用的方式就是通过请求头Headers。这里需要设置两个关键的请求头我把它做成表格更清晰参数名参数值说明AuthorizationBearer 你的token值这是核心。格式必须是“Bearer ”注意Bearer后面有个空格紧接着粘贴你的token。这种格式是JWT Token的标准携带方式。Content-Typeapplication/json告诉服务器我们请求和接收的数据格式是JSON。在Apifox里你可以在请求的“Headers”选项卡里一条条添加进去。设置好后再次发送GET请求到/system/user/list。这次你应该能收到一个成功的响应里面包含了用户列表的数据比如用户的ID、昵称、部门、创建时间等等数据量会比较多。但是等等如果你完全按照我上面说的只设置了这两个Headers可能会发现请求还是失败了提示“用户名或密码错误”。这是我曾经踩过的一个坑。若依框架的某些版本或配置下除了Token它还会非常隐晦地校验Cookie中的用户信息。特别是在前后端不分离的版本里这个机制更常见。那Cookie从哪里来呢还记得我们登录成功的响应吗仔细看响应头Response Headers里通常会有Set-Cookie字段服务器通过这个字段告诉浏览器或我们的测试工具设置一些Cookie。我们需要把这些Cookie特别是包含登录会话信息的在后续请求中原样带回去。一个更稳妥的Headers设置方案是让工具自动管理Cookie在Apifox或Postman中通常有一个开关叫“自动管理Cookie”或“Send cookies automatically”把它打开。这样工具会自动保存登录接口返回的Cookie并在后续请求中发送。手动添加Cookie如果自动管理失效如果自动管理不生效你就需要手动查看登录响应头中的Set-Cookie值然后手动在后续请求的Headers里添加一个Cookie字段其值就是那一长串字符串。终极方案手动构造关键Cookie若依框架有时会检查Cookie中名为username和password的值。这个password不是明文密码而是加密后的密文。超级管理员admin的默认密码密文是固定的$2a$10$7JB720yubVSZvUI0rEqK/.VqGOZTH.ulu33dHOiBE8ByOhJIrdAu2。你可以手动添加这样一个Cookie头Cookie: usernameadmin; password$2a$10$7JB720yubVSZvUI0rEqK/.VqGOZTH.ulu33dHOiBE8ByOhJIrdAu2所以一个能确保成功的用户列表查询请求其Headers至少应该包含Authorization: Bearer eyJhbGci...你的tokenContent-Type: application/json可选但推荐Cookie: usernameadmin; password密文或由工具自动管理的Cookie当这些都配置正确后你就能成功获取到用户列表的JSON数据了。这个过程虽然有点繁琐但一旦跑通你就掌握了测试若依框架所有受保护接口的通用方法。5. 常见问题排查与实战技巧分享走通了整个流程是不是感觉有点成就感了别急在实际项目中你肯定会遇到各种各样的问题。我把这些年测试若依接口时踩过的坑和解决方法总结一下希望能帮你少走弯路。第一个常见问题登录总是返回“验证码错误”。这是最高频的错误。请按以下顺序检查uuid不匹配确保登录请求Body里的uuid和之前调用/captchaImage拿到并存入Redis的那个uuid是完全一致的。每次获取验证码都会生成新的uuid不能混用。验证码已过期Redis里的验证码是有有效期的默认2分钟。如果你动作太慢验证码失效了自然就会报错。重新调用/captchaImage获取一套新的。Redis里没有对应的键检查一下Redis里到底有没有以captcha_codes:开头后面跟着你的uuid的键。没有的话说明获取验证码的请求可能就没成功或者数据没存进去。Code值取错了再次确认你从Redis取出的值是填到登录Body的code字段而不是响应状态码。第二个问题有了Token访问接口还是返回“未授权”或“登录超时”。Token格式错误检查Authorization头的值是不是严格遵循了Bearer token的格式中间有空格。Token已过期JWT Token是有过期时间的若依默认大概2小时。过期后需要重新登录获取新的Token。Cookie缺失正如前面强调的尝试在Headers里补上Cookie信息。这是很多朋友忽略的关键点。接口地址或方法错误确认你调用的接口地址和HTTP方法GET/POST/PUT/DELETE是否正确。可以去查看若依的Swagger文档如果开启了的话通常访问http://localhost:8081/swagger-ui.html或者后端代码确认。第三个问题如何高效管理这些参数在Apifox里我强烈建议使用环境变量功能。你可以创建一个“本地若依测试”环境然后定义变量比如base_url:http://localhost:8081token: (登录后把值粘贴到这里)username:adminpassword_md:$2a$10$7JB720yubVSZvUI0rEqK/.VqGOZTH.ulu33dHOiBE8ByOhJIrdAu2这样在接口地址里你就可以写成{{base_url}}/login在Authorization头里写成Bearer {{token}}在Cookie里写成usernameadmin; password{{password_md}}。一劳永逸切换环境也方便。最后再分享一个进阶技巧编写自动化测试脚本。在Apifox的“测试”标签里你可以用JavaScript写一些断言脚本。比如在登录接口的测试脚本里你可以添加// 检查状态码是否为200 pm.test(Status code is 200, function () { pm.response.to.have.status(200); }); // 检查响应体里包含token pm.test(Response has token, function () { var jsonData pm.response.json(); pm.expect(jsonData.data.token).to.be.a(string).that.is.not.empty; // 将获取到的token设置为环境变量供后续接口使用 pm.environment.set(token, jsonData.data.token); });这样每次运行登录接口不仅能自动测试是否成功还能自动把新的Token更新到环境变量里后续接口直接用实现了真正的自动化测试流。从单次的手动调试到可重复、可验证的自动化流程这才是接口测试效率提升的关键。希望这些实实在在的步骤和经验能帮你把若依框架的接口测试玩转起来。