七个步骤覆盖 API 接口测试

接口测试作为最常用的集成测试方法的一部分，通过直接调用被测试的接口来确定系统在功能性、可靠性、安全性和性能方面是否能达到预期，有些情况是功能测试无法覆盖的，所以接口测试是非常必要的。首先需要对接口测试的基本信息做一些了解：

接口测试的意义

低 - 低成本

因为接口的相对稳定性，不需要大量的重新编写，做好基础的维护，用例的扩充，能满足日常的使用范围

稳 - 相对稳定

当接口自动化创建后，可以相对稳定的运行。接口相对稳定，不会频繁更换，顶多增加字段或者新增接口（相对于UI测试来说，维护、编写成本很大，实际过程中一点点的放弃了UI自动化测试）

快 - 执行速度快，反馈速度快

涉及到持续集成，把接口集成到 jenkins 上，自动触发或定时任务触发，触发后就反馈结果。

测试和监控 API 对确保应用程序的功能和性能变得越来越重要，我们在本文中可以详细了解完成API 测试的操作步骤，详细信息请参照下文：

七个基本步骤

1. 了解 API 的范围

在尝试测试 API 之前，了解 API 的作用及其职责是至关重要的。此步骤应从访问 API 文档开始。应该手动对 API 端点进行一些调用，以深入了解它们的工作方式以及它们返回的数据

2. 了解用户流程

在这一步中，应该超越单个 API，查看使用它的应用程序。尝试并了解用户如何使用这些应用程序，以及它们的使用会触发哪些 API 调用。这将帮助你了解API在实际生活中使用的场景，并使你能够开发测试，以测试和验证 API 在实际生活中的使用方式。

例如，如果直接从 Web 应用程序调用 API，可以使用浏览器开发人员工具记录对 API 发出的所有请求并检查请求和响应负载。这有助于了解 API 的使用方式。

3. 编写API测试

测试接口选择

项目有几十个或者几百个接口。一方面，不可能对每一个接口都做自动化测试，所以要分主要接口和非主要接口；另一方面，也不是每个接口都适合做自动化测试，所有要分稳定接口和不稳定接口；还有一方面，有些接口只能调用一次，所有要分可重复执行接口和不可重复执行接口。当然其中还有其他银色影响接口的选择，要根据实际情况进行筛选，然后对接口逐步分析，来确定最后需要自动化测试的接口，做到可以在接口层面成本最大化。

注册接口

这是一个重要的接口，但却是不可重复执行的接口，因为同样的数据第二次是无法注册成功的，所以这个接口不适合做这类自动化。

登录接口

这个接口是可以重复执行的，而且相对于来说不太会随意改动的借口，所以这个接口适合做自动化。

用户信息查询

这个接口可以反复请求，适合做自动化。

结合自身项目并在具体的实践过程中，我们会发现大多数做自动化的接口都是查询接口，因为不涉及对数据库的改动，仅仅是查询可以重复操作的，而且返回数据也是相同的，便于对返回结果的判断验证。

4. 覆盖异常情况和边界值情况

上一节介绍 API 测试接口的选择，并验证它在“正常”使用情况下是否按预期工作。在这一步中，判断 API 在边界值和异常情况下的行为是否正确。例如：

是否试图让一个不存在的实体返回正确的错误代码（404 响应）？
如果提供了错误数据类型的参数（400 响应），API 是否会失败？
如果我们尝试访问我们没有权限的实体（401 响应）会发生什么？

这一步的技巧是查看HTTP 错误代码列表（尤其是 4xx 范围 - 用户错误）并尝试创建生成这些代码的场景。

5. 针对 Dev 和 Stage 环境执行测试

自动化需要一个干净的测试环境，不然很难重复运行起来。自动化测试要做到绝对只能也是不可能的，尤其运行过程中会遇到脏数据活着异常就会中断。首先需要在测试环境跑一遍正常流程，中间通过抓包获取数据信息，一方面需要确定这些数据作为自动化测试的数据基础，另一方面需要了解数据结构是什么，可能是包含列表的字典，也可能是一个纯元组。前提是可以测试通过一套流程，不然获取这些数据没有必然意义。

编写测试后，你应该能够开始在非生产环境中使用它们并看到它们通过。理想情况下，如果正确编写了测试，应该可以通过向不同环境传递不同的变量来针对不同环境执行测试。这可以帮助你开始验证 API 的开发版本。

6. 持续集成 Jenkins

Jenkins 是一个功能强大的工作，测试人员可以根据各自的测试需求灵活运用其中的部分功能。引进持续集成思想是为了帮助测试人员提高测试效率，一旦可以看到针对开发/阶段环境运行的所有测试，你就可以将它们连接到你的 CI/CD 管道，以便在你推送新代码时开始自动化测试过程。这可以通过源代码管理工具（如 GitHub 或 GitLab）或构建工具（如 Jenkins 或 CircleCI）来完成。这有助于保持测试运行并“强制”使测试保持最新，因为无法在测试失败的情况下推送代码。