英文文档地址:
http://gatling.io/docs/2.1.7/advanced_tutorial.html#advanced-tutorial

Advance Tutorial

在这部分,我们假设你已经阅读完 QuickStart 部分并且已经有了一个可用的基础 simulation。我们将应用一系列的重构来介绍更多 gatling 的高级特性和 DSL 结构。

第一步:隔离过程

目前,我们的 Simulation 是一个大的场景。所以首先我们把它分割为独立的业务流程,类似于 Selenium 的 PageObject 模式。

这样你就可以轻松地复用一些部分并构建复杂行为。

在我们的示例 scenario 中有 3 个独立的过程:

我们将这些操作提取出来并存储在单独的对象中,对象是单个本地 Scala 文件。你可以在专用文件中创建它们,或者直接在同一个 Simulation 文件中创建它们。

object Search {

  val search = exec(http("Home") // let's give proper names, as they are displayed in the reports
    .get("/"))
    .pause(7)
    .exec(http("Search")
    .get("/computers?f=macbook"))
    .pause(2)
    .exec(http("Select")
    .get("/computers/6"))
    .pause(3)
}

object Browse {

  val browse = ???
}

object Edit {

  val edit = ???
}

我们现在可以使用可复用的业务流程来重写我们的 scenario:

val scn = scenario("Scenario Name").exec(Search.search, Browse.browse, Edit.edit)

第二步:配置虚拟用户

所以,我们现在可以对我们的服务器进行加压测试了,用多少个用户呢? 一个!--- 显然,我们需要增加用户的数量。

我们定义两种常见用户:

翻译成场景如下:

val users = scenario("Users").exec(Search.search, Browse.browse)
val admins = scenario("Admins").exec(Search.search, Browse.browse, Edit.edit)

你只需要像下面这样配置 Simulation 就可以增加模拟用户的数量:

setUp(users.inject(atOnceUsers(10)).protocols(httpConf))

在这我们只设置 10 个用户,因为我们不希望淹没我们的测试用 Web 应用程序。请善待我们的服务器,不要让它崩溃。

如果要模拟 3000 个用户,你可能不希望他们在同一时间开始。事实上,真正的场景更可能是用户在逐渐地增加。

Gatling 提供 rampUsers 来实现此行为。ramp 的值表明在整个过程中用户将被线性地启动。

在我们的场景中我们使用 10 个普通用户和 2 个管理员用户,我们将在 10 秒内启动它们。

setUp(
  users.inject(rampUsers(10) over (10 seconds)),
  admins.inject(rampUsers(2) over (10 seconds))
).protocols(httpConf)

第三步:使用动态数据

我们设定我们模拟运行了一堆的用户,但他们都在搜索相同的记录。如果我们能让每个用户搜索不同的记录不是更好?

我们需要使用动态数据来使所有的用户不必执行完全相同的行为。这就需要 Feeders.

Feeders 是一个数据源,包含所有你想要在 scenarios 中使用的数据。

Feeders 有几种类型,最简单的是 CSV:这也是我们在测试中使用的类型。

首先创建一个名叫 search.csv 的文件并放置在 user-files/data 文件夹中。

这个文件包含下面几行内容:

searchCriterion,searchComputerName
Macbook,MacBook Pro
eee,ASUS Eee PC 1005PE

下面让我们在文件中使用它们:

object Search {

  val feeder = csv("search.csv").random // 1, 2

  val search = exec(http("Home")
    .get("/"))
    .pause(1)
    .feed(feeder) // 3
    .exec(http("Search")
    .get("/computers?f=${searchCriterion}") // 4
    .check(css("a:contains('${searchComputerName}')", "href").saveAs("computerURL"))) // 5
    .pause(1)
    .exec(http("Select")
    .get("${computerURL}")) // 6
    .pause(1)
}

代码解释:
1.首先我们创建了一个包含如下内容的 csv 文件:searchCriterion,searchComputerName.
2.由于默认的 feeder 策略是队列,所以我们在测试中显式指定随机策略来避免 feeder 中的数据不够用。
3.每当一个用户的行为需要数据时,从 feeder 文件中随机取一条数据,这样这个用户就有了两个新的 session 属性:searchCriterion,searchComputerName.
4.我们通过 Gatling 的 EL 使用 session 数据来参数化搜索.
5.我们使用带 EL 的 CSS 选择器来捕捉 HTML response 的一部分,并将其以 computerURL 的名称保存在用户 session 中。
6.我们使用之前保存的超链接来获得一个特定的页面。

注意:
有关 Feeders 的详细信息,请查看 Feeder reference page.
有关 HTTP Checks 的详细信息,请查看 Checks reference page.

第四步:循环

在浏览页面的过程中我们有大量的重复。使用不同参数值的相同请求有 4 次,我们能否改变这种情况来避免违反 DRY 原则?

首先我们重复执行的部分抽象为方法。事实上,Simulation 是纯 Scala 类,所以如果需要,我们可以使用编程语言的所有特性。

object Browse {

  def gotoPage(page: Int) = exec(http("Page " + page)
    .get("/computers?p=" + page))
    .pause(1)

  val browse = exec(gotoPage(0), gotoPage(1), gotoPage(2), gotoPage(3), gotoPage(4))
}

现在我们可以调用这个方法并传递所需的页码但是仍然有重复所以是时候介绍另一个内建的结构了
object Browse {

  val browse = repeat(5, "n") { // 1
    exec(http("Page ${n}")
      .get("/computers?p=${n}")) // 2
      .pause(1)
  }
}

代码解释:
1.repeat 内建方法是一个运行时的循环解决办法。它接受重复次数和保存在用户 Session 中的计数器名称
2.当我们指定计数器的名称时,我们可以在 Gatling EL 中使用它并访问第 N 个 page.

备注:
有关循环的更多信息,请查看 Loops reference page.

第五步:检查和故障管理

直到现在我们也只是使用 check 来解析 html response 中的一些数据并保存到 session 中。事实上 check 也可以用来检查 response 的属性。

默认情况下 Gatling 检查 http response 状态是否是 20X 或 304.

为了演示故障管理,我们将随机地介绍对失败情况的一次检查:

import java.util.concurrent.ThreadLocalRandom // 1

val edit = exec(http("Form")
  .get("/computers/new"))
  .pause(1)
  .exec(http("Post")
  .post("/computers")
  .check(status.is(session => 200 + ThreadLocalRandom.current.nextInt(2)))) // 2

代码解释:
1.首先 import ThreadLocalRandom,生成随机值。
2.对已经定制了 lambda 的情况进行检查。 每次用户执行请求是随机返回 200 或 201.当 response 状态是 200 时,检查随机失效。

为了处理随机失败我们使用 tryMaxexitHereIfFailed 结构,如下:

val tryMaxEdit = tryMax(2) { // 1
  exec(edit)
}.exitHereIfFailed // 2

代码解释:
1.tryMax 执行指定代码块 n 次。这里我们最大执行两次
2.如果全部失败,则用户退出整个场景

备注:
有关 conditional blocks 的更多信息,请查看 Conditional Statements reference page.

本文档的相关文档可以在 user-files/simulations 文件夹下找到。


↙↙↙阅读原文可查看相关链接,并与作者交流