Redfish接口测试实战：用Postman搞定BMC用户、网络与电源管理

Redfish接口测试实战：用Postman搞定BMC用户、网络与电源管理

发布时间：2026/10/21 18:49:16
Redfish接口测试实战：用Postman搞定BMC用户、网络与电源管理 1. Redfish接口到底解决了什么问题为什么要用Postman去测它做服务器运维和硬件管理的朋友应该都有感触以前管理BMC基板管理控制器基本靠IPMI命令行那一套ipmitool敲来敲去功能还算齐全但每次要写批量脚本、对接自动化平台的时候就很痛苦。命令行解析麻烦不同厂商的BMC实现细节还不一样真出问题排查起来光对着满屏十六进制输出就够喝一壶的。后来Redfish标准推出核心思路很明确用一套统一的RESTful API来管理服务器硬件资源用标准JSON表达操作走标准HTTP方法GET/POST/PATCH/DELETE语义清晰和云平台、自动化框架对接起来非常自然。Redfish的生态已经很成熟了现在的服务器BMC固件基本都内置了Redfish服务端口默认443认证走Basic Auth或者Session登录。你需要做的就是有一套趁手的工具去把这些接口调起来、跑通、验证。Postman在这方面确实比命令行顺手得多——图形化界面、环境变量管理、断言脚本、批量跑测试集合都是日常硬件接口联调里高频用到的能力。这篇文章写给谁我觉得有两类人最合适一类是刚接触Redfish、想知道怎么用Postman把BMC的常见操作串起来的运维新手另一类是已经在用Redfish但每次都是临时拼命令想沉淀一套可复用测试集合的自动化工程师。文里的完整用例主要围绕BMC用户管理、网络配置、电源控制这三块展开这三块是日常服务器管理里最常碰到的需求。先把基础架子搭好后面往存储、事件推送、固件升级方向扩展思路是一样的。2. 搭建Postman测试集合前先搞懂这几个关键概念2.1 Redfish的三层资源模型Redfish接口的路径设计很有规律根路径是/redfish/v1下面的资源按服务根 → 资源集合 → 具体资源的层次组织。比如/redfish/v1/Systems是服务器系统集合/redfish/v1/Systems/{id}是具体某一台服务器的系统资源。如果要管理系统里的电源路径大概是/redfish/v1/Systems/{id}/Power或者通过/redfish/v1/Chassis/{id}下的Power子资源访问。不同厂商在细节上有差异但都遵循DMTF定义的标准模型。刚开始接触的时候不用急着背路径先发一个GET /redfish/v1看看返回的JSON里有哪些链接顺着Links和Members一路点下去整个资源树就清楚了。Postman里可以把这些响应里返回的URL直接手动拼成新请求也可以后续用脚本自动提取前期手动摸索更快。2.2 认证方式Basic Auth还是SessionRedfish标准支持Basic认证和Session登录两种主流方式。Basic认证最简单每个请求头带Authorization: Basic base64(用户名:密码)适合快速验证接口通不通。但实际项目里我不推荐长期用Basic因为每次请求都要带明文密码虽然走HTTPS还好但日志里很容易留下痕迹也不利于权限回收。Session登录是更规范的做法先POST /redfish/v1/SessionService/Sessions请求体带上用户名密码服务端返回的响应头里会有X-Auth-Token后续请求带上这个Token就行用完通过DELETE删掉Session。Postman里可以用环境变量存Token登录接口里写脚本自动提取后面所有请求都引用这个变量非常方便。注意用Session认证时登录接口的响应体里通常会返回一个Id字段对应Session资源路径删除Session时要拿这个路径构造DELETE请求。有些BMC厂商对异常结束的Session有超时回收机制但显式删除更稳妥我见过不少环境里Session泄漏导致连接数满的情况。2.3 Postman环境变量的设计思路Redfish接口测试集合里环境变量就是整个集合的配置中心。建议至少规划这几个变量bmc_ipBMC的管理IP地址bmc_user登录用户名bmc_pass登录密码base_url协议加IP比如https://192.168.1.10所有请求直接用{{base_url}}拼接auth_tokenSession登录后自动写入system_id服务器系统资源的ID大多数厂商都是1但不要写死登录后通过查询动态获取更保险chassis_id机箱资源的ID电源管理通常要到这里环境变量分Global和Environment两层我的习惯是IP、账号密码放EnvironmentToken这种动态值也放EnvironmentPostman有脚本可以一键写入。别把密码放进Global因为切环境时容易误带到别的环境去。还有一个细节因为BMC的HTTPS证书基本都是自签的Postman里要在设置里关掉SSL证书校验或者单独导入BMC的CA证书。关校验在联调阶段最省事但正式环境建议还是把证书处理好避免安全扫描时被揪出来。3. 开始动手建立Postman测试集合的基础框架3.1 创建集合和目录结构打开Postman新建一个Collection名字就叫Redfish BMC测试集合之类的。集合下面按资源模块建文件夹推荐这样组织_00_ServiceRoot服务根、版本信息查询_01_AuthSession登录、注销_02_Systems系统资源查询、电源管理_03_Chassis机箱资源、温度风扇、电源状态_04_AccountServiceBMC用户管理_05_Network网络接口、IP配置_06_Utils辅助脚本、批量操作文件夹名字前面加序号方便排序跑起来也清晰。每个请求的命名要能一眼看出在做什么比如查询所有用户列表而不是叫GetAccounts就算完团队协作时中文命名对非开发背景的运维同事更友好。3.2 配置全局变量和集合级脚本集合建好之后点开Collection的Variables页签先定义好环境变量名的默认值。再到Authorization页签里可以把认证方式统一配置成Bearer Token或者Basic Auth。我个人建议用脚本统一处理Token见下面的做法。集合级有两个脚本入口Pre-request Script和Tests。Pre-request适合做如果Token不存在就先登录这种前置判断Tests适合做每个请求跑完后统一记录响应时间、日志输出这类动作。Redfish这种接口联调场景我在集合级Tests里会写一段通用脚本// 统一记录响应状态 const resp pm.response.json(); if (pm.response.code 400) { console.log(请求失败: pm.request.url); console.log(JSON.stringify(resp, null, 2)); } pm.test(响应码可接受, function() { pm.expect(pm.response.code).to.be.oneOf([200, 202, 204]); });这段脚本不针对某个接口它让每次跑测试集合时只要有个别请求返回异常第一时间就能从测试报告里看到失败信息。后面写具体用例时再在请求级别补充更细的断言。3.3 登录请求和Token自动写入在_01_Auth文件夹里新建一个请求方法POSTURL填{{base_url}}/redfish/v1/SessionService/Sessions。Body选raw JSON内容{ UserName: {{bmc_user}}, Password: {{bmc_pass}} }Headers里加一个Content-Type: application/json。发送后看响应正常情况下返回201 Created响应头里能找到X-Auth-Token响应体里能看到Id字段。接着在Tests里写Token提取逻辑const token pm.response.headers.get(X-Auth-Token); if (token) { pm.environment.set(auth_token, token); } const sessionId pm.response.json().Id; if (sessionId) { pm.environment.set(session_id, sessionId); }顺手把session_id也存起来因为注销时要用到。注销请求是DELETE {{base_url}}/redfish/v1/SessionService/Sessions/{{session_id}}成功返回204。登录这一步是整个集合的地基后面所有请求只要在Headers里加X-Auth-Token: {{auth_token}}即可。Postman里可以在Collection的Authorization页签里选Bearer Token直接填{{auth_token}}但我更喜欢显式加Header因为有些BMC实现用的是X-Auth-Token而不是标准Bearer显式控制更稳。3.4 动态发现系统ID和机箱ID前面说的system_id不建议写死因为不同厂商默认值不一样有的是1有的是一长串UUID。写一个自动发现的脚本更省心请求GET {{base_url}}/redfish/v1/Systems在Tests里处理const data pm.response.json(); const members data.Members; if (members members.length 0) { const firstMemberUrl members[0][odata.id]; const systemId firstMemberUrl.split(/).pop(); pm.environment.set(system_id, systemId); }Chassis同理请求GET {{base_url}}/redfish/v1/Chassis把第一个成员的ID存成chassis_id。这两个动态变量弄好之后电源管理、温度查询这些接口的URL都可以拼成/redfish/v1/Systems/{{system_id}}/Actions/...换任何一台BMC都能直接跑。4. BMC用户管理完整用例从查询到权限控制4.1 查用户列表和用户详情用户管理是BMC安全运维的重点Redfish里对应的资源是AccountService。先看整体结构GET {{base_url}}/redfish/v1/AccountService返回里会有Accounts的链接这才是用户集合。查列表GET {{base_url}}/redfish/v1/AccountService/Accounts返回的Members数组里每个元素就是一条用户记录。正常情况至少有一个管理员账号。断言脚本可以这样写pm.test(用户列表返回正常, function() { pm.expect(pm.response.code).to.eql(200); const data pm.response.json(); pm.expect(data.Members.length).to.be.at.least(1); });单个用户详情根据列表里某个用户的odata.id直接GET比如/redfish/v1/AccountService/Accounts/admin。详情里包含UserName、RoleId、Enabled、Locked等字段。Locked这个字段很重要账号被锁定后这里能看到。还有Password字段通常是null因为出于安全考虑接口不会返回用户密码。有些厂商会在Links里给出Role的链接方便你跳转查询角色权限定义。4.2 创建用户用例创建一个新用户要用POST到/redfish/v1/AccountService/AccountsBody示例{ UserName: ops_test, Password: Test12345, RoleId: Operator, Enabled: true }这里有几个坑要提前说RoleId不是随便填的必须是BMC本身支持的角色。常见的自定义角色名比如Administrator、Operator、ReadOnlyUser具体看AccountService返回里的Roles链接或者直接GET每个Role资源确认。填一个不存在的角色名大概率返回400。密码策略因厂商而异有的要求至少8位、必须含大小写和数字有的要求12位以上。建议创建前先GET一下AccountService看返回里有没有MinPasswordLength这类字段。创建成功一般返回201响应头里带Location指向新用户资源的URL。这个响应头可以用脚本提取后面要改密码或者删用户时直接用。创建用例的断言建议加两条pm.test(创建用户成功, function() { pm.expect(pm.response.code).to.eql(201); }); pm.test(响应Location头存在, function() { const loc pm.response.headers.get(Location); pm.expect(loc).to.not.be.undefined; pm.environment.set(new_user_url, loc); });把新用户资源的URL存到环境变量里后续改密码、禁用、删除都能直接引用不需要再拼路径。4.3 修改用户属性和密码Redfish里更新资源用PATCH注意不是PUT。区别是PATCH允许只传要修改的字段PUT通常要求传完整资源。绝大多数厂商实现只支持PATCH做部分更新。改密码的请求PATCH {{base_url}}/redfish/v1/AccountService/Accounts/{{username}}{ Password: NewPass6789 }改角色和状态可以合并成一个请求{ RoleId: ReadOnlyUser, Enabled: false }PATCH成功后一般返回200或者204响应体可能是更新后的资源也可能是空的这个看厂商实现断言里不要对响应体做太强假设只要状态码对就行。实操提醒改完密码之后如果这个用户是当前登录会话使用的账号部分BMC会强制注销当前Session导致后续请求全部401。测试集合里如果改的是登录账号的密码记得把环境变量bmc_pass同步更新然后重新跑一遍登录请求。4.4 禁用、删除和批量造数据删除用户用DELETE /redfish/v1/AccountService/Accounts/{{username}}成功返回204。有的厂商不允许删除最后一个管理员账号这是正常的保护逻辑别在测试环境里硬删。批量创建测试用户是联调时的高频需求。比如要建10个用户验证并发登录逐个手点太累可以写个Pre-request脚本循环创建。这里分享一个思路写一个独立的请求在Tests里用pm.sendRequest循环POST到Accounts接口for (let i 1; i 10; i) { const createReq { url: pm.environment.get(base_url) /redfish/v1/AccountService/Accounts, method: POST, header: { Content-Type: application/json, X-Auth-Token: pm.environment.get(auth_token) }, body: JSON.stringify({ UserName: test_user_ i, Password: Test12345, RoleId: Operator, Enabled: true }) }; pm.sendRequest(createReq, function(err, res) { console.log(创建 test_user_ i - res.code); }); }这样一条请求就能批量造数据配合后面的批量删除脚本测试完一键清理环境保持干净。5. 网络管理完整用例IP配置、DNS和VLAN操作5.1 查看网络接口和当前配置BMC网络这块Redfish路径集中在/redfish/v1/Managers/{manager_id}/EthernetInterfaces。第一步先确认manager_id和前面一样建议动态获取请求GET {{base_url}}/redfish/v1/Managers取第一个成员的ID存成manager_id。然后请求GET {{base_url}}/redfish/v1/Managers/{{manager_id}}/EthernetInterfaces返回的Members数组就是BMC的网口列表。注意一个细节BMC通常有多个网口但其中一个才是管理口怎么识别看接口详情里InterfaceEnabled是否为true、LinkStatus是否为LinkUp以及有没有配置有效的IPv4地址。有的厂商会在Name字段里直接标注管理口。查看单个网口的详情GET /redfish/v1/Managers/{{manager_id}}/EthernetInterfaces/eth0返回里通常有IPv4Addresses数组里面能看出Address、SubnetMask、Gateway这些关键信息。还有NameServersDNS服务器地址、VLAN如果启用了VLAN功能以及MACAddress、PermanentMACAddress。5.2 修改静态IP、网关和DNS——可能踩的大坑改IP配置是网络管理里最刺激的操作因为改完当前连接可能就断了。请求结构PATCH /redfish/v1/Managers/{{manager_id}}/EthernetInterfaces/{{interface_id}}{ DHCPEnabled: false, IPv4Addresses: [ { Address: 192.168.10.55, SubnetMask: 255.255.255.0, Gateway: 192.168.10.1 } ] }这个请求发出去之后如果IP真的换了当前Postman这个连接理论上应该断开。实际操作中分两种情况如果修改的IP和现在Postman连的是同一个响应可能直接超时这是预期内的别慌如果BMC有两个网口改的是另一个口当前连接不会断可以继续发请求验证。发这个请求前务必做两件事一是确认这台BMC的带外网口连接的是哪个网络改错IP会把自己的管理通道弄丢二是准备一个串口或者第二网络路径防止改完彻底失联。注意DHCPEnabled这个字段有些厂商在IPv4Addresses里也允许放DHCPEnabled: true两者表达的含义不完全一样。稳妥做法是先在接口详情里根据当前实际值做探测再决定PATCH哪些字段。修改DNS配置的Body长这样{ NameServers: [114.114.114.114, 8.8.8.8] }要注意的是有些厂商的DNS和IPv4Addresses在同一个PATCH请求里可以一起改有些则要求分开如果400了就把两个字段拆成两次PATCH。响应正常是200或204。5.3 VLAN配置用例不少机房场景要求BMC的管理口走VLAN网络。Redfish里VLAN配置在网口资源的VLAN字段下PATCH /redfish/v1/Managers/{{manager_id}}/EthernetInterfaces/{{interface_id}}{ VLAN: { VLANEnable: true, VLANId: 100 } }VLANEnable控制开关VLANId是VLAN号范围1到4094。改VLAN同样是断连高危操作如果当前网络就是走的这个口启用了VLAN但交换机那边没配好连接直接断掉只能带外恢复。建议的验证流程是先GET确认接口当前VLAN状态再PATCH配置最后重新GET确认。有些厂商在VLAN配置后网口会重新协商链路LinkStatus短暂显示为Down再恢复Up这是正常现象。自动化测试里可以加一个逻辑配置完成后轮询接口状态直到LinkStatus恢复LinkUp再继续后续操作。批量操作多个网口时逐个配置并等待稳定不要并发PATCH同一个Manager很容易把BMC的网络协议栈搞出问题。5.4 网络用例的常见断言和回归检查网络配置相关的测试脚本建议监听这些点状态码200或204拒绝400/500。IPv4信息存在响应里IPv4Addresses的长度大于等于1且Address字段不是空字符串。DHCP状态符合预期改完之后DHCPEnabled是false。VLAN状态如果配置了VLANVLANEnable为trueVLANId等于设定值。连接可用性配置完成后再发一个最轻量的GET /redfish/v1请求确认服务还在这个动作比什么都实在。6. 电源管理完整用例开机、关机、重启和状态查询6.1 电源状态查询接口服务器电源管理是Redfish里最常用、也最需要谨慎操作的部分。先说查询GET /redfish/v1/Systems/{{system_id}}返回的JSON里有一堆字段其中PowerState就是当前的电源状态典型的取值有On、Off、PoweringOn、PoweringOff。注意有些厂商还有DiagnosticMode之类的扩展状态查询时留意一下。更细的电源数据在GET /redfish/v1/Chassis/{{chassis_id}}/Power里这里面有PowerControl数组记录功耗、功耗上限、电源冗余状态PowerSupplies数组记录每个电源模块的型号、输入输出功率、健康状态Voltages和Temperatures也常挂在Chassis下。监控脚本里定期拉这个接口比看BMC网页快得多。6.2 开机、强制关机和优雅关机Redfish控制电源走的是Actions每个厂商支持的动作可能略有不同但标准动作都覆盖了。先看系统资源详情里Actions字段能直接看到厂商支持哪些动作不用猜。常见的动作路径和请求体开机POST /redfish/v1/Systems/{{system_id}}/Actions/ComputerSystem.ResetBody填{ResetType: On}。优雅关机{ResetType: GracefulShutdown}相当于软关机给操作系统时间正常关闭。强制关机{ResetType: ForceOff}相当于硬断电慎重用。重启{ResetType: GracefulRestart}或{ResetType: ForceRestart}。强制重启{ResetType: ForceRestart}不优雅但响应快。发送后一般返回204可以先GET /redfish/v1/Systems/{{system_id}}轮询PowerState确认状态真的切换了。风险提示强制关机会导致操作系统非正常退出有损坏文件系统的风险。自动化用例里如果包含ForceOff最好只在测试机上跑。生产环境的电源操作要有独立的审批流程Postman集合可以做到提示确认但流程上的把关还得靠人来。6.3 电源操作后的状态轮询电源操作和网络操作一样是异步的请求返回204不代表电源已经到位。需要一个轮询函数。Postman里可以用环境变量循环请求的方式模拟轮询或者简单一点用手动重试脚本// 发送Reset请求后在Tests里轮询PowerState const systemUrl pm.environment.get(base_url) /redfish/v1/Systems/ pm.environment.get(system_id); pm.sendRequest({ url: systemUrl, method: GET, header: { X-Auth-Token: pm.environment.get(auth_token) } }, function(err, res) { const state res.json().PowerState; console.log(当前电源状态: state); pm.test(电源状态已切换, function() { pm.expect(state).to.eql(On); }); });例如从Off到On有些服务器整个过程要一两分钟单次轮询不够建议结合定时任务跑Collection。Postman的Collection Runner支持配置迭代次数和延迟时间配合环境变量里保存状态快照可以实现接近脚本的效果。如果是对接CI/CD流水线更推荐用Newman跑集合后边会提到。6.4 电源按钮模拟和指示灯控制除了Reset动作有些BMC还支持模拟物理电源按钮。这个动作不是所有厂商都支持还是先看Actions字段里有没有。如果有路径类似/redfish/v1/Systems/{{system_id}}/Actions/ComputerSystem.PowerButtonBody里填PushType: Press或PushType: PressAndHold对应短按和长按长按等效强制关机。日常脚本里这个动作不常用但当你面对一个系统卡死、操作系统连RESET都不响应时这个动作可能是救命的。还有一类常见操作是识别指示灯PATCH /redfish/v1/Systems/{{system_id}}设置IndicatorLED字段为Lit或Blinking用来在机柜里快速定位机器。这个操作安全无害非常适合做Redfish接口的入门验证因为就算发错了也不会造成什么实际影响。6.5 写一套完整的电源管理自动化流程把上面的用例组合起来可以形成一套自动化流程登录并获取Token前置请求。查询当前电源状态并记录到环境变量。发送GracefulShutdown等待PowerState变成Off。发送On等待PowerState变成On。查询Chassis/Power里的功耗和电源模块健康状态。清理Session注销登录。这套流程在测试机上可以全自动跑在真实生产服务器上建议抽出其中步骤让运维手动确认。Postman里把每个步骤拆成独立请求并放到同一个文件夹Collection Runner按顺序执行。跑完之后看报告哪些请求耗时长短、哪些断言失败一眼就能定位。7. 常见问题排查与进阶技巧7.1 证书校验、认证失败和路径错误Redfish联调阶段常见的问题我列一个表遇到直接对照处理现象可能原因排查方法请求返回SSL错误BMC自签证书不受信任Postman设置里关闭SSL校验或导入BMC证书401 UnauthorizedToken过期、密码错误、账号被锁重新登录检查环境变量里的账号密码404 Not Found资源路径不对、ID写死错误先GET服务根沿Members动态获取ID400 Bad Request请求体字段或角色名不合法对照该资源的Entity schema检查看Actions字段405 Method Not Allowed用错了HTTP方法确认是PATCH还是POSTRedfish里规范更新用PATCH其中404最常见的诱因就是system_id写死了1厂商A没问题换厂商B就404。所以不断强调动态获取ID就是这个道理。7.2 PATCH返回400的深层排查Redfish的PATCH看起来简单但细节很多。我遇到过一个情况修改IPv4地址时把IPv4Addresses数组里的Address改成新IP但忘了同时传原来的SubnetMask结果厂商实现要求整个数组字段必须完整直接400。排查方法很简单先手动GET当前完整配置把原有字段原样保留只修改目标字段再PATCH一次能避免绝大多数400。另外注意PATCH和POST的语义差异。资源创建用POST资源部分更新用PATCH资源整体替换用PUT但Redfish标准里没有普遍使用PUT绝大多数厂商也不会支持直接用PATCH就行。7.3 大规模自动化用Newman跑出测试报告Postman图形界面适合交互式调试但真正要集成到CI或者定时跑巡检Newman是更好选择。把集合导出成JSON文件环境变量单独导出然后命令行执行。基本用法newman run redfish_bmc_collection.json \ -e bmc_test_env.json \ -n 3 \ --delay-request 2000 \ --reporters cli,json \ --reporter-json-export report.json-n 3是迭代三次--delay-request 2000是请求间加2秒延迟跑完把JSON报告喂给下游监控系统。电源操作这种扫描型请求加延迟是必须的不然BMC的web服务都可能被拖垮。7.4 集合健壮性设计前置脚本、后置清理与数据隔离最后讲讲集合健壮性设计这一点对长期维护特别重要。分几层来看第一层请求间的依赖管理。Redfish集合里很多请求依赖环境变量比如登录后的Token、动态发现的系统ID。我建议在每个请求的Pre-request脚本里加一个关键变量存在性检查不存在就直接抛异常避免脚本跑到一半才发现Token没拿到。const token pm.environment.get(auth_token); if (!token) { throw new Error(auth_token未设置请先执行登录请求); }第二层测试环境隔离。BMC测试和真实机房环境一定要用不同的Environment配置Postman里Environment就是干这个的。测试环境可以随便做破坏性操作生产环境只做只读查询。我的做法是生产环境变量命名加_prod后缀Collection里凡是有写操作PATCH/POST/DELETE的请求在Pre-request里都检查环境名后缀不是测试环境就弹确认框防止手滑点错。第三层数据清理。批量造的用户、改过的IP和密码测试完了必须恢复。我习惯在集合末尾放一个清理文件夹专跑DELETE用户、恢复IP配置这些操作每次跑完测试集合后顺手跑一遍保证BMC还有下一批人能用。第四层日志记录。Postman的Console能实时打日志但跑完就没了。我把关键操作的结果都用console.log输出之外还在Tests里拼了文本存到环境变量比如每次操作的时间、对象、结果定期导出来做运维审计这也是Redfish相对IPMI在可观测性上的一个优势。这些细节都做到位之后这个Postman集合就不再是一堆手工请求的堆砌而是一个可以放心重复跑、能交到团队其他成员手里的自动化资产。我个人的体会是Redfish的入门门槛其实不高难的是把一套接口用例做成换了任何一台机器都能稳定跑的状态。第一次搭集合可以从单个系统查询开始慢慢加认证、加用户管理、加网络和电源控制。每个模块跑通后再考虑合并成完整流程。这套模式我在多个项目里复用过效果一直很稳定。最后再分享一个小技巧把这套集合的导出文件放进公司内部的代码仓库做版本管理改了用例就有记录出了问题上一个版本能立刻拉回来比在Postman云端里瞎改踏实得多。