SoapUI、Jmeter、Postman三种接口测试工具的比较分析!
前段时间忙于接口测试,也看了几款接口测试工具,简单从几个角度做了个比较,拿出来与诸位分享一下。本文从多个方面对接口测试的三款常用工具进行比较分析,以便于在特定的情况下选择最合适的工具,或者使用自己编写的工具。(不同工具定位不同,我们只是主要从接口功能测试的角度进行分析)。
1.? 用例组织方式
首先是用例组织方式的不同,不同的目录结构与组织方式代表不同工具的测试思想,学习一个测试工具应该首先了解其组织方式。
SoapUI的组织方式如下图,最上层是WorkSpace,每个窗口只可以打开一个WorkSpace(这是一个xml文件),每个Project也是一个单独的xml文件(为了协同工作,也可以通过设置将其转化为一堆文件集合),所以每个WorkSpace中可以打开多个Project,一个Project也可以在不同的WorkSpace中。
Project对应我们的测试项目,其中可添加WSDL、WADL资源、TestSuite以及MockService。
TestSuite对应我们的测试模块,比如商户中心,其中可以添加TestCase,TestCase对应我们对某个模块的不同接口,比如订单管理接口。而一个接口可以能需要多个Step完成,变量、数据源、请求等都是一个Step。
Jmeter的组织方式相对比较扁平,它首先没有WorkSpace的概念,直接是TestPlan,等价于SoapUI中的Project,TestPlan下创建的Threads Group就相当于TestCase,并没有TestSuite的层级。
TheadsGroup中的Sampler、管理器等均相当于SoapUI中的一个Step,如下图:
Postman功能上更简单,组织方式也更轻量级,它主要针对的就是单个的HTTP请求。Collection就相当于是Project,而Collection中可以创建不定层级的Folders,可以自己组织TestSuite。每个Request可以当做是一个TestCase或者Step:
现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:691998057【暗号:csdn999】
2.? 支持的接口类型与测试类型
从功能上Jmeter最为强大,可以测试各种类型的接口,不支持的也可以通过网上或自己编写的插件进行扩展。SoapUI专门针对HTTP类型的两种接口,其初衷更是专门测试Soap类型接口,对于其他协议的接口不支持。Postman更是轻量级,定位也不同,可用来测试Rest接口。
工具 | 接口类型 | 测试类型 |
SoapUI | Soap、Rest | 功能、压力、安全 |
Jmeter | Rest、Soap等 可扩展WebSocket、socket | 功能、压力 |
Postman | Rest | 功能 |
3.? 配置不同接口类型
-
SoapUI可以创建Soap Project或者Rest Project(但Project中添加什么类型的Step则不受影响),可添加wsdl、wadl资源,并能在TestCase里添加Rest或Soap的Step。
-
Jmeter可以在线程组里添加HTTP、TCP或WebSocket的Sampler。
-
Postman仅支持Rest接口。
4.? 自定义变量以及变量的作用域
除以下表格中所列的变量之外,每个工具都有系统变量,未列在内。
工具 | 变量类型 | 作用域 |
SoapUI | Project、TestSuite、TestCase的Properties以及Custom Properties | 各自以内的范围内 |
TestCase里的Properties | 在整个TestCase内 | |
TestCase里的Data Source、DataGen等 | 在整个TestCase内 | |
Groovy脚本定义 | 看定义方式 | |
Jmeter | TestPlan中用户定义的变量 | 所有Threads Group |
配置元件 - 用户定义的变量 | 根据元件位置而定 | |
CSV data set、random variable等 | 根据元件位置而定 | |
前置、后置处理器 | 当前Threads Group | |
Postman | Environment Variable | 当前环境的Collection |
Global Variable | 所有Collections | |
CSV/JSON datafile | Runner当前的Collection |
5.? 数据源、生成器,进行参数化
工具 | 数据源 | 生成器 | 循环 |
SoapUI | DataSource,数据可来源于文件、目录、数据库、Excel、Grid等 | DataGen | DataSource Loop |
Jmeter | CSV Data Set Config读取csv文件 | Random Variable 计数器 | ForEach控制器 循环控制器 While控制器 |
Postman | Runner中运行时,可加载CSV/JSON文件 | 无(只能通过脚本) | Runner中的Iteration |
6.? 流程控制
-
SoapUI:由Conditioinal Goto控制流程,以及Groovy脚本
-
Jmeter:由Switch控制器、If控制器、随机控制器等一系列控制器实现流程控制,以及Beanshell脚本
-
Postman:通过JavaScript脚本控制
7.? 结果解析、展示
工具 | 结果 | 日志 | 报告 |
SoapUI | Project-OverView、TestSuites TestSuite-TestCases TestCase-TestSteps | SoapUI全局多种log TestSuite log | Project report TestSuite report TestCase report (PDF/HTML/XML/CSV) |
Jmeter | 各种监听器 | 统一的Jmeter log | 监听器可导出到文件 并可导出JTL、CSV文件、通过插件可导出HTML(Jmeter3自带) |
Postman | Send可查看Request的Response Runner可查看运行的Result | Postman console Chrome DevTools | Request的Response以及Runner的Result均可导出json |
8.? 断言
-
SoapUI:每个Request可添加Assertion
-
Jmeter:TestPlan、Threads Group、Sampler均可添加断言
-
Postman:请求的Tests中可添加断言
9.? 脚本扩展能力
-
SoapUI:Groovy脚本
-
Jmeter:Bean shell(Java)
-
Postman:JavaScript
10. 团队协作
-
SoapUI:本身一个project是一个xml文件,但是可以通过配置变成一系列文件夹,每个Case、每个Suite均是独立的文件,这样可通过svn/git进行团队协作。支持性较好。
-
Jmeter:一个TestPlan也是一个jmx(xml)文件,无法分割,但Jmeter有一个合并的功能,允许将多个文件合并在一起。只能每个团队成员自己建立一个TestPlan,分功能块进行测试。最后整理合并。
-
Postman:有团队协作的功能,需要付费。
END今天的分享就到此结束了~!点赞关注不迷路!?
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!