企业官网建设流程全解析

我做接口测试这些年，Postman一直是我最顺手的工具。不管是刚入行的测试新手，还是带团队的资深开发，几乎每个人桌面上都装着一个。但说实话，大多数人只用到了它的皮毛——发个GET请求、填几个Header、看看响应体，然后就没有然后了。一旦遇到需要登录态、依赖上一个接口的返回值、接口又带着签名或加密参数的情况，就开始手动复制粘贴、临时改脚本，效率低还容易出错。

这篇文章我想围绕Postman在接口测试里的三个关键能力展开：全局变量、接口关联、加解密处理。这三个点如果吃透了，你会发现自己处理接口测试项目的效率能上一个台阶，尤其是面对多环境、多接口联动、带加密签名的业务接口时，基本能做到“一套脚本到处跑”。我会把原理、踩过的坑、可以落地的写法都整理出来，适合刚接触接口测试的新手，也适合想系统梳理一下Postman用法的老手。文章里所有代码都是我在实际项目里用过的，不是空谈理论，你可以直接照着抄。

1. 先搞明白：Postman接口测试到底在测什么

很多刚入行的测试同学会把接口测试理解成“用工具发请求看结果”，这个理解不能说错，但太片面了。接口测试本质上是在验证服务端接口的输入输出契约：给定一组入参，接口能不能返回符合预期的响应，状态码对不对、字段全不全、业务逻辑是否正确、异常情况有没有兜底。Postman之所以受欢迎，是因为它把这些能力封装得非常轻量，不需要写完整的测试框架就能上手。

但真正到了实际项目里，接口测试会面临三个绕不开的痛点。

第一个痛点是环境切换。开发环境、测试环境、预发布环境，甚至联调环境，域名不一样、数据库不一样、基础配置不一样。如果你每个环境都手动改URL、改Header，那简直是在给自己挖坑。第二个痛点是接口依赖。登录接口返回一个token，后面的所有接口都要带着这个token；下单接口要先用商品列表接口拿到商品ID，再用库存接口确认数量，最后才能下单。这些依赖关系如果靠人工传递，工作量大不说，还极其容易出错。第三个痛点是参数加密。现在很多业务接口为了防止参数被篡改、数据被窃取，会对请求参数做签名或加密处理，比如MD5签名、AES对称加密、RSA非对称加密。这类接口用浏览器F12能看到，但直接复制到Postman里发出去，服务端很可能返回签名错误。

这三个痛点，恰好对应Postman的三大核心功能：全局变量与环境变量、接口关联（数据传递）、脚本加解密。把这三点解决了，你基本就能应对绝大多数接口测试场景。接下来我逐个展开讲，每个部分都会包含原理、写法和实际项目里的案例。

1.1 工具选型：为什么不用JMeter或Apifox

先说个题外话，免得有人问我“不是有JMeter吗”“Apifox不也挺火吗”。工具没有绝对的好坏，只有适配的场景。JMeter做压测和复杂性能测试确实比Postman强，但它的学习曲线陡，脚本调试起来没那么直观，日常接口联调用它就跟用大炮打蚊子似的。Apifox在一些团队里也流行，接口文档管理做得不错，但如果你想在脚本里做复杂的动态参数、自定义加密逻辑，Apifox的生态和资料相对少一些，遇到问题不好搜。

Postman的优势在于三点：一是社区资料最多，基本上你踩过的坑，别人早就踩过并且在Stack Overflow里写了答案；二是脚本能力基于JavaScript，几乎所有的加解密逻辑都能在Pre-request Script和Tests里实现，你不需要额外准备Java或Python环境；三是Collection和Environment的文件式管理非常适合团队协作，导出成JSON就能分享，配合Newman甚至可以做持续集成。所以我个人建议，日常接口测试、联调、排查问题，Postman是目前综合成本最低的方案。

2. 全局变量：从环境隔离到脚本读写

全局变量这个概念，听起来很简单，就是定义一些可以在所有请求中引用的参数，但实际用起来有不少讲究。我见过不少人在每个请求里硬编码URL和token，测试环境一换，所有请求全得改一遍，那种痛苦我太理解了。所以这一节我不只讲“怎么设置变量”，更重要的是讲清楚变量的作用域、优先级和脚本读写方式。

2.1 环境变量与全局变量的区别与适用场景

Postman里有三种范围的变量：全局变量（Global）、环境变量（Environment）、局部变量（Local/Data）。全局变量在所有环境、所有请求里都可以使用，适合存放比较固定的信息，比如公司统一的AppKey、公共的秘钥前缀、基础地址的兜底值。环境变量则是绑定在某一个环境下面的，比如dev环境有dev的baseUrl和数据库配置，test环境有test的一套，切换环境时这些变量会自动切换。

我实际项目里最常用的组合是：全局变量存一些不变的安全参数，环境变量存每个环境不一致的配置项。举个例子，我在一个金融类项目的接口测试里，接口地址和数据库状态每个环境都不同，但接口签名里的固定盐值（salt）是同一个（当然，这只是测试环境的约定，生产环境的盐值绝对不会这么存）。于是我把baseUrl、merchantId放在环境变量里，把salt、version放在全局变量里。这样在不同环境间切换时，我只需要在下拉框里选一下环境名，所有请求就自动指向对应的服务，签名逻辑也不用改。

注意：全局变量虽然方便，但不能滥用。如果团队里有人偷偷把某个环境的密钥写进全局变量，导出Collection时就会把密钥一起带出去，这是很危险的操作。我自己的习惯是，涉及密钥、密码类信息，要么从环境变量里读取，要么直接从外部文件读取，绝不放全局变量。

2.2 变量作用域优先级，你真的搞懂了吗

我见过一个比较隐蔽的坑：在同一个请求里，定义了一个局部变量，名字恰好和全局变量一样，结果脚本运行出来的值和预期不符。这就是优先级问题。

Postman的变量解析顺序从高到低是这样的：局部变量（Local variables） > 数据变量（Data variables） > 环境变量（Environment variables） > 集合变量（Collection variables） > 全局变量（Global variables）。也就是说，只要当前作用域里有同名的局部变量，环境变量和全局变量都会被“遮蔽”。

所以，如果你发现一个变量怎么都不生效，别急着怀疑代码，先检查一下是不是在请求的脚本里意外声明了同名局部变量。我遇到过最头疼的一种情况，是同事在Pre-request Script里写了一句pm.variables.set("token", "xxx")，这个操作实际上是在当前请求作用域里生成了一个临时局部变量，运行结束后就销毁了，并不会影响到下一个请求。结果下层接口拿不到token，排查了好久才发现是这个原因。

2.3 用脚本读写变量的正确姿势：pm对象与sandbox

Postman从v7开始全面拥抱pm这个全局对象，所有的读写操作都推荐通过pm.*系列API来做。我早期还在用老版本的postman.setEnvironmentVariable()写法，后来升级后发现新写法更顺手，而且官方推荐也是新写法。

常用操作我整理了一份，几乎每个项目都会用到：

// 获取变量，推荐这种写法，支持传默认值 const baseUrl = pm.environment.get("baseUrl"); const token = pm.globals.get("token") || "default-token"; // 设置变量 pm.environment.set("token", responseJson.data.token); pm.globals.set("appKey", "b1094f8c"); // 清除变量 pm.environment.unset("tempId"); pm.globals.unset("tempId"); // 获取当前环境名，方便调试输出 const envName = pm.environment.name;

这里要注意，pm.environment.get()只能获取当前环境下的变量，如果变量定义在全局作用域里，就要用pm.globals.get()。两个都取不到，再考虑pm.variables.get()，这个方法会自动按照优先级去查，适合写通用函数时用。

实际写脚本时，我习惯把一些常用的函数抽到Collection级别的Pre-request Script里，比如统一的签名逻辑、统一的时间戳生成、统一的参数拼接函数。Collection级别的脚本会在Collection内所有请求发送前执行，相当于给整个集合挂了一层“公共方法层”。这个设计在多个请求都需要签名时非常省事，你只需要在每个请求的脚本里调用已经定义好的函数就行。

3. 接口关联：把上一个接口的响应变成下一个接口的入参

接口关联是接口测试里最核心、也最容易被忽略的技能。很多人做接口测试能做到“一条链路跑通”，但链路里的数据全是手工从上一个响应里复制到下一个请求里的，一旦某个响应字段变了，整条链路就崩。真正的接口关联，是让Postman自动从上一个接口的响应中提取数据，保存成变量，再在下一个请求里自动引用。

3.1 核心原理：在Tests脚本里提取响应数据并存入变量

Postman执行请求后，响应体数据可以在Tests脚本里通过pm.response对象访问。常见的响应格式是JSON，所以最常用的是pm.response.json()，把响应体解析成JavaScript对象，然后用JS语法从里面取值。

举一个经典的登录-获取Token的例子。登录接口的响应体长这样：

{ "code": 0, "message": "success", "data": { "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9", "userInfo": { "userId": 1024, "username": "test_user" } } }

那我就在登录请求的Tests里写：

const res = pm.response.json(); if (res.code === 0 && res.data.token) { pm.environment.set("token", res.data.token); pm.environment.set("userId", res.data.userInfo.userId.toString()); console.log("Token saved:", res.data.token); } else { console.error("Login failed:", JSON.stringify(res)); // 断言失败时可以主动抛出异常，方便在测试报告里看到 pm.expect(res.code).to.eql(0); }

这段代码执行后，token和userId就已经被存进了当前环境的环境变量里。之后其他接口发送时，在Headers或者Params里写{{token}}就能自动替换成刚才保存的值。

提示：pm.response.json()在响应体不是合法JSON时会直接抛异常，所以如果响应内容是HTML或者字符串类型，建议先判断pm.response.headers里的Content-Type，或者用pm.response.text()取原始文本再自己做解析。

3.2 关联方法大全：JSON提取、正则提取、Header提取、Cookie处理

JSON提取是最常见、也最简单的方式，但实际项目中响应体可不一定总是标准的JSON。有些老系统会返回XML，有些网关会包一层加密字符串，有些响应数据嵌在很深的层级里，光靠res.data.token这种路径提取可能就够了，但深层嵌套时也可以明确写全路径，甚至用res.data.list[0].id这种带索引的写法。

除JSON以外，还有几种场景值得掌握正则提取。比如有些接口返回的是纯文本，中间夹着一小段动态生成的东西，比如一个确认链接https://example.com/verify/abc123def456，你要把这个链接里的abc123def456提取出来。这时就用JS的match方法：

const text = pm.response.text(); const matched = text.match(/\/verify\/([a-f0-9]{12})/); if (matched) { pm.globals.set("verifyCode", matched[1]); }

Header提取适用于token不是放在响应体，而是放在响应头里的场景，这种设计在OAuth2.0或某些自定义认证体系里常出现。代码如下：

const authHeader = pm.response.headers.get("Authorization"); if (authHeader) { pm.environment.set("authHeader", authHeader); }

Cookie处理在登录类接口里也很常见。有些系统不用token，而是通过Set-Cookie来做会话保持。Postman对Cookie有自动管理的功能，但如果你需要手动取Cookie值，可以这样写：

const jar = pm.cookies.jar(); jar.getAll("https://api.example.com", (error, cookies) => { if (error) { console.error("Get cookies error:", error); return; } cookies.forEach(cookie => { console.log(cookie.name + " = " + cookie.value); if (cookie.name === "SESSION") { pm.environment.set("sessionId", cookie.value); } }); });

这段代码里的回调是异步的，所以如果后续请求依赖这个cookie，建议在Tests里设置完成后，由下一个请求再读取。只要链路顺序正确，一般不会出现竞态问题。

3.3 批量参数关联与动态数组处理

单个字段的关联并不难，真正麻烦的是关联一组数据。举个例子，商城项目里“一键下单”接口，需要把购物车里的多个商品ID和数量一起传过去，而这些商品ID是上一个“查询购物车列表”接口返回的。购物车可能随时变化，不能写死，也不能只取第一个商品。

面对这种情况，我通常的做法是在Tests脚本里循环遍历响应数据，把需要的字段拼成数组或字符串，再存成变量：

const res = pm.response.json(); const cartItems = res.data.items; if (cartItems && Array.isArray(cartItems)) { const ids = cartItems.map(item => item.goodsId); const quantities = cartItems.map(item => item.quantity); pm.environment.set("goodsIds", JSON.stringify(ids)); pm.environment.set("goodsQuantities", JSON.stringify(quantities)); }

在下一个请求的Body里，可以用{{goodsIds}}引用，但这个引用语法只能替换字符串，如果你的接口要求传真正的JSON数组格式，建议在Pre-request Script里用JSON.parse(pm.variables.get("goodsIds"))解析成数组，再用JSON.stringify()覆写：

const rawIds = pm.variables.get("goodsIds"); const ids = rawIds ? JSON.parse(rawIds) : []; pm.environment.set("goodsIdsJson", JSON.stringify(ids));

然后Body里的raw内容就直接写成{{goodsIdsJson}}占位符。这样处理完，即使商品数量增加，脚本也能自动适配，不用手动改请求体。

3.4 链式关联：三级甚至四级接口依赖怎么设计

有些业务链路比较长，接口依赖是层层递进的。比如：登录拿token -> 用token查用户列表 -> 选中某个用户查其订单列表 -> 选中某个订单查订单详情。这种链路如果在一个请求的Tests里把所有变量都存好，下一个请求再存新的变量，是能跑通的，但脚本会越来越乱，调试的时候也不好定位问题。

我的习惯做法是给每个请求的Tests脚本都明确区分责任，只维护自己需要传递的变量。同时会开启Postman的Request Logging和Console打印，在每个关键步骤把变量值打出来，比如：

console.log("[Associate] step1 token:", pm.variables.get("token")); console.log("[Associate] step2 userId:", pm.variables.get("userId")); console.log("[Associate] step3 orderId:", pm.variables.get("orderId"));

这样一条链路跑下来，打开Postman的Console面板，就能很清楚地看到数据在每一步之间是如何流转的。如果某一步失败了，也能快速定位是哪一级接口出了问题，而不是满屏请求一条条点开看响应。

4. 加密与解密：接口签名、AES、RSA等场景如何落地

接下来聊很多人觉得高深的部分：加密与解密。接口测试里遇到的加密，大致可以分成两类。一类是请求参数加密，就是发送给服务端的数据本身被加密了，比如用户手机号、身份证号用AES加密后再传输；另一类是请求签名，就是对所有参数按规则拼接后做一个哈希或MAC计算，生成一个签名串，服务端验证通过后才处理。这两类问题，Postman都能通过Pre-request Script和Tests脚本解决，因为它们本质上都是JavaScript可以实现的。

4.1 先弄清楚：你的接口用的是哪种加密方式

不要一上来就写代码，先搞清楚接口的加密规则。我一般先看接口文档和前后端联调时留下的蛛丝马迹，实在没有就抓一个正常请求看一下。常见的加密方式有这些：

MD5签名：把参数按key排序后拼接，加上salt，然后做MD5。这种方式最常见，也最容易实现。SHA系列签名：和MD5类似，但用的是SHA-1/SHA-256，安全性更高。AES对称加密：前端和服务端共享一个密钥，加密和解密用同一个key。特点是计算快，但密钥管理是个问题。RSA非对称加密：前端用公钥加密，服务端用私钥解密。对前端来说，只需要知道公钥就能加密，Postman里也可以用公钥做加密。

我实际项目中碰到的加密接口，80%以上都是“参数拼接+MD5/SHA”，剩下的大部分是AES，极少数是RSA。新手不用一开始就把这几种全学会，先把MD5和AES吃透，就能覆盖绝大多数业务测试场景了。

注意：Postman的脚本是运行在沙箱环境里的，它内置的CryptoJS库可以处理MD5/SHA/AES等常见算法，你不需要额外引入别的依赖。这一点很方便，直接用var CryptoJS = require("crypto-js")或者直接通过全局的CryptoJS对象调用即可。

4.2 实战：Pre-request Script实现MD5签名+时间戳

下面这个例子是我在某个物流开放平台项目里实际用过的签名方案。规则是：参与签名为appId、timestamp、bizParams三个字段，按字段名的ASCII码升序排列，拼接成字符串后加上盐值，再做MD5。

请求头里需要传appId、timestamp、sign三个字段。每个请求发出前，都要计算一次新的sign。直接在Pre-request Script里写：

// 读取环境变量和全局变量 const appId = pm.environment.get("appId"); const salt = pm.globals.get("salt"); // 生成13位毫秒级时间戳 const timestamp = Date.now(); pm.environment.set("timestamp", timestamp.toString()); // 获取请求里的业务参数（假设接口Body是一个JSON对象） const bizParams = pm.request.body.raw ? JSON.parse(pm.request.body.raw) : {}; // 实际项目中，业务参数可能需要按规则做序列化，这里简化处理 const bizParamsStr = JSON.stringify(bizParams); // 按规则拼接 const rawStr = `appId=${appId}&bizParams=${bizParamsStr}&timestamp=${timestamp}${salt}`; // 计算MD5 const sign = CryptoJS.MD5(rawStr).toString().toUpperCase(); pm.environment.set("sign", sign); console.log("Raw string:", rawStr); console.log("Generated sign:", sign);

在请求头里把timestamp和sign变量引用上，这个请求发送时就会自动携带正确的签名。之后哪怕你改了Body里的业务参数，只要重新发送，Pre-request Script就会重新计算签名。

这个例子看起来不难，但有几个细节我要重点提醒。一是时间戳的一致性：签名用的时间戳和Header里传的时间戳必须是同一个值，否则服务端校验会发现签名时间对不上，直接拒绝。所以我计算完时间戳后会立刻存进环境变量，Header里用的是同一个变量。二是Boby参数序列化顺序：很多服务端的签名规则是把Body里某个核心参数提取出来拼接，并不是简单的JSON.stringify全量字符串，这个一定要以具体接口文档为准，不能照搬我上面的简化写法。三是签名转大写还是小写：这个也要以服务端规则为准，有的服务端统一转大写，有的统一转小写，两边不一致就会签名失败。

4.3 实战：AES加密与解密处理

再举一个AES加密的例子。我在做某电商App的后台接口测试时，有一个“保存用户手机号”的接口，需要把手机号和验证码用AES-CBC模式加密后再放入Body。Postman脚本里可以这样处理：

// AES配置，密钥和偏移量一般从环境变量取 const aesKey = CryptoJS.enc.Utf8.parse(pm.environment.get("aesKey")); const aesIv = CryptoJS.enc.Utf8.parse(pm.environment.get("aesIv")); // 待加密数据，从请求Body中读取 const plainText = "13800138000|123456"; // AES-CBC加密，注意输出格式是Base64字符串 const encrypted = CryptoJS.AES.encrypt(plainText, aesKey, { iv: aesIv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString(); pm.environment.set("encryptedPhone", encrypted); console.log("Encrypted result:", encrypted);

加密这段是Postman发给服务端的，而解密则通常用在Tests脚本里。有些接口的响应数据也是加密的，要先解密才能断言里面的业务字段。解密的写法是对称的：

const encryptedResp = pm.response.text(); const decryptedBytes = CryptoJS.AES.decrypt(encryptedResp, aesKey, { iv: aesIv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); const decryptedText = decryptedBytes.toString(CryptoJS.enc.Utf8); console.log("Decrypted response:", decryptedText); // 解析成JSON后做断言 const data = JSON.parse(decryptedText); pm.expect(data.code).to.eql(0);

用AES的时候有几个非常容易踩的坑。一是Key和IV的格式：AES要求密钥长度固定是16/24/32字节，很多项目里给的密钥是明文字符串，你得确定它是直接用UTF-8解析成字节，还是Hex字符串。Postman里如果用CryptoJS.enc.Utf8.parse()和CryptoJS.enc.Hex.parse()得到的结果完全不一样，一个搞错就解密出来一堆乱码。我在项目里就吃过这个亏，后来养成了先拿一个已知明文密文对做回环验证的习惯，确认解析方式对了再写进脚本。二是加密后密文格式：有的服务端返回的是Hex字符串，有的是Base64，还有的在Base64基础上又做了URLEncode。这个需要看服务端代码或者联调文档。三是字符编码：如果加密前的内容包含中文，一定要统一用UTF-8，否则服务端用UTF-8解密出来中文还是乱码。

4.4 动态参数生成：随机数、UUID、时间窗口参数

加密签名里经常会用到随机数、UUID、时间戳这些“动态因子”。Postman的脚本里可以用以下方式生成：

// UUID const uuid = require("uuid"); const traceId = uuid.v4(); pm.environment.set("traceId", traceId); // 随机数 const randomNum = Math.floor(Math.random() * 1000000).toString().padStart(6, "0"); pm.environment.set("randomNum", randomNum); // 当前时间戳（秒级 + 毫秒级） const timestampSec = Math.floor(Date.now() / 1000); const timestampMs = Date.now(); // 时间窗口：比如最近30分钟内的某个时间 const startTime = timestampMs - 30 * 60 * 1000;

这些动态因子有一个共同特点：每次请求都不一样，不能写死在请求里。把它们放在Pre-request Script里生成，既保证了每次都能拿到新值，又让签名逻辑始终能引用到同一个变量。实际接口性能测试时，这种动态参数的设计也很有价值，避免了所有请求都带着一模一样的traceId导致服务端报重复请求的错误。

另外还有一个很小的技巧：有些接口要求请求体中必须有“随机盐”字段，用于加密手机号或身份证号。这个随机盐如果写死在环境变量里，那每次加密结果都一样，很容易被服务端识别为重放攻击。正确做法是每次生成一个随机盐，用这个随机盐去加密数据，并且把这个随机盐放在请求体里一起传过去，方便服务端知道怎么解密。代码看起来是这样：

const randomSalt = CryptoJS.lib.WordArray.random(8).toString(); const encryptedData = CryptoJS.AES.encrypt(plainText, randomSalt, { iv: aesIv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString(); pm.environment.set("randomSalt", randomSalt); pm.environment.set("encryptedData", encryptedData);

5. 常见问题与排查技巧实录

前面写了很多实操细节，最后把我和团队在实际项目里经常遇到的问题统一整理一下，做成一份“速查表”，方便你遇到问题时直接对照排查。这些问题都是真实的，不是凭空想象出来的。

5.1 高频问题速查表

5.2 排查思路速成：拿到一个加密类接口问题，先这样做

如果你是第一次接触加密接口，而且一遍跑不通，我的建议是不要着急改脚本，先按这个顺序排查一遍：

第一步，确认你是否有“标准答案”。最好能拿到一个由正常前端或服务端生成的请求样例，包含完整的明文、拼接规则、密文或签名结果。如果拿不到，就找开发要一段生成签名的单元测试代码或日志。第二步，用Postman的Console打印出你脚本里生成签名时的原始拼接字符串，与接口文档里的规则逐字比对。很多问题就出在拼接的时候多了一个空格、少了一个&，或者字段顺序不对。第三步，单独在外部工具里验证一下MD5或AES算法本身对不对。比如你在命令行里用同样的字符串算一次MD5，看和Postman脚本里的输出是否一致，这一步能快速排除算法库用法错误。第四步，如果算法没问题，那就是参数或环境的问题，重点检查时间戳、随机数、盐值是否被某些缓存导致一致了。

提示：Postman的Console面板在排查时非常有用。只要在脚本里写了console.log()，发送请求后Console就会实时输出变量值。我几乎在每一个接口的Pre-request Script里都会加一行“最终签名串”的日志，这样出了问题能立刻看到实际参与计算的数据是什么。

5.3 组织接口用例的三条实战经验

最后分享三个我长期坚持使用的小经验，它们不算具体某个功能，但对项目的可维护性帮助特别大。

第一条，每个Collection都要有清晰的目录结构。我习惯按“认证模块-用户模块-订单模块-支付模块”这样划分，每个模块下再按正向用例、异常用例、边界用例分子文件夹。这样不管是自己回归还是交接给同事，都很清晰。

第二条，请求命名要带场景。不要叫“查询订单1”“查询订单2”，要叫“查询订单-存在商品-返回200”“查询订单-商品已下架-返回错误码2001”。命名越具体，后面维护时就越不需要点开一个个请求看Body。

第三条，尽量用Collection Runner或Newman跑全量回归。手点一遍是正常开发时的状态，真正验收时要让Collection在Runner里按顺序执行，并且写清断言。Postman Runner支持数据文件（CSV/JSON），可以把不同的参数组合批量跑完，然后导出测试报告。把这一步接入CI流程后，接口测试这件事才算真正闭环了。

一些心里话

Postman这个工具，上手容易，深入之后其实有不少学问。我今天讲到的全局变量、接口关联、加解密，只是接口测试里最常用的三个板块，但项目复杂起来之后，你还可能会用到Mock Server、Monitors、Newman、API文档管理这些进阶功能。工具是死的，人的思路是活的——重要的是，你在用这些功能时，能真正理解变量在什么时候替换、脚本在什么阶段执行、加密规则到底怎么拼的，这些底层逻辑搞懂了，不管用什么工具都不慌。

我回想自己刚接触接口测试那会儿，遇到加密接口就头皮发麻，觉得“这哪是测试，这是在解谜”。如今经历的项目多了，再回头去看，其实每一套加密规则的背后，都逃不开“参数拼接+摘要算法”或“对称/非对称加密”这些基本套路。把这些套路在Postman里玩熟了，你不但能测得更快，还能在跟开发沟通时说出“你这里的签名拼接规则是不是少了个换行符”这种让对方一愣然后心服口服的话。希望这篇文章能帮你少走一些弯路。如果你在实操中遇到别的怪问题，不妨先把Console日志打开，逐条对一遍原始数据，答案很多时候就藏在那里。