anchor.diff:  </dependencies>
   --------------------------------------------------
   
  -Replace the elasticsearch version and the lucene version with the corresponding elasticsearch version and its accompanying lucene release.
  -
  -We provide a few classes that you can inherit from in your own test classes which provide:
  -
  -* pre-defined loggers
  -* randomized testing infrastructure
  -* a number of helper methods
  +将 elasticsearch 版本和 lucene 版本替换成你的 elasticsearch 版本和其对应的 lucene 版本。
  +你可以在你自己的测试类中继承我们提供的部分类，这些父类提供了以下功能：
  +
  +* 预定义的 loggers
  +* 随机测试基础框架
  +* 一些帮助方法
   
   
   [[unit-tests]]
  -=== unit tests
  -
  -If your test is a well isolated unit test which doesn't need a running elasticsearch cluster, you can use the `ESTestCase`. If you are testing lucene features, use `ESTestCase` and if you are testing concrete token streams, use the `ESTokenStreamTestCase` class. Those specific classes execute additional checks which ensure that no resources leaks are happening, after the test has run.
  -
  -
  +=== 单元测试
  +
  +如果你的单元测试用例隔离性很好，不需要运行在elasticsearch集群之上， 你可以使用 `ESTestCase`。 如果你需要测试 lucene 的功能， 使用 `ESTestCase`， 如果你需要测试具体的 token streams, 请使用 `ESTokenStreamTestCase` 这个类。 还有一些特别的测试类用来执行额外的检查以确保在单元测试运行后没用资源泄露。
   [[integration-tests]]
  -=== integration tests
  -
  -These kind of tests require firing up a whole cluster of nodes, before the tests can actually be run. Compared to unit tests they are obviously way more time consuming, but the test infrastructure tries to minimize the time cost by only restarting the whole cluster, if this is configured explicitly.
  -
  -The class your tests have to inherit from is `ESIntegTestCase`. By inheriting from this class, you will no longer need to start elasticsearch nodes manually in your test, although you might need to ensure that at least a certain number of nodes are up. The integration test behaviour can be configured heavily by specifying different system properties on test runs. See the `TESTING.asciidoc` documentation in the https://github.com/elastic/elasticsearch/blob/master/TESTING.asciidoc[source repository] for more information.
  -
  +=== 整合测试
  +
  +这类测试在运行之前，需要启动整个集群。 相对单元测试来说，整合测试显然更耗时，但是测试框架只在显式配置了每个用例需要重启集群时才会重启整个集群，通过这种方法来尽量减少耗时。
  +你的类需要继承的是 `ESIntegTestCase`。通过继承这个类， 你再也不用在测试用例中手动启动集群节点，然而你需要确保至少部分节点已经启动了。整合测试的行为可以通过配置不同的系统变量来定制。 更多信息参见 `TESTING.asciidoc` 文档 https://github.com/elastic/elasticsearch/blob/master/TESTING.asciidoc[source repository]。
   
   [[number-of-shards]]
  -==== number of shards
  -
  -The number of shards used for indices created during integration tests is randomized between `1` and `10` unless overwritten upon index creation via index settings.
  -The rule of thumb is not to specify the number of shards unless needed, so that each test will use a different one all the time. Alternatively you can override the `numberOfShards()` method. The same applies to the `numberOfReplicas()` method.
  -
  +==== 分片数
  +
  +除非在创建索引时通过索引设置改写分片数，整合测试中索引创建时的分片数是1 ~ 10 之间的随机数。
  +基本原则是除非特别需要，一般情况下不要设置分片数，这样每个测试用例将使用不同的分片数。 另外，你可以重写 `numberOfShards()` 方法和 `numberOfReplicas()`方法。
   
   [[helper-methods]]
  -==== generic helper methods
  -
  -There are a couple of helper methods in `ESIntegTestCase`, which will make your tests shorter and more concise.
  -
  -[horizontal]
  -`refresh()`::           Refreshes all indices in a cluster
  -`ensureGreen()`::       Ensures a green health cluster state, waiting for relocations. Waits the default timeout of 30 seconds before failing.
  -`ensureYellow()`::      Ensures a yellow health cluster state, also waits for 30 seconds before failing.
  -`createIndex(name)`::   Creates an index with the specified name
  -`flush()`::             Flushes all indices in a cluster
  -`flushAndRefresh()`::   Combines `flush()` and `refresh()` calls
  -`optimize()`::          Waits for all relocations and optimized all indices in the cluster to one segment.
  -`indexExists(name)`::   Checks if given index exists
  -`admin()`::             Returns an `AdminClient` for administrative tasks
  -`clusterService()`::    Returns the cluster service java class
  -`cluster()`::           Returns the test cluster class, which is explained in the next paragraphs
  +==== 常用 helper 方法
  +
  +`ESIntegTestCase` 类中有一些帮助方法，使用这些方法可以是你的整合测试用例更简短和具体。
  +[horizontal]
  +`refresh()`::           更新集群中所有的索引
  +`ensureGreen()`::       在等待重新分配分片分布时， 确保集群状态变绿， 等待时间默认是30秒
  +`ensureYellow()`::      确保集群状态变为黄色， 默认等待时间也是 30 秒
  +`createIndex(name)`::   用给定的名称创建一个索引
  +`flush()`::             刷新集群中得所有索引
  +`flushAndRefresh()`::   组合 `flush()`和 `refresh()` 两个调用到一起。
  +`optimize()`::          等待所有的重新分片并且优化集群中的所有索引到一个索引段
  +`indexExists(name)`::   检查索引名称是否存在
  +`admin()`::             针对某些管理任务，返回一个 `AdminClient` 对象
  +`clusterService()`::    返回集群服务这个 java 对象
  +`cluster()`::           返回测试集群类，这个概念将在下一节讲解
   
   
   [[test-cluster-methods]]
  -==== test cluster methods
  -
  -The `InternalTestCluster` class is the heart of the cluster functionality in a randomized test and allows you to configure a specific setting or replay certain types of outages to check, how your custom code reacts.
  -
  -[horizontal]
  -`ensureAtLeastNumNodes(n)`::        Ensure at least the specified number of nodes is running in the cluster
  -`ensureAtMostNumNodes(n)`::         Ensure at most the specified number of nodes is running in the cluster
  -`getInstance()`::                   Get a guice instantiated instance of a class from a random node
  -`getInstanceFromNode()`::           Get a guice instantiated instance of a class from a specified node
  -`stopRandomNode()`::                Stop a random node in your cluster to mimic an outage
  -`stopCurrentMasterNode()`::         Stop the current master node to force a new election
  -`stopRandomNonMaster()`::           Stop a random non master node to mimic an outage
  -`buildNode()`::                     Create a new elasticsearch node
  -`startNode(settings)`::             Create and start a new elasticsearch node
  +==== 测试集群方法
  +
  +在随机测试中， `InternalTestCluster` 类是核心， 它可以让你配置一个特定的设置，或者重放某些错误异常，来查看你的自定义代码如何响应
  +
  +[horizontal]
  +`ensureAtLeastNumNodes(n)`::        至少需要集群中指定个节点已经正常启动
  +`ensureAtMostNumNodes(n)`::         最多需要集群中指定数量的节点已经启动
  +`getInstance()`::                   从随机节点中获取一个 guice 实现实例
  +`getInstanceFromNode()`::           从指定节点中获取guice实现实例
  +`stopRandomNode()`::                停止一个随机节点，来模拟集群中出现的一个问题
  +`stopCurrentMasterNode()`::         停止当前的主节点，从而强制产生新的主节点选举流程
  +`stopRandomNonMaster()`::           停止一个非主节点的节点，来模拟错误
  +`buildNode()`::                     新建一个 elasticsearch 节点
  +`startNode(settings)`::             新建并启动一个 elasticsearch 节点
   
   
   [[changing-node-settings]]
  -==== Changing node settings
  -
  -If you want to ensure a certain configuration for the nodes, which are started as part of the `EsIntegTestCase`, you can override the `nodeSettings()` method
  -
  +==== 更改节点配置
  +
  +如果你需要特别设置节点的某些配置，这也是 `EsIntegTestCase` 所支持的，你只要重写 `nodeSettings()` 方法就可以了。
   [source,java]
   -----------------------------------------
   public class Mytests extends ESIntegTestCase {
  
positive.code: }
  -----------------------------------------
  
  The above sample configures the test to use a new cluster for each test method. The default scope is `SUITE` (one cluster for all test methods in the test). The `numNodes` settings allows you to only start a certain number of nodes, which can speed up test execution, as starting a new node is a costly and time consuming operation and might not be needed for this test.
  
  
  [[changing-node-configuration]]
  ==== Changing plugins via configuration
  
  As elasticsearch is using JUnit 4, using the `@Before` and `@After` annotations is not a problem. However you should keep in mind, that this does not have any effect in your cluster setup, as the cluster is already up and running when those methods are run. So in case you want to configure settings - like loading a plugin on node startup - before the node is actually running, you should overwrite the `nodeSettings()` method from the `ElasticsearchIntegrationTest` class and change the cluster scope to `SUITE`.
  
  [source,java]
  -----------------------------------------
  @Override
  
negative.code: -----------------------------------------
  
  [[randomized-testing]]
  === 随机测试
  
  目前为止，你看到的代码片段并没有体现出随机测试的任何特性，那是因为这些细节被小心的被隐藏在底层了。然而，在你写自己的测试用例时，你也应该使用这些特性。在开始之前，你需要知道，如何重现一个失败的测试用例，它是如何失败的。幸运的是，这特别简单，因为整个mvn调用信息和失败的测试用例一起被记录了下来，这样你就可以简单的复制粘贴那一行，并重新执行该测试就好了。
  
  [[generating-random-data]]
  ==== 随机数据生成
  
  接下来就是将你的测试用例从使用静态测试数据转变为使用随机测试数据。 你需要随机化的数据随着你的测试功能的不同可能有比较大的差异。看下面的例子（注意，下面的列表中得内容可能会改变，因为分布式系统经常会有很多很多的变化）：
  
  * 搜索那些包含任意UTF8字符的数据
  * 在每个用例中改变映射配置，索引和字段名称
  * 在每个用例中改变你的请求返回的数据量或者改变配置的最大限制记录数
  * 在创建索引时改变主分片或从分片的大小
  
  那么，如何生成随机数据呢。你需要知道的最重要的一点是， 你不应该自己实例化 `Random` 实例，而应该使用 `RandomizedTest` 所提供的实例， 所有elasticsearch测试类都是从这个类继承而来的。
  [horizontal]
  `getRandom()`::         返回一个random的实例，这个实例也可以通过传入特别的参数来重新创建一个新的。
  `randomBoolean()`::     返回一个随机 boolean 对象
  `randomByte()`::        返回一个随机 byte 对象
  `randomShort()`::       返回一个随机 short 对象
  `randomInt()`::         返回一个随机 integer 对象
  `randomLong()`::        返回一个随机 long 对象
  `randomFloat()`::       返回一个随机 float 对象
  `randomDouble()`::      返回一个随机 double 对象
  
  `randomInt(max)`::      返回一个0到 max 之间的随机 integer 对象
  `between()`::           返回一个指定范围内的随机值
  `atLeast()`::           返回一个不小于某个数的随机 integer 对象
  `atMost()`::            返回一个不超过某个数的随机 integer 对象
  
  `randomLocale()`::      返回一个随机 locale 对象
  `randomTimeZone()`::    返回一个随机 timezone 对象
  
  `randomFrom()`::        从一个 list/array 中随机返回一个元素
  
  另外，在这个随机测试类中，还包含一些帮助方法，可以用它们生成随机 ASCII 和 Unicode 字符串， 见方法名以 `randomAscii`, `randomUnicode`, 和 `randomRealisticUnicode` 开头的那些方法。
  如果你在调试一个特别的问题时，需要用到一个特别的随机种子， 可以使用 `@Seed` 这个注解来达到在测试用例中配置一个特定种子的目的。 如果你希望运行一个测试用例多次，不需要一次又一次的重启该测试套件，你可以直接使用 `@Repeat` 注解就可以了，该注解可以设置重复任意次数， 每次迭代使用一个不同的随机种子。
  
  [[assertions]]
  === 断言
  
  As many elasticsearch tests are checking for a similar output, like the amount of hits or the first hit or special highlighting, a couple of predefined assertions have been created. Those have been put into the `ElasticsearchAssertions` class. There is also a specific geo assertions in `ElasticsearchGeoAssertions`.
  由于在 elasticsearch 中经常需要检查一些相似的输出，比如匹配到的文档数量，第一个匹配文档，或者是特殊高亮片段，因此预置了一些断言。 这些断言被放在 `ElasticsearchAssertions` 类中。 同时， 特别针对 geo 相关处理的断言也可以在 `ElasticsearchGeoAssertions` 中找到。
  [horizontal]
  `assertHitCount()`::        检查搜索或者 count 请求匹配到的文档数量
  `assertAcked()`::           确保一个请求被主节点接受了
  `assertSearchHits()`::      断言一个请求返回中包含特定的id列表
  `assertMatchCount()`::      对于percolation请求，断言匹配数
  `assertFirstHit()`::        断言第一个文档，命中了特定的匹配规则
  `assertSecondHit()`::       断言第二个文档，命中了特定的匹配规则
  `assertThirdHit()`::        断言第三个文档，命中了特定的匹配规则
  `assertSearchHit()`::       断言返回中指定文档，命中了特定的匹配规则
  `assertNoFailures()`::      断言在返回中不包含分片失败的信息
  `assertFailures()`::        断言在返回中包含有分片失败的信息
  `assertHighlight()`::       断言有指定的高亮片段被匹配到
  `assertSuggestion()`::      断言包含指定的搜索建议
  `assertSuggestionSize()`::  断言包含指定的搜索建议数
  `assertThrows()`::          断言某个特定的异常被抛出
  
  通用匹配器
  
  [horizontal]
  `hasId()`::     检查匹配到的文档id的匹配器
  `hasType()`::   检查匹配到的文档类型的匹配器
  `hasIndex()`::  检查匹配到的文档所属索引的匹配器
  `hasScore()`::  检查匹配到的文档得分的匹配器
  `hasStatus()`:: 检查返回中是否包含特定 `RestStatus` 的匹配器
  
  通常， 你需要像下面这样组合使用断言和匹配器
  [source,java]
  ----------------------------
  SearchResponse seearchResponse = client().prepareSearch() ...;
  