转载

在 RFT 中集成 SoapUI 进行 REST 服务测试

SoapUI 测试工具介绍

SoapUI 是一个免费开源的跨平台功能测试解决方案。它允许用户使用友好的界面，快速地创建和执行自动化功能、回归、压力测试，尤其适合对于各种以 API 形式表现的服务的测试。SoapUI 支持所有的标准协议和技术，从基于 SOAP 和 REST 的 Web 服务到 JMS 企业消息、数据库、Internet 应用，并提供完整的测试方案。

回页首

集成 SoapUI 到 Rational Functional Tester

通过插件进行安装集成

使用 Rational Functional Tester(RFT）进行基于 Web 服务的测试，我们通常需要编写庞大的代码，并对代码进行维护。现在我们可以通过插件的形式把 SOAPUI 集成到 RFT 中，这样可以大大提高我们测试的速度，并减少代码维护成本。

首先启动 RFT，通过菜单 HELP->Software Updates...打开软件更新管理器,选择增加站点按钮，如图 1 所示：

图 1. 增加 Site

输入 URL：http://www.soapui.org/eclipse/update

然后点击确定按钮。可以看到 SOAPUI 的可安装插件。如图 2 所示：

图 2. 更新插件对话框

点击安装按钮并按照向导进行安装。安装完毕之后，我们可以通过切换视图到 SOAPUI 的使用界面，如图 3 所示。

图 3. SoapUI 使用界面

配置介绍

通过 RFT 的菜单栏 Windows->Preferences->soapUI 打开 SOAPUI 的首选项设置页面，如图 4 所示。通过首选项来设置 HTTP、SLL、proxy，安全属性以及其他全局变量。也可以设置测试用例编辑器的属性和用户界面的默认行为。

图 4. 首选项配置

回页首

在 RFT 中使用 SoapUI 进行测试

如何进行 REST/SOAP API 测试

测试用例的组织形式： 项目->测试套->测试用例->测试步骤

在 SoapUI 中，测试用例是按照项目的形式组织的。一个项目可以包括多个测试套，每个测试套包含多个测试用例。而每个测试用例由多个测试步骤组成。对于不同的应用场景，有不同的测试步骤相对应。每个测试步骤都是针对特定的网络资源（也就是特定的 API）进行测试。用户可以根据不同的输入参数来设置不同的测试步骤，包括各种正常值和边界值进行测试。

我们将以如何测试一个简单的 REST API 为例子，说明如何在 SoapUI 中进行测试。主要的内容包括项目资源的添加、测试用例的更新以及如何执行测试用例。

项目新建与资源添加

在 SoapUI 中，通过菜单选项 New soapUI Project 可以快速地新建一个项目。新建的项目是一个 XML 的形式保存的，所以可以很方便地在第三方工具中进行处理。

通过添加资源对话框，我们可以把需要测试的资源（某一个 API 或者方法）添加到项目中，同时在添加资源的过程中，可以指定使用该资源的方法名、HTTP 方式（GET、POST、PUT、DELETE、HEAD)和参数。

图 5. 添加资源

测试用例更新

测试用例都是基于某一个测试资源的。所以在添加资源到项目之后，我们可以基于某一个资源来添加测试用例。在项目中首先选中某个资源后，选择右键，我们就可以通过选择菜单 Add to TestCase 来添加测试用例了。在添加测试用例的过程中，我们可以设置该用例所使用的数据，一般为格式固定的 HTTP 数据，也包括一些安全信息。

图 6. 添加测试用例

我们可以根据实际需要来通过菜单来添加不同的测试步骤。我们经常会使用到的测试步骤包括属性步骤（Properties）、延迟步骤（Delay）、条件跳转步骤（Conditional Goto）。

在一个测试用例中会包含很多的测试步骤。在特定的情况下，我们需要从一个测试步骤跳转到另外一个测试步骤去执行，而不是按照正常的顺序去执行测试步骤，这时就需要条件跳转步骤。如果我们需要在执行下一个测试步骤之前等待前一个步骤的执行结果，那我们就需要延迟步骤来处理。或者我们需要在两个测试步骤之间来传递共享某些信息，那这时就需要属性步骤了。

添加不同测试步骤的菜单如图 7 所示：

图 7. 添加测试步骤

例如我们需要一个延迟 5 秒执行下一个步骤，我们可以通过选择延迟（Delay）步骤来实现。首先选择延迟（Delay）步骤，然后设置该测试步骤的名称和延长时间，单位以秒计算。具体设置如图 8 所示。

图 8. 延迟步骤设置

通过以上步骤，我们完成了一个简单 API 的测试准备工作，包括项目新建、测试资源添加和测试用例的更新。整体的项目结构如图 8 所示：

图 9. 项目结构

执行测试和结果检查

在 SoapUI 中执行测试用例可以从三个层次进行。我们可以只执行单个的测试步骤，也可以执行单个的测试用例，或者执行整个的项目，这样可以快速灵活地进行测试的组织。每种测试执行完成之后，测试结果都已固定的格式保存到了本地，我们可以直接在 SoapUI 中来打开结果查看。为了更方便阅读结果，也可以用第三方工具来配合。

一个简单只包含三个测试步骤的执行结果如图 10 所示。执行的三个步骤都通过，并且结果显示通过。

图 10. 执行结果

提示： 在 SoapUI 的插件版本中，并不提供命令行的执行用例方式，只提供图形界面的执行方式。这也是我们需要增强的部分。

“断言”在测试中的使用

在测试基于 Web 的服务中，一个难点就是如何判断测试步骤的执行的正确性。也就是我们在 SoapUI 中执行了一个测试步骤后，如何来判断对于这个特定资源的测试是否正确。这里我们介绍在 SoapUI 中“断言”的使用。

断言机制是为了检验执行测试步骤所获得的信息是否部分或者全部与期望的信息相匹配。一个测试步骤可以包含无数多个断言。每个断言检查返回信息的不同方面。在每个测试步骤执行完成之后，所有包含的断言都会被执行。如果其中的某个断言失败，那么这个测试步骤会被标记为失败。

在 SoapUI 中，为了更容易管理，对断言进行了分类。具体的断言列表如图 11 所示。

第一类：针对属性内容检查的断言

这类断言用于判断返回内容的正确性。有包含/排除断言，XPATH 断言和 XQUERY 断言。
第二类：针对规则、状态和标准的断言
这类断言用于判断 HTTP 状态或者返回信息中是否包含了正确的头部信息。（注：图 11 中的 Valid/Invalid HTTP Status Codes）
第三类：脚本断言

这类断言使用定制的脚本进行模糊验证。
第四类：响应时间断言

这类断言用于判断是否请求和响应在规定的时间内完成。
第五类：JMS 断言
这类断言用于判断 JMS 请求是否能正确执行或者 JMS 请求状态超时。（注：该插件版本不包含此类断言）
第六类：JDBC 断言
这类断言用于判断 JDBC 请求是否能正确执行或者 JDBC 请求状态超时。（注：该插件版本不包含此类断言）
第七类：安全断言
这类断言用于验证是否返回信息中暴露了敏感的安全相关的信息。（注：图 11 中的 Sensitive Information Exposure）

在添加完成每个测试步骤之后，选中一个测试步骤并打开，我们可以根据需要来使用不同的断言。如果我们需要判断结果中是否包含期望的字符串，我们可以使用包含/排除断言。如果我们希望判断每个 HTTP 请求的返回状态，我们可以使用有效/无效 HTTP 状态码断言。在下一章节，我们将详细讲解如何使用 XPath 作为断言来使用。

图 11. 断言列表

XPath“断言”的使用实例

XPath 是一门在 XML 文档中查找信息的语言。XPath 用于在 XML 文档中通过元素和属性进行导航。XPath 使用路径表达式来选取 XML 文档中的节点或节点集。节点是通过沿着路径 (path) 或者步 (steps) 来选取的。XPath 含有超过 100 个内建的函数。这些函数用于字符串值、数值、日期和时间比较、节点和 QName 处理、序列处理、逻辑值等等。

XPath 于 1999 年 11 月 16 日成为 W3C 标准。XPath 被设计为供 XSLT、XPointer 以及其他 XML 解析软件使用。

XPath 是 XSLT 标准中的主要元素。XQuery 和 XPointer 均构建于 XPath 表达式之上。XQuery 1.0 和 XPath 2.0 共享相同的数据模型，并支持相同的函数和运算符。

在 SoapUI 中所有的测试结果都以 XML 的形式被保存，这就为后续的检查提供了一个很好的基础，尤其是使用 XPATH 和 XQUERY 技术标准进行匹配检查。在 SoapUI 中，所有的几个都支持标准的 XPath/XQuery 查询技术。

XPath 断言通过应用一个特定的 XPath 表达式到一个特定的返回信息，从而验证结果节点是否与期望的一致。如果验证成功，该断言标记为通过，否则标记为失败。

我们以下面的 XML 文档作为一个 HTTP 请求的返回值例子：

<?xml version="1.0" encoding="ISO-8859-1"?>  <response>  <app version=”1.0.0”> <name>test app 1</price> </app>  <app version=”2.0.0”> <name>test app 2</price> </app>  </response>

如果我们希望验证第一个 APP 的版本是否等于 1.0.0,那么我们可以在这个测试步骤的断言中添加 XPath 断言，我们输入//response[1]/app[1]/@version 作为 XPath 表达式，输入数字 1.0.0 作为期望值，如图 12 所示。断言中所使用的语言可以按照 XPath 的标准来编写。具体细节请参阅网址 http://www.w3school.com.cn/xpath/xpath_syntax.asp

图 12. XPath 使用