如何确保API的稳定性与正确性?你只需要这一招

现在,越来越多的 Web 应用转向了RESTful的架构,很多产品和应用暴露给用户的往往就是一组 REST API,这样有一个好处,用户可以根据需要,调用不同的 API,整合出自己的应用出来。从这个角度来讲,Web 开发的成本会越来越低,人们不必再维护自己的信息孤岛,而是使用 REST API 这种组合模式。
在这里插入图片描述
那么,作为 REST API 的提供者,如何确保 API 的稳定性与正确性呢?全面系统的测试是必不可少的。Java 程序员常常借助于 JUnit 来测试自己的 REST API,不,应该这样说,Java 程序员常常借助于JUnit 来测试 REST API的实现!从某种角度来说,这是一种“白盒测试”,Java 程序员清楚地知道正在测试的是哪个类、哪个方法,而不是从用户的角度出发,测试的是哪个REST API。

在这里插入图片描述
Rest-Assured 是一套由 Java 实现的 REST API测试框架,它是一个轻量级的REST API 客户端,可以直接编写代码向服务器端发起 HTTP请求,并验证返回结果;它的语法非常简洁,是一种专为测试 REST API 而设计的 DSL。使用 Rest-Assured 测试 REST API,就和真正的用户使用 REST API 一样,只不过 Rest-Assured 让这一切变得自动化了。
在这里插入图片描述
模拟get请求

雪球网是一个股票投资网站,你可以使用网站的搜索功能来查询股票信息,比如我们想查询sougou的信息,下 面利用了charles分析工具来查看请求和回答:
在这里插入图片描述
这是一个Get请求,返回的内容格式如下:
在这里插入图片描述
现在,我们使用 Rest-Assured 来编写一个简单的测试程序调用相同的Get请求:

第一步,我们要判断这是什么格式数据:json
第二步,确定请求地址:从charles的结果中获取y为https://xueqiu.com/stock/search.json
在这里插入图片描述
第三步,填写表单:从chrome浏览器检查结果中查询request的query信息是code:sougou
在这里插入图片描述
我们的代码也很简单:
在这里插入图片描述
返回的结果却很残酷:
在这里插入图片描述
与登陆账号,刷新页面有关的话,我首先想到了cookie,网站都用cookie来保存账号相关信息,于是加入 cookie:
在这里插入图片描述
返回结果正确,你问我惊不惊喜,老实回答,不惊喜。因为我搞不明白为什么一个查询需要Cookie验证,如果不加Cookie,返回的信息却是没有登陆!

在这里插入图片描述
显然,我的Cookie并不包含登陆信息,因为我压根就没有登陆,当然这是网站的设计,与Rest-assured无关。
在这里插入图片描述
更进一步

怎么区别xml与json
在这里插入图片描述
答:你看就知道了嘛,xml长这个样子
在这里插入图片描述
json长这个样子
在这里插入图片描述
given,when,then分别是什么

在这里插入图片描述
答:given用于放置需要的参数,比如上面例子中,我将访问参数:code和cookie放到了given里;when用于填 写要访问的url;then进行断言,来来判断结果是否正确。

模拟post请求

有的时候,我们想提交表单,这种情况下使用get会非常被动,于是post登场了。
在这里插入图片描述
下面是代码。
在这里插入图片描述
我相信此时你的内心是这样的。
在这里插入图片描述
别着急,下面我会讲清楚…

在我大万维网世界中,TCP就像汽车,我们用TCP来运输数据,它很可靠,从来不会发生丢件少件的现象。但是 如果路上跑的全是看起来一模一样的汽车,那这个世界看起来是一团混乱,非常紧急的警车可能被前面的汽车拦堵在路上,整个交通系统一定会瘫痪。
在这里插入图片描述
为了避免这种情况发生,交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别,有GET, POST, PUT, DELETE等等,HTTP规定,当执行GET请求的时候,要给汽车贴上GET的标签(设置method为GET),而且要求把传送的数据放在车顶上(url中)以方便记录。如果是POST请求,就要在车上贴上POST的标签,并把货物放在车厢里。当然,你也可以在GET的时候往车厢内偷偷藏点货物,但是这是很不光彩;也可以在POST的时候在车顶上也放一些数据,让人觉得傻乎乎的。HTTP只是个行为准则,而TCP才是GET和POST怎么实现的基本。
在这里插入图片描述
使用断言

使用EqualTo

在前面,我们使用了EqualTo判断值是否是“搜狗”:

在这里插入图片描述
它的作用显而易见:判断值是否相同。比如下面的例子
在这里插入图片描述
如果你想验证LottoId是否等于5,你可以这样做:
在这里插入图片描述
使用HasItems

在这里插入图片描述
在这里插入图片描述
你可以用再次EqualTo(),对WinnerId[0]用一次,对WinnerId[1]用一次。
在这里插入图片描述
哈哈,当然不是。你可以使用HasItems,它是这么使用的:

在这里插入图片描述

从根开始定位
在这里插入图片描述
在这里插入图片描述
额…请教王师傅。
在这里插入图片描述
比如下面的代码,我们可以这么验证:
在这里插入图片描述
使用find
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
答对了,请一定要记住xml和json的区别,不要混谈,那么你能编写一个测试来验证杂货(groceries)的类别是 否包含巧克力(Chocolate)和咖啡(Coffe)吗?
在这里插入图片描述
在这里插入图片描述
这确实达到了我的要求,但代码明显有很多bug,如果我更改了category的位置,像下面这样,你的代码就不 适用了,我不难为你了,请王师傅来解答吧:
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
find的用法展示的很清楚,不需要我多讲,当然还有一点要注意,你可以这么使用find:
在这里插入图片描述
**是个特殊用法,它从xml文档根部开始,进行深度搜索,直到找到符合我们需要的项。
在这里插入图片描述
使用findAll
在这里插入图片描述
现在我手头只有20块钱,我只能买两本书,我更喜欢世纪的谚语和白鲸记,现在的任务是:挑选出格低于10的书籍,并且标题是“世纪的谚语(Sayings of the Century)”和“白鲸记(Moby Dick)”
在这里插入图片描述
在这里插入图片描述
对的,这时候应该使用findAll,可以粗鲁的认为多个find的叠加。findAll可以筛选出一批符合要求的数据,而 find只能筛选出一个符合要求的数据,这就像是我们只能挑出一个人领取一等奖,但有很多人可以拿参与奖, 两个方法都有自己的用武之地。
在这里插入图片描述
下面的代码展示了findAll的用法:
在这里插入图片描述
提取想要的值

有时候,我们并不想验证是否正确,我们只想取出这个值以进行下一步处理,比如我想取出next的链接:/title?page=2,这种情况怎么办呢?
在这里插入图片描述
下面的代码判断内容是不是JSON,并且标题是My Title的话,就返回href链接/title?page=2,这个值被存放在nextTitleLink中,以供我们以后使用。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
当然,有两点需要注意:

返回类型是Response,我们可以用http://Response.xxx来二次提取想要的值。
extract().后面是response()方法,不要写错了。
更改默认值

rest-assured有很多默认值,也正因为如此,需要我们的填的参数可以很少,也可以很多,就像画画一样,可以很精致,也可以很简洁。
在这里插入图片描述
修改端口

rest-assured发起请求时,默认使用的host为localhost,端口为8080,如果你想使用不同的端口,你可以这样做:
在这里插入图片描述
或者是这样
在这里插入图片描述
或者
在这里插入图片描述
修改baseURI和basePath

你也可能改变默认的baseURI、basePath
在这里插入图片描述
这就意味着,类似 get(“/hello”) 这样的一个请求,其实完整的请求为:http://myhost.com:80/resource/hello , 并且使用基础授权认证"username" and “password”。

其他

其他的默认值可以参考下面:
在这里插入图片描述
重置

你也可以重置为标准的baseURL(localhost)、basePath(空)、标准端口port(8080)、标准根路径root path(" "),默 认的认证scheme(none)以及URL编码(true),通过下面的方法重置:
在这里插入图片描述
specification

在不同的测试用例当中,我们可能会有重复的响应断言或者是请求参数,那么我们可以将重复的这一部分提取出来定义一个规范或者模板,这样的话在后续的测试用例当中就可以使用这个规范模板了。
在这里插入图片描述
为了达到这个效果,我们可以使用RequestSpecBuilder或 ResponseSpecBuilder来实现,它们之间的区别 是,前者用在请求中,后者则用在body中。

ResponseSpecification重用

例如,你想在多个测试用例中,都使用这样的断言:判断响应状态码是否为200,并且Json数组"x.y"的大小是否 等于2。你可以定义一个ResponseSpecBuilder来实现这个功能:
在这里插入图片描述
在这个例子中,需要重用的两个断言数据被定义在"responseSpec",并且与另外一个body断言合并,组成了这个测试用例中全部的断言,那么这个测试用例需要全部断言都通过用例结果才会通过,一旦其中一个断言失败,则测试用例的测试结果为失败。

RequestSpecification重用

同样,假如你想在多个测试用例中重用请求数据,可以通过下面的代码来实现:

在这里插入图片描述
这里的请求数据被合并在"requestSpec"中,所以这个请求包含了两个参数(“parameter1"和"parameter2”)以及一 个头部(“header1”)。

学习安排上!

感谢每一个认真阅读我文章的人,下面这个网盘链接也是我费了几个月时间整理的非常全面的,希望也能帮助到有需要的你!
在这里插入图片描述
这些资料,对于想转行做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!凡事要趁早,特别是技术行业,一定要提升技术功底。希望对大家有所帮助……

如果你不想一个人野蛮生长,找不到系统的资料,问题得不到帮助,坚持几天便放弃的感受的话,可以点击下方小卡片加入我们群,大家可以一起讨论交流,里面会有各种软件测试资料和技术交流,同时我也把上面花几个月整理的资料放里边了,赶快加入吧。

敲字不易,如果此文章对你有帮助的话,点个赞收个藏来个关注,给作者一个鼓励。也方便你下次能够快速查找。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值