|
![]() |
级别: 中级 刘 欣, 高级软件工程师, IBM 2009 年 12 月 31 日 REST 作为一种针对 Web 应用的全新架构风格,近年变得越来越流行。soapUI 是一个对 Web 服务进行测试的开源工具, 它可以让开发人员直观的测试基于 SOAP 的 Web 服务, 随着新版本的推出,soapUI 也增加了对 REST 的支持。本文主要介绍如何利用 soapUI 对 REST 服务进行测试 REST(Representational State Transfer)是 Roy Fielding 博士在 2000 年提出的一种新的软件架构风格,它以资源(resource)为核心,使用 HTTP、 URI、XML 以及 HTML 等现有流行协议和标准来完成对资源的操作及显示。 这些操作包括获取、创建、修改和删除资源,分别对应于 HTTP 协议的 GET、POST、PUT 和 DELETE 方法。REST 架构定义了以下设计准则:
REST 服务(RESTful Service)是一种基于 HTTP 和 REST 准则的轻量级 Web 服务。这类服务可以看作一系列资源(resource)的集合,服务的定义可以视为以下三个切面的组合 :
相比目前流行的 Web 服务实现方案 SOAP 和 XML-RPC, REST 服务更加简洁,它可以完全通过 HTTP 协议实现,还可以利用缓存 Cache 来提高响应速度, 其性能,效率和易用性等方面均优于 SOAP 协议。 本文主要介绍如何使用 soapUI 来测试此类 Web 服务。
由于 Web 服务是被程序调用的, 一般不会提供界面让最终用户或测试人员直接使用,在 soapUI 等工具出现之前,测试人员不得不自己编写程序来测试它, 这就要求测试人员花费很大的精力了解底层的接口,调用关系和详细的协议,导致他们不能把注意力集中到测试中。 soapUI 的出现极大的改变了这一局面。 作为一个开源的工具,soapUI 强大的功能、易用的界面,吸引了很多用户。用户可以在 soapUI 中通过简单的操作完成复杂的测试,不需要了解底层的细节, 极大的减轻了工作量。soapUI 支持多样的测试, 例如功能测试,性能测试,回归测试等。到目前为止 soapUI 的下载量已经超过了 100 万次,成为了事实的 Web 服务测试标准和领先的 Web 服务测试工具。 它不仅仅可以测试基于 SOAP 的 Web 服务,也可以测试 REST 风格的 Web 服务,后者也是本文介绍的重点。 soapUI 基于 Java 开发,支持多个平台,安装非常简单。读者可以到 soapUI 的 官方网站下载一个安装包 ( 本文使用的是 Window 版本 3.0.1),直接安装即可。在该安装包中,包括了一个 soapUI 所需要的 JRE1.6 版本。安装完毕以后,读者需要设置 JAVA_HOME 变量指向到相应的 JRE 目录,同时修改 PATH 变量,将 JRE1.6 的 bin 目录添加进去。
为了避免空洞的讲解,同时为了更好的展示 soapUI 对 REST 服务的测试功能,本文假想了一个在线书店 (http://www.example.com) 的例子。该在线书店对外提供了一些 REST 服务让第三方的应用程序调用。 为了让读者把注意力集中在使用 soapUI 进行测试上,我们对这些 REST 服务进行了必要的简化,仅仅只包含下面 3 种功能:书籍列表,书籍详情和添加评论。这 3 个 REST 服务覆盖了层次状的 REST 资源、基本的 HTTP 操作和多种展现形式。
清单 1. 书籍列表 application/json
清单 2. 书籍列表 text/xml
清单 3. 书籍详情 application/json
在创建测试用例之前,我们先来看一看在 soapUI 中的基本概念,soapUI 把 REST 服务、资源及其操作组织为一个层次结构。如 图 1所示,主要包括如下层次:
注: 读者可以在 下载区的 bookstore-soapui-project.zip 找到完整的例子,下文中主要以该例子为基础进行讲解。读者解压 zip 文件以后,能得到一个 xml 文件,可以通过 soapUI 的 File->import project 把项目导入到自己的工作区中。 图 1. soapUI 中的层次结构 ![]() 对于测试用例来讲,同样是一个层次结构:
soapUI 实际上是一个平台,它支持强大的编程能力,开发或者测试人员可以利用 groovy 脚本来访问 soapUI 中的对象,在运行时修改 REST request/response, 这就提供了极大的灵活性。 图 2. TestCase 定义 ![]() 有了上面的基本概念以后,在 soapUI 中创建测试用例就比较简单了, 用户几乎可以根据自己的直觉来一步一步的完成一个测试。图 3展示的就是一个建立书籍列表 REST 服务的步骤: 1. 新建一个名为 BookStoreTest 的项目 图 3. 创建一个 REST 服务 ![]() 有了 REST 服务,就可以建立 TestCase,主要有两种方式:
一个完成的 TestCase 如 图 4所示,用户可以在其中加入 Assertion 对运行结果进行验证,这也是自动化测试所必须的。 图 4. REST TestCase ![]() soapUI 支持使用自定义变量(Property)在 Project 中存储和共享数据。Property 是一个命名的字符串可以被 Groovy Script,Property Transfer 或者 Property-Expansion 引用, 目前所有的变量均被处理为字符串。soapUI 允许在项目的各个层次中定义变量,常用的层次包括:Project,TestSuite,TestCase,Global 等。 1. 使用 Property 编辑器定义变量。 图 5. 使用 Property 编辑器定义项目变量 ![]() 2. 使用命令行指定变量。 清单 x. 使用命令行指定变量
其中,properties.txt 为指定的全局变量文件名字,可以通过添加如下代码到全局变量文件来设置 project/testsuite/testcase 等层次的变量: 清单 x. 使用命令行指定变量
<shortened-name-of-object> 为相应对象的名字。 3. 使用变量 清单 x. 使用命令行指定变量
其中,scope 可以为 #Project#,#TestSuite#,#TestCase# ,#Global#,#System#,#MockService#,#Env#,[TestStep name]#。 测试用例建好之后,需要向测试用例中添加 Assertions 以便验证结果的正确性。soapUI 支持 Response SLA, Script Assertion, Contains, XQuery Match, Schema Compliance, XPath Match 以及 Not Contains 等多种断言来对 response 进行判断来保证对 Web 服务高质量的测试。本文以 XPath Match 和 Script Assertion 为例来对在线书店服务返回的 XML 和 JSON 格式的 response 进行判断。 1. 使用 XPath Match 测试请求 GetBookListRequest_XML 返回的结果中,id 为 1234 的 book 的 price 为 29.0, response 参见 代码清单 2。 点击 TestCase 的添加 Assertions 按钮,如 图 4所示。 在弹出的 Select Assertion 窗口中选择 XPath Match 断言,点击 OK。配置 XPath 如下图所示: 图 6. 使用 XPATH 测试 XML 格式的书籍列表 ![]() 在 XPath Expression 面板中书写用于匹配 Response 的 XPath 表达式,Expected Result 面板中填写期望的值。soapUI 将使用 XPath Expression 面板中填写的 XPath 表达式与 Service 调用结果匹配, 将匹配结果与期望值比较,如果相同则测试通过,否则失败。 2. 使用 Script Assertion 测试请求 GetBookListRequest_JSON 返回的结果,response 参见 代码清单 1。 Assertion 添加过程与 XPath Match 类似,在 Select Assertion 窗口中选择 Script Assertion,并在之后弹出的 Script Assertion 窗口中书写如下代码: 清单 5. 使用 Script Assertion 测试 JSON 格式的书籍列表
3. 使用 Property 测试请求 GetBookRequest_JSON 返回的结果, response 参见 代码清单 3。 在 Script Assertion 窗口中写入如下代码: 清单 6. 使用 Property 测试 JSON 格式的书籍详情
上述使用 Groovy Script 对 Service 调用结果进行验证,可用的 soapUI 对象包括 :messageExchange, context 以及 log。
依照上述步骤定义好 TestCase 并添加适当的断言之后,就可以对在线书店 REST 服务进行测试。双击 BookStoreSerive_TestSuite, 点击 Run 按钮来运行所有的 TestCase,结果如下图所示: 图 7. 运行测试用例 ![]()
性能测试在 soapUI 中称为 Load Test, 针对一个 soapUI 的 TestCase, 可以建立一个或多个 LoadTest, 这些 LoadTest 会自动的 把 TestCase 中的所有步骤都添加到其中, 在运行的时候,soapUI 会自动的使用多个线程来运行这些 TestStep,同时也会监控 它们的运行时间, 例如最短时间,最长时间,平均时间等等。这样用户能够很直观的看到 REST 服务的响应时间,从而对性能进行调优。 建立 LoadTest 非常简单,只需要在“Load Tests”上点击右键, 选择"New LoadTest", 然后输入名称即可,下图是一个针对 GetBookList 的 性能测试, 可以看到有两个 TestStep : "GetBookList_xml" 和"GetBookList_json" , 100 个线程并发执行, 时间限制是 60 秒。 最后的结果是,最短时间 4 毫秒,最长时间 1204 毫秒,平均时间 20.54 毫秒。 图 8. 性能测试 ![]() 性能测试还支持断言,用户可以对一个 TestStep 或 TestCase 设置运行时间要求,例如平均时间大于 2 秒就认为失败,点击 图 8 中中的 “LoadTest Assertions”就可以设置。 当然根据需要,用户也可以编写脚本来做一些准备工作,或者清除工作。 参见 图 8 中的"Setup Script"和“TearDown Script”。 测试可以有效的保证代码的质量,但是仅仅手工的、在本机上运行的 REST 服务测试时远远不够的。实际上把测试作为软件构建的一部分,加入到持续集成中去是一个常见的敏捷开发实践,通过频繁的,自动化的测试, 可以更有效的发现缺陷,保证代码质量。 IBM Rational BuildForge 是一个管理软件构建和发布的平台 , 它提供了一个框架来自动化整个构建流程,不仅仅自动化单独的任务,可以集成多种用户现有的脚本和工具, 最大限度的保护用户投资。作为一个框架,BuildForge 几乎可以调用操作系统上的任何脚本。本文重点不在介绍 BuildForge, 假定读者对 BuildForge 已经比较熟悉, 不熟悉的读者可以查看参考资料中的相关文章。 对于 soapUI 来说,最简单的一种集成方式就是提供命令行脚本让 BuildForge 调用。在上文中 我们已经展示了通过 soapUI 的 GUI 运行 TestCase 的功能,那么 soapUI 可不可以通过命令行完成类似的功能呢? 答案是肯定的。 soapUI 提供了一个命令行工具 testrunner.bat 来运行一个项目中的 TestSuite, 可以在 <soap_ui_home>/bin 下找到它, 它的使用非常简单,只需要设置下面的几个常用参数即可:
下面这行命令就是运行 bookstore.xml 这个 soapUI 项目中的 BookstoreTestSuite, 把结果输出到 c:/temp/reports 中。 有了 testrunner,把 soapUI 的测试集成到 BuildForge 中就很简单了,只需要在 BuildForge 的项目中添加一个步骤,参见下图: 图 9. BuildForge 中使用 testrunner ![]()
从上文可以看出,soapUI 是一款强大的 Web 服务测试工具 , 它提供了便利的 GUI 界面帮助用户对 REST 服务进行快速的测试,使用简单,学习成本很低。 它也提供了可编程能力例如变量,Groovy 脚本等, 以便让用户应对一些复杂的情况。 总而言之,有效的实际项目中使用 soapUI,可以极大的减轻工作量,提供工作效率。当然作为开源的工具, soapUI 仍然在不断的发展完善过程中,本文所能介绍的也只是它的部分功能, 感兴趣的读者可以到 soapUI 网站上获取更多资料。
|