1. 关于tests[]断言
对于系统整套接口的测试最好是建立系统相关的Collection，便于以后测试，测试脚本采用的是JavaScript语法编写，脚本主要写的位置在Pre-request Script和Tests两个栏目中，Pre-request Script主要用于在请求发送之前执行，Tests用于请求发送之后执行，在Postman中也提供了一些简单的断言，比如：
// 判断返回的状态码是否为200
tests["Status code is 200"] = responseCode.code === 200;
// 判断返回的内容中是否存在指定关键字
tests["Body matches string"] = responseBody.has("关键字");
// 判断返回内容是否跟预期完全相等。
tests["Body is correct"] = responseBody === "预期的内容";
// responseBody为字符串类型，支持转为 Json 格式
var jsonData = JSON.parse(responseBody);
tests["Your test name"] = jsonData.value === 100;
// 判断请求时长是否小于200ms ,具体时长按情况自定义
tests["Response time is less than 200ms"] = responseTime < 200;
上述test命令的语法基本是：
test["类似于函数名字"] = 一个判断条件
函数名字可以随缘嘛，只要见名知意就行了(比如上面判断状态码是否为200就是Status code is 200)，判断条件可以是各种形式，比如数值、字符串的相等可以用===、响应体中包含关键字可以用responseBody.has("关键字")函数、以及>、<等等，只要最后返回的是一个布尔值即可，为true即表示通过，false为失败，tests的直接赋值作用比较局限，如果在脚本中进行一些其他异步操作，则需要用到pm.test了，比如：
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
一般使用test赋值和pm.test/pm.expect已经可以满足基本的测试需求了。也可以在测试请求拿到结果后再根据这些结果发送新的新的请求，然后添加断言，如：
// 将JSON响应体转成json
let responseJSON = JSON.parse(responseBody)
// 获取关注的第一个用户，并请求他的用户信息
pm.sendRequest(responseJSON[0].url, function (err, response) {
let responseJSON = response.json()
pm.test('has email', function () {
pm.expect(responseJSON.email).is.be.true // 如果用户email不存在，断言则会失败
})
});
如果我们有一些动态接口要进行测试，可以尝试这种写法，一级接口返回List，二级接口根据List的ID进行获取对应信息。
【注意】
这里提一下我做的时候犯得一个蠢错误，一般后台都是返回给前端下面这副小东西：
{
"code": "xxx",
"message": "xxx",
"data": <T>
}
我在断言的时候写了这么一个脚本：
tests["code:success"] = responseBody.has("success");
很马虎，居然用responseBody去断言code中有没有success，无限扩大了断言范围，极有可能造成误断(message或data中出现success可咋整啊)，比较合适的方式为：
pm.test("code:success", function () {
var jsonData = pm.response.json();
pm.expect(jsonData.code).to.eql("success");
});
2. 关于变量global和environment
Postman提供了两种变量：一个是global，一个environment。其中global可以像下面这样操作：
pm.globals.set("variable_key", "variable_value") // set variable
pm.globals.get("variable_key") // get variable
pm.globals.unset("variable_key") // remove variable
上述是使用脚本的方式设置global变量，这一点在Account中很实用，用户在登录后可以直接利用pm.globals.set("variable_key", "variable_value")的方式将cookie设置到全局变量中，这样后续的操作就可以利用这个cookie获取到用户的状态是登录的状态。变量设置完，可以在测试的URL中使用{{..}}双括号的形式包裹global变量来使用。
environment变量的权重要比global变量更高一些，针对某些环境来进行设置，操作方式和上述类似（也是用双花括号的形式包裹变量即可），在发起请求(一个或多个)时，可以勾选对应的环境来使用不同的变量，environment变量可以使用的位置如下：
URLURL paramsHeader valuesform-data/url-encoded valuesRaw body contentHelper fields
在对大量API测试时，使用environment设置domain和context-path是比较推荐的，比如：
// 在环境管理中配置一个domain变量，值为https://api.github.com
domain: https://api.github.com
// 使用双括号的形式在URL中引用环境变量
{{domain}}/res1
{{domain}}/res2
具体设置环境变量时可以这么干：
postman.setEnvironmentVariable("variable_key","variable_value");
postman内部也提供了三种随机数的生成方式（未测试通过）：
{{$guid}}：添加一个V4风格GUID；{{$timestamp}}：将当前的时间戳，精确到秒；{{$randomInt}}：添加0和1000之间的随机整数；
3. Run Collection
在自动化测试过程中，通常是通过 Run Collection 的方式一次跑大量的API，Collection 建好后直接点击左上方的Runner按钮，即可进入界面，对其中的几个参数做一些说面：
上述界面的参数依据实际情况进行设置即可。
关于接口的执行顺序
默认情况下，接口是按照我们编写的顺序执行的，即接口在前面的就先执行，在后面就后执行，如果想手动指定接口的执行顺序，可以在接口的Tests一栏中使用setNextRequest函数指定下一个要运行的接口，如：
# 当前接口运行完毕后就会继续运行Request2接口，而不管位置上在它下一个的接口
postman.setNextRequest("Request2");
4. 变量解析
在通过postman中在RequestBody中放List，遇到JSON解析问题，原来是要往里面塞一个List<Long> feedbackIds，后来在postman中直接这么放的：
{
"feedbackIds":[
1194812025388864,
1195607949901632
]
}
然后出现下面的解析异常：
"exepct '[', but {, pos 1, json : {\n\t\"feedbackIds\":[\n\t\t1194812025388864,\n\t\t1195607949901632\n\t]\n}"
在JSON解析的时候，后端是要的一个List，而前端传过来的确实一个对象(这一块感觉说不太清楚，应该都有这种感觉)，最终直接通过最简单的方式传入得以解决(传入[xx, xx, ..]的形式)，直接将传入的数据改写为：
[
1194812025388864,
1195607949901632
]
很多情况下，API返会给前端的数据都是封装成下面的JSON格式：
{
"code": string,
"message": string,
"data": T
}
在此时断言responseBody中的具体JSON内容时，比如返回的内容为：
{
"code": "invitee.not.reach",
"message": "The Invitee not reach."
}
那在断言的时候先转JSON再取其中的内容进行判断：
// 转成json
var jsonData = JSON.parse(responseBody);
// 取json中具体需要断言的key做判断
tests["check qualification"] = jsonData.message === "The Invitee not reach."
除此外，postman还可以断言 response 的头部信息，如：
// 断言响应头中是否有Content-Type
tests["Content-Type is present"] = responseHeaders.hasOwnProperty("Content-Type");
// 获取Content-Type的值
var ct = postman.getResponseHeader("Content-Type");
// 判断Content-Type的类型是否相符
tests["Content-Type is image/gif;charset=UTF-8"] = postman.getResponseHeader("Content-Type") === "image/gif;charset=UTF-8";
// 判断Cookie的值，cookie一般都是很多cookie一起，中间以分号间隔
var cookied = postman.getResponseHeader("set-cookie");
// 将多个cookie字符串切割为一个个单个的cookie
cookies = cookied.split(";");
// 将该接口写入的cookie中的最后一个设置为postman全局环境变量，从而影响后面接口的测试
postman.setEnvironmentVariable("Cookie",cookies[0]);
// 如果知道了cookie的名字，想直接取这个cookie的值
var cuk_yk = postman.getResponseCookie("cuk_yk").value;
【注意】
上述流程中在获取整个cookie时使用的是postman.getResponseHeader("set-cookie")这个函数，如果这个接口在后台逻辑内部有设置cookie的行为，第一次使用postman测试该接口时postman.getResponseHeader("set-cookie")函数可以获取到设置的cookie的头字段set-cookie，但是一旦这个运行过该接口后cookie被写进去了，没有清cookie运行第二次的时候，postman发现该cookie存在就不会去设置对应的cookie，接口响应体中也不会出现set-cookie头字段，所以最终获取的cookied为null，从而也导致cookied.split(";")函数出现TypeError: Cannot read property 'split' of undefined，因为获取的cookied变量为null，没法调用该函数，很多人会使用(cookied || "").split(";")方式处理来避免这个错误，其中(cookied || "")其实类似于三目运算的过程，如果cookied不为null结果就为cookied，否则结果为一个空串。
5. 具体操作
这里只记录我遇到的一些不太注意的东西，常规操作自行百度，有下面一些：
关于环境变量
在创建环境时，我以为只有在Run Collection时才能使用，然后为了在测试单个接口时，在每个接口的Pre-requestScript中都用脚本写了domain和context-path：
pm.environment.set("domain","http://www.xxxx.com");
pm.environment.set("contextpath","/api");
但实际根本不需要，在配置好环境变量后，在下图的红色框中选用即可：
除此之外，使用脚本配置环境变量和全局变量有一个坑，就是在使用脚本pm.environment.set("variable_key","variable_value");和pm.globals.set("variable_key", "variable_value");配置环境和全局变量时，如果直接通过 Run Collection 的方式，那么这些变量不会记录在postman中，但是如果单独运行(即Send的方式)，这些脚本配置的变量会被postman自动保存(右上角有个眼睛的图标，点一下即可查看)，如果更改变量名的话会影响后续测试，所以在必要时候一定要注意手动清理这些变量。
关于调试或postman输出、打印
postman在写测试脚本的时候也是可以进行简单打印调试的，只是之前没有用过，但不是常规意义上打端点进行debug，而是利用console.log()函数将变量进行输出，关键是输出你最起码有个类似于控制台的地儿啊，这玩意找了大半天，调出postman控制台的操作流程如下：顶部菜单栏View–> Show Postman Console，或者直接快捷键Ctrl+Alt+C，这样在脚本使用console.log()就可以将需要查看的变量显示出来了。