超详细整理，Java接口自动化测试实战-rest-assured

1、关于rest-assured

rest-assured 是一个能够简化测试rest服务的Java DSL，像ruby或者python一样的动态语言去测试和验证http服务。

基于java并且兼容了groovy动态语言的特性，使我们像写脚本语言一样去测试http服务。

例如：你的http服务（ http://localhost:8080/lotto/{id}）返回一个如下json：

{
   "lotto":{
      "lottoId":5,
      "winning-numbers":[2,45,34,23,7,5,3],
      "winners":[
         {
            "winnerId":23,
            "numbers":[2,45,34,23,3,5]
         },
         {
            "winnerId":54,
            "numbers":[52,3,12,11,18,22]
         }
      ]
   }
}

很简单的使用rest-assured断言你的响应结果是否符合预期。

get("/lotto").then().body("lotto.lottoId", equalTo(5));

或者你想断言下 winnerId是不是 23 和 54:

get("/lotto").then().body("lotto.winners.winnerId", hasItems(23, 54));

如果看起来很简单，have a try？

2、rest-assured小试牛刀

在我们没有运行测试用例之前，我们需要把rest-assured的maven依赖先引入

<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>rest-assured</artifactId>
    <version>3.0.0</version>
    <scope>test</scope>
</dependency>

RestAssured这个类是整个测试框架的请求入口，类的内部定义了一系列静态方法，包括我们常用的POST, GET, PUT, DELETE, OPTIONS, PATCH and HEAD等请求类型，请求响应结果，能用于我们常用的验证和断言。

RestAssured.get方法请求http服务

Response response = RestAssured.get("http://localhost/greting?id=5");

请求响应结果response中定义了一系列的json转换方法，你可以很简单把你的结果转换成
json等字符串直接输出

response.asString();

或者对应实体bean转换为json对象或者xml。

//json
GreetingBean as = response.as(GreetingBean.class);
//xml
XmlPath xmlPath = response.xmlPath();

也可以把返回结果进行验证是不是你想要的结果

response.then().statusCode(200).body("name",equalTo("test"));

看到这里你可能认为rest-assured提供的方法的确很简单，但是我把httpclient或者okhttp封装一下，也可以达到这个效果，我是一个程序员，我就是喜欢重复造轮子，因为这样才可以提高我自己的编程水平，那么OK，你一定要造一个比它还好用的轮子。

对于上面的http测试请求还是可以在简化，能用小程序实现的，决不用大程序。

第一步：

import static io.restassured.RestAssured.given;

第二步：

get("http://localhost/greting?id=5")

我们就可以使用简单的get，post或者delete发送我们的请求，并且可以获得响应结果进行断言返回结果是否正确。

虽然我们在使用别人东西，但是我们也要知其然知其所以然，刨根问底。如果你足够仔细，打开源码一识真面目，其实你会发现rest-assured本身也没有什么神秘，他就是充分利用了java多态的特性，对接口进行了高度的继承和封装。

查看get或者post等一系列http请求方法的实现，你会发现所有的请求体Request，rest-assured本身都对他进行了重新定义，即RequestSpecification，这只是一个接口，它的实现类则是TestSpecificationImpl，这里面则是封装了标准的http请求(如下，截取了其中的一部分，来自于类io.restassured.internal.TestSpecificationImpl),它是使用groovy语言进行实现。

 /**
   * {@inheritDoc}
   */
  Response get(String path, Object... pathParams) {
    requestSpecification.get path, pathParams
  }

  /**
   * {@inheritDoc}
   */
  Response post(String path, Object... pathParams) {
    requestSpecification.post path, pathParams
  }

  /**
   * {@inheritDoc}
   */
  Response put(String path, Object... pathParams) {
    requestSpecification.put path, pathParams
  }

  /**
   * {@inheritDoc}
   */
  Response delete(String path, Object... pathParams) {
    requestSpecification.delete path, pathParams
  }

groovy是什么？Groovy是一种基于JVM（Java虚拟机）的敏捷开发语言，它结合了Python、Ruby和Smalltalk的许多强大的特性，Groovy 代码能够与 Java 代码很好地结合，也能用于扩展现有代码。

你可以再反过来看看返回结果response也是按照这种思路，里面也有一个实现类即ResponseSpecificationImpl。这里也就契合了为什么一开始我们为什么说rest-assured是基于java DSL（DSL是一种为了特定任务而设计的开发语言 ）框架。

3、rest-assured优势

足够简单，短，而且编写测试用例快（应该是程序员为啥找不到女朋友的原因吧）。

顺序控制结构（最简单的结构莫过于此，执行这条语句然后执行下一条语句的形式）?

符合契约编程思想（如果前置条件满足的情况下调用函数，那么函数的执行将确立后置条件）

同时，我也为大家准备了一份软件测试视频教程（含面试、接口、自动化、性能测试等），就在下方，需要的可以直接去观看，也可以直接点击文末小卡片免费领取资料文档

软件测试视频教程观看处：

4、rest-assured系统测试

耐心看了上面的内容，相信你对这个测试框架有了个整体的了解，但是在现实场景中根本不可能使用java的main函数直接调用RestAssured里面的静态函数，因为这样写出来的测试用例是不容易维护的，也是不可移植的。

因为这些测试用例今天你是简单在打包前跑了下测试用例，确定没有错误后，打成测试包，但是之后可能也对这个产品进行持续集成（CI　server或者jenkins等），又或者这个产品的用户量比较大我们需要在Jmeter或者loaderunner中，跑下脚本，测试性能。

这时我们要把rest-assured结合Junit(或者一些自己擅长的单元测试框架testNG等)进行使用。

下面简单介绍下几种常见的测试用例场景：

第一步，确保你已经引入Junit和rest-assured包。

并且在引入类的同时进行静态化,如下：

import static io.restassured.RestAssured.get;
import static io.restassured.RestAssured.given;
import static io.restassured.RestAssured.post;
import static org.hamcrest.Matchers.*;

@Before
public void setup() {
    RestAssured.baseURI = "http://localhost";
    RestAssured.port = 8080;
}

这里是使用Junit的注解，在运行测试用例之前的准备工作。这里我们配置了ip地址和端口。看到这里有的同学可能要问了我的请求是基于https单向请求，那么我们可以在setup函数中添加 ：

RestAssured.config.getSSLConfig().relaxedHTTPSValidation();

这个设置代表信任所有客户端，不用携带任何可信任证书，直接能够请求到服务端，如果这时你使用OKHttp或者httpURLConnection，你可能就要花时间自己实现绕过https认证了，可能你现在手头有一份可信任证书，想要模拟真是的浏览器环境,你可以这样设置：

RestAssured.config.getSSLConfig().trustStore("test.truststore","123456");

我曾经自己原生的java语言以及httpclient实现过基于证书的双向认证过程具体请查看源码，已经精简到不能在精简，还写了个大概十行左右的代码，如果不参考之前写的，我可能还要翻开API看看到底是怎么调用的。

但是rest-assured就跟我们做了很好的封装如下：

RestAssured.certificate("clq.truststore", "123456","clq.p12", "123456", CertificateAuthSettings.certAuthSettings().keyStoreType("PKCS12").trustStoreType("jks"));

因为代码的封装不够好，降低了我们的工作效率，很明显rest-assured提高了我们的工作效率，降低了我们在工作中可能出错的机率。

其实它这里面不仅做了单双向认证的封装，我们平时常见的用户名密码登录、oauth认证、代理请求等等。具体见DOC

第二步，开始我们的rest服务测试

get请求测试

@Test
public void greetingTest() {
    given().param("name", "clq")
            .then().statusCode(200)
            .body("id", equalTo(2),"content", containsString("Hello"))
    .when().get("/greeting");
}

这一大串的顺序控制结构代码的含义就是，给出参数name，当我发送get请求之后，那么你给我返回响应码200，并且id=2，content为hello。

如果你的这个rest服务请求测试有一定的特殊性，那么你可以在这个测试用例中进行另外的声明。如下：

@Test
public void greetingTest() {
    try {
        RestAssured.requestSpecification = new RequestSpecBuilder().addCookie("cookie","123456").build();
        given().param("name", "clq")
                .then().statusCode(200)
                .body("id", equalTo(2),"content", containsString("Hello"))
        .when().get("/greeting");
    }finally {
        RestAssured.reset();
    }
    
}

使用完之后，记得在finally里面进行reset，因为有可能会影响其它的测试用例。同样的我们举一个基于json请求的post实例，（这个框架可不仅支持基于json格式body传参，也支持我们常用的form表单或者xml传参。）

@Test
public void postTest() {
    Map<String, Object> map = new HashMap<String, Object>();
    map.put("id", 123412);
    map.put("addr", "zz");
    map.put("age", Arrays.asList(12,27,23,41));
    given().contentType(ContentType.JSON)
            .body(JSON.toJSONString(map)).proxy(ProxySpecification.host("192.168.1.11").withPort(2010))
            .then().statusCode(200)
            .body("addr", equalTo("zz"), "id", equalTo(123412), "age[1]", is(27))
            .time(lessThan(1L),TimeUnit.SECONDS)
    .when().post("/welcome");

这个post请求，我在这里设置了特别多的场景，首先是requestBody里面的json传参，并且使用代理192.168.1.11:2010，当我发送post请求后，那么给我返回响应码200，body里面的结果符合预期（里面内置了hamcrest这个包，它的主要作用是response返回结果进行验证）。

这些场景也是比较常见的，比如说，我的后台要添加一个这样的功能，支持微信公众号服务的调用。

但是我的整个后台服务都是部署在内网，只有微信调用微信公众号获取openid的这一部分需要使用外网，于是搭建了一个外网的代理服务器，那么我就可以基于http请求的代理服务，只让这部分rest服务访问外网。

我们现实场景中还有一些经常使用的像文件上传和下载之类的，它也是支持的。

文件上传，并且在上传文件的同事支持参数的传递。

@Test
public void uploadFile() {
    Response post = given().param("id", "123456")
            .multiPart("file", new File("D:/zzrd.jpg"))
            .post("/file");
    Assert.assertEquals("123456", post.asString());
}

文件下载如下：

@Test
public void downloadFile() {
    Response response = given().get("/export");
    byte[] bytes = response.asByteArray();
    BufferedOutputStream bos = null;
    try {
        bos = new BufferedOutputStream(new FileOutputStream(new File("d:/xxoo.xls")));
        bos.write(bytes);
    } catch (FileNotFoundException e) {
        //TODO
        e.printStackTrace();
    } catch (IOException e) {
        //TODO
        e.printStackTrace();
    }finally {
        try {
            if(bos != null) {
                bos.close();
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

5、rest-assured使用场景

我的系统测试非常复杂，有基于表单的，基于json数据格式的，还有使用了xml格式，有部分返回的数据结构也很复杂，有的接口请求地址或者端口是不一样的，或者使用了代理等功能。

你可以直接使用rest-assured来解决你碰到的这些实际问题。

我是不是可以在业务代码的请求中直接使用rest-assured?

其实这个我是不推荐的，因为我曾经在我机器上，基于我自己的系统对rest-assured和httpclient做了比较，分别单线程测试（分别请求1000次，rest-assured耗时85s，httpclient耗时79s）后来我自己也做过多线程测试，无论怎么测试，得出的结论就是httpclient也比rest-assured快。

当然这个可能也不一定准确，服务不同环境不同，测试结果也会随之改变。毕竟rest-assured底层对httpclient又进行了一次封装，而且使用了groovy，groovy虽然是一门动态语言，但是他还是基于jvm平台的，最后还是编译成了class。

个人认为，groovy除了在jvm平台上执行，并且写的脚本足够短之外，跟其它的ruby或者python等脚本语言相比，是没有什么优势的。但是他作为测试用例来用，优势还是非常大的，因为测试用例，不是线上环境，对性能没什么特别要求。

我使用了springmvc Controller可以使用rest-assured做接口测试吗？

其实对于这个rest-assured也有对应的spring-mock-mvc，但是spring官方也有基于spring-test接口测试，要是还用rest-assured提供的，老感觉有一种拿着锤子找钉的感觉。

6、测试带给我们的好处

测试给我们的产品带来的好处是非常多的，这里我们只是基于rest API进行测试，在单元测试中来说，这是一个粗粒度的测试，如果想更加详细，像基于h2数据库的脚本测试，但是现在我们大部分框架都使用了jpa，这个测试能给我们带来一定好处，但是工作量也是很可观的。

该不该进行一些基于h2内存数据库的模拟测试，这里我们自己拿捏，不做过多的建议。

至于基于mock业务逻辑的隔离测试，当我们碰到复杂业务逻辑，或者在某种环境下，某个场景难于模拟，如果我们使用了mock，这种场景完全可以避免掉。

这种测试该做还是要做的，下面我们可以简单说下单元测试本身给我们带来哪些明面上的好处。

首先应该就是它是一种验证行为，而且具有一定的可回归性。

我们只是在每完成一个功能之后写了一个测试用例，立刻可以验证我们的功能是通过的。当我们的一个模块或者一个大的功能通过之后，我们可以基于maven快速的运行所有的单元测试。来保证我们的功能在本地是通过测试的。

其实就是在开发后期，我们看着某一块功能或者业务逻辑很不爽（这是别人写的），那么我们就可以直接修改功能或者重构，之后我们就可以利用测试用例来保证没有破坏其他的设计，说白了单元测试能给我们改善设计带来信心。

单元测试代码更具有可维护性，在某种程度上，可以认为是一种文档的行为，但是带来效果可能比文档还要好。

一套系统，我开发出来，可能过几天交给AA了，2年后交给了CC，CC怎么才知道后台服务系统是完全没有问题的，或者说他怎么知道某个rest服务的目的是什么。

如果说我们测试用例中写了完整的输入和输出的断言机制，整体系统的代码可读性都会增强。

7、能够在某种程度上提升代码质量

这一点我也认为是非常重要的，当你编写完一个简单的功能时，你运行一下，输入一些边界条件，保证程序是可运行的。

这一点是必须的，但是当你出现问题，通常我们调试代码的过程都是打个断点，进入代码内部进行详细分析，这时你对你的刚刚完成的业务逻辑有个整体的认识，这时如果你发现有不合适的地方，或者代码冗余的地方，你应该开始调整了。

特别是当你使用mock进行隔离测试时，有时为了测试某一个场景，你不得不解耦合（因为这样让你更容易测试），在不知不觉中提升了自己的代码质量。

当然上述都是一些单元测试的好处，测试本来都应该是软件开发的一部分，这些都是不可否认的。甚至有人提出了TDD,先编写测试用例，测试用例来确定要编写什么产品代码，这些都充分说明了单元测试的重要性。

所以我们不仅要写测试用例，还要写好测试用例。

8、系统测试覆盖率依然少的可怜

其实究其原因无非就是产品更新迭代快需要快速占领市场，或者项目赶得实在太紧急，根本没有时间写测试用例，这里一般都是说没有时间写测试用例，但是还是要测试的。

我感觉除了一些业界大牛外，在自己的一段业务代码没有做测试前，谁敢保证完全没有任何问题。再说业界大牛估计写业务代码的也不多吧。

所以我经常就发现一些现象就是，大部分人在这种情况下，对于rest服务接口，直接简单省事的用一个httpURLconnection轮番测试所有的接口，最后测着测着自己的测试代码都有问题了，这还如何保证自己服务端代码的质量呢？

有的同学可能比较擅长使用一些工具，像谷歌的postman或restclient等http接口测试工具，直接把请求拷贝过去，参数添加上去，运行下，OK！

有些运用熟练地同学发现里面还可以收藏，把你以前添加的接口收藏到一个列表中，以后可以继续使用。

在某种程度上来说，他提高了我们一些效率，但是难道我们每次上线前都得手动把你之前添加的接口，挨个点一遍么，刚开始看着还能说过去，但是长远看，效率太低。

这里我们在反过来看rest-assured，或者我们开发出一套适用于我们系统的测试框架，通常都是一句逻辑控制代码加断言，这样一句简单的代码，的确能够保证我们的产品质量，还能提升我们的工作效率。

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。

?