使用 REST-Assured Java 进行 PATCH API 请求测试指南

测试是 API 开发过程中确保 API 正常工作的关键环节。RESTful API 中包含多种 HTTP 方法，包括 POST、GET、PUT、PATCH 和 DELETE。在之前的文章中，我们学习了如何使用 Rest-Assured Java 对 POST、PUT 和 GET API 进行自动化测试。

在本教程中，我们将讨论并涵盖以下内容：

1. 什么是 PATCH API 请求？
2. 如何使用 REST-Assured Java 测试 PATCH API 请求？

什么是 PATCH API 请求？

PATCH 请求用于对资源进行部分更新。虽然它与 PUT 请求类似，但关键区别在于：PUT 要求发送完整的请求体，而 PATCH 允许你仅发送需要更新的特定字段。

让我们以本教程中用于演示的 PATCH API 为例：

PATCH (/partialUpdateOrder/{id})

此 API 端点根据提供的订单 ID 对系统中的现有订单进行部分更新。

[LOADING...]

为了更新现有订单，此 API 需要将 order ID 作为路径参数，以便系统知道要修改哪条记录。更新后的详细信息应以 JSON 格式提供在请求体中。由于这是一个 PATCH 请求，因此无需发送整个有效载荷，只需在请求体中包含需要更新的字段即可。

PATCH 和 PUT API 的区别

下表展示了 PATCH 和 PUT API 之间的区别：

让我们使用 PATCH API /partialUpdateOrder/{id} 来部分更新系统中的现有订单。

测试场景：

## 测试场景标题：部分更新系统中的现有订单。
## 前置条件：系统中存在有效的订单
## 测试步骤：
1. 更新订单 ID 为 2 的 product_name 和 product_id。
2. 验证响应返回状态码 200。
3. 断言订单详情已正确更新。

测试实现

由于 PATCH API 受身份验证保护，我们需要身份验证令牌才能成功访问它。要实现此测试场景，我们必须：

1. 编写测试以调用授权 API，生成并提取令牌。
2. 使用第一步生成的令牌调用 PATCH API，以部分更新订单。

第一步：编写测试以调用授权 API，生成并提取令牌。 应使用以下有效凭据调用 POST /auth API 端点以生成令牌。

{
  "username": "admin",
  "password":"secretPass123"
}

[LOADING...]

它返回以下响应：

{
  "message": "Authentication Successful!",
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNzc1NjMzMDU5LCJleHAiOjE3NzU2MzY2NTl9.jHQwCyts9IejhwKGAZEm4Uyo9dgu5Kpe4OjTiYw1dm8"
}

创建以下测试方法来执行 POST /auth API 请求并从响应中提取令牌。

@Test
public void testTokenGeneration () {
    String requestBody = """
    {
        "username": "admin",
        "password": "secretPass123"
    }""";
    token = given ().contentType (ContentType.JSON)
        .when ()
        .body (requestBody)
        .post ("http://localhost:3004/auth")
        .then ()
        .statusCode (201)
        .and ()
        .body ("token", notNullValue ())
        .extract ()
        .path("token");
}

testTokenGeneration() 测试发送带有登录凭据的 POST 请求，以使用 REST Assured 生成身份验证令牌。它验证响应是否返回 201 状态码，并检查响应中是否包含令牌。收到令牌后，将其提取并存储在名为 token 的全局变量中，以便在其他测试用例中重复使用。

第二步：使用 PATCH API 请求部分更新记录。

在此步骤中，让我们添加一个新的测试方法 testPartialUpdateOrder()，该方法使用 PATCH 端点发送部分更新请求。请求体需要使用所需的字段（即 product_id 和 product_name）构建。我们将使用 Google Gson 和 Datafaker 库来生成请求体。

public class TestPatchRequestExamples {
    private String token;

    @Test
    public void testPartialUpdateOrder () {
        Faker faker = new Faker ();
        String productId = String.valueOf (faker.number () .numberBetween (1, 2000));
        String productName = faker.commerce () .productName ();
        JsonObject orderDetail = new JsonObject ();
        orderDetail.addProperty ("product_id", productId);
        orderDetail.addProperty ("product_name", productName);
        //..
    }
}

这段代码使用 Datafaker 库中的 Faker 类为 product_id 和 product_name 字段生成随机值。请求体所需的 JSON 对象是使用 Google Gson 库的 JsonObject 类生成的。此代码生成的请求体如下：{"product_id":"702","product_name":"Sleek Silk Plate"}。

接下来，编写自动化测试以使用 PATCH API 端点更新记录。

@Test
public void testPartialUpdateOrder () {
    int orderId = 2;
    //..
    given ().contentType (ContentType.JSON)
        .header ("Authorization", token)
        .when ()
        .log () .all ()
        .body (orderDetail.toString ())
        .patch ("http://localhost:3004/partialUpdateOrder/" + orderId)
        .then ()
        .log () .all ()
        .statusCode (200)
        .and ()
        .assertThat ()
        .body ("message", equalTo ("Order updated successfully!"),
               "order.product_id", equalTo (productId),
               "order.product_name", equalTo (productName));
}

此测试针对 订单 ID 2 发送 PATCH API 请求。请求中包含了我们之前创建的请求体，其中仅包含需要更新的字段。

• given().contentType(ContentType.JSON)：指定请求体将采用 JSON 格式。
• .header("Authorization", token)：将身份验证令牌添加到请求头中，这是授权 API 调用所必需的。
• .when().log().all()：此语句开始执行请求并记录所有请求详细信息（标头、正文等）。
• .body(orderDetail.toString())：设置请求有效载荷。之前创建的 orderDetails JSON 仅包含需要更新的字段。
• .patch("http://localhost:3004/partialUpdateOrder/"+ orderId)：发送 PATCH 请求，以部分更新指定订单 ID 的订单。
• .then().log().all()：记录完整响应，以便更好地查看测试执行情况。
• .statusCode(200)：验证 API 请求已发送，且 API 响应为 200 OK 状态。
• .and().assertThat().body(...)：对响应体执行多项断言：
  1. "message" 字段的值应为 "Order updated successfully!"。
  2. 订单对象中 "product_id" 和 "product_name" 字段的值应与请求中提供的值相同。

使用动态方法生成请求体有助于消除重复代码，并提高测试用例的可重用性。

有关响应验证的更多信息，请查看此教程。

[LOADING...]

测试执行

正如我们在关于使用 REST Assured 测试 PUT API 请求的教程中所讨论的那样，我们需要遵循相同的方法：先生成令牌，然后使用它来调用 PATCH API 请求。让我们创建以下 testng.xml 文件以按顺序执行测试：

以下测试执行截图显示测试已成功执行，且订单已部分更新。

[LOADING...]

测试执行后，控制台打印出以下日志，显示了请求和响应的详细信息：

Request method: PATCH
Request URI:    http://localhost:3004/partialUpdateOrder/2
...
Body:
{
    "product_id": "702",
    "product_name": "Sleek Silk Plate"
}

HTTP/1.1 200 OK
...
{
    "message": "Order updated successfully!",
    "order": {
        "id": 2,
        "user_id": "1",
        "product_id": "702",
        "product_name": "Sleek Silk Plate",
        "product_amount": 750,
        "qty": 1,
        "tax_amt": 7.99,
        "total_amt": 757.99
    }
}

可以看到，product_id 和 product_name 两个字段具有随机生成的值，并与订单 ID 2 一起发送在请求中。响应中返回了 200 OK 状态码以及显示相同 product_id 和 product_name 的完整响应体。这些详细信息以及测试中使用的断言确认订单已成功更新。

总结

在自动化测试中有效地测试 PATCH API，涉及通过仅发送必需字段来验证部分更新，并确保未更改的数据保持不变。使用 DataFaker、Google Gson 等动态方法，并通过 POJO、构建器模式、JSON 文件或 Java Map 构建请求体，有助于生成全新的测试数据，减少重复问题并简化维护。遵循适当的身份验证处理、验证响应体和状态码以及保持测试可重用和可维护等最佳实践，可确保 API 测试自动化的稳健性和可扩展性。祝测试愉快！