Selenium Grid: 并行的 Web 测试

很多敏捷团队已经使用了 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 测试机群提供支持

ThoughtWorks 将为那些希望了解和使用 Selenium-RC 和 Selenium Grid 提供支持和咨询服务。

想了解更多，请访问 Selenium Grid 的网站 （正准备在 OpenQA 上立项），也可以在 InfoQ 了解更多关于测试 和单元测试 的相关内容。

查看英文原文： Selenium Grid: Web Testing in Parallel