这是番外篇1, 标题是book-自动测试-番外篇-接口测试1。--辣么丑1.1概要大家好, 我是辣么丑, 《安卓app自动化测试》这个系列的文章目前已经更新了三个部分的内容了, 今天是来给大家发一个额外补充的番外篇章节, 主要内容是讲解那个接口API测试方面相关的事情。1.2 接口测试理论咱们先来认识一下接口是个什么东西, 以及什么又是接口测试。因为我的文章一贯都秉承着实战为主的原则, 所以对于那些理论性的概念, 我也尽量把它讲得通俗易懂。打个比方来说, 我对待接口的概念, 绝不会直接照抄纯理论的含义然后就完事了。好闲话说到这里, 我这里就举一个比较简单的例子, 通过这个例子来向你们说明白到底什么是接口, 以及我们这些做测试的人员, 究竟应该怎么样才能做好接口测试。比如说, 某个公司的一个网站有一个功能是用来查询一个城市的天气情况, 而这个公司也有对应的APP应用, 同样可以做城市的天气查询, 那么, 在程序实现上, 不会在网站开发一套天气查询功能, 手机短APP也去开发一套城市查询功能吧。讲到了这个程度, 相信大伙都已经清清楚楚了, 其实我们压根儿不需要在前台费劲巴拉地去做这件事, 我们的全部任务, 就是稳稳当当地在服务器那边把这个功能给开发出来, 而且只要我们的服务器, 能够真真切切地提供出一整套非常规整的方法, 好让那些在外界的形形色色的程序去调用和运用就好了, 无论是对应于那种通过网页浏览器去访问的web端还是手机端里面的各种app客户端, 你们只需要去安安稳稳地使用我们服务端已经给你准备好的一系列天气查询功能就可以了, 剩下的那部分工作, 就纯粹只是各个不同系统的前台界面该如何去把结果漂亮地展示给大家观看的问题了, 就是这么简单清晰。所以, 这里服务器端所提供的这一套方法, 实际上就是接口。如果把它说得更通俗一点, 那就是方法。只要知道了接口的地址以及参数是如何传递的, 任何知道这些信息的人都可以调用这个方法来获取天气情况。那么, 不妨接着深入思索一番, 平日里我们所开展的工作中的黑盒测试阶段, 其实际的操作表现形式, 难道不就等同于直接在网站平台或者是应用程序软件内部, 去切实执行与天气查询相关的那一部分功能逻辑吗?在此基础上, 依据所确定的具体功能模块, 然后再进一步地去细致考量关于如何编写测试用例的相关策略与方法。而接口测试就是在网站和app还未能完成前端的功能展示时, 我们提前针对天气查询这个功能做测试。和黑盒测试的区别就在于, 我们不是测试眼睛看到的实实在在的界面操作, 而是通过程序调取后台的方法即接口, 来完成测试这件事而已。那么说到我们的接口测试, 原则上来讲, 它和黑盒测试的测试思路是一样的, 在做黑盒测试的时候, 你需要去设计相关的测试用例, 所以在做接口测试时, 你也同样要去按照这样的方式去设计测试用例, 只是缺少了关于UI界面方面的测试内容。比如在做app端的测试这个工作的时候咱们是不是应该去设计一个案例, 这个案例的内容就是输入空内容, 拿这空内容去做天气查询, 然后看看咱们的app是怎么处理的。它究竟是弹出一个提示框, 明确提示说输入内容为空, 还是说对它不做任何反应。总之只要程序不会报错, 也不会崩溃, 就算通过了。然后接下来的问题是, 在具体做接口测试的时候, 具体该怎么做? 在接口传递参数的过程之中, 我们需要去设计一个案例, 这个案例是关于传递空字符串的。然后我们接着去检查服务所返回的内容到底是一个什么样的状态。是服务直接返回了400这样的报错信息。还是说服务返回了200来表示正常操作。如果是代表了正常的情况。我们还需要关注具体的返回内容究竟是什么样子。基于以上概述, 核心逻辑非常清晰, 那就是只要团队成员能够熟练掌握并扎实执行黑盒测试方法, 并且同时深刻理解接口的具体定义与运作原理, 那么关于“如何进行接口测试”这一操作层面的问题, 实际上也就迎刃而解, 不再构成任何实质性的障碍了。最后再来说说关于接口请求的事情, 这一般情况下总共有4种类型, 但是在我们的日常操作当中, 大家接触得最多的肯定就是POST和GET了。存在着两种方式, 其区别在于GET是不传递参数的请求, POST是需要传递参数的请求。1.3 实现的接口测试本节我们就进入接口测试的实战环节了。请原谅我在上一节说了很多话, 大家心里可能在想, 不是说好的要开始实战了吗, 哈哈。现在好了, 今天我将借助网络上现成的两个具备不同功能的接口, 来向大家讲解接口方面的应用技巧。其实我们公司内部也有自己的一套接口测试脚本, 但是那组脚本实在太难看了, 考虑到公司的面子问题, 我们决定还是采用其他的方式来进行演示。在进行接口测试工作的时候, 通常情况下, 开发人员需要提供给我们要进行验证的后台接口的详细说明文档, 也就是常说的接口文档, 然而我们今天所探讨的案例是从互联网上搜索得到的公开资料, 因此我会努力将每一个环节都描述得非常清楚, 确保细节能够被人们充分理解。首先我们先来看看这两个接口实现的功能第一个是大家能够把这个网址在浏览其中打开。这是一个进行天气查询的接口。第二个哈, 关于周公解梦这件事, 特此声明, 这里并不是在宣传迷信活动。实际上, 在此之前, 我还在自己的微信公众号平台里面成功实现了梦的功能解析。由于我已经唠叨了如此长的时间, 所以我打算直接呈现出一段代码, 以便让诸位能够对它形成一种直观上的感性认识。我们把页面上的那个东西点开, 如果从字面意思上去理解它所说的获取支持的城市这一概念, 那是显而易见的, 因为这其实就是一个用来查看系统到底支持哪些城市的接口方法。当我们把新页面滚动到最底部的地方, 就能看到下面这种画面里的内容。大家看到了没有, 前面所讲到过的GET, POST这个两个词就出现在这里了。我们先来详细看看关于GET的那一部分, 在它的介绍里面, 上面的那一行是说请求方面的情况, 而下面的那一部分则是说的服务器的返回结果方面的情况。如果你请求对了, 那么服务器会返回给你200 OK, 然后才是具体的结果。看看我们的代码中的内容#-*-:utf8-*-jsonurl;ret.(url)print ret.read()执行我们的脚本后看看打印的返回结果结果是, 输出的内容长度比较长, 这里只截取了开头的那少部分内容。看到这种输出结果, 就表示我们的接口请求已经完成并且成功获取到了支持的城市列表, 在城市名称后面的括号内就是与之对应的城市编码代码。现在我们回过头来查看脚本里面的具体代码实现过程。首先我们在代码文件里面通过导入操作把这个包给加载进来, 接着在后面就是通过调用来完成的整个接口访问流程, 其具体的执行逻辑其实非常简单, 仅仅包含了3行代码。先要把我们需要去访问的那个接口地址拼接在第一行, 那么现在我们不妨来具体看看这个接口地址究竟是怎么获取到的吧, 接着请大家回到我们的网页里面去, 并且找到关于GET方法的那块介绍内容。GET//.asmx/?/1.1Host:当然, 我们把地址链接起来, 就是主机部分加上请求部分里面的内容。在等号右边的位置是我们需要传递的参数, 这一点要和使用另一种方法提交的参数区分清楚。在这里, 参数是直接放在网络地址里面传送的。通常情况下, 问号之后的内容就是参数部分了。最后是具体我们要发送的数据内容。例如, 如果我们需要查询系统是否支持北京这个城市, 就把相应的部分替换成北京这个词。当然, 在我们的脚本里, 我们是没有传入任何参数的, 这也就表示我们传递的是一个空值。在接口的说明文档里头, 提到了一种情况, 具体的描述是这样的: “输入参数是代表指定的亚洲或者国内的某个省份的, 如果输入的是ALL这个字, 或者是空的, 那么就表示要返回全部的城市信息。”接着又说, “返回的数据形式是一个一维的字符串数组”。在这个数组里边, 每个元素的结构是由“城市名称”再加上一个括号, 括号里面装着“城市代码”这样的格式组成的。”如果我们实际上传递的参数确实是ALL, 或者压根就没有传参, 也就是空的话, 那么系统就会把全部的城市都返回给我们。因此, 如果我们是需要传递一个具体的城市名称的这一点的话, 像例如辣么丑所存在的那西安这样一个地方的话, 那么我们便是要用类似于以下的这样一种方式来去做书写与表达的。URL变量的值被设置为空字符串, 随后通过加号运算符连接一个经过编码处理的西安这个城市的名称, 该操作指定了所使用的字符集编码为UTF-8格式。执行以下看看结果返回的结果是正常的, 但是居然不支持我所在城市西安, 对此我只能予以谴责, 在这里我们应当把话题重新转向我们的接口测试方面, 就目前的情况来说, 我们在这一组接口上完成了两种不同类型的参数传递工作, 并且这些操作都产出了正常的结果。如果我们将这种情况放在实际的工作场景或者具体的项目里面去进行考量, 它是不是类似于我们正在执行的黑盒功能测试这样的操作呢? 如果你希望展开来讨论的话, 那么你可以把那些原本用于设计功能测试用例的思路与方法, 灵活地运用并移植到接口测试的工作上来。好了, 考虑到篇幅的限制, 我们目前只是实现了天气查询方面的一个接口的功能, 在接下来的《book--auto-test-番外篇-接口2》这个内容里面, 我会接着把上一篇的内容给延续下去, 进而把那个能够获取具体城市的天气预报的另外一个接口, 还有第二个关于解梦的接口, 这两个接口都给实现出来, 最后真心实意地感谢各位能够耐心地把这一篇文章读完完毕, 我的名字叫做辣么丑。