接口测试理论
API测试：（接口测试）
技术栈：协议
测试工具 （postman、jmeter）
接口测试的框架
MockServer
金字塔模型：
在金字塔的模型中：
1、金字塔模型把开发测试的模型分为三层，分别是单元测试，接口测试，和UI测试
2、unit:单元测试 services:接口测试（API自动化测试） UI：UI测试(功能测试,ui自动化测试)
3、越底层的，越应该投入更多的精力去保障，越上层的，投入少量的精力去保障
在金字塔的模型中，在测试分为三个维度来进行思考，分别是单元，服务和UI三个层级。这地方主要的说下服务层 的测试，在服务层的测试维度中，主要针对的是业务接口的测试，来验证接口功能是否完整，如内部逻辑，异常处 理。这样的目的是验证接口它是否稳定，所以接口的测试相对而言比较容易而且更加高效,测试用例的维护成本也 低。有很多主流的测试工具都可以做接口测试，如PostMan,JMeter,SoupUi等，除了工具还有在Python语言中很多 的第三方的库都是可以来做接口测试的，如:urllib,requests,aiohttp等。
架构：
1、单体架构
2、分布式架构
3、微服务的架构
单体架构：
微服务的架构通信模式：
微服务的通信模式使用的方式有两种：
1、一种是采用基于REST API的轻量级的基于HTTP的协议
2、使用的是gRPC的协议
微服务架构就是根据业务场景，把每个独立的业务场景单独分离成一个服务，这样服务和服务之间通信，通信通过REST API 或者gRPC的协议来进行交互。
服务和服务之间需要进行通信和调用：
1、同步通信模式
2、异步通信模式
1.同步通信：容易延迟和堵塞在客户端与服务端在进行交互的时候，通信模式主要分为同步通信和异步通信。同步通信简单的可以理解为客户端发送请求给服务端，服务端必须得回应客户端的请求。所以同步通信它存在如下的缺点，具体为:
容易超时，客户端发送请求后，服务端迟迟没有回应客户端的请求
如果请求是存在大的计算量和逻辑存在问题，就会导致请求堵塞，后面的都积压
2.异步通信：在异步的交互中，客户端和服务端互相不需要关注对方的存在，只需要关注对应的MQ的消息，客户端与服务端的交互主要是会通过MQ的消息中间作为消息的 传递来进行交互的
常规开发模式中接口测试的场景：
开发同学：
1、前端程序员把代码写完，后端程序员把代码写完
2、前端和后端进行联调（前端把输入的账户和密码拿到，然后发送给(HTTP的协议)后端）
3、后端拿到前端发送的数据进行验证
测试同学：
1、验证这个过程中业务逻辑是否能够成功
协议
1、http协议
http是一个无状态的协议，但是互联网产品的发展，需要记住用户的操作行为习惯。
1.1 http协议的版本
HTTP协议，也可以称呼为“超文本传输协议”。
HTTP协议是为知识共享而诞生，因为有了HTTP的协议，然后有了 WEB1.0时代和WEB2.0的时代
HTTP/1.1
1997年发布的HTTP/1.1的版本是目前比较主流的HTTP的版本，很遗憾的是从HTTP/1.1的版本之后，就一直停止不 前，而且目前一直使用的也是HTTP/1.1的版本。
HTTP/2.0
新一代的HTTP协议是HTTP/2.0的版本，它支持流式的处理，以及进行了很多的优化，但是很遗憾的是没有被大规 模的应用。在分布式架构以及微服务架构中，基于新一代的架构设计有了gRPC的协议，它就是基于HTTP/2.0的版 本来进行设计的。
1.2 http一个完整的请求流程
客户端与服务端建立tcp连接
客户端向服务端发送request请求（请求地址、请求方法、请求参数、请求头）
服务端response响应回复给客户端（协议状态码、响应数据、响应头）
客户端与服务端关闭tcp连接
2、websocket:持久连接
websoket协议（auth2.0）：
客户端：拿微信来说，手机微信，电脑微信，都是客户端
服务端：腾讯的微信服务器
客户端与服务端始终保持持久连接 不会断开
3、gRPC：远程过程调用（调用远程的服务感觉像调用自己本地的服务一样快）
主要应用分布式架构 基于HTTP2.0来设计
网络分层
TCP/IP分层管理
TCP/IP协议按层次主要为:应用层，传输层，网络层，数据链路层。
TCP/IP通信传输流
下面具体还是以流程图来描述这部分，具体如下:
1.应用层
应用层决定了向用户提供应用服务时通信的活动。而HTTP的协议就是属于应用层的协议。
http和grpc都是应用层的协议
2.传输层（保障数据安全）
传输层 ：核心的协议就是TCP/IP的协议
应用层的下层是网络传输层，提供处于网络连接中的两台计算机之间的数据传输。
3.网络层
主要是用来处理网络上流动的数据包，所谓数据包就是网络传输中的最小单位，在该层协议中，规范了通过怎样的路径到达目标计算机，并且把数据包传送给对方。
4.链路层
主要是处理连接网络的硬件部分，如操作系统，硬件设备的驱动等。
三次握手
为了确保把数据能够送到目标的服务器，TCP协议内部使用了三次握手的策略机制，也就是说在TCP协议中，TCP 把数据包送去后，TCP会进行确认对方是否收到，或者是确认是否成功送达，那么三次握手主要使用了TCP的标 志，具体为:SYN和ACK。首先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，ack=x+1，随机产生一个值seq=y，并将该数据包发送给Client以确认连接请求，Server进入SYN-RCVD 状态，此时操作系统为该TCP连接分配TCP缓存和变量;
第三次握手:Client收到确认后，检查ack是否为x+1，ACK是否为1，如果正确则将标志位ACK置为1， ack=y+1，并且此时操作系统为该TCP连接分配TCP缓存和变量，并将该数据包发送给Server，Server检查ack 是否为y+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握 手，随后Client和Server就可以开始传输数据。
为什么会有三次握手的设计？
应用层的协议是为了上层应用之间的交互，但是不需要关注底层网络传输层之间的事情，那么问题来了？应用层既然不关注网络传输层的事情，网络传输层怎么保障应用层之间数据的传输？所以为了数据传输的安全和保障，就设计了三次握手。
1、服务端的确认：客户端发送数据出去，服务端需要确认我收到了
2、服务端反馈：服务端告诉客户端，你发送的数据我这边确认收到了
3、客户端确认：客户端需要向服务端再次反馈，客户端收到服务端的反馈了
URI和URL
URI可以称为统一资源标识符，而URL是统一资源定位符
URL表示的资源的地点。
HTTP协议中使用URI定位到互联网上的资源，这也是为什么互联网任意位置的资源我们都能够获取到的原因。
持久连接 （keep-alive）
在HTTP的早期版本中，每次发送请求，都需要进行一次TCP的连接和断开，很明显这对服务端的性能损耗是非常大 的，同时也是增加了通信量的开销。在HTTP/1.0版本开始以及后面的版本中，有了持久连接，也就是keep-alive， 它的特点是只要客户端或者是服务端没有明确断开连接，那么就得一直保持TCP的连接请求，持久连接减少了TCP 连接的重复连接和断开造成的性能损耗，减轻了服务端的负载，也提升了整体相求响应时间的性能。
常用请求方法
在HTTP的应用层协议中，常用的请求方法具体为GET,POST,PUT,DELETE的请求方法，具体如下所示:
请求头/响应头
常用请求数据格式：
常用协议状态码
当客户端向服务端发送一个请求后，服务端响应回复返回给客户端，在返回的信息中会包含一个HTTP请求头的状态码信息用以响应客户端的请求。在网站https://http.cat中可以看⻅各个不同表情的状态码的显示，如调用https://http.cat/504就会显示如下对应的信息。常用的状态码具体为:
- 200 请求成功
- 301 永久重定向
- 302 临时重定项
- 400 Bad Request 客户端请求错误
- 401 Unauthorized （无权限访问该系统）
- 403 Forbidden （有权限但是禁止访问）
- 404 请求的资源不存在
- 405 不被允许的请求方法
- 500 服务器内部错误
- 504 GateWay Timeout （网关超时）
COOKIE
1.cookie是什么？
cookie:主要是存储用户操作行为的数据，在早期的互联网产品中，用户登录系统的凭证都是由cookie来进行记录的，但是由于是存储在客户端的（本机的电脑），所以是不安全的，基本目前登录认证的凭证不会再使用cookie的技术了
2.COOKIE请求流程：
SESSION
2、登录成功后，会在服务端把用户登录成功后的信息生成一个sessionid的凭证，并且存储在服务端
3、然后服务端通过响应头中的set-cookie把生成的sessionid返回给客户端
4、客户端再次查看个人主页，客户端会通过请求头中的cookie，把set-cookie返回的sessionid带上，发送给服务端
5、服务端接收到客户端发送的sessionid，和存储在服务端的session ID作一个对比
6、如果对比一致，用户可以继续反问系统的任何功能，如果对不一致，立刻跳转到登录的页面
2.cookie和session的区别：
由于cookie是存储在客户端的，它不安全，所以session是把登录成功后的数据存储在服务端
TOKEN
1.token是什么？
token本质上是session的原理实现的，我们可以把它理解为一个令牌，每次登录成功后，返回的token都是随机的字符串 token是通过jwt的技术来实现
2.token请求流程：
1、客户端输入账户和密码，点击登录
2、登录成功后，会在服务端把用户登录成功后的信息生成一个Token的凭证，同时了存储在服务端
3、服务端会通过响应数据或者是响应头中的set-cookie返回给客户端
4、那么客户端再次向服务端发送请求，会在请求参数或者请求头中的Authuration中带上返回来的token发送给服务端
5、服务端接收到客户端发送的Token，和存储在服务端的Token作一个对比
6、如果对比一致，用户可以继续反问系统的任何功能，如果对不一致，立刻跳转到登录的页面
HTTPS（超文本传输安全协议）
HTTP的协议它是存在缺陷的，这些缺陷主要为:
通信内容是明文，内容很可能被第三方获取到不验证通信方的身份信息，容易被伪装无法证明请求头的完整性
基于HTTP存在这些缺陷，也就有了HTTPS的协议，我们可以把HTTPS可以汇总为:HTTPS=HTTP+加密+认证+完整性保护。
基于这样一层的设计，相对来书还是比较安全的，HTTPS不是全新的协议，它只是HTTP的协议基础上新增SSL和 TLS。在前面中我们知道HTTP是和TCP直接通信，那么在HTTPS中，HTTP先和SSL通信，SSL再和TCP来进行通信。
- BASIC认证，也就是基本认证
- DIGEST认证，也就是摘要认证
- SSL客户端认证
- FormBase认证，也就是基于表单认证
BASIC
