很多敏捷团队已经使用了Selenium和Watir等 工具进行验收测试或用户接口测试。这些工具通过驱动Web浏览器的方式反映用户体验，并且为测试那些使用DHTML和Ajax构建的动态接口提供强力支持。然而，随着更多的团队采纳类似的工具，他们发现，运行这一整套浏览器驱动的Web接口测试会花费很长时间，而导致构建太慢。敏捷团队可能不得不在全 面测试和构建速度之间做出艰难的选择。使用Selenium的用户中，有人通过使用Selemium-RC运行多个测试，也有人将测试分配给多个 Selemium-RC运行测试，但帮助有限。虽然对于少量并行是有效的，但对于大量并行却无能为力。Selenium用户现在有了另一种选择：Selenium Grid。

Selenium Grid是Selenium的一个扩展，也是免费且开源的(Apache License 2.0)。它把管理一小撮Selenium-RC实例的事情和为了运行一个测试而连接一个Selenium实际的事情分开了。实际上，Selenium Grid是提供了一个hub，象个用于控制测试的远程控制器，但是是显式地将测试请求发送到一个或多个机器上的某个有效的Selenium-RC实例上。 这个Selenium Hub负责以下这些事情：

    将一个SeleniumRC显式地分配给一个具体的测试
    限制在每个RC大并发测试数
    将测试屏蔽在一个实际的网格结构之外。

使用Selenium Gird时，Selenium测试可以通过名称选择具体环境的实例，例如某个测试可以运行在Windows XP系统的IE7上，而其它实例却指定运行在Ubuntu的Firefox 1.5之上。

更重要的是，它允许组织构建一个复杂的包含多种必要的测试环境的测试机群，并在其上并行运行一个或多个项目的测试。这将在测试方面有显著的提高，终减少每个项目所需要的基础设施。某些大型组织对这一点认识的为深刻（比如Google在用相似的方法），但即使是对于单个项目的单个机器也是有价值的。

Selenium-RC 近已经大幅度地改进了性能，包括在单一线程的环境下。但是，多机器多线程测试对于长时间测试来说还是有相当大的益处的。利用足够的测试处理能力和测试的独立性，对于减少长测试的时间是可行的。

虽然这些测试可以不必知道自己是在单机上顺序运行还是运行于整个机群，但Selenium Grid却不负责这些测试的并行执行，这些是由TestNG，Parallel JUnit和DeepTest for Ruby等完成的。

InfoQ采访了Selenium Grid的团队成员，并问及并行执行测试可能对Selenium测试用例的影响：

    我们讨论过隔离性，以及开发Grid之前所面临的问题。我们想现在把这个担子交给写测试的人，让他们来设计测试用例，以确保它们之间不会相互影响。当 然，这个问题在Gird产生之前已经存在了。你不想让你的Selenium受其执行顺序的影响，那在每个测试执行之前要做一些数据初始化工作，执行这后 再清理掉。然而，这不是一个优雅的解决方案。理想情况下，你的Selenium test好只了解这个应用的前端，但实际上，通过暴露一点数据给测试，会使针对具体的Scenarios写测试比较快且方便，而且由于只要较少的导航页 可达到被测试页，运行时间会较少。嗯，看来有一点儿道理啦！但是不管怎么样，我们还是希望Grid能够支持这两种方式，不久前我们找到了一些方法可以在 数据库层隔离这些测试。虽然还只算是alpha版，但它可能会成为Grid的一部分，也可有是一个独立的项目。

在谈到Selenium Grid的未来时，开发团队认为以下特性中的内容终会成为Selenium Grid的一部分：

    一个更完善的管理控制台
    成为Windows服务(以及solaris，Linux等操作系统的等价物)
    屏保功能（桌面电脑在闲置时可以加入Grid）
    为用Amazon's EC2 (Electronic Compute Cloud)基础设施作为Selenium测试机群提供支持