你应该学会的Postman用法(2)-自动化测试
前言
之前的一篇文章《你应该学会的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,再整合其他构建发布工具,来对我们的微服务进行发布,真正做到了自动化的发布、测试,而且能做到不停机、不影响用户使用情况下完成系统的发布。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
(1)学习笔记 ) ASP.NET CORE微服务 Micro-Service ---- 什么是微服务架构,.netCore微服务选型
开发工具:VS2017 .Net Core 2.1 什么是微服务?单体结构: 缺点: 1)只能采用同一种技术,很难用不同的语言或者语言不同版本开发不同模块; 2)系统耦合性强,一旦其中一个模块有问题,整个系统就瘫痪了;一旦升级其中一个模块,整个系统就停机了; 3)要上线必须一起上线,互相等待,无法快速响应需求; 4)集群只能是复制整个系统,即使只是其中一个模块压力大; 微服务:不同模块放到不同的进程/服务器上,模块之间通过网络通讯进行协作。适用于:模块比较多,访问量比较大的互联网类系统,并不是所有项目都适合微服务 优点: 1)可以用不同的语言或者语言不同版本开发不同模块; 2)系统耦合性弱,其中一个模块有问题,可以通过“降级熔断”等手段来保证系统不血崩; 3)可以独立上线,能够迅速响应需求; 4)可以对不同模块用不同的集群策略,哪里慢集群哪里。 缺点: 1)开发难度大,系统结构更复杂; 2)运行效率低;(网络通讯没有进程通讯快) 微服务架构要处理哪些问题?服务间通讯;服务治理与服务发现;网关和安全认证;限流与容错;监视等第一代微服务:Dubbo(Java)、Orleans(...
- 下一篇
高可用高并发的 9 种技术架构!
1、分层 分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对简单并比较单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统。 在网站的分层架构中,常见的为3层,即应用层、服务层、数据层。应用层具体负责业务和视图的展示;服务层为应用层提供服务支持;数据库提供数据存储访问服务,如数据库、缓存、文件、搜索引擎等。 分层架构是逻辑上的,在物理部署上,三层架构可以部署在同一个物理机器上,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,即三层结构分别部署在不同的服务器上,是网站拥有更多的计算资源以应对越来越多的用户访问。 所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护,但在网站的发展过程中,分层结构对网站支持高并发向分布式方向的发展至关重要。 2、冗余 网站需要7×24小时连续运行,那么就得有相应的冗余机制,以防某台机器宕掉时无法访问,而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。 3、分隔 如果说分层是将软件在横向方面...
相关文章
文章评论
共有0条评论来说两句吧...