使用Gatling进行DELETE接口性能测试的资源预生成方案问询

方案1：保障每次DELETE请求存在有效可删资源（推荐） #

该方案符合真实业务调用逻辑，得到的性能数据贴合线上实际情况，有两种落地方式：

• 「创建+删除」绑定为单执行单元
  Gatling的Scenario原生支持链式编排多个请求，不需要额外的单请求级前置钩子，直接把创建资源的请求作为DELETE的前置步骤放在同一个执行链里即可，示例代码如下：

  val deleteScn = scenario("DELETE接口性能测试")
    // 前置步骤：调用资源创建接口，提取返回的资源ID存入会话
    .exec(
      http("创建待删除资源")
        .post("/api/your-resource")
        .header("Content-Type", "application/json")
        .body(StringBody("""{"data":"test"}"""))
        .check(jsonPath("$.data.id").saveAs("targetId"))
    )
    // 执行DELETE请求
    .exec(
      http("删除指定资源")
        .delete("/api/your-resource/${targetId}")
        .check(status.is(204))
    )
  

• 预生成资源ID池批量供给
  如果创建资源的接口性能不足以支撑高并发调用，可以在Simulation全局的before钩子中提前批量生成足够多的待删资源ID，存入自定义Feeder供给后续DELETE请求使用：

  // 全局存储预生成的资源ID队列，数量需要大于测试总请求数
  var preGeneratedIds: Queue[String] = _
  
  before {
    // 批量写入10000条测试数据到数据库，提取ID存入队列
    preGeneratedIds = (1 to 10000).map(i => createResourceAndReturnId(i)).toQueue
  }
  
  // 自定义Feeder，每次返回一个未使用的资源ID
  val resourceFeeder = Iterator.continually(Map("resourceId" -> preGeneratedIds.dequeue()))
  
  val deleteScn = scenario("DELETE接口性能测试")
    .feed(resourceFeeder)
    .exec(
      http("删除指定资源")
        .delete("/api/your-resource/${resourceId}")
        .check(status.is(204))
    )
  

  注意：如果是分布式多节点执行Gatling，需要提前将预生成的ID池同步到所有执行节点，或者借助Redis等分布式共享存储存储ID池，避免不同节点重复取用同一个ID。

方案2：预期错误响应（仅适用特定测试场景） #

如果你的测试目标是验证接口处理非法删除请求的性能，可以直接设置预期的错误状态码，Gatling会将符合预期的错误响应判定为成功请求，同时正常记录耗时：

.exec(
  http("删除不存在资源")
    .delete("/api/your-resource/invalid-id")
    .check(status.is(404))
)

该方案得到的性能数据和真实业务场景下的DELETE请求性能有差异，仅适合错误处理逻辑的专项性能验证，不推荐作为常规DELETE接口性能测试方案。

内容的提问来源于stack exchange，提问作者Kris