软件测试学习笔记丨接口测试面试题

本文转自测试人社区，原文链接：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的区别

	GET	POST
请求资源	从指定的资源请求数据	向指定的资源提交要被处理的数据
可见性	数据在 URL 中对所有可见	数据不会显示在 URL 中
安全性	安全性差	安全性好
对数据类型的限制	只允许 ASCII 字符	没有限制也允许二进制数据
长度限制	长度受浏览器限制	无限制
参数	保留在浏览器	参数不会保存在浏览器
编码类型	application/x-www-form-urlencoded	application/x-www-form-urlencoded or multipart/form-data。为二进制数据使用多重编码。
缓存	能被缓存	不能缓存
书签	可被保存	不可收藏为书签
后退按钮/刷新	不影响	数据会被重新提交（浏览器应该告知用户数据会被重新提交）。

回答：

• 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的区别

	Cookie	Session	Token
存储位置	客户端	服务器	客户端
安全性	较差	较高	相对最高
占用服务器资源	占用服务器资源消耗少	当访问多时消耗服务器的资源	不占用服务器资源
作用	记录用户状态，辩认身份（传话管理，个性化，追踪）	同cookie	减轻服务端查询数据库的压力，提供授权和认证功能
优点	易于使用和实现，不需要服务器资源，透明性，持久性	信息非常的安全,都是存储在服务器端的	无状态，可扩展和解耦，更好的跨域（跨域资源共享）
缺点	安全性差	服务器压力大，，扩展性不强，分布式，跨系统实现困难	最小的token也比cookie更大，占带宽，性能问题（需要验证两次），无法在服务端注销，很难解决劫持问题
适用范围	在线定货系统、网站个人化和网站跟踪	session 更适用于客户端代码和服务端代码运行在同一台服务器上	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 异常。
• 网络异常。
• 缓存更新

• 缓存失效场景：

• 缓存失效的解决方案

• 降级： 禁用部分接口，开放核心接口。
• 熔断： 禁用部分服务，开放核心服务。

• 缓存失效相关测试方法

1. 梳理系统中的核心服务列表（通常直接让研发给出对应列表）。
2. 梳理服务中核心接口列表（通常直接让研发给出对应列表）。
3. 模拟 Redis 失效，验证核心服务和核心接口是否还能正常运行。

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

• 缓存击穿场景

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

1. 获取热 key 的列表（与运维沟通后获取）。
2. 模拟热 key 失效的场景（比如登陆 Redis，直接将热 key 删除）。
3. 查看研发是否有对应的容错机制，保证服务正常运行。

• 缓存穿透场景

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

1. 不停访问对应服务的接口，传递一个不存在的数据的查询请求。
2. 查看研发是否有对应的容错机制，保证服务正常运行。