接口测试（二）

接口信息

1. 常规板块

字段	含义
请求 URL	接口完整地址
Request Method	POST，提交表单数据，登录提交一般用 POST
Status Code	200 OK，服务器成功收到请求并返回响应（不代表登录业务成功，只是通信成功）
Remote Address	服务器 IP + 端口：49.233.201.254:8080
Referrer Policy	引用策略，控制浏览器发送 Referer 的规则：strict-origin-when-cross-origin 跨域时只发送源，同域发送完整地址

• 请求方法
  • GET：查数据（查询，不会修改服务器数据，一般无body）
  • POST：提交数据（新增、登录、提交表单，常用Body传参）
  • PUT：修改数据
  • DELETE：删除数据
• URL：接口地址，服务器访问入口
  • http:// 协议；
  • 49.233.201.254服务器 IP；
  • 8080端口；
  • 剩余 接口路径

2. 响应头（服务器返回给浏览器的信息）

字段	含义
Content-Type	application/json;charset=UTF-8：响应体是 JSON 格式，编码 UTF-8，Postman 可以直接解析返回 json
Date	服务器时间：Fri, 09 Oct 2026 11:05:37 GMT
Server	服务器容器：Apache-Coyote/1.1（Tomcat）
Transfer-Encoding	chunked：分块传输，服务器不知道响应长度时，分段返回数据

3. 请求头（浏览器发给服务器）⭐️

字段	含义
Accept	浏览器告诉服务器：我能接收 application/json、js、任意类型/ 的响应
Accept-Encoding	浏览器支持的压缩格式：gzip、deflate，服务器压缩返回，减少传输大小
Accept-Language	浏览器语言：优先中文 zh-CN，其次英文；服务器可根据这个返回多语言页面
Connection	keep-alive：保持长连接，一次 TCP 连接可以多次收发请求，不用每次都新建连接
Content-Length	33，请求体（表单）数据长度，单位字节
Content-Type	application/x-www-form-urlencoded; charset=UTF-8；✅重点：表单类型，键值对格式，不是 json！Postman 里面要选 x-www-form-urlencoded 而不是 raw json
Cookie	JSESSIONID=6881B04FF9E12BA98628213C1E804029 ；✅重点：会话 ID，Tomcat 服务端 session 标识；登录前会先访问页面拿到这个 JSESSIONID，提交登录请求必须带上这个 Cookie，否则登录失败！
Host	目标服务器 IP 和端口，浏览器自动填充
Origin	来源地址： http://49.233.201.254:8080 ，标记请求来自哪个源，用于跨域校验
Referer	http://49.233.201.254:8080/cms/manage/login.do ；上一页页面地址，告诉服务器：这个请求是从登录页面跳转过来的，有些后台系统会校验 Referer，不带会拦截
User-Agent	浏览器身份标识，告诉服务器当前是什么浏览器、操作系统
X-Requested-With	XMLHttpRequest ✅重点：AJAX 异步请求标记。后端判断这是前端 JS 异步 ajax 提交，不是普通页面表单提交。如果 Postman 缺少这个头，后端可能拒绝请求！

• Content-Type：指定 Body 里面数据的格式（最核心！错了接口直接报错）
  • application/json：json 格式，现在前后端最常用
  • application/x-www-form-urlencoded：表单格式，老系统表单
  • multipart/form-data：上传文件用
• Cookie：会话凭证，登录后的身份令牌，保存登录状态
• token / Authorization：鉴权令牌，很多接口登录后要带这个才能访问，相当于通行证

传 JSON 忘记写 Content-Type:application/json，后端识别不到数据，直接返回参数为空

4. Params（Query参数，URL 问号后面的参数）

• 特点：参数拼在网址？后面，GET请求常用

参数	含义	例子
Key	参数名，后端定义好的名字	userName
Value	参数值，你传给后端的数据	admin
Description	描述（可选，写备注）	登录账号

✅ 适合：查询条件、分页 page、size
❌ 不适合：密码、大量数据（明文展示，不安全）

5. Body 请求体（POST/PUT 常用，GET一般不用）
   Body 下面五种类型，常用三种

• form-data（表单，支持上传文件）
  • Key：参数名
  • Value：值；如果上传文件，下拉选 File，选择本地文件
    适用：上传图片、文件 + 普通参数一起提交
• x-www-form-urlencoded（表单键值对，老项目）
  一行一行 key:value，和 form-data 类似，不能传文件
  适用：老系统登录接口
• raw（原始文本，选 JSON）
  最常用！写 json 格式
  ✅ 选 raw，右侧下拉选择JSON，会自动带上Content-Type:application/json

  raw 还支持 xml/text，接口是什么格式就选什么

鉴权

鉴权简单说：验证你是谁，判断你有没有权限访问这个接口。
流程：登录 → 获取身份凭证 → 后续每次请求带上凭证 → 后端校验凭证是否合法

1. Cookie简介
   Cookie 是服务器下发给浏览器，保存在本地的一小段文本数据。
   浏览器后续访问同一个网站时，会自动带上 Cookie 发给服务器。

作用：记住用户身份、登录状态、页面设置等。接口 / UI 自动化经常用到。

核心特点

• 存储在客户端（浏览器）
• 有域名限制：A 网站的 cookie 不会发给 B 网站
• 有过期时间
  • 会话 Cookie：关闭浏览器就失效
  • 持久 Cookie：设置过期时间，保存在本地文件
• 大小很小，单条一般 4KB 以内

常见字段

字段	含义
Name	Cookie 名称
Value	Cookie 的值（最关键，登录 token 经常放这里）
Domain	归属域名，哪些网站可以读取这个 cookie
Path	路径，比如 / 代表整个网站都生效
Expires/Max-Age	过期时间
Secure	勾选后：只有 HTTPS 请求才会携带这个 cookie
HttpOnly	勾选后：JS 脚本不能读取 cookie，防止 XSS 盗取（安全）
SameSite	防止跨站请求伪造 CSRF

测试场景使用cookie

• 接口测试（postman）
  登录接口请求成功后，服务端返回 Set-Cookie。
  Postman 会自动保存 Cookie，后续同域名请求自动带上，保持登录态。
  也可以手动复制 Cookie 放到请求头：Cookie: name1=value1; name2=value2
• Selenium UI 自动化
  可以获取浏览器 cookie：driver.get_cookies()
  添加 cookie：driver.add_cookie({"name":"xxx","value":"xxx"})

  常用场景：跳过登录，直接注入 cookie 进入页面

❌️ 常见坑

• HttpOnly=True：Selenium 的 JS 无法读取这个 cookie，只能浏览器自动携带
• Domain/Path 不对，cookie 不生效

2. Session 简介
   Session 叫会话，保存在服务器端。
   用户登录网站后，服务器开辟一块空间，保存用户信息（身份、权限等），同时生成一个唯一的 sessionId。
   这个 sessionId 一般会发给浏览器，存到 Cookie 里面。

流程一句话：
浏览器登录 → 服务端创建 Session，返回 sessionId → 浏览器把 sessionId 放到 Cookie → 之后每次请求自动带上 Cookie 里的 sessionId → 服务器拿 sessionId 查找服务端保存的用户信息，识别你是谁。

• 特点
  • 数据存在服务器，不是浏览器，相对 Cookie 更安全
  • 依靠 sessionId 来识别用户，sessionId 通常放在 Cookie
  • 有超时时间：长时间不操作，Session 过期，需要重新登录
  • 一个用户一次会话对应一个 Session

测试场景使用 Session

• Postman
  登录接口成功，响应头 Set-Cookie 会带回 JSESSIONID（Java 项目常见 sessionId 名称）。
  后续请求自动带上 Cookie，服务器通过 JSESSIONID 找到服务端 session，保持登录。
• Selenium UI 自动化
  不需要手动操作 session，浏览器自动管理 Cookie，自动携带 sessionId。
  如果清空浏览器 Cookie，sessionId 丢失 → 服务端找不到 session → 退出登录。

❌️ 常见坑

• Cookie 被禁用：session 机制会失效（部分网站会改用 URL 拼接 sessionId）
• Session 超时：脚本长时间不发请求，会话失效，用例报错需要重新登录
• 多用户并发：每个用户有独立 session，互不干扰
• 重启服务器：服务端内存 session 会全部丢失，所有人需要重新登录

3. Token 简介
   Token 中文叫令牌，是服务端发给客户端的一串加密字符串，作为用户身份凭证。

核心思想：不用在服务器保存用户会话数据。
登录成功后，后端把用户信息 + 过期时间等加密打包，生成 Token 返回给前端；
之后每次请求，客户端在请求头带上 Token，后端只需要解密校验签名，就能识别用户，不需要去查服务器内存里的会话记录。

完整流程

• 客户端发送账号密码，请求登录接口
• 服务器校验账号密码正确 → 生成 Token 返回给客户端
• 客户端保存 Token（可以存在 localStorage / Cookie）
• 后续所有接口请求，请求头带上 Token：Authorization: Bearer xxxxx.token.xxx
• 服务端拿到 Token，解密校验，确认身份，返回数据
• Token 过期 → 需要重新登录获取新 Token

核心特点

• 无状态：服务器不存储会话信息，减轻服务器压力，适合分布式 / 微服务
• 自带信息：Token 内部本身就包含用户 ID、权限、过期时间
• 有有效期：过期就失效，需要重新获取
• 跨域友好，适合前后端分离、APP、小程序

最常用：JWT（JSON Web Token），就是 Token 的一种标准格式

JWT 结构（三段，小数点.分隔）
header.payload.signature

• header 头部：加密算法、类型
• payload 载荷：存放用户信息（注意：明文，不要放密码！）
• signature 签名：加密校验，防止被篡改

测试实操（Postman）

• 调用登录接口，拿到返回的 token 字符串
• 在请求头添加：Authorization，值写 Bearer 拿到的token

Bearer 和 token 中间有空格！很多初学者漏空格导致鉴权失败

• 访问业务接口，后端校验 token，正常返回数据
• token 过期：接口返回 401 Unauthorized，需要重新登录拿 token

❌️ 常见坑

• payload 是明文，不能放敏感信息（密码）
• Bearer 后面空格不能丢，少空格直接鉴权失败，返回 401
• Token 过期状态码一般是 401
• Token 一旦签发，中途无法作废（缺点，不像 session 可以服务端直接删除）
• 不要手动修改 token 任意一段，签名校验失败直接失效

4. Cookie / Session / Token 三者对比（⭐️）

	Cookie	Session	Token(JWT)
存储位置	浏览器客户端	服务端	客户端（本地存储 /cookie）
服务端是否存数据	否	✅保存会话数据	❌无状态，不存会话
身份凭证	Cookie 本身	cookie 里存 sessionId	请求头 Authorization 携带 token
适用场景	传统网页	传统网页	前后端分离、APP、小程序
扩展性	差	差（集群要共享 session）	好，适合分布式

4种鉴权方式

1. Cookie + Session （老系统、web 后台常用）
   ✅原理

• 浏览器发送账号密码登录请求
• 服务器校验成功，在服务端保存 session，生成 sessionId
• 服务器把 sessionId 放到 Cookie，返回给浏览器
• 浏览器自动保存 Cookie，之后每次请求自动带上 Cookie
• 后端读取 Cookie 里的 sessionId，查到会话，确认已登录
  ✅ 测试特点（Fiddler/Postman）
• Postman：登录接口跑完，自动保存 Cookie；后续接口不用手动加
• Fiddler 抓包可以看到请求头里 Cookie: xxx
• ❗缺点：多端不好共享，移动端很少用；服务端保存 session，集群部署麻烦

2. Token 鉴权（现在前后端分离、APP 最常用，重点掌握）
   JWT 属于 Token 的一种
   ✅ 原理

• 登录提交账号密码，后端校验通过，生成 token 字符串返回给客户端
• 客户端（网页 / APP）自己保存 token（localStorage 等）
• 后面所有接口，请求头带上 token
  Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9xxxx
• 后端收到，解析 token，判断是否有效、是否过期，不需要在服务端存会话

Bearer 是令牌类型，后面空格 + token 字符串
✅ Postman 操作：登录接口提取 token，存入环境 / 集合变量，其他接口 Header 引用{{token}}
✅ JWT Token 结构（由 . 分成 3 段）

• 第一段：Header 算法信息
• 第二段：Payload 存放用户信息、过期时间（可以解码看到，不要放密码！）
• 第三段：签名，用来校验有没有被篡改

  优点：服务端不用存会话，适合分布式、APP、小程序
  缺点：token 一旦签发，没过期前无法直接作废

3. Basic Auth（简单鉴权，内部测试接口用得多）
   ✅ 原理：账号：密码 base64 编码，放在请求头
   Authorization: Basic YWRtaW46MTIzNDU2

base64 不是加密！只是编码，可以直接解码，不能用于生产环境。
Postman：Authorization 标签直接选 Basic auth，填入账号密码即可。

4. Apikey（开放接口，第三方调用）
   ✅ 原理：后端给调用方分配一个固定密钥 apikey
   传递方式二选一：

• 请求头 apikey: abc123456
• URL 参数 xxx.com/api/getData?apikey=abc123456

✅ 适用：第三方对接，比如天气、地图接口

缺点：密钥固定，如果泄露别人就能访问

5. 鉴权操作总结

• Cookie-Session：先调用登录接口，自动带上 Cookie，后面接口直接请求
• Token/JWT：登录接口返回 token → Tests 脚本提取 token 存变量 → 其他接口 Header 添加 Authorization
  Header：Authorization: Bearer {{token}}

6. 测试常见鉴权相关 bug

• 没带凭证 → 401 Unauthorized（未认证）
• token 过期 / Cookie 失效 → 401
• 凭证正确，但账号没有该接口权限 →403 Forbidden（禁止访问）
• token 被篡改 →401

7. 快速区分记忆

• 传统 Web 管理后台：Cookie+Session（你的 CMS 项目）
• 前后端分离、APP：Token (JWT)
• 第三方开放接口：ApiKey
• 简单内部调试：Basic Auth

总结：接口鉴权是确认访问者身份和访问权限；常用方案有 CookieSession、JWT Token、Basic Auth、ApiKey。CookieSession 会话保存在服务端；JWT 把用户信息放在 token，服务端不保存会话。

同步接口与异步接口

1. 同步接口
   客户端发请求 → 服务器立刻处理 → 处理完成后，一次性返回结果；客户端一直等待服务端处理完毕，才能继续往下执行。

一句话：发请求，原地等结果，拿到结果才结束。

流程

• 客户端发起请求
• 服务端接收，同步执行业务逻辑（查询、计算）
• 业务处理完成
• 服务端返回最终结果
• 客户端收到响应，请求结束

✅ 特点

• 客户端阻塞等待，没返回结果不能做别的事
• 响应体直接返回最终业务数据
• 逻辑简单，好调试
• 如果业务耗时很长，客户端长时间等待，容易超时
  📌 例子：查询用户信息、登录接口，点查询立刻返回数据。

2. 异步接口
   客户端发起请求 → 服务端不等待业务全部处理完，直接先返回一个响应（一般返回任务 ID）；
   服务端在后台慢慢执行业务；客户端拿到任务 ID，后续单独查询任务状态，等任务完成再获取结果。

一句话：提交任务，马上收到 “收到指令”，后台慢慢跑，之后查任务进度拿结果。

流程

• 客户端提交任务请求
• 服务端接收任务，放入后台队列
• 立刻返回：任务 task_id（不是最终业务结果！）
• 服务端后台异步处理耗时任务（文件导入、报表生成、大数据统计）
• 客户端拿着 task_id，循环调用【查询任务状态接口】
• 状态 = 成功 → 获取最终数据；状态 = 失败 → 获取失败原因

✅ 特点

• 请求快速响应，不会长时间阻塞
• 适合耗时任务：大批量数据导入、导出、报表生成
• 需要多一步：轮询查询任务状态
• 链路更长，自动化测试需要处理轮询逻辑

📌 例子：批量导入用户、生成 Excel 报表

3. 对比

对比项	同步接口	异步接口
响应内容	直接返回最终业务结果	先返回任务 ID，不返回最终数据
客户端行为	阻塞等待，一直等处理完成	提交任务后即可释放，后续轮询查状态
适用场景	短时间就能完成的操作	耗时较长的任务（文件、大数据）
接口数量	1 个接口完成	至少 2 个：提交任务接口 + 查询任务接口
超时风险	业务慢容易超时	提交接口不会超时；任务本身可能执行失败

4. 测试重点【postman/自动化】
   ✅ 同步接口

• 直接发请求，校验响应数据、状态码
• 重点测：正常场景、参数错误、边界值

✅ 异步接口

测试步骤：

1. 调用【提交任务接口】，拿到 taskId
2. 循环调用【查询任务接口】，判断 status 状态
   • running：继续等待
   • success：校验返回结果
   • fail：断言失败信息

自动化里不能写死 sleep，最好加轮询等待（类似显式等待）

❌️常见坑

• 误以为异步接口第一次请求会返回结果，拿到 taskId 就结束用例 → 用例假成功
• 轮询不加最大次数限制，死循环一直查状态
• 任务后台执行失败，但是提交接口返回 200，容易漏测失败场景