此篇博文主要是做名词解释，原始文章地址：http://gatling.io/docs/2.1.7/general/concepts.html
下一期将详细介绍 gatling 用于做用户并发模式的 Simulation Setup
还是那句，欢迎转载，不过请注明出处。
一些负载测试工具，像 ab、wrk，在 url 压测的时候是很有效率的。但是它们不能很好地处理请求之间的逻辑关系。
像 Gatling 这样的高级负载测试工具就可以很好地处理虚拟用户。让每一个虚拟用户都使用不同的参数，甚至是请求到不同的地址去。
其他一些测试工具使用线程的方式来实现虚拟用户。但是 Gatling 的实现方式是通过消息，这样做更好，处理起几千个虚拟用户来说毫不费力。
我们可以通过 Gatling 自带的脚本来创建场景，从而实现模拟用户的操作。
创建场景既可以根据线上运行的数据分析工具提供的数据，也可以是一个新应用里我们预期的用户操作。无论如何，创建场景都是做负载测试的关键所在，必须重视。
场景代表着用户的典型操作，也是各虚拟用户必须遵守的操作流程。
举例来说，一个典型的电商应用的场景大致如下：
1.进入主页；
2.选择浏览的商品类型；
3.在这个类型中搜索商品；
4.打开商品的详细描述；
5.返回；
6.打开另一个商品的详细描述页面；
7.点击购买这个商品；
8.登录；
9.权限校验；
10.支付；
11.退出登录；
在 gatling 里面，我们可以使用 DSL 来实现场景。DSL 语言实现和维护起来都非常简单。
下面是一个简单的 DSL 实现例子：
scenario("Standard User")
.exec(http("Access Github").get("https://github.com"))
.pause(2, 3)
.exec(http("Search for 'gatling'").get("https://github.com/search?q=gatling"))
.pause(2)
上面这段代码，我们可以大致猜到它的意思：
1.实现了一个叫 “Standard User” 的场景；
2.发了 2 个请求；
3.暂停了 2 次；
这里的 pause，用于设置用户的思考时间。当一个真实的用户点击链接的时候，加载网页就有一段时间，用户必须等待这个时间。大多数时候，用户需要阅读下页面内容再进行下一步操作。
HTTP 请求实际上是由用户点击一个按钮或者链接触发的。每个 HTTP 请求（包括页面的资源请求）都是很容易抓取的。
进入 Github 是一个 GET 请求（点击 http://github.com）
搜索 “ gatling” 也是一个 GET 请求（点击 gatling）
想知道更多关于场景的知识，点击：http://gatling.io/docs/2.1.7/general/scenario.html#scenario
译者觉得这里的 simulation 暂时找不到合适的翻译，也许直接使用 simulation 就是最好的表达方式。
Simulation 其实就是负载测试的描述。它解释了用户执行了哪些操作（可能是好几个操作）、执行哪些场景，新的用户怎么被注入等等。
下面是一个 simulation 的应用例子：
val stdUser = scenario("Standard User") // etc..
val admUser = scenario("Admin User") // etc..
val advUser = scenario("Advanced User") // etc..
setUp(
stdUser.inject(atOnceUsers(2000)),
admUser.inject(nothingFor(60 seconds), rampUsers(5) over (400 seconds)),
advUser.inject(rampUsers(500) over (200 seconds))
)
译者试着简单解释下三种用户的操作方式：
atOnceUsers -- 立即并发的用户；
nothingFor 再 rampUsers -- 先停止一段时间再操作的线性启动用户；
rampUsers -- 线性启动的用户（每隔一段时间再启动，推荐这种初始化用户的方式）；
想知道更多关于 simulation 的知识，点击：http://gatling.io/docs/2.1.7/general/simulation_setup.html#simulation-setup
每一个虚拟用户都有一个 Session 支持着。这些 session 都是实际的工作流中的数据信息。Session 是一个测试者可以用来注入、捕获、存储数据的的占位符。
译者：session 其实是数据管理用的
想知道更多关于 session 的知识，点击：http://gatling.io/docs/2.1.7/session/session_api.html#session
译者注：译者对自己的语言知识表示羞愧，又是一个不知道咋翻译的词。
有些测试应用需要校验数据，比如一些登录、登出等等需要特定用户/数据才能操作的场景。测试者需要考虑下数据。
Gatling 本身并不提供生成测试数据的工具。
Feeder 就是一个方便用户将外部资源存储的数据注入到虚拟用户的 session 中的一些 API。
想知道更多关于 feeder 的知识，点击：http://gatling.io/docs/2.1.7/session/feeder.html#feeder
我们使用 gatling 发送请求的时候，一般情况下是有返回的，比如 xml、json 或者 html 等返回到 gatling。
Gatling 中，就是用 checks 来检查、分析、校验返回（response）的结果。也可以预设一些检查的条件。举例来说，当发送一个 HTTP 请求的时候，你希望检查下这个请求的重定向地址。使用了 Check，你就可以检查到返回的状态码是 30 几开头的。
Checks 也可以用来捕获一些页面元素并存到 session 里面，这样我们就可以在下一个请求中重复使用这些数据了。
想知道更多关于 Checks 的知识，点击：http://gatling.io/docs/2.1.7/http/http_check.html#http-check
断言用来定义测试成功的标准。如果 Assertion 失败了，会返回一个全局定义的错误码。
想知道更多关于 Assertions 的知识，点击：http://gatling.io/docs/2.1.7/general/assertions.html#assertions
在一个 simulation 结束后，gatling 会自动生成一个 html 版本的测试报告。因为是 html 格式的，任何有浏览器的设备都能方便地浏览。
想知道更多关于 reports 的知识，点击：http://gatling.io/docs/2.1.7/general/reports.html#reports