英文文档地址：
http://gatling.io/docs/2.1.7/advanced_tutorial.html#advanced-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 时，检查随机失效。
为了处理随机失败我们使用 tryMax 和 exitHereIfFailed 结构，如下:
val tryMaxEdit = tryMax(2) { // 1
exec(edit)
}.exitHereIfFailed // 2
代码解释：
1.tryMax 执行指定代码块 n 次。这里我们最大执行两次
2.如果全部失败，则用户退出整个场景
备注：
有关 conditional blocks 的更多信息，请查看 Conditional Statements reference page.
本文档的相关文档可以在 user-files/simulations 文件夹下找到。