软件测试 / 测试开发丨接口测试学习笔记分享
获取更多相关知识
本文为霍格沃兹测试开发学社学员学习笔记分享，文末附原文链接。
一、http 与 https 的区别
1、HTTP 与 HTTPS 的概念
HTTP 超文本传输协议是一个基于请求与响应，无状态的，应用层的协议常基于 TCP/IP 协议传输数据以明文方式发送内容
HTTPS 安全套接字层超文本传输协议通过计算机网络进行安全通信的传输协议在 HTTP 的基础上加入了 SSL/TLS 协议 HTTP + 加密 + 认证 + 完整性保护 = HTTPS
2、HTTP 与 HTTPS 的区别
HTTPS 比 HTTP 更安全
HTTP 是超文本传输协议，连接简单无状态，信息明文传输
HTTPS 通过 SSL/TLS 提供安全方式
HTTP 和 HTTPS 使用完全不同的连接方式
HTTP 和 HTTPS 用的端口也不一样
HTTP 是 80 端口
HTTPS 是 443 端口
HTTPS 协议需要到 CA 申请证书，可能需要一定费用
二、get、post 区别
1、区别
2、总结：GET 与 POST 的区别
HTTP 的 method 字段不同
POST 可以附加 body，可以支持 form、json、xml、binary 等各种数据格式
行业通用的规范无状态变化的建议使用 GET 请求数据的写入与状态修改建议用 POST
传送数据量不同
安全性不同
三、session、cookie、token 的区别
1、 Session Cookie Token 区别
Session：数据存储到服务端，只把关联数据的一个加密串放到 Cookie 中标记
Cookie：浏览器接受服务器的 Set-Cookie 指令，并把 cookie 保存到电脑上，每个网站保存的 cookie 只作用于自己的网站
Token：是一个用户请求时附带的请求字段，用于验证身份与权限
2、 Session 实现机制
服务器创建 Session 出来后，会把 Session id，以 Cookie 的形式回写给客户端 浏览器，这样，只要客户端的浏览器不关，再去访问服务器时，都会带着 Session id ，服务器发现客户机浏览器带 Session id 过来了，就会使用内存中与之对应的 Session 为之服务。(Session 会存在服务器)
3、 cookie 实现机制
Cookie 通过在客户端记录信息确定用户身份，
Cookie 由服务器生成，发送给浏览器，浏览器把 Cookie 以 kv 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该 Cookie 发送给服务器。
4、 Token 的原理
基于 Token 的身份验证是无状态的，我们不将用户信息存在服务器或 Session 中。这解决了在服务端存储信息时的许多问题 NoSession 意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
基于 Token 的身份验证的过程如下:用户发送数据请求程序验证程序返回一个签名的 token 给客户端客户端储存 token，并且每次用于每次发送请求。服务端验证 token 并返回数据。
token 通常在 HTTP 的头部发送给服务端
5、 Session,Cookie,Token 的工作原理
四、tcp 三次握手与四次挥手
1、 TCP 报文
序号:占 4 个字节，表示发送的数据字节流
确认号:占 4 个字节，发送方期待接收的下一序列号，只有 ACK=1 时才有效
ACK：确认序号的标志，ACK=1 表示确认号有效，ACK=0 表示报文不含确认序号信息
SYN：连接请求序号标志，用于建立连接，SYN=1 表示请求连接
FIN：结束标志，用于释放连接，为 1 表示关闭本方数据流
2、 三次握手
首先 Client 端发送连接请求报文
Server 端接受连接后回复 ACK 报文，并为这次连接分配资源
Client 端接收到 ACK 报文后也向 Server 段发生 ACK 报文，并分配资源
3、 四次挥手
假设 Client 端发起中断连接请求，也就是发送 FIN 报文。
Server 端接到 FIN 报文后，先发送 ACK，这个时候 Client 端就进入 FIN_WAIT 状态，继续等待 Server 端的 FIN 报文。
当 Server 端确定数据已发送完成，则向 Client 端发送 FIN 报文
Client 端收到 FIN 报文后, 发送 ACK 后进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传。Client 端等待了 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭
Client 端关闭连接
4、 tcp 三次握手与四次挥手
三次握手首先 Client 端发送连接请求报文 Server 段接受连接后回复 ACK 报文，并为这次连接分配资源 Client 端接收到 ACK 报文后也向 Server 段发生 ACK 报文，并分配资源
四次挥手 Client 端发起中断连接请求(发送 FIN 报文)Server 端接到 FIN 报文后，先发送 ACK，Client 端进入 FIN_WAIT 状态，继续等待 Server 端的 FIN 报文。当 Server 端确定数据已发送完成，则向 Client 端发送 FIN 报文 Client 端收到 FIN 报文后, 发送 ACK 后进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传。Client 端等待了 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭 Client 端关闭连接
五、tcp 与 udp 的区别
1、 TCP 与 UDP 的区别
TCP：面向连接、错误重传、拥塞控制，适用于可靠性高的场景
UDP：不需要提前建立连接，实现简单，适用于实时性高的场景
2、 UDP 无连接，TCP 面向连接
使用 UDP 不需要提前建立连接
使用 TCP 协议的双方在发送数据之前必须使用
UDP 支持一对一，一对多，一对全的通信
TCP 仅支持一对一
3、 TCP 和 UDP 对报文的处理
UDP 是面向报文的
TCP 面向字节流
4、 传输方式
UDP 是无连接的不可靠的传输
TCP 是有连接的可靠传输
5、 数据报首部
UDP 首部是 4 个字段，每个字段两个字节，共 8 个字节
TCP 首部最小长度为 20 字节，最大长度为 60 字节
6、 TCP 与 UDP 区别总结
六、消息队列测试场景
1、 什么是消息队列
Broker：消息服务器，提供消息核心服务
Producer：消息生产者，业务的发起方，负责生产消息传输给 broker。
Consumer：消息消费者，业务的处理方，负责从 broker 获取消息并进行业务逻辑处理。
2、 消息队列的应用场景
异步通信
流量削峰
应用解耦
负载均衡
数据同步
3、 消息队列的测试点
七、redis 测试场景
1、 Redis 简介
读写性能优异。
数据类型丰富。
Redis 支持数据的备份。
数据自动过期。
发布订阅。
分布式。
2、 Redis 的应用场景
应用场景主要包含：读多写少，并发强的场景。有时间性的业务场景。对有序集合数据类型排序。对于时效性要求不高。Session 会话缓存。消息系统。单线程的特点可以天然用作分布式锁。
3、 Redis 的查询流程
没有 redis 的情况下
有 redis 的情况下
4、 淘汰缓存与更新缓存
（1） 缓存操作流程-读
缓存中有数据。
缓存中没有数据。
（2） 缓存操作流程-写（淘汰缓存）
优点： 操作简单，性能比较好。
缺点：至少会出现一个 cache miss。
（3） 缓存操作流程-写（更新缓存）
优点： 基本不会出现 cache miss 的情况。
缺点： 每次更新数据库都更新缓存，比较影响性能。
（4） 淘汰缓存与更新缓存区别
视应用场景而定。
通常会使用淘汰缓存。
5、 Redis 缓存失效
缓存不可用之后，大量并发到数据库。
6、 为什么会产生缓存失效
缓存过期。
Redis 异常。
网络异常。
缓存更新
7、 缓存更新导致失效场景
8、 缓存失效的解决方案
降级： 禁用部分接口，开放核心接口。
熔断： 禁用部分服务，开放核心服务。
9、 缓存失效相关测试方法
梳理系统中的核心服务列表（通常直接让研发给出对应列表）。
梳理服务中核心接口列表（通常直接让研发给出对应列表）。
模拟 Redis 失效，验证核心服务和核心接口是否还能正常运行。
10、 Redis 击穿、穿透区别
（1） 击穿
（2） 击穿的场景的测试用例步骤
获取热 key 的列表（与运维沟通后获取）。
模拟热 key 失效的场景（比如登陆 Redis，直接将热 key 删除）。
查看研发是否有对应的容错机制，保证服务正常运行。
（3） 穿透-正常查询场景
（4） 穿透-缓存穿透的场景
（5） 穿透的场景的测试用例步骤
不停访问对应服务的接口，传递一个不存在的数据的查询请求（并发查询）。
查看研发是否有对应的容错机制，保证服务正常运行。
（6） 击穿与穿透总结
版权声明: 本文为 InfoQ 作者【测试人】的原创文章。
原文链接:【http://xie.infoq.cn/article/7adbc633cc36c41423f8e1882】。文章转载请联系作者。
专注于软件测试开发 2022-08-29 加入
霍格沃兹测试开发学社，测试人社区：https://ceshiren.com/t/topic/22284
评论