API 自动化测试指南

前言：

什么是 API 测试？

为什么 API 测试很重要？

测试金字塔

GUI 测试

单元测试

API 测试

API 负载测试

API 测试工具如何选择

如何测试 Web 服务

HTTP

关于 HTTP 请求

请求行（HTTP 方法）

标头

请求体

HTTP 状态码

什么是 REST API？

什么是 JSON

前言：

API自动化测试是现代软件开发中至关重要的一环。它可以帮助开发团队快速、准确地验证API的功能和性能，提高软件质量和开发效率。

我相信自动化技能已经成为高级测试工程师总体技能的标配。敏捷和持续测试破坏了传统的测试自动化实践，导致测试工程师重新考虑自动化的完成方式。当今的自动化工程师需要在 GUI 的下方深入到 API 级别完成软件质量的保护。

导致转向 API 测试的第二个变化是物联网。物联网是具有嵌入式功能的日常对象，允许它使用 HTTP 或 HTTPS 在 Web 上进行通信以与远程后端服务进行通信。

下面分享一下 API 测试的基础使用指南：

什么是 API 测试？

应用程序编程接口（API）是充当软件组件接口的规范。大多数功能测试都涉及测试网页或表单等用户界面，而 API 测试涉及绕过用户界面并通过调用其 API 直接与服务程序通信。

API 测试允许测试绕过 GUI 并将请求直接发送到应用程序的后端或服务，并在验证响应内容以确保按预期运行的同时收到响应。

上面的示例通常称为客户/服务器关系。客户端通过请求资源来发出请求，然后请求出去寻找将满足请求的服务器。服务器找到所需的资源，然后将响应发送回客户端。

为什么 API 测试很重要？

随着敏捷开发成为大多数互联网公司的标准，我们开发软件和自动化测试的方式已经发生了巨大变化。在敏捷开发之前，大部分自动化时间都是通过图形用户界面（GUI）完成的。这是 Selenium 和 UFT/QTP 等工具处理的部分。

但是，如果您已经进行了一段时间的自动化操作，您就会知道这些类型的测试是多么耗时，脆弱且难以维护。企业投入大量资金来创建自定义功能 GUI 测试自动化框架，单很可能最终使他们对其可靠性失去了信心，直到人们停止投入。

同样，针对用户界面的 GUI 测试往往需要花费很长时间才能运行。对于某些敏捷实践（例如连续构建），迁入新代码时，从 GUI 回归测试套件接收反馈所花费的时间是不能被接受的。

API 快速反馈

在这些情况下，需要更快的反馈。发现错误的时间越早越好，因为开发人员会立即知道他们所做的代码更改已破坏了构建，因此需要进行检查。在测试驱动的流程中，用户需要大量测试集才能快速且频繁地运行，并且必须能够将它们集成到开发生命周期中。

GUI 测试仍然非常重要。它是唯一能够真正测试用户在生产过程中如何体验应用程序的测试类型。某些缺陷只能通过 GUI 测试来捕获。换句话说，尽管至关重要，但 GUI 不应是用户关注的唯一自动化类型，也不应该是自动化测试总量中最大的一部分。

敏捷关注的自动化类型是更可靠的 API 下层测试，而较少涉及 GUI 自动化。

测试金字塔

GUI 测试

GUI 测试专注于测试应用程序用户界面，以确保其功能正确。GUI 测试位于金字塔的顶部，仅占应该创建的自动化测试类型总数的一小部分。

单元测试

单元测试构成了金字塔的最大部分，形成了坚实的基础。创建单元测试以验证源代码的单个单元，例如方法。通过这样做，开发人员可以隔离其代码中最小的可测试部分。单元测试是最容易创建的，并能带来最大的收益。由于单元测试通常是用与编写应用程序相同的语言编写的，因此开发人员可以轻松将它们添加到开发过程中。

API 测试

中间服务层是创建诸如 Rest-Assured 和 Postman 之类的工具的 “最佳位置” 。

服务测试的重点是验证许多小组件的交互是否可以集成在一起而不会出现问题。由于 API 测试绕过了用户界面，因此它们往往比 GUI 测试更快，更可靠。

最重要的是：由于 API 测试不依赖 UI 即可完成，因此可以在开发周期的早期创建它们。

API 负载测试

API 测试的另一个好处是，您可以利用相同的功能性 API 自动测试来在性能测试工作中使用。很多公司使用 JMeter 进行负载测试，而这些测试用例都是基于 API 功能测试。

基本思想是，您正在使用工具进行性能测试，但是在针对您的 API 运行例如负载测试之前，需要确保它实际上可以正常工作。因此，您想先进行功能测试，然后可以利用功能测试脚本完成性能测试。

因此，API 测试脚本是性能测试工作流程中的一大优势。

API 测试工具如何选择

您可以使用许多工具来帮助您进行 API 测试自动化。

如何测试 Web 服务

测试任何其他应用程序一样！通常，对于 Web 服务，正常功能测试的最佳方法是相同的（除了与大多数其他应用程序不同的是，Web 服务没有 GUI 用户界面这一区别除外）。

因此，一直使用的功能测试技术仍然适用。只需将 Web 服务视为没有业务流程，然后相应地编写测试用例。

自动化 Web 服务时要问的一些好问题：

服务是否以正确的值响应？
该行为是否符合最终用户的预期要求？
该服务多快将响应发送给用户？
服务可以处理预期和意外的用户负载吗？
服务可以处理无效数据和错误数据导致的异常吗？
Web 服务测试术语

对于大多数测试人员而言，最大的障碍是适应谈论 Web 服务时使用的术语。

例如：

XML 格式
XML 是一种创建标记语言的方法，您可以使用它定义自己的标签。XML 允许用户与众多系统共享结构化数据，包括通过 Internet。
REST
REST（表示性传输状态）是用于开发使用 HTTP 协议的 Web 服务的轻量级选项。

HTTP

HTTP 是一种通过网络传输消息的通信协议。HTTP 也被称为无状态协议，因为它发出的每个请求都独立于所有先前的请求。

Cookies 用于跟踪会话的先前请求的状态。Cookies 是存储在客户端上的文件，具有从 HTTP 标头信息中添加的信息。当向用户已经访问过的网站发出请求时，存储在 Cookies 中的信息将发送回浏览器。以这种方式，网站能够记住用户的先前活动和当前的状态。

理解 HTTP 将为我们了解大多数 API 测试工具功能奠定良好的基础。

关于 HTTP 请求

HTTP 客户端请求包含三个主要部分。他们是：

请求行（HTTP 方法）

告诉服务器正在发出什么类型的请求。在上面的示例中，我们发出了 GET 请求，但您可以使用更多请求，具体取决于您需要发出的请求类型。HTTP 方法具有以下选项（前四个方法是最常见的）：

GET –从指定来源检索数据
POST –将新数据发送到指定的源
PUT –更新指定来源的信息
DELETE –从指定的源中删除数据
TRACE –要求代理人声明自己
选项 –询问有关服务器上可用选项的信息
HEAD –与 GET 请求类似，但仅发送有关文档的信息
CONNECT –客户端必须使用 HTTPS 服务器时使用

标头

包含要发送到服务器的其他信息，例如浏览器，操作系统，接受和 Cookie 信息。标头的不同类型是：

常规 -可选的标头，其中包含诸如当前时间之类的信息
请求 -向服务器提供有关客户端的更多信息
实体 -包含有关发送文档的特定信息，例如长度和编码方案。

请求体

包含用于需要它的方法的数据，Get 方法为空。

从服务器返回的响应也包含三个部分，就像我们在 HTTP 请求中看到的那样：

响应行（状态码）
标头信息
包含响应中所有文本的正文

HTTP 状态码

在我们的示例中，状态代码为 200，表示一切正常。状态代码将根据原始请求发生的情况而有所不同。

可以从服务器返回的状态码是：

1xx – 100-199 范围内的响应表示服务器正在处理请求。
2xx – 200-299 范围内的响应表示请求成功。
3xx –响应范围在 300-399 之间表示未执行请求 - 需要采取进一步的措施。
4xx –响应范围为 400-499，表示请求不完整，可能需要更多信息。
5xx – 500-599 范围内的响应表示服务器遇到错误。