REST Assured API 测试 Skill：把接口场景落成可执行自动化

5 分钟阅读 PolyForm Noncommercial 1.0.0

AI 测试Agent SkillsREST Assured 接口自动化

API 自动化测试测的是接口行为。用户能否创建订单、未授权请求返回什么、重复提交会不会多扣库存，这些规则和测试框架无关。REST Assured 的角色很明确：把已经确认的 API 场景落成 Java 项目能执行、能进 CI 的测试类。

api-test-restassure Skill 用于读取多种 API 材料，整理场景、断言、测试数据和证据要求，再生成 REST Assured 自动化。它不会替团队发明状态码，也不会把未执行的代码包装成测试结果。

Awesome QA Skills 按语言和测试阶段组织 Skill。通用安装方式见系列总览；本文讲通用 API 测试怎样落到 REST Assured。

先准备接口测试材料

OpenAPI、Swagger、Postman/Bruno Collection、接口文档、需求说明和既有测试都可以成为输入。选择哪一种不重要，版本和业务规则必须清楚。

开始前至少写明：

  • 接口版本、基础地址和认证方式；
  • 本次覆盖的接口与业务链路；
  • 成功、权限、参数校验、状态冲突等关键场景；
  • 测试数据的创建、清理与隔离方式；
  • Java 版本、JUnit、构建工具和既有测试目录。

例如，接口文档写了“创建订单”，却没有说幂等请求的返回语义。Skill 应把它列为待确认，而不是在测试里随手写一个 409。看起来完整的猜测，通常会在回归门禁里找回来。

先写清场景，再生成框架代码

API 测试场景可以独立于 REST Assured 存在：

场景：已登录用户创建订单
前置：库存 book-001 为 2；用户拥有 buyer 权限
请求：POST /api/orders，body 为 { "sku": "book-001", "quantity": 1 }
预期响应：201；返回订单 ID、sku 和 PENDING 状态
预期副作用：库存变为 1；发布 order.created 事件
证据：测试报告、失败响应、构建号

每项预期都对应一个可验证的接口规则。响应断言覆盖状态码、错误码和关键字段；有状态变化时，再检查数据库、事件或下游调用。这里的规则可以复用给其他框架，变化的是测试代码的语法和项目集成方式。

从输入材料到回归入口

先让 Skill 输出场景清单，再生成 Java 测试类。把业务规则、测试数据和构建入口分开存放，后续换框架或换环境时不必重新整理全部上下文：

docs/openapi.yaml                 # 路径、参数、schema
docs/order-rules.md               # 幂等、库存和权限规则
src/test/java/support/ApiSpec.java
src/test/java/api/OrdersApiTest.java
build/test-results/               # JUnit 结果与失败响应

场景清单至少列出请求、预期响应、状态变化、数据负责人和待确认项。生成的 RequestSpecification、fixture 和断言应当接入已有测试基础设施，避免并行维护两套认证和环境配置。

REST Assured 在这里做什么

REST Assured 用 Java 链式 API 发送请求、校验响应，并和 JUnit、Gradle 或 Maven 进入同一套测试流程。认证、基础地址和公共 Header 可以放在 RequestSpecification 中，业务测试保持聚焦。

String orderId = given()
    .spec(ApiSpec.authenticated(token))
    .contentType(ContentType.JSON)
    .body(Map.of("sku", "book-001", "quantity", 1))
.when()
    .post("/api/orders")
.then()
    .statusCode(201)
    .body("sku", equalTo("book-001"))
    .body("status", equalTo("PENDING"))
    .extract().path("id");

assertThat(orderRepository.findById(orderId)).isPresent();

项目若已有认证 helper、Testcontainers、fixture 或断言库，Skill 应复用它们。公共配置集中处理，测试方法表达具体业务场景，维护时会轻松很多。

用 Skill 生成第一版用例

安装：

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/api-test-restassure -g

调用时，把通用 API 规则和 Java 框架约束一起给出：

请使用 api-test-restassure Skill。

接口材料：docs/openapi.yaml、docs/order-rules.md
测试范围：创建订单的成功、未登录、库存不足、重复提交
测试数据：现有 Testcontainers 配置；每个用例结束后清理
项目约定：Java 21、JUnit 5、Gradle；现有测试目录为 src/test/java/api
交付：生成或更新 REST Assured 测试类，列出覆盖场景、未确认规则和未执行命令。

复用已有 RequestSpecification、认证和断言约定；不要创建平行的测试基础设施。
响应断言覆盖状态码、错误码和关键字段；有状态变化时检查必要副作用。
不要把文档中没有定义的业务规则当成事实。

生成后先核对场景是否逐条对应接口材料，再执行项目测试：

./gradlew test --tests api.OrdersApiTest

Maven 项目使用项目约定的测试命令。测试报告、失败请求和响应、构建号才是执行证据；生成文件仍然需要运行验证。

怎么判断已经接入

检查项最低要求失败时的处理
场景覆盖成功、权限、参数、状态冲突都有明确结果回到接口材料补规则
可重复执行每次运行创建自己的数据并完成清理修正 fixture 或 Testcontainers
失败可定位请求、响应、版本和 run ID 能对应同一次运行补 Allure/JUnit 输出字段
CI 可判定Gradle/Maven 退出码与门禁规则一致修正插件和测试筛选参数

先接一条高价值链路。它在开发机和 CI 都能稳定复跑以后，再扩展分页、并发和跨服务场景。

这类 API 自动化最容易踩的坑

  1. 只给 Skill 一个 URL，没有接口版本、账号和业务范围，生成结果只能猜。
  2. 把 Collection 的一次绿色执行当成 Java 回归证据，实际没有接入 Gradle 或 Maven。
  3. 所有用例共用固定订单号、Token 或库存，顺序一变就互相污染。
  4. 只断言 HTTP 状态码，错误体、对象映射和关键副作用变化没有被发现。
  5. 生成了测试类，却没有报告、失败响应和构建号，问题无法回溯。

先看测试类能否被构建工具发现，再看报告能否回到具体请求。代码能编译只是入口成立，不能替代一次真实运行。

REST Assured 与其他 API 自动化框架的区别

接口场景、验收规则和证据要求可以共享。框架按项目栈选，负责把它们变成可维护的代码。

框架适合的项目栈生成产物
REST AssuredJava、JUnit、Gradle 或 MavenJava 测试类
SupertestNode.js、JavaScript、TypeScriptSupertest 测试脚本
PytestPythonPytest 接口测试
BrunoCollection 驱动的接口调试与回归Bruno Collection 与脚本

项目从 Supertest 迁移到 REST Assured 时，业务场景和接口规则依然有效。需要调整的是语言、断言库、数据工具和 CI 命令。

相关 Skill

Skill何时接入
API 契约测试OpenAPI、字段或错误语义发生变化
回归测试选择需要按改动范围挑选接口回归集合
测试报告需要把命令、报告、失败信息交给评审或 CI

先确认接口行为，再用 REST Assured 交付 Java 自动化。框架是执行层，业务规则才是测试真正要保护的东西。

常见问题

没有 OpenAPI 也能用吗？

可以。提供现有 Collection、接口文档、调用示例或需求说明；没有定义的状态码、错误码和业务规则要明确标为待确认。

可以把 Bruno Collection 直接交给这个 Skill 吗？

可以。它是 API 材料来源之一。最终交付是 REST Assured Java 测试类，Bruno 不需要成为 Java 项目依赖。

什么时候可以接入发布门禁？

当本地与 CI 使用同一命令、测试数据可重置、失败报告能定位到请求和版本时，就可以纳入门禁。

参考

安全测试白盒测试背靠背测试本地化测试边界测试
分享