用Playwright Java进行PATCH API请求自动化测试怎么做？

在之前的博客教程中，我们讨论了如何使用Playwright Java编写PUT请求的自动化测试脚本。

在这篇博客中，我们将讨论并介绍以下几点，并通过示例编写测试自动化脚本。

1. PATCH 请求是什么？
2. 如何用 Playwright Java 测试 PATCH 接口？

一个PATCH请求是什么？（PATCH请求是一种HTTP请求方法，用于修改服务器上的资源）

PATCH 请求用于部分更新资源的内容。它类似于 PUT 请求，但是两者之间的区别在于，PUT 需要发送整个请求体的内容，而使用 PATCH 只需发送需要更新的具体字段在请求中。

PUT请求和PATCH请求之间的另一个区别是，PUT请求总是幂等，也就是说，重复执行相同的请求不会改变资源的状态，而PATCH请求可能不总是幂等。

以下是一个使用restful-ecommerce API通过PATCH请求来更新订单信息的示例。在博客中，我们将进一步使用该PATCH API，利用Playwright Java编写自动化测试脚本来进行测试自动化。

1. PATCH /partialUpdateOrder/{id}，使用其订单ID部分更新订单信息（更新部分内容）

此 API 需要通过路径参数 id（例如 order_id）来检查并部分更新现有订单。订单的部分详情需要以 JSON 格式包含在请求体中。因为这是 PATCH 请求，只需发送需要更新的字段，其余信息无需提供。

另外，作为安全措施，发送PATCH请求时必须包含有效的 Authentication token，否则请求将失败。

PATCH 请求将返回状态码 200 和更新的订单详情。

如果 PATCH 请求失败，根据以下标准，会显示以下状态代码：

1. 状态码 — 404 — 如果提供的 order_id 没有找到对应的订单
2. 状态码 — 400 — 如果 token 验证不通过
3. 状态码 — 400 — 如果请求体错误或没有请求体
4. 状态码 — 403 — 如果发送请求时未提供 token

如何使用Java的Playwright测试PATCH API？

playwright提供了所需的API测试方法，使得API测试可以无缝进行。我们现在开始使用Playwright Java编写PATCH类型的API的自动化测试。

开始吧

看看这篇之前的教程博客，了解Playwright框架与Java的前置条件、设置及配置的详细信息。

正在测试的应用:

确保“应用”一词适用于具体情境；如果“应用”不是指特定软件或应用的常用术语，考虑使用更具体的术语。

这次演示中，我们将使用在GitHub上免费提供的restful-电商API。

Restful-Ecommerce — 一个简单的Node.js电商平台，可用于实践API测试如果您想学习和实践API测试，并想找一个示例API来练习，请参考这篇博客以了解更多免费使用的信息…medium.com

PATCH 接口, /partialUpdateOrder/{id} 将用来部分更新订单信息。该接口将用来部分更新订单信息。

了解更多请点击 这里

测试场景一 — 使用PATCH方法更新订单

1. 启动 restful-ecommerce 服务。
2. 使用 POST 请求在系统中创建一些订单
3. 将订单 order_id “1” 的 product_name, product_amt 和 qty 字段进行更新
4. 检查状态码应为 200
5. 检查详情更新是否正确

测试实施

为了部分更新订单信息，我们需要在请求体中包含需要更新的字段和访问令牌。此令牌确保只有有效的应用程序用户才能更新订单。

生成认证 token

可以通过POST /auth API端点生成访问令牌。

此 API 端点需要在请求体中包含登录凭证。有效的登录凭证如下：

• 用户名， “admin”；
• 密码， “secretPass123”

当您输入这些有效的登录信息后，API 在响应中会返回状态码 200 和 JWT 令牌。

我们将通过testdata包中的_TokenBuilder_类的_getCredentials()_方法来生成并使用token。

    public static TokenData getCredentials() {  
        return TokenData.builder().username("admin")  
                .password("secretPass123")  
                .build();  
    }

获取凭证，返回一个包含用户名'admin'和密码'secretPass123'的TokenData对象。

该方法返回一个 TokenData 对象，其中包含 username 和 password 字段。

    @Getter  
    @Builder  
    public class TokenData {  

        private String username;  // 存储用户名
        private String password;  // 存储密码

    }

这是一个用于存储用户名和密码的数据类。

一旦生成了token，就可以在PATCH API请求中使用，以部分更新订单信息。

生成用于订单更新的测试数据

接下来的一步是生成包含所需数据的请求正文，以部分更新订单的信息。

如之前博客中提到的，我们将向现有的测试数据生成器类中添加一个新的方法，即 getPartialUpdatedOrder() ，以补充现有的 OrderDataBuilder 类。
（注：保留原文中的下划线以保持与源代码的一致性，尽管在中文翻译中通常不会使用下划线来表示变量或方法名。）

修订后的版本：
如之前博客中提到的，我们将在现有的测试数据生成器类中添加一个新方法 getPartialUpdatedOrder() 。

静态方法获取部分更新的订单：public static OrderData getPartialUpdatedOrder() {  
    返回带有构建器的订单数据：return OrderData.builder()  
            .设置产品名称：.productName(FAKER.commerce().productName())  
            .设置产品金额：.productAmount(FAKER.number().numberBetween(550,560))  
            .设置数量：.qty(FAKER.number().numberBetween(3, 4))  
            .构建订单数据：.build();  
}

此方法仅使用3个字段，分别是 product_name、product_amount 和 qty，并相应地用它们生成一个新的JSON对象，并将这个JSON对象作为补丁API请求的请求体传递。

使用 PATCH 请求更新订单信息

我们现在进入最后一步，将用Playwright Java来测试PATCH请求。

咱们来在现有的 HappyPathTests 类中添加一个新测试方法，命名为 testShouldPartialUpdateTheOrderUsingPatch()。

    @Test  
        public void 应使用Patch部分更新订单的测试() {  

            final APIResponse authResponse = this.request.post("/auth", RequestOptions.create().setData(getCredentials()));  
            final JSONObject authResponseObject = new JSONObject(authResponse.text());  

            final String token = authResponseObject.getString("token");  
            final OrderData partialUpdatedOrder = getPartialUpdatedOrder();  

            final int orderId = 1;  
            final APIResponse response = this.request.patch("/partialUpdateOrder/" + orderId, RequestOptions.create()  
                    .setHeader("Authorization", token)  
                    .setData(partialUpdatedOrder));  

            final JSONObject updateOrderResponseObject = new JSONObject(response.text());  
            final JSONObject orderObject = updateOrderResponseObject.getJSONObject("order");  
            assertEquals(response.status(), 200);  
            assertEquals(updateOrderResponseObject.getString("message"), "订单更新成功！");  
            assertEquals(orderId, orderObject.get("id"));  
            assertEquals(partialUpdatedOrder.getProductAmount(), orderObject.get("product_amount"));  
            assertEquals(partialUpdatedOrder.getQty(), orderObject.get("qty"));  
        }

此方法首先会调用授权API来生成token。随后，将结果存储在authResponseObject变量中，并用于从响应中提取_“token”_字段的值。

用于PATCH API的请求体将被生成并存储在_partialUpdateOrder_对象中。这样做的目的，是为了在后续验证响应时可以继续使用该对象。

接下来，token会在setHeader()方法中设置，并且请求体对象会通过setData()方法发送。PATCH API请求会通过API的_patch()方法处理，从而允许部分更新订单。

响应正文

{
  "message": "订单更新成功!",
  "order": {
    "id": 1,
    "user_id": "1",
    "product_id": "1",
    "product_name": "三星 Galaxy S23",
    "product_amount": "5999元",
    "qty": "数量: 1",
    "tax_amt": "5.99元",
    "total_amt": "505.99元"
  }
}

此 PATCH API 的响应将会被存储在 response 变量中，并然后用于验证响应。

最后一步是进行验证，PATCH API 返回的是一个 JSON 对象，该对象将存储在名为 updateOrderResponseObject 的变量中。

message字段存在于主响应体中，因此我们将在调用_updateOrderResponseObject_时，通过调用get()方法来验证该字段。

JSON 对象 order 将被存储在名为 orderObject 的对象中。字段的断言检查将通过 orderObject 对象进行。

实际存储我们用于部分更新订单的请求体的 partialUpdateOrder 对象将作为预期值，而 orderObject 则用于实际值的断言。

测试运行环节

我们将创建一个新的测试文件，名为 testng-restfulecommerce-partialupdateorder.xml，以顺序方式运行测试，即首先通过调用 POST API 来生成订单，然后通过调用 PATCH API 来部分更新订单信息。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="RESTful电子商务测试套件">
    <test name="测试创建和更新订单的正常流程">
        <classes>
            <class name="io.github.mfaisalkhatri.api.restfulecommerce.HappyPath测试">
                <methods>
                    <include name="testShould创建新订单"/>
                    <include name="testShould使用PATCH部分更新订单"/>
                </methods>
            </class>
        </classes>
    </test>
</suite>

以下来自 IntelliJ IDE 的测试执行的截图显示，测试已成功运行，并且订单的部分更新也已成功。

简述：

PATCH API 请求允许对资源进行部分更新。它允许仅更新所需的字段，这样更灵活。从而可以轻松更新特定资源。在本文中，我们使用 Playwright Java 测试了 PATCH API 请求功能。

测试所有的HTTP方法也同样重要，在执行API测试的过程中，我们应该为每个端点进行单独的测试，同时也要对所有API进行全面的测试，以确保应用程序中的所有API都能良好集成并顺畅运行。

祝你测试愉快！