目录
很多的老6面试官都喜欢问这个憨批问题,兄弟们在这里就稍微的记一下哈。
重点:学习资料学习当然离不开资料,这里当然也给你们准备了600G的学习资料
前言:
很多小伙伴和凡叔说能不能把写一个详细到细胞核的关于接口自动化测试的全套自动化测试教程啊
行!!!谁让你是凡叔粉丝呢,哈哈哈。当然学习是一个循序渐进的过程,这里也会从最基础的开始写,这样也方便哪些基础不是很ok的小伙伴去理解和学习,后续的技术深度和广度也会慢慢的增加,基础好的小伙伴也不要着急哈,后续还是能学到很多东西的,废话少bb直接上干货。
【文章末尾给大家留下了大量的福利】
接口定义
一般我们所说的接口即API,那什么又是API呢,百度给的定义如下:
API(Application Programming Interface,应用程序接口)是一些预先定义的接口(如函数、HTTP接口),或指软件系统不同组成部分衔接的约定。用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程,而又无需访问源码,或理解内部工作机制的细节。
有点绕口,但我们看下定义里面这些关键字:预先定义的接口 (如函数、HTTP接口)、基于软件或硬件得以访问、无需访问源码、无需理解内部工作机制,大概就明白了。
举例说明:
-
电脑或手机上提供了各种物理硬件接口,如:USB接口、充电接口、耳机接口、麦克风接口等。这些不同的接口有不同的功能,比如通过USB接口插入U盘就可以拷贝数据,插入耳机接口可以听音乐,我们无需关心这些接口的工作原理,只需通过这些接口满足我们的使用需求即可。
-
在中国天气网网上查询某个城市天气,输入城市名称,即可获取对应城市的天气。查询背后的本质也是调用了网站后台接口来获取数据,这里的接口是Web服务软件接口。用户不需要关注数据在网站后台是怎么查询的,只需要得到返回结果即可。
接口分类
软件接口分类的维度有很多,类型比较难以界定,也可能经常会被搞混淆。
以接口所使用的协议不同可做如下分类:
-
HTTP 接口,使用 HTTP 协议
-
Web Service 接口,使用 soap
-
WebSocket 接口,使用 TCP、UDP 协议
-
Dubbo 接口,使用 Dubbo 协议
当然,以使用协议不同进行分类其实也是不严谨的,例如 soap 协议也是基于 HTTP 协议的封装,Dubbo 协议基于 TCP 协议,所以这个分类也仅供参考。
以接口设计风格不同可做如下分类:
-
RPC 类型接口,RPC 面向过程调用(Remote Procedure Call Protocol),主要是基于 TCP/IP 协议
-
REST 类型接口,REST 面向资源调用(Representational State Transfer),主要是基于 HTTP 协议
至于这两种风格的具体内容,这里不做过多说明,有兴趣的同学可以自行查找资料。
常见接口
接口测试即对接口进行校验性测试,测试工作过程中常遇到的接口有HTTP、Dubbo两种,两者对比如下 (理解有误的话欢迎评论指正):
目前绝大部分公司的接口测试都是针对HTTP接口。
以登录TesterHome网站为例,我们在网页上输入用户名、密码,点击【登录】按钮后,网页就会请求登录接口 (该接口为HTTP接口) 向服务端发起登录请求。
输入错误的用户名或错误,登录接口(sign_in)就会返回错误,如下:
输入正确的用户名和密码,登录接口校验通过,登录成功且跳转至首页,如下:
通过示例,我们对客户端跟服务端之间怎样通过接口的形式进行数据的交互有个大致的印象。
测试分层
通常把软件测试分为三层金字塔模型,由上至下依次为:UI测试、接口测试、单元测试。
就项目质量而言,金字塔的每一层都无法被替代,我们平常测试可能更多的是关注UI测试,但对于满足满足被测系统的质量而言这往往是不能够的,除此之外还需要对接口进行测试 (单元测试一般由开发完成)。
接口测试的必要性及优势如下:
-
比UI测试更接近底层,越早发现底层的问题,解决成本越低。
-
相对于UI测试而言,接口测试更容易发现后端隐藏的bug。
-
在前后端分离的设计模式下,容易绕过前端篡改或伪造数据进行接口请求,因此需要对接口的异常处理能力及安全性方面进行测试。
-
在并发的情况下,需要对接口的稳定性进行性能测试,否则容易造成系统问题。
-
相对于单元测试而言,接口测试更接近用户使用场景,且投入成本更低。
-
相对于UI测试,接口测试可以进行维护成本更低、效率更高的自动化测试。
测试左移和右移
近些年测试行业越来越多地提及测试的左移与右移,它们的定义如下。
测试左移
测试左移