不点蓝字,我们哪来故事?
前言
接口测试的意义是什么?它依据什么来测试?
1、HTTP接口测试的意义继《软件测试|| 让我们一起走进接口测试(一)》文,我们了解到,当发送“https://api.douban.com/v2/music/search?q=漫步人生路&count=2”请求到服务端时,服务端返回的是原始的文本字符串,如下图所示。
图1 请求响应
通过以上返回的原始字符串可以看到,这些文本字符串其实是具有一定格式的,在这里抽取前面一小部分的字符串来介绍。
例如:{"count":17,"start":0,"total":17}。
这种格式的字符串也是以键值对应(key-value)的表示方式来表达的。
其中第一组的键是count,键的值是17;另外两组的键分别为start和total,它们的值分别是0和17。
这里的键和值之间用“:”连接(前面介绍的用等号连接的方式也是键值对应的表现形式之一)。
不同的键值对用“,”分隔,键本身需要用双引号括起来,键的值如果是数字的话可以不用双引号,如果是字符(比如中文和英文等字符)则需要用双引号括起来。
其实它们表示的含义可以理解为count=17,start=0,total=17。
这里把这种键值对应并外加花括号格式的字符串称为JSON格式字符串。在进行HTTP接口测试时,服务端返回的一般都是JSON格式字符串。
这里可以把JSON理解为具有键值对应的纯文本字符串。
从图1中可以看到原始的JSON格式的字符串密密麻麻地串在一起,不是很美观,此时可以将原始的JSON字符串格式化一下。
可以利用Firefox浏览器自带的JSON格式化的工具进行格式化,在Firefox浏览器中只要单击“原始数据”左边的JSON按钮,就可以将原始的JSON字符串进行格式化。
由于内容很多,从中选取一个片段,如下图所示。
图2 JSON格式化
经过格式化后的JSON字符串是不是美观了很多呢!
以上查询结果是直接通过接口进行查询的,而不是通过用户的交互界面进行查询的,接下来通过豆瓣网官网,也就是已集成好的用户交互界面去查询歌曲名为“漫步人生路”的歌曲,如下图所示。
搜索“漫步人生路”的歌曲
查询之后来看看返回的结果,如下图所示。
搜索结果
对比通过接口进行查询和通过用户交互界面进行查询的两种方式可以发现,它们查询出来的内容几乎是一样的。
只是通过用户交互界面查询出来的数据更漂亮一些,因为这些数据是要给用户看的,所以使用UI技术进行了美化和渲染。
虽然说通过接口进行查询返回的JSON格式的字符串没有集成界面返回的网页元素那么直观和漂亮,但是JSON格式的字符串通过键值对应的方式也很直接地描述出返回来的内容。
在图2中抽取了几个键值对应的数据,如publisher:“环球唱片”、title:“漫步人生路”,这里面的publisher、title的中文意思分别是出版商、标题。
那么通过这些键值对应的信息,就能很清楚地了解到这首歌曲的相关信息,这也就是为什么接口测试返回的数据一般都用JSON格式的字符串,因为它较清楚直接地描述了要返回的内容。
关于JSON格式的字符串,几乎所有的开发语言都认识它,更多JSON字符串的语法在这里不做详细讨论,请大家自行参考网上资源和相关图书。
接口测试的意义不仅在于它返回的是JSON格式的字符串,之所以通过上面两种查询的方式进行对比是想告诉大家以下几点。
(1)接口测试可以在用户界面还没有被开发出来之前就对系统或系统中的模块进行测试,不用等到系统提供了可测试的功能界面之后再进行测试。
(2)用户的交互界面封装了系统中各模块的接口。
有用户界面时,通过用户界面传递数据到系统中的接口去;没有用户界面时,可以直接通过接口传递数据。
也就是说,系统中各模块的接口是实现用户界面功能的基础。越早进行测试,就能越早发现Bug,与此同时开发人员修复Bug的成本就越低,这便是接口测试的意义所在。
(3)前端的页面和后台模块是两组人开发的,后台开发完后,再将前端的页面套在后台的接口上。
也就是说,只要后台模块测试好了,前端页面不管怎么改变都可以适用。
同时还要注意,数据通过前端页面输入时,前端页面通常只做一些基础校验,核心业务还要靠后台来处理。因为接口测试是跳过前端页面这一层框架提前对后台模块进行测试的,所以它的意义更重大。
有关接口测试更深层次的意义,待大家有了一定的工作经验后再自行感悟和学习。
2、HTTP接口测试的依据在上面节中,用豆瓣网提供的一个开放接口演示了接口测试的实质和意义。
那么在接口测试中,如何找到系统中各模块的接口地址呢?接口需要传递哪些参数呢?这些参数都代表了什么意思呢?如何去判断服务端返回的JSON字符串是否符合预期的要求呢?
这个大家不用担心,接口测试同大家做系统测试一样,都是有需求文档的,接口测试的需求文档叫接口文档。
接口测试人员做接口测试时,首要的任务就是拿到开发人员提供的接口文档,没有接口文档就等于没有测试的标准,也就无法开展测试工作。
下面展示一个接口文档中的一部分内容,见下表。
表1 接口文档的部分内容
此接口文档的内容很简单,并没有附加一些复杂的条件,目的是让大家能把基础的东西先了解清楚。
比如通过这份接口文档,可以了解到接口的地址、接口地址中要传递的参数、请求示例、服务端返回信息的格式、返回的示例、服务端会返回哪些具体的参数、这些参数都有什么对应关系等信息。
这是初学者应该能看懂的,但该接口文档里面有3个点是初学者可能没有见过的,具体如下。
(1)该接口文档提到的HTTP的两种请求方式——GET方式和POST方式,初学者可能不了解。
(2)该文档中提到的参数的数据类型,这里有两种常用的类型,一个是String(字符串类型),另一个是Number(数字型),其代表了参数可以输入的字符类型,这个并不是很难,请大家自行了解。
(3)该文档中提到的业务状态码,这里提到了0和-1的返回码,初学者可能不太了解。这个状态是开发人员自行制定的,为了判定业务信息返回的正确性。
本例中如果业务状态码返回0,则可以代表业务信息返回成功,如返回-1则代表业务信息返回失败。
有了此接口文档,就可以根据接口文档去设计接口的测试用例,那么接口测试的用例是什么样的呢?
在这里结合表1中的接口文档来设计几个示范用例,具体见表2。
表2 接口测试用例示范
从以上设计的测试用例可以看出,接口测试的测试用例和系统测试的测试用例并无太大区别,都有输入、输出。
有了测试用例之后,接下来就可以按照测试用例进行接口测试了。
由于请求的方式是GET方式,所以可以直接通过浏览器发送这些请求,例如执行最后一条用例,输入大于100的整数101,参数与接口地址之间用“?”分隔,如下图所示。
发送GET请求
发送完请求后再查看服务端响应的JSON格式的字符串是否符合本条用例的预期结果,如符合则本条测试用例通过,如不符合则提交Bug单给开发人员。
提交Bug单过程跟系统测试中提交Bug单都是一样的,描述Bug重现步骤并附上截图,指派给相应的开发人员进行修复。
在这里总结一下接口文档的要素,一个接口文档至少要包括以下内容。
(1)URL(接口地址)。
(2)请求方式POST、GET。
(3)入参(请求参数)。
(4)返回参数。
(5)请求、返回示例。
(6)返回的状态码和参数说明。
而接口测试的大体流程如下。
(1)拿到接口文档。
(2)设计测试用例。
(3)执行用例(测试的步骤:请求接口,然后取到返回值,最后判断实际结果与预期结果是否相同)。
(4)提交Bug单。到这里,相信大家对HTTP接口测试的概念和流程应有一个大体了解了,这样大家在面试中如果被问到接口测试的相关话题,也不至于不知所措了。
好了,今天分享到此哦,喜欢我,就关注我,期待下次相遇哦,么么哒~
end
往期推荐
软件测试|| 带你了解神秘的html,敢来试试吗?
软件测试|| 听说你还不了解XPath定位技术???
软件测试|| 今天咱们就来揭秘一下Python的神秘面纱!
软件测试|| 坐好小板凳,咱们一起看看Selenium WebDriver如何安装。
软件测试|| Selenium WebDriver的初步应用,初学者来了解一下。
软件测试|| 让我们一起走进接口测试(一)
扫描二维码
获取更多精彩
阳哥说IT