Postman进阶使用技巧与接口测试实战经验分享

Postman环境变量那点破事儿

今天又被Postman的环境变量搞了一脸懵逼，本来以为很简单的事情，结果折腾了快两个小时。主要是项目里有多个环境要切换，本地开发、测试服务器、预发布环境，每次切换都要手动改一堆配置，烦死了。

最早的时候我是直接在请求URL里写死地址的，比如 http://localhost:3000/api/user，然后到测试环境改成 http://test.example.com/api/user。每次换环境都得一个请求一个请求地改，累得要命。后来想用环境变量来统一管理，结果发现自己对这块的理解有偏差。

环境变量的基本用法其实挺简单

这里我踩了个坑，就是环境变量的语法搞错了。Postman里的环境变量要用双大括号包起来，像这样：

// 正确写法
GET {{baseUrl}}/api/user
// 错误写法  
GET {baseUrl}/api/user

还有就是全局变量和环境变量的区别，我当时也没搞清楚。全局变量所有环境都能用，环境变量只在当前激活的环境生效。一般我会把不同环境的base URL设成环境变量，把一些公共参数设成全局变量。

动态设置环境变量的几种方法

最头疼的是怎么在代码里动态设置环境变量。一开始我以为只能手动在界面里点点点，后来发现可以在Pre-request Script里设置：

// 在Pre-request Script里设置
pm.environment.set("token", pm.response.json().data.token);

这样就可以在登录接口返回token后，自动把这个token存到环境变量里，后面的请求就能直接用了。这个功能挺实用的，特别是做用户认证相关的接口测试。

不过这里有个需要注意的地方，就是设置环境变量的时机。如果在Test script里设置，当前请求已经发出去了，要到下次请求才能用上新的变量值。所以要提前到Pre-request Script里设置。

JSON解析的那些坑

折腾了半天发现一个问题，就是response数据有时候解析不了。错误信息是”Cannot read property ‘data’ of undefined”，找了半天才发现是响应数据格式的问题。

有些接口返回的数据不是标准JSON格式，或者字段名跟预期的不一样。后来写了段容错代码：

try {
    var responseJson = pm.response.json();
    if(responseJson && responseJson.data && responseJson.data.token) {
        pm.environment.set("token", responseJson.data.token);
    } else {
        console.log("Response doesn't contain expected token field");
    }
} catch (e) {
    console.log("Failed to parse JSON response:", e.message);
}

这样即使某些接口响应格式不对，也不会影响整个测试流程。

Collection Runner里的变量传递

用Collection Runner跑一系列接口的时候，环境变量的传递又是个问题。刚开始发现前面接口设置的环境变量，在后面接口里用不了，查了一下发现需要在Collection级别设置变量才行。

在Collection的Variables tab里定义的变量，整个Collection内的请求都可以共享。这样就可以保证登录接口设置的token，在后续的用户信息查询接口里能正常用到。

脚本批量更新环境变量

还有一个场景，就是环境切换时需要批量更新很多变量。手动一个个改太麻烦，后来写了个脚本来处理：

// 批量设置环境变量
var envConfig = {
    "development": {
        "baseUrl": "http://localhost:3000",
        "apiVersion": "v1",
        "timeout": "5000"
    },
    "testing": {
        "baseUrl": "http://test.jztheme.com",
        "apiVersion": "v1",
        "timeout": "3000"
    },
    "production": {
        "baseUrl": "https://api.jztheme.com",
        "apiVersion": "v1", 
        "timeout": "2000"
    }
};

// 获取当前环境名称
var currentEnv = pm.environment.get("currentEnvironment") || "development";
var config = envConfig[currentEnv];

if(config) {
    Object.keys(config).forEach(function(key) {
        pm.environment.set(key, config[key]);
    });
}

只要在collection的第一个请求里加上这段Pre-request Script，就能根据当前环境名称自动设置对应的变量值。虽然这个方法不是最优雅的，但确实解决了频繁切换环境的问题。

环境同步的麻烦事儿

另一个让人头大的问题是团队协作。Postman的环境默认是本地的，团队成员之间的环境配置经常不一致。后来发现可以用Postman的同步功能，把环境配置共享给团队。

但这又带来了新问题，就是不同开发人员可能需要不同的配置。比如A同事在本地开发，B同事在测试服务器调试，配置肯定不一样。最后我们约定了一套标准化的环境变量命名规范，每个人维护自己的环境配置，但变量名保持一致。

变量的作用域问题

还遇到过一个诡异的问题，就是在不同作用域下的变量冲突。Postman的变量作用域有四个层级：local > environment > collection > global。local是单个请求级别的，environment是环境级别的，以此类推。

当时发现某个变量值总是不对劲，查了半天才发现是在collection级别设置了，但某个特定请求里又临时改了，导致后面的请求用了错误的值。理解了这个作用域机制后，就把不同类型的变量放到合适的作用域里：

• 全局配置用global变量
• 环境相关用environment变量
• 临时调试用local变量

这样就不会相互干扰了。

总结一下

以上是我踩坑后的总结，主要是环境变量的使用姿势要掌握好，还有就是错误处理要做好。虽然Postman的环境变量功能看起来简单，但实际用起来还是有不少细节需要注意的。

如果你有更好的环境变量管理方案，欢迎评论区交流。反正我现在这套方法虽然不算完美，但至少能满足日常开发需求了。