SoapUI、Jmeter、Postman三种接口测试工具的比较分析 1. 用例组织方式

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:


 

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

TestCase log

Request 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:有团队协作的功能,需要付费。

首先是用例组织方式的不同,不同的目录结构与组织方式代表不同工具的测试思想,学习一个测试工具应该首先了解其组织方式。

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:


 

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

TestCase log

Request 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:有团队协作的功能,需要付费。

猜你喜欢

转载自blog.csdn.net/spring_hong_1983/article/details/80911619