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：

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

欢迎指正，更多文章，请关注本人博客——灰蓝的博客。