REST 服务介绍
REST（Representational State Transfer）是 Roy Fielding 博士在 2000 年提出的一种新的软件架构风格，它以资源（resource）为核心，使用 HTTP、 URI、XML 以及 HTML 等现有流行协议和标准来完成对资源的操作及显示。 这些操作包括获取、创建、修改和删除资源，分别对应于 HTTP 协议的 GET、POST、PUT 和 DELETE 方法。REST 架构定义了以下设计准则：
网络中的所有事物都被抽象为资源（resource）。
每个资源对应一个唯一的资源标识（resource identifier）。
通过通用的连接器接口（generic connector interface）对资源进行操作。
对资源的各种操作不会改变资源标识。
所有的操作都是无状态的（stateless）。
REST 服务（RESTful Service）是一种基于 HTTP 和 REST 准则的轻量级 Web 服务。这类服务可以看作一系列资源（resource）的集合，服务的定义可以视为以下三个切面的组合 :
访问 Web Service 的 URI，如：http://example.com/resources。
Web Service 所支持的数据 MIME 类型，如：JSON， XML， YAML 等。
Web Service 使用 HTTP 协议支持的操作，如 GET， POST， PUT， DELETE。
相比目前流行的 Web 服务实现方案 SOAP 和 XML-RPC， REST 服务更加简洁，它可以完全通过 HTTP 协议实现，还可以利用缓存 Cache 来提高响应速度， 其性能，效率和易用性等方面均优于 SOAP 协议。 本文主要介绍如何使用 soapUI 来测试此类 Web 服务。
soapUI 介绍
由于 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 目录添加进去。
REST 服务案例
为了避免空洞的讲解，同时为了更好的展示 soapUI 对 REST 服务的测试功能，本文假想了一个在线书店 (http://www.example.com) 的例子。该在线书店对外提供了一些 REST 服务让第三方的应用程序调用。 为了让读者把注意力集中在使用 soapUI 进行测试上，我们对这些 REST 服务进行了必要的简化，仅仅只包含下面 3 种功能：书籍列表，书籍详情和添加评论。这 3 个 REST 服务覆盖了层次状的 REST 资源、基本的 HTTP 操作和多种展现形式。
清单 1. 书籍列表 application/json
{"books":
[
{"book":
{
"id":
"1234"，
"name":
"book1"，
"price":
29
}}，
{"book":
{
"id":
"5678"，
"name":
"book2"，
"price":
18
}}
]}
清单 2. 书籍列表 text/xml
清单 3. 书籍详情 application/json
{
"id":
"1234"，
"name":
"book1"，
"description":
"this is book 1"，
"author":
"author1"，
"price":
29，
"comments":
[
{"comment":
{
"user":
"user1"，
"content":
"good book"
}}，
{"comment":
{
"user":
"user2"，
"content":
"not bad"
}}
]
}
在 soapUI 中建立测试用例
基本概念
在创建测试用例之前，我们先来看一看在 soapUI 中的基本概念，soapUI 把 REST 服务、资源及其操作组织为一个层次结构。如 图 1所示，主要包括如下层次：
项目定义：位于最上层 (BookStoreTest)，项目可以包含多个服务的定义。
REST 服务定义：服务其实是对多个 REST 资源的一个分组，在我们的例子中只有一个服务 BookStoreServie
REST 资源定义：具体描述该资源的名称，URI， 参数等属性
REST 方法定义：针对每个资源的方法 (GET，POST，PUT，DELETE 等 )，图 1 中的方法名就是 GetBookList
REST 操作请求定义：基于每个方法，可以有一个或多个请求操作，如 GetBookListRequest，这些请求操作才是真正被 soapUI 所调用执行的。每个请求可以设置非常丰富的信息，例如 Accept 类型，请求的 Header 信息，运行了该请求以后，就能以各种方式查看运行结果。但是这里还不能加入断言来验证结果 - 必须在建立测试用例以后才能使用。
注： 读者可以在 下载区的 bookstore-soapui-project.zip 找到完整的例子，下文中主要以该例子为基础进行讲解。读者解压 zip 文件以后，能得到一个 xml 文件，可以通过 soapUI 的 File->import project 把项目导入到自己的工作区中。
图 1. soapUI 中的层次结构
对于测试用例来讲，同样是一个层次结构：
TestSuite：类似于 Junit 中的测试套件，其中可以加入多个 TestCase
TestCase：可以包含多个 TestStep
TestStep：一个 TestCase 可以包含多个 TestStep，TestStep 有多种类型，它可以是上面提到一个 REST 操作请求，也可以是一个 Groovy 的脚本，还可以试一个设置属性的操作。 TestStep 甚至支持分支跳转操作：根据特定的条件，从一个 step 可以跳转到其他 step， 而不必顺序执行。
soapUI 实际上是一个平台，它支持强大的编程能力，开发或者测试人员可以利用 groovy 脚本来访问 soapUI 中的对象，在运行时修改 REST request/response， 这就提供了极大的灵活性。
图 2. TestCase 定义
创建测试用例
有了上面的基本概念以后，在 soapUI 中创建测试用例就比较简单了， 用户几乎可以根据自己的直觉来一步一步的完成一个测试。图 3展示的就是一个建立书籍列表 REST 服务的步骤：
1. 新建一个名为 BookStoreTest 的项目
2. 在项目上点击右键，选择"New Rest Service"，在对话框中输入 Service Name(BookStoreService) 和 Endpoint(http://localhost:9080)
3. 在"BookstoreService"上点击右键，选择“New Resource”， 在对话框中输入 Resource Name(BookList) 和 Resource Path (/books)，点击 OK
4. 在弹出的对话框中输入 Method Name: GetBookList，HTTP Method 选择默认的 GET， 点击 OK
有了 REST 服务，就可以建立 TestCase，主要有两种方式：
自动生成，步骤如下：
(1). 右键点击一个 REST 服务，例如本例中的"BookStoreService"， 选择"Generate TestSuite"
(2). 在弹出的对话框中，保持默认设置， 选择"OK"
(3). 输入名称 ， 例如"BookStoreService TestSuite"， 选择"OK"即可。
手工创建，步骤如下：
(1). 在项目"BooksStoreTest"上点击右键，选择“New TestSuite”， 在对话框中输入"BookStoreService TestSuite"
(2). 在 BookStoreService TestSuite 上点击右键， 选择"New TestCase"， 在对话框中输入"BookList TestCase"
(3). 然后在左边的导航栏中展开 BookList TestCase， 在“Test Steps”上点右键，选择 Add Step->Rest Test Request
(4). 在弹出的对话框中选择 GetBookListRequest_XML
一个完成的 TestCase 如 图 4所示，用户可以在其中加入 Assertion 对运行结果进行验证，这也是自动化测试所必须的。
图 4. REST TestCase
