解锁 Postman 接口测试的奇妙之旅

一、Postman 初印象

（一）简介

Postman 是一款在 API 开发与测试领域极具影响力的工具，它为开发者和测试人员提供了诸多便利。简单来说，它就像是一个功能强大的 "请求中转站"，能够帮助使用者轻松地向服务器发送各类请求，并直观地查看服务器返回的响应内容。

例如，开发人员在完成 API 接口的编写后，可以利用 Postman 迅速发送请求来验证接口是否按照预期工作，测试人员也可以借助它对 API 进行全面的测试，涵盖功能测试、性能测试等多个方面。

不仅如此，Postman 还支持编写测试脚本，通过自定义的脚本逻辑来自动化地验证响应结果是否符合要求，极大地提高了测试效率，减少了人工逐个比对的繁琐操作。而且它还具备自动化测试的能力，能够按照预设的规则和流程批量执行测试用例，方便快捷地检测 API 在不同场景下的表现。

在支持的请求方法方面，Postman 非常全面，像常见的 GET、POST、PUT、DELETE 等 HTTP 方法都能很好地支持，满足了各种不同类型的 API 交互需求。同时，它还支持 REST、SOAP、GraphQL 等多种 API 协议，无论是传统的 RESTful API，还是新兴的 GraphQL API，都可以在 Postman 中进行相应的开发与测试操作，适用范围相当广泛。

（二）安装与设置

下载：

Windows 系统：打开浏览器，访问 Postman 官方网站（https://www.postman.com/downloads/ ），在下载页面中找到适合 Windows 系统的版本（一般会区分 64 位和 32 位，根据自己电脑的配置选择对应版本），点击下载按钮，等待下载完成后，找到下载的安装文件（通常为一个.exe 文件），双击运行安装文件，然后按照安装向导的指示逐步完成安装操作即可。

macOS 系统：同样在 Postman 官方网站上，选择对应 macOS 的版本进行下载（下载的文件格式一般为.dmg），下载完成后，双击该文件进行挂载，将里面的 Postman 应用程序拖移到 "应用程序" 文件夹中，就完成了安装过程。

Linux 系统：进入官网下载页面，选择适合 Linux 系统的版本（比如 X64 或 X86 等不同架构版本），下载相应的安装包后，通过命令行等方式进行解压和安装操作（不同 Linux 发行版安装方式略有差异，但基本遵循解压后运行相关可执行文件的步骤）。

创建账号：虽然 Postman 可以在不登录账号的情况下直接使用，但创建账号有着诸多好处。例如，通过账号登录后，可以将自己创建的 API 集合以及配置好的环境变量等信息同步到云端，这样一来，当我们在不同的设备（如办公室的电脑、家里的电脑或者笔记本等）上使用 Postman 时，只要登录账号，就能轻松获取之前保存的设置，实现无缝切换和继续工作，极大地方便了使用者在多设备间共享和管理自己的 API 相关资源。

（三）用户界面构成

请求构建区：这是我们在 Postman 中构建和发送 API 请求的核心区域。在这里，首先可以选择想要使用的 HTTP 方法，比如是获取数据的 GET 方法，还是提交数据的 POST 方法等。接着输入请求对应的 URL 地址，同时还能够对请求头（Headers）进行详细设置，像添加自定义的请求头信息，以满足不同 API 对于认证、数据格式等方面的要求。而且对于有请求体（Request Body）的请求，例如 POST 请求需要提交的数据内容等，可以在这个区域按照相应的数据格式（如 JSON、XML、Form-data 等）进行编写和配置，确保请求能够准确无误地发送给服务器。

响应区：当我们发送请求后，服务器返回的响应内容就会在这个区域展示出来。它会清晰地呈现响应状态码（如常见的 200 表示请求成功、404 表示资源未找到等），通过状态码我们可以快速判断请求是否被正确处理。同时，响应头信息也会罗列出来，从中能了解到服务器返回数据的一些相关属性，比如数据的类型、缓存策略等。而响应体部分更是关键，我们可以根据返回的数据格式，选择以不同的方式查看内容，例如选择 Pretty（美化格式）可以让 JSON 等格式的数据更清晰易读，Raw（原始格式）则能看到最原始的返回数据，Preview（HTML 预览格式）方便查看如果返回的是 HTML 页面内容的展示效果等，方便我们细致地查看和分析服务器返回的信息，以验证请求是否达到预期效果。

侧边栏：侧边栏主要起到管理相关资源的作用。其中，"集合（Collection）" 功能非常实用，它相当于一个容器，可以把一组相关的 API 请求组织在一起，方便我们进行分类管理，比如按照不同的项目、不同的功能模块等将相关的接口请求分别归纳到不同的集合当中，便于查找和批量操作这些接口。"环境（Environment）" 板块则用于管理环境变量，在实际的 API 开发和测试中，常常会涉及到不同的环境，如开发环境、测试环境、生产环境等，每个环境下对应的服务器地址、API 密钥等参数可能不同，通过在这里配置环境变量，我们可以在请求中方便地调用这些变量，实现根据不同环境快速切换配置的目的，避免了手动修改请求参数的麻烦。此外，侧边栏还会记录请求的历史记录，方便我们回顾之前发送过的请求情况，快速再次发起相同或者相似的请求。

而在 Postman 中的主要组件方面，"请求（Request）" 组件涵盖了请求的 URL、HTTP 方法、请求头、请求体等关键信息，是我们构建请求的基础要素所在，完整地描述了要发送给服务器的具体内容。"响应（Response）" 组件则如前文所述，是服务器针对请求返回的结果呈现，包含了状态码、响应头、响应体等重要的反馈内容，供我们进行验证和分析。集合（Collection）用于组织和管理多个请求，让众多 API 请求有条理地整合在一起，便于操作和维护。环境（Environment）通过一组变量的设置，支持在不同环境下进行灵活的配置管理，保障了 API 在各个阶段的顺利测试和部署。

二、创建并发送请求

（一）选择 HTTP 方法

在 Postman 的请求构建区，我们可以根据实际的需求来选择不同的 HTTP 方法，常见的如 GET、POST、PUT、DELETE 等，每种方法都有其适用的场景。

GET 方法：它主要用于从服务器检索数据。例如，当我们想要获取某个网页的内容、查询数据库中的某些记录或者获取某个 API 提供的信息时，就会使用 GET 方法。像在开发一个电商网站时，通过 GET 方法向服务器请求商品列表数据，服务器接收到请求后，会根据请求的 URL 等相关信息查找对应的商品数据并返回给客户端。GET 方法通常是幂等的，多次请求相同的 URL 应该返回相同的结果，并且它一般不会对服务器上的数据进行修改等操作。在 Postman 中选择 GET 方法后，我们后续输入对应的 URL 以及相关参数等信息，就能向服务器发起获取数据的请求了。

POST 方法：常用于向服务器提交数据，比如用户注册时填写的表单信息、发表文章时提交的文章内容等场景都会用到 POST 请求。例如在一个社交平台上，用户发布一条新动态，客户端就会使用 POST 方法将动态的文本内容、图片等相关数据发送给服务器，服务器接收后进行相应的存储等处理操作。POST 请求会将数据放在请求体（Body）中发送给服务器，而且它不是幂等的，多次相同的 POST 请求可能会在服务器端产生不同的效果，比如多次提交相同的订单信息，服务器会多次处理这些订单，而不是像 GET 方法那样返回相同结果。

PUT 方法：主要用于从客户端向服务器传送的数据取代指定文档的内容，也就是更新服务器上已有的资源。例如，在一个在线文档编辑系统中，当用户对已经存在的文档进行修改保存时，客户端可以通过 PUT 方法将修改后的文档内容发送给服务器，服务器会用接收到的新内容替换掉原来的文档内容。

DELETE 方法：正如其名，它用于删除服务器上的资源。比如在一个文件管理系统中，当用户选择删除某个文件时，客户端会向服务器发送 DELETE 请求，告知服务器要删除对应的文件资源，服务器接收到请求后执行删除操作。

总之，根据不同的业务需求，合理地在 Postman 中选择相应的 HTTP 方法，是准确进行接口测试的第一步。

（二）输入请求 URL 及参数

准确输入请求的 URL 是至关重要的，这就好比我们要准确填写收件人的地址，才能确保请求准确地发送到对应的服务器资源处。

对于 GET 请求来说，除了直接在请求构建区的 URL 输入框中输入基本的 URL 地址（包含协议、域名、路径等信息）外，如果有请求参数，一般是在 URL 中通过特定的方式传递。常见的是在 URL 后面添加 "?"，然后按照 "键 = 值" 的形式来写参数，多个参数之间用 "&" 符号进行连接。例如，我们请求一个查询商品信息的接口，URL 可能是 "https://example.com/api/goods?"，后面接着 "id=123&name=phone"，表示查询商品 ID 为 123 且名称为 phone 的商品信息，这些参数信息会在 Params 区域直观呈现，并且 Postman 也会自动解析并在发送请求时将其整合到完整的 URL 中发送给服务器。另外，GET 请求有时候也可以通过 Cookie 来传递一些参数，比如某些需要验证用户登录状态的接口，服务器会根据客户端发送的 Cookie 中的相关信息来识别用户身份等，我们可以在请求的 Headers 中设置对应的 Cookie 值来传递必要的参数。

而 POST 请求的参数处理方式有所不同，它的参数通常放在 Body 中进行传递。在 Postman 中，点击 Body 选项卡后，可以根据实际的数据格式来填写参数内容。常见的数据格式有以下几种：

• form-data：代表的是多部分对象，常用于有文件上传或者需要传递混合类型数据（如既有文本数据又有文件等）的情况，例如表单中有文件上传的时候就会使用这种格式。
• x-www-form-urlencoded：简称 URL-encoded，这种格式的数据使用与 URL 参数相同的编码，一般用于普通的键值对参数数据传送，例如提交简单的表单数据，像登录时的用户名和密码等信息就可以用这种格式传递，数据会以键值对的形式进行组织发送。
• raw：它的灵活性很强，可以发送任何能够以文本方式输入的内容，在后面的类型下拉框中（显示在 GraphQL 的后面）会显示数据类型，包括 Text、JavaScript、JSON、HTML、XML 等，并且 Postman 会自动将相应的 Headers 信息加入到请求中。例如，当我们要发送一段 JSON 格式的数据作为请求参数时，就可以选择 raw 格式，然后在输入框中按照 JSON 的语法规范（如 {"key":"value"}）来填写参数内容。
• binary：用于发送 "无法在 Postman 编辑器中手动输入的信息"，例如 image、audio、video files（也可以传递文本文件）等二进制文件类型的数据。

不同的 POST 请求场景，需要根据 API 要求选择合适的 Body 数据格式来准确传递参数，确保服务器能够正确解析并处理请求。

（三）设置请求头

设置请求头在整个请求过程中有着重要的作用，它包含了关于请求的元数据信息，这些信息对于服务器准确处理请求是必不可少的。

对于不同类型的请求，在请求头中需要声明的关键内容有所不同。比如在 POST 请求涉及特定数据格式时，Content-Type 这个请求头字段就尤为关键。Content-Type 用于指示请求体（Body）中的数据类型，这样服务器才能知道按照何种格式来解析接收到的数据。例如，当我们在 POST 请求的 Body 中选择以 JSON 格式填写参数时，就需要在请求头中添加 "Content-Type: application/json"，告诉服务器发来的数据是 JSON 格式的，服务器收到请求后就会按照 JSON 格式解析规则去处理请求体中的数据，从而正确提取其中的参数信息。

除了 Content-Type 外，还有很多常见且重要的请求头字段。像 Authorization 字段，常用于传递身份验证凭据，在需要验证用户身份的接口请求中，比如使用 Basic 认证或 Bearer Token 认证时，我们会在这个字段中填写对应的认证信息，服务器根据此信息来确认请求是否来自合法的用户。再比如 User-Agent 字段，它包含发出请求的用户信息，服务器可以通过这个字段了解客户端的一些基本情况，像是什么类型的客户端软件、在什么操作系统上运行等，有时候服务器会根据 User-Agent 来做一些兼容性处理或者统计分析等操作。另外，还有 Accept 字段，它指定客户端能够接收的内容类型，例如 "Accept: text/plain, text/html,application/json" 表示客户端可以接受纯文本、HTML 页面、JSON 格式等类型的响应数据，服务器在返回响应时会尽量按照客户端可接受的类型来返回内容。

在 Postman 中，我们可以在请求构建区很方便地找到 Headers 标签，点击后会出现一个表格形式的编辑区域，每个请求头由一个键值对组成，键和值之间使用冒号分隔，如 "Key: Value"，在这里就可以根据实际需求添加、修改各种请求头信息了。

（四）发送请求

当我们完成了 HTTP 方法选择、请求 URL 及参数输入、请求头设置等前期准备工作后，就可以点击 Send 图标来发送请求了。这个操作非常简单，在 Postman 的请求构建区找到 Send 按钮，点击它即可将构建好的请求发送给对应的服务器。

发送请求后，我们需要查看验证请求结果是否正确，这主要通过查看响应区呈现的相关信息来判断。响应区会展示出服务器返回的响应内容，其中包含了 Body（响应体）和 Headers（响应头）等重要信息。

响应头中罗列了服务器返回数据的一些相关属性，比如数据的类型（通过 Content-Type 字段体现）、缓存策略（如 Cache-Control 字段）等，通过查看这些信息我们可以了解服务器对请求的一些处理方式以及返回数据的一些基本特征。

而响应体部分更是关键所在，它是服务器实际返回给客户端的数据内容。我们可以根据返回的数据格式，选择以不同的方式查看内容。例如选择 Pretty（美化格式），如果返回的数据是 JSON 等格式，那么会以更清晰易读的形式展示出来，方便我们查看其中的具体数据结构和内容；选择 Raw（原始格式）则能看到最原始的返回数据，有时候在排查一些问题或者需要获取最原汁原味的数据时会用到这种查看方式；Preview（HTML 预览格式）则方便查看如果返回的是 HTML 页面内容的展示效果，对于测试一些返回网页内容的接口非常有用。通过仔细查看和分析服务器返回的这些信息，我们就能验证请求是否达到了预期的效果，比如请求获取商品信息的接口后，查看响应体中是否正确返回了相应商品的详细数据，状态码是否是表示成功的 200 等，以此来判断接口的功能是否正常。

三、测试和验证响应

（一）查看响应状态码与信息

在 Postman 发送请求后，响应区展示的响应状态码是我们首先要关注的内容。状态码是一个三位数字的代码，不同的数字范围代表着不同含义，常见的如：

• 1xx（信息性状态码）：表示服务器已接收请求，正在处理中，通常比较少见，例如 100 Continue 表示服务器已接收到请求头，客户端应继续发送请求主体。
• 2xx（成功状态码）：意味着请求已成功被服务器接收、理解并处理。其中最常见的就是 200 OK，表示请求成功完成，服务器返回了请求的数据。比如我们向一个查询商品信息的接口发送请求，成功获取到商品详情时，就会返回 200 状态码。还有 201 Created，常用于 POST 请求后，服务器成功创建了新的资源，像用户注册成功创建新账号时可能返回此状态码。
• 3xx（重定向状态码）：表明客户端需要采取进一步的操作才能完成请求，一般是资源被临时或永久移动到了其他位置，需要重定向访问。比如 301 Moved Permanently 表示请求的资源已被永久移动到新的 URL，客户端后续应使用新的 URL 进行访问；302 Found 表示资源临时移动，客户端需要使用新的临时 URL 再次发起请求。
• 4xx（客户端错误状态码）：通常表示客户端发送的请求有错误，导致服务器无法处理。400 Bad Request 表示客户端请求的语法错误，服务器无法理解请求内容；401 Unauthorized 意味着请求要求用户进行身份验证，通常是缺少正确的认证凭据；404 Not Found 是大家比较熟悉的，说明服务器找不到请求的资源，例如输入了错误的 URL 地址或者请求一个不存在的接口时会返回该状态码。
• 5xx（服务器错误状态码）：这是服务器在处理请求过程中出现错误的情况。500 Internal Server Error 表示服务器内部出现了未知的错误，无法完成请求的处理；502 Bad Gateway 常出现在服务器作为网关或代理，从上游服务器获取响应时出现了无效响应的情况；503 Service Unavailable 则表示服务器目前暂时无法处理请求，可能是处于维护状态或者过载等原因。

通过查看响应状态码，我们可以快速初步判断请求是否正常处理。

除了状态码外，响应头中也包含着许多关键信息。在响应区中找到 "Headers" 标签页，就能看到以键值对形式罗列出来的响应头信息。例如，"Content-Type" 字段会指明响应体的数据类型，像 "Content-Type: application/json" 代表返回的数据是 JSON 格式，"Content-Type: text/html" 则表示返回的是 HTML 页面内容，我们可以据此来确定如何去解析和查看响应体。再比如 "Cache-Control" 字段，它规定了缓存相关的策略，如是否允许缓存、缓存的有效期等，对于了解数据的时效性和缓存机制很有帮助。还有 "Set-Cookie" 字段，如果服务器需要设置 Cookie 信息，会通过这个字段传递给客户端，方便后续的交互中客户端携带相应的 Cookie 进行请求等操作。总之，从响应头中获取这些相关的关键信息，能够辅助我们更全面深入地判断请求的处理情况以及理解服务器返回的数据特性。

（二）解析响应体内容

响应体作为服务器返回给客户端的实际数据内容，其查看和解析十分关键。Postman 为我们提供了几种不同的查看模式，以适应各种不同的数据格式和查看需求。

• Pretty（美化格式）模式：当返回的数据是 JSON 或者 XML 等格式时，选择 Pretty 模式可以让数据以更清晰易读的形式展示出来。例如，返回的是一个复杂的 JSON 格式的用户信息数据，包含多个层级的对象和数组，在 Pretty 模式下会自动进行缩进、换行等格式化处理，我们能很直观地看到其中的具体数据结构和内容，比如查看用户的姓名、年龄、联系方式等各个字段的值，方便验证数据是否符合预期。而且在该模式下，如果数据中有链接，这些链接会高亮显示，点击它们还可以通过链接 URL 在 Postman 中直接加载对应的 GET 请求，便于进一步查看相关资源。若要浏览较大篇幅的响应报文，还可以单击左侧的向下指向的三角形（▼）来折叠响应报文，使查看更有条理。不过需要注意的是，为了让 Postman 能自动对响应体进行格式化，要确保服务器返回了正确的 "Content-Type" 请求头指明数据类型，如果没有返回相应的请求头，我们也可以通过在 "Settings" 中的 "常规" 选项卡下选择 "JSON" 等方式来强制进行格式设置。
• Raw（原始格式）模式：此模式展示的是最原始的返回数据内容，原汁原味地呈现了服务器返回的信息。有时候在排查一些问题，比如怀疑数据在传输过程中是否被篡改，或者需要获取最原始的字节流等情况下会用到这种查看方式。例如，当我们进行文件下载相关接口的测试，查看返回的二进制文件流数据时，Raw 模式就能看到完整的原始数据。又或者在调试接口时，需要核对服务器返回的每一个字符，包括空格、换行等，也可以通过 Raw 模式来查看。
• Preview（HTML 预览格式）模式：如果服务器返回的是 HTML 页面内容，那么 Preview 模式就非常有用了。它会在沙箱中的 iframe 形式呈现响应，能让我们看到类似在浏览器中查看网页的效果，便于查看页面的布局、样式以及展示的内容等。不过由于 iframe 沙盒的限制，在这种模式下 JavaScript 和图像通常是被禁用的。例如，测试一个网页渲染接口，返回的 HTML 页面包含了页面结构和样式信息，通过 Preview 模式就能直观地查看页面是否正确展示，元素排版是否符合要求等。

在实际操作中，我们可以根据具体的接口返回的数据格式以及验证目的，灵活选择合适的查看模式，然后从响应体正文中提取所需的数据，与预期的结果进行比对，从而进行结果的验证，判断接口的功能是否正常实现。

（三）利用 Tests 模块进行断言

Postman 内置的 Tests 模块为我们提供了强大的功能，通过编写 JavaScript 脚本，并利用断言库，可以对响应结果进行更细致、精确的验证，确保响应符合我们预期设定的条件。

在请求构建区完成请求的相关设置并发送请求后，点击 "Tests" 标签页，这里提供了一个编辑器，允许我们输入和编辑 JavaScript 代码。例如，要验证响应状态码是否为 200，我们可以编写如下代码：

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

这段代码中，pm.test用于定义一个测试用例，括号内第一个参数是测试用例的名称（这里命名为 "Status code is 200"），方便我们在查看测试结果时能清晰识别每个测试的含义；第二个参数是一个函数，在函数内部通过pm.response.to.have.status(200)来断言响应的状态码是否等于 200，如果等于则这个测试用例通过，反之则失败。

再比如，当响应体是 JSON 格式的数据，要验证其中某个字段的值是否符合预期，可以这样写：

pm.test("Check specific JSON value", function () {
    let jsonData = pm.response.json();
    pm.expect(jsonData.field_name).to.eql("expected_value");
});

这里首先使用pm.response.json()将响应体的内容解析为 JSON 对象并赋值给jsonData变量，然后通过pm.expect(jsonData.field_name).to.eql("expected_value")来断言jsonData中名为field_name的字段的值是否等于我们预期的expected_value。

除了上述常见的状态码和 JSON 字段值验证外，还可以进行很多其他方面的断言，像验证响应时间是否在预期范围内：

pm.test("Response time is within expected range", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

这段代码就是检查响应时间是否小于 500 毫秒，可根据实际需求调整具体的时间数值。

又如验证响应头中是否包含特定的字段：

pm.test("Response includes certain header", function () {
    pm.response.to.have.header('header_name');
});

通过上述各种方式，我们能利用 Tests 模块根据接口的不同要求编写相应的断言脚本，在发送请求后，Postman 会自动执行这些测试脚本，并在 "Test Results" 面板中展示出每个测试用例的测试结果，绿色代表通过，红色则表示失败，方便我们快速定位接口不符合预期的地方，进而进行针对性的调整和优化，保障接口的质量和功能正确性。

四、环境变量的巧用

（一）创建和管理环境变量

在实际的 API 开发与测试过程中，常常会涉及不同的环境，比如开发环境、测试环境、生产环境等，而每个环境下对应的服务器地址、API 密钥等参数可能各不相同。此时，合理地创建和管理环境变量就显得尤为重要，它能帮助我们轻松实现根据不同环境快速切换配置，避免手动反复修改请求参数的繁琐操作。

Postman 中有三种主要的变量类型，分别是全局变量、环境变量和集合变量，它们各有特点且生效范围和优先级也不一样。

首先说全局变量，它在整个 Postman 工作空间内都是有效的，也就是在任何集合、任何请求中都可以使用这个变量，作用域最大。定义全局变量的方式如下：在 Postman 界面左上角点击 "设置" 按钮，接着在 "Settings" 页面中，点击 "General" 选项卡，然后在 "Globals" 设置里，就可以设置全局变量的键值对了，例如设置变量名为 "token"，变量值为 "123456" 等。

再来看环境变量，申明环境变量需要先创建环境，然后才能在该环境中创建变量。我们可以创建多个环境，每个环境下又可以有多个变量。具体操作步骤为：在 Postman 左侧边栏的 "Environments" 部分，点击下拉菜单，选择 "Manage Environments"。在弹出的 "Manage Environments" 窗口中，点击 "Add" 按钮，接着输入环境的名称（像 "Development""Production" 等），之后在 "Values" 区域，添加变量，每个变量包含一个键和一个值，比如添加一个名为 "baseUrl" 的变量，其值设为对应的 API 基地址，最后点击 "Add" 按钮保存环境即可。

而集合变量则是针对集合的，仅仅在指定的集合内生效。在新建或编辑 Collection 时，通过 "Variables" 选项来添加集合变量。

这三种变量在重名的情况下，优先级顺序为环境变量＞集合变量＞全局变量。例如，当我们在某个请求中同时定义了同名的这三种变量，那么最终生效的会是环境变量的值。

（二）在请求中引用环境变量

在 Postman 中创建好各种环境变量后，就可以在请求的不同位置通过特定格式来引用它们，以此实现根据不同环境灵活配置请求参数的目的。引用环境变量的格式为 "{{变量名}}"。

在 URL 位置引用环境变量是很常见的用法。比如我们创建了一个名为 "baseUrl" 的环境变量，在不同环境下其值分别对应开发环境、测试环境、生产环境的服务器地址。当我们构建请求的 URL 时，就可以写成 "{{baseUrl}}/api/v1/users" 这样的形式。发送请求时，Postman 会自动根据当前所选择的环境，将 "{{baseUrl}}" 替换为对应环境下该变量设置的值，从而准确地向相应环境的服务器发送请求。

在 Params（请求参数）部分同样可以引用环境变量。例如，有一个查询用户信息的接口，在不同环境下查询参数的部分默认值可能不同，我们可以将这些可能变化的参数设置为环境变量，然后在 Params 区域按照 "{{变量名}}" 的格式进行引用，Postman 会在发送请求时自动替换为实际的值整合到完整的 URL 中发送给服务器。

对于请求体（Body）部分，也支持引用环境变量。如果请求体是 JSON 格式的数据，比如要发送一段包含用户登录信息的 JSON 数据，而其中的用户名、密码等参数在不同环境下有不同的测试账号，这时可以将这些账号相关信息设置为环境变量，在 Body 中像这样使用："{"username": "{{user_name}}", "password": "{{password}}" }"，发送请求后，Postman 会把相应的环境变量替换为真实的值，确保请求按照对应环境的配置准确发送给服务器。

此外，在 Pre-request Script（请求前置脚本）和 Tests（测试脚本）中也可以使用环境变量，不过在脚本中需要通过特定的语句来获取变量，例如 "var e_a = pm.environment.get ("a");" 这样的语句就能获取名为 "a" 的环境变量，方便我们在脚本中根据不同环境进行相应的逻辑处理和验证操作。

五、创建和运行测试脚本

（一）编写测试脚本基础

在 Postman 中，我们可以使用 JavaScript 语言来编写测试脚本，以此实现对 API 接口响应结果的自动化验证。下面来介绍一些编写测试脚本的基本规则和常用语法，以及结合 Postman API 与内置断言库（如 Chai 断言库）编写简单测试脚本的示例。

首先，测试脚本需要遵循 JavaScript 的基本语法规范。例如，使用var、let或const来声明变量，像var num = 10;就是声明了一个名为num且初始值为10的变量。在函数定义方面，通过function关键字来定义函数，例如：

function add(num1, num2) {
    return num1 + num2;
}

这里定义了一个名为add的函数，用于计算两个数相加的结果。

条件判断语句可以使用if、else if、else来实现，比如：

if (num > 10) {
    console.log("大于10");
} else if (num === 10) {
    console.log("等于10");
} else {
    console.log("小于10");
}

循环语句中，for循环常用于已知循环次数的情况，像下面这样遍历数组：

const arr = [1, 2, 3];
for (let i = 0; i < arr.length; i++) {
    console.log(arr[i]);
}

while循环则是在满足特定条件时持续执行循环体，例如：

let j = 0;
while (j < 5) {
    console.log(j);
    j++;
}

在 Postman 中编写测试脚本时，会经常用到其内置的一些对象和函数。例如，pm对象就是非常关键的，它提供了诸多用于操作请求和响应的方法。

结合 Postman API 和内置断言库来编写测试脚本示例如下：

当我们想要验证响应状态码是否为 200 时，可以这样写：

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

这里的pm.test用于定义一个测试用例，第一个参数"Status code is 200"是测试用例的名称，方便我们在查看测试结果时能清晰识别其含义；第二个参数是一个函数，在函数内部通过pm.response.to.have.status(200)来断言响应的状态码是否等于200，如果等于则这个测试用例通过，反之则失败。

要是响应体是 JSON 格式的数据，想验证其中某个字段的值是否符合预期，代码可以这样编写：

pm.test("Check specific JSON value", function () {
    let jsonData = pm.response.json();
    pm.expect(jsonData.field_name).to.eql("expected_value");
});

上述代码首先使用pm.response.json()将响应体的内容解析为 JSON 对象并赋值给jsonData变量，然后通过pm.expect(jsonData.field_name).to.eql("expected_value")来断言jsonData中名为field_name的字段的值是否等于我们预期的expected_value。

总之，熟练掌握 JavaScript 的基础语法，并灵活运用 Postman 提供的内置对象和函数以及断言库，就能编写出有效的测试脚本，对接口响应进行全面准确的验证。

（二）脚本的执行时机

在 Postman 中，脚本的执行有着不同的时机，主要分为在发送请求前（Pre-request Script）执行和请求完成后（Tests）执行，它们各自有着重要且不同的作用。

Pre-request Script（请求前置脚本）：

这个脚本是在请求发送之前运行的，常用于进行参数准备等操作。例如，在实际的接口测试场景中，有时我们需要动态生成一些请求参数。比如，某个接口要求每次请求时带上一个随机生成的数字作为参数，就可以在前置脚本中编写如下代码来实现：

var randomNum = Math.floor(1000 + Math.random() * 9000);
pm.request.url.addQueryParams([{ key: "random", value: randomNum.toString() }]);

上述代码首先生成了一个1000到9999之间的随机数，然后将其作为名为random的 URL 参数添加到请求的 URL 当中。

再比如，当接口需要根据不同的环境来设置请求头中的认证信息时，我们可以在前置脚本中获取对应的环境变量，并设置到请求头里。假设环境变量中有一个名为authToken的变量存储着认证令牌，代码如下：

const token = pm.environment.get("authToken");
pm.request.headers.add({ key: "Authorization", value: `Bearer ${token}` });

这样就能确保每次请求发送前，请求头中的认证信息是根据当前环境正确设置的。

另外，如果接口的请求参数依赖于之前某个操作或者接口返回的数据，也可以在前置脚本中进行相应的数据处理和参数设置，为即将发送的请求做好准备工作。

Tests（请求后置脚本）：

请求后置脚本则是在请求完成后，也就是收到服务器返回的响应之后执行的，其主要作用在于进行响应验证等操作。例如，我们前面提到过的验证响应状态码是否为200的脚本：

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

就是典型的后置脚本应用，通过这个脚本来检查接口返回的状态码是否符合预期，判断请求是否成功被服务器处理。

如果响应体是 JSON 格式的数据，要验证其中特定字段的值、数据结构等是否正确，也可以在后置脚本中编写相应的断言代码，像这样：

pm.test("Verify JSON data structure", function () {
    let jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property("key_name");
    pm.expect(jsonData.key_name).to.be.a("string");
});

这段代码先解析响应体为 JSON 对象，然后断言该对象中是否存在key_name这个属性，并且进一步验证这个属性的值是否为字符串类型，以此来确保返回的 JSON 数据结构和内容符合接口的预期要求。

又如，验证响应时间是否在合理范围内，可编写如下后置脚本：

pm.test("Response time is within expected range", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

它用于检查接口的响应时间是否小于500毫秒，若超出这个时间范围，可能意味着接口性能存在问题或者服务器处理效率较低等情况，方便我们及时发现潜在的性能隐患。

总之，前置脚本侧重于在请求发送前准备好合适的请求参数和环境配置等，而后置脚本重点在于对响应结果进行细致的验证，两者相辅相成，共同保障接口测试的全面性和准确性。

（三）运行测试脚本

当我们在 Postman 中编写好了包含测试脚本的各个请求后，往往需要批量运行这些请求来实现自动化测试流程，并查看整体的测试结果，这时就会用到 Postman 的相关功能，比如 Runner（运行器）。

下面来介绍如何通过 Runner 来批量运行包含测试脚本的请求集合：

首先，打开 Runner 有多种方式。一种是在接口集合的 "・・・"（更多）按钮处，选择 "Run collection"，从这个入口打开 Runner 页面，默认会显示该接口集合下的所有接口；另一种是点击 Postman 的界面底部按钮 "Runner"，不过从这个入口打开 Runner 页面后，需要手动再选择接口；还有在集合的编辑页面，点击 "Run" 按钮也能打开 Runner 页面，同样会显示该接口集合下的所有接口。

打开 Runner 页面后，我们可以进行一些运行前的配置操作。例如，可以选择要运行的环境，因为不同环境下接口对应的服务器地址、参数等可能不同，通过选择合适的环境，能确保请求准确发送到相应环境的服务器进行测试。还能设置运行的次数，如果希望多次重复执行这些接口请求来更全面地检测接口在不同情况下的表现，就可以指定运行次数，比如设置为5次，那么 Runner 就会将集合中的接口依次循环执行5次。

另外，在 Runner 中也可以调整接口请求的执行顺序。默认情况下，请求将按照它们在集合中列出的顺序运行，但如果有特殊需求，比如某个接口需要依赖其他接口先执行的结果，那么可以单击每个请求的左侧并拖动以移动它来改变执行顺序，或者通过内置函数postman.setNextRequest()来修改运行顺序。

配置好相关参数后，点击 "Run test" 按钮，Postman 就会实时显示请求执行和测试结果。在右侧会显示每次运行的数字，单击可以选择其中的一次运行结果，界面上会展示每个请求的概述，单击请求名称还会显示有关执行的更多详细数据。而且，我们可以使用右上角的按钮查看运行摘要，摘要页面会将集合运行的每次迭代列出一列，能够一目了然地查看整个运行过程中的测试输出情况。

如果想要保存测试结果以便后续分析或者分享给团队成员等，测试结果也是支持导出的，导出的文件格式为 JSON 格式，不过需要注意导出之后的文件无法重新导入到 Postman 中。

通过这样利用 Runner 功能批量运行包含测试脚本的请求集合，我们可以高效地实现自动化测试，快速定位接口中存在的问题，保障接口的质量和稳定性。

六、Postman 的高级玩法

（一）关联技术应用

在进行接口测试时，很多时候后一个接口的请求会依赖前一个接口的响应结果，这时候就需要用到 Postman 的关联技术了。关联技术的核心就是将前一个请求的响应结果保存到变量中，然后在后续请求里进行引用，从而实现接口之间的数据传递和流程连贯，让整个测试场景更贴近实际业务逻辑。

下面通过一个常见的获取 access_token 场景来详细讲解关联操作的实现过程。例如，我们在进行一个涉及用户登录及后续操作的接口测试，首先有一个登录接口，当用户登录成功后，服务器会返回包含 access_token 等信息的响应数据，后续的接口请求（比如获取用户信息、操作用户资源等接口）往往都需要在请求头中携带这个 access_token 来进行身份验证。

具体操作如下：

发送登录请求并获取响应数据：

在 Postman 中构建登录接口的请求，选择对应的 HTTP 方法（通常为 POST 方法用于提交登录信息），填写好请求 URL 以及请求体（比如包含用户名、密码等登录所需的参数）等信息后，点击 Send 按钮发送请求。

提取 access_token 并保存到变量：

登录接口请求成功后，在 Tests 模块编写 JavaScript 脚本进行数据提取和变量设置。假设响应数据是 JSON 格式，示例代码如下：

var jsonData = pm.response.json();
var token = jsonData.data.access_token;
pm.collectionVariables.set("access_token", token);

上述代码首先通过 pm.response.json() 将响应体的内容解析为 JSON 对象并赋值给 jsonData 变量，然后从 jsonData 中提取出 access_token 的值赋给 token 变量，最后使用 pm.collectionVariables.set() 方法把 token 保存为名为 access_token 的集合变量（当然也可以根据实际需求选择保存为环境变量或者全局变量等，这里以集合变量为例），方便后续接口在该集合内进行引用。

在后续请求中引用变量：

当要发送需要携带 access_token 的接口请求时，比如获取用户信息接口，在请求头的 Authorization 字段（通常用于传递身份验证凭据）中，通过 {{access_token}} 这样的格式来引用刚才保存的变量，像这样设置请求头：

Authorization: Bearer {{access_token}}

这样，Postman 在发送请求时就会自动将 {{access_token}} 替换为实际的值，从而让后续接口能正确携带 access_token 进行请求，服务器就能识别出是已登录用户的合法请求并返回相应的数据了。

通过这种关联技术应用的优势是很明显的，它使得接口测试不再是孤立的单个接口验证，而是可以模拟出真实业务场景下多个接口之间相互关联、依赖的情况，大大提高了接口测试效率。