postman做接口自动化测试

• 可能是目前最好用的web接口调试工具
• 无需注册（注册后可多终端同步用例）
• 免费（每年付费$60可用云服务，30天免费试用）
• 保存历史记录
• 支持录制请求
• 基于Chrome的V8引擎，支持JS脚本（基本支持ES6，浏览器相关对象和API和require() import等除外）
• 同样的代码和用例可用于自动化接口测试，见它的命令行版本Newman介绍
• 能生成各种语言的HTTP请求代码模板
• 能生成比较好看的在线API文档（支持MarkDown）
• 提供简易版持续集成（Monitor功能，只支持公网IP的请求…不如Jenkins实用）

选它的做自动化测试的理由：

• 满足互联网公司的多数场景
• 超轻，比另一个热门选择——JMeter门槛低、开发效率高、界面顺眼
• 开发几乎人手一个，容易沟通，容易推动开发自测
• 容易拉功能测试入坑，发生人员变动时容易交接

不选它的理由：

• 功能受限：Postman运行在沙盒里，Newman虽然基于Node.js，但一套脚本2边共用决定了它的功能不能比Postman多，无法用在以下场景：

• 需要读写文件
• 需要读写数据库
• 需要引入外部库，如不常见/自定义的加密方式
• 非HTTP协议

• 毕竟是调试小工具出身，和成熟的自动化测试框架在管理用例、代码复用、稳定性、报告，甚至易用性上都有明显差距，用的人要有足够能力从坑里爬出来
• 如果项目经常用JMeter做接口测试，有人足够熟悉JMeter，可以考虑把脚本拆分到单个接口的粒度，花点功夫把功能和性能自动化都做了，不用维护2套
• 如果全英文和缺乏中文资料也算的话

---

安装

https://www.getpostman.com/apps

建议选择Mac/Windows app，比起Chrome app，下载不需要FQ，功能更强大

---

基本使用

官方文档

教程

接口测试工具 postman, 2016-09-01（基于Chrome版的Postman，和桌面版大同小异）

[API 测试]postman, 2016-02-29

API自动化测试利器——Postman, 2015-09-26（教程里的版本比较旧了，但还是讲得不错）

How to write powerful automated API tests with Postman, Newman and Jenkins, 2015-09-03

How to write automated tests for APIs using Postman – Part 1, 2014-03-07

How to write automated tests for APIs with Postman – Part 2, 2014-04-17

Writing automated tests with Postman – Part 3, 2014-05-09

• 有些早期文章会提到Jetpack，曾经收10美元，现在成了Postman自带的Collection Runner，可以批量执行用例

示例

Postman Echo

Making the perfect HTTP request using Postman Echo, 2015-11-13

Cooper's Meal Plan

Conditional Workflows in Postman, 2016-03-23

Spotify Playlist Generator

Generate Spotify Playlists using a Postman Collection, 2016-11-09

CurencyCloud的Postman集合和使用说明

---

录制接口

Capturing requests (native app)

Using Postman Proxy to Capture and Inspect API Calls from iOS or Android Devices，2016-06-26

接口调用方希望测试业务逻辑时，用不着Fiddler/Charles抓包再往里面一个个填这么麻烦

开启Postman的代理（默认5555端口），浏览器/手机设好对应的IP和端口就行

支持正则表达式过滤URL，建议排除掉静态资源、流量统计站和别的后台进程时不时请求的网站

baidu|google|microsoft|github|qq\.com|.*\.(html?|css|js|png|jpe?g|webp|ico)$

可以设置保存的位置：

如果所有操作步骤都要做接口测试，建议直接保存到目标集合

如果一大堆操作里只取其中一个到几个接口，建议保存到历史记录，挑出想要的另存到目标集合，不用浪费时间删

---

Collection Runner

Running a collection

• 适合一次运行/调试多个用例，不用自己一个个点发送
• 适合开发自测接口性能（例如循环个10000次），至少响应时间和稳定性都过关了才交给别人调用
• 适合做简单的数据驱动测试——CSV文件里写上各种合法非法参数组合，1个集合/文件夹只放1个接口，关联起来点运行就是
• runtime、默认行为（比如不保存环境变量）、可以指定数据文件等跟Newman一样，适合用界面调通了用例再放到命令行做持续集成

Postman集合的概念

导出之后可以看到1个集合其实就是1个json文件，打开文件就能看到，里面的item属性是个数组，每个用例都是数组里的1个JSON对象

Postman/Newman1次只能跑1个集合，各个集合之间没有任何关系

Postman文件夹的概念

文件夹实际上也是集合的item数组里的对象，它里面也有1个item数组，文件夹里的用例是这数组里面的对象

collection runner/Newman批量跑用例的最小粒度是文件夹

• 目前集合下只支持1级文件夹，不推荐场景搞太复杂，用例管理起来有难度
• 目前集合和文件夹只能按字母顺序排序，用例可以拖动排序
• 目前搜索不能搜到URL地址，建议用例名写成 /path/to/api 接口描述，方便看和搜索

如果打算做自动化和持续集成：

• 集合、文件夹的名字建议英文无空格，方便命令行调用
• 要么不放，要么全放文件夹
• 每个文件夹测完全独立的子场景，文件夹之间的用例不要有顺序、状态等依赖关系

如果你不是从写用例到搞持续集成都包了并且一直由你自己维护，不能假设别人会按你想要的方式、顺序、设置运行测试

别人写的脚本可能运行整个集合或逐个文件夹运行，不同文件夹之间可能同步可能异步，可能会保存运行中产生的环境变量也可能不保存

此外，越多耦合，稳定性越差，维护工作量越大

流程控制

只有在collection runner或Newman里才生效（在普通界面你选哪个发送就是哪个）

/* 假设2个用例的顺序为： 用例A 用例B 如果希望执行顺序为： 用例A -> 用例B -> 用例A，又不想复制一份用例A，那么 */ // 用例A的Tests里写 if (xxx) postman.setNextRequest('null'); // 终止执行 // 用例B的Tests里写 postman.setNextRequest('用例A'); // 【注意】如果不设终止条件，用例A执行完到用例B，用例B执行完又指向用例A，会构成死循环 // PS：postman是Postman提供的全局对象

---

断言

Testing Sandbox 内建对象、方法、变量和可用的第三方库介绍

Testing examples

Extracting data from responses and chaining requests, 2014-10-27

在主界面可以靠肉眼看返回结果，但在collection runner/Newman里如果不加断言，跑完没法知道是成功还是失败

断言写在Tests标签页里，上手可以参考文档和界面右边的代码模板：

tests['Status code is 200'] = responseCode.code === 200; // 推荐用全等 ===，确保类型和值都一致

tests['Response time is less than 200ms'] = responseTime < 200; tests['Body matches string'] = responseBody.has('xxx'); // 只要有指定关键字就行，在哪、有几个等都不管 tests['Content-Type is present'] = postman.getResponseHeader('Content-Type') || false; // Postman的断言实际上就是往全局对象

tests 添加键值对 // 它的key会显示在报告界面上，value是可以解析为boolean的表达式 // 如果得出的值是true，在报告里显示为成功，false失败 // 【变通】用总是为真的断言来显示信息 tests[`[INFO] Request params: ${JSON.stringify(request.data)}`] = true; // 显示所有请求参数（在自动化测试里很有用）

tests[`跑第${iteration + 1}次`] = true; // 用在runner里循环很多次时 // 迭代次数 iteration 是Postman提供的全局变量，从0开始 // PS：request是Postman提供的全局对象 // responseCode（对象）、responseTime（数字）、responseBody（字符串）目前是Postman收到服务器返回内容才声明的变量 //

【注意】如果你在做自动化测试，目前在接口超时没返回时： // responseCode、responseTime、responseBody都没定义，使用时会导致脚本出错，判断是否超时没返回的只能靠header // request.data里的变量在超时时不解析，很容易让人误会请求参数传错了，建议此时不显示这行

关于'use strict';

因为Postman提供了不少全局变量，写了'use strict';会在用到这些变量的地方出警告提示

如果平时有养成好习惯，不用容易出错的写法，不写它也没关系

---

提取接口返回值

返回JSON时

let json = JSON.parse(responseBody); // responseBody是包含整个返回内容的字符串

// 提取某字段的值： let foobar = json.foo.bar[0].foobar;

// 假设结构为 {"foo": {"bar": [{"foobar": 1}, {"baz": 2}]}}

// 想用在自动化测试可以多写点： let json; try { json = JSON.parse(responseBody); } catch (err) { tests['Expect response body to be valid JSON'] = false; tests[`Response body: ${responseBody}`] = true; console.error(err); }

返回HTML时

// A. 用正则表达式匹配 let foo = responseBody.match(/foo/g);

// g 全局 i 不分大小写 m 多行 tests['blahblahblah'] = foo[0] === 'bar';

// 正则里包含变量时： let foo = 'xxx'; let bar = responseBody.match(new RegExp(`^${foo}.*$`, 'g');

// B. 用CheerioJS库（可以让你用jQuery语法）： const $ = cheerio.load(responseBody); $.html()

// 整个网页 $('title').text();

//