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

2023-12-18 18:03:42

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,或者我们开发出一套适用于我们系统的测试框架,通常都是一句逻辑控制代码加断言,这样一句简单的代码,的确能够保证我们的产品质量,还能提升我们的工作效率。

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

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

?

文章来源:https://blog.csdn.net/huace3740/article/details/135064704
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。