测试知识杂烩

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	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 都会改数据，不安全

Authentication（身份认证）

身份认证是接口测试中绕不开的一环，Postman 提供了多种配置粒度来管理认证信息。以下按 Token 的配置方式展开。

Token 配置

方式一：直接配置 Token（静态方式）

三种粒度：

请求级别（Headers）：在单个请求的 Headers 里手动加 Authorization: Bearer xxx。
请求级别（Authorization 选项卡）：在单个请求的 Authorization 选项卡里，Type 选 Bearer Token，Token 框填具体值，Postman 自动生成认证信息。这是 Postman 主推的方式，比手动拼 Headers 更直观、不易拼错。
集合级别：在 Collection 的 Authorization 里设置好 Token，然后每个请求的 Authorization 选 Inherit auth from parent，自动跟随父集合。

适用场景：Token 长期不变、测试阶段临时调试、接口数量少。

缺点：Token 一旦过期，所有请求都得手动改一遍。

方式二：环境变量 + 自动更新（动态方式）

核心流程：

在 Environment 里建一个变量，比如 token，先留空。
在登录接口的 Tests 脚本里写代码，把响应里的 Token 提取出来存进环境变量：

javascript
1
2
const jsonData = pm.response.json();
pm.environment.set("token", jsonData.access_token);
在其他请求里引用 {{token}}：
- 请求的 Authorization 选项卡里填 Bearer {{token}}
- 或请求 Headers 里填 Authorization: Bearer {{token}}
- 或集合级别 Authorization 里填 Bearer {{token}}

关键点：每次跑测试时，先跑登录接口，token 变量就被刷新了，后续请求自动用上新 Token。

API 认证流程配置（Postman 实战补充）

在实际项目中，登录接口返回的 access_token 和 refresh_token 可以通过 Environment 变量 + Collection 授权，实现全集合的自动认证。完整流程如下：

第一步：建立环境变量

在 Postman 左侧 ENVIRONMENTS 里新建一个环境（如 token1），添加两个变量：

Variable	Value
`access_token`	先留空，登录后自动写入
`refresh_token`	先留空，登录后自动写入

保存后，右上角下拉框必须选中这个环境，否则变量不生效。

第二步：登录接口自动写入 Token

在登录接口（POST /login/phone-verification/）的 Scripts → Post-response 中粘贴：

javascript

1
2
3

const jsonData = pm.response.json();
pm.environment.set("access_token", jsonData.access_token);
pm.environment.set("refresh_token", jsonData.refresh_token);

这样每次跑登录接口，环境变量里的 Token 就会被自动刷新。登录接口本身的 Authorization 要选 No Auth，因为它不需要带 Token。

第三步：Collection 级统一授权

点左侧 Collection 名字 → Authorization 标签
Type 选 Bearer Token
Token 框填 {{access_token}}（不要加 Bearer，Postman 会自动加）
保存

第四步：子请求继承

集合下的业务请求（如 menu-permission/、current/），Authorization 选 Inherit auth from parent，自动使用集合级别的 {{access_token}}。

第五步：验证流程

先跑登录接口 → 返回 201，环境变量 access_token 自动刷新
再跑业务请求 → Headers 自动带上 Authorization: Bearer eyJ...，返回 200 即成功

黑盒测试

等价类划分：将输入数据划分为不同的等价类，选取代表性的数据进行测试。
边界值分析：针对输入或输出范围的边界进行测试，尤其聚焦于边界条件。
决策表测试：使用决策表来设计测试用例，确保覆盖所有可能的情况和组合。
因果图：用于处理输入条件和输出结果之间的依赖关系，生成测试用例。
状态迁移测试：测试不同状态之间的转移情况，适用于带有状态机的系统。

白盒测试

路径覆盖：测试人员尝试覆盖所有可能的路径。例如，一个简单的if-else结构，你需要测试两条路径：if (true) 和 else。
语句覆盖：这个方法强调执行代码中的每一条语句至少一次。例如，程序中有三行代码，你需要确保这三行代码都被运行到。
分支覆盖：在这种方法中，关注条件语句的每一个分支（true和false的情况）都被执行到。例如，一个if语句，你需要确保if为true和为false的情况都测试到。
条件覆盖：不仅要考虑条件语句的整体结果，还要独立考虑每个布尔表达式的true和false。例如，if(a && b)，你需要分别测试a为true或false、b为true或false，以及两者组合的情况。