本节大纲
- 接口测试概述
- 通信协议原理解析
- HTTP与HTTPS协议讲解
- HTTP之cookie、session、token解析
01.接口测试概述
接口测试定义
接口 是前后端沟通的桥梁，是数据传输的通道，包括外部接口、内部接口。内部接口又包括：上层服务与下层服务接口，同级接口
生活中常见接口：电脑上的键盘、 USB 接口，电梯按钮， KFC 下单
接口测试 ：是对系统或组件之间的接口进行测试，主要校验数据的交换、传递和控制管理 过程，以及相互逻辑依赖关系
接口自动化测试 ：让程序代替人为对接口项目进行自动化验证测试的过程
接口测试是一种功能测试：只要管输入数据后得到的输出结果是怎么样的 -- 功能测试
接口测试也是一种自动化测试：从接口测试的执行方式来说，接口必须要借助工具来实现
性能测试： jmeter--> 接口 --> 对接口进行压测 -- 》接口性能测试
接口测试意义
接口测试使 ” 测试更早投入 ” 这句话变成现实
接口测试可以测试一些界面测试非常难以实现或无法测试的范围
从对项目的影响，接口测试直接测试后端服务，更加接近服务器上运行代码，也更能发 现影响范围广泛的bug
接口测试更容易和自动化测试系统相结合
总结：熟练接口测试，能够独立搭建接口测试框架是测试工程师能力分水岭的体现
接口测试的实现
实现方式：
1. 使用接口测试 工具 来实现，比如 jmeter,postman
2. 通过编写代码来实现，比如 python+requests
两者比较
1. 接口工具：更容易上手；测试数据不好控制；不方便测试加密接口；扩展能力不足
2. 代码实现：比较难；测试数据容易控制；可以使用加密函数对接口加密；容易扩展
02.通信协议原理解析
接口测试的原理
接口测试是基于 协议 进行测试的，实际上是黑盒测试，基本的测试思路是 通过输入和输
出来判断被测系统或对象的逻辑是否符合用户需求 。
原理：客户端发送网络请求 -- 》 API 网关（阿里云， apache,IIS,nginx ） -->services
03.HTTP与HTTPS协议讲解
HTTP协议
HTTP 协议是 Hyper Text Transfer Protocol （ 超文本传输协议 ）的缩写；
是用于从万维网（ www ）服务器传输超文本到本地浏览器的传送协议
HTTP 是一个基于 TCP/IP 通信协议（建立连接 -3 次会话 - 断开连接 -4 次会话 ) 来传递数据（ HTML 文件、 图片、查询结果等）
HTTP特点：
简单快速、灵活、 无状态、无连接
无连接：限制每次连接时处理一个请求
无状态：对于事务处理没有记忆能力 。缺少状态意味着如果后续处理需要前面的信息，则必须
要重传，这样可能导致每次传输的数据量增大。
HTTP工作原理
HTTP 协议工作于客户端 / 服务端（ C/S ）架构上，比如浏览器作为客户端通过 url 向服务器 （web 服务器）发送所有请求。 web 服务器根据接收到的请求后，想客户端发送响应信息。
web 服务端有：阿里云 ,apache,IIS,nginx
HTTP 默认端口为 80 ，也可以自定义修改
HTTP组成
http 消息是服务器和客户端之间交互数据的方式。有两种类型的消息：
1. 请求 ：由客户端发送，用来触发一个服务器上的动作
请求由三个部分组成： 请求行、请求头、请求体
2. 响应 ：来自服务器的应答
响应也由三个部分组成： 状态行、响应头、响应正文
HTTP请求组成
http 请求（ request ）一般由三部分构成：
1. 请求行（request line ）
2. 请求头部(request header)
3. 空行
4. 请求体（request body ）
请求行
请求行（ request line ） ：一般指请求包中第一行内容。
通常包含以下信息：
1. 请求方法 （ request method ）：重点（ get/post/head 。。。）
2. 请求路径 （ request path ）：就是 URL 的 PATH 部分
3. 协议版本 （ protocol/version ）：包括协议和版本号
请求方法
请求方法（ request method ）： http 协议里定义了一些请求的方法，这些方法可以进一 步定义请求的目的，比如是获取资源还是提交资料还是删除资源， 常用的是 get ， post
请求头
请求头部：紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息 , 主要是为了去完成通信的控制
请求头的名称（类型）都是由 http 协议提前约定好的，具有特定的通信效果的，一般不 能自定义
请求头含义解释： https://jingyan.baidu.com/article/375c8e19770f0e25f2a22900.html
请求体
请求体：请求主体。是指第一个空行之后的内容，可以添加任意的数据。 比如说get方法，一般来说 body 就是空的。 post 方法才会产生 body 内容。
注意：请求头部后面的空行是必须的，即使第四部分的请求数据为空，也必须有空行
post请求参数传递方式总结
post 请求的参数是在 body 中传递，有多种传值方式，需要根据头部参数的 Content-Type 的 值来确定选择哪种方式传值。
Content-Type 取值与 body 传值方式对应关系
HTTP响应组成
HTTP 响应也由四个部分组成 :
1. 状态行 (response line)
2. 消息报头/ 响应头 （ response header ）
3. 空行
4. 响应正文/ 响应报文 （ response body ）
状态行
状态行 : 通常就是响应数据包中的第一行 。
由 HTTP 协议 / 版本号， 状态码， 状态消息 三部分组成
状态码
状态代码（ HTTP Status code ）：由三位数字组成，第一个数字定义了响应的类别，共分
五种类别 :
常见状态码
常见状态代码：
1. 200-请求成功
2. 301-资源被永久转移到其他 url
3. 404-请求的资源（网页）不存在
4. 500-内部服务器错误
状态码汇总
响应头
消息报头：第二行和第三行为消息报头，用来说明客户端要使用的一些附加信息。例如 服务器类型，响应报文格式。
1. Date:生成响应的日期和时间
2. Content-Type:指定了内容的数据类型 HTML(text/html) Charset: 编码类型是 UTF-8
响应头参数说明
响应正文
响应正文：空行后面的 html 部分为响应正文。表示服务器返回给客户端的文本信息。
注意：消息报头后面的空行是必须的，即使第四部分的返回数据为空，也必须有空行
04.HTTP之cookie、session、token解析
HTTP无状态处理方案
http 协议本身是无状态的 , 但是在实际的 web 开发中常有一些操作需要有状态。比如想要 访问一些私人访问权限的文章, 或者这种操作需要明确当前用户身份。
显然，最简单的方案就是每次都发送账户和密码，但是这样重复操作用用户并不友好， 对服务器页增添了额外的压力。为了解决无状态带来的鉴权问题, 一般有以下几种解决方 案:cookie 、 session 、 token
Cookie
Cookie 是储存在客户端的一串字符，一般说来大小不超过 4kb 。比如我们常见的记住密码功能，或者 一些基于之前输入的提醒和默认配置，就是通过cookie 来实现的。
cookie 简单说来就是一种 本地存储方法 。但是这里 存储的信息常用来进行鉴权操作（状态信息）
cookie 只能保存文本信息，浏览器可以禁止 cookie 。 cookie 的期限可以被自由设定，可以是仅仅一次浏 览起效，也可以长达一年。如果是短期的，那么这些信息会被存储在内存中，如果是长期则会存储在 硬盘上。
问题：单纯的采用 cookie 来 认证身份 会带来一个比较麻烦的问题，就是 伪造比较容易 。因为这样处理， cookie中必然要带有身份信息，但是服务器也要解析这个身份信息，所以必然要在原理上支持双向的 编码和解码，那么这个信息很容易被破解和进一步伪造。
Cookie
Session
如果想要解决上述 cookie 伪造的这个问题 , 我们常用的方案应该是加一个 secret ，而这个 secret 应该是 放在服务器上的，服务器返回这样一个带有secret 编码的字符串，而在服务器端再带上这个 secret 反 向解密，如此一来，问题不就解决了，这个就是我们要讲的第二个对象: session 。
session 是保存在服务器端的，是跟踪用户的一种上下文保持的机制 。当服务器创建了一个 session 时， 就给客户端发送的响应头中包含了 set-cookie 字段 。浏览器会将 set-cookie 的字段信息，将其保存在本 地，并且之后发送的请求报文都包含了 cookie ， cookie 中包含了 set-cookie 返回的字段值。
Session 也可以设定有效时间。
session
Token鉴权
定义：访问令牌 access token, 用于接口中，用于标识接口调用者的身份、凭证。简单来说就是不要登 录。
目的：减少用户名和密码的传输次数
token类型：
1. API Token(接口令牌 ) ：用于访问不需要登录的接口
2. USER Token(用户令牌 ) ：用于访问需要用户登录之后的接口
3. Token的实效性： token 可以是一次性的、也可以在一段时间范围内是有效的
4. Token一般放在请求头 headers 或者 body 参数里面。 -- 一般在接口文档会有说明
Token鉴权流程
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：
1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个 Token ，再把这个 Token 发送给客户端
4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
6. 服务端收到请求，然后去验证客户端请求里面带着的 Token ，如果验证成功，就向客户端返回
请求的数据
微信搜一搜【程序员阿沐】关注这个文绉绉的程序员，这样的干货内容还有近百篇。关注后主页点击【领取资料】有我准备的一线大厂面试资料和简历模板，希望大家都能找到心仪的工作，学习是一条时而郁郁寡欢，时而开怀大笑的路，加油。如果你通过努力成功进入到了心仪的公司，一定不要懈怠放松，职场成长和新技术学习一样，不进则退。如果有幸我们江湖再见！
————————————————
分享的内容如果对你有帮助记得点赞让更多的朋友看到！这个对我很重要！
————————————————