Redfish接口测试避坑指南：Postman中处理Session、ETag和If-Match的那些事儿-编程实验室

Redfish接口测试避坑指南：Postman中处理Session、ETag和If-Match的那些事儿

当你第一次尝试用Postman测试Redfish接口时，可能会觉得一切都很简单——发送请求，获取响应，任务完成。但当你真正开始处理复杂的服务器管理任务时，那些隐藏在HTTP头中的小细节就会突然变成拦路虎。本文将带你深入Redfish接口测试中最容易踩坑的三个关键点：Session管理、ETag机制和If-Match头的正确使用。

1. Session管理：不只是获取Token那么简单

几乎所有Redfish接口测试教程都会告诉你如何获取X-Auth-Token，但很少有人会解释为什么你的Token突然失效了。让我们从一个真实的场景开始：

上周，我们的测试团队遇到了一个奇怪的问题——在连续测试30分钟后，所有请求突然开始返回401未授权错误。经过排查，我们发现Redfish服务的Session超时设置是30分钟，而我们的测试脚本没有处理这个情况。

正确的Session管理应该包含以下步骤：

获取Token时，同时记录响应中的Session超时时间（通常在响应头的X-Auth-Token-Timeout字段）
在Postman的Tests脚本中添加超时检查逻辑：

// 获取Token并设置全局变量 const token = pm.response.headers.get("X-Auth-Token"); const timeout = parseInt(pm.response.headers.get("X-Auth-Token-Timeout")) || 1800; // 默认30分钟 pm.globals.set("X-Auth-Token", token); pm.globals.set("Token-Expiry", new Date().getTime() + timeout * 1000); // 在后续请求的Pre-request Script中添加检查 const now = new Date().getTime(); if (now > pm.globals.get("Token-Expiry")) { pm.sendRequest({ url: pm.variables.get("deviceip") + "/redfish/v1/SessionService/Sessions", method: "POST", header: { "Content-Type": "application/json" }, body: { mode: "raw", raw: JSON.stringify({ UserName: pm.variables.get("username"), Password: pm.variables.get("password") }) } }, (err, res) => { if (!err) { const newToken = res.headers.get("X-Auth-Token"); const newTimeout = parseInt(res.headers.get("X-Auth-Token-Timeout")) || 1800; pm.globals.set("X-Auth-Token", newToken); pm.globals.set("Token-Expiry", new Date().getTime() + newTimeout * 1000); } }); }

常见错误：

假设Token永远不会过期
没有处理Token失效后的自动刷新
在并发测试中重复使用同一个Token导致冲突

2. ETag和If-Match：资源版本控制的守护者

Redfish使用ETag和If-Match头来实现乐观并发控制，这是防止多个客户端同时修改同一资源导致数据不一致的关键机制。但很多测试工程师直到遇到409 Conflict错误才开始重视它们。

ETag的工作原理：

当你GET一个资源时，服务器会在响应头中返回ETag（通常是资源的哈希值或版本号）
当你尝试修改(PATCH/PUT)该资源时，必须在请求头中包含If-Match字段，其值为之前获取的ETag
服务器会比较当前资源的ETag和你提供的If-Match值：
- 如果匹配，执行修改并返回200 OK
- 如果不匹配，返回412 Precondition Failed

在Postman中实现自动化ETag处理：

// 在GET请求的Tests脚本中捕获ETag const etag = pm.response.headers.get("ETag"); if (etag) { pm.globals.set("Resource-ETag", etag); } // 在PATCH/PUT请求的Headers中自动添加If-Match // 在Pre-request Script中添加： const etag = pm.globals.get("Resource-ETag"); if (etag) { pm.request.headers.add({ key: "If-Match", value: etag }); }

实际案例：BIOS设置修改

假设你要修改服务器的启动顺序，正确的流程应该是：

首先获取当前BIOS设置：

GET /redfish/v1/Systems/1/Bios/Settings

从响应头中捕获ETag
发送修改请求时带上If-Match头：

PATCH /redfish/v1/Systems/1/Bios/Settings Headers: If-Match: "a1b2c3d4" Body: { "Attributes": { "BootTypeOrder0": "HardDiskDrive", "BootTypeOrder1": "DVDROMDrive" } }

常见错误：

忘记先获取ETag就直接尝试修改
在长时间运行的测试中，ETag可能已经过期但没有重新获取
没有正确处理412 Precondition Failed响应

3. 并发测试中的陷阱与解决方案

当你需要模拟多个用户同时操作服务器时，Redfish的并发控制机制会带来一些意想不到的行为。以下是我们在压力测试中积累的经验：

问题1：Token冲突当多个测试线程使用同一个Token时，可能会导致服务器拒绝请求或意外注销Session。

解决方案：

为每个测试线程创建独立的Session
在Postman中使用环境变量隔离不同线程的Token

问题2：ETag竞争当多个线程同时获取和修改同一资源时，可能会出现"丢失更新"问题。

解决方案：

// 实现重试逻辑 const maxRetries = 3; let retryCount = 0; function modifyResource() { // 1. 获取最新ETag pm.sendRequest({ url: pm.variables.get("resource_url"), method: "GET", headers: { "X-Auth-Token": pm.globals.get("X-Auth-Token") } }, (err, res) => { if (err || !res.headers.get("ETag")) { if (retryCount++ < maxRetries) { setTimeout(modifyResource, 1000); return; } pm.test("Failed to get ETag after retries", () => {}); return; } // 2. 尝试修改 const etag = res.headers.get("ETag"); pm.sendRequest({ url: pm.variables.get("resource_url"), method: "PATCH", headers: { "X-Auth-Token": pm.globals.get("X-Auth-Token"), "If-Match": etag, "Content-Type": "application/json" }, body: { mode: "raw", raw: JSON.stringify(pm.variables.get("patch_body")) } }, (patchErr, patchRes) => { if (patchErr || patchRes.code === 412) { if (retryCount++ < maxRetries) { setTimeout(modifyResource, 1000); return; } pm.test("Failed to modify after retries", () => {}); return; } // 修改成功 }); }); } modifyResource();

4. 高级技巧：自动化测试集合设计

为了将上述知识转化为可重复使用的测试方案，我们设计了以下Postman测试集合结构：

1. 初始化阶段

创建独立Session
获取系统基本信息
设置全局变量（超时时间、基础URL等）

2. 资源准备阶段

创建测试用户
配置网络设置
获取当前BIOS设置

3. 并发测试阶段

// 示例：并发修改用户权限测试 const users = ["admin", "operator", "readonly"]; const threads = []; users.forEach((role) => { threads.push(new Promise((resolve) => { // 每个线程有自己的Session pm.sendRequest({ url: pm.variables.get("base_url") + "/SessionService/Sessions", method: "POST", body: { mode: "raw", raw: JSON.stringify({ UserName: pm.variables.get("username"), Password: pm.variables.get("password") }) } }, (err, res) => { if (err) { resolve(false); return; } const threadToken = res.headers.get("X-Auth-Token"); // 获取用户ETag pm.sendRequest({ url: pm.variables.get("user_url"), method: "GET", headers: { "X-Auth-Token": threadToken } }, (getErr, getRes) => { if (getErr) { resolve(false); return; } // 尝试修改 pm.sendRequest({ url: pm.variables.get("user_url"), method: "PATCH", headers: { "X-Auth-Token": threadToken, "If-Match": getRes.headers.get("ETag"), "Content-Type": "application/json" }, body: { mode: "raw", raw: JSON.stringify({ RoleId: role }) } }, (patchErr, patchRes) => { resolve(!patchErr && patchRes.code === 200); }); }); }); })); }); // 等待所有线程完成 Promise.all(threads).then((results) => { pm.test("All threads completed", () => { pm.expect(results.every(Boolean)).to.be.true; }); });

4. 清理阶段