Postman实战总结
简介本次实战内容主要包括如下几点：
l 背景介绍
l Postman使用，侧重于自动化实现，基础使用不做介绍
l 可视化Newman介绍
l 框架特色
l 实战中的坑
背景
随着国内软件技术的高速发展，越来越多的手工测试逐渐被自动化所替代，如UI测试，接口测试，单元测试等均可被自动化所替代，国内的大型互联网公司早已将自动化测试做的很成熟，大大提升了产品的交付效率和交付质量。
在it行业的大趋势下，产品组面临着如下四个挑战：
1. dubbo+cloudt2.X底层的老接口亟待升级；
2. 产品基本实现双周迭代，回归测试无法覆盖全部模块，偶尔出现关联影响考虑不周，导致泄露bug出现；
3. 测试资源不足，出现泄露bug后，影响产品质量；
4. 陆续尝试过使用python、doclever、eolinker、postman等做过接口测试，效果不是太理想。
在此背景下，最终通过研究，结合产品组内对postman有使用经验，且测试人员自动化能力欠缺，postman封装好，学习成本低，可快速产出自动化脚本，确立使用Postman+newman作为接口自动化测试方案。
如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以关注我一起讨论。
给大家推荐一个软件测试技术交流群：1079636098 群友福利免费领取
PostmanJson用例
Json格式的自动化测试用例，其实保存的是数组，数组元素均为对象，而一个对象则对应了一条用例，如下图；
用例包含了用例名称（caseName），用例描述（description），期望调用结果（expectation），自动化业务类型（requestType），入参（queryData），预期结果（checkData）,结果校验字段（checkKey）；可根据自动化框架需要，灵活设置自己的用例参数。
Postman中访问用例数据的几种方式，为了便于后面查看，特准备如下格式用例：
[
{
"url":"requestUrl",
"params":"params"
"body":0,
"script":{
"consoleInfo":"helloWorld"
}
}
]
1. 接口地址，只能访问用例对象中最外层属性，使用方式{{variableName}}
2. Params，使用方式和规则同地址
3. Body，使用方式和规则同地址
4. Pre-request-Script& Tests（下文均称前置脚本和后置脚本），data指向用例对象，想要获取对象的属性，通过data.属性名的方式获取，如下图：
环境变量
Postman支持环境变量，其中可设置一些不同环境的变量，如域名，登录账号密码等。
环境变量也可以在脚本中使用，使用方式如下：
1． 接口地址，params和body中的使用方式同用例属性的调用方式，{{variableName}}，如果出现变量冲突时，优先取用例中的属性，比如环境变量中设置了url=www.baidu.com，用例对象最外层属性中也有一个url=www.google.com属性，那么优先使用www.google.com
2． 前置和后置脚本中使用环境变量会有所不同，可使用postman封装的方法,具体使用如下：
全局变量
Postman支持设置全局变量，顾名思义，全局变量在任何环境下均可以使用，这也就限制了其只能设置一些公用的变量。接口地址，params和body中对于全局变量的使用同环境变量，这里不再赘述；前置/后置脚本中的使用方式大体与环境变量相同，只不过postman封装的方法名有差异：
获取全局变量：pm.globals.get(“variable_key”);
设置全局变量：pm.globals.set(“variable_key”,”variable_value”);
清空环境变量：pm.globals.unset(“variable_key”);
在此次自动化实战中，博主提炼了公用方法作为全局变量，比如获取时间戳，对比数据，处理cookie，查询数据字典等等，下图是获获取时间戳方法，getTime是方法名，右侧是方法体：
全局变量中的公用方法使用不同于变量，需要特殊处理；如果想要在脚本中使用获取时间戳方法，需要使用eval（)方法引用，如同java中的import；
注意：
1. 使用eval引用方法时，方法名后面不需要增加()，而调用方法时需要增加()；
2. 环境变量中也可以设置方法，不过一般不这样使用，使用方式类似于全局变量，eval（environment.functionName)；
3. 方法中可以调用其他方法，用法同1、2。
脚本
前置脚本在调用接口前执行，一般对接口参数进行前置处理，如对入参进行赋值；后置脚本在接口调用后执行，一般对接口响应结果进行校验。对于环境变量、全局变量、json外部数据访问上文中已经涉及，此处不再赘述。
这两部分是postman支持脚本编写的部分，博主习惯使用JavaScript语言进行编写；而且postman列举了一些常用的方法，这里就不再对其一一介绍，主要介绍几个postman未列举，但是在后置脚本编写过程中很实用的点：
1. postman.setNextRequest()：跳转
collection中有多个接口，一条用例会涉及多个接口的调用，如果不加跳转语句，自动化运行时会默认执行下一个接口，会使用例执行流程不易控制，如果增加跳转语句后，跳转就会灵活，结束执行流程也变得更方便；
结束当前用例执行：postman.setNextRequest(null)；
跳转执行另一个接口：postman.setNextRequest(“接口名称”)；
2. return：返回
Tests脚本可看做一个方法的方法体，上图中的return也就意味着方法返回了，不再执行后续脚本
3. responseCode：接口调用状态
一般只需要使用其中的code（接口响应码），使用方式：responseCode.code，整个responseCode内容如下：
{
"name": "OK",
"detail": "Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.",
"code": 200,
"standardName": "OK"
}
4. responseBody：响应结果
这里要注意的是，responseBody的值是字符串类型的响应结果，如接口返回应该是对象，则需要对responseBody进行转换（JSON.parse(responseBody)）
5. request：当前调用接口信息，内容如下：
6. tests[“响应断言输出内容”] = true：响应断言，任何一个脚本都要有响应断言
等号后面可使用判断语句，如果是true，则断言通过，如果是false，断言失败。如判断tests[“接口调用成功，状态码为200”] = responseCode.code == 200，判断接口是否调用成功。
自动化测试
使用postman可以在本地进行单个collection进行自动化测试，collection runner窗口即可进行执行自动化脚本。
1. environment可选择执行环境变量；
2. Iterations设置执行用例数，如果设置用例数少于json外部文件中的用例数，那么只执行设置的用例数；如果设置用例数多于json外部文件中的用例数，那么执行完全部用例后，会将最后一条用例重复执行，直到执行完设置的Iterations次数为止。
3. Delay设置执行间隔时间；
4. Data可选择外部json用例，这里注意文件中json数据格式如果有问题会报错。
运行结果如下：
Newman 是 Postman 推出的一个 nodejs 库，直接来说就是 Postman 的json文件可以在命令行执行的插件。Newman 可以方便地运行和测试集合，并用之构造接口自动化测试和持续集成。
Newman的安装在这里不进行赘述，网上有很多安装教程。
因newman需要使用bat命令运行，自动化脚本量大，且编写命令形式不利于管理；为了解决这个问题，特开发newman可视化页面，可选择环境变量和全局变量，批量选择脚本，自动生成bat命令并执行，提高效率，降低使用难度。可视化页面如下图
Newman执行脚本，每套脚本会生成三种格式的报告（xml，json和html），可读性很差，为了解决这个问题，进行了如下研究：
1. 现过程中发现json文件大，读取效率低；
2. 通过查询资料，确定从newman安装文件中生成报告的js脚本下手（路径：C:\Users\账号 \AppData\Roaming\npm\node_modules\newman\lib\reporters\json），缩减json报告大小，只保留部分有用的内容
3. 生成excel格式的自动化报告
4. 邮件发送，通过nodejs脚本自动将处理后的报告，以邮件形式发送到干系人。
框架特点按业务模块存放
此次实战主要针对web api，接口自动化冒烟测试从业务维度进行拆分collection，不仅测试单接口异常情况，也支持关联接口之间配合测试；
数据驱动模式
1． 自动化用例全部提取到外部json文件；
2． 同一个collection中，不存在相同接口；
3． 任何一个接口中入参或出参，都只有一个变量保存在用例中，后续接口维护后，仅需要更新用例，脚本无需再做修改；如入参或出参需要处理，则在前置脚本中进行处理；示例见下图，body中只传入一个变量值；
4． 预期结果保存在用例中，同一套脚本，适用不同的业务场景。
如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以关注我一起讨论。
给大家推荐一个软件测试技术交流群：1079636098 群友福利免费领取
公用方法提炼
为了减少自动化脚本中的冗余脚本，提高脚本的编写效率，特提炼公用方法到全局变量中，不仅减少代码复杂度，提高脚本编写效率，也能够降低此套自动化框架的上手难度；公用方法的使用方式在postman介绍中已经描述，此处不再赘述。
多环境执行
在多套环境的基础上，基础数据的主键有所不同；面临越来越多的自动化脚本，维护的工作量不断加大。
为了减少这部分的工作，通过研究，确立数据字典模式：
1. 将环境下的数据字典维护到环境变量中
2. 自动化用例中需要使用基础数据主键的部分，增加变量标识
3. 编写公用方法，用来识别变量并在数据字典中匹配并替换成匹配结果。
优势：脚本和用例有且只有一套，适用于任何环境，进一步降低维护成本
劣势：用例的可读性降低，不能直观看出数据
实战中的坑1. 如body中使用的变量需要是对象或数组，则需要将对象或数组通过JSON.stringify()转换成字符串后，赋值给变量才能成功调用接口；
Json外部用例格式，body参数要传入bodyInfo属性：
前置脚本处理：
Body中调用：
2. 前置或后置脚本中定义变量时，如果不写标识符，定义的变量可在其他接口执行时使用，但其生命周期仅限于本条用例执行完毕。
查询1中定义变量：
查询2中输出test的内容：
Collection runner运行后输出结果
3. 前置脚本中不支持接口间跳转：postman.setNextRequest();
4. Collection可增加前置脚本，后置脚本和变量定义；前置脚本和后置脚本，没调用一个接口后，均执行一次；
