接口测试基础
什么是接口?
接口是指系统或组件之间的交互点,通过这些交互点可以实现数据的交互(交换、传递和控制管理)以及相互逻辑依赖关系。
接口可分为硬件接口和软件接口,这里只关注软件层面的接口。
接口包括内部接口和外部接口。内部接口,开发人员开发的对自身系统提供的接口;外部接口,开发系统调用外部的,例如微信、支付宝等其他接口。
总结:接口就是软件提供给外部的一种服务,用于做数据传输。
软件为什么需要接口?
因为接口能够让内部的数据被外部进行修改。
我们为什么要做接口测试?
- 现在很多系统都是前后端分离的,开发进度不一样,需要把先开发出来的接口进行测试;
- 基于安全考虑,前端的验证可能轻易绕过,直接请求接口调用到敏感数据;
- 测试推崇的测试左移,测试尽早的介入;
接口以及接口测试的本质
接口测试的本质:就是测试接口能否正常的交互数据、权限控制及异常场景等。
接口测试的原理
用工具或代码模拟客户端向服务器发送请求,服务器接收请求后进行相应的业务处理,并向客户端返回响应数据,检查响应数据是否符合预期。
接口测试主要内容包括:
1)检查接口返回的数据是否与预期结果一致。
2)检查接口的容错性,假如传递数据类型错误时是否可以处理。
3)接口参数的边界值。
4)接口的性能,接口处理数据的时间也是测试的一个方法。涉及内部算法与代码的优化。
5)接口的安全性,特别是外部接口,如银联接口、支付宝接口等待。
接口测试流程
拿到接口API文档(没有文档的话通过抓包工具获取),熟悉接口业务,接口地址,鉴权方式,入参、出参,错误码等;
设计接口测试用例以及评审;
思路:
- 正例:输入正常入参,接口能够成功返回数据;
- 反例:
- 鉴权反例:鉴权码为空,鉴权码错误,鉴权码过期等;
- 参数反例:参数为空,参数类型异常,参数长度异常等;
- 错误码覆盖:根据业务而定的;
- 其他错误场景:接口调用次数限制,接口黑名单,分页场景等;
使用接口测试工具执行接口测试,例如Postman、Jmeter等;
通过Jenkins实现持续集成,并输出测试报告发送邮件,例如Postman+Newman+Jenkins等;
HTTP协议
HTTP:Hyper Text Transfer Protocol 超文本传输协议,是一个基于请求与响应模式的、应用层的协议,也是互联网上应用最为广泛的一种网络协议。目前最常用的版本是HTTP1.1版。
HTTP协议的完整请求
HTTP是应⽤层的协议,它不需要刻意的去关注底层⽹络传输层协议的东⻄。在整体应⽤层的协议中,通俗的说在整个API的测试维度上,需要关注的是⼀个完整的HTTP请求流程,请求⽅法,请求头响应头,COOKIE请求流程,SESSION的请求流程和TOKEN的请求流程,以及HTTPS的请求流程。
网络七层协议OSI的7层从上到下分别是: 7 应用层 6 表示层 5 会话层 4 传输层 3 网络层 2 数据链路层 1 物理层 ;其中高层(即7、6、5、4层)定义了应用程序的功能,下面3层(即3、2、1层)主要面向通过网络的端到端的数据流。
TCP/IP协议集,包含在上面的七层结构中,含有4层:链路层、网络层、传输层和应用层。(链路层包括控制操作系统及硬件的驱动程序等;网络层包括常用的IP协议;传输层包括TCP协议和UDP协议等;应用层包括HTTP、FTP、DNS等协议)
TCP/IP通信数据流如下图所示:![]()
TCP协议是应用层的协议,提供可靠的连接服务,采用三次握手确认建立一个连接。具体信息为Client端发送连接请求报⽂,Server端接受连接后回复ACK报⽂,并为这次连接分配资源。Client端接收到ACK报⽂后也向Server段发⽣ACK报⽂,并分配资源,这样TCP连接就建⽴了。
三次握⼿具体为:
- 第⼀次握⼿:起初两端都处于CLOSED关闭状态,Client将标志位SYN置为1,随机产⽣⼀个值seq=x,并将该数据包发送给Server,Client进⼊SYN-SENT状态,等待Server确认;
- 第⼆次握⼿:Server收到数据包后由标志位SYN=1得知Client请求建⽴连接,Server将标志位SYN和ACK都置为1,ackn=x+1,随机产⽣⼀个值seq=y,并将该数据包发送给Client以确认连接请求,Server进⼊SYN-RCVD状态,此时操作系统为该TCP连接分配TCP缓存和变量;
- 第三次握⼿:Client收到确认后,检查ackn是否为x+1,ACK是否为1,如果正确则将标志位ACK置为1,ackn=y+1,且将seq=x+1,此时操作系统为该TCP连接分配TCP缓存和变量,并将该数据包发送给Server,Server检查ackn是否为y+1,ACK是否为1,如果正确则连接建⽴成功,Client和Server进⼊ESTABLISHED状态,完成三次握⼿,随后Client和Server就可以开始传输数据。
TCP的标志位:
- SYN (synchronous建立联机)
- ACK (acknowledgement 确认)
- seq (Sequence number 顺序号码)
- ackn (Acknowledge number确认号码) (其他资料都是ack,这里为跟方便区分ACK所以写成了ackn)
状态的意义:
- LISTEN - 侦听来自远方TCP端口的连接请求;
- SYN-SENT -在发送连接请求后等待匹配的连接请求;
- SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认;
- ESTABLISHED- 代表一个打开的连接,数据可以传送给用户;
以上是建立连接的三次握手。关联连接还需要进行四次挥手。四次挥手这里不再讲述,自行补充。(今后面试的时候可能会被问到)
完整的HTTP请求流程如下:

- 客户端与服务端之间建⽴TCP的连接请求(三次握手)
- 客户端向服务端发送Request的请求
- 服务端Response相应回复给客户端
- 客户端与服务端之间关闭TCP的连接请求(四次挥手)
需要明确的是客户端向服务端发送请求的过程中,这⾥的客户端不单纯的WEB,它包含了⼿机,PC以及请求模拟工具等。
HTTP协议的特点
支持客户端/服务器模式
客户/服务器模式工作的方式是由客户端向服务器发出请求,服务器端响应请求,并进行相应的服务;
简单快速
客户想服务器请求服务时,只需传送请求方法、路径及参数;
请求方法常用的有GET、POST、DELETE、PUT等,每种方法规定了客户端与服务器端联系的类型不同;
灵活
HTTP允许传输任意类型的数据对象;
正在传输的类型由Content-Type加以标记(Content-Type是HTTP中用来表示内容类型的标识);
无连接
无连接的含义是限制每次连接只处理一个请求;
服务器处理完客户的请求,并收到客户的应答后,即断开连接;
采用这种方式可以节省传输时间;
无状态
HTTP协议是无状态协议。无状态指协议对于事务处理没有记忆能力。缺少状态,意味着如果后续处理需要前面的信息,则必须重新传输,这样可能导致每次连接传送的数据量增大;相反,若服务器不需要先前传送的信息时,应答就会很快;
常用的HTTP请求方法
HTTP/1.1 定义的请求方法有9种:GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE、CONNECT。最常的两种GET和POST,如果是RESTful接口的话一般会用到GET、POST、DELETE、PUT。
请求方法 | 描述 |
---|---|
GET | 请求指定的页面信息,并返回实体内容 |
POST | 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致心的资源的建立和/或已有资源的修改。 |
HEAD | 类似于GET请求,只不过返回的响应中没有具体内容,用于获取报头 |
PUT | 从客户端向服务器传送的数据取代指定的内容,即向指定的位置上传最新的内容。 |
PATCH | 对PUT方法的补充,用来对已知资源进行局部更新。 |
DELETE | 请求服务器删除Request-URL所标识的资源 |
TRACE | 回显服务器收到的请求,主要用于测试或诊断。 |
CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器 |
OPTIONS | 返回服务器针对特殊资源所支持的HTML请求方式,或允许客户端查看服务器的性能 |
a. GET
GET方法要求服务器将URL定位的资源放在响应报文的数据部分,会送给客户端。使用GET方法时,请求参数和对应的值附加在URL后面,利用一个问号‘?’代表URL的结尾与请求参数的开始,传递参数长度受限制(1024)。例如,/index.jsp?id=100&op=bind。通过GET方式传递的数据直接放在地址中,所以GET方式的请求一般不包含“请求体”部分,请求数据以地址的形式表现在请求行。地址中‘?’之后的部分就是通过GET发送的请求数据,各个数据之间用‘&’符号隔开。显然这种方式不适合传送数据的安全性得不到保障。
b. POST
允许客户端给服务器提供信息较多。POST方法将请求参数封装在HTTP请求数据中,以名称/值的形式出现,可以传输大量数据,这样POST方式对传送的数据大小没有限制,而且也不会显示在URL中。POST方式请求行中不包含数据字符串,这些数据保存在“请求体”部分,各数据之间也是使用‘&’符号隔开。POST方式大多用于页面的表单中。
HTTP之URI、URN与URL关系
- URI :Universal Resource Identifier 统一资源标志符,用来标识抽象或物理资源的一个紧凑字符串
- URL :Universal Resource Locator 统一资源定位符,一种定位资源的主要访问机制的字符串,一个标准的URL必须包括:protocol、host、port、path、parameter、anchor
- URN :Universal Resource Name 统一资源名称,通过特定命名空间中的唯一名称或ID来标识资源
简单理解:URI是某个人,URL是这个人的具体地址,URN是这个人的名字或身份证号码。
URI是网络上某个具体的资源(可能是硬件资源,也可能是软件资源),URL是这个资源的详细访问地址,而URN是这个资源的名字。
URL的组成:
<协议>://<主机>:<端口号>/<路径>?<参数>&<参数>
其中,端口号、路径及参数有时可以省略(HTTP默认端口号是80)

常用状态码
当客户端向服务端发送⼀个请求后,服务端响应回复返回给客户端,在返回的信息中会包含⼀个HTTP请求头的状态码信息⽤以响应客户端的请求。在⽹站https://http.cat中可以看⻅各个不同表情的状态码的显示,如调⽤https://http.cat/504就会显示如下对应的信息。常⽤的状态码具体为:
- 200 请求成功
- 301 永久重定向
- 302 临时重定项
- 400 Bad Request 客户端请求错误
- 401 Unauthorized
- 403 Forbidden
- 404 请求的资源不存在
- 405 不被允许的请求⽅法
- 500 服务器内部错误
- 504 GateWay Timeout
HTTP请求的完整语法格式
- 由客户端发送给服务器端
- 规定了发送给服务器的数据语法格式

HTTP请求由四部分组成:请求行,请求头,空行,请求体

a. 请求行
* 作用: 指定请求方法、请求资源
* 语法格式:请求方法(空格)URL(空格)协议版本(\r\n)
* 请求方法:GET、POST等前文已经描述;
* URL:协议://域名:端口号/资源路径?查询参数&查询参数&...
* 协议版本:http1.1/http1.2/http2.0 (当前主要使用的是http1.1版本)
b. 请求头
- 作用:向服务器描述客户端(浏览器)的基本信息
- 语法格式:key:value键值对
Accept: 浏览器可接受的MIME(媒体)类型;(Accept: text/plain)
Accept-Charset: 浏览器可接受的字符集;(Accept-Charset: utf-8)
Accept-Encoding: 浏览器可以处理的编码方式;(Accept-Encoding: gzip)
Accept_Language: 浏览器接收的语言;(Accept-Language: zh-CN)
Connection: 表示十分需要持久连接,HTTP1.1版本默认的值是“keep-Alive”
==Content-Type==: 向服务器描述请求体的数据类型;
==Cookie==: 维持当前会话必须的key=value
==User-Agent==: 向服务器描述客户使用的操作系统、浏览器等的版本信息
Host: 被请求的服务器的域名或ip,若不是默认的80端口,还会加上端口号
Referer: 标识这个请求时从哪个页面发送过来的
c. 请求体
- GET、DELETE 请求方法,没有请求体
- POST、PUT请求方法,有请求体
- 请求体的数据类型,受请求头中 Content-Type的值影响
HTTP响应的完整语法格式
- 由服务器回发给客户端
- 规定了服务器回发给客户端的数据的语法格式

HTTP响应由四部分组成:状态行,响应头,空行,响应体

a. 状态行
协议版本:默认是HTTP/1.1
状态码:针对http请求的响应状态
状态描述:对状态码的说明
b. 响应头
- 作用:向客户端描述服务器的基本信息;
- 语法:k:v键值对
- ==Content-Type==: 向客户端描述响应体的数据类型
c. 响应体
- http响应体也叫响应报文,绝大多数是都有响应体的
- 响应体的数据类型,受响应头中Content-Type的值影响
Content-Type
Content-Type,用于定义网络文件的类型和网页的编码,决定浏览器将以什么形式、什么编码发送请求或接收返回数据。最常见的Content-Type有如下四种:
application/x-www-form-urlencoded
表单数据被编码为名称/值对。是默认的标准编码格式application/json
消息主体是序列化后的JSON字符串multipart/form-data
在表单中进行文件上传时,需要使用此格式text/plain
数据以纯文本形式(text/json/xml/html)进行编码,其中不含任何控件或格式字符
Cookie
由于HTTP协议是无状态协议,比如登录电商系统,购买商品A,由于HTTP协议的无状态特点,无法区分登录的账号与购买商品A的账号是同一个,这就引入了Cookie。在保留无状态协议这个特征的同时又要解决类似记录状态的矛盾问题。Cookie 技术通过在请求和响应报文中写入Cookie 信息来控制客户端的状态。Cookie 会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息,通知客户端保存Cookie。当下次客户端再往该服务器发送请求时,客户端会自动在请求报文中加入Cookie 值后发送出去。服务器端发现客户端发送过来的Cookie 后,会去检查究竟是从哪一个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前的状态信息。
Cookie总是保存在客户端中,按在客户端中的存储位置,可分为内存Cookie和硬盘Cookie。内存Cookie由浏览器维护,保存在内存中,浏览器关闭后就消失了,其存在时间是短暂的。硬盘Cookie保存在硬盘里,有一个过期时间,除非用户手工清理或到了过期时间,硬盘Cookie不会被删除,其存在时间是长期的。所以,按存在时间,可分为非持久Cookie和持久Cookie。
Cookie的交互过程
没有登录状态时,进行登录操作的请求报文(没有登录Cookie信息的状态)
进行登录操作时的响应报文(Set-Cookie,添加登录状态Cookie)
访问系统的其他页面,Cookie中已经带上了登录状态的Cookie
SESSION
Session是另一种记录客户状态的机制,不同的是Cookie保存在客户端浏览器中,Session保存在服务器上。客户端浏览器访问服务器的时候,服务端把客户端信息以某种形式记录在服务器上,这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。如果说Cookie机制是通过检查客户身上的”通行证”来确定客户身份的话,那么Session及时就是通过检查服务器上的”客户明细表”来确认身份。Session相当于程序在服务器上建立的一份客户档案,客户来访时只需要检查客户的档案表就可以了。
TOKEN
Token顾名思义就是令牌、凭证、钥匙,只有这把钥匙,你才能打开门。Token一般都是服务端生成,比如一个web系统,用户登录的时候,服务端校验用户名密码通过以后,会生成一个token,同时会生成refreshToken和一个过期时间,然后将refreshToken和token返回给客户端,客户端会将token保存下来,后续所有的请求都会携带这个token。服务端会判断当前token是否存在已经是否过期。如果token不存在或者过期就会拒绝本次请求。如果token过期了,就用refreshToken刷新时间,当然这里可能还有别的方案。比如只生成token,每次请求的时候都刷新过期时间。如果长时间没有刷新过期时间,那token就会过期。
接口测试维度
单接口测试
单接口测试的重点是保证该接口的正确性和健壮性,测试维度总结有如下几点:
- 验证必填参数是否为空
- 验证参数的数据类型是否做了校验
- 验证参数的字段长度是否做了校验
- 接口的安全性校验和性能校验
对单个API的测试,如果测试的API涉及到支付与金钱有关及重要的敏感数据信息的接口,都需要考虑API的安全测试,可以从下面几个维度来思考,分别是:
- 是否增加了防爬虫的机制
- 是否增加了请求次数的限制
- 是否增加了对应的请求头信息
- 是否增加了鉴权的认证信息
- 是否对请求进行了加密
- 是否对接口做了防SQL注入处理
- 是否在被请求的服务端增加了IP的限制
多接口测试
单个接⼝测试是必要的,但是⽆法保障到全链路的产品质量保障,所以需要基于产品全链路的质量保障,也就是业务场景的测试,简单的说就是通过API的测试技术,模拟⼈的操作⾏为,实现产品业务场景的覆盖,这种覆盖包含了产品正常的业务逻辑以及异常的程序逻辑判断。在基于业务场景的测试中,需要考虑的是参数上下关联的解决⽅案和思路。比如登录了某个系统获得登录的用户token,然后将token添加到后续的接口请求参数中进行创建任务,创建任务后,获取到任务ID,将任务ID传递个下一个接口,进行任务列表或任务详情接口的验证等。
OPEN API测试
在实际的⼯作场景中,经常涉及到对应和第三⽅公司的对接,或者说公司提供给第三⽅公司的API,这样的API我们称呼为开放平台,也就是Open API。针对开放平台,本质上我们可以理解为“赋能”。open api都是有加密的⽅式的,⼀般业界都是有统⼀的标准来进⾏加密。
接口测试的思路
在⼀个完整的API测试⽤例编写中,需要考虑到每个测试点的初始化,测试步骤,测试断⾔以及清理的操作,在常⽤的单元测试框架中都已经提供了这部分的信息,如在Python的技术栈中常使⽤的测试框架Pytest
和unittest
都提供了这部分的思路和知识体系。
接口测试用例设计
a. 接口测试用例设计主要考虑的因素
- 请求参数的必填项和可选项;
- 请求参数的合法输入和非法输入;
- 请求参数的边界值;
- 请求参数的异常处理;
- 基于业务场景的考虑,登录状态、权限等;
接口测试用例设计的方法与手工功能测试用例的设计的方法及思路是一致的,这里不再扩展介绍。
b. 接口测试用例的模板

c.接口测试用例的示例
