REST API 测试策略：我们应该测试什么？

任何程序或系统的 API 层都是最关键的软件组件之一。它是连接客户端到服务器（或一个微服务到另一个微服务）的通道，驱动业务流程，并提供给用户带来价值的服务。
一个面向客户的公共 API 暴露给最终用户，它本身就变成了一个产品。如果它崩溃了，所要面临风险不仅仅是单个应用程序，而是围绕它构建的整个业务流程链。
Mike Cohn 著名的测试金字塔将 API 测试放在服务级别（集成），这表明我们所有测试中约有 20% 或更多应侧重于 API（确切百分比不太重要，并且根据我们的需求而异）。
在有了单元测试的坚实基础后，API 测试为系统提供更高的可靠性。
API 测试速度快，回报率高，并简化了业务逻辑、安全性、合规性等应用方面的验证，覆盖了与用户更接近的接口，且没有 UI 测试的脆弱性。如果 API 是提供给用户的最终服务，那么 API 测试实际上将成为端到端测试，并且应涵盖完整的用户案例。
因此，API 测试的重要性是显而易见的。已经有很多资料介绍了如何进行接口测试 —— 手动测试、自动测试、测试环境、工具、库和框架，等等。。。
然而，无论你会使用什么 ——Postman、JMeter、pytest、或者其他的专业工具 —— 在动手之前，我们首先要确定一个东西：测试什么

1.API 测试策略

测试策略是对测试需求的高级描述，从中可以从中导出详细的测试计划，并指定各个测试方案和测试用例。我们首先关心的是功能测试 —— 确保 API 正常工作。
API 功能测试的主要目标是：

• 确保实现按预期正确运行 —— 没有 BUG！
• 以确保实现按要求规范（以后成为我们的 API 文档）中指定的那样工作。
• 以防止代码合并和发布之间的回归。

2. API 即契约

API 本质上是客户端与服务器之间，或两个应用程序之间的契约。
在开始任何实施测试之前，重要的是要确保契约正确。首先可以通过检查规范（例如 Swagger 或 OpenAPI）并确保端点的名称正确，资源及其类型正确地反映对象模型，没有缺少功能或重复功能，并且资源之间的关系正确反映在 API 中。
上面的准则适用于任何 API，但为简单起见，在本文中，我们假设使用最广泛的 Web API 体系结构 REST over HTTP。如果 API 设计为真正的 RESTful API，则重要的是要检查 REST 契约是否有效，包括所有 HTTP REST 语义，约定和原则。

3. 测试 API 的哪些方面？

既然我们已经验证了 API 契约，我们就可以考虑要测试什么了。无论是要考虑自动化测试还是手动测试，我们的功能测试用例都具有相同的测试动作，是更广泛的测试场景类别的一部分，都属于三种测试流程。
API 测试动作
每个测试都包含测试动作。这些是测试每个 API 测试流程需要采取的单独操作。对于每个 API 请求，测试都需要采取以下措施：
1. 验证正确的 HTTP 状态代码 例如，创建资源应返回 201 CREATED，不允许的请求应返回 403 FORBIDDEN，等等。
2. 验证响应有效负载 检查有效的 JSON 正文和正确的字段名称、类型和值，包括错误响应也有检查。
3. 验证响应头 HTTP 服务器标头对安全性和性能都有影响。
4. 验证正确的应用程序状态 这是可选的，主要适用于手动测试，或者可以轻松检查 UI 或其他接口时。
5. 验证基本性能的合理性 如果操作成功完成，但花费的时间不合理，则测试将失败。
测试场景类别
我们的测试用例属于以下常规测试场景组：

• 基本的正向测试（快乐路径）
• 带有可选参数的扩展正向测试
• 有效输入的反向测试
• 无效输入的反向测试
• 破坏性测试
• 安全、鉴权和权限测试（不在本文的讨论范围之内）

快乐路径测试检查 API 基本的功能和最低验证标准。然后会进行扩展的正向测测试。接下来做反向测试（否定测试），我们希望应用程序在用户 “正确的输入”、“错误的输入” 等不同的场景中，都能优雅的进行处理。
破坏性测试是否定测试的一种更深层形式，在这种形式中，我们有意尝试破坏 API 以检查其健壮性（例如，发送巨大的有效载荷主体以试图使系统溢出）。

4.测试流程

让我们区分构成我们的测试计划的三种测试流程：
1. 隔离测试请求 —— 执行单个 API 请求并相应地检查响应。
这些基本测试是我们应该开始的最低限度构建块，并且如果这些测试失败，则没有理由继续进行测试。
2. 具有多个请求的多步骤工作流 —— 测试一系列常见的用户操作请求，因为某些请求可能依赖于其他请求。
例如：

1. 我们执行一个 POST 请求，该请求创建一个资源，并在响应中返回一个自动生成的标识符 ID。
2. 我们执行 GET 请求发送该 ID，检查该资源是否存在
3. 我们使用 PATCH 请求更新该资源新数据，然后再次调用 GET 请求以验证新数据
4. 最后，我们删除该资源，然后再次使用 GET 来验证它不再存在。

3. 结合 API 和 UI 测试–这主要与手动测试有关，在此我们要确保 UI 和 API 之间的数据完整性和一致性。
我们通过 API 执行请求，并通过 Web 应用程序 UI 验证操作，反之亦然。这些完整性测试流程的目的是确保尽管资源通过不同的机制受到影响，但系统仍保持预期的完整性和一致的流程。

5. API 示例和测试矩阵

 

现在，我们可以将所有内容表示为可用于编写详细测试计划的矩阵（用于自动化测试或手动测试）。
假设我们的 API 子集是 / users 端点，其中包括以下 API 调用：

API 调用	动作

其中 *{id} 是 UUID，所有 GET 端点都允许使用可选查询参数 filter*，sort，skip 和 limit 进行过滤，排序和分页。

＃	测试场景	测试动作	测试动作说明

上表得出的测试用例应根据我们的需求，资源和优先级来涵盖不同的测试流程。

6. 功能测试之外

遵循上面的测试矩阵应该会生成足够的测试用例，以使我们保持一段时间的忙碌，不过也提供 API 的良好功能覆盖。通过所有功能测试意味着 API 的成熟度很高，但是不足以确保 API 的高质量和可靠性。
在本系列的下一篇文章中，我们将介绍以下对 API 质量至关重要的非功能性测试方法：
安全与授权

• 检查 API 是否根据正确的安全原则进行设计：默认拒绝，安全失败，最低特权原则，拒绝所有非法输入等。
  • 正向：确保 API 对所有使用约定的身份验证方法，并拥有正确授权的请求做出正确响应
  • 反向：确保 API 拒绝所有未经授权的调用
• 角色权限：确保根据角色向用户公开特定的终结点。API 应该拒绝对用户角色不允许的端点调用
• 协议：根据规格检查 HTTP / HTTPS
• 数据泄漏：确保希望保留在内部的内部数据表示形式不会泄漏到响应有效负载中的公开 API 之外
• 速率限制，限制和访问控制策略

性能测试

• 在各种情况下（隔离和处于负载下）检查 API 响应时间，延迟，TTFB / TTLB
• 查找容量极限点，并确保系统在负载下运行正常，并在压力下正常运行

可用性测试

• 对于公共 API：从文档，登录，身份验证，代码示例等整个开发人员的整个过程中，进行手动的 “产品” 级测试，以确保用户无需了解我们的系统就可以使用 API。

---

首发于公众号：测试开发研习社，持续分享Python自动化测试开发内容，欢迎关注