SoapUI 快速指南



SOAP - 简介

SOAP 是 Simple Object Access Protocol 的缩写。它由万维网联盟 (W3C) 在 https://www.w3.org/TR/2000/NOTE-SOAP-20000508 中定义如下:

SOAP 是一种用于在分散的分布式环境中交换信息的轻量级协议。它是一种基于 XML 的协议,包含三个部分:一个信封,用于定义描述消息内容和如何处理消息的框架;一组编码规则,用于表达应用程序定义的数据类型的实例;以及表示远程过程调用和响应的约定。

SOAP - 重要特性

以下是 SOAP 的一些重要特性。

  • 它是一种旨在通过互联网进行通信的通信协议。

  • 它可以扩展 HTTP 用于 XML 消息传递。

  • 它为 Web 服务提供数据传输。

  • 它可以交换完整文档或调用远程过程。

  • 它可以用于广播消息。

  • 它既独立于平台,也独立于语言。

  • 它是定义发送什么信息以及如何发送信息的 XML 方式。

  • 它使客户端应用程序能够轻松连接到远程服务并调用远程方法。

尽管 SOAP 可用于各种消息传递系统,并且可以通过各种传输协议传递,但 SOAP 的初始重点是通过 HTTP 传输的远程过程调用。其他框架(如 CORBA、DCOM 和 Java RMI)提供了与 SOAP 类似的功能,但 SOAP 消息完全用 XML 编写,因此具有独特的平台和语言独立性。

SOAP - 消息

SOAP 消息是一个普通的 XML 文档,包含以下元素:

  • 信封 - 定义消息的开始和结束。它是一个必选元素。

  • 头部 - 包含消息的任何可选属性,这些属性用于在中间点或最终终点处理消息。它是一个可选元素。

  • 主体 - 包含构成正在发送的消息的 XML 数据。它是一个必选元素。

  • 错误 - 一个可选的 Fault 元素,提供有关在处理消息期间发生的错误的信息。

所有这些元素都在 SOAP 信封的默认命名空间中声明:

https://www.w3.org/2001/12/soap-envelope

SOAP 编码和数据类型的默认命名空间为:

https://www.w3.org/2001/12/soap-encoding

注意 - 所有这些规范都可能发生变化。因此,请随时更新 W3 网站上提供的最新规范。

SOAP - 消息结构

以下代码块描述了 SOAP 消息的一般结构:

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope> 

SOAP - 什么是 REST?

REST 是 Representational State Transfer 的缩写。它可以定义为一种设计软件的架构风格。REST 不是规范或 W3C 标准。因此,使用 RESTful 服务更容易。它不需要任何中间件规范框架。

REST - 重要特性

以下是 REST 的一些重要特性。

  • 它依赖于无状态、客户端-服务器、可缓存的通信协议 - 几乎在所有情况下都使用 HTTP。

  • 它是 Web 服务和 RPC(远程过程调用)如 SOAP-WSDL 的轻量级替代方案。

  • 它用唯一的 ID 或 URI 表示所有内容。

  • 它使用标准的 HTTP 方法,例如 GET、POST、PUT、DELETE。

  • 它将源链接在一起。

  • REST 资源可以有多种表示形式。

  • 任何命名信息都被视为资源。例如:图像、人员、文档,都可以被视为资源示例,并表示为唯一的 ID 或 URI。

  • 基于 HTTP 的万维网本身可以被视为基于 REST 的架构。

REST 服务独立于平台和语言。由于它基于 HTTP 标准,因此它可以在防火墙存在的情况下轻松工作。与 Web 服务一样,REST 没有提供任何内置的安全、会话管理、QoS 保证,但可以通过构建在 HTTP 之上的方式来添加这些功能。对于加密,REST 可以用于 HTTPS 之上。

SoapUI - 简介

SoapUI 是一种可用于功能和非功能测试的工具。它不仅限于 Web 服务,尽管它是 Web 服务测试中事实上的工具。

SoapUI - 重要特性

以下是 SoapUI 的一些重要特性。

  • 它能够充当客户端和服务的角色。

  • 它使用户能够使用单个环境快速有效地创建功能和非功能测试。

  • 它根据 GNU Leaser 通用公共许可证 (LGPL) 的条款获得许可。

  • 它完全使用 JAVA 平台实现。

  • 它支持 Windows、Mac、多种 Linux 版本。

  • 它允许测试人员在不同的 Web API 上执行自动化的功能、回归、合规性和负载测试。

  • 它支持所有标准协议和技术来测试各种 API。

SoapUI 可用于测试完整的 RESTful API 和 SOAP Web 服务测试。它支持功能测试、性能测试、互操作性测试、回归测试、负载测试等等。

它既用户友好,又易于将功能测试转换为非功能测试,例如负载、压力测试。

SoapUI - 功能

SoapUI 在以下五个方面非常丰富:

  • 功能测试
  • 安全测试
  • 负载测试
  • 协议和技术
  • 与其他工具集成

让我们进一步了解这些功能。

功能测试

  • SoapUI 允许测试人员在 SoapUI 中编写功能性 API 测试。

  • SoapUI 支持拖放功能,从而加快脚本开发。

  • SoapUI 支持调试测试,并允许测试人员开发数据驱动的测试。

  • SoapUI 支持多个环境,从而方便地在 QA、Dev 和 Prod 环境之间切换。

  • SoapUI 允许高级脚本编写(测试人员可以根据场景开发自定义代码)。

安全测试

  • SoapUI 执行一整套漏洞扫描。

  • SoapUI 防止 SQL 注入以保护数据库安全。

  • SoapUI 扫描由文档大小过大引起的堆栈溢出。

  • SoapUI 扫描跨站点脚本,当服务参数在消息中公开时发生。

  • SoapUI 执行模糊测试和边界扫描以避免服务的异常行为。

负载测试

  • SoapUI 将负载测试分布到 n 个 LoadUI 代理上。

  • SoapUI 可以轻松模拟高容量和现实世界的负载测试。

  • SoapUI 允许高级自定义报告以捕获性能参数。

  • SoapUI 允许端到端系统性能监控。

协议与技术

SoapUI 支持广泛的协议:

  • SOAP – 简单对象访问协议
  • WSDL – Web 服务定义语言
  • REST – 表述性状态转移
  • HTTP – 超文本传输协议
  • HTTPS – 超文本传输协议安全
  • AMF – Action 消息格式
  • JDBC – Java 数据库连接
  • JMS – Java 消息服务

与其他工具集成

  • Apache Maven 项目
  • HUDSON
  • JUnit
  • Apache - Ant 等等。

SoapUI - NG Pro

SoapUI 是一个具有基本测试功能的开源免费版本工具,而 SoapUI NG Pro 是一款商业化工具,具有高级报告、数据驱动功能等功能。

比较

下表比较了 SoapUI 和 SoapUI NG Pro 的各种功能。

特性 SoapUI SoapUI NG Pro
支持的技术
SOAP
WSDL/WADL
REST
JMS
AMF
JDBC
HTTP
一般功能
独立应用程序
多环境支持
浮动许可证
WSDL 覆盖率
请求/响应覆盖率
消息断言
测试重构
运行多个测试
数据源驱动测试
脚本库
单元报告
手动测试步骤
报告
Junit 报告
报告数据导出
WSDL HTML 报告
测试套件覆盖率
测试用例覆盖率
断言覆盖率
消息记录覆盖率

SoapUI - 安装与配置

SoapUI 是一款跨平台工具。它支持 Windows、Linux 和 Mac 操作系统。

先决条件

  • 处理器 - 1GHz 或更高 32 位或 64 位处理器。

  • RAM - 512MB RAM。

  • 硬盘空间 - 安装至少需要 200MB 硬盘空间。

  • 操作系统版本 - Windows XP 或更高版本,MAC OS 10.4 或更高版本。

  • JAVA - JAVA 6 或更高版本。

下载过程

步骤 1 - 访问 www.soapui.org 并点击下载 SoapUI。

Download

步骤 2 - 点击“获取”下载 SoapUI 开源版。它将开始在系统中下载 112MB 的 .exe 文件。等待下载过程完成。

Testing Downloads

安装过程

步骤 1 - 下载后,以“以管理员身份运行”的方式运行 .exe 文件。

Exe File

Windows 将启动安装过程,如下面的屏幕截图所示。

Install Wizard

步骤 2 - 安装完成后,过程窗口将显示以下屏幕,点击下一步。

Process Window

步骤 3 − 接受许可协议并点击下一步。

License Agreement

步骤 4 − 选择安装目录或保留系统选择的默认路径。点击下一步。

Installation Directory

步骤 5 − 选择要安装的组件。点击下一步。

Component

步骤 6 − 接受 HermesJMS 的许可协议并点击下一步。

License for Hermes

步骤 7 − 选择保存教程的目标目录并点击下一步。

Target Directory

步骤 8 − 选择开始菜单文件夹位置,或者保留默认位置,然后点击“下一步”。

Default Location

步骤 9 − 启用“创建桌面图标”复选框并点击“下一步”。

Desktop Icon

现在,安装开始。完成安装需要几分钟。

Installation Starts

步骤 10 − 安装完成后,在以下向导中点击完成。

Installer

点击完成之后,SoapUI 将启动。

  • 菜单栏
  • 工具栏
  • 项目导航栏
  • 工作区属性
  • 日志面板
Getting Started

配置过程

第一步是创建一个可以包含多个项目的的工作区。

步骤 1 − 转到文件 → 新建工作区。

Workspace

步骤 2 − 添加工作区名称并点击确定。

Sample Workspace

步骤 3 − 现在,选择保存工作区 xml 的路径。

步骤 4 − 选择路径并点击保存。

New Workspace

工作区创建如下面的屏幕截图所示。还显示了工作区属性。

Properties

SoapUI - WSDL

WSDL 代表 Web 服务描述语言。它是一种描述 Web 服务的标准格式。WSDL 由微软和 IBM 共同开发。WSDL 发音为“wiz-dull”,拼写为“W-S-D-L”。

WSDL ─ 简史

2001 年 3 月,Ariba、IBM 和微软将 WSDL 1.1 作为 W3C 说明提交给 W3C XML 活动,用于描述 XML 协议的服务。

WSDL 1.1 尚未获得万维网联盟 (W3C) 的认可,但它刚刚发布了 2.0 版的草案,该草案将成为建议 (正式标准),并因此获得 W3C 的认可。

WSDL ─ 注意要点

WSDL 是一种基于 XML 的协议,用于在分散和分布式环境中进行信息交换。WSDL 的其他一些功能如下:

  • WSDL 定义描述了如何访问 Web 服务以及它将执行哪些操作。

  • 它是一种用于描述如何与基于 XML 的服务交互的语言。

  • 它是通用描述、发现和集成 (UDDI) 的组成部分,UDDI 是一个基于 XML 的全球业务注册中心。

  • WSDL 是 UDDI 使用的语言。

WSDL 用法

WSDL 通常与 SOAP 和 XML Schema 结合使用,以通过互联网提供 Web 服务。连接到 Web 服务的客户端程序可以读取 WSDL 以确定服务器上有哪些可用功能。使用的任何特殊数据类型都以 XML Schema 的形式嵌入到 WSDL 文件中。然后,客户端可以使用 SOAP 实际调用 WSDL 中列出的其中一个函数。

理解 WSDL

WSDL 将 Web 服务分解成三个特定且可识别的元素,这些元素一旦定义即可组合或重用。

WSDL 的三个主要元素可以分别定义为:

  • 类型
  • 操作
  • 绑定

WSDL 文档包含各种元素,但它们包含在这三个主要元素中,这些元素可以作为单独的文档开发,然后可以组合或重用以形成完整的 WSDL 文件。

在本教程中,我们使用 CurrencyConverter WSDL:http://www.webservicex.net

格式和元素

CurrencyConverter WSDL 将如下所示:

Currency Converter

Response

Binding Elements

WSDL ─ 端口类型

<portType> 元素将多个消息元素组合成一个完整的一路或往返操作。例如,<portType> 可以将一个请求消息和一个响应消息组合成一个请求/响应操作。这最常用于 SOAP 服务。portType 可以定义多个操作。

示例

Port Type
  • portType 元素定义了一个名为 ConversionRate 的单个操作。
  • 该操作包含一个输入消息 ConversionRateHttpPostIn。
  • 输出消息的操作为 ConversionRateHttpPostOut。

操作模式

WSDL 支持四种基本的操作模式:

单向

服务接收一条消息。因此,该操作只有一个输入元素。单向操作的语法为:

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

请求 ─ 响应

服务接收一条消息并发送响应。因此,该操作包含一个输入元素,后跟一个输出元素。为了封装错误,还可以指定一个可选的故障元素。请求-响应操作的语法为:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

请求 ─ 响应

服务发送一条消息并接收响应。因此,该操作包含一个输出元素,后跟一个输入元素。为了封装错误,还可以指定一个可选的故障元素。请求-响应操作的语法为:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

通知

服务发送一条消息。因此,该操作只有一个输出元素。以下是通知操作的语法:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions> 

WSDL ─ 绑定 & 服务

<binding> 元素提供了有关 portType 操作如何实际通过网络传输的具体详细信息。

  • 绑定可以通过多种传输方式提供,包括 HTTP GET、HTTP POST 或 SOAP。

  • 绑定提供了有关用于传输 portType 操作的协议的具体信息。

  • 绑定提供了服务所在位置的信息。

  • 对于 SOAP 协议,绑定为 <soap:binding>,传输是在 HTTP 协议之上的 SOAP 消息。

  • 您可以为单个 portType 指定多个绑定。

Binding Services

服务

<service> 元素定义了 Web 服务支持的端口。对于每个支持的协议,都有一个端口元素。service 元素是端口的集合。

Web 服务客户端可以从 service 元素中了解以下内容:

  • 在哪里访问服务,
  • 通过哪个端口访问 Web 服务,以及
  • 通信消息是如何定义的。

service 元素包含一个 documentation 元素,用于提供人类可读的文档。

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service> 

SoapUI - 项目

SoapUI 项目是所有 SoapUI 测试的中心点。创建项目后,用户可以创建和运行功能测试、负载测试、创建模拟服务等等。

在本章中,我们将讨论两件事 - 如何:

  • 创建 SOAP 项目
  • 添加 WSDL

创建 SOAP 项目

步骤 1 − 在屏幕左侧的导航器中,右键单击“项目”并选择“新建 SOAP 项目”。

SOAP Project

或者转到文件并选择新建 Soap 项目。

Select File

选择后,将打开一个新的弹出窗口 - 新建 Soap 项目。

步骤 2项目名称:输入项目名称 - 它是用户输入字段。初始 WSDL:这不是强制性的。这取决于用户。用户可以提供 WSDL 或在创建项目后添加。

在本例中,我们创建了一个项目并在稍后添加了 WSDL。

Create Project

步骤 3 − 点击确定。它将创建一个新项目,并且将在左侧导航面板上可见。

Navigation Panel

添加 WSDL

SOAP 项目基于 WSDL。不必从导入 WSDL 开始,但它使测试更容易,因为 WSDL 包含测试 Web 服务所需的所有信息,例如有关请求和响应的信息、它们包含的内容等等,从而简化了 SoapUI 测试。

步骤 1 − 要添加 WSDL,请右键单击项目名称 (SOAP – Example) 并选择添加 WSDL。

Add WSDL

选择后,将显示 WSDL 向导。

步骤 2WSDL 位置:输入 WSDL 作为 http://www.webservicex.com 或从计算机中浏览它。

步骤 3 − 一旦输入 WSDL,3 个复选框 - 创建请求、创建测试套件、创建模拟服务将被启用。根据需求,用户可以选中一个或多个复选框。

默认情况下,选中创建请求的复选框。

Create Request

步骤 4 − 点击确定。WSDL 已成功添加到项目中。可以通过观察左侧导航面板进行验证。在项目内部,有多个操作,并且根据 WSDL 添加了请求。

Multiple Operation

详细信息视图

要获取项目的更多详细信息,请双击项目名称,它将打开一个包含各种详细信息的新窗口。

在概述选项卡中,提供了各种信息,例如:

  • 文件路径 − 它显示保存的项目 xml 的位置。

  • 接口摘要 − 与之关联的接口名称和 WSDL。

  • 测试摘要 − 它显示添加到项目的测试套件、测试用例、测试步骤、断言。

Detail View

用户可以双击接口名称以获取接口详细信息。它将打开一个新窗口并显示与 WSDL 相关的信息。这些信息对于浏览和检查 WSDL 非常有用。

在概述选项卡中,它列出了 WSDL 定义、定义部分和操作详细信息。

Definition Part

同样,服务端点列出了端点的详细信息。

Endpoint

在 WSDL 内容选项卡中,提供了 XML/schema 格式的 WSDL 的所有详细信息,如下面的屏幕截图所示。

Content Tab

SoapUI - 测试套件

测试套件是测试用例的集合,可用于将功能测试分组到逻辑单元中。可以在 SoapUI 项目中创建任意数量的测试套件以支持大量的测试场景。

测试套件的创建

步骤 1 − 在项目中,右键单击接口(项目名称旁边),然后单击“生成测试套件”。

这里,SOAP – Example 是项目名称,而 CurrencyConvertorSoap 和 CurrencyConvertorSoap12 是接口。

Generate Testsuite

步骤 2 − 将打开一个新的向导。根据需求选择选项。

步骤 3 − 完成选择后,点击确定。

Create Testsuite

步骤 4 − 选中生成负载测试的复选框。这将为在此测试套件中创建的每个测试用例生成一个负载测试。

步骤 5 − 在新的向导中输入测试套件名称,然后点击确定。

Testsuite Name

创建的测试套件显示在导航面板中,如下面的屏幕截图所示。

Display Navigation

步骤 6 − 双击测试套件名称,测试套件窗口将在右侧面板打开。由于没有添加测试用例,因此它是空白的。

Right Panel

测试套件属性可以在导航面板底部查看。可以在测试套件级别添加新的自定义属性。

Custom Properties

SoapUI - 测试用例

测试用例是一组用于测试 Web 服务某些特定方面的测试步骤的集合。用户可以向测试套件添加 n 个测试用例,甚至可以将它们模块化以相互调用,以实现复杂的测试场景。

创建测试用例

步骤 1 − 在测试套件中,用户可以添加多个测试用例。右键单击测试套件并选择“新建测试用例”。

New Testcase

步骤 2 − 输入测试用例的名称,然后单击“确定”。

TestCase Name

创建的测试用例目前没有测试步骤。所有类型的可用测试都添加了零测试步骤的测试用例。添加测试步骤后,括号中的数字将自动更改。功能测试步骤应进入“测试步骤”,而性能测试步骤应进入“负载测试”,安全测试步骤应进入“安全测试”。

Functional Test

步骤 3 − 双击测试用例名称,右侧面板上将打开一个测试用例窗口。由于没有添加测试步骤,因此它为空白,如下面的屏幕截图所示。

Testcase Window

SoapUI - 测试步骤

测试步骤是 SoapUI 中功能测试的“构建块”。它们被添加到测试用例中,用于控制执行流程并验证要测试的 Web 服务的功能。

插入测试步骤

步骤 1 − 右键单击测试步骤。添加步骤并从列表中选择一个合适的测试步骤。例如,如果用户必须测试 REST Web 服务,则用户将选择 REST 测试请求。

Add Step

步骤 2 − 通过选择“测试步骤”→“添加步骤”→“SOAP 请求”来添加一个测试步骤以验证导入的 SOAP 请求。

步骤 3 − 在向导中输入测试步骤的名称,然后单击“确定”。

Specify Name

单击“确定”后,将弹出一个对话框以选择要调用的操作。列出了所有操作,用户可以选择他们想要调用的操作。

将列出两个操作。这两个操作都相同,只是使用的 SOAP 版本不同。CurrencyConvertorSoap 使用 SOAP 版本 1.1,而 CurrencyConvertorSoap12 使用 SOAP 版本 1.2。

步骤 4 − 选择第一个 – CurrencyConvertorSoap 并单击“确定”。

Testrequest

在添加测试用例时,可以添加不同的标准断言。断言也称为 SOAP 请求/响应的检查点/验证点。

步骤 5 − 让我们创建一个具有默认选项的测试用例,这意味着创建一个没有任何以下验证点的测试步骤:

  • 执行测试后,验证响应消息是否为 SOAP。
  • 验证响应架构是否有效。
  • 验证 SOAP 响应是否包含 FAULT。
Add Request to Case

步骤 6 − 单击“确定”后,将弹出以下请求 XML 屏幕截图。

Request XML

由于添加了功能测试步骤,因此测试步骤计数现在增加到 1。类似地,在添加负载和安全测试步骤后,相应的数字会根据添加的步骤数量自动增加。

Incremented

SoapUI - 请求与响应

请求设置

在这里,我们将执行将货币从 INR 转换为 USD 的操作。

  • FromCurrency – INR
  • ToCurrency – USD

接下来,将这些输入输入到问号所在的位置,这些输入将作为请求 XML 发送。将这些值放入相应的 XML 标签后,单击“提交请求”按钮以检查响应。

Submit Request

响应

提交请求后,Web 服务请求将由 Web 服务器处理并发送回响应,如下面的屏幕截图所示。

通过读取响应,可以得出结论,1 个 INR 单位 = 0.0147 个 USD 单位。

Web-server Response

HTTP 请求

SOAP 消息通过 HTTP 协议传输。要查看 HTTP 请求,请单击 SoapUI 请求窗口(左侧)中的“RAW”。

HTTP Request

请求发布到 Web 服务器。因此,使用 Http 的 POST 方法。

SOAP 请求在 http 消息的主体中传输,如下所示。

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5) 

HTTP 响应

单击 SOAP-UI 响应窗口中的“RAW”选项卡以了解响应如何通过 HTTP 发送。

处理请求后,将显示 http 响应代码 (200),这意味着它是成功的。Web 服务器已成功处理它。

SOAP 响应作为 HTTP 消息主体的一部分发送回客户端。

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316 

Http Response

以下 HTTP 代码用于 Web 服务器发送响应,对于调试非常有用。

HTTP 代码 描述

1xx

信息性 − 这表示已收到请求并且正在进行处理。

2xx

成功 − 操作已成功接收、理解和接受。

3xx

重定向 − 这表示必须采取进一步的操作才能完成请求。

4xx

客户端错误 − 这表示请求包含错误的语法或无法满足。

5xx

服务器错误 − 服务器未能满足显然有效的请求。

SoapUI - 属性

属性是使用 SoapUI 进行更高级测试的核心方面。功能测试属性用于参数化测试的执行和功能。

  • 属性可用于保存服务的端点,从而可以轻松更改测试执行期间使用的实际端点。

  • 属性可用于保存身份验证凭据,从而可以轻松地在中心位置或外部文件中管理这些凭据。

  • 属性可用于在测试执行期间传输和共享会话 ID,以便多个测试步骤或测试用例可以共享相同的会话。

定义属性

可以在项目的多个级别定义属性。

  • 可以在项目级别定义项目级通用的属性。

  • 类似地,可以在其各自的级别定义测试套件和测试用例特定的属性。

  • 项目特定属性在“自定义属性”选项卡中定义。

Defining Properties

例如,可以通过单击“+”符号并输入属性名称和值来在项目级别定义属性“ToCurrency”。

ToCurrency

访问属性

可以使用属性扩展在项目的任何位置访问属性。

结构如下:

  • ${#Project#PropertyName} – 适用于项目级别

  • ${#TestSuite#PropertyName} – 适用于测试套件级别

  • ${#TestCase#PropertyName} – 适用于测试用例级别

  • ${TestStepName#PropertyName} – 适用于测试步骤级别

  • ${#MockService#PropertyName} – 适用于模拟服务属性

  • ${#Global#PropertyName} – 适用于全局属性,位于“文件”→“首选项”→“全局属性”选项卡中。此属性可在所有项目中使用

  • ${#System#PropertyName} – 适用于系统属性,位于“帮助”→“系统属性”中

  • ${#Env#PropertyName} – 适用于环境变量

相同的结构可以放在请求 XML 中,以便在运行时获取特定属性的值。

Same Structure

属性也可以被视为计算机程序中的变量。如果用户想要定义一些可以在其他地方使用的内容,则属性非常有用。属性也可以动态定义,但它依赖于 Groovy 脚本。

SoapUI - 属性传递

有时需要从响应消息中提取某些值并将其包含在后续请求中。在这种情况下,我们需要有一种机制来检索指定的值并将其传输到项目的其他元素。SoapUI 通过属性传输测试步骤支持此类功能。

添加属性传输

步骤 1 − 选择测试用例或测试步骤,右键单击→添加步骤→属性传输。

Adding Property

步骤 2 − 输入测试步骤名称,然后单击“确定”。

Rate Transfer

步骤 3 − 添加 RateTransfer 步骤,并将打开一个新的向导。

New Wizard

步骤 4 − 单击属性传输窗口左上角的“添加新的属性传输”图标 +。系统将提示您输入传输的名称。输入 Rate 并单击“确定”。

Rate

传输属性

创建传输后,目标窗格需要指定相关的 XPath 表达式以提取和替换属性值。在“源”旁边的下拉框中,列出了可用作属性传输源的 SoapUI 项目的各个级别。默认情况下,将显示最接近的测试步骤。

在本例中,它是请求 – INR 到 USD测试步骤。在“属性”旁边的下拉列表中显示了传输中使用的源属性,该属性可以是请求、响应或服务端点。

Transfer Property

步骤 1 − 选择“响应”并转到“路径语言”。用户可以选择 XPath、Xquery 或 Jason 来定义属性。在本例中,选择 XPath。

Path Language

步骤 2 − 要获取源 xml 的声明,请单击 ns 并指定 XPath。

步骤 3 − 指定要将从上述 XPath 表达式中提取的值传输到的目标。为此,请使用属性传输窗口底部的目标窗格。

步骤 4 − 传输从 RequestINRtoUSD 步骤的响应中提取的 ConversionRateResult 值。

目标 − 属性

属性 − ConversionRate(添加了一个新属性,最初没有值)。

Target Property

步骤 5 − 测试用例成功运行后,属性“ConversionRate”将根据响应进行更新。

以下是初始屏幕截图。

Conversion Rate

以下是成功运行后的屏幕截图。

Successful Run

类似地,目标可以是下一个请求 XML。如果目标是 SOAP 请求,我们需要提供 XPath 以识别目标属性。

SoapUI - 日志面板

日志窗格存储有关客户端和服务器之间事务的完整信息。用户将能够看到日志窗格的各个选项卡。在本章中,我们将讨论在使用 SoapUI 时最常用的日志窗格。

Transaction Properties

SoapUI 日志

SoapUI 日志显示来自 Web 服务器的响应信息。相同的信息存储在 SOAP-UI 安装文件夹下的“bin”目录中的 soapui.log 文件中。

UI Log

HTTP 日志

HTTP 日志显示所有 HTTP 数据包传输。HTTP 日志中显示了“RAW”中的所有信息。

Http Packet Transfer

错误日志

错误日志显示整个项目会话期间遇到的所有错误。相同的信息可在 SoapUI 安装位置的“bin”目录中的“soapui-errors.log”中找到。

内存日志

此选项卡监视内存消耗并以图表的形式显示它,如下面的屏幕截图所示。当执行内存密集型操作时,它确实很有帮助。

Memory Log

SoapUI - 断言

断言可以解释为检查点或验证点。将请求发送到 Web 服务器后,将收到响应。需要验证响应是否包含预期的数据。为了验证响应,SoapUI 具有断言功能。

注意事项

  • 断言用于验证测试步骤在执行期间收到的消息。

  • 它将消息的一部分或整个消息与某个预期值进行比较。

  • 可以向测试步骤添加任意数量的断言,每个断言都验证响应消息的某些不同方面和内容。

  • 测试步骤执行后,其所有断言都将应用于收到的响应,如果任何断言失败,则测试用例视图中将标记测试步骤已失败。

  • 测试执行日志中显示失败的条目。

Execution Log

断言类型

SoapUI 支持响应中的各种断言。

以下是 SoapUI 支持的断言列表。

断言 描述
属性内容
包含 检查指定字符串是否存在。它也支持正则表达式。
不包含 检查指定字符串是否不存在。它也支持正则表达式。
XPath 匹配 使用 XPath 表达式选择目标节点及其值。将 XPath 表达式的结果与预期值进行比较。
XQuery 匹配 使用 Xquery 表达式从目标属性中选择内容。将 XQuery 表达式的结果与预期值进行比较。
合规性、状态、标准

HTTP 下载所有资源 下载 HTML 文档引用的所有资源(图像、脚本等),并验证它们是否都可用。适用于包含 HTML 的任何属性。
无效 HTTP 状态码 检查目标测试步骤是否收到 HTTP 结果,其状态码不在定义的代码列表中。适用于接收 HTTP 消息的任何测试步骤。
非 SOAP 错误 验证最后接收到的消息不是 SOAP 错误。适用于 SOAP 测试步骤。
模式一致性 验证最后接收到的消息是否与关联的 WSDL 或 WADL 模式定义一致。适用于 SOAP 和 REST 测试步骤。模式定义 URL 支持属性扩展(例如 ${#System#my.wsdl.endpoint}/services/PortType?wsdl)。
SOAP 错误 验证最后接收到的消息是否为 SOAP 错误。适用于 SOAP 测试步骤。SOAP 请求 - 验证最后接收到的请求是否为有效的 SOAP 请求。仅适用于模拟响应测试步骤。
SOAP 响应 验证最后接收到的响应是否为有效的 SOAP 响应。仅适用于 SOAP 测试请求步骤。
有效 HTTP 状态码 检查目标测试步骤是否收到 HTTP 结果,其状态码在定义的代码列表中。适用于接收 HTTP 消息的任何测试步骤。
WS-Addressing 请求 验证最后接收到的请求是否包含有效的 WS-Addressing 标头。仅适用于模拟响应测试步骤。
WS-Addressing 响应 验证最后接收到的响应是否包含有效的 WS-Addressing 标头。仅适用于 SOAP 测试请求步骤。
WS-Security 状态 验证最后接收到的消息是否包含有效的 WS-Security 标头。适用于 SOAP 测试步骤。
脚本
脚本断言 允许用户执行自定义脚本以执行用户定义的验证。仅适用于测试步骤(即不适用于属性)。
SLA
响应 SLA 验证最后接收到的响应的响应时间是否在定义的限制范围内。适用于脚本测试步骤和发送请求并接收响应的测试步骤。
JMS
JMS 状态 验证目标测试步骤的 JMS 请求是否成功执行。适用于具有 JMS 端点的请求测试步骤。
JMS 超时 验证目标测试步骤的 JMS 语句是否未超过指定持续时间。适用于具有 JMS 端点的请求测试步骤。
安全
敏感信息泄露 验证响应消息是否未泄露有关目标系统的敏感信息。我们可以将此断言用于 REST、SOAP 和 HTTP 测试步骤。
JDBC
JDBC 状态 验证目标测试步骤的 JDBC 请求是否成功执行。仅适用于 JDBC 测试步骤。
JDBC 超时 验证目标测试步骤的 JDBC 语句是否未超过指定持续时间。仅适用于 JDBC 测试步骤。

SoapUI - 故障排除

在 SoapUI 中,用户会遇到许多通用问题,这些问题可以通过一点警惕性解决。以下是一些最常见的问题:

问题 - 命名空间定义错误。使用正确的命名空间。命名空间应为 Web 服务所在的 URL。

解决方案 - 如果在开发脚本断言时抛出错误,请使用“log.info”打印变量的内容。

问题 - 如果收到错误代码作为响应 XML,则可能是由于输入无效。

解决方案 - 验证请求 XML 的输入。

示例 - 在货币转换器中,如果“FromCurrency”的输入为“123”(不存在),则输出会抛出错误代码“SOAP-Client”,这意味着问题出在从客户端传递的参数上。

请求

Parameter

响应

Fault Code

问题 - 使用 XPath 或 XQuery 时,当前响应中没有匹配项。

解决方案 -

  • 定义 XPath 或 XQuery 时使用正确的语法。
  • 验证在声明命名空间时使用了冒号而不是点。
  • 确保 XPath 和 XQuery 正确。
Not Match Response

SoapUI - 性能测试

性能测试是 Web 服务测试中最常见的关键检查点之一。性能测试定义为人为创建或模拟负载,并衡量环境如何处理它。

这意味着它不一定必须是系统在高负载下的性能表现,它也可以是系统在基本负载或预期负载下的性能表现。它甚至不必是结构化的、自动化的或在 SoapUI 等测试软件中创建的;简单地反复快速刷新 Web 浏览器也是一种负载测试。

性能测试类型

以下是性能测试的类型:

  • 基准测试 - 检查系统在预期或正常负载下的性能,并创建一个基线,其他类型的测试可以以此为参考进行比较。

  • 负载测试 - 包括增加负载并查看系统在更高负载下的行为。在负载测试期间,用户可以监控响应时间、吞吐量、服务器状态等等。负载测试的目标不是破坏目标环境。

  • 浸泡测试 - 测试的目标是确保在较长时间内不会出现任何意外行为。

  • 可扩展性测试 - 可扩展性测试与负载测试非常相似,但是它不是增加请求数量,而是增加发送的请求的大小或复杂性。例如,发送大型请求、大型附件或嵌套很深的请求。

Web 服务的关键方面

Web 服务性能的独特特性有两个方面脱颖而出。

第一个方面

在服务器端,正在进行 XML/JSON 处理,包括 XML/JSON 解析和序列化。经常首先失败的是有效负载的处理。失败的原因可能是多方面的;它可能存在于平台、应用程序服务器的弱点中,也可能是由于 WSDL 不必要地复杂而导致的实现问题。它也可能意味着代码正在向响应缓慢的数据库发出请求。

测试方面 - 解析 XML/JSON 有效负载的复杂性意味着需要额外关注可扩展性测试。这也意味着应该仔细检查 WSDL。如果请求和响应很复杂或很大,或者如果它们包含大型附件,则应重点关注复杂性,并查看它在负载下的行为。

第二个方面

另一个经常遇到的因素是安全。HTTPS 后面的安全站点性能明显较低,在 Web 服务测试中,我们可以在 HTTP 安全层上添加一层 WSSecurity,从而进一步降低性能。

测试方面 - 安全问题意味着需要重点进行安全请求的测试。如果整个 Web 服务都是安全的,则意味着负载测试更为重要,尤其是在使用 WS-Security 和令牌处理时。

SoapUI - 负载测试

负载测试是性能测试的一种特定形式,用于评估系统在特定负载下的行为。在 SoapUI 中,我们通常将术语“负载测试”用于所有类型的非功能测试,但 SoapUI 支持 Web 服务的所有类型的性能评估,例如负载、压力和耐力。

注意事项

  • 负载测试在 SoapUI 中非常独特;它是一个功能测试用例,允许快速创建和修改性能测试。

  • 主要的区别在于,SoapUI 中的性能测试通常是从现有的功能测试创建的。这允许快速创建高级性能测试。

  • 可以在不同的负载场景下验证 Web 服务性能。维护功能验证以确保它们在负载下不会中断,同时运行多个负载测试以查看它们如何相互影响等等。

负载测试的创建

步骤 1 - 右键单击功能测试用例,然后选择“新建负载测试”。

New Load Test

步骤 2 - 在对话框向导中输入负载测试的名称,然后单击“确定”。

Dialog Wizard

负载测试将打开,并创建负载测试,如下面的屏幕截图所示。

Open Load Test

负载测试的执行

创建新的负载测试时,它预配置为使用简单的负载策略运行 60 秒(右上角)并使用 5 个线程。

根据需要修改这些值并运行。注意 - 用户应了解负载测试配置和概念。

Load Configuration

用户将在中间看到统计表,从收集数据开始,60 秒后应完成负载测试。

Statistic Table

添加断言

步骤 1 - 在负载测试编辑器中,选择编辑器底部的“负载测试断言”选项卡。

Load Test Assertion

步骤 2 - 单击“负载测试断言”菜单栏中的“添加断言”按钮以添加断言。

Assertion Button

步骤 3 - 将打开“添加断言”对话框。选择“步骤最大值”。选择“最大值”设置响应允许花费的最大时间(以毫秒为单位),如果时间超过我们设置的时间,则测试将失败。单击“确定”。

Max Error

步骤 4 - 将打开“测试步骤最大值断言”窗口。如以下屏幕截图所示,我们允许最大响应时间为 1 秒,即 1000 毫秒。我们暂时不修改任何内容。单击“确定”。

Step Maximum

现在将成功添加“步骤最大值”断言。

Added Maximum

步骤 5 - 现在再次运行测试。如果响应花费的时间过长,您应该会看到“err”列中的数字迅速增加。

Error Column

SoapUI - RESTful Web 服务

Web 服务是一组用于在应用程序或系统之间交换数据的开放协议和标准。用各种编程语言编写并在各种平台上运行的软件应用程序可以使用 Web 服务通过计算机网络(如互联网)交换数据,其方式类似于单个计算机上的进程间通信。这种互操作性(例如,Java 和 Python 之间或 Windows 和 Linux 应用程序之间)是由于使用了开放标准。

基于 REST 架构的 Web 服务称为 RESTful Web 服务。这些 Web 服务使用 HTTP 方法来实现 REST 架构的概念。RESTful Web 服务通常定义一个 URI(统一资源标识符),它是一个提供资源表示(如 JSON)和一组 HTTP 方法的服务。

SoapUI 的所有 REST 测试功能都基于称为 REST 服务的逻辑表示。我们不应该将此处的术语“服务”与服务实现混淆,因为它不是服务实现,而是对正在调用的 RESTful 服务的映射。我们可以在 SoapUI 项目中添加任意数量的 REST 服务。每个都代表一个特定的 RESTful 服务。它们如下:

SoapUI - JDBC 连接

SoapUI 允许使用名为 JDBC 请求的测试步骤来管理数据库操作。

步骤 1 - 右键单击测试步骤,然后选择“添加步骤”→“JDBC 请求”。

JDBC Request

步骤 2 - 输入步骤名称,然后单击“确定”。

New Step

JDBC 步骤已添加。双击步骤,将打开 JDBC 向导。

JDBC Wizard

要创建 JDBC 连接,用户需要提供有效的驱动程序和连接字符串。这些参数用于识别数据库类型并创建连接以使用数据库。

对于 MySQL,数据库驱动程序可以是com.mysql.jdbc.Driver。类似地,对于其他数据库,也存在一个预定义的驱动程序,可以在数据库的文档部分找到。

步骤 3 − 连接字符串应采用以下格式 −

Jdbc:mysql://[host]:[port]/[database]?[property][=value] 

这里,property 是用户名和密码以及连接到数据库所需的其它参数。

例如,

jdbc:mysql://127.0.0.1:8089/xxx_DB?user=root&password=root 

步骤 4 − 点击测试连接。连接成功后,将显示 SUCCESS,否则提供失败的详细信息。

Test Connection

SoapUI - JDBC 属性

JDBC 有自己的添加属性部分,可以作为 SQL 查询中的变量使用。

让我们看看它是如何工作的 −

假设,需要在 JDBC 步骤中执行的 SQL 查询是 Select * from Currency where CurrencyCode = ‘xxx’。

在这种情况下,CurrencyCode 可以根据请求输入进行更改。如果用户提供硬编码的值,JDBC 步骤将不会对请求中给定的那些货币执行。

为了克服这种情况,JDBC 支持添加属性,其中可以定义一个属性 Code,并且它将使用属性传递步骤不断变化。

SQL 查询将根据属性 Code 的当前值运行,并且 SQL 查询将参数化 CurrencyCode =:Code。

点击添加属性 + 并将名称设置为 Code,并提供值或保持空白以使用属性传递步骤提供它。

Add Property

SoapUI - JDBC 断言

JDBC 请求也可以利用大多数与 SOAP 请求 TestSteps 的断言。在 SoapUI 中,大多数这些断言独立于 TestSteps。因此,诸如 Contains 和 XPath Match 之类的断言可以与 JDBC Request TestStep 一起使用。

通过点击 JDBC Request TestStep 顶部菜单中的添加断言图标,用户可以找出 TestStep 支持哪些断言。

除了通用断言之外,还有两个 JDBC Request TestStep 特定的断言 −

JDBC 超时 − 此断言可用于验证当前 SQL 查询是否在指定的 Query Timeout 属性值内执行。

JDBC 状态 − 为了检查 SQL 语句是否成功执行,我们可以使用 JDBC 状态断言。

JDBC Status

要设置查询超时,请在屏幕左侧提供相应的属性 Query Timeout 值。请记住,它接受以毫秒 (ms) 为单位的值。

Property Query
广告