面向初学者的 10 个 API 测试技巧（SOAP 和 REST）

API 本质上是应用程序或软件内各层和系统的“中间人”。

API（应用程序编程接口）测试在消息层进行，无需 GUI。它是集成测试的一部分，用于确定 API 是否满足测试人员对功能、可靠性、性能和安全性的期望。

Web API 的 Web 服务分为两大类：SOAP 和 REST。

SOAP（简单对象访问协议）是 W3C 标准定义的标准协议，用于发送和接收 Web 服务请求和响应。 

REST（表述性状态传输）是使用 HTTP 的基于 Web 标准的架构。与基于 SOAP 的 Web 服务不同，RESTful Web API 没有官方标准。

以下是 API 测试需要了解的 10 个基本技巧：

了解 API 需求

在测试 API 之前，您需要回答以下问题以彻底了解 API 的要求：

• API 的用途是什么？

了解 API 的用途将为您准备好用于输入和输出的测试数据奠定坚实的基础。此步骤还可以帮助您定义验证方法。例如，对于某些 API，您将根据数据库验证响应；对于其他一些情况，最好根据其他 API 验证响应。

• 应用程序的工作流程是什么；该流程中的 API 在哪里？

通常，应用程序的 API 用于操作其资源，包括读取 (GET)、创建 (POST)、更新 (PUT) 和删除 (DELETE)。了解 API 的用途将为您准备好用于输入和输出的 API 测试数据奠定坚实的基础。

此外，此步骤还可以帮助您定义验证方法。例如，对于某些 API，您将根据数据库验证响应；对于其他一些情况，最好根据其他 API 验证响应。

例如，“创建用户”API 的输出将作为“获取用户”API 的输入进行验证。 “获取用户”API 的输出可以用作“更新用户”API 的输入，等等。

指定 API 输出状态

在 API 测试中需要验证的最常见的 API 输出是响应状态代码。

验证响应代码是否等于 200 来决定 API 测试是否通过或失败对于新的 API 测试人员来说很熟悉。这并不是一个错误的验证。但是，它并不能反映 API 的所有测试场景。

在全球标准中，所有 API 响应状态代码都分为五个类（或类别）。状态代码的第一位数字定义响应的类别。最后两位数字没有任何类别或分类作用。

第一位数字有五个值：

• 1xx（信息）：请求已收到并继续处理

• 2xx（成功）：请求被成功接收、理解并接受

• 3xx（重定向）：需要采取进一步的操作来完成请求

• 4xx（客户端错误）：请求包含错误语法或无法满足

• 5xx（服务器错误）：服务器无法满足明显有效的请求

然而，API 的实际响应状态码是由构建该 API 的开发团队指定的。因此作为测试人员，您需要验证是否：

• 代码遵循全球标准类

• 该代码在需求中指定。

专注于小型功能性 API

在测试项目中，总有一些 API 比较简单，只有一两个输入，例如登录 API、获取 Token API、健康检查 API 等。但这些 API 是必需的，被视为进入的“大门”更多 API。在其他 API 之前先关注这些 API 将确保 API 服务器、环境和身份验证正常工作。

您还应该避免在一个测试用例中测试多个 API。如果出现错误，那就很痛苦了，因为你必须按顺序调试 API 生成的数据流。让您的测试尽可能简单。在某些情况下，您需要调用一系列 API 来实现端到端的测试流程。然而，这些任务应该在所有 API 都经过单独测试之后进行。

组织 API 端点

一个测试项目可能有几个甚至上百个 API 进行测试。我们强烈建议您将它们组织成类别，以便更好地进行测试管理。它需要一个额外的步骤，但将极大地帮助您创建具有高覆盖率和集成度的测试场景。以 JIRA 的 API 为例：

同一类别中的 API 共享一些通用信息，例如资源类型、路径等。使用相同的结构组织测试将使您的测试可重用并可通过集成流程进行扩展。

利用自动化功能进行 API 测试

利用自动化尽可能快地加快 API 测试流程。以下是自动化 API 测试的一些显著优势：

• 测试数据和执行历史记录可以与 API 端点一起保存。这使得以后重新运行测试变得更加容易。

• API 测试稳定并小心更改。API 反映了系统的业务规则。API 的任何更改都需要明确的要求；因此测试人员可以始终对任何变化保持警惕并及时调整。

• 与 Web UI 测试相比，测试执行速度要快得多

• API 测试被视为黑盒测试，其中用户发送输入并获取输出进行验证。采用数据驱动方法的自动化（即在同一测试场景中应用不同的数据集）有助于提高 API 测试覆盖率

• 数据输入和输出遵循一些特定的模板或模型，因此您只需创建一次测试脚本。这些测试脚本还可以在整个测试项目中重复使用。

• API 测试可以在软件开发生命周期的早期阶段进行。具有模拟技术的自动化方法可以帮助在开发实际 API 之前验证 API 及其集成。因此，团队内部的依赖程度降低了。

选择合适的自动化工具

利用 API 测试自动化功能的进一步步骤是从市场上数百个选项中选择大多数或一组合适的工具。以下是选择 API 测试自动化测试工具时应考虑的一些标准：

• 该工具是否支持测试您的 AUT（被测应用程序）正在使用的 API/Web 服务类型？如果所选工具支持测试 RESTful 服务，而您的 AUT 使用 SOAP 服务，则没有意义。

• 该工具是否支持您的 AUT 服务所需的授权方法？以下是您的 API 可以使用的一些授权方法：

这是一项重要任务，因为未经授权您无法开始测试 API。

• 该工具是否支持从 WSDL、Swagger、WADL 和其他服务规范导入 API/Web 服务端点？这是一个可选功能。但是，如果您有数百个 API 需要测试，这将非常耗时。

• 该工具是否支持数据驱动方法？这也是一个可选功能。然而，如果该工具具有此功能，您的测试覆盖率将显着提高。

• 最后但同样重要的一点是，除了 API 测试之外，是否还需要进行其他类型的测试，例如 WebUI 或数据源？ API 测试在数据源和 UI 之间的业务层进行。所有这些层都必须经过测试是正常的。支持所有测试类型的工具将是一个理想的选择，以便您的测试对象和测试脚本可以在所有层之间共享。

选择合适的验证方法

响应状态代码说明请求的状态，而响应正文内容是 API 通过给定输入返回的内容。

API 响应内容因数据类型和大小而异。响应可以是纯文本、JSON 数据结构、XML 文档等。它们可以是一个简单的几个单词的字符串（甚至是空的），也可以是一个一百页的 JSON/XML 文件。因此，为给定的 API 选择合适的验证方法至关重要。

Katalon Studio 提供了丰富的库来使用匹配、正则表达式、JsonPath 和 XmlPath 来验证不同的数据类型。

一般来说，验证 API 响应正文内容有一些基本方法：

将整个响应正文内容与预期信息进行比较

此方法适用于具有静态内容的简单响应。动态信息如日期时间、递增的 ID 等都会给断言带来麻烦。

比较响应的每个属性值

对于 JSON 或 XML 格式的响应，很容易获取给定键或属性的值。因此，这种方法在验证动态内容或个体值而不是整个内容时很有用。

与正则表达式比较匹配

与验证各个属性值一起，该方法用于验证具有特定模式的数据响应以处理复杂的动态数据。

每种验证方法都有优点和缺点，并且没有一刀切的选择。您需要选择最适合您的测试项目的解决方案。

创建积极和消极测试

API 测试需要进行正向和负向测试，以确保 API 正常工作。由于 API 测试被认为是一种黑盒测试，因此两种类型的测试都是由输入和输出数据驱动的。对于测试场景生成有一些建议：

• 检测呈阳性验证 API 是否接收输入并返回要求中指定的预期输出。验证响应状态代码是否按照要求返回，无论是返回 2xx 还是错误代码。指定具有最少必填字段和最多字段的输入。

• 阴性测试当预期输出不存在时，验证 API 是否返回适当的响应。执行输入验证测试。使用不同级别的授权验证 API 的行为。

现场测试流程

强烈建议在测试过程实时时安排每天执行 API 测试。由于 API 测试执行快速、稳定且足够小，因此可以轻松地以最小的风险在当前测试流程中添加更多测试。这只有使用具有以下功能的自动化 API 测试工具才能实现：

• 使用内置测试命令进行测试调度

• 与测试管理工具和缺陷跟踪工具集成

• 与各种领先的 CI 工具持续集成

• 可视化日志报告生成

测试过程完成后，您每天都可以得到这些测试的结果。如果发生测试失败，您可以检查输出并验证问题以获得正确的解决方案。

不要低估 API 自动化测试

API 测试流程非常简单，主要分为三个步骤：

• 发送带有必要输入数据的请求

• 获取具有输出数据的响应

• 验证响应是否按要求返回

API 测试中最涉及的部分不是发送请求或接收响应。它们是测试数据管理和验证。通常，测试一些第一个 API（例如登录、查询某些资源等）非常简单。 

随着 API 的深入，测试任务变得越来越困难。因此，API 测试任务很容易被低估。

在某个时间点，您会发现自己正在为测试数据和验证方法选择一个好的方法。这是因为返回的数据结构相似，但在测试项目中却不相同。

此外，如果您应该逐个验证 JSON/XML 数据，或者使用对象映射来利用编程语言的强大功能，那么选择正确的方法将很困难。

强烈建议考虑 API 自动化测试一个真正的开发项目。它的结构应该是可扩展、可重用和可维护的。

原文链接：10 API Testing Tips for Beginners (SOAP & REST)