本文转自测试人社区，原文链接：https://ceshiren.com/t/topic/29817

一，http 和 https 的区别

1，了解概念

• HTTP 超文本传输协议是一个基于请求与响应，无状态的，应用层的协议常基于 TCP/IP 协议传输数据以明文方式发送内容

• HTTPS 安全套接字层超文本传输协议通过计算机网络进行安全通信的传输协议在 HTTP 的基础上加入了 SSL/TLS 协议 HTTP + 加密 + 认证 + 完整性保护 = HTTPS

2，通信过程

3，回答

• HTTPS 比 HTTP 更安全 HTTP 是超文本传输协议，连接简单无状态，信息明文传输 HTTPS 通过 SSL/TLS 提供安全方式

• HTTP 和 HTTPS 使用完全不同的连接方式

• HTTP 和 HTTPS 用的端口也不一样 HTTP 是 80 端口 HTTPS 是 443 端口

• HTTPS 协议需要到 CA 申请证书，可能需要一定费用

二，get 和 post 的区别

回答：

• HTTP 的 method 字段不同

• POST 可以附加 body，可以支持 form、json、xml、binary 等各种数据格式

• 行业通用的规范无状态变化的建议使用 GET 请求数据的写入与状态修改建议用 POST

• 传送数据量不同

• 安全性不同

三，session、cookie、token 的区别

• Session：数据存储到服务端，只把关联数据的一个加密串放到 Cookie 中标记

• Cookie：浏览器接受服务器的 Set-Cookie 指令，并把 cookie 保存到电脑上，每个网站保存的 cookie 只作用于自己的网站

• Token：是一个用户请求时附带的请求字段，用于验证身份与权限

Session 实现机制

• 服务器创建 Session 出来后，会把 Session id，以 Cookie 的形式回写给客户端 浏览器，这样，只要客户端的浏览器不关，再去访问服务器时，都会带着 Session id ，服务器发现客户机浏览器带 Session id 过来了，就会使用内存中与之对应的 Session 为之服务。(Session 会存在服务器)

cookie 实现机制

• Cookie 通过在客户端记录信息确定用户身份

• Cookie 由服务器生成，发送给浏览器，浏览器把 Cookie 以 kv 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该 Cookie 发送给服务器。

Token 的原理

• 基于 Token 的身份验证是无状态的，我们不将用户信息存在服务器或 Session 中。这解决了在服务端存储信息时的许多问题 NoSession 意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

• 基于 Token 的身份验证的过程如下: 用户发送数据请求 程序验证 程序返回一个签名的 token 给客户端 客户端储存 token，并且每次用于每次发送请求。 服务端验证 token 并返回数据。

• token 通常在 HTTP 的头部发送给服务端

session、cookie、token 的区别

四，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 报文详解

• 序号:占 4 个字节，表示发送的数据字节流

• 确认号:占 4 个字节，发送方期待接收的下一序列号，只有 ACK=1 时才有效

• ACK：确认序号的标志，ACK=1 表示确认号有效，ACK=0 表示报文不含确认序号信息

• SYN：连接请求序号标志，用于建立连接，SYN=1 表示请求连接

• FIN：结束标志，用于释放连接，为 1 表示关闭本方数据流

五，tcp 与 udp 的区别

• TCP：面向连接、错误重传、拥塞控制，适用于可靠性高的场景

• UDP：不需要提前建立连接，实现简单，适用于实时性高的场景

连接方式

• UDP 是无连接的不可靠的传输，不进行流量控制和拥塞控制

• TCP 是有连接的可靠传输，使用流量控制和拥塞控制

通信方式

• UDP 支持一对一，一对多，多对多的通信

• TCP 仅支持一对一

对报文的处理

• UDP 是面向报文的（对应用层交付的报文直接打包）

• TCP 面向字节流

数据报首部

• UDP 首部是 4 个字段，每个字段两个字节，共 8 个字节

• TCP 首部最小长度为 20 字节，最大长度为 60 字节

六，消息队列测试场景

消息队列

• Broker：消息服务器，提供消息核心服务

• Producer：消息生产者，业务的发起方，负责生产消息传输给 broker。

• Consumer：消息消费者，业务的处理方，负责从 broker 获取消息并进行业务逻辑处理。

应用场景

1. 异步通信

2. 流量削峰

3. 应用解耦

4. 负载均衡

5. 数据同步

消息队列的测试点

• 生产者：时序：不同时序推送消息，先后顺序是否和预期一致数据正确性： 内容是否完整；内容是否满足需求推送：推送失败是否有重试

• 消费者：是否正常消费信息消息被消费后是否清除消费者接收到的信息和生产者一致消费者堵塞，如何处理。幂等（接收到重复消息）

七，redis 测试场景

redis 简介

• 读写性能优异。

• 数据类型丰富。

• Redis 支持数据的备份。

• 数据自动过期。

• 发布订阅。

• 分布式。

应用场景

• 主要包含：读多写少，并发强的场景。有时间性的业务场景。对有序集合数据类型排序。对于时效性要求不高。Session 会话缓存。消息系统。单线程的特点可以天然用作分布式锁。

面试题

1，你们的 Redis 使用的是淘汰缓存还是更新缓存，这两者有什么区别？请详细说明。

• 淘汰缓存优点： 操作简单，性能比较好。缺点：至少会出现一个 cache miss。

• 更新缓存优点： 基本不会出现 cache miss 的情况。缺点： 每次更新数据库都更新缓存，比较影响性能。

2，怎么定位 Redis 缓存失效问题（缓存坏了）？

• 缓存失效：缓存不可用之后，大量并发到数据库。

• 缓存失效原因：缓存过期。Redis 异常。网络异常。缓存更新

• 缓存失效场景：

• 缓存失效的解决方案降级： 禁用部分接口，开放核心接口。熔断： 禁用部分服务，开放核心服务。

• 缓存失效相关测试方法

• 梳理系统中的核心服务列表（通常直接让研发给出对应列表）。

• 梳理服务中核心接口列表（通常直接让研发给出对应列表）。

• 模拟 Redis 失效，验证核心服务和核心接口是否还能正常运行。

3，Redis 击穿、穿透区别，如何设计用例以及完成测试？

• 缓存击穿场景

• 击穿场景的测试用例步骤

• 获取热 key 的列表（与运维沟通后获取）。

• 模拟热 key 失效的场景（比如登陆 Redis，直接将热 key 删除）。

• 查看研发是否有对应的容错机制，保证服务正常运行。

• 缓存穿透场景

• 穿透场景的测试用例步骤

• 不停访问对应服务的接口，传递一个不存在的数据的查询请求。

• 查看研发是否有对应的容错机制，保证服务正常运行。

获取更多软件测试知识