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 群友福利免费领取
Postman
Json用例
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
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. 预期结果保存在用例中,同一套脚本,适用不同的业务场景。
公用方法提炼
为了减少自动化脚本中的冗余脚本,提高脚本的编写效率,特提炼公用方法到全局变量中,不仅减少代码复杂度,提高脚本编写效率,也能够降低此套自动化框架的上手难度;公用方法的使用方式在postman介绍中已经描述,此处不再赘述。
多环境执行
在多套环境的基础上,基础数据的主键有所不同;面临越来越多的自动化脚本,维护的工作量不断加大。
为了减少这部分的工作,通过研究,确立数据字典模式:
1. 将环境下的数据字典维护到环境变量中
2. 自动化用例中需要使用基础数据主键的部分,增加变量标识
3. 编写公用方法,用来识别变量并在数据字典中匹配并替换成匹配结果。
优势:脚本和用例有且只有一套,适用于任何环境,进一步降低维护成本
劣势:用例的可读性降低,不能直观看出数据
实战中的坑
1. 如body中使用的变量需要是对象或数组,则需要将对象或数组通过JSON.stringify()转换成字符串后,赋值给变量才能成功调用接口;
Json外部用例格式,body参数要传入bodyInfo属性:
前置脚本处理:
Body中调用:
2. 前置或后置脚本中定义变量时,如果不写标识符,定义的变量可在其他接口执行时使用,但其生命周期仅限于本条用例执行完毕。
查询1中定义变量:
查询2中输出test的内容:
Collection runner运行后输出结果
3. 前置脚本中不支持接口间跳转:postman.setNextRequest();
4. Collection可增加前置脚本,后置脚本和变量定义;前置脚本和后置脚本,没调用一个接口后,均执行一次;
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取