接口测试

接口测试原理
接口测试是软件工程中验证系统组件间接口交互正确性的测试方法，核心原理是通过模拟调用接口、传递输入参数，验证接口输出是否符合设计预期。

核心原理拆解
接口本质是系统间数据交互的标准化桥梁，接口测试的核心逻辑围绕三个环节展开：

‌请求构造‌：根据接口文档，构造包含合法输入、异常边界、非法参数的各类请求数据，覆盖不同业务场景
‌请求发送‌：通过工具向被测接口发起调用，获取接口返回结果
‌结果验证‌：对比实际返回结果与预期设计，验证接口的功能正确性、性能稳定性、安全性是否符合要求
举个通俗的例子：用户登录接口，输入参数为username和password，接口需要验证「用户是否存在、密码是否正确」，并返回token和用户信息。接口测试需要覆盖「正常登录、错误密码、空参数、超长用户名」等场景，验证接口在不同输入下的返回结果和容错能力符合设计要求。

核心测试目标与类型
接口测试的核心目标是‌保证系统间协作的正确性和稳定性‌，常见测试类型分为四类：

1.功能测试

‌参数校验‌

• ‌必填项检查‌：验证不填必填参数时接口是否正常拦截并返回对应错误
• 参数格式校验：验证参数类型、长度、格式（手机号/邮箱等）不符合要求时，接口能否正确识别并返回提示
• 参数边界值：覆盖参数的上下限、空值、异常值，验证接口边界处理逻辑正确

‌功能逻辑验证‌

• 验证正常输入情况下，接口返回结果与预期一致，业务逻辑能正确执行
• 验证接口幂等性：对于重复调用的接口（如支付、创建订单），重复请求不会产生副作用（如重复扣款）
• 异常场景容错处理：验证依赖服务超时、下游接口异常时，接口有合理的降级和错误处理，不会导致系统崩溃

‌数据交互正确性‌

• 验证接口返回参数完整，关键字段内容符合预期格式和含义
• 验证上下游模块数据传递正确，修改接口数据后，下游依赖接口能正确获取更新后的值

2.性能测试

• ‌响应时间验证‌：验证单接口正常请求下，平均响应时间、95分位响应时间符合性能指标要求
• ‌吞吐量验证‌：验证接口在预期并发请求下，每秒能处理的请求数（TPS）满足业务需求
• ‌并发稳定性验证‌：验证长时间高并发压测下，接口不会出现内存泄漏、连接泄漏，不会导致系统宕机
• ‌压力极限验证‌：逐步加压找到接口性能瓶颈，确认接口能承受的最大并发量，提前预判系统扩容需求

3.安全测试

• ‌权限校验验证‌
  越权访问测试：验证未授权用户无法调用需要权限的接口，低权限用户无法访问高权限接口资源
  身份令牌校验：验证令牌过期、伪造、篡改后，接口能正确拦截拒绝访问
• ‌注入攻击防护‌：验证接口对SQL注入、XSS跨站脚本攻击输入有过滤拦截，不会导致恶意代码执行或数据泄露
• ‌敏感信息防护‌：验证接口返回结果不包含明文密码、密钥、用户隐私等敏感信息，不会泄露系统内部数据
• ‌重放攻击防护‌：验证接口对重复请求有校验机制，不会被攻击者截获请求后重复调用执行恶意操作

4.其他通用测试

• 兼容性测试：验证接口适配不同协议版本、不同系统环境下都能正常工作
• 文档一致性：验证接口实际功能、参数、返回结果与接口文档描述一致，避免文档和实现脱节

cookie,session和token的区别
Cookie、Session、Token三者都是‌维持用户登录会话状态的方案‌，核心区别在于存储位置、应用场景和设计思路不同，通俗对比如下：

对比维度	Cookie	Session	Token
‌本质‌	客户端存储会话信息的小文本文件	服务端存储用户状态的机制	加密签名后的用户身份凭证
‌存储位置‌	存在用户浏览器端	存在服务端（内存/数据库/Redis）	一般存在客户端（LocalStorage）
‌安全性‌	容易被XSS攻击窃取，敏感数据不建议存	相对安全，不会暴露给客户端	可防CSRF攻击，签名防篡改，比Cookie安全
‌扩展性‌	不适合分布式集群，多服务端需要同步Session	分布式需要额外做Session共享	天然支持分布式，服务端无需存储，直接验证即可
‌性能‌	每次请求自动携带，服务端无需查询	需要服务端查询存储，高并发有性能压力	服务端只需要验签，无需查询，性能更高

通俗理解+工作流程

1. Cookie -> 客户端存信息的小纸条
   你第一次登录网站，服务器会给你一张写着你身份的「小纸条（Cookie）」存在你浏览器里，之后你每次访问网站，浏览器都会自动把这张小纸条带给服务器，服务器就知道你是谁了。

缺点：如果攻击者通过XSS脚本偷了你的小纸条，就能冒充你登录；而且多服务器部署时，每个服务器都需要认这张纸条，不方便。
2. Session -> 服务端登记本
Cookie存的是你的SessionID，真正的用户信息存在服务器的「登记本（Session）」上：你登录后，服务器给你一个SessionID写在Cookie里，你每次带ID过来，服务器去登记本查你的信息。

缺点：高并发场景下，服务器要存大量Session，占资源；分布式系统需要把Session同步到所有服务器，维护成本高。
3. Token -> 加密签名的身份凭证
你登录后，服务器把你的身份信息加密签名，生成一张「防伪门票（Token）」发给你，你存在客户端，每次请求把门票带给服务器，服务器验票确认身份即可，‌服务器不需要存门票‌。

优势：天然支持分布式/微服务，服务端不需要存储，高并发性能好，也能防CSRF攻击，是现在前后端分离项目的主流方案。

在请求中携带token的三种位置

1. 最常用：放在请求头Authorization中

Authorization: Bearer <你的Token值>

例如：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

2. 放在URL参数中

https://api.example.com/data?token=eyJhbGciOiJIUzI1NiIs...

3. 放在请求体中

把Token和业务参数一起放在POST请求的请求体中，比如：

{
  "username": "test",
  "token": "eyJhbGciOiJIUzI1NiIs..."
}