前言
之前的一篇文章《你应该学会的Postman用法》,主要介绍了postman的一些高级的用法，便于日常开发和调试使用，本文的基础是对postman的基本使用以及一些高级用法有一定的了解，如对此不太了解的同学，建议移步：《你应该学会的Postman用法》了解。
背景
随着公司微服务体系服务越来越多，业务增长越来越迅速，版本迭代越来越快，而且对系统的可用性要求越来越高，传统的手工发布系统的方式已经完全无法满足日常运维的需求了，自动化构建发布的需求越来越强烈，但是自动化发布有个基础的环境，自动化测试，鉴于团队规模不大，测试人员的能力参差不齐，自动化测试我们选择了以开发测试一起搭建的方式，通过轻量级的工具postman进行自动化测试。
测试文件共享
postman可以将测试的接口进行collections分组，分组后的一组接口可以进行导出，如图：
导出后的文件，可以作为测试脚本共享，使用的人员只要导入，即可使用。
这样，就可以在不同人员间，共享一个测试的文件。当然，如果能升级到高级版，可以直接通过不同的账号在云端共享测试文件，更加方便。
脚本测试
一直以来，我们都是介绍通过postman 的UI进行测试的，但是，实际做自动化测试的时候，我们更多是使用脚本，特别是在生产环境，通过脚本进行测试，就是必然了。postman为我提供了一个测试的工具——newman，基于node.js的一个脚本测试工具。
安装
先安装node.js,这里不赘述了，开发人员必备工具。
在安装newman:
npm install -g newman
初步使用
记得前面介绍的，我们导出的测试文件吧，那个文件除了分享给别人，也是我们用来测试的文件。
newman run 11.json
11.json 就是我刚才导出的文件，使用脚本文件类型必须是json。
这时候看看我们测试发生了什么？
貌似，失败了。提示我们循环，执行了一次，6个请求，但是全面部失败了。看到错误的信息发现URI不正确，因为我用到postman了环境变量，但是导出的结果里没有环境变量。这时候我们需要调整一下执行的脚本。
newman run 11.json -e url.json
url.json 实际是我们需要当前执行的环境变量，文件从就是如图方式导出的：
导出后，我们也是将文件命名为json类型的文件。这样我看下我们执行的结果。
全部执行成功了。就是这么简单。一个命令配上我们开发时候就需要用到的测试文件，就可以了，无需另外的测试脚本，用一个shell脚本即可完成结果的测试。
参数详解
newman是个非常轻量级的命令，参数很少，这里我们列出常用的几个参数：
| 参数 |
详细说明 |
| -e |
环境变量(environment)文件路径或者url，json文件 |
| -g |
全部配置(Global)文件路径或url，json文件 |
| -d |
测试数据文件路径，cvs文件 |
| -n |
循环测试次数 |
| --delay-request |
延迟执行时间 |
| --timeout-request |
请求超时时间 |
| --bail |
其中一个接口失败后，是否继续执行 |
详细参数，可以参考：【这里】
总结
这样一个非常轻量级的自动化测试脚本就做好了，当然，这是我们做自动化构建发布一个前提，postman的优势是将日常开发中需要用的测试工具做成通过shell就能执行的工具，比专门花时间了编写soapui这样的脚本来说，更加轻量级，更加友好，当集成了shell的相关功能后，对于开发人员来说，可扩展性就变得非常容易了，后面的文章我将会介绍如何结合postman，再整合其他构建发布工具，来对我们的微服务进行发布，真正做到了自动化的发布、测试，而且能做到不停机、不影响用户使用情况下完成系统的发布。
