接口测试的核心思维（基础篇）

1.为什么会进行接口测试？

• 早期发现问题，降低修复成本

  • 当我们服务端已经完成，而前端还未进行开发的时候。我们可以通过接口测试避免前端的交互直接进行服务端的测试。

  • 接口测试也能够更早介入项目的测试，降低修复成本。

• 提高测试效率，覆盖更多的场景

  • 接口测试速度更快：相比UI测试需要模拟用户操作，接口测试直接通过HTTP请求调用，执行效率更高

  • 覆盖更全面的场景：

    • 正向：正常流程、异常流程
    • 反向：例如：支持对应的反向就是退款
    • 边界条件

• 适应于微服务架构和分布式系统

  • 在微服务架构中，系统被拆分未多个独立服务，接口时服务间通信的唯一方式
  • 接口测试能验证：
    • 服务间调用的正确性
    • 分布式事务的一致性

• 支持自动化测试和持续集成

  • 接口测试用例易于自动化
  • 自动化接口测试可集成到CI/CD流程中，实现：
    • 代码提交后自动运行测试。
    • 快速反馈问题，阻断有缺陷的代码进入生产环境。

2.接口测试的方法论

• 从工具到框架的进阶：

  • Postman、jmeter等工具进行接口测试
  • 编写接口测试脚本，再到封装测试框架，逐步深入

• 抽象与封装：通过抽象和封装，将接口测试脚本转化为可复用的测试框架，提高测试效率

• **支持多协议测试：**接口测试不仅限于HTTP协议，还需支持其他协议的测试，以满足不同项目的需求。

• 持续集成

3. 接口测试

3.1 什么是接口？

3.1.1 接口的基础知识

• 接口的定义：接口是不同系统、模块或组件之间交互桥梁，它定义了双方如何传递数据、调用功能以及遵循的规则。

• 接口的本质：其实就是一种契约，遵循一种形式：在开发前期，约定接口会接收什么数据，在处理完成后，它又会返回什么数据。

3.1.2 接口的常见类型和场景

• 软件接口

  • 代码级接口：函数、类或模块之间的调用规则

    def calculate_sum(a: int, b: int) -> int:  # 接口定义：输入两个整数，返回整数
        return a + b
    

    • 作用：隐藏实现细节，让代码模块化（例如调用一个加密函数时）

  • API（应用程序接口）

    • Web API:通过HTTP协议传递数据（如RESTful API、GraphQL）
    • gRPC(远程过程调用)：Googel开发的高性能RPC框架，支持多语言，用于为服务间通信
    • 消息队列：通过Kafka、RabbitMQ异步传输数据（如订单创建后发送消息通知库存系统）

• 硬件接口

  • 物理接口：USB、HDMI等硬件连接标准
  • 驱动接口：操作系统调用打印机、摄像头的统一指令

• 网络接口

  • TCP/IP协议栈：定义数据分包、路由、重组规则（如网页浏览）。
  • WebSocket：长连接实现实时数据推送（如股票行情）。

3.1.3 为什么需要接口？

• 解耦与协作

  • 前端和后端通过API交互，可以独立开发（如前端用React，后端用Java）
  • 微服务架构中，订单服务和库存服务通过接口通信，互不影响。

• 标准化通信

  • 定义清晰的请求参数、响应格式和错误码（如HTTP状态码200表示成功，500表示服务器错误）

• 复用性

  • 天气预报接口可被多个App（打车、旅游）重复调用，无需重复开发。

• 安全性

  • 接口通过OAuth 2.0认证、HTTPS加密传输，保护敏感数据（如银行转账接口）。

• 扩展性：新增功能只需实现现有接口（如插件系统）。

3.1.4接口的典型问题

• 兼容性：新版接口修改了参数，旧版客户端调用失败。
• 性能瓶颈：高并发时接口响应变慢（如秒杀系统）。
• 安全问题：未加密的接口泄露用户隐私数据。

3.1.5 接口类型是由谁决定的

• 人员：架构师
• 参照方法：
  • 系统以前技术栈的延续
  • 系统外部依赖系统的需求
  • 一些公共技术规划让系统更容易扩展

3.2 什么是接口测试？

3.2.1 接口测试的基础知识

• 接口测试的定义：模拟调用方，通过接口通信来检测被测接口的正确性和容错性
• 接口测试的核心目标
  • 功能正确性：验证接口是否按需求正确处理输入并返回结果
  • 数据完整性：检查请求参数和响应数据的格式、类型、取值范围（如字段是否必填、金额不能为负数）
  • 异常处理能力：模拟网络超时、参数缺失、非法输入等异常场景、验证接口的容错性和错误提示
  • 安全合规性：检查接口的身份验证（如Token）、数据加密（如HTTPS）、权限控制（如普通用户无法访问管理员接口）。
  • 性能基准：评估接口的响应时间、吞吐量（如每秒处理1000次请求）、资源占用（CPU/内存）。

3.2.2 接口测试的内容（分层测试）

• 单接口测试
  • 定义：针对于单个接口的独立测试，关注接口自身的功能、参数、异常处理等，不依赖于其他接口的上下文
  • 测试重点：
    • 上述的接口测试的核心目标
• 业务流程接口（串联接口）
  • 定义：通过多个接口的顺序调用，验证跨接口的业务流程是否完整，数据是否一致。
  • 测试重点：
    • 数据传递：上游接口的输出是否作为下游接口的输入正确传递（如订单ID贯穿支付流程）
    • 状态一致性：多个接口操作后的系统状态是否符合预期（如创建订单后库存减少）
    • 事务完整性：跨接口操作是否具备原子性（如支付失败后订单状态回滚）
    • 依赖管理：第三方服务（如短信网关）异常时，业务流程的降级策略是否生效。
  • 注意事项：接口测试更关注数据流驱动的业务流程，**而非代码异常或边界问题（这些问题已在单接口测试中覆盖）

3.2.3 接口测试与界面测试之间的区别

	接口测试	界面测试
测试对象和范围	数据交互层	用户可见的功能和流程
验证目标	数据的准确性、协议合规性、隐藏逻辑（数据库事务、加密算法、第三方服务调用）	是否符合需求文档实现、交互体验、端到端的流程
测试效率	更早介入、速度快、覆盖深层逻辑	依赖于UI完成、执行熟读较慢、容易受到UI变更影响。

接口测试脱离界面-特殊情况：一些接口的控制输入无法通过界面测试，这是因为在前端已经设置相关的异常拦截，但对于空值有必要进行验证的，这些只能通过接口进行测试。 体现了：接口测试相对界面测试更加全面。

两者关系：互补而非对立

1. 接口测试为功能测试奠基：
   • 若接口存在逻辑错误（如扣款金额计算错误），功能测试必然失败。
   • 先通过接口测试确保底层逻辑正确，再通过功能测试验证端到端流程。
2. 功能测试覆盖接口测试盲区：
   • 接口测试无法验证前端交互（如页面元素渲染、动画效果）。
   • 跨系统的数据展示一致性（如订单列表页与详情页的数据同步）。
3. 成本与效率平衡：
   • 接口测试成本低、效率高，适合覆盖核心逻辑。
   • 功能测试更贴近用户，但维护成本高，需合理选择覆盖范围

3.2.4 接口测试的策略

• 关键指标：接口覆盖率（目标100%）、自动化率（>90%）、CI/CD流水线集成率
• 测试策略：正向用例（30%）+ 异常用例（50%）+ 安全用例（20%）

4.方法论

4.1 没有任何文档我们该怎么测试

4.1.1 一个理想的提测项目

• 产品需求：它描述了系统的业务逻辑，通过这个文档，你才能知道怎么来设计测试用 例；
• 原型设计：它会更加直观地告诉你系统的使用逻辑，这对测试用例的设计、对系统的前 期认知都是有辅助作用的。
• 接口文档：它详细地描述了后端接口的访问方式和参数说明，使用这个输入项才能开展 接口测试用例的设计、测试脚本的准备和测试数据的构建
• 单元测试脚本。它是保障提测质量的必要环节，是研发工程师自测的一个有效手段，可 以保障提测项目的提测质量

4.1.2 你应该知道被测系统SUT

• 手机APP
• Web服务
• 微服务接口

4.1.3 接口测试的文档

​ 接口测试的文档是由开发工程在设计和开发产生的产物—接口测试的文档，产品经理和测试经理一般都会要求写一个接口测试的文档，方便我们进行接口测试用例的设计和执行，保证项目的正常运行。

• 注意：

  • 开发工程师在设计和开发接口的过程，会不断的维护接口文档。 在进行接口设计开发评审的时候，就确定不轻易改动，否者会加大人力成本！

  • 如果开发工程师没有给我们任何的有价值的文档。我们进行询问还总是说自己”没空“!!! 只能我们自己去找它m。

• 接口文档的内容

  • 方法
  • 访问路由
  • 输入参数的含义
  • 返回参数的含义
  • 以及一个完整的例子

• 保存方式

  • Word文档

  • Swagger工具的形式:一个接口文档的存在形式，是一个从代码生成 的、以 Web 服务形式存在的接口文档，它可以伴随代码的变更同步变化，这就减少了很多 开发工程师和测试工程师之间的沟通成本。

4.1.4 三部曲（方法）

• 借助一些工具的辅助来完成接口分析（Fiddler、Charles、mitmproxy等）

  • 通过工具截获一些接口信息
  • 通过分析接口的访问方式、参数等信息整理出一些问题。

• 和研发工程师沟通这些问题，将以下不知道参数含义、参数取值范围等问题问清楚

• 重复上述步骤

• 询问内容：

  • 参数的含义以及来源

    • 参数实际的自然语言的名字，相对应就知道对应的函数的作用

    • 参数的来源

      • 上游接口的响应数据作为下游接口的输入，哪一个是上游返回的参数
      • 系统自动生成参数

    • 参数的作用域

      • 访问周期一直存在吗？
      • 是否存在于其他的业务分支

    • 返回值的含义

4.2新项目和存量项目

• 新项目：需要项目经理、测试经理推动开发人员维护完善的接口文档，从项目流程保证和完善
• 存量项目：三部曲：工具辅助，分析问题，询问解惑

4.3 测试用例设计中的参数

• 单接口测试中的参数类型
  • 参数（字段）的常见情况：为空、正确、错误。
  • 额外考虑：虽然有人建议考虑参数类型（如数字、中文、英文、敏感词、特殊字符等以及极大极小值），但文件指出这些内容更多属于安全测试范围，接口测试中不一定需要过分考虑。
• 业务流程接口测试中的参数类型
  • 主要关注：业务逻辑错误，而非参数类型的细节。