前言

文章中还介绍了测试工具，比如cURL、postman，单API如何测试；但这些都是偏基础的东西，且网上教程各式各样，就不再赘述了；这里主要讲的就是关于复杂场景的API测试要如何应对

 

API测试的流程

  1. 准备测试数据（这是可选步骤，不一定所有 API 测试都需要这一步）
  2. 通过 API 测试工具，发起对被测 API 的 request
  3. 验证返回结果的 response

 

如何应对复杂场景的API测试？

测试场景一：被测业务操作是由多个API调用协作完成

背景

一个单一的前端操作可能会触发后端一系列的API调用，此时API的测试用例就不再是简单的单个API调用，而是一系列API的调用

 

存在的情况

  • 存在后一个API需要使用前一个API返回结果的情况
  • 需要根据前一个API的返回结果决定后面应该调用哪个API

 

存在问题

高效地获取单个前端操作所触发的API调用顺序

 

解决上述问题思路

  1. 通过网络监控手段，捕获单个前端操作时所触发的API调用顺序，譬如Fiddler、Charles等抓包工具
  2. 也可以通过用户行为日志，通过大数据手段来获取调用顺序

 

测试场景二：API 测试过程中的第三方依赖

背景

  • API 之间是存在依赖关系的，比如你的被测对象是 API A，但是 API A 的内部调用了 API B，此时如果由于某种原因，API B 在被测环境中处于不可用状态，那么 API A 的测试就会受到影响。
  • 在单体架构下，通常只会在涉及到第三方 API 集成的场景中才会遇到这个问题，所以还不算严重。但是，在微服务架构下，API 间相互耦合的依赖问题就会非常严重。

 

解决问题的核心思路

启用 Mock Server 来代替真实的 API

 

测试场景三：异步 API 的测试

什么是异步API

调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调（Callback）的 API

 

对异步 API 的测试主要分为两个部分

  1. 测试异步调用是否成功：检查返回值和后台工作线程是否被创建两个方面就可以了
  2. 测试异步调用的业务逻辑处理是否正确

 

测试异步调用的业务逻辑复杂性

因为异步 API 通常发生在一些比较慢的操作上，比如数据库 I/O、消息队列 I/O 等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力。在实际工程项目中，这些能力一般会在测试框架级别提供，也就是说要求 API 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等