Gatling 中跨场景传递会话变量的正确实践方式

Gatling 中跨场景传递会话变量的正确实践方式

Gatling 的 session 是虚拟用户私有的，无法在不同 scenario 间共享；实现数据流转必须统一在单个用户行为链中完成，而非拆分到多个独立场景。

没错，Gatling 的 Session 对象是虚拟用户私有的，天生就无法在不同的 Scenario 之间共享。这意味着，要想实现数据流转，就必须把逻辑封装在同一个用户的行为链条里，而不是拆分成多个独立的场景。

在性能测试实践中，一个相当普遍的误区是：试图将业务流程拆成几个独立的 ScenarioBuilder（比如 `BooksStore.getScenario()` 和 `Client.getScenario()`），然后天真地希望通过 `.andThen()` 把它们串联起来执行——这种做法，根本实现不了会话数据的传递。原因何在？因为 Gatling 的 Session 对象严格绑定于单个虚拟用户的整个生命周期，而每个 Scenario 启动的实际上是彼此隔离的用户群体。即便你用了 `.andThen()`，它也只是在调度层面控制顺序（例如，先让10个用户执行“获取书籍ID”，再让另外10个用户执行“查询书籍”）。这两批用户的 Session 是完全不互通的，所以 `firstBookId` 在第二个场景里自然就解析不出来了。

✅ 那正确的做法是什么？其实很简单：将存在依赖关系的逻辑，全部封装在同一个 Scenario 内的连续 ChainBuilder 链中。这样一来，数据的采集和消费就确保发生在同一个虚拟用户的上下文里了。

下面是一段重构后的推荐写法（使用 Gatling 官方推荐的 Scala 语言；需要提醒的是，Ja va DSL 自 Gatling 3.8+ 起已被正式弃用，因此不建议继续使用）：

class BookWorkflowSimulation extends Simulation {
  val httpProtocol = http
    .baseUrl("https://bookylova.com")
    .acceptHeader("application/json")
    .header("Authorization", getGetAccessToken())

  // ✅ 单一场景：一个用户先获取 ID，再用该 ID 查询详情
  val bookFlow = scenario("Book Lookup Flow")
    .exec(
      http("Get Books IDs")
        .get("/api/books/ids")
        .check(jsonPath("$.idList[0]").sa veAs("firstBookId")) // 取第一个 ID（更健壮）
    )
    .exec(
      http("Get Book by ID")
        .get("/api/book/${firstBookId}") // Session 变量直接插值
        .check(status.is(200))
    )

  setUp(
    bookFlow.inject(
      rampUsers(10).during(10.seconds) // 10 个用户在 10 秒内逐步启动
    )
  ).protocols(httpProtocol)
}

? 这里有几个关键要点需要厘清：

• Session 是线程/用户级隔离的：每个虚拟用户都拥有自己独立的 Session 实例，它的生命周期从 `scenario.exec(...)` 开始，直到该用户完成所有 ChainBuilder 的执行后才结束。
• .andThen() ≠ 数据传递：这个方法仅仅表示“先运行 A 场景的所有用户，再运行 B 场景的所有用户”，它属于调度顺序的控制，并不会建立 Session 上下文的继承关系。
• 跨类复用 ChainBuilder 是可行的，但前提是保证在同场景内调用：你可以把 `getBooks` 和 `readBook` 这样的步骤抽取到 object 中定义为 `val` 或 `def`，只要它们最终被组合进同一个 `scenario.exec(...)` 链里就行：

object BookFlows {
  val getBooks: ChainBuilder = exec(
    http("Get Books IDs").get("/api/books/ids")
      .check(jsonPath("$.idList[0]").sa veAs("firstBookId"))
  )
  val readBook: ChainBuilder = exec(
    http("Get Book by ID").get("/api/book/${firstBookId}")
  )
}
// 在 Simulation 中复用：
val scn = scenario("Book Flow").exec(BookFlows.getBooks, BookFlows.readBook)

⚠️ 最后，还有几个注意事项需要警惕：

• 务必避免使用全局静态变量或外部存储（比如单例类的字段）来尝试“中转” Session 数据——这不仅会引发线程安全问题，更严重的是违背了 Gatling 的设计哲学，最终会导致压测结果完全失真。
• 如果业务流程涉及多步骤、多角色（例如“用户搜索 → 下单 → 支付”），应该使用 feeders、foreach、doIf 等 DSL 来构建条件化的流程，而不是去拆分 Scenario。
• 所有 `${variable}` 形式的插值，都是在运行时由当前 Session 解析的。只有当变量已经通过 `check(...).sa veAs(...)` 或 `session.set(...)` 显式写入当前 Session 后，插值才会生效。

总结一下：Gatling 的核心范式，其实就是 “一个用户，一条完整业务链”。数据流转靠的不是“类与类之间的通信”，而是依靠 ChainBuilder 的线性组合与 Session 的隐式传递。深刻理解并遵循这一原则，才能写出真正可维护、可复用且结果可信的性能测试脚本。