【问题标题】:Gatling JDBC with dynamic where clause使用动态 where 子句的 Gatling JDBC
【发布时间】:2019-09-09 21:47:50
【问题描述】:

我将 Gatling 与 JDBC 馈送器一起使用,并希望根据先前请求的响应动态地将参数添加到 JDBC 馈送器的 where 子句。这是我的示例,我正在尝试创建一个用户,然后让提要使用从创建用户请求返回的 userId 获取用户生成的 UUID,然后使用 UUID 发布一些数据。

val dbConnectionString = "jdbc:mysql://localhost:3306/user"
val sqlQuery = "SELECT user_uuid FROM users where user_id = '${userId}'"
val sqlUserName = "dbUser"
val sqlPassword = "dbPassword"
val sqlQueryFeeder = jdbcFeeder(dbConnectionString, sqlUserName, sqlPassword, sqlQuery)
val uuidPayload = """{"userUUID":"${user_uuid}"}"""

val MyScenario = scenario("MyScenario").exec(
(pause(1, 2))
.exec(http("SubmitFormThatCreatesUserData")
  .post(USER_CREATE_URL)
  .body(StringBody("""{"username":"test@test.com"}""")).asJson
  .header("Accept", "application/json")
  .check(status.is(200))
  .check(jsonPath("$..data.userId").exists.saveAs("userId")))
.feed(sqlQueryFeeder) 
.exec(http("SubmitStuffWithUUID")
  .post(myUUIDPostURL)
  .body(uuidPayload).asJson
  .header("Accept", "application/json")
  .check(status.is(200)))
)

我已验证以下内容:

1) 用户数据确实在表单帖子中正确插入数据库 2) userId 从该表单帖子返回 3) userId 正确保存为 Gatling 会话变量 4) 如果我硬编码用户 id 变量,SQL 查询将正确执行

我遇到的问题是,当我在 JDBC 馈送器的 where 子句中有 Gatling ${userId} 参数时,它似乎没有使用 userId 变量,我收到一条错误消息 java.lang.IllegalArgumentException: requirement failed: Feeder must not be empty。当我用硬编码的 userId 替换 ${userId} 时,一切都按预期工作。我只想知道如何在我的 JDBC 馈送器的 where 子句中使用 userId 会话参数。

【问题讨论】:

    标签: gatling scala-gatling


    【解决方案1】:

    调用jdbcFeeder(dbConnectionString, sqlUserName, sqlPassword, sqlQuery) 以创建 jdbc 馈送器仅将字符串作为参数,而不是加特林表达式(如 ${userId})。

    在您发布的场景中,您并没有真正按预期使用馈送器 - 它们通常用于让不同的用户从值池中获取不同的值,而您有一个静态用户名并且只获取返回的第一个值从分贝。在场景中间获取外部数据通常不是一个好主意,因为它会使时间变得不可预测。

    您可以查找并硬编码 user_uuid 吗?最好的方法是获取所有用户数据并在模拟的before 块中查找诸如 uuid 之类的内容。但是,您不能在那里使用加特林 DSL。

    您还可以使用 scala 变量来存储 user_uuid 并内联定义馈线,但如果您确实需要支持多个用户,这会变得很麻烦

    【讨论】:

    • 谢谢詹姆斯,这是有道理的。我的问题是我的场景调用了一个创建数据的休息服务,然后另一个需要使用该数据的服务。我稍微改变了场景,因为我不想暴露任何客户细节。基本上,用户注册一个帐户并在电子邮件中发送一个验证码。我想从数据库中读取验证码,这样我就可以模拟用户输入他们在电子邮件中收到的代码。我最好的选择是在一个场景中注册一堆用户,然后在另一个场景中提交他们的验证码吗?
    • 是的 - 正如您所建议的那样,用户创建和登录是单独的模拟。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-10-12
    • 2016-12-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多