《软件测试52讲》读书笔记 —— API测试怎么作

前言

文章中还介绍了测试工具，好比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 测试框架中包含对应的工具类去访问和操做数据库或者消息队列等