API接口测试

一.基础

1.API测试技术栈

1、协议
2、接口测试的工具:PostMan,JMeter
3、接口测试的框架
4、MockServer

2.单体架构的开发模式

图书管理系统：

业务场景：看到喜欢的书，然后下单，支付，购买

单体架构的模式是把前后以及所有的业务场景的代码都整合到一起

业务模块：书籍管理、支付模块、账户模块、物流模块

3.微服务架构模式

微服务架构就是根据业务场景，把每个独立的业务场景单独分离成一个服务，这样服务和服务之间通信，通信通过REST API 或者gRPC的协议来进行交互。

4.场景

开发：

1、前端程序员把代码写完，后端程序员把代码写完

2、前端和后端进行联调（前端把输入的账户和密码拿到，然后发送给(HTTP的协议)后端）

3、后端拿到前端发送的数据进行验证

测试：

1、验证这个过程中业务逻辑是否能够成功

5.金字塔模型

在?字塔的模型中，在测试分为三个维度来进?思考，分别是单元，服务和UI三个层级。这地?主要的说下服务层的测试，在服务层的测试维度中，主要针对的是业务接?的测试，来验证接?功能是否完整，如内部逻辑，异常处理。这样的?的是验证接?它是否稳定，所以接?的测试相对???较容易?且更加?效,测试?例的维护成本也低。有很多主流的测试?具都可以做接?测试，如PostMan,JMeter,SoupUi等，除了?具还有在Python语?中很多的第三?的库都是可以来做接?测试的，如：urllib,requests,aiohttp等。

在金字塔的模型中：
1、金字塔模型把开发测试的模型分为三层，分别是单元测试，接口测试，和UI测试
2、unit:单元测试 services:接口测试（API自动化测试） UI：UI测试(功能测试,ui自动化测试)
3、越底层的，越应该投入更多的精力去保障，越上层的，投入少量的精力去保障

6.HTTP

1989年的3?份了，诞?了HTTP的协议，也可以称呼为“超?本传输协议”。

HTTP/0.9
HTTP从发展开始，?直没有?个统?的标准，最典型的版本是HTTP/0.9
HTTP/1.0
HTTP协议作为正式的标准是在1996年的5?份，版本被命名为HTTP/1.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的版
本来进?设计的。

7.微服务的架构通信模式：

微服务的通信模式使用的方式有两种：
1、一种是采用基于REST API的轻量级的基于HTTP的协议
2、使用的是gRPC的协议

二.网络分层

1.TCP/IP分层管理

TCP/IP协议按层次主要为：应?层，传输层，?络层，数据链路层。

应用层
应?层决定了向?户提供应?服务时通信的活动。?HTTP的协议和gRPC的协议就是属于应?层的协议。
传输层
应?层的下层是?络传输层，提供处于?络连接中的两台计算机之间的数据传输。
核心的协议就是TCP/IP的协议
TCP/IP通信传输流
网络层
主要是?来处理?络上流动的数据包，所谓数据包就是?络传输中的最?单位，在该层协议中，规范了通过怎样的
路径到达?标计算机，并且把数据包传送给对?。
链路层
主要是处理连接?络的硬件部分，如操作系统，硬件设备的驱动等。

2.websoket协议（auth2.0）：

websocket协议：客户端与服务端始终保持持久连接 不会断开


客户端：拿微信来说，手机微信，电脑微信，都是客户端
服务端：腾讯的微信服务器

3.三次握手

为了确保把数据能够送到?标的服务器，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、客户端确认：客户端需要向服务端再次反馈，客户端收到服务端的反馈了

4.URI和URL

URI可以称为统一资源标识符，而URL是统一资源定位符。URI可以理解为标识某一个互联网的资源，而URL表示的是资源的地点。

三.HTTP协议

HTTP是应?层的协议，它不需要刻意的去关注底层?络传输层协议的东?。在整体应?层的协议中，通俗的说在整个API的测试维度上，需要关注的是?个完整的HTTP请求流程，请求?法，请求头响应头，COOKIE请求流程，SESSION的请求流程和TOKEN的请求流程，以及HTTPS的请求流程。在微服务的架构模式下，使?的也是轻量级的通信模式（REST API），在微服务的架构模式中，需要清楚的是它的通信可以分为同步通信模式和异步通信模式，或者更加具体本质的说就是请求/响应和异步请求/响应（发布/订阅模式）。协议可以具体?如下：

1.HTTP协议请求流程

2.查看请求

3.通信模式

3.1同步通信

在客户端与服务端在进?交互的时候，通信模式主要分为同步通信和异步通信。同步通信简单的可以理解为客户端发送请求给服务端，服务端必须得回应客户端的请求。所以同步通信它存在如下的缺点，具体为：

容易超时，客户端发送请求后，服务端迟迟没有回应客户端的请求

如果请求是存在?的计算量和逻辑存在问题，就会导致请求堵塞，后?的都积压

3.2异步通信

由于同步交互存在超时以及堵塞的情况，所以也就有了异步的交互。在异步的交互中，客户端和服务端互相不需要关注对?的存在，只需要关注对应的MQ的消息，客户端与服务端的交互主要是会通过MQ的消息中间作为消息的传递来进?交互的，具体交互如下：

4.HTTP常用请求方法

GET	客户端从服务端获取资源
POST	客户端往服务端发送请求添加新的资源
PUT	客户端针对服务端已有的数据进行更新
DELETE	客户端删除服务端已有的数据
CONNEC	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器
OPTIONS	允许客户端查看服务器的特性
TRACE	回显服务器收到的请求，主要用于测试或诊断
HEAD	类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头

由于PUT和DELETE请求方法不安全，所以了很多时候，往往会使用POST来进行替代。

5.HTTP请求的组成部分

5.1Requests请求部分

请求地址：Request URL
请求方法：Request Method
请求头：Request Headers
- Content-Type:指的是数据格式
- Cookie：反爬虫，身份凭证
- Referer：发送请求的地址是从哪里来的
- User-Agent：发送网络请求的时候向服务端标注请求是通过什么浏览器或者什么软件(PostMan,JMeter)发送的
请求参数
- get：路径参数
```
如：
     http://xxx.com/?name=wuya&age=18 ?key1=value1&key2=value2
```
  PS：get的请求参数与数据格式没任何关系
- post：在payload中显示了请求的参数

5.2Response响应部分

协议状态码

200 #请求成功
301 #永久重定向?
302 #临时重定项?
400 Bad Request #客户端请求错误
```
1.请求参数不对

2.请求头不对
```
401 Unauthorized #无权限访问该系统
403 Forbidden #有权限但是禁止访问

404 #请求的资源不存在?

请求的地址不存在，所以导致请求的资源也是不存在

405 #不被允许的请求方法?

 你请求的方法，没有定义对应的请求方法，但是你去进行访问?

500 #服务器内部错误?

空指针 Null PointExpection
            堆栈溢出 在测试选择项的时候，选择很多很多的项，同时触发，看是否会暴露该问题
            OOM（内存泄露） Out Of Memory 
            其他异常:Expection

504 #GateWay Timeout
```
网关超时
```

响应数据

响应数据返回的数据格式是由响应头里面的content-type来决定的

响应头
- content-type:指明返回的响应数据的数据格式是什么
- set-cookie:服务端返回给客户端的登录凭证
1

5.3常用的表单数据

表单

application/x-www-form-urlencoded; charset=UTF-8(GBK)

json格式

application/json;charset=UTF-8 json数据格式：基于JSON的数据格式，但是数据类型是字符串

ext/html
```
返回的是基于html的数据格式
```
text/xml
```
返回的是基于xml的数据格式
```

以下为百度首页的请求响应数据：

General：

Request URL: https://www.baidu.com/   #请求地址
Request Method: GET   #请求方法
Status Code: 200 OK   #请求状态
Remote Address: 36.152.44.95:443   #远程地址
Referrer Policy: unsafe-url

Response Headers：   #响应头


Bdpagetype: 2   Bdqid: 0xe010484800023fd8
Cache-Control: private
Connection: keep-alive   #连接
Content-Encoding: gzip   #响应内容编码
Content-Type: text/html;charset=utf-8   #返回的数据类型和编码
Date: Mon, 03 Jan 2022 15:48:08 GMT   #响应产生的时间
Expires: Mon, 03 Jan 2022 15:48:08 GMT   #有效期
Server: BWS/1.1   #服务器的信息
Set-Cookie: BDSVRTM=299; path=/
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: H_PS_PSSID=35640_35468_35105_35631_35489_34584_35491_35245_35317_26350_35621_35561; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Traceid: 1641224888055166925816145484138198220760
Transfer-Encoding: chunked
X-Frame-Options: sameorigin
X-Ua-Compatible: IE=Edge,chrome=1

Request Headers：   #请求头


Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9   #指定客户端接收的数据类型
Accept-Encoding: gzip, deflate, br   #客户端可接受的内容编码
Accept-Language: zh-CN,zh;q=0.9   #客户端可接受的语言编码
Connection: keep-alive
Cookie: BIDUPSID=1BC8669236942C81DEB0A40AA5BB8099; PSTM=1635924020; BAIDUID=1BC8669236942C8160730242377CD27E:FG=1; __yjs_duid=1_51a616f347f31a89b8d2b2cf652ce7371635924140466; __sec_t_key=c6f49002-912c-474e-bbcb-0e614ab9a6d2; BAIDUID_BFESS=1BC8669236942C8160730242377CD27E:FG=1; Hm_lvt_aec699bb6442ba076c8981c6dc490771=1637285395,1638457818,1638863850; COOKIE_SESSION=104510_1_8_9_14_3_1_0_8_3_2_0_104511_0_3_0_1638949274_1638412634_1638949271%7C9%231127298_3_1638412631%7C2; BDUSS=ZjNDZEUEI0TGdGaHNVRUFQT2xZcFo5Wm82N0YxNXd3YTZDS2NEZ2xQLWhHZWxoRVFBQUFBJCQAAAAAAAAAAAEAAAA7Sk2R556O6Ze58J-SpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKGMwWGhjMFhUD; BDUSS_BFESS=ZjNDZEUEI0TGdGaHNVRUFQT2xZcFo5Wm82N0YxNXd3YTZDS2NEZ2xQLWhHZWxoRVFBQUFBJCQAAAAAAAAAAAEAAAA7Sk2R556O6Ze58J-SpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKGMwWGhjMFhUD; BD_UPN=12314753; BD_HOME=1; BDRCVFR[feWj1Vr5u3D]=I67x6TjHwwYf0; delPer=0; BD_CK_SAM=1; PSINO=3; H_PS_PSSID=35640_35468_35105_35631_35489_34584_35491_35245_35317_26350_35621_35561; H_PS_645EC=477eCF32idOG1i0IqrcDOoCO%2Faa8D7RccotKPSIkoV97Agl5xRK0sbMHJZh4M8nT681n; BDORZ=B490B5EBF6F3CD402E515D22BCDA1598; baikeVisitId=44bef63e-f3f8-454f-a3a4-aa768bee9829; BA_HECTOR=8g0h2g0kal2g2404rc1gt66li0q; WWW_ST=1641224888826
Host: www.baidu.com   #请求主机的IP地址和端口号
Referer: https://www.baidu.com/　　#请求是从哪个页面发送过来的
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36　　#识别客户端使用的操作系统版本 浏览器版本信息等

四.cookie、session、token

由于http是一个无状态的协议，但是由于互联网产品迭代的发展，需要记住用户的操作行为习惯等

1.cookie

主要是存储用户操作行为的数据，在早期的互联网产品中，用户登录系统的凭证都是由cookie来进行记录的，但是由于是存储在客户端
的（本机的电脑），所以是不安全的，基本目前登录认证的凭证不会再使用cookie的技术了

2.session

由于cookie是存储在客户端的，它不安全，所以session是把登录成功后的数据存储在服务端

session流程

客户端输入账号和密码，点击登录
登录成功后，会在服务端把用户登录成功后的信息生成一个sessionid的凭证，并且存储在服务端
服务端通过响应头中的set-cookie把生成的sessionid返回给客户端
客户端再次查看个人主页或其他行为，客户端会通过请求头中的cookie，把set-cookie返回的sessionid带上，发送给服务端
服务端接收到客户端发送的sessionid，和存储在服务端的session ID作一个对比
如果对比一致，用户可以继续反问系统的任何功能，如果对不一致，立刻跳转到登录的页面

实战

我们以一品威客官网的登录请求为例，服务端把sessionid通过响应头中的set-cookie返回给客户端

然后我们在进行其他操作，如查看个人首页，客户端会通过请求头中的cookie，把set-cookie返回的sessionid带上，发送给服务端，服务端接收到客户端发送的sessionid，和存储在服务端的session ID作一个对比，如果对比一致，用户可以继续反问系统的任何功能，如果对不一致，立刻跳转到登录的页面

比如我们删除Application中cookies中的信息来模拟客服端发送的sessionid与服务端储存的sessionid不一致，重新发送请求就会重新登录

3.token

本质上是session的原理，我们可以把它理解为一个令牌，每次登录成功后，返回的token都是随机的字符串 使用jwt的技术来实现

token流程

客户端输入账户和密码，点击登录
登录成功后，会在服务端把用户登录成功后的信息生成一个Token的凭证，同时了存储在服务端
服务端会通过响应数据或者是响应头中的set-cookie返回给客户端
那么客户端再次向服务端发送请求，会在请求参数或者请求头中的Authuration中带上返回来的token发送给服务端
服务端接收到客户端发送的Token，和存储在服务端的Token作一个对比
如果对比一致，用户可以继续反问系统的任何功能，如果对不一致，立刻跳转到登录的页面

实战　　

我们以考虫的官网登录请求为例：

登录成功后，服务端会把tokenid通过响应头中的set-cookie返回给客户端，当我们再次请求时，会在请求参数或者请求头中的Authuration中带上返回来的token发送给服务端