《软件测试52讲》——API自动化测试篇

《软件测试52讲》

1、测试基础知识篇——（0~11讲）

2、GUI自动化测试篇——（12~21讲）

3、API自动化测试篇——（22~24讲）

4、代码测试篇——（25~27讲）

5、性能测试篇——（28~34讲）

6、测试数据准备篇——（35~38讲）

持续更新中~

API自动化测试篇

22——从0到1：API测试怎么做？常用API测试工具简介

API 测试的基本步骤

　　主要包括三大步骤：

　　　　（1）准备测试数据（这是可选步骤，不一定所有 API 测试都需要这一步）

　　　　（2）通过 API 测试工具，发起对被测 API 的 request

　　　　（3） 验证返回结果的 response

　　API测试工具：Postman+Newman

常见的典型复杂场景

　　（1）测试场景一：被测业务操作是由多个 API 调用协作完成、解决问题核心思路：通过网络监控的手段，捕获单个前端操作所触发的 API 调用序列。

　　（2）测试场景二：API 测试过程中的第三方依赖解决问题核心思路：启用Mock Server来代替真实的 API

　　（3）测试场景三：异步 API 的测试异步 API 的测试主要分为：一是，测试异步调用是否成功，二是，测试异步调用的业务逻辑处理是否正确。

23——API自动化测试框架

基于 Postman 和 Newman 的 API 测试，结合Jenkins

自动生成 API 测试代码和 Response 结果变化的自动识别

　　基于 Postman 的 Collection 生成基于代码的 API 测试用例

24——微服务模式下API测试要怎么做

单体架构

　　单体架构是早期的架构模式，并且存在了很长时间。单体架构是将所有的业务场景的表示层、业务逻辑层和数据访问层放在同一个工程中，最终经过编译、打包，并部署在服务器上。

微服务架构

　　微服务是一种架构风格。在微服务架构下，一个大型复杂软件系统不再由一个单体组成，而是由一系列相互独立的微服务组成。其中，各个微服务运行在自己的进程中，开发和部署都没有依赖。

微服务架构下的测试挑战

　　（1）过于庞大的测试用例数量

　　（2）微服务之间的耦合关系

基于消费者契约的API测试

　　基于消费者契约的 API 测试的核心思想是：只测试那些真正被实际使用到的 API 调用，如果没有被使用到的，就不去测试。

微服务测试的依赖解耦和 Mock Service