为什么使用selenium grid

Browser内的测试太慢
Browser内的测试与一个应用栈相关，并且和大量的浏览器之间的网络对话，网站服务器，数据库和其他处理器相关。这导致大量性能开销一点都不奇怪。当你的应用程序增长的时候，web验收测试要花半个多小时才跑完，导致了开发回馈周期的大量延迟。

维护花费是一个现实的挑战
使用Selenium,很容易去写或者创建大量Browser内的自动化测试。现实的挑战是，虽然是为了随着应用的成熟，降低维护成本，然后测试集随着时间不断增长。不管这些测试是多么的有价值，如果维护代价呈指数级增长，很难维持一个高的ROI。我们已经看到太多的测试会要求一个专职的QA或者developer全天的努力，只是为了使测试集能够pass，发现更多的测试集本身的bug，而并非应用程序的bug。

及时和可靠的回馈是很重要的
使维护费用低是一个很困难的事，只能用技术和最优方法相结合。然后，如果你的回馈周期太慢，被断断续续的失败侵占，两者都不工作。及时和有效地反馈是实验，创新和改进的关键。
更糟糕的是，如果没有快速的反馈循环，当你的开发团队比build失败被解决更快的时候，你会最终变成追踪一个破坏的selenium build。

硬件很便宜
Browser内的测试天生慢，但既然现在的硬件那么便宜，没有理由不在多台机器上并行运行这些测试，使反馈循环大大加快。这就是Selenium Grid。
你甚至不需要购买昂贵的server farm。在我们的经验里，几个Mac minis或者Linux Box可以帮助保持你的构建在10分钟之内！