SoapUI – 快速指南

SoapUI – 快速指南

SOAP – 简介

SOAP 是简单对象访问协议的首字母缩写词。它由万维网联盟（W3C）在https://www.w3.org/TR/2000/NOTE-SOAP-20000508定义如下 –

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

SOAP – 重要功能

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

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

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

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

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

  • 它可用于广播消息。

  • 它既独立于平台又独立于语言。

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

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

尽管 SOAP 可用于各种消息传递系统，并可通过各种传输协议进行交付，但 SOAP 的最初重点是通过 HTTP 传输的远程过程调用。其他框架（如 CORBA、DCOM 和 Java RMI）提供与 SOAP 类似的功能，但 SOAP 消息完全用 XML 编写，因此独特地独立于平台和语言。

SOAP – 消息

SOAP 消息是包含以下元素的普通 XML 文档 –

  • 信封– 定义消息的开始和结束。它是一个强制性元素。

  • Header – 包含用于处理消息的消息的任何可选属性，无论是在中间点还是在最终端点。它是一个可选元素。

  • Body – 包含包含正在发送的消息的 XML 数据。它是一个强制性元素。

  • Fault – 一个可选的 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。

  • 它是 WebService 和 RPC（远程过程调用）的轻量级替代品，如 SOAP-WSDL。

  • 它代表唯一 ID 或 URI 中的所有内容。

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

  • 它将资源链接在一起。

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

  • 任何命名信息都被视为资源。例如：一张图片、一个人、一个文档，都可以看作是一个资源的例子，并表示为一个唯一的 ID 或一个 URI。

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

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

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 – 动作消息格式
  • JDBC – Java 数据库连接
  • JMS – Java 消息服务

与其他工具集成

  • Apache Maven 项目
  • 哈德逊
  • JUnit
  • Apache – Ant 等等……

SoapUI – NG Pro

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

比较

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

Features 用户界面 SoapUI NG Pro
Supported Technologies
SOAP 是的 是的
WSDL/WADL 是的 是的
REST 是的 是的
JMS 是的 是的
AMF 是的 是的
JDBC 是的 是的
HTTP 是的 是的
General Features
Standalone Application 是的 是的
Multi Environment Support 不 是的
Floating Licence 不 是的
WSDL Coverage 不 是的
Request/Response Coverage 不 是的
Message Assertion 是的 是的
Test Refactoring 不 是的
Running multiple tests 是的 是的
Data Source Driven Test 不 是的
Scripting Libraries 不 是的
Unit Reporting 不 是的
Manual test steps 是的 是的
Reporting
Junit Reports 不 是的
Report Data Export 不 是的
WSDL HTML Report 是的 是的
Test Suite Coverage 不 是的
Test Case Coverage 不 是的
Assertion Coverage 不 是的
Message Recording Coverage 不 是的

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。

下载

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

测试下载

安装过程

步骤 1 – 下载后，以“以管理员身份运行”运行 .exe 文件。

exe文件

Windows 将开始设置过程，如下面的屏幕截图所示。

安装向导

步骤 2 – 设置后，进程窗口显示以下屏幕，单击下一步。

工艺窗口

步骤 3 – 接受许可协议并单击下一步。

许可协议

Step 4 – 选择安装目录或将其保留为系统选择的默认路径。点击下一步。

安装目录

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

成分

步骤 6 – 接受 HermesJMS 的许可协议，然后单击下一步。

爱马仕许可证

步骤 7 – 选择目标目录以保存教程，然后单击下一步。

目标目录

步骤 8 – 选择开始菜单文件夹位置，或者保持默认位置不变，然后单击“下一步”。

默认位置

步骤 9 – 启用复选框“创建桌面图标”，然后单击“下一步”。

桌面图标

现在，安装开始。需要几分钟才能完成。

安装开始

步骤 10 – 安装完成后，在以下向导中单击完成。

安装程序

单击完成后，将启动 SoapUI。

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

入门

配置流程

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

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

工作区

步骤 2 – 添加工作区的名称并单击确定。

示例工作区

步骤 3 – 现在，选择将保存工作区 xml 的路径。

步骤 4 – 选择路径并单击保存。

新工作区

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

特性

SoapUI – WSDL

WSDL 代表 Web 服务描述语言。它是描述 Web 服务的标准格式。WSDL 是由 Microsoft 和 IBM 联合开发的。WSDL 发音为“wiz-dull”，拼写为“WSD-L”。

WSDL ─ 简史

2001 年 3 月，Ariba、IBM 和 Microsoft 将 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 结合使用，以通过 Internet 提供 Web 服务。连接到 Web 服务的客户端程序可以读取 WSDL 以确定服务器上可用的功能。使用的任何特殊数据类型都以 XML 模式的形式嵌入到 WSDL 文件中。然后，客户端可以使用 SOAP 实际调用 WSDL 中列出的功能之一。

理解 WSDL

WSDL 将 Web 服务分解为三个特定的、可识别的元素，一旦定义，就可以组合或重用这些元素。

可以单独定义的 WSDL 的三个主要元素是 –

  • 类型
  • 操作
  • 捆绑

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

在本教程中，我们遵循 CurrencyConverter WSDL：http : //www.webservicex.net

格式和元素

CurrencyConverter WSDL 将如下所示 –

货币换算

回复

绑定元素

WSDL ─ 端口类型

<portType> 元素组合多个消息元素以形成完整的单向或往返操作。例如，<portType> 可以将一个请求和一个响应消息合并为一个请求/响应操作。这在 SOAP 服务中最常用。一个 portType 可以定义多个操作。

例子

端口类型

  • 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 ─ 绑定与服务

所述<结合>元素提供关于如何具体细节的portType操作实际上将通过线路进行传输。

  • 可以通过多种传输方式（包括 HTTP GET、HTTP POST 或 SOAP）使绑定可用。

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

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

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

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

绑定服务

服务

所述<服务>元素定义由web服务所支持的端口。对于每种支持的协议，都有一个端口元素。服务元素是端口的集合。

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

  • 在哪里访问服务，
  • 通过哪个端口访问网络服务，以及
  • 如何定义通信消息。

服务元素包括文档元素以提供人类可读的文档。

<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 项目”。

选择文件

选择后，将打开一个新的弹出窗口 -New Soap Project。

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

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

创建项目

步骤 3 – 单击确定。它将创建一个新项目，并将在左侧导航面板上可见。

导航面板

添加 WSDL

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

步骤 1 – 要添加 WSDL，请右键单击项目名称（SOAP – 示例）并选择添加 WSDL。

添加 WSDL

选择后，将显示 WSDL 向导。

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

第 3 步– 输入 WSDL 后，将启用 3 个复选框 – 创建请求、创建 TestSuite、创建 MockServices。根据需求，用户可以勾选一个或多个复选框。

默认情况下，创建请求复选框处于选中状态。

创建请求

步骤 4 – 单击确定。WSDL 已成功添加到项目中。可以通过观察左侧导航面板来验证。项目内部有多个操作，按照WSDL添加请求。

多重操作

详情查看

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

在概览选项卡中，提供了各种信息，例如 –

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

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

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

详细视图

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

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

定义部分

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

端点

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

内容标签

SoapUI – 测试套件

TestSuite是一组测试用例，可用于将功能测试分组为逻辑单元。可以在 SoapUI 项目中创建任意数量的 TestSuite，以支持海量测试场景。

创建测试套件

步骤 1 – 在项目中，右键单击界面（项目名称旁边），然后单击“生成 TestSuite”。

此处，SOAP – Example 是项目名称，而 CurrencyConvertorSoap 和 CurrencyConvertorSoap12 是接口。

生成测试套件

第 2 步– 一个新向导打开。根据要求选择选项。

步骤 3 – 做出选择后，单击确定。

创建测试套件

步骤 4 – 选中 Generate LoadTest 复选框。这将为在此 TestSuite 中创建的每个测试用例生成一个 LoadTest。

步骤 5 – 在新向导中输入 TestSuite 名称，然后单击确定。

测试套件名称

创建的 TestSuite 显示在导航面板中，如下面的屏幕截图所示。

显示导航

步骤 6 – 双击 TestSuite 名称，TestSuite 窗口将在右侧面板中打开。由于没有添加测试用例，所以它是空白的。

右面板

TestSuite 属性可以在导航面板的底部看到。可以在 TestSuite 级别添加新的自定义属性。

自定义属性

SoapUI – 测试用例

TestCase 是一组 TestSteps 的集合，用于测试 Web 服务的某些特定方面。用户可以将 n 个测试用例添加到一个 TestSuite 中，甚至可以将它们模块化以在复杂的测试场景中相互调用。

创建测试用例

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

新测试用例

步骤 2 – 输入测试用例的名称，然后单击确定。

测试用例名称

到目前为止，创建的 TestCase 的测试步骤为零。TestCase 为各种可用的测试添加了零测试步骤。添加 TestSteps 后，括号中的数字将自动更改。功能性 TestStep 应进入“测试步骤”，而性能 TestStep 应进入“负载测试”，安全性 TestStep 应进入“安全测试”。

功能测试

步骤 3 – 双击 TestCase Name，然后在右侧面板上打开一个 TestCase 窗口。由于没有添加 TestSteps，它是空白的，如下面的屏幕截图所示。

测试用例窗口

SoapUI – TestStep

TestSteps 是 SoapUI 中功能测试的“构建块”。这些被添加到测试用例中，用于控制执行流程和验证要测试的 Web 服务的功能。

插入 TestStep

步骤 1 – 右键单击​​ TestSteps。添加步骤并从列表中选择适当的测试步骤。例如，如果用户必须测试 REST Web 服务，则用户将选择 REST 测试请求。

添加步骤

Step 2 – 添加一个 TestStep 以通过选择 TestSteps → Add Step → SOAP Request 来验证导入的 SOAP 请求。

步骤 3 – 输入 TestStep 的名称，然后在向导中单击确定。

指定名称

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

将列出两个操作。除了使用的 SOAP 版本外，这两个操作是相同的。CurrencyConvertorSoap使用 SOAP 1.1 版，而CurrencyConvertorSoap12使用 SOAP 1.2 版。

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

测试请求

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

第 5 步– 让我们创建一个带有默认选项的 TestCase，这意味着创建一个没有以下任何验证点的 TestStep –

  • 在执行测试时验证响应消息是否为 SOAP。
  • 验证响应模式是否有效。
  • 验证 SOAP 响应是否包含 FAULT。

将请求添加到案例

步骤 6 – 单击“确定”后，会弹出以下请求 XML 屏幕截图。

请求 XML

随着功能性 TestStep 的添加，测试步骤计数现在增加到 1。同样，在添加负载和安全性 TestSteps 后，相应的数量会根据添加的步骤数自动增加。

增加的

SoapUI – 请求和响应

请求设置

在这里，我们将执行货币从 INR 到 USD 的转换。

  • FromCurrency – 印度卢比
  • ToCurrency – 美元

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

提交请求

回复

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

通过阅读回复，可以得出结论，1 单位印度卢比 = 0.0147 单位美元。

网络服务器响应

HTTP 请求

SOAP 消息通过 HTTP 协议传输。要查看 HTTP 请求，请在 SoapUI 请求窗口（左侧）中单击 RAW。

HTTP 请求

请求被发布到网络服务器。因此，使用 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)，表示请求成功。网络服务器已成功处理它。

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 响应

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

HTTP Code 描述

1xx:

信息– 这意味着收到了一个请求，并且有一个持续的过程。

2xx:

成功– 动作被成功接收、理解和接受。

3xx:

重定向– 这意味着必须采取进一步行动才能完成请求。

4xx:

客户端错误– 这意味着请求包含错误的语法或无法完成。

5xx:

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

SoapUI – 属性

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

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

  • 属性可用于保存身份验证凭据，以便在中央位置或外部文件中轻松管理这些凭据。

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

定义属性

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

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

  • 类似地，可以在各自的级别定义 TestSuite 和 TestCase 特定属性。

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

定义属性

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

到货币

访问属性

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

结构将是 –

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

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

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

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

  • ${#MockService#PropertyName} – 用于 MockService 属性

  • ${#Global#PropertyName} – 对于全局属性，可在文件 → 首选项 → 全局属性选项卡中找到。此属性可用于所有项目

  • ${#System#PropertyName} – 对于系统属性，可在帮助 → 系统属性中找到

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

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

相同的结构

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

SoapUI – 财产转移

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

添加物业转让

步骤 1 – 选择 TestCase 或 TestStep，右键单击 → 添加步骤 → 属性转移。

添加属性

步骤 2 – 输入 TestStep 名称并单击确定。

利率转移

第 3 步– 添加 RateTransfer 步骤并打开一个新向导。

新向导

步骤 4 – 单击属性转移窗口左上角的添加新的属性转移图标 +。系统将提示输入传输名称。输入速率并单击确定。

速度

转让财产

创建传输后，源和目标窗格需要指定相关的 XPath 表达式来提取和替换属性值。在Source旁边的下拉框中，列出了各个级别的SoapUI项目，可以作为属性转移的来源。默认情况下，将显示最近的 TestStep。

在这种情况下，它是Request – INR to USD TestStep。属性旁边的下拉列表显示传输中使用的源属性，可以是请求、响应或服务端点。

转让财产

步骤 1 – 选择响应并转到路径语言。用户可以选择 XPath、Xquery 或 Jason 来定义属性。在这种情况下，选择 XPath。

路径语言

第 2 步– 要获取源 xml 的声明，请单击 ns 并指定 XPath。

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

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

目标– 属性

属性– ConversionRate（添加了一个新属性，它最初没有任何价值）。

目标物业

第 5 步– 一旦测试用例成功运行，属性“ConversionRate”将根据响应进行更新。

以下是最初的截图。

兑换率

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

成功运行

同样，Target 可能是下一个 Request XML。如果Target是SOAP请求，我们需要提供XPath来标识target属性。

SoapUI – 日志窗格

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

交易属性

SoapUI 日志

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

用户界面日志

HTTP 日志

HTTP 日志显示所有 HTTP 数据包传输。‘RAW’ 中的所有信息都显示在 HTTP 日志中。

Http 数据包传输

错误日志

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

内存日志

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

内存日志

SoapUI – 断言

断言可以解释为检查点或验证点。一旦请求被发送到 Web 服务器，就会收到响应。需要验证包含数据的响应是否符合预期。为了验证响应，SoapUI 具有断言功能。

注意事项

  • 断言用于验证 TestStep 在执行期间收到的消息。

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

  • 可以向 TestStep 添加任意数量的断言，每个断言验证响应消息的某些不同方面和内容。

  • 在 TestStep 执行后，它的所有断言都应用于接收到的响应，如果其中任何一个失败，则 TestStep 在 TestCase 视图中被标记为失败。

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

执行日志

断言类型

SoapUI 支持广泛的断言作为响应。

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

Assertion 描述
Property Content
Contains 检查指定字符串是否存在。它还支持正则表达式。
Not Contains 检查指定字符串是否不存在。它还支持正则表达式。
XPath Match 使用 XPath 表达式选择目标节点及其值。将 XPath 表达式的结果与预期值进行比较。
XQuery Match 使用 Xquery 表达式从目标属性中选择内容。将 XQuery 表达式的结果与预期值进行比较。
Compliance, Status, Standards
HTTP DOwnload All Resource 下载作为 HTML 文档（图像、脚本等）引用的所有资源，并验证它们都可用。适用于任何包含 HTML 的属性。
Invalid HTTP Status Codes 检查目标 TestStep 是否接收到状态代码不在定义代码列表中的 HTTP 结果。适用于任何接收 HTTP 消息的 TestStep。
Not SOAP Fault 验证最后收到的消息不是 SOAP 错误。适用于 SOAP 测试步骤。
Schema Compliance 验证最后收到的消息是否符合关联的 WSDL 或 WADL 模式定义。适用于 SOAP 和 REST 测试步骤。模式定义 URL 支持属性扩展（例如 ${#System#my.wsdl.endpoint}/services/PortType?wsdl）。
SOAP Fault 验证最后收到的消息是否为 SOAP 故障。适用于 SOAP TestSteps SOAP 请求 – 验证最后收到的请求是有效的 SOAP 请求。仅适用于 MockResponse 测试步骤。
SOAP Response 验证最后收到的响应是否是有效的 SOAP 响应。仅适用于 SOAP 测试请求步骤。
Valid HTTP Status Codes 检查目标 TestStep 是否收到了 HTTP 结果，在定义的代码列表中带有状态代码。适用于任何接收 HTTP 消息的 TestStep。
WS-Addressing Request 验证最后收到的请求是否包含有效的 WS-Addressing 标头。仅适用于 MockResponse TestSteps。
WS-Addressing Response 验证最后收到的响应是否包含有效的 WS-Addressing Headers。仅适用于 SOAP 测试请求步骤。
WS-Security Status 验证最后收到的消息是否包含有效的 WS-Security 标头。适用于 SOAP 测试步骤。
Script
Script Assertion 允许用户执行自定义脚本以执行用户定义的验证。仅适用于 TestSteps（即不适用于属性）
SLA
Response SLA 验证最后收到的响应的响应时间是否在定义的限制内。适用于发送请求和接收响应的脚本测试步骤和测试步骤。
JMS
JMS Status 验证目标 TestStep 的 JMS 请求是否成功执行。适用于使用 JMS 端点请求 TestSteps。
JMS Timeout 验证目标 TestStep 的 JMS 语句花费的时间没有超过指定的持续时间。适用于使用 JMS 端点请求 TestSteps。
Security
Sensitive Information Exposure 验证响应消息是否未公开有关目标系统的敏感信息。我们可以将此断言用于 REST、SOAP 和 HTTP TestSteps。
JDBC
JDBC Status 验证目标 TestStep 的 JDBC 请求是否成功执行。仅适用于 JDBC TestSteps。
JDBC Timeout 验证目标 TestStep 的 JDBC 语句花费的时间没有超过指定的持续时间。仅适用于 JDBC TestSteps。

SoapUI – 故障排除

在 SoapUI 中，用户面临许多通用的常见问题，只要稍加警惕就可以解决这些问题。其中一些最常见的问题如下 –

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

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

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

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

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

要求

范围

回复

故障代码

问题– 使用 XPath 或 XQuery 时当前响应不匹配。

解决方案–

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

不匹配响应

SoapUI – 性能测试

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

这意味着它不必是系统在高负载下的表现，也可以是它在基本负载或预期负载下的表现。它甚至不必在诸如 SoapUI 之类的 TestWare 中进行结构化、自动化或创建；只需非常快速地一遍又一遍地刷新 Web 浏览器也是一种负载测试。

性能测试的类型

以下是性能测试的类型 –

  • 基线测试– 检查系统在预期或正常负载下的执行情况，并创建可以比较其他类型测试的基线。

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

  • 浸泡测试–测试的目标是确保在更长的时间内不会出现不需要的行为。

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

Web 服务的关键方面

Web Service 性能的独特特征有两个方面突出。

第一方面

在服务器端，正在进行 XML/JSON 处理，包括 XML/JSON 解析和序列化。通常首先失败的是有效载荷的处理。失败的原因可能是多方面的；它可能是平台、应用服务器的弱点，也可能是不必要的复杂 WSDL 形式的实现问题。这也可能意味着代码正在向响应缓慢的数据库发出请求。

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

第二方面

另一个经常遇到的因素是安全性。HTTPS 背后的安全站点的性能要低得多，在 Web 服务测试中，我们可以在 HTTP 安全层上增加一层 WSSecurity，从而进一步降低性能。

测试方面– 安全意味着问题，需要专注于对安全请求进行测试。如果整个 Web 服务是安全的，则意味着负载测试更为重要，尤其是在使用 WS-Security 和令牌处理的情况下。

SoapUI – 负载测试

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

注意事项

  • SoapUI 中的负载测试非常独特；一个功能测试用例，允许快速创建和修改性能测试。

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

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

创建负载测试

步骤 1 – 右键单击​​功能测试用例并选择新建负载测试。

新负载测试

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

对话向导

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

开负载测试

执行负载测试

创建新的负载测试时，它使用简单负载策略预先配置为使用 5 个线程运行 60 秒（右上）。

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

负载配置

用户将在中间看到统计表，从收集数据开始，60 秒后应该有一个完成的 LoadTest。

统计表

添加断言

步骤 1 – 在 LoadTest 编辑器中，选择编辑器底部的 LoadTest Assertion 选项卡。

负载测试断言

步骤 2 – 单击 LoadTest Assertion 菜单栏中的 Add Assertion 按钮以添加断言。

断言按钮

步骤 3 – 添加断言对话框将打开。选择步长最大值。Select Maximum 设置允许响应花费的最大时间（以毫秒为单位），如果时间超过我们设置的时间，则测试将失败。单击确定。

最大误差

Step 4 – TestStep Max Assertion 窗口将打开。如以下屏幕截图所示，我们允许最大响应为一秒，即 1000 毫秒。我们不要修改任何东西。单击确定。

最大步数

现在将成功添加 Step Maximum 断言。

增加的最大值

步骤 5 – 现在再次运行测试。如果响应时间过长，您应该会看到 err 列中的数字加起来很快。

错误列

SoapUI – RESTful Web 服务

Web 服务是用于在应用程序或系统之间交换数据的开放协议和标准的集合。以各种编程语言编写并在各种平台上运行的软件应用程序可以使用 Web 服务以类似于单个计算机上的进程间通信的方式通过计算机网络（例如 Internet）交换数据。这种互操作性（例如，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 请求的 TestStep 管理数据库操作。

步骤 1 – 右键单击​​ TestStep 并选择添加步骤 → JDBC 请求。

JDBC 请求

步骤 2 – 输入步骤名称并单击确定。

新步骤

添加了 JDBC 步骤。双击 step，将打开 JDBC 向导。

JDBC 向导

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

对于 MySQL，数据库驱动程序可以是com.mysql.jdbc.Driver。同样，对于其他数据库，也有预定义的驱动程序，可以通过数据库的文档部分找到。

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

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

这里，属性是用户名和密码以及连接数据库所需的其他参数。

例如，

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

步骤 4 – 单击测试连接。连接成功时，将显示 SUCCESS，否则提供失败的详细信息。

测试连接

SoapUI – JDBC 属性

JDBC 有自己的 Add 属性部分，可用作 SQL 查询中的变量。

让我们看看它的行为 –

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

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

为了克服这种情况，JDBC 支持添加属性，其中可以定义一个属性 Code，它会使用 Property Transfer Step 不断变化。

SQL Query 将基于 Property Code 的当前值运行，SQL Query 将参数化 CurrencyCode =:Code。

单击添加属性 +，名称为代码并提供值或保留为空白以使用属性转移步骤来提供它。

添加属性

SoapUI – JDBC 断言

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

通过单击JDBC Request TestStep 顶部菜单中的Add an assertion图标，用户可以了解TestStep 支持哪些断言。

除了通用断言之外，还有两个 JDBC 请求 TestStep 特定的断言 –

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

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

JDBC 状态

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

属性查询

觉得文章有用？

点个广告表达一下你的爱意吧 ！😁