Postman进阶：解锁Pre-request Script与Tests脚本的隐藏力量

Postman 脚本初相识

在当今的软件开发领域，API（Application Programming Interface）已经成为连接不同软件组件、实现系统间数据交互和功能协作的关键桥梁。而 Postman，作为一款广受欢迎的 API 开发与测试工具，以其简洁易用的界面、丰富强大的功能，在 API 测试的舞台上占据着举足轻重的地位。无论是前端开发人员与后端进行对接调试，还是测试人员对 API 进行全面细致的测试，Postman 都能提供高效便捷的解决方案，助力开发流程的顺畅推进。

在 Postman 的众多功能模块中，Pre-request Script（预请求脚本）和 Tests（测试脚本）脚本无疑是其进阶使用的核心与精髓所在。Pre-request Script 允许我们在发送请求之前执行一段 JavaScript 代码，这就像是在出发前精心准备行囊，我们可以利用它来完成各种数据预处理工作，比如动态生成请求参数、设置请求头信息、从环境变量或全局变量中获取数据并进行整合等。而 Tests 脚本则是在请求得到响应之后发挥作用，它能够对响应数据进行深入细致的校验，通过编写断言语句，判断响应状态码是否符合预期、响应体中的数据格式是否正确、特定字段的值是否与预设值一致等，确保 API 返回的结果是可靠且符合业务需求的。

学习和掌握 Pre-request Script 与 Tests 脚本的编写，对于提升接口测试效率有着不可估量的意义。一方面，它们能够将原本繁琐、重复的手动操作自动化，大大节省测试时间和人力成本。以一个包含多个接口且接口间存在数据依赖的项目为例，通过 Pre-request Script 自动处理数据依赖关系，避免了手动逐个传递参数的麻烦；利用 Tests 脚本批量验证接口响应，一次性就能判断多个接口的正确性，而无需逐个手动检查。另一方面，这两个脚本为测试工作赋予了更强的灵活性和扩展性。在面对复杂多变的业务场景和测试需求时，我们可以通过编写个性化的脚本，模拟各种特殊情况和边界条件，对 API 进行更加全面、深入的测试，从而有效提升软件质量，降低上线后的风险。

Pre-request Script 深度剖析

基础概念与原理

Pre-request Script 是 Postman 提供的一项强大功能，允许用户在发送 HTTP 请求之前执行一段 JavaScript 代码。它基于 JavaScript 语言编写，这意味着只要你掌握了 JavaScript 的基本语法和常用操作，就能轻松驾驭 Pre-request Script 的编写。当我们在 Postman 中点击发送请求按钮时，Postman 并不会立即将请求发送出去，而是会先检查是否存在 Pre-request Script，如果有，则会按照我们编写的逻辑顺序依次执行脚本中的代码，完成各种预处理操作后，才会正式发送请求。

应用场景展示

自动添加 token：在如今的 Web 应用开发中，基于 token 的身份验证机制极为普遍。每次发送请求时，都需要在请求头或请求参数中携带有效的 token，以验证用户身份和权限。手动添加 token 不仅繁琐，而且容易出错，尤其是在测试多个接口时，一旦遗漏或输错 token，就会导致请求失败，影响测试效率。借助 Pre-request Script，我们可以实现 token 的自动添加，确保每个请求都能准确无误地携带 token。假设我们已经通过登录接口获取到了 token，并将其存储在了名为 "token" 的环境变量中。那么在需要添加 token 的接口请求的 Pre-request Script 中，我们可以编写如下代码：

复制代码

var token = pm.environment.get("token"); pm.request.headers.add({ key: "Authorization", value: "Bearer " + token });

上述代码首先使用pm.environment.get("token")从环境变量中获取名为 "token" 的值，然后通过pm.request.headers.add方法向请求头中添加一个名为 "Authorization" 的字段，其值为 "Bearer " 加上获取到的 token。这样，在每次发送该接口请求时，Postman 都会自动执行这段脚本，将 token 添加到请求头中，大大提高了测试的便利性和准确性。

动态修改请求参数 ：在实际的 API 测试中，经常会遇到需要根据不同的测试场景动态修改请求参数的情况。比如，我们要测试一个商品查询接口，可能需要根据不同的商品类别、价格区间、库存状态等条件进行查询，此时就可以利用 Pre-request Script 来动态生成和修改请求参数。以测试商品查询接口为例，假设接口的基本 URL 为 "https://example.com/api/products"，我们可以在 Pre-request Script 中根据不同的测试场景动态生成查询参数：

复制代码

// 根据测试场景设置不同的查询条件 var category = "electronics"; // 商品类别 var minPrice = 100; // 最低价格 var maxPrice = 500; // 最高价格 // 构建查询参数字符串 var queryParams = `category=${category}&minPrice=${minPrice}&maxPrice=${maxPrice}`; // 修改请求URL，添加查询参数 pm.request.url = pm.request.url + "?" + queryParams;

在上述代码中，我们首先根据测试需求定义了商品类别、最低价格和最高价格等变量，然后通过字符串拼接的方式构建了查询参数字符串queryParams。最后，使用pm.request.url属性修改了请求的 URL，将查询参数追加到了 URL 后面。这样，当发送请求时，接口就能根据我们动态生成的查询参数返回相应的商品列表数据，方便我们对不同条件下的接口功能进行全面测试。

设置请求头：请求头在 HTTP 请求中起着至关重要的作用，它可以携带各种与请求相关的信息，如请求的内容类型、接受的数据格式、用户代理信息等。不同的 API 可能对请求头有不同的要求，通过 Pre-request Script，我们可以灵活地设置请求头，以满足各种 API 的需求。比如，当我们请求一个需要特定 Content-Type 的接口时，可以在 Pre-request Script 中设置请求头的 Content-Type 字段：

复制代码

pm.request.headers.add({ key: "Content-Type", value: "application/json" });

这段代码向请求头中添加了一个名为 "Content-Type" 的字段，其值为 "application/json"，表示请求体的数据格式为 JSON。如果接口还需要其他特殊的请求头信息，如自定义的标识字段、版本号等，都可以通过类似的方式在 Pre-request Script 中进行设置，确保请求能够符合 API 的规范，顺利被服务器接收和处理。

Tests 脚本全解析

功能与作用阐述

Tests 脚本是 Postman 中用于对 API 响应进行自动化测试的关键工具。当我们向 API 发送请求并得到响应后，Tests 脚本便开始发挥作用，它通过编写一系列的断言语句，对响应数据进行全面细致的检查，从而确保 API 的行为符合我们的预期。

在实际的 API 开发与测试过程中，响应状态码是判断请求是否成功的重要依据。例如，当我们发送一个 GET 请求获取用户信息时，如果一切正常，服务器应该返回状态码 200，表示请求成功。此时，我们就可以利用 Tests 脚本中的断言来验证返回的状态码是否为 200。如果状态码不是 200，就说明可能存在问题，如接口地址错误、服务器内部错误、权限不足等，通过 Tests 脚本的检测，我们能够快速发现并定位这些问题。

响应体是 API 返回的核心数据部分，对响应体的验证能够确保我们获取到的数据是准确、完整且符合业务逻辑的。比如，一个商品查询接口应该返回商品的名称、价格、库存等信息，我们可以使用 Tests 脚本来检查响应体中是否包含这些必要的字段，以及字段的值是否在合理范围内。假设商品价格字段的值出现负数，这显然不符合实际情况，通过 Tests 脚本的断言验证，就能及时发现并反馈给开发人员进行修复。

响应头中包含了关于响应的一些元信息，如内容类型、缓存控制、服务器信息等。验证响应头可以帮助我们确保 API 返回的数据格式正确，并且符合相关的规范和约定。例如，当我们期望接口返回的是 JSON 格式的数据时，就可以通过 Tests 脚本检查响应头中的 "Content-Type" 字段是否为 "application/json"，如果不是，可能会导致数据解析错误，影响后续的业务处理。

断言使用技巧

判断状态码是否正确 ：在 Postman 中，使用pm.response.to.have.status()方法来判断响应状态码。例如，要验证响应状态码是否为 200，可以编写如下代码：

复制代码

pm.test("响应状态码为200", function () { pm.response.to.have.status(200); });

这里的pm.test是 Postman 提供的测试函数，第一个参数是测试的描述信息，方便我们在测试结果中识别该断言的作用；第二个参数是一个匿名函数，在这个函数内部编写具体的断言逻辑。pm.response.to.have.status(200)表示期望响应的状态码为 200。如果实际返回的状态码与 200 一致，该断言通过，测试结果显示为绿色的勾号；否则，断言失败，显示为红色的叉号，并会给出详细的错误信息，如 "AssertionError: expected response to have status code 200 but got [实际状态码]" 。

响应体是否包含特定数据 ：如果需要检查响应体中是否包含某个特定的字符串，可以使用pm.expect(pm.response.text()).to.include()方法。例如，假设我们请求一个博客文章列表接口，想要验证返回的响应体中是否包含某篇文章的标题，代码如下：

复制代码

pm.test("响应体包含文章标题", function () { var expectedTitle = "Postman进阶教程"; pm.expect(pm.response.text()).to.include(expectedTitle); });

上述代码中，首先定义了期望包含的文章标题expectedTitle，然后使用pm.expect(pm.response.text()).to.include(expectedTitle)来判断响应体的文本内容中是否包含该标题。这种方式适用于对响应体进行简单的文本匹配，快速验证某些关键信息是否存在于响应中。

当 API 返回的响应体是 JSON 格式时，我们经常需要验证 JSON 数据中的某个字段值是否符合预期。比如，一个用户登录接口返回的 JSON 数据中包含 "token" 字段，我们要验证这个 "token" 字段是否存在且不为空，代码如下：

复制代码

pm.test("响应体中token字段存在且不为空", function () { var jsonData = pm.response.json(); pm.expect(jsonData.token).to.exist; pm.expect(jsonData.token).to.not.be.empty; });

这段代码首先使用pm.response.json()方法将响应体解析为 JSON 对象，存储在jsonData变量中。然后通过pm.expect(jsonData.token).to.exist验证 "token" 字段是否存在，pm.expect(jsonData.token).to.not.be.empty验证 "token" 字段的值是否不为空。通过这种方式，可以对 JSON 格式的响应体进行更细致、深入的验证，确保数据的完整性和正确性。

两者协同实战

综合案例演示

为了更直观地展示 Pre-request Script 和 Tests 脚本如何协同工作，我们以一个电商平台的接口测试为例。假设该电商平台有以下两个关键接口：

用户登录接口：用于用户登录，成功登录后返回用户信息和 token，token 用于后续接口的身份验证。
商品查询接口：需要携带 token 才能访问，根据用户传入的查询条件返回相应的商品列表。

在 Postman 中，我们首先创建一个集合来管理这两个接口的测试。

对于用户登录接口的 Pre-request Script，我们无需特殊处理，因为登录时所需的用户名和密码可以直接在请求参数中手动填写（当然，也可以通过脚本从数据文件中读取，这里为了简化演示，采用手动填写方式）。

在用户登录接口的 Tests 脚本中，我们需要进行以下断言验证：

复制代码

pm.test("登录成功，状态码为200", function () { pm.response.to.have.status(200); }); pm.test("响应体包含token", function () { var jsonData = pm.response.json(); pm.expect(jsonData.token).to.exist; }); // 将token保存到环境变量中，供后续接口使用 pm.environment.set("token", pm.response.json().token);

上述代码首先验证登录请求的响应状态码是否为 200，确保请求成功。然后检查响应体中是否包含 "token" 字段，验证登录接口返回的信息是否完整。最后，使用pm.environment.set("token", pm.response.json().token)将返回的 token 保存到名为 "token" 的环境变量中，以便后续商品查询接口使用。

接下来是商品查询接口的设置。在商品查询接口的 Pre-request Script 中，我们从环境变量中获取 token，并添加到请求头中：

复制代码

var token = pm.environment.get("token"); pm.request.headers.add({ key: "Authorization", value: "Bearer " + token });

这段代码从环境变量中获取名为 "token" 的值，然后向请求头中添加一个名为 "Authorization" 的字段，其值为 "Bearer " 加上获取到的 token，实现了自动添加身份验证信息的功能。

在商品查询接口的 Tests 脚本中，我们进行如下断言验证：

复制代码

pm.test("查询成功，状态码为200", function () { pm.response.to.have.status(200); }); pm.test("响应体包含商品列表", function () { var jsonData = pm.response.json(); pm.expect(jsonData.products).to.be.an('array').and.not.be.empty; });

这里首先验证商品查询请求的响应状态码是否为 200，确保接口请求成功。然后检查响应体中的 "products" 字段是否为非空数组，验证接口是否正确返回了商品列表数据。

通过这样的设置，我们可以看到 Pre-request Script 和 Tests 脚本在整个接口测试流程中紧密配合，Pre-request Script 负责在请求前进行必要的准备工作，如添加身份验证信息；Tests 脚本则在请求响应后对结果进行全面验证，确保接口的功能和数据符合预期。在实际测试过程中，我们可以点击集合运行按钮，依次执行用户登录接口和商品查询接口的测试，快速、准确地判断接口的正确性。

脚本优化与注意事项

优化脚本性能 ：在编写脚本时，应尽量避免复杂的计算和不必要的循环操作，以减少脚本执行时间。例如，在生成随机数作为请求参数时，如果只是简单地需要一个随机数，可以使用Math.random()方法生成一个随机小数，然后根据需求进行简单的转换，而不是编写复杂的算法去生成特定范围内的随机数。同时，合理利用变量缓存，避免重复获取相同的数据。比如在一个需要多次使用某个环境变量的脚本中，将该环境变量获取一次并存储在一个局部变量中，后续直接使用局部变量，而不是每次都通过pm.environment.get()方法去获取，这样可以减少对环境变量的读取次数，提高脚本执行效率。
提高可读性：为了使脚本易于维护和理解，要合理使用注释，对关键代码段进行解释说明。例如，在一个复杂的计算逻辑代码块前，添加注释描述该计算的目的和原理。同时，采用有意义的变量名和函数名，避免使用过于简单或晦涩难懂的命名。比如，将存储 token 的变量命名为 "token"，而不是使用无意义的 "a""b" 等。此外，将功能相关的代码封装成函数，提高代码的复用性和可读性。例如，将验证响应状态码和响应体的断言逻辑封装成一个函数，在不同的接口测试脚本中可以直接调用该函数，而无需重复编写相同的断言代码。
安全问题：在脚本中避免硬编码敏感信息，如用户名、密码、API 密钥等。这些信息应通过环境变量或其他安全的方式进行传递和管理。比如，将登录密码存储在环境变量中，在 Pre-request Script 中从环境变量获取密码并用于登录请求，而不是直接将密码写在脚本代码中，防止密码泄露。同时，注意处理异常情况，确保脚本在出现错误时不会导致安全漏洞。例如，在发送请求时，如果出现网络错误或请求失败，应进行适当的错误处理，避免因为错误信息暴露敏感的系统信息或导致后续请求出现异常行为。
常见错误及解决方法：在编写脚本过程中，常见的错误包括语法错误、变量未定义、断言失败等。对于语法错误，Postman 会在脚本编辑器中以红色波浪线提示错误位置，我们可以根据提示仔细检查代码语法，确保语句正确。变量未定义错误通常是由于变量名拼写错误或作用域问题导致的，在使用变量前，要确保变量已经被正确定义和赋值，并且在正确的作用域内访问变量。如果断言失败，要仔细检查断言条件是否正确，以及响应数据是否符合预期。例如，在验证响应体中某个字段的值时，要确保字段名称拼写正确，并且响应数据中确实包含该字段。同时，可以通过打印响应数据和变量值，辅助调试，找出断言失败的原因。

总结与展望

在本次关于 Postman 进阶的探索之旅中，我们深入剖析了 Pre-request Script 和 Tests 脚本的强大功能与应用场景。Pre-request Script 作为请求前的 "幕后英雄"，能够灵活地进行数据预处理、参数动态生成以及请求头设置等操作，为 API 请求的顺利发送奠定了坚实基础。而 Tests 脚本则如同严谨的 "质量检验员"，在响应到来后，通过各种断言对响应状态码、响应体和响应头进行细致入微的验证，确保 API 返回的结果符合预期，为软件质量保驾护航。

在实际工作中，无论是复杂的微服务架构下的接口测试，还是前后端分离项目中的 API 联调，Pre-request Script 和 Tests 脚本都能大显身手。它们能够帮助我们提高测试效率，减少人为错误，更全面地覆盖各种测试场景，从而有效提升软件开发的质量和稳定性。