接口测试
一 接口测试基础
1 测试流程
1 需求分析 - 依据需求文档
2 接口文档解析(API文档)- 开发人员编写
3 设计测试用例
4 执行测试 - 使用接口测试工具 / 编写代码
5 接口缺陷管理与跟踪
6 生成测试报告
7 接口自动化持续集成
2 定义
- 接口测试:对系统或组件之间的接口进行测试,主要是校验数据的交换、传递和控制管理过程,以及相互逻辑依赖关系
- 接口自动化测试:让程序或工具代替人工自动地完成对接口测试的测试
- 接口:硬件接口 / 软件接口,指系统或组件之间的交互点,通过这些交互点可以实现数据的交互(数据交互的通道)
- 接口类型(按照范围划分):
- 系统之间的接口:多个内部系统之间的交互,内部系统与外部系统之间的交互
- 程序内部的接口:方法与方法之间,模块与模块之间的交互
3 原理
模拟客户端向服务器发送请求,服务器接收请求后进行相应的业务处理,并向客户端返回响应数据,检查响应数据是否符合预期
4 特点
- 测试提前介入,提早发现Bug,符合质量控制前移的理念
- 可以发现一些页面操作呢发现不了的问题
- 接口测试低成本高效益(底层的1个Bug能够引发上层8个Bug)
- 不同于传统的单元测试,接口测试是从用户的角度对系统进行全面的检测
5 实现方式
- 使用接口测试工具:JMeter Postman
- 编写代码:Python+Requests
6 测试点
二 HTTP协议
1 HTTP协议
- HyperText Tranfer Protocol 超文本传输协议,基于请求与响应模式的,应用层协议
- 特点:支持客户端-服务器模式 / 简单快速 / 灵活 / 无连接 / 无状态
2 URL
- HTTP用URL来建立连接和传输数据
3 HTTP 请求
- 客户端:用于发送请求,如浏览器、App
- 服务端:处理客户端请求并返回数据,如apache / nginx
- 请求:客户端向服务器索要数据
请求行
- 位置在第一行,说明请求方法,要访问的资源以及所使用的协议版本
请求方法:
- GET:查询数据,从服务器获取资源 / 无请求体
- POST:提交数据,新增数据,在服务器建立一个资源
- PUT:修改数据,在服务器更新资源(客户端提供改变后的完整资源)
- DELETE:删除数据,从服务器删除资源
- HEAD:请求获取由Request-URL所标识资源的响应消息报头
- TRACE:请求服务器回送收到的请求信息,主要用于测试或诊断
- CONNECT:保留将来使用
- OPTIONS:请求查询服务器的性能,或者查询与资源相关的选项和需求
GET和POST区别
- GET把参数包含在URL中,POST通过request body(请求体)传递参数
- GET比POST更不安全,因为参数直接暴露在URL上,所以不能够用来传递敏感信息
- GET在浏览器回退时是无害的,而POST会再次提交请求
- GET请求只能进行URL编码,而 POST支持多种编码方式
- GET请求参数会被完整地保留在浏览器历史记录里,而POST的参数不会被保留
- GET请求在URL中传送的参数是有长度限制的,而POST没有(这个限制是由浏览器导致的)
- 对参数的数据类型,GET只接受ASCII码字符,而POST没有限制
请求头
- 第一行后,空行前 / 描述客户请求信息的相关参数,一般以键值对的形式存在,如描述浏览器类型
- 请求头:
- User-Agent:产生请求的浏览器类型
- Accept:客户端可识别的内容类型列表
- Content-Type:请求体数据的类型,常见的类型:
- text/html:HTML格式
- text/plain:纯文本格式
- image/jpeg:jpg图片格式
- application/json:JSON数据格式
- application/x-www.form-urlencoded:form表单数据
- multipart/form-data:文件上传
请求体
- GET中无请求体,POST PUT中常用
- 请求体的数据可以是:表单数据、文本、XML、JSON
4 HTTP 响应
- 响应:服务器处理完成后,返回给客户端的数据与信息
状态行
- 由协议版本号,状态码,状态消息3部分组
状态码
301 redirect: 301 代表永久性转移(Permanently Moved)
302 redirect: 302 代表暂时性转移(Temporarily Moved )
共同:301和302状态码都表示重定向,就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址,这个地址可以从响应的Location首部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)
不同:301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了),搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址;302表示旧地址A的资源还在(仍然可以访问),这个重定向只是临时地从旧地址A跳转到地址B,搜索引擎会抓取新的内容而保存旧的网址
响应头
描述服务器的基本信息以及数据的描述,服务器通过这些数据的描述信息,可以通知客户端如何处理响应数据
响应体
响应的消息体,数据可以是普通文本,XML,JSON,HTML源码
5 TCP三次握手
SYN:同步序列编号Synchronize Sequence Numbers
- 第一次握手:建立连接时,客户发送syn包到服务器,并进入SYN_SENT状态,等待服务器确认
- 第二次握手:服务器收到syn包,必须确认客户的SYN,同时自己也发送一个SYN包,即SYN+ACK包,此时服务器进入SYN_RECV状态
- 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK,此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手
为什么不是两次?
在服务端对客户端的请求进行回应后(第二次握手后),就会理所当然认为连接已经建立,但是如果客户端并没有收到服务器端的回应呢?
此时,客户端仍认为连接未建立,服务端会对已建立的连接保存必要的资源,如果出现大量这种情况,服务器会崩溃。
6 TCP四次挥手
- TCP连接是全双工的,因此每个方向都必须单独进行关闭
- 这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接
- 收到一个FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能够发送数据
- 首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭
- 第一次挥手:客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送
- 第二次挥手:服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1,ACK和SYN一样,均占用一个序号
- 第三次挥手:服务器B关闭与客户端A的连接,发送一个FIN给客户端A
- 第四次挥手:客户端A发回ACK报文确认,并将确认序号设置为收到序号加1
为什么四次?
- 因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后,它可以把ACK和SYN(ACK起应答作用, SYN起同步作用)放在一个报文里来发送
- 但当关闭连接时,当收到对方FIN报文通知时,它仅仅表示对方没有数据发送给你了,但未必你所有的数据都发送给对方了
- 所以你未必会马上关闭SOCKET,你可能还需要发送一些数据给对方之后,再发送FIN报文给对方表示你同意现在可以关闭连接了
- 所以这里的ACK报文和FIN报文多数情况下都是分开发送的
三 接口规范 RESTful
- 一种软件架构风格,设计风格,而不是标准,只是提供了一组设计原则和约束条件
- REST(Representational State Transfer),表现层状态转化
- 如果一个架构符合REST原则,则为RESTful架构
- RESTful接口风格,对用户进行操作的相关接口,包括增删改查
- RESTful架构特点