一、前言
Postman作为常规的API接口调试工具，对于前后端的调试、接口测试等工作来说，都是非常实用的一款工具。
本人主要用它来做测试工作，主要是为了给项目后期的接口自动化做铺垫，关于Postman的安装和一些配置，我在这里就不进行详情的描述了，我有时间了再补充进来，大家暂时可以自行百度。
下面列出Postman的下载地址和官方文档：
①、下载地址：https://www.getpostman.com/apps
②、官方文档：https://www.getpostman.com/docs
③、API文档：https://docs.postman-echo.com
二、利用Postman生成cURL和代码（多种语言）-- 本人主要用于各种测试脚本
使用场景：
一般根据接口文档，在Postman中调试成功后，我们又要去书写接口脚本，这时候能够直接生成代码的话，能够更加方便的有助于我们书写脚本的速度，当然能自己写最好。或者有时候我们甚至连接口文档都获取不到，纯靠自己抓包之后在Postman中调试成功，也可以生成code来帮助我们后续工作的顺利进行，生成代码可以支持多种语言。
实际案例：
1、编写好API并调试成功之后，点击右侧的 </>
2、下拉选择cRUL
3、选择不同的语言，生成对应的Code（此处本人选择的是python语言）
三、设置Cookie
使用场景：
一般在发送请求的时候，都需要cookie，而最常见的就是将登录凭证token写入Cookie中，使得用户登录状态保持为“已登录”。
实际案例：
1、案例一：
a、点击右上角区域的cookies，进入cookies管理面板。如果发送了请求，且服务端新增了Cookie，这里都能查看的到。
b、在cookies管理面板的输入栏里输入一个域名（不需要http头），这个表示cookie作用的域名，输入完成后点击Add添加。
c、点击Add之后，面板中多出一个改域名的分组，在改组下点击Add Cookie来新增一个Cookie
d、这时候会出现一个默认的Cookie的值，我们把Cookie_1和value分别改为我们要设置的cookie键值对，点Save保存。
e、在cookie管理面板，点X可以删除不需要的cookie。可以删除单个Cookie，也可以删除某个域名下所有的Cookies。
2、案例二：
a、可以在具体的某个请求之下添加token，可以选择具体的token方式，然后填入具体的token值(此处以Bearer Token为例)。这样在发送请求的时候，就能够模拟已经登录的用户，能够验证通过。
b、同时可以在单例接口的上一级（Folder）、上上级（Collection）增加Token，来控制其Collection下或者Folder的所有请求都保持一致。
c、还可以在Folder或Collection下设置一个变量{{access_token}}，然后再环境变量处设置{{access_token}}的值，来控制不同环境下的Token。需要改变不同环境的Token，只需要改变不同的环境即可。
四、设置环境变量（开发环境dev、测试环境qa、预发布环境pre、生产环境prod）
使用场景：
针对各种服务环境切换的时候，防止频繁的去修改请求的地址或者参数，我们采用设置不同的环境变量来进行切换。
实际案例：
1、点击左侧栏中的Environment，点击 “＋” 来新增一个环境。
2、在环境中可以添加各种变量（例如host）。
3、在右上角环境选择处下拉选择一个环境。
4、使用变量（例如host）。
5、查看环境变量与全局变量（Global）。
五、设置全局变量
使用场景：
在实际的业务过程中，总有一些参数的值是不会变化的，或者是变化很少的，且是统一的，这时候设置全局变量比环境变量来说要好一点。操作过程与上一节设置环境变量相似。
实际案例：
1、点击左侧栏中的Environment，点击 Globals。
2、设置全局变量，可以给初始值，也可以不给初始值。
3、当然可以利用{{num}}的方式调用，也可以在js中设置全局变量“ postman.setGlobalVariable("signature", signature); ”
六、自动生成签名（signa）
使用场景：
我们在写服务端接口时候，往往需要考虑安全问题，最基本的一点就是接口需要按照约定的规则进行签名校验。一旦接口校验签名，就意味着我们用Postman不能像以前那样顺利的测试了，服务端必定会返回签名失败。我们在本地开发时候，一定有不少开发同学是通过注释掉验签代码来绕开签名，但往往提交代码时候又不小心提交上去。灵活点的签名校验可能会忽略掉来自本机请求的验签，我们这里假设系统设计的没这么灵活，而且即使这样灵活设计也还是解决不了外网要测试dev qa环境的接口无法通过验签的问题。下面我们就利用Postman强大的Pre-request Script功能来实现自动为每个请求生成服务端需要的签名参数。
Pre-request Script是通过Postman的沙盒(Sandbox)来实现的，而Sandbox是一个JavaScript执行环境，里面内置了一部分常用的JS库和函数（。所以我们其实是通过编写JavaScript代码，代码在请求发出前先被执行，从而达到自动生成签名的目的。
实际案例：
1、先切换到Pre-request Script选项卡，开始编写JavaScript代码（实际中的Signa算法以后端的为准，次处截图中的算法是本人在工作中使用的，并不适用大家的业务场景）。
2、我们还需要在请求的Headers里加上signature、timestamp和requestId字段（有时候可能在Body中填充），而且必须用双引号括起来，否则会报错。还要在环境变量或全局变量（视情况而定）里设置signature字段。
3、代码中使用到了Postman Sandbox的一些常用的内置函数，这里简单介绍一下。Sandbox内置的类库以及完整的Postman API介绍请看最下面的文档，这里无法一一罗列和演示。
(function(){ ... })()：jQuery的写法，Sandbox内置了jQuery库。
pm.environment.get(variableName)：获取某个环境变量的值，也可以写成 postman.getEnvironmentVariable(variableName)。
pm.globals.set(variableName, variableValue)：设置某个全局变量，也可以写成 postman.setGlobalVariable(variableName, variableValue)。
CryptoJS.HmacSHA1()：内置的CryptoJS库，几乎涵盖所有加密算法，本案例使用了SHA1，大家根据具体签名规则来选择。
{{$timestamp}}：动态返回当前时间戳。类似的语法还有{{$guid}}生成唯一ID，{{$randomInt}}生成0到1000的随机整数。
4、如果每个请求都要加签名，不必为每个请求都写一份重复的Pre-request Script代码。可以在收藏或者文件夹级别统一设置，这样该收藏或文件夹下每一个请求都能执行到。
5、关于Pre-request Script的API文档
七、自动化测试
使用场景：
我们写完了业务接口，一般都要自验一下，看下通没通。虽然可以写单元测试，但实施起来没有那么简单。我们第一时间想到了Postman，它的出现不就是为了解决API测试问题的吗？我们要做的是把要测试的API录入到Postman，然后写验证返回结果的测试脚本。每次改完代码，都可以手动跑一下所有API，如果返回结果都是我们想要的，那证明这个接口通了。除了手动触发执行以外，我们还可以用做成自动化，做CI持续集成。
实际案例：
1、先编写好一个API，我这里以Postman提供的示例API为例，请求地址是 {{host}}/xunlong/demandPosition/demandPageList，其中 {{host}}是我在环境变量中配置的。点击选项卡Tests，在这里写我们的测试脚本。与上一节Pre-request Script一样，在这里可以写JavaScript代码，不同的是，Tests是在请求结束后执行的。
2、在面板右侧，Postman提供了超全面的示例代码。我们根据该请求的返回结果，简单写两个test，第一个是校验请求返回码是200，第二个是校验args字段。
3、写完脚本，我们再发送一下请求。发现Test Results里面有东西，而且是绿色，证明我们的测试通过。当然我们可以把一些通用一点的test（例如请求码返回200）写在收藏夹或文件夹里，这样里面所有的请求都能被执行到，然后在每个请求里面写跟该请求特定的test（具体业务相关的）。
4、利用Runner功能批量执行请求。点击最顶部的Runner打开Runner面板，选择一个收藏夹或文件夹（我这里选择了一个收藏夹，里面只有一个刚才写好的请求）。简单说下这里的设置，Environment是选择环境，Iterations是执行次数（这里填10次），Delay是每个请求执行的间隔（这里填100ms），Data可以选择一个数据文件，然后在请求中设置占位符{{xxx}}，就可以用文件中的数据来替换，一个请求一个数据，这里不作介绍，详情看官方文档：https://www.getpostman.com/docs/v6/postman/collection_runs/working_with_data_files。
5、运行结果
6、虽然Runner功能已经很方便，但每次写完代码都要手动点一下还是很麻烦。其实postman可以用命令行来运行，我们自己写脚本基本也可以实现自动化测试。另外，postman可以集成到Jenkins和Travis CI上，在每次部署前或者把代码合并到主干分支前都进行一次接口测试，以保证系统服务可用。这里暂时不作深入介绍，深入的内容待我有时间再补充进去。
八、控制台输出
使用场景：
前面两节介绍了Postman的Pre-request Script和Tests，它们都需要写JavaScript代码，说到写代码肯定离不开调试（控制台输出）。Postman为我们提供了一个类似浏览器console的简单控制台面板，可以通过console.log打印一些信息到控制台方便我们验证和调试。
实际案例：
1、我们在Tests（或者Pre-request Script）下编写一些示例代码，通过console.log输出到控制台。
2、打开Postman Console（控制台）。可以通过左下角图标打开，也通过在菜单栏（View -> Show Postman Console）打开。
九、请求的拦截（API收集）
使用场景：
前面介绍了那么多Postman的功能，都有一个前提，就是要先把API写出来。但是有些团队往往是已经把项目前后端对接完了，再来使用Postman。这时候，我们就不需要一个一个API录进去，我们可以利用Postman提供的请求拦截功能来收集API。性质跟我们平时拦请求用的Fiddler其实差不多，下面以手机APP来演示。
实际案例：
假设我们开发了一个APP，我们要抓取这个APP的所有后端接口（一般是某个域名下的）。但现在我们换种场景，我以手机浏览器APP为例，抓取所有百度域名的请求，并保存在Postman的指定收藏夹下。
1、 点击Postman右上角的类似电磁波图标，弹出代理设置。第一行是端口，默认5555，不需要修改。第二个是目标，可以选择History或者某个收藏夹，也就是请求要保存到哪里，这里我们选择刚创建的名为baidu的收藏夹，点Connect按钮就可以开启代理。
2、为了精准收集，我们进入Filters选项卡，在第一行输入baidu.com，也就是说url不包含baidu.com的我们不要。第二行是不包含的内容，例如我们排除静态资源文件可以写成.ico|.png|.jpg|.css|.js，第一个和第二个内容都支持正则表达式，而且两者并不冲突。第三个是要筛选的请求方法，可以不填。最后点Save按钮保存，设置就会立即生效。
3、查询电脑内网IP，Windows用户可以通过ipconfig命令查找，我这里是192.168.0.107。手机保证和电脑在同一个局域网内，手机进入wifi设置。我这里以我的小米安卓机来演示，其他品牌手机大同小异。进入已连接的wifi的详细设置，在代理那里选择手动，然后主机名填写电脑内网IP，端口填写Postman监听的端口，打勾保存。
4、这时候我们所有准备工作都已经完成了，只需要用手机打开浏览器，然后随意访问百度的网站，观察baidu收藏夹里API数量的变化。收集了一段时候后，我们可以看到收藏夹已经有几十条请求了，我们可以选中某条请求进行重放，也可以对它们进行编辑。
5、特别提醒：官网说了Postman桌面版目前暂时无法拦截 HSTS 模式的 HTTPS 请求，如果需要拦截这种类型的 HTTPS 请求，只能暂时使用Chrome版+Postman Interceptor插件的形式。还在登录同一个帐号数据可以同步，影响并不大，而且我们在测试环境调试的接口可以暂时不升级HTTPS。Postman Interceptor插件的使用非常简单，这里不再赘述。
6、本文只演示了安卓手机如何设置代理，其他系统的设置方法差不多。如果要拦截浏览器的请求，需要为浏览器设置代理。希望这个功能能为大家减轻API编写的工作量，提高测试效率。
十、发布API文档
使用场景：
开发一个项目需要前端和后端的配合，而接口文档则是连接前后端的一个桥梁。接口文档一般由后端驱动完成，当然也可以由前端驱动完成。只要文档一出来，两边都可以同时开干，提高开发效率。你是不是还在烦恼要用什么云文档平台来编写接口说明，完全不需要，因为Postman已经为我们提供了在线文档发布功能。下面，我将告诉大家如何在Postman上预览并发布文档（创建一个Postman帐号并登录）。
实际案例：
1、首先创建一个集合(collection)，因为集合是文档生成的最小单位。如有需要，可以加上描述，介绍一下这个集合是对应哪一个工程/业务。
2、在该集合里创建一个请求(request)，我们继续复用之前用过的简单GET请求。添加一些必要的注释，例如params、headers、body等。
3、为该请求添加示例(example)。示例其实很好理解，一般好的接口文档都有成功请求的示例，以及失败时的示例，大家主要关注请求的返回值(response)。一对请求值和返回值合起来才能算一个示例。点击Examples(0)的Add Example添加示例，我们添加一个请求成功的示例。我们在NAME填入成功作为示例名称，在Status填入成功时返回的HTTP状态码，一般为200 OK，并在返回值RESPONSE中填入成功时返回的数据。
4、如果接口已经开发完，则不需要造一个返回结果。我们可以点一下Send发送请求得到真实的返回值，点一下返回值附近的Save按钮，把当前的请求值和返回值作为一个示例保存下来，填入示例名字即可。
5、重复第2和第3步，把所有请求及对应示例和注释都写好，就可以在线预览文档。点击集合右边的三角形，再点View documentation。在页面中，我们可以很直观的看到我们最终发布的文档的样子，左边是文件夹和接口列表，中间顶部是集合介绍，下面是每个接口的请求地址、方法、参数和描述等，最右边是对应的示例。
6、当然，现在别人是看不到的，因为你还没发布出去。我们可以点页面右上角的Publish按钮来发布该文档，也可以直接在Postman桌面客户端的集合右键选择Publish Docs发布。在发布设置页面中，记住请勿勾选Collection discover，不然你的文档就会暴露在Postman社区上，你懂的。发布之后就会得到一个地址，可以分享给与你协同的其他开发者，不需要密码访问（当然也设置不了密码）。已发布的文档可以随时修改保存或下架的。
7、其他人打开之后可以通过页面右上角的Run in Postman把所有请求一键导入到自己的Postman桌面客户端（前提是你电脑已经安装最新版Postman，貌似chrome插件版享受不到这项功能）。
十一、Mock服务
使用场景：
通过上一节的学习我们掌握了如何生成并发布接口文档，可是现实总是残酷的。前端团队往往不满足于干巴巴的接口文档，他们需要对接真实的数据，但这样很受限于后端开发进度，于是便有了Mock(模拟)这种东西，也就是我们平时常说的“造 假数据”。Mock并不是Postman先提出的，在没接触Postman之前，不少前端团还是有一些自己熟悉的Mock工具。大多数情况下，mock都是由前端团队来驱动完成的。
利用Postman的Mock Server功能，我们可以把现成的请求模拟数据。前端请求Mock的接口地址，就能返回我们预先模拟好的数据，而不依赖于后端的开发进度。同时，还能解决在家远程办公而无法连接公司内网服务问题，以及开发初期由于服务不稳定引起的其他问题。
实际案例：
看过不少介绍Postman Mock的相关文章，它们大多数都使用创建好的集合和请求示例来Mock，而忽略了通过新建API的这种方式来Mock接口，并没有把Mock的一些基本概念讲清楚。
Postman提供的Mock Server方式有两种：
①、新建API集合
②、使用工作区的集合
我们先通过新建API的方式让大家对Mock的概念有个基本的理解。
方式一：新建API
①、点击Postman主窗口左上角的New，选择Mock Server。在弹出的新窗口中，我们可以看到有两种创建方式，默认选择的是第一种Create a new collection。中间有个类似表格一样的东西，有请求方法、请求路径、响应码、响应体这几项，也就是说，一个标准的mock须包含以上几项。
②、我们先填写一个API：请求方法是GET，请求路径是test，响应码是200，响应体是ok。值得注意的是，请求路径前面为什么加了个{{url}}/？这是因为Postman匹配路径的时候会忽略掉前面协议和域名这一块，而域名之后的部分才是我们所关心的。
③、填完API，点下一步。我们的mock名字就叫test_mock吧。先别勾选Make this mock server private，这个我后面会解释。完成后点创建，你会得到一个Postman分配给的网址，这个网址是以mock.pstmn.io域名结尾的，这个就是对于刚才创建的API对应的mock地址。
④、如果你不小心关掉没保存下来也没关系，你会发现左侧多了一个集合，Postman自动为我们刚才填写的API创建了一个同名的新集合。集合里包含一个请求，请求里包含一个示例，点开发现全是我们刚才填写的内容。我们点集合三角形展开详细面板，选择Mocks选项卡，就可以找回刚才分配的mock地址了。不仅如此，还自动创建了一个同名的环境变量，里面包含一个url的值，正是我们刚刚分配的mock地址。
⑤、我们打开Postman为我们自动创建的那个请求test，运行环境选择自动创建的test_mock（即你刚才填写的mock名称），直接点运行，返回结果正是我们刚才填入的ok值。把鼠标移动请求地址的{{url}}上，发现被替换成真正的mock地址。我们通过Code功能把请求地址拷贝到浏览器请求一下，发现返回结果还是我们想要的。至此，你已经成功学会了如何mock，而且对mock的概念有了基本的理解。
⑥、再讲多一点，我们在地址栏后面加上/1，最终变成{{url}}/test/1，再请求一次会有什么变化？如果把test变成test1，结果又是怎样呢？大家可以试试。其实这里涉及到了Mock Server的匹配算法，我们不会展开来讲，先简单理解为支持模糊匹配，并返回最接近的请求示例响应。
方式二：使用集合
①、先创建一个集合，在集合里创建一些请求，为请求添加一个示例。如果不懂的可以先看上一节关于请求示例的添加
注意：示例创建之后可以修改。一个请求可以包含多个示例，只会返回最符合要求的示例响应。
②、为该集合添加Mock。点击左侧集合旁边的三角形，展开详情面板。选择Mocks选项卡，点击Add a mock进入打开添加窗口。操作方法跟上面一样，只不过不需要手动填mock名称，完成后同样会得到一个mock地址。至于如何使用上面已经提过了，这里不再赘述。
私有mock server
①、 在创建mock的界面，有一项是Make mock server private。不勾选的话，我们的mock地址公布出去，谁都可以访问，会造成不必要的麻烦。我们重新生成一个mock server，这次勾选设为私有。
②、 打开 https://go.pstmn.io/pro-api-keys ，点击Get API key生成一个密钥，名字可以叫使用者的名字方便管理。这里可以看到我们所有生成的key，可以禁用或删除。
注意：生成的api key并不是专门用于mock server，还可以用于Postman提供的其他服务中。
③、如果我们直接请求会返回没有访问权限，这就对了，因为我们还差最后一步。在请求的头部加入api_key，再次请求即可正常返回数据。当然，这个api key我们正常应该写在全局变量里，比较好维护。
后续内容如有继续完善的，会慢慢补充完整，敬请期待！
本文参考：https://blog.csdn.net/qq598535550/article/details/81276594
