接口测试
1、接口测试技术栈：
1.1、协议
1.2、接口测试的工具:PostMan,JMeter
1.3、接口测试的框架
1.4、MockServer
2、接口测试是目前所有测试人员必须掌握的技术栈
2.1、流量回放
2.2、混沌工程（混沌理论）
2.3、全链路监控&分布式
2016年，前后端分离开发模式在企业全面落地
youyuxi. VUE
2019年之后，UI
1、走向了API的自动化测试
2、开发模式的彻底
2021年：
1、走向了API的自动化测试
2、开发模式的彻底
3、微服务的架构通信模式
3、单体架构的开发模式：
单体架构的模式是把前后以及所有的业务场景的代码都整合到一起
4、微服务架构模式：
4.1微服务架构就是根据业务场景，把每个独立的业务场景单独分离成一个服务，这样服务和服务之间通信，通信通过REST API 或者gRPC的协议来进行交互。
4.2常规开发模式中接口测试的场景：
4.2.1开发同学：
1、前端程序员把代码写完，后端程序员把代码写完
2、前端和后端进行联调（前端把输入的账户和密码拿到，然后发送给(HTTP的协议)后端）
3、后端拿到前端发送的数据进行验证
4.2.2测试同学：
1、验证这个过程中业务逻辑是否能够成功
https://element.eleme.cn/#/zh-CN/component/input
5、金字塔模型
在金字塔的模型中，在测试分为三个维度来进行思考，分别是单元，服务和UI三个层级。这地方主要的说下服务层 的测试，在服务层的测试维度中，主要针对的是业务接口的测试，来验证接口功能是否完整，如内部逻辑，异常处 理。这样的目的是验证接口它是否稳定，所以接口的测试相对而言比较容易而且更加高效,测试用例的维护成本也 低。有很多主流的测试工具都可以做接口测试，如PostMan,JMeter,SoupUi等，除了工具还有在Python语言中很多 的第三方的库都是可以来做接口测试的，如:urllib,requests,aiohttp等。
5.2在金字塔的模型中：
1、金字塔模型把开发测试的模型分为三层，分别是单元测试，接口测试，和UI测试
2、unit:单元测试 services:接口测试（API自动化测试） UI：UI测试(功能测试,ui自动化测试)
3、越底层的，越应该投入更多的精力去保障，越上层的，投入少量的精力去保障
saas化：Software As A Service 软件即服务
pass化：Platform As A Service 平台即服务
6、http:“超文本传输协议”（HTTP是应用层的协议）
目前HTTP最新的版本是：HTTP/2.0(gRPC的协议就是基于HTTP/2.0的版本来进行设计的) 但是业界使用的版本是HTTP/1.1
6.1微服务的架构通信模式：
6.1.1微服务的通信模式使用的方式有两种：
1、一种是采用基于REST API的轻量级的基于HTTP的协议
2、使用的是gRPC的协议
6.2数据：文字和声音，当然还有其他的
TCP/IP分层管理
TCP/IP协议按层次主要为:应用层，传输层，网络层，数据链路层。
6.3应用层
应用层决定了向用户提供应用服务时通信的活动。而HTTP的协议和gRPC的协议就是属于应用层的协议。
6.4传输层
应用层的下层是网络传输层，提供处于网络连接中的两台计算机之间的数据传输。
6.5网络层
主要是用来处理网络上流动的数据包，所谓数据包就是网络传输中的最小单位，在该层协议中，规范了通过怎样的
路径到达目标计算机，并且把数据包传送给对方。
6.6链路层
websocket协议：客户端与服务端始终保持持久连接 不会断开
主要是处理连接网络的硬件部分，如操作系统，硬件设备的驱动等。
6.7传输层 ：核心的协议就是TCP/IP的协议
TCP/IP通信传输流
7、三次握手
为什么会有三次握手的设计？
应用层的协议是为了上层应用之间的交互，但是不需要关注底层网络传输层之间的事情，那么问题来了？应用层既然不关注网络传输层的事情，网络传输层怎么保障应用层之间数据的传输？所以为了数据传输的安全和保障，就设计了三次握手。
1、服务端的确认：客户端发送数据出去，服务端需要确认我收到了
2、服务端反馈：服务端告诉客户端，你发送的数据我这边确认收到了
3、客户端确认：客户端需要向服务端再次反馈，客户端收到服务端的反馈了
URI可以称为统一资源标识符，而URL是统一资源定位符。URI可以理解为标识某一个互联网的资源，而URL表示的 资源的地点。
在微服务的架构模式下，使用的也是轻量级的 通信模式(REST API)，在微服务的架构模式中，需要清楚的是它的通信可以分为同步通信模式和异步通信模式， 或者更加具体本质的说就是请求/响应和异步请求/响应(发布/订阅模式)
REST API
Java：企业级开发领域具备非常强大的生命力，开发的技术栈非常完善，其中阿里的生态开发语言基本是Java
Python:数据分析，数据科学领域非常具备优势
Go:容器化的语言，应用在Docker和K8S的开发
PHP:轻量级的语言
Net:微软系列
三个语言开发，但是需要之间需要通信，需要数据传输，标准化就是REST API 使用统一的标准来进行交互
http是一个无状态的协议，但是互联网产品的发展，需要记住用户的操作行为习惯。
cookie:主要是存储用户操作行为的数据，在早期的互联网产品中，用户登录系统的凭证都是由cookie来进行记录的，但是由于是存储在客户端的（本机的电脑），所以是不安全的，基本目前登录认证的凭证不会再使用cookie的技术了
session:由于cookie是存储在客户端的，它不安全，所以session是把登录成功后的数据存储在服务端
token:本质上是session的原理，我们可以把它理解为一个令牌，每次登录成功后，返回的token都是随机的字符串 jwt的技术来实现
8、通信模式：
8.1、同步通信：
客户端发送请求给服务端，服务端必须得回应客户端的请求。
容易超时，客户端发送请求后，服务端迟迟没有回应客户端的请求
如果请求是存在大的计算量和逻辑存在问题，就会导致请求堵塞，后面的都积压
同步通信又可以说是请求/响应的模式
8.2异步通信：
1、在异步的交互中，客户端和服务端互相不需要 关注对方的存在，只需要关注对应的MQ的消息，客户端与服务端的交互主要是会通过MQ的消息中 间作为消息的 传递来进行交互的 。
所有的M Q都可以说是队列机制，也可以说是生产者消费者的模式。所谓队列机制，遵守先进先出的规则
生产者消费者模式：生产后，基于进行快速的消费
9、常用请求头
9.1发送Requests的组成部分：
1、请求地址
2、请求方法
3、请求头
Content-Type:指的是数据格式
Cookie：反爬虫，身份凭证
Referer：发送请求的地址是从哪里来的
User-Agent：发送网络请求的时候向服务端标注请求是通过什么浏览器或者什么软件(PostMan,JMeter)发送的
1、开发了一个APP，想看那个系统使用的用户比较多，统计user-agent的数据，进行分析
4、请求参数 :请求头中的数据格式决定了请求参数的格式
get: 路径参数 http://xxx.com/?name=wuya&age=18 ?key1=value1&key2=value2(get的请求参数与数据格式没任何关系)
post: payload中显示了请求的参数
9.2Response响应部分：
1、协议状态码
200 请求成功
301 永久重定向
302 临时重定项
400 Bad Request 客户端请求错误
1、请求参数不对
2、请求头不对
401 Unauthorized 无权限访问该系统
403 Forbidden 有权限但是禁止访问
404 请求的资源不存在
404NOT FOUND (请求的地址不存在，所以导致请求的资源也是不存在)
405 不被允许的请求方法
405METHOD NOT ALLOWED你请求的方法，没有定义对应的请求方法，但是你去进行访问
500 服务器内部错误
空指针 Null PointExpection 堆栈溢出 在测试选择项的时候，选择很多很多的项，同时触发，看是否会暴露该问题
OOM（内存泄露） Out Of Memory
其他异常:Expection
504 GateWay Timeout网关超时
2、响应数据
3、响应头（response headers）
content-type:指明返回的响应数据的数据格式是什么
set-cookie:服务端返回给客户端的登录凭证
10、数据格式：
10.1常用的数据格式：
1、表单 application/x-www-form-urlencoded; charset=UTF-8(GBK)
2、json格式:application/json;charset=UTF-8 json数据格式：基于JSON的数据格式，但是数据类型是字符串
3、text/html :返回的是基于html的数据格式
4、text/xml：返回的是基于xml的数据格式
请求的数据格式和响应的数据格式是独立的可以一样也可以不一样，get请求时没有数据格式
查看响应返回值。
一般情况下因为加载的数据比较多，在不知道他的响应数据时我们都需要，点击加载下一页然后慢慢一个个的去找（清理掉之前的加载数据），
一、 请求方式：
http是一个无状态的协议，但是互联网产品的发展，需要记住用户的操作行为习惯。
cookie:主要是存储用户操作行为的数据，在早期的互联网产品中，用户登录系统的凭证都是由cookie来进行记录的，但是由于是存储在客户端的（本机的电脑），所以是不安全的，基本目前登录认证的凭证不会再使用cookie的技术了
session:由于cookie是存储在客户端的，它不安全，所以session是把登录成功后的数据存储在服务端
token:本质上是session的原理，我们可以把它理解为一个令牌，每次登录成功后，返回的token都是随机的字符串 jwt的技术来实现
1、HTTP完整的请求流程
2、session的请求流程：
1、客户端输入账户和密码，点击登录
2、登录成功后，会在服务端把用户登录成功后的信息生成一个sessionid的凭证，并且存储在服务端
3、然后服务端通过响应头中的set-cookie把生成的sessionid返回给客户端
4、客户端再次查看个人主页，客户端会通过请求头中的cookie，把set-cookie返回的sessionid带上，发送给服务端
5、服务端接收到客户端发送的sessionid，和存储在服务端的session ID作一个对比
6、如果对比一致，用户可以继续反问系统的任何功能，如果对不一致，立刻跳转到登录的页面
3、token的请求流程：
1、客户端输入账户和密码，点击登录
2、登录成功后，会在服务端把用户登录成功后的信息生成一个Token的凭证，同时了存储在服务端
3、服务端会通过响应数据或者是响应头中的set-cookie返回给客户端
4、那么客户端再次向服务端发送请求，会在请求参数或者请求头中的Authuration中带上返回来的token发送给服务端
5、服务端接收到客户端发送的Token，和存储在服务端的Token作一个对比
6、如果对比一致，用户可以继续反问系统的任何功能，如果对不一致，立刻跳转到登录的页面
HTTPS：
HTTP的协议它是存在缺陷的，
这些缺陷主要为:
1、通信内容是明文，内容很可能被第三方获取到
2、不验证通信方的身份信息，容易被伪装
3、无法证明请求头的完整性
基于HTTP存在这些缺陷，也就有了HTTPS的协议，我们可以把HTTPS可以汇总为:HTTPS=HTTP+加密+认证+完 整性保护。
基于这样一层的设计，相对来说还是比较安全的，HTTPS不是全新的协议，它只是HTTP的协议基础上新增SSL和 TLS。在前面中我们知道HTTP是和TCP直接通信，那么在HTTPS中，HTTP先和SSL通信，SSL再和TCP来进行通 信。
BASIC
基本认证采用Base-64编码方式，但是不是加密的处理方式。不需要附加任何信息可对其进行解码，那么在HTTP等 非加密通信的线路上进行BSCIC认证的过程中，很容易被人进行获取信息，安全体系不够高。
DIGEST
DIGEST的认证体系是为了解决BASIC的缺陷之一的，它也是采用质询/响应的模式，但是不会直接发送明文密码。 所谓质询/响应模式指的是一开始一方先发送认证要求给另外一方，接着使用从另一方那接收到的质询码计算生成 响应码，最后将响应码返回给对方进行认证的方式。
