- SoapUI 教程
- SoapUI - 主页
- 肥皂基础知识
- SOAP - 简介
- SOAP - 消息
- SOAP - 什么是 REST?
- SoapUI 基础知识
- SoapUI - 简介
- SoapUI - 功能
- SoapUI - NG Pro
- SoapUI - 安装和配置
- SoapUI-WSDL
- SoapUI - 项目
- SoapUI - 测试套件
- SoapUI - 测试用例
- SoapUI - 测试步骤
- SoapUI - 请求和响应
- SoapUI - 属性
- SoapUI - 财产转让
- SoapUI - 日志窗格
- SoapUI - 断言
- SoapUI - 故障排除
- SoapUI - 性能测试
- SoapUI - 负载测试
- SoapUI - RESTful Web 服务
- SoapUI - JDBC 连接
- SoapUI - JDBC 属性
- SoapUI - JDBC 断言
- SoapUI 有用资源
- SoapUI - 快速指南
- SoapUI - 有用的资源
- SoapUI - 讨论
SoapUI - 快速指南
SOAP - 简介
SOAP 是简单对象访问协议的缩写。它由万维网联盟 (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 数据。它是一个强制性要素。
故障- 可选的故障元素,提供有关处理消息时发生的错误的信息。
所有这些元素都在 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 是表述性状态传输的缩写。它可以被定义为一种设计软件的架构风格。REST 不是规范或 W3C 标准。因此,使用 RESTful 服务更容易。它不需要任何中间件规范框架。
REST - 重要功能
以下是 REST 的一些重要功能。
它依赖于无状态、客户端-服务器、可缓存的通信协议——几乎在所有情况下都使用 HTTP。
它是 WebService 和 RPC(远程过程调用)(如 SOAP-WSDL)的轻量级替代品。
它代表唯一 ID 或 URI 中的所有内容。
它使用标准 HTTP 方法,例如 GET、POST、PUT、DELETE。
它将来源链接在一起。
REST 资源可以有多种表示形式。
任何命名信息都被视为资源。例如:图像、人、文档,都可以被视为资源的示例,并表示为唯一的 ID 或 URI。
万维网本身基于 HTTP,可以被视为基于 REST 的架构。
REST 服务独立于平台和语言。由于它基于 HTTP 标准,因此可以在存在防火墙的情况下轻松工作。与 WebServices 一样,REST 不提供任何内置安全性、会话管理、QoS 保证,但可以通过构建在 HTTP 之上来添加这些内容。对于加密,可以在 HTTPS 之上使用 REST。
SoapUI - 简介
SoapUI 是一个可用于功能和非功能测试的工具。它不仅限于 Web 服务,尽管它是 Web 服务测试中使用的事实上的工具。
SoapUI - 重要功能
以下是 SoapUI 的一些重要功能。
它能够扮演客户端和服务的角色。
它使用户能够使用单一环境快速高效地创建功能和非功能测试。
它根据 GNU 租赁通用公共许可证 (LGPL) 的条款获得许可。
纯粹使用JAVA平台实现。
它支持 Windows、Mac、多种 Linux 方言。
它允许测试人员在不同的 Web API 上执行自动化功能、回归、合规性和负载测试。
它支持所有标准协议和技术来测试各种API。
SoapUI 可用于测试完整的 RESTful API 和 SOAP Web Service 测试。它支持功能测试、性能测试、互操作性测试、回归测试、负载测试等等。
它用户友好,并且很容易将功能测试转换为非功能测试,例如负载、压力测试。
SoapUI - 功能
SoapUI 丰富于以下五个方面 -
- 功能测试
- 安全测试
- 负载测试
- 协议和技术
- 与其他工具集成
让我们详细了解其中的每一项功能。
功能测试
SoapUI 允许测试人员在 SoapUI 中编写功能 API 测试。
SoapUI 支持拖放功能,可加速脚本开发。
SoapUI 支持测试调试并允许测试人员开发数据驱动测试。
SoapUI 支持多种环境,可以轻松在 QA、Dev 和 Prod 环境之间切换。
SoapUI 允许高级脚本编写(测试人员可以根据场景开发自定义代码)。
安全测试
SoapUI 执行一套完整的漏洞扫描。
SoapUI 可防止 SQL 注入以保护数据库。
SoapUI 扫描因文档尺寸过大而导致的堆栈溢出。
SoapUI 扫描跨站点脚本,当服务参数在消息中公开时就会发生这种情况。
SoapUI 执行模糊扫描和边界扫描以避免服务的不稳定Behave。
负载测试
SoapUI 将负载测试分布在 n 个 LoadUI 代理上。
SoapUI 可以轻松模拟大容量和真实世界的负载测试。
SoapUI 允许高级自定义报告来捕获性能参数。
SoapUI 允许端到端系统性能监控。
协议与技术
SoapUI 支持多种协议 -
- SOAP——简单对象访问协议
- WSDL – Web 服务定义语言
- REST——代表性状态转移
- HTTP——超文本传输协议
- HTTPS – 安全的超文本传输协议
- AMF——动作消息格式
- JDBC——Java 数据库连接
- JMS——Java消息传递服务
与其他工具集成
- Apache Maven 项目
- 哈德森
- 联合单元
- Apache – Ant 等等......
SoapUI - NG Pro
SoapUI 是一款开源免费版本工具,具有基本的测试功能,而 SoapUI NG Pro 是一款商业化工具,具有报告、数据驱动功能等高级功能。
比较
下表对 SoapUI 和 SoapUI NG Pro 的各种功能进行了比较和对比。
特征 | 肥皂用户界面 | SoapUI NG 专业版 |
---|---|---|
支持的技术 | ||
肥皂 | 是的 | 是的 |
WSDL/WADL | 是的 | 是的 |
休息 | 是的 | 是的 |
联合管理系统 | 是的 | 是的 |
AMF | 是的 | 是的 |
数据库连接 | 是的 | 是的 |
HTTP协议 | 是的 | 是的 |
一般特征 | ||
独立应用程序 | 是的 | 是的 |
多环境支持 | 不 | 是的 |
浮动许可证 | 不 | 是的 |
WSDL 覆盖范围 | 不 | 是的 |
请求/响应覆盖范围 | 不 | 是的 |
消息断言 | 是的 | 是的 |
测试重构 | 不 | 是的 |
运行多个测试 | 是的 | 是的 |
数据源驱动测试 | 不 | 是的 |
脚本库 | 不 | 是的 |
单位汇报 | 不 | 是的 |
手动测试步骤 | 是的 | 是的 |
报告 | ||
联合报告 | 不 | 是的 |
报告数据导出 | 不 | 是的 |
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。
步骤 2 - 单击“获取”下载 SoapUI 开源。它将开始在系统中下载 112MB 的 .exe 文件。等待下载过程完成。
安装过程
步骤 1 - 下载后,以“以管理员身份运行”运行 .exe 文件。
Windows 将开始设置过程,如以下屏幕截图所示。
步骤 2 - 设置完成后,流程窗口将显示以下屏幕,单击下一步。
步骤 3 - 接受许可协议并单击下一步。
步骤 4 - 选择安装目录或将其保留为系统选择的默认路径。点击下一步。
步骤 5 - 选择您要安装的组件。点击下一步。
步骤 6 - 接受 HermesJMS 许可协议,然后单击下一步。
步骤 7 - 选择保存教程的目标目录,然后单击下一步。
步骤 8 - 选择开始菜单文件夹位置,或者保留默认位置不变,然后单击“下一步”。
步骤 9 - 启用“创建桌面图标”复选框,然后单击“下一步”。
现在,安装开始。需要几分钟才能完成。
步骤 10 - 安装完成后,在以下向导中单击“完成”。
单击 Finish 后,SoapUI 将启动。
- 菜单栏
- 工具栏
- 项目导航栏
- 工作区属性
- 日志面板
配置流程
第一步是创建一个可以包含多个项目的工作区。
步骤 1 - 转到文件 → 新工作区。
步骤 2 - 添加工作区名称并单击“确定”。
步骤 3 - 现在,选择工作区 xml 的保存路径。
步骤 4 - 选择路径并单击“保存”。
工作区已创建,如以下屏幕截图所示。还展示了工作空间属性。
SoapUI-WSDL
WSDL 代表 Web 服务描述语言。它是描述 Web 服务的标准格式。WSDL 由 Microsoft 和 IBM 联合开发。WSDL 发音为“wiz-dull”,拼写为“WSDL”。
WSDL ── 简史
WSDL 1.1 由 Ariba、IBM 和 Microsoft 于 2001 年 3 月作为 W3C 注释提交,用于描述 XML 协议上的 W3C 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
格式和元素
货币转换器 WSDL 将如下所示 -
WSDL ─ 端口类型
<portType> 元素组合多个消息元素以形成完整的单向或往返操作。例如,<portType> 可以将一个请求和一个响应消息组合成一个请求/响应操作。这在 SOAP 服务中最常用。一个 portType 可以定义多个操作。
例子
- portType 元素定义单个操作,称为 ConversionRate。
- 该操作由单个输入消息 ConversionRateHttpPostIn 组成。
- Output消息的操作是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 指定多个绑定。
服务
<service>元素定义 Web 服务支持的端口。对于每一种受支持的协议,都有一个端口元素。服务元素是端口的集合。
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 向导。
步骤 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 - 检查生成负载测试的复选框。这将为该 TestSuite 中创建的每个测试用例生成一个 LoadTest。
步骤 5 - 在新向导中输入 TestSuite 名称,然后单击“确定”。
创建的 TestSuite 将显示在导航面板中,如以下屏幕截图所示。
步骤 6 - 双击 TestSuite 名称,TestSuite 窗口将在右侧面板中打开。由于没有添加测试用例,因此它是空白的。
TestSuite 属性可以在导航面板的底部看到。可以在 TestSuite 级别添加新的自定义属性。
SoapUI - 测试用例
测试用例是测试步骤的集合,用于测试 Web 服务的某些特定方面。用户可以将 n 个测试用例添加到 TestSuite 中,甚至可以将它们模块化以相互调用以实现复杂的测试场景。
创建测试用例
步骤 1 - 在 TestSuite 中,用户可以添加多个测试用例。右键单击测试套件并选择“新建测试用例”。
步骤 2 - 输入测试用例的名称,然后单击“确定”。
到目前为止,创建的测试用例的测试步骤为零。为所有类型的可用测试添加了零测试步骤的 TestCase。添加测试步骤后,括号中的数字会自动更改。功能测试步骤应进入“测试步骤”,而性能测试步骤应进入“负载测试”,安全测试步骤应进入“安全测试”。
步骤 3 - 双击测试用例名称,右侧面板上将打开一个测试用例窗口。由于没有添加测试步骤,因此它是空白的,如下图所示。
SoapUI - 测试步骤
TestSteps 是 SoapUI 中功能测试的“构建块”。它们被添加到测试用例中并用于控制执行流程并验证要测试的 Web 服务的功能。
插入测试步骤
步骤 1 - 右键单击“测试步骤”。添加步骤并从列表中选择适当的测试步骤。例如,如果用户必须测试 REST WebService,则用户将选择 REST 测试请求。
步骤 2 - 通过选择“测试步骤”→“添加步骤”→“SOAP 请求”来添加测试步骤以验证导入的 SOAP 请求。
步骤 3 - 输入测试步骤的名称,然后在向导中单击“确定”。
单击“确定”后,将弹出一个对话框以选择要调用的操作。列出了所有操作,用户可以选择他们想要调用的操作。
将列出两个操作。除了使用的 SOAP 版本之外,这两种操作都是相同的。CurrencyConvertorSoap使用 SOAP 版本 1.1,而CurrencyConvertorSoap12使用 SOAP 版本 1.2。
步骤 4 - 选择第一个 –CurrencyConvertorSoap 并单击“确定”。
添加测试用例时,可以添加不同的标准断言。断言也称为 SOAP 请求/响应的检查点/验证点。
步骤 5 - 让我们创建一个带有默认选项的测试用例,这意味着创建一个没有以下任何验证点的测试步骤 -
- 在执行测试时验证响应消息是否为 SOAP。
- 验证响应架构是否有效。
- 验证 SOAP 响应是否包含 FAULT。
步骤 6 - 单击“确定”后,将弹出以下请求 XML 屏幕截图。
随着功能测试步骤的添加,测试步骤计数现在增加到 1。同样,在添加负载和安全测试步骤后,相应的数字会根据添加的步骤数自动增加。
SoapUI - 请求和响应
请求设置
在这里,我们将执行货币从 INR 到 USD 的转换。
- 货币来源 – INR
- 货币 – 美元
接下来,在问号位置输入这些输入,该输入将作为请求 XML 发送。将这些值放入相应的 XML 标签后,单击“提交请求”按钮以检查响应。
回复
提交请求后,Web 服务请求将由 Web 服务器处理并发回响应,如以下屏幕截图所示。
通过阅读响应,可以得出结论:1 单位 INR = 0.0147 单位 USD。
HTTP请求
SOAP 消息通过 HTTP 协议传输。要查看 HTTP 请求,请单击 SoapUI 请求窗口(左侧)中的 RAW。
请求被发布到网络服务器。因此,使用了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 代码用于由 Web 服务器发送响应,对于调试非常有用。
HTTP 代码 | 描述 |
---|---|
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 - 输入测试步骤名称并单击“确定”。
步骤 3 - 添加 RateTransfer 步骤,并将打开一个新向导。
步骤 4 - 单击属性转让窗口左上角的添加新属性转让图标 +。系统将提示您输入传输名称。输入费率并单击确定。
转让财产
创建传输后,源窗格和目标窗格需要指定相关的 XPath 表达式来提取和替换属性值。在 Source 旁边的下拉框中,列出了可用作属性传输源的各个级别的 SoapUI 项目。默认情况下,将显示最接近的测试步骤。
在本例中,它是请求 – 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来标识目标属性。
SoapUI - 日志窗格
日志窗格存储有关客户端和服务器之间事务的完整信息。用户将能够看到日志窗格的各个选项卡。我们将在本章中讨论使用 SoapUI 时最常用的日志窗格。
SoapUI 日志
SoapUI 日志显示来自 Web 服务器的响应信息。相同的信息存储在“bin”目录下 SOAP-UI 安装文件夹的soapui.log 文件中。
HTTP日志
HTTP日志显示所有HTTP数据包传输。“RAW”中的所有信息都显示在 HTTP 日志中。
错误日志
错误日志显示整个项目会话期间遇到的所有错误。SoapUI 安装位置的“bin”目录中的“soapui-errors.log”中提供了相同的信息。
内存日志
该选项卡监视内存消耗并以图表的形式显示,如下图所示。当执行内存密集型操作时,它确实很有帮助。
SoapUI - 断言
断言可以解释为检查点或验证点。一旦请求被发送到网络服务器,就会收到响应。需要验证包含是否符合预期数据的响应。为了验证响应,SoapUI 具有断言功能。
注意事项
断言用于验证 TestStep 在执行期间接收到的消息。
它将消息的一部分或整个消息与某个期望值进行比较。
可以将任意数量的断言添加到 TestStep,每个断言验证响应消息的某些不同方面和内容。
TestStep 执行后,其所有断言都会应用于收到的响应,如果其中任何断言失败,则 TestStep 在 TestCase 视图中被标记为失败。
测试执行日志中显示失败的条目。
断言类型
SoapUI 支持多种断言响应。
以下是 SoapUI 支持的断言列表。
断言 | 描述 |
---|---|
财产内容 | |
包含 | 检查指定字符串是否存在。它还支持正则表达式。 |
不包含 | 检查指定字符串是否不存在。它还支持正则表达式。 |
XPath 匹配 | 使用 XPath 表达式选择目标节点及其值。将 XPath 表达式的结果与预期值进行比较。 |
XQuery 匹配 | 使用 Xquery 表达式从目标属性中选择内容。将 XQuery 表达式的结果与预期值进行比较。 |
合规性、状态、标准 | |
HTTP下载所有资源 | 下载 HTML 文档中提到的所有资源(图像、脚本等)并验证它们是否全部可用。适用于任何包含 HTML 的属性。 |
无效的 HTTP 状态代码 | 检查目标 TestStep 是否收到状态代码不在已定义代码列表中的 HTTP 结果。适用于任何接收 HTTP 消息的 TestStep。 |
不是 SOAP 错误 | 验证最后收到的消息不是 SOAP 错误。适用于 SOAP 测试步骤。 |
架构合规性 | 验证最后收到的消息是否符合关联的 WSDL 或 WADL 架构定义。适用于 SOAP 和 REST 测试步骤。架构定义 URL 支持属性扩展(例如 ${#System#my.wsdl.endpoint}/services/PortType? wsdl)。 |
SOAP 错误 | 验证最后收到的消息是否为 SOAP 错误。适用于 SOAP TestSteps SOAP 请求 - 验证最后收到的请求是否是有效的 SOAP 请求。仅适用于 MockResponse 测试步骤。 |
SOAP 响应 | 验证最后收到的响应是否是有效的 SOAP 响应。仅适用于 SOAP TestRequest 步骤。 |
有效的 HTTP 状态代码 | 检查目标 TestStep 是否收到 HTTP 结果以及已定义代码列表中的状态代码。适用于任何接收 HTTP 消息的 TestStep。 |
WS-寻址请求 | 验证最后收到的请求是否包含有效的 WS-Addressing 标头。仅适用于 MockResponse TestSteps。 |
WS-寻址响应 | 验证最后收到的响应是否包含有效的 WS-Addressing 标头。仅适用于 SOAP TestRequest 步骤。 |
WS-安全状态 | 验证最后收到的消息是否包含有效的 WS-Security 标头。适用于 SOAP 测试步骤。 |
脚本 | |
脚本断言 | 允许用户执行自定义脚本来执行用户定义的验证。仅适用于测试步骤(即不适用于属性) |
SLA | |
响应SLA | 验证最后收到的响应的响应时间是否在定义的限制内。适用于发送请求和接收响应的脚本 TestSteps 和 TestSteps。 |
联合管理系统 | |
JMS 状态 | 验证目标 TestStep 的 JMS 请求是否成功执行。适用于使用 JMS 端点请求 TestSteps。 |
JMS 超时 | 验证目标 TestStep 的 JMS 语句所花费的时间不超过指定的持续时间。适用于使用 JMS 端点请求 TestSteps。 |
安全 | |
敏感信息暴露 | 验证响应消息是否未公开有关目标系统的敏感信息。我们可以将此断言用于 REST、SOAP 和 HTTP 测试步骤。 |
数据库连接 | |
JDBC 状态 | 验证目标 TestStep 的 JDBC 请求是否成功执行。仅适用于 JDBC TestSteps。 |
JDBC 超时 | 验证目标 TestStep 的 JDBC 语句所花费的时间不超过指定的持续时间。仅适用于 JDBC TestSteps。 |
SoapUI - 故障排除
在 SoapUI 中,用户面临许多一般性的常见问题,只需稍加警惕即可解决。其中一些最常见的问题如下 -
问题- 命名空间定义错误。使用正确的命名空间。命名空间应该是 Web 服务所在的 URL。
解决方案- 如果在开发脚本断言时抛出错误,请使用“log.info”打印变量的内容。
问题- 如果收到响应 XML 形式的故障代码,则可能是由于输入无效造成的。
解决方案- 验证请求 XML 的输入。
示例- 在货币转换器中,如果“FromCurrency”的输入是不存在的“123”,则输出将抛出错误代码“SOAP-Client”,这意味着问题出在从客户端。
要求
回复
问题- 使用 XPath 或 XQuery 时当前响应不匹配。
解决方案-
- 定义 XPath 或 XQuery 时使用正确的语法。
- 验证在声明命名空间时使用的是冒号而不是点。
- 确保 XPath 和 XQuery 正确。
SoapUI - 性能测试
性能测试是 Web 服务测试中最常见的重要检查点之一。性能测试被定义为人工创建或模拟负载并测量环境如何处理它。
这意味着不一定是系统在高负载下的执行方式,也可以是系统在基本负载或预期负载下的执行方式。它甚至不必在 TestWare(例如 SoapUI)中进行结构化、自动化或创建;简单地一遍又一遍地快速刷新网络浏览器也是一种负载测试。
性能测试的类型
以下是性能测试的类型 -
基线测试- 检查系统在预期或正常负载下的性能,并创建可以与其他类型的测试进行比较的基线。
负载测试- 包括增加负载并查看系统在较高负载下的Behave方式。在负载测试期间,用户可以监控响应时间、吞吐量、服务器状况等等。负载测试的目标不是破坏目标环境。
浸泡测试- 测试的目标是确保在较长时间内不会出现不需要的Behave。
可扩展性测试- 可扩展性测试非常类似于负载测试,但是它不是增加请求数量,而是增加发送请求的大小或复杂性。例如,发送大型请求、大型附件或深度嵌套的请求。
Web 服务的关键方面
Web Service 性能的独特特征有两个方面突出。
第一方面
在服务器端,正在进行 XML/JSON 处理,包括 XML/JSON 解析和序列化。通常首先失败的是有效负载的处理。失败的原因可能是多方面的;它可能是平台、应用程序服务器的弱点,也可能是不必要的复杂 WSDL 形式的实现问题。这也可能意味着代码正在向响应缓慢的数据库发出请求。
测试方面- 解析 XML/JSON 有效负载的复杂性意味着需要额外关注可扩展性测试。这也意味着应该仔细检查 WSDL。如果请求和响应很复杂或较大,或者包含大型附件,则应重点强调复杂性并查看其在负载下的Behave。
第二个方面
另一个经常遇到的因素是安全性。HTTPS 背后的安全站点的性能要低得多,在 Web 服务测试中,我们可以在 HTTP 安全层上添加一层 WSSecurity,从而进一步降低性能。
测试方面- 安全问题意味着需要专注于对安全请求进行测试。如果整个 Web 服务都是安全的,则意味着负载测试更加重要,特别是在使用 WS-Security 和令牌处理的情况下。
SoapUI - 负载测试
负载测试是性能测试的一种特定形式,用于评估系统在特定负载下的Behave。在 SoapUI 中,我们通常使用术语“负载测试”来表示所有类型的非功能测试,但是 SoapUI 支持所有类型的 Web 服务性能评估,例如负载、压力和耐力。
注意事项
负载测试在 SoapUI 中非常独特;功能测试用例,允许快速创建和修改性能测试。
主要区别在于 SoapUI 中的性能测试通常是根据现有的功能测试创建的。这允许快速创建高级性能测试。
可以在不同的负载场景下验证Web服务的性能。维护功能验证以确保它们不会在负载下崩溃,同时运行多个负载测试以了解它们如何相互影响等等。
创建负载测试
步骤 1 - 右键单击功能测试用例并选择新建负载测试。
步骤 2 - 输入负载测试的名称,然后在对话框向导中单击“确定”。
负载测试将打开并创建负载测试,如以下屏幕截图所示。
负载测试的执行
创建新的负载测试时,它被预先配置为使用简单负载策略使用 5 个线程运行 60 秒(右上角)。
根据要求修改这些值并运行。注意- 用户应该了解负载测试配置和概念。
用户将在中间看到统计表,从收集数据开始,60 秒后应该完成 LoadTest。
添加断言
步骤 1 - 在 LoadTest 编辑器中,选择编辑器底部的 LoadTest Assertion 选项卡。
步骤 2 - 单击 LoadTest 断言菜单栏中的添加断言按钮以添加断言。
步骤 3 - 将打开“添加断言”对话框。选择步长最大值。选择“最大”设置允许响应的最长时间(以毫秒为单位),如果时间超过我们设置的时间,测试将失败。单击“确定”。
步骤 4 - 将打开 TestStep Max Assertion 窗口。如下图所示,我们允许最大响应时间为一秒,即 1000 毫秒。我们不要修改任何东西。单击“确定”。
现在将成功添加最大步长断言。
步骤 5 - 现在再次运行测试。如果响应时间过长,您应该会看到错误列中的数字快速累加。
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 请求的 TestStep 来管理数据库操作。
步骤 1 - 右键单击 TestStep 并选择添加步骤 → JDBC 请求。
步骤 2 - 输入步骤名称并单击“确定”。
添加了 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 有自己的添加属性部分,可以用作 SQL 查询中的变量。
让我们看看它的Behave方式 -
假设,在 JDBC 步骤中需要执行的 SQL 查询是 Select * fromCurrency whereCurrencyCode = 'xxx'。
在这种情况下,CurrencyCode 可以根据请求输入进行更改。如果用户提供硬编码值,则 JDBC 步骤将不会针对请求中给定的货币执行。
为了克服这种情况,JDBC 支持添加属性,可以定义属性代码,并使用属性传输步骤不断更改。
SQL 查询将根据属性代码的当前值运行,并且 SQL 查询将参数化CurrencyCode =:Code。
单击“添加属性+”,将名称命名为“代码”,并给出值或保留空白以使用“属性转移”步骤来提供它。
SoapUI - JDBC 断言
JDBC 请求还可以利用 SOAP 请求 TestSteps 的大多数断言。在 SoapUI 中,大多数断言都独立于 TestSteps。因此,Contains 和 XPath Match 等断言可以与 JDBC Request TestStep 一起使用。
通过单击JDBC Request TestStep 顶部菜单中的“添加断言”图标,用户可以了解该 TestStep 支持哪些断言。
除了通用断言之外,还有两个 JDBC 请求 TestStep 特定断言 -
JDBC Timeout - 此断言可用于验证当前 SQL 查询是否在指定的查询超时属性值内执行。
JDBC Status - 为了检查 SQL 语句是否成功执行,我们可以使用 JDBC Status 断言。
要设置查询超时,请在屏幕左侧提供属性查询超时的相应值。请记住,它接受以毫秒 (ms) 为单位的值。