测试知识杂烩
测试知识杂烩
HTTP 状态码速查表
1xx — 信息响应
| 状态码 | 含义 |
|---|---|
| 100 | Continue（继续） |
| 101 | Switching Protocols（切换协议） |
2xx — 成功
| 状态码 | 含义 |
|---|---|
| 200 | OK（请求成功） |
| 201 | Created（创建成功） |
| 204 | No Content（成功但无内容返回） |
3xx — 重定向
| 状态码 | 含义 |
|---|---|
| 301 | Moved Permanently（永久重定向） |
| 302 | Found（临时重定向） |
| 304 | Not Modified（资源未修改，使用缓存） |
4xx — 客户端错误
| 状态码 | 含义 |
|---|---|
| 400 | Bad Request（请求参数错误） |
| 401 | Unauthorized（未认证，请登录） |
| 403 | Forbidden（无权限访问） |
| 404 | Not Found（资源不存在） |
| 405 | Method Not Allowed（请求方法不允许） |
| 409 | Conflict（冲突，如数据重复） |
| 429 | Too Many Requests（请求过于频繁） |
5xx — 服务器错误
| 状态码 | 含义 |
|---|---|
| 500 | Internal Server Error（服务器内部错误） |
| 502 | Bad Gateway（网关错误） |
| 503 | Service Unavailable（服务不可用） |
| 504 | Gateway Timeout（网关超时） |
curl（基础数据交换工具）
- 命令行下的网络请求工具
- 本质是模拟发送 HTTP 请求（如 GET、POST）
- 不包含浏览器环境，不执行 JavaScript，只负责收发原始 HTTP 报文
- 适合快速调试接口、下载文件或测试服务器响应
- 无法处理需要 JS 渲染的现代网页
HAR（通用数据交换格式）
- 全称 HTTP Archive
- 一种 JSON 格式的存档文件
- 用于记录浏览器与服务器之间的所有网络交互细节（请求头、响应体、Cookie、时间线等）
- 本身不是工具，而是数据载体
- 可通过浏览器开发者工具（Network 面板）导出 HAR，再导入到分析工具或 Postman 中，用来复现问题或分析性能
Playwright（高级浏览器自动化框架）
- Node.js / Python / .NET 库
- 能通过 API 控制 Chromium、Firefox 和 WebKit（Safari 内核）执行真实的浏览器操作
- 能模拟点击、填写表单，并自动等待元素出现
- 天然支持 SPA（单页应用）的 JS 渲染
- 常用于编写爬虫、自动化测试或生成截图 / PDF
开发者工具面板说明
| 标签 | 作用 |
|---|---|
| 标头（Headers） | 显示请求和响应的头信息、URL、方法、状态码等 |
| 负载（Payload） | 显示请求携带的数据（Body、Query 参数） |
| 预览（Preview） | 以可读格式预览响应内容（JSON 树形展示） |
| 响应（Response） | 显示服务器返回的原始内容 |
| 发起程序（Initiator） | 显示这条请求是由哪个代码 / 操作触发的 |
| 计时（Timing） | 显示请求各阶段耗时（DNS、连接、TLS、等待、下载） |
HTTP 版本演进：从“每次敲门”到“多路并行”
HTTP/1.0：每次请求新建连接
特点：
- 每个请求都要重新建立 TCP 连接
- 请求完就断开
通俗理解：
你每次去便利店买东西，都要重新排队、重新结账，买完就走，下次再来重新排。
问题：
- 建立连接慢（三次握手）
- 频繁请求效率极低
HTTP/1.1：长连接 + 管道化（主流）
特点：
- 长连接（Keep-Alive）：一次 TCP 连接可以发多个请求
- 管道化（Pipelining）：可以连续发多个请求，不用等响应
通俗理解：
你进便利店后，可以一次买多件东西，不用每次重新排队。
问题：
- 管道化有队头阻塞：第一个请求慢，后面都得等
- 浏览器实际很少用管道化
HTTP/2：多路复用 + 头部压缩
特点：
- 多路复用：一个连接上并行多个请求，互不阻塞
- 头部压缩（HPACK）：重复的请求头不再重复传
- 二进制分帧：不再是文本，效率更高
- 服务器推送：服务器可主动推资源
通俗理解：
便利店开了多个收银台，你可以同时结账多件商品，互不影响。
解决了 HTTP/1.1 的队头阻塞问题。
HTTP/3：基于 QUIC，更快
特点：
- 底层不用 TCP，改用 QUIC（基于 UDP）
- 0-RTT 建连：首次连接就能发数据
- 彻底解决队头阻塞
- 更适合弱网、移动网络
通俗理解：
不用排队了，直接走 VIP 通道，进门就能办事。
版本对比总结
| 版本 | 连接方式 | 并发 | 头部压缩 | 队头阻塞 | 底层 |
|---|---|---|---|---|---|
| HTTP/1.0 | 每次新建 | 无 | 无 | 有 | TCP |
| HTTP/1.1 | 长连接 | 管道化 | 无 | 有 | TCP |
| HTTP/2 | 多路复用 | 并行 | 有 | 基本解决 | TCP |
| HTTP/3 | QUIC | 并行 | 有 | 彻底解决 | UDP |
Token 和 Cookie：都是“身份凭证”，但机制不同
Cookie：服务器发给浏览器的“小纸条”
流程：
- 你登录成功
- 服务器通过
Set-Cookie把凭证写进浏览器 - 浏览器每次请求自动带上 Cookie
- 服务器靠 Cookie 识别你
特点：
- 浏览器自动管理
- 存在浏览器里
- 每次请求自动带上
- 默认随域名走
通俗理解：
你去游乐园，门口给你盖个章，之后每次玩项目都看这个章。
缺点：
- 跨域麻烦
- 容易被 CSRF 攻击
- 移动端（App、小程序）支持不好
Token：客户端自己保存的“通行证”
流程：
- 你登录成功
- 服务器返回一个 Token（通常是 JWT）
- 客户端自己保存（localStorage / 内存 / 数据库）
- 每次请求手动放到
Authorization头里 - 服务器验证 Token
特点：
- 客户端手动管理
- 不依赖浏览器
- 跨域友好
- 适合 App、小程序、前后端分离
通俗理解：
你去酒店，前台给你一张房卡，之后每次进门自己刷卡。
Cookie vs Token 对比
| 对比项 | Cookie | Token |
|---|---|---|
| 存储位置 | 浏览器 | 客户端自己存 |
| 谁管理 | 浏览器自动 | 客户端手动 |
| 跨域 | 麻烦 | 友好 |
| 移动端 | 支持差 | 支持好 |
| 安全性 | 易 CSRF | 易 XSS |
| 典型场景 | 传统网页 | App、小程序、前后端分离 |
HTTP 请求方法（Request Methods）
GET（获取资源）
- 作用：从服务器获取数据
- 特点：只读，不修改服务器数据
- 示例：
GET /api/users（获取用户列表） - 通俗理解：查资料
POST（新建资源）
- 作用：向服务器提交数据，通常用于新建资源
- 特点：会修改服务器数据，非幂等
- 示例：
POST /api/users（新建用户） - 通俗理解：提交表单
PUT（更新资源，全量）
- 作用：更新整个资源，客户端提供完整数据
- 特点：幂等，多次调用结果一致
- 示例：
PUT /api/users/1（更新用户 1 的全部信息） - 通俗理解：整份资料替换
PATCH（更新资源，部分）
- 作用：只更新资源的部分字段
- 特点：非幂等（取决于实现），比 PUT 更轻量
- 示例：
PATCH /api/users/1（只改用户 1 的昵称） - 通俗理解：只改一个字段
DELETE（删除资源）
- 作用：删除指定资源
- 特点：幂等，删除后再删通常也返回成功
- 示例：
DELETE /api/users/1（删除用户 1） - 通俗理解：删记录
HEAD（获取响应头）
- 作用：与 GET 类似，但只返回响应头，不返回响应体
- 特点：用于检查资源是否存在、是否被修改
- 示例：
HEAD /api/users（只看头信息） - 通俗理解：只看信封，不看信
OPTIONS（预检请求）
- 作用：询问服务器支持哪些请求方法，常用于 CORS 预检
- 特点：不修改数据，浏览器跨域时会自动发
- 示例：
OPTIONS /api/users（问服务器支持哪些方法） - 通俗理解：先问“我能进吗？”
TRACE（回显请求）
- 作用：服务器把收到的请求原样返回，用于调试
- 特点：有安全风险，现代服务器通常禁用
- 示例：
TRACE /api/users - 通俗理解：原话复述
CONNECT（建立隧道）
- 作用：建立网络隧道，常用于 HTTPS 代理
- 特点：不直接操作资源，用于代理场景
- 示例：
CONNECT example.com:443 - 通俗理解：开一条专属通道
方法对比速查表
| 方法 | 作用 | 幂等 | 安全 | 常用度 |
|---|---|---|---|---|
| GET | 获取资源 | 是 | 是 | 极高 |
| POST | 新建资源 | 否 | 否 | 极高 |
| PUT | 全量更新 | 是 | 否 | 高 |
| PATCH | 部分更新 | 否 | 否 | 中 |
| DELETE | 删除资源 | 是 | 否 | 高 |
| HEAD | 只取响应头 | 是 | 是 | 中 |
| OPTIONS | 预检 / 查支持方法 | 是 | 是 | 中 |
| TRACE | 回显请求 | 是 | 是 | 低 |
| CONNECT | 建立隧道 | 否 | 否 | 低 |
幂等与安全的含义
幂等（Idempotent）
- 同一个请求执行一次和执行多次，结果相同
- 例如：
DELETE /users/1执行 1 次和 10 次，用户都被删掉，结果一致 - 非幂等：
POST /users执行多次会创建多个用户
安全（Safe）
- 请求不会修改服务器数据
- 例如：GET、HEAD、OPTIONS 都是安全的
- POST、PUT、PATCH、DELETE 都会改数据，不安全
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 moshiqiqian！
微信- 支付宝
评论