企业🤖AI智能体构建引擎,智能编排和调试,一键部署,支持私有化部署方案 广告
接口测试简介 本节概要 1 了解测试金字塔(应知) 2 了解接口的定义(应知) 3 掌握接口测试用例设计(应会) 4 接口测试工具的简介(应知) 1 了解测试金字塔(应知) 1.1在软件测试界有个金字塔大家需要了解 ![](https://img.kancloud.cn/7c/4b/7c4b2d72bb08d8c9e5397b302f7b835d_639x418.png) 首先我们来看看这个分层 手动测试: 就是我现在这样手动的黑盒测试 界面测试: 一般都是 UI 层级的测试, 我所了解到的使用的工具就是 selenium, 通过对 UI的自动化测试, 也能进行功能上的验收。 服务测试: 就是对产品所提供的服务进行测试 组件测试: 接口测试, 可以通过代码实现, 也可以借助工具, 当前使用最多的工具应该就是 poster、 postman 和 Jmeter 单元测试: 针对类库和程序集进行测试 从上面这个金字塔我们基本可以看出以下几个特点: 1) **测试越往下面测试效率越高,** **测试质量保障程度越高** 单元测试时对软件中最小可测试单元进行测试, 所以在缺陷的定位上更精确。 而不同的语言都有自己的单元测试框架, 从而也能够保证单元测试的规范。 和其他测试相比, 单元测试对测试员的要求更高, 但是也能够更好的保证测试的质量。 2) **测试越往下面测试成本越低** 大家也都知道, Bug 越早发现, 损失就越小, 成本也越低。 这个金字塔, 也是符合这个规则的。 虽然目前敏捷开发盛行, 但是真正的敏捷团队, 我至今没有遇到多少, 大部分的团队仍然是瀑布式模型。 那么按照瀑布模型来看, 单元测试, 是最早开始实施的。 等到界面测试、 手工测试的时候才发现的 Bug, 再进行定位、 解决, 花费的时间会更多。 3) **测试越往下面,** **职业前景越好** 越往金字塔底层, 测试的技术含量要求更高, 测试人员的核心竞争力更大, 薪酬当然要高一些, 如果从技术方向来说, 可以做高级测试工程师、 测试架构师都有可能。 2.1 **接口测试的定义** 接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。 测试的重点是要检查数据的交换, 传递和控制管理过程, 以及系统间的相互逻辑依赖关系等。 2 了解接口的定义(应知) 2.2**接口的分类** **外部系统的接口** 其实无论是 C/S 还是 B/S 的产品, 都会存在外部接口的调用。 最经常见到的就是, 接入的第三方登录(QQ、 微信、 微博等) , 在产品上, 使用你们在接入的平台已经注册过得账号进行登录, 然后产品就会调用接入的接口, 交给接入的第三方进行验证, 验证通过的话,返回给产品一个登录成功的信息, 就实现了第三方接入的登录。 **服务与服务的接口** 服务间的接口, 其实就是不同模块的互相调用, 实现功能上的交互。 举个例子来说, 比如我们注册一个账号, 这个时候, 就会先去调用数据查询的服务, 检查数据是否有重复, 如果无重复数据再允许注册, 然后还要调用新增数据的接口, 这样才可以完成一个账号的创建。 **上层服务对下层服务的调用** 应用层: 系统的功能 服务层: 服务器对数据和逻辑的处理 数据库: 主要用来存放数据 就像上面的例子, 我们去注册一个用户。 首先在应用层, 我们通过输入框和注册的按钮, 输入我们将要注册的用户的信息, 然后通过注册按钮, 提交请求至服务层。 这个时候服务层, 在接收到应用层的请求之后, 要先去判断是否是重复的数据, 所以就要去调用数据库的查询接口, 如果发现是重复数据, 那么返回一个是重复数据的状态码到服务层, 服务层, 根据状态码做出判断, 返回到应用层, 应用层根据服务层返回的内容, 做出相应的处理。 如果不是重复数据, 那么也会返回一个状态码给服务层, 服务层判断之后作出处理, 返回到应用层。 然后我们在应用层上看到的就是注册成功了。 上面讲述的这个例子, 在各个层级中的数据传递, 层级之间的交互都是通过接口的。 **2.3** **神秘的接口测试** 接口, 一个很熟悉的名词, 经常听人提起, 却又是那么神秘。 大家都觉得接口测试很神秘, 其实它并不神秘, 我们大家在 UI 层的测试就做过, 只是不知道而已。 现在无非是提升到另一个层级罢了。 抛开 UI 层, 客户端我们来看。 所谓的接口充满着整个项目, 模块与模块之间的交互、调用, 端与端的交互、 数据的传递, 还有外部接口的调用, 最常见的就是第三方集成的 SDK的调用(比如支付、 登录、 注册) 。 这些都要通过一个一个的接口去实现。 通过接口, 将模块, 端与端衔接起来, 这样才能使我们的项目正常的进行工作。 最简单的接口测试应该就是, 拿一个接口, 粘贴到浏览器的地址栏然后拼接参数, 检查返回数据的正确性, 这里这个正确性不仅仅包括数据是否正确还要检查数据格式。 当然, 我们也能通过工具去完成这项测试。 那么再进一步应该就是通过设置线程、 循环、 启动时常, 去完成压力、 并发的测试。 这里也可以算作是性能接口测试。 这些的通过工具可以实现。 用代码实现起来的话, 监测的数据没有工具那么全面, 但是代码比工具更加灵活。 高级接口测试就涉及到了签名加密的接口,这一类的接口一般都是通过写脚本去进行测试。 2,4 **接口测试的意义** **保证系统的稳定性** 越接近底层对系统的影响就越大。 服务端的一个缺陷, 可能会引起客户端的几个甚至十几个缺陷, 还有一些会直接导致客户端的崩溃。这对整个系统造成的损失是不可估量的,因此服务端接口的质量将直接影响到系统的正确和稳定。 正常来讲, 一般的开发或者是白盒测试, 都需要进行单元测试, 而相对于单元测试来讲,接口测试需要测试的接口或者函数的数量会远远小于单元测试, 所以, 接口定义的稳定性会远远高于类级别的函数 将缺陷控制在项目前期 对于我们测试来说, 越早介入测试越好。 由测试金字塔中的介绍可以看出, 他的颗粒度比单元测试更粗。 一般是基于子系统或者是子模块的接口层面的测试, 所以并不需要等到完全集成, 所有功能开发完成才能进行测试。 从这个角度来看, 它确实能够帮助我们将缺陷控制在项目前期。 节省测试成本 我们上面也说到了, 接口测试是基于子系统或者是子模块的接口层面的测试。 因此, 接口测试需要测试的接口或者函数的数量会远远小于单元测试, 所以, 接口测试用例代码的改动量也远远小于单元测试,代码维护成本会比单元测试少很多,因而测试的投入量会小很多。 而且将缺陷有效的控制在了项目前期, 避免了很多不必要的麻烦, 所以我认为, 接口测试能够节省测试成本。 3 掌握接口测试用例设计(应会) 3.1 **接口测试用例的理解** **如何简单设计接口测试的设计用例** a) 明确出发点——测试的目的是为了让找出软件的缺口, 修复并使之更加完善。 在这一基础点上, 接口测试也不例外。 以找出软件的误漏为出发点, 测试用例需紧贴此线, 更容易找出问题所在。 b) 明确测试点——选择好的测试对象。 系统内部层次繁复复杂, 任何一个接口的变动都将导致用例失效。 (可将这些最外层的接口根据数据的流向分为进入和流出两类, 进入系统的接口实际上是我们用例的执行调用的接口。 可通过参数对这些接口进行调用, 模拟外部的使用; 而流出的接口则是我们用例真正该验证的点。 数据从哪里流出, 流出的状态如何,此时系统的状态都是作为测试目的所要着重关注的部分) c) 确认完整的测试对象的功能——确认外部接口提供给使用这些接口的外部用户什么样的功能, 外部用户真正需要的时什么样的功能予以区别。 用例的设计要严格按照测试对象功能设计才是正确的用例。 **接口测试用例有哪些要求**: 结构好, 可读性高, 渗透性强。 接口测试用例包括的内容 a) 接口测试测试的功能点: 如果一个接口功能过于复杂时, 可以对接口用例进行结构划分(如根据层次, 平台, 功能点等等) , 这样用例具有更好的可读性(接口划分原则为: 以接口提供的功能点的不同进行合适粒度的划分, 同一功能点的用例又可根据测试环境的不同, 数据的不同进行用例的填充) b) 接口测试用例的环境: 程序内部环境和程序所调用的外部接口的环境。 c) 关于接口测试测试数据: 分为两部分: 接口参数数据和用例执行所需系统数据。 数据的设计、 准备测试用例的数据不可马虎。 通过好的测试数据查找问题, 能极大的提高工作效率。 接口参数数据需要对每个参数根据测试接口的实际功能进行分析, 在符合业务逻辑的情况下进行逻辑组合排列, 一定要记得边界值和错误点的数据, 这样用例更容易发现问题。 d) 执行操作: 即对所测接口的调用。 e) 预期结果: 根据需求进行验证, 是衡量软件是否达到预期的标准。 应该着重细致,每个用例均需验证, 应该避免一个用例重复做相同的验证, 提高测试用例的效率。 **具体测试用例的参考点** a) 参数测试: 针对参数进行的测试, 也可以说是假定接口参数的不正确性进行的测试, 确保接口对任意类型的输入都做了相应的处理: 输入参数合法(不合法) , 输入参数为空, 为null, 输入参数超长等等; b) 功能测试: 接口是否满足了所提供的功能, 相当于正常情况测试, 如果一个接口功能复杂时推荐对接口用例进行结构划分, 这样子用例觉有更好的可读性和可维护性; c) 逻辑测试: 保持内部逻辑的正确性, 从设计文档中考虑内部逻辑错误的分之情况和异常; d) 异常情况测试: 接口实现是否对清楚情况都进行了处理, 接口输入参数虽然合法, 但是在接口实现中, 也会出现异常, 因为内部的异常不一定是输入的数据造成的, 而有可能是其他逻辑造成的, 程序需要对任何异常都进行处理。 下面给大家分享一个接口: ![](https://img.kancloud.cn/17/6a/176a60da91c043862748e42f1a0916b8_639x714.png) ![](https://img.kancloud.cn/29/e0/29e03ba3bc2dc0e06b8f46fc4bbcf30d_639x714.png) 3.2 接口测试用例的设计 通过接口测试文档知道了以下信息。 请求的 URL 请求的方式 用户中奖之后的返回值。 状态码,接口测试用例要覆盖到每一种情况。 当然,这里提供的处理逻辑并不一定是完整的,比如,这个接口的调用,还有哪些情况是接口没考虑到的。比 如你传的参数是空的,结果接口没有正确处理这种情况,而是返回了一堆报错。那么说明这个接口有问题,需要开 发修改。当然,这主要是靠你对接口业务的熟悉程度了。和功能测试用例的设计本身没有区别。 3.3 状态吗 ![](https://img.kancloud.cn/7d/2a/7d2a02ae51f643677fbd3e7bc1e76181_646x353.png) 4 接口测试工具的简介(应知) 4.1 关于接口测试工具 1. postman 是google开发的一款功能强大的网页调试与发送HTTP请求的chrome插件,并能运行测试用例的的Chrome插件. 2. Firefox RESTClient的插件,是一款用于测试各种Web服务的插件,它可以向服务器发送各种HTTP请求(用户也可以自定义请求方式),并显示服务器响应. 3. Jmeter:是Apche公司使用Java平台开发的一款测试工具。想学习更专业接口测试。了解接口测试工具,还有使用方法的话,去传智播客的论坛去。里面有视频资料还有课堂笔记资料。足够自学了。找不到的话去官网对话框直接要也能要到。我就是直接要的。 注意:章节主要学习postman的使用 4.2 postman介绍 Postman有两个版本:1 .chrom浏览器插件版本,2.native本地安装版他们的区别如下: 1) native版本可以直接操作cookies,而chrome版本需要安装拓展 2) native版本自带proxy,可以用来抓包: 3) native版本可以直接操作cookies,而chrome版本需要安装拓展 4) 有一些headers在chrome上是受限的,比如origin and user-agent 5) don't follow redirect option,只有native版本才有这个选项 6) postman console,native版本自带 基于以上原因,本课程也主要介绍native版本的使用。(插件版本官方已经停止更新) 至于这个能不能做 APP 的接口测试,我只想说, 接口测试只看协议, 不分架构, 无论你是 C/S 还是 B/S。 无论你是 web 还是 APP,只要你是 http 协议, 它就能够帮助你完成你的测试。) 为了保持版本一致建议使用教材中的安装文件