REST API 测试教程:示例手动测试用例

⚡ 智能摘要

REST API 测试通过发送 HTTP 请求(例如 GET、POST、PUT 和 DELETE)来验证 RESTful Web 服务,然后验证服务器返回的状态代码、响应标头和有效负载。

  • ???? 核心理念: 直接执行服务层操作,中间无需用户界面。
  • 🔁 方法覆盖率: 对每个公开的资源执行 GET、POST、PUT 和 DELETE 操作。
  • 🛠️ 客户端设置: 在发送第一个请求之前,请先安装高级REST客户端。
  • 📋 请求构建: 提供端点 URL方法、标头、参数和 JSON 有效负载。
  • 响应检查: 确认响应代码、响应消息和响应正文均符合预期。
  • 🔐 安全深度: 使用缺失、过期或低权限的令牌重放调用,以强制返回 401 和 403 回复。
  • 🤖 人工智能支持: 机器学习可以生成人工测试人员经常忽略的边缘情况有效载荷。

什么是 REST API 测试?

REST API 测试 REST API 是一种开源的 Web 自动化测试技术,用于测试 Web 应用程序的 RESTful API。REST API 测试的目的是通过发送各种 HTTP/S 请求来记录 REST API 的响应,从而检查 REST API 是否正常工作。REST API 测试使用 GET、POST、PUT 和 DELETE 方法。

REST的 代表表述性状态转移。它是一种架构风格,也是一种用于开发 Web服务REST 已成为构建 API 的合理选择,因为它使用户能够高效地连接和与云服务交互。

应用程序编程接口(API)是一组用于访问基于Web的软件应用程序的编程指令。换句话说,它是一组命令,程序之间可以通过这些命令直接通信,并使用彼此的功能来获取信息。

例如,一个 Google 网站可以提供用于搜索、翻译和日历的 API。通常,API 的格式如下例所示,包含服务器名称、路径和参数。

http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv

但为什么要在这一层投入测试工作呢?

为什么REST API测试至关重要

REST API 位于用户界面和数据库之间,因此大部分业务逻辑都实际存在于这一层。定价规则或权限检查中的缺陷会在 API 响应中显现,远早于屏幕上显示错误数字,因此在此层进行测试能够更早地发现问题,并更接近问题的根源。

速度是第二个原因。请求在几毫秒内即可完成,无需浏览器、渲染引擎或脆弱的元素定位器。测试人员可以在加载一个页面的时间内测试数十个端点,而且无论前端是网站、移动应用还是合作伙伴集成,同一个请求的行为都完全相同。

稳定性是第三个原因。布局会不断变化,但已发布的 REST 内容却能保持稳定。trac预计 t 将保持稳定。针对该情况编写的测试trac为了在重新设计中幸存下来,它们会保护产品中其他团队实际在其基础上进行开发的部分。

API 方法的类型

主要有4种类型 API测试 方法:GET、POST、DELETE 和 PUT。

  • 的GET– GET 方法用于执行trac使用给定的 URI 从给定的服务器获取信息。使用 GET 请求时,它应该只执行一次请求。tract 数据,并且不应对数据产生其他影响。
  • 解决方案&帖子– POST 请求用于创建新实体。它还可用于使用 HTML 表单向服务器发送数据,例如客户信息、文件上传等。
  • PUT– 创建新实体或更新现有实体。
  • 删除– 删除由 URI 给出的目标资源的所有当前表示。

如何测试 REST API

REST API 测试需要应用程序与用于测试的示例 API 进行交互。要测试 API,您需要两样东西:

  • 驱动 API 的测试工具/框架
  • 编写自己的代码来测试示例 REST API

REST API 测试用例可以使用以下工具进行测试:

  • 高级 Rest 客户端
  • Postman-Rest 客户端
  • Linux 中的 Curl

这里我们将使用高级REST客户端。以下是获取高级REST客户端的步骤。

如何获取高级REST客户端?

  • 在MyCAD中点击 软件更新 Google Chrome的网上商店
  • 搜索“Advanced Rest Client”或直接进入 开始 并安装扩展
  • 选择 Chrome 应用程序部分下的“Advanced Rest Client”图标 – chrome://apps/

网上商店列表如下所示。

如何安装 Advance Rest Client

安装完成后,请按照以下测试步骤进行测试。 RESTful API.

测试 REST API 的步骤

这里我们使用Chrome浏览器中的REST客户端扩展。为了更清楚地理解它,我们使用一个虚拟API进行测试:

http://ip.jsontest.com/

步骤 1)打开高级 REST 客户端

成功安装后,启动应用程序高级 REST 客户端 (ARC)。

打开高级 REST 客户端

步骤 2)输入 URL 测试 API

输入示例 REST API URL 用于测试 URL 文本框。

URL 测试 API

步骤 3)选择 HTTP 方法

选择 API 测试中要命中的 HTTP 方法类型,例如 POST

HTTP Method

步骤 4)提供标头集

在 Headers 文本框中提供 Headers Set。单击 Insert header set。

标头设置

步骤 5)确认 Headers 设置

接下来单击使用此设置。

标头设置

步骤 6)提供所需的 Body 内容

  1. 现在切换到“Body”选项卡。
  2. 设置所需的 Body 内容类型和编辑器视图,例如 Body 内容类型:application/json
  3. 编辑器视图:原始输入。
  4. 在有效负载 (Payload) 中,以键值对的形式传递用于测试的演示 API 的请求体,例如 {"key1":"value1","key2":"value2"}。如果是 POST API,则需要传递请求体或参数。我们将把这些参数放在给定的有效负载下。
{"property" : ["Sites"], "report_type" : ["ALL"]}

测试 REST API 的步骤

⚠️警告: Content-Type 为 application/json 且有效负载无效 JSON 返回 400 错误请求。

步骤 7)提交详细信息以开始测试

  1. 点击发送按钮。
  2. 您可以点击“详细信息”按钮来查看响应标头。

测试 REST API 的步骤

以下是响应详情:

测试 REST API 的步骤

仍需根据预期结果来评判该回应。

验证结果

对于 Web API 测试,我们主要需要检查响应代码、响应消息和响应正文。

响应代码分为五类:

家庭 类别
1xx 信息化 已接收,仍在处理中
2xx 成功 已完成;200 OK,201 创建
3xx 重定向 需要采取进一步行动。
4xx 客户端错误 无效的有效载荷、令牌或资源
5xx 服务器错误 请求有效,但服务器失败

以下是可能会遇到的响应代码。

验证结果

一次请求可以证明端点正常工作。一系列请求可以证明它持续正常工作。

你必须涵盖的 REST API 测试用例

一个实用的 REST API 套件应该涵盖多个类别,而不是用不同的数据重复相同的正常调用:

  • 快乐之路: 向每个端点发送有效请求,并确认状态码、架构和每个字段值。
  • 阴性病例: 如果发送格式错误的 JSON、不支持的方法和缺少资源 ID,则预期会收到 400、405 和 404 错误,而不是 500 错误。
  • 边界值: 如果一个字段接受 1 到 200 个字符,则测试 0、1、200 和 201。验证规则在边界处失效。
  • 特殊字符: 将带重音符号的字母、表情符号、引用和多字节文本输入到每个字段中,以发现编码错误。
  • 连接器tract 检查: 将响应与已发布的 OpenAPI 或 Swagger 规范进行比较,以便及早发现未记录的更改。
  • 排序: 按照合理的顺序调用端点,例如先调用 POST,再调用 GET,最后调用 DELETE,因为状态会在调用之间传递。
  • 表现合理性: 记录每次运行的响应时间,并标记任何超出与团队商定的阈值的端点。

REST API 测试工具

不同的工具适用于不同的测试阶段。

工具 类型 最适合
高级 Rest 客户端 桌面客户端 快速手动调用
Postman 桌面客户端 收藏夹和团队工作区
JMeter 负载测试 负载下的响应时间
SoapUI 功能测试 REST 和 SOAP 结合使用
放心 Java 图书馆 稳定案例的自动化
cURL 命令行 将通话记录粘贴到错误报告中

查看汇总 API测试工具.

大多数真实终端在请求证明其发送者身份之前,都不会响应。

REST API 身份验证和安全检查

公开演示端点可以对任何人开放,但生产环境中的 REST API 依赖于身份验证机制,授权漏洞的危害远大于字段值错误。首先要确定身份验证机制:静态 API 密钥、HTTP 基本凭据、OAuth 2.0 持有者令牌,还是签名的 JSON Web Token。

一旦身份验证请求成功,就要有意识地排查所有失败路径:

  1. 没有凭证: 移除 Authorization 标头。预期会返回 401 Unauthorized 错误,并且响应体中不会包含任何记录数据。
  2. 凭证格式错误: 篡改令牌中的一个字符。预计会再次返回 401 错误,但不会显示任何解释原因的消息。
  3. 已过期凭证: 重复使用已过期的令牌。确认令牌被拒绝而非被接受,这是常见的时钟偏差缺陷。
  4. 权限级别错误: 以低权限用户身份进行身份验证,并调用仅限管理员访问的端点。预期返回 403 Forbidden 错误,而不是 200 错误。
  5. 另一位用户的记录: 修改ID,使用户A能够请求用户B的数据。这种做法的成功表明存在严重的访问控制缺陷。

最后,确认所有调用都通过 HTTPS 传输,并且失败的响应不会泄露任何堆栈信息。 traces 或版本横幅,并且快速重复会触发 429 请求过多错误。

REST API 测试也带来了一些接口测试所没有的困难。

API 测试的挑战

REST API 测试中测试人员面临的有趣问题包括:

  1. 为了确保测试框架能够以某种方式改变 API 调用的参数,从而验证功能并发现故障,它包括探索边界条件和分配通用参数。
  2. 为具有两个或更多参数的调用创建有趣的参数值组合
  3. 确定API调用所依据的内容。这可能包括设置外部环境条件(外围设备、文件等)以及影响API的内部存储数据。
  4. 根据函数执行的顺序对 API 调用进行排序
  5. 使得 API 通过连续调用产生有用的结果。

常见问题

REST 测试使用轻量级的 JSON 或 XML,并基于纯 HTTP 动词进行操作。SOAP 测试则根据 WSDL 规范验证严格的 XML 封装。trac因此,它需要一个支持模式的客户端,例如 SoapUI 而不是一个简单的 REST 客户端。

不。诸如 Advanced Rest Client 之类的客户端和 Postman 它允许您通过表单创建请求。只有当您使用诸如此类的库来自动化相同的操作时,才需要编写代码。 放心.

大多数团队认为单次读取操作的响应时间低于 300 毫秒就算不错,低于 1 秒也算可以接受。超过几秒就会损害调用应用程序的性能,因此每次运行都要记录时间,如果出现偏差就提交缺陷报告。

AI 读取 OpenAPI 规范并生成请求负载,包括测试人员经常忽略的边界变体和格式错误变体。它还会将类似的故障聚类,并突出显示最近发生更改可能导致故障的端点。

不。人工智能并不知道企业认为什么是正确的,哪些访问规则至关重要,或者哪些数据属于敏感数据。它只是扩展了案例生成规模,而最终决定有效响应含义的仍然是测试人员。

总结一下这篇文章: