1、基本概念

1.1 接口分类

  • 服务间：webservice rpc-dubbo （服务框架）
  • 协议间：http、Socket、telnet协议接口（协议）
  • 代码类型：java、sdk提供的接口（语言）

  • 接口功能分类：增删改查

    1.2 接口测试定义

  • 通过模拟接口调用方的各种情况来测试接口提供方处理逻辑正确性、功能、性能

  • 接口调用方：客户端前端（移动端/PC 应用 & 浏览器）、软件内部|后台等

  • 接口提供方：后端、底层服务、第三方服务、内部平台服务、sdk 等

    1.3 接口测试与功能测试的异同点

    很多在功能测试中的方法论在接口测试中同样适用。接口测试其实并不难，只不过是测试的对象是接口

    相同点

  • 前提：已知输入内容和期望结果 （功能：交互需求 接口：接口文档 需求）

  • 过程：使用被测对象——使用功能|调用API（需要了解被测对象）

  • 目的：验证是否能实现期望的结果 （校验的重要性 没有校验结果的接口用例无价值）

    不同点

  • 对测试环境的依赖：接口测试在返回结果被呈现给客户前就完成了，对环境依赖小。比如浏览器、移动、pc端的功能测试，会受不同的客户端类型限制的影响，测试结果有不同。

  • 速度：接口测试无需界面加载/响应，短时间内可回归测试多条用例，速度比较快
  • 反馈问题效率：接口测试结合持续集成实践，可快速回归并准确发现问题。接口测试是自动化测试中的一种，和ui自动化一样，在用例质量好的情况下可以实现自动的高效测试

常见工具：抓包工具（fiddler、charles、wireshark 等）、postman、jmeter、java/python、接口平台等

2、接口测试流程

和功能测试的流程差不多：

  1. 接口需求评审：需求文档 | 需求评审意记录 | 开发时间计划
  2. 接口文档评审：接口文档评审意见记录
  3. 测试点编写和评审：测试点思维导图 | 测试点评审意见记录
  4. 用例编写和评审：测试用例 | 测试用例评审意见记录
  5. 用例调试及报 bug：可回归的测试用例 | bug 记录
  6. 计划执行及发报告：测试报告

    2.1 接口需求评审

  • who ——谁是使用者 接口调用方是谁
  • Where —— 待测 API 会在什么环境、场景下被使用 有哪些异常场景
  • Why ——待测 API 的目的是什么，是为了解决什么问题而开发的接口
  • What ——待测 API 处理的资源对象是什么 参数、请求、返回、异常状态码分别是什么
  • When ——被调用的时间 存不存在并发请求 性能相关的考虑
  • How ——接口是如何实现的 涉及的功能逻辑是怎样的 对其他系统有没有什么影响和交互

其他的需求评审和普通的功能测试一致（合理性、完整性、一致性、容错性、可测性、性能、安全）

2.2 接口文档评审

新增接口

  • 接口定义描述
  • 请求参数
  • 返回值状态码
  • 逻辑细节实现方案

  • 影响范围

    改动接口

  • 修改相关逻辑细节

  • 对模块内的影响范围

  • 对模块外的影响范围

    3、接口用例设计

    接口用例设计如何做到覆盖的全面性呢？
    图片1.png

    3.1 变量：控制变量法

    覆盖全面：梳理所有可变因素（输入条件 不遗漏头部参数）
    控制变量：1个测试用例内仅测试单一变量情况。无关变量保证正常1条用例检查1个变量的各种情况，有问题时方便定位

    3.2 变量值

    用边界值分析、等价类划分、错误推测法

    3.3 输出和变化：结果验证

    输出和变化：

  • 输出对象覆盖全面：接口状态码、返回字段值等

  • 输出情况覆盖全面：正常、异常
  • 后续变化：数据（mysql/redis）、MQ、触发其他event
  • APM 日志

把关注点放在输出条件上 包括后置的一些接口反应

3.4 场景：流程图分析法

举个例子，有个二维码登录接口：图片2.png
根据需求可以画出手机扫码登录的流程图：
图片3.png
通过流程图，可以取得一些条件：
图片4.png
这种流程图分析法除了分析单个接口内容的场景，还能拿来分析多个接口间资源的状态变化、增删改查。可以按流程安排测试顺序，方便前后置用例的编写
接口覆盖率检查：可以检测测试对代码分支的覆盖、逻辑覆盖

3.5 变量间的排列组合

用场景设计法、因果图法
例如，一个 updateNode 更新节点的接口，有一个 uid(节点自己的id)、和 newParentUid (新节点id)字段，根据场景可以设计出如下的用例：
图片5.png
当变量有多个且多个变量之间的排列组合会影响接口结果时，需要覆盖可变因素间的排列组合影响

4、接口测试常见误区

误区一

不需要维护接口列表，我只关注正在测的接口就行？
答：接口列表需要保证完整性、接口唯一性、实时更新性。了解相关接口才能高效的完成测试数据构造

误区二

把多个环境的变量设置在一起，通过不同变量名区分就行？
答：不利于用例管理，需要改用例里的变量名来区分环境 。用例数*环境数=用例总量的设计并不合理，需要用同名变量名，不同环境不同值的方式管理 环境变量。包括host、数据库、常用变量等

误区三

写个固定的变量值，这样写用例方便？
答：方便一时但难维护，可回归性差。动态取值的方式更有效

误区四

返回值校验——执行然后看一下返回值正不正确就行？
答：没有回归意义，没有校验的用例，不能复用，价值不高

误区五

接口测试就是测接口功能？
答：还需要关注性能、安全性