Postman接口测试自动化：Cookie自动携带实现与实战指南

1. 项目概述：为什么我们需要自动携带Cookie？

在接口测试的日常工作中，登录验证是绕不开的第一道坎。无论是测试一个电商系统的下单流程，还是验证一个内容管理系统的权限控制，你几乎总是需要先“登录”进去。对于手工测试，我们可以在浏览器里点点鼠标，输入账号密码，然后浏览器会帮我们记住那个叫做“Cookie”的小东西，后续的请求就畅通无阻了。但到了自动化测试，尤其是在Postman这类工具里，事情就变得有点棘手。

很多新手，甚至一些有经验的测试同学，都曾卡在这个环节：第一个登录接口调通了，返回了Set-Cookie头，看着状态码200很高兴。但紧接着调用第二个需要登录态的接口时，直接就返回了401未授权或者跳转到登录页。问题出在哪？Postman并没有像浏览器那样，自动将上一个请求响应的Cookie，附加到下一个请求的Header里。这个“自动”的动作，需要我们通过脚本去实现。

这就是“自动携带Cookie”的核心价值：模拟浏览器的会话保持行为，让一系列相关的接口测试能够像真实用户操作一样连贯执行。它解决的不仅仅是“登录”这一步，更是解决了后续所有依赖登录状态的接口测试的自动化前提。没有它，你的接口集合（Collection）就无法真正实现一键运行，每次可能都得手动去复制粘贴那一长串的Cookie值，效率低下且容易出错。

2. 核心思路拆解：Cookie的流转与自动化捕获

要实现自动携带，我们首先要理解Cookie在HTTP请求中的生命周期。它本质上是一小段由服务器发送到客户端（浏览器或Postman）的文本信息，客户端会将其存储起来，并在后续向同一服务器发起请求时自动附加上去。

2.1 Cookie从哪来，到哪去？

1. 来源：当服务器验证用户身份成功后（比如登录接口），会在HTTP响应头（Response Headers）中通过Set-Cookie字段下发一个或多个Cookie。例如：Set-Cookie: sessionId=abc123; Path=/; HttpOnly。
2. 存储：客户端（如Postman）接收到这个响应后，会解析Set-Cookie头，并将Cookie值（如sessionId=abc123）存储在其内部的Cookie Jar（Cookie罐）中，同时记录该Cookie的域名（Domain）、路径（Path）等属性。
3. 携带：当客户端后续再向同一域名、且路径匹配的服务器发起请求时，会自动从Cookie Jar中取出对应的Cookie，并将其添加到请求头（Request Headers）的Cookie字段中。例如：Cookie: sessionId=abc123。

2.2 Postman的“半自动”与我们的“全自动”

Postman本身具备基础的Cookie管理能力，即它有自己的Cookie Jar。如果你在Postman中直接访问一个网站并登录，它也能记录Cookie。但问题在于，当我们通过脚本（Pre-request Script 或 Tests）来驱动接口调用时，特别是当登录接口返回的Cookie需要被后续接口使用时，Postman的默认行为并不总是如我们所愿。

我们的目标，是通过编写脚本，主动地、可靠地完成“捕获登录响应Cookie” -> “存储或设置为全局变量” -> “为后续请求自动添加Cookie头”这个流程，从而实现无缝的、可复现的自动化登录测试链。

2.3 方案选型：环境变量与脚本联动

在Postman中，实现数据传递和持久化的核心是环境变量（Environment Variables）和全局变量（Global Variables）。我们的方案将围绕它们展开：

• 捕获阶段：在登录接口的“Tests”标签页中，编写JavaScript脚本，从响应中提取Cookie，并将其存入一个环境变量（如auth_cookie）。
• 应用阶段：在后续所有需要登录态的接口的“Pre-request Script”标签页中，编写脚本，从上述环境变量中读取Cookie值，并动态地将其设置为当前请求的Header。

这个方案的优势在于清晰、灵活、可维护。环境变量可以随着不同的测试环境（开发、测试、生产）切换，而脚本逻辑是通用的。它避免了硬编码，也使得我们的接口集合可以在不同用户、不同环境下共享和运行。

3. 实操准备：环境搭建与脚本基础

在开始编写核心脚本之前，我们需要做好一些准备工作，确保Postman环境处于最佳状态。

3.1 创建与管理测试环境

强烈建议为你的项目创建一个专属的测试环境，而不是使用全局变量。这样更利于管理。

1. 在Postman右上角，点击眼睛图标旁边的下拉菜单，选择“Add”。
2. 输入环境名称，例如“My_API_Test_Env”。
3. 在下方表格中，我们可以预先添加一些变量，比如base_url（基础地址）、username、password（如果不想明文存储密码，可以在脚本中通过其他方式获取或使用占位符）。对于Cookie，我们暂时留空，让脚本运行时填充。
4. 创建完成后，务必在右上角下拉菜单中选中这个新环境，这样我们的脚本才能正确读写其中的变量。

3.2 理解Postman的脚本沙盒

Postman的脚本运行在Node.js风格的沙盒环境中，它内置了许多强大的库，比如pm对象、cheerio（用于解析HTML）、lodash等。我们最需要熟悉的是pm对象，它提供了访问请求、响应、变量、测试结果的完整API。

• pm.response：获取响应对象。pm.response.headers获取响应头，pm.response.json()获取JSON格式的响应体。
• pm.request：获取请求对象。可以修改请求头、请求体等。
• pm.environment和pm.globals：用于管理环境变量和全局变量。pm.environment.set("key", "value")用于设置，pm.environment.get("key")用于获取。
• pm.test：用于编写测试断言。
• pm.cookies：Postman提供的Cookie操作对象，但有时直接操作Set-Cookie头更直接。

3.3 创建接口集合与示例接口

1. 创建集合（Collection）：新建一个集合，命名为“用户业务流测试”。集合可以添加文件夹，用于归类接口，比如“认证”、“用户信息”、“订单”。
2. 添加登录接口：在“认证”文件夹下，新建一个请求。
   • 方法：POST
   • URL：{{base_url}}/api/login(使用环境变量)
   • Body：选择raw->JSON，填入{"username": "{{username}}", "password": "{{password}}"}
   • 在“Tests”标签页，我们将编写捕获Cookie的脚本。
3. 添加一个需要登录的接口：例如“获取用户信息”。
   • 方法：GET
   • URL：{{base_url}}/api/user/profile
   • 在“Pre-request Script”标签页，我们将编写添加Cookie头的脚本。

准备工作就绪，接下来进入核心环节。

4. 核心脚本实现：捕获、存储与应用Cookie

这是整个自动化的心脏部分。我们将分三步，实现完整的Cookie流转。

4.1 在登录接口的Tests中捕获并存储Cookie

登录接口成功调用后，我们需要在其“Tests”标签页编写脚本，从响应头中提取Cookie。

// 登录接口的 Tests 脚本 // 1. 验证登录是否成功（可选但推荐） pm.test("登录成功", function () { pm.response.to.have.status(200); var jsonData = pm.response.json(); pm.expect(jsonData.code).to.eql(0); // 假设业务码0表示成功 }); // 2. 核心：从响应头中获取Cookie // 注意：响应头中的Cookie字段可能是`set-cookie`（小写），Postman的`pm.response.headers`对象对头名称大小写不敏感，但返回的可能是数组。 var cookieHeader = pm.response.headers.get('Set-Cookie'); // 如果服务器返回了Cookie if (cookieHeader) { // 打印一下看看，调试用 console.log("原始Set-Cookie头：", cookieHeader); // 处理Cookie字符串。一个Set-Cookie头可能包含多个Cookie，用逗号分隔，但更常见的是多个Set-Cookie头。 // 这里我们处理一个简单场景：假设只有一个主要的会话Cookie。 // 我们需要从`sessionId=abc123; Path=/; HttpOnly; Max-Age=3600`这样的字符串中提取出`sessionId=abc123`。 // 方法：分割字符串，取第一个分号前的部分 var cookiePairs = cookieHeader.split(';'); var sessionCookie = cookiePairs[0].trim(); // 得到 "sessionId=abc123" // 3. 将Cookie存储到环境变量中 pm.environment.set("auth_cookie", sessionCookie); console.log("已将会话Cookie存储到环境变量 auth_cookie: ", sessionCookie); // 你也可以存储完整的Cookie头，但后续使用可能需要额外处理 // pm.environment.set("full_cookie_header", cookieHeader); } else { console.warn("登录响应中未找到Set-Cookie头，请检查接口实现。"); // 或者尝试从响应体中获取token（如果是Token方案） }

注意：实际场景中，Cookie可能非常复杂，包含多个键值对（如sessionId,userId,token等），并且可能有多个Set-Cookie头。上述脚本是一个基础示例。对于复杂情况，你可能需要循环遍历pm.response.headers，过滤出所有Set-Cookie头，然后进行拼接和处理。

4.2 在需要认证的接口的Pre-request Script中应用Cookie

对于“获取用户信息”这类需要登录态的接口，我们在其“Pre-request Script”标签页中编写脚本，动态添加Cookie头。

// 需要认证接口的 Pre-request Script 脚本 // 1. 从环境变量中获取之前存储的Cookie var storedCookie = pm.environment.get("auth_cookie"); // 2. 检查Cookie是否存在 if (storedCookie) { // 3. 将Cookie添加到当前请求的Header中 // 注意：这里使用`pm.request.headers.upsert`，如果已存在Cookie头则更新，不存在则添加。 pm.request.headers.upsert({ key: 'Cookie', value: storedCookie }); console.log("已为请求添加Cookie头: ", storedCookie); } else { console.error("环境变量 auth_cookie 为空，请先运行登录接口。"); // 可以选择让请求失败，或者继续执行（请求可能会返回401） // pm.expect(storedCookie).to.not.be.empty; // 使用断言让测试失败 }

4.3 使用集合级脚本进行全局管理

如果集合内很多接口都需要这个Cookie，在每个接口都写一遍Pre-request Script会很冗余。Postman允许在集合（Collection）级别和文件夹（Folder）级别添加脚本，这些脚本会在集合内每个请求运行前（Pre-request）或运行后（Tests）执行。

这是一个更优雅的方案：

1. 点击你的集合“用户业务流测试”右侧的“...”，选择“Edit”。
2. 切换到“Pre-request Scripts”标签页。
3. 将上面“应用Cookie”的脚本移到这里。这样，集合下的所有请求在发送前，都会自动尝试添加Cookie。

// 集合级别的 Pre-request Script var storedCookie = pm.environment.get("auth_cookie"); if (storedCookie) { pm.request.headers.upsert({ key: 'Cookie', value: storedCookie }); } // 注意：这样会为所有请求添加Cookie，包括登录请求本身（此时auth_cookie为空，所以没影响）。 // 但如果某些接口（如公开API）不需要Cookie，可能会出错。这时可以在该接口的Pre-request Script中覆盖此行为。

实操心得：对于大型项目，我通常采用“集合级脚本添加Cookie + 接口级脚本选择性移除”的策略。在集合级脚本里添加Cookie，然后在那些不需要Cookie的接口的Pre-request Script里写pm.request.headers.remove('Cookie')。这样管理起来最清晰。

5. 高级技巧与常见问题排查

掌握了基础方法后，我们来看看更复杂的场景和那些容易踩的坑。

5.1 处理复杂的Cookie场景

• 多个Cookie：如果登录接口返回多个Set-Cookie头，你需要将它们合并成一个Cookie头的值，用分号和空格分隔。

  // 在登录接口的Tests中 var cookieHeaders = pm.response.headers.getAll('Set-Cookie'); var combinedCookieValue = ''; if (cookieHeaders && cookieHeaders.length > 0) { // 提取每个Cookie头的第一个键值对（分号前） var cookiePairs = cookieHeaders.map(function(header) { return header.split(';')[0].trim(); }); combinedCookieValue = cookiePairs.join('; '); pm.environment.set("auth_cookie", combinedCookieValue); }

• Cookie域和路径：Postman的Cookie Jar会自动管理域和路径。但当我们手动设置Cookie头时，就绕过了这个机制。确保你请求的URL域名和路径与Cookie匹配，否则服务器可能不认。如果你的测试涉及多个子域名，可能需要更精细的处理。
• HttpOnly Cookie：这种Cookie无法通过JavaScript的document.cookie访问，但通过HTTP头Set-Cookie设置和Cookie发送是完全正常的，我们的脚本处理方式不受影响。

5.2 使用Postman内置的Cookie Jar（替代方案）

除了手动设置Header，Postman的pm.cookiesAPI允许你直接操作其内部的Cookie Jar。

// 在登录接口的Tests中，将Cookie设置到Jar中 var cookieHeader = pm.response.headers.get('Set-Cookie'); if (cookieHeader) { // pm.cookies.set() 参数：Cookie名, Cookie值, 域名, [路径] // 需要从cookieHeader中解析出域名，这里用当前请求的域名简化处理 var domain = pm.request.url.getHost(); // 例如 "api.example.com" // 解析Cookie名和值（简化示例，实际需更健壮的解析） var match = cookieHeader.match(/^([^=]+)=([^;]+)/); if (match) { pm.cookies.set(match[1], match[2], domain); console.log(`已设置Cookie到Jar: ${match[1]}=${match[2]} for ${domain}`); } }

使用此方法后，后续向同一域名的请求，Postman会自动从Jar中附加Cookie，无需再写Pre-request Script。但请注意，这种方式依赖于Postman的Cookie管理机制，在脚本控制的流程中，有时不如手动设置Header来得直接和可控，尤其是在需要清理或覆盖特定Cookie时。

5.3 常见问题排查清单

当你发现Cookie自动携带失效时，可以按照以下清单逐一排查：

5.4 安全与维护建议

• 不要硬编码敏感信息：账号密码尽量使用环境变量，并且考虑使用Postman的“初始值和当前值”功能，将密码的当前值留空，运行时手动输入或通过更安全的方式获取。
• 定期清理Cookie：在测试套件的开始或结束，可以编写脚本清除环境变量pm.environment.unset("auth_cookie")或清除Cookie Jarpm.cookies.clear()，避免测试数据污染。
• 封装通用函数：如果你有多个项目或集合，可以将捕获和应用Cookie的脚本写成通用的代码片段，保存在Postman的“Snippets”中，方便复用。

6. 完整脚本示例与集合运行实战

让我们整合前面的知识，构建一个可运行的完整示例，并通过Postman的集合运行器来执行整个测试流。

6.1 完整的登录接口Tests脚本（增强版）

这个脚本增加了更健壮的Cookie解析和错误处理。

// 增强版登录接口Tests脚本 pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); // 尝试从JSON body中获取业务状态码（根据实际API设计调整） var jsonData; try { jsonData = pm.response.json(); pm.test("Login successful", function () { pm.expect(jsonData.code).to.eql(0); // 或 pm.expect(jsonData.success).to.be.true; }); } catch (e) { console.log("Response is not JSON or parsing failed:", e.message); } // 捕获并处理Cookie var cookieHeaders = pm.response.headers.getAll('Set-Cookie'); console.log("Found Set-Cookie headers:", cookieHeaders); if (cookieHeaders && cookieHeaders.length > 0) { var cookiesToStore = []; for (var i = 0; i < cookieHeaders.length; i++) { var header = cookieHeaders[i]; // 提取每个Cookie的主要键值对（第一个分号前） var keyValuePart = header.split(';')[0].trim(); if (keyValuePart) { cookiesToStore.push(keyValuePart); } } if (cookiesToStore.length > 0) { var combinedCookie = cookiesToStore.join('; '); pm.environment.set("auth_cookie", combinedCookie); console.log("Combined and stored cookie:", combinedCookie); // 可选：同时解析出重要的Cookie单独存储，方便其他用途 // 例如，解析sessionId for (var pair of cookiesToStore) { if (pair.startsWith('sessionId=')) { pm.environment.set("session_id", pair.split('=')[1]); break; } } } else { console.warn("No valid key-value pairs found in Set-Cookie headers."); } } else { // 如果没有Cookie，检查是否是Token方案（如Bearer Token） if (jsonData && jsonData.data && jsonData.data.token) { pm.environment.set("access_token", jsonData.data.token); console.log("Stored access token."); // 注意：Token通常放在Authorization头，不是Cookie头。后续接口的Pre-request Script需要相应调整。 } else { console.error("No authentication credentials (Cookie or Token) found in response."); } }

6.2 完整的集合级Pre-request Script（智能版）

这个脚本会智能判断，只为需要认证的接口添加Cookie。

// 集合级Pre-request Script (智能版) // 假设我们为需要认证的接口的URL路径定义一个特征，例如包含 '/api/private/' 或 '/admin/' var requestUrl = pm.request.url.toString(); // 定义一个函数判断是否需要认证（根据你的项目规则调整） function requiresAuth(url) { // 规则1：排除登录接口本身 if (url.includes('/api/login')) { return false; } // 规则2：特定路径需要认证 var authPaths = ['/api/private/', '/api/user/', '/api/admin/', '/api/order/']; // 示例路径 for (var path of authPaths) { if (url.includes(path)) { return true; } } // 规则3：可以根据请求方法判断（如所有POST/PUT/DELETE需要认证） // if (pm.request.method !== 'GET') { return true; } return false; } if (requiresAuth(requestUrl)) { var authCookie = pm.environment.get("auth_cookie"); if (authCookie) { pm.request.headers.upsert({ key: 'Cookie', value: authCookie }); console.log(`[集合脚本] 为请求 ${pm.request.method} ${pm.request.url.getPath()} 添加Cookie头`); } else { console.warn(`[集合脚本] 请求 ${pm.request.method} ${pm.request.url.getPath()} 需要认证，但 auth_cookie 为空。`); // 可以在这里让测试提前失败 // throw new Error("Authentication required but no cookie found. Please run login first."); } } else { // 对于不需要认证的请求，确保没有残留的Cookie头（避免干扰） pm.request.headers.remove('Cookie'); console.log(`[集合脚本] 请求 ${pm.request.method} ${pm.request.url.getPath()} 为公开接口，已清理Cookie头`); }

6.3 使用集合运行器进行自动化测试

脚本写好后，真正的威力在于自动化执行。

1. 打开Postman，进入你的“用户业务流测试”集合。
2. 点击顶部的“Runner”按钮打开集合运行器。
3. 在左侧勾选你的集合以及需要运行的接口（通常全选）。
4. 在右侧选择对应的环境（如“My_API_Test_Env”）。
5. 设置迭代次数（如1次）和延迟。
6. 点击“Run XXX Collection”按钮。

集合运行器会按照顺序执行集合内的请求。你会看到：

• 首先执行“登录接口”，其Tests脚本会捕获Cookie并存入环境变量。
• 接着执行“获取用户信息”等接口，集合级的Pre-request Script会检测到这是需要认证的接口，并从环境变量中读取Cookie，自动添加到请求头中。
• 所有请求的结果（状态码、测试结果）会清晰地展示在运行结果页面。

如果中间任何一步出错（比如登录失败导致Cookie为空），后续的认证接口很可能会失败，从而在测试结果中明确标识出问题链路，这正是自动化测试的价值所在。

6.4 维护与扩展

随着项目迭代，接口可能变化。你需要定期检查：

• 登录接口响应格式：Cookie的名称或位置是否改变。
• 认证规则：集合级脚本中的requiresAuth函数规则是否需要更新。
• 环境变量：确保测试账号有效，环境配置（如base_url）正确。

你可以将这个模式扩展到更复杂的场景，比如处理OAuth 2.0令牌、处理CSRF Token（通常也需要从Cookie或响应体中提取并放到后续请求的Header或Body中）。其核心思想不变：通过脚本桥接请求之间的依赖关系，将手动操作自动化。

掌握了自动携带Cookie的技术，你的Postman接口测试就突破了单点验证的局限，迈向了业务流程自动化测试的新阶段。从用户登录、浏览商品、加入购物车到下单支付，这一整套流程都可以在一个集合运行中一气呵成，极大地提升了回归测试的效率和可靠性。下次当你需要测试一整个用户旅程时，别忘了先把这个“通行证”自动化的脚本准备好。