Selenium-Grid是基于传统Selenium架构发展起来的,它有如下优点:
1.Selenium测试案例、待测Web应用系统、Remote Control/浏览器组合之间无须紧密耦合。它们之间通过HTTP进行通信,因此不需要工作在一台机器上。
2.Selenium测试案例和待测Web应用系统与具体项目相关。不过,无论Selenium Remote Control还是浏览器都与具体项目无关。事实上,它们可以在不同应用和项目间进行共享。
因此,只有通过建立一个基于Selenium Remote Control的网络,我们才能在不同版本、不同应用、不同项目,甚至于不同组织间共享测试平台。当然我们同样会面对前面提到的传统Selenium架构所面临的局限。这就解释了为什么我们需要一个全新组件,来解决如下问题:
如何透明地向测试案例指派一个Selenium Remote Control;
克服每个Remote Control支持的并发测试案例个数限制;
屏蔽测试案例对于测试平台架构的依赖
Selenium-Grid将这一组件称为Selenium Hub.
1.Hub拥有一个与传统Remote Control一模一样的对外接口。这就意味着测试案例集可以透明地选择一个传统Remote Control或者Selenium Hub,而无须为此更该代码,唯一需要改变的就是IP地址。它能屏蔽测试案例对网络基础架构(你可以对其进行扩展)的依赖,这一点很重要,它同样能够减轻测试人员的工作量。同样的测试案例,既可以在测试人员的办公机器上运行,也可以在网络分布式网络上运行,而不需要改变任何一行代码。
2.Hub会为每一个测试案例分配Selenium Remote Control。Hub同样负责来自测试案例的Selenium命令,路由至正确的Remote Control。同时它还会不断底跟踪测试进程。
3.当一个新测试启动后,如果Hub找不到符合测试要求的Remote Control,它就会暂存收到请求。一旦符合要求的Remote Control资源被释放,Hub就会立即响应这一请求。对于整个测试流程而言,测试案例并不需要知道Grid内部发生了什么;它需要做的仅仅是等待HTTP响应。
Selenium Grid的架构简图如图8-2所示。
想要发挥Selenium-Grid的优势,你必须并行地运行测试案例。如果使用Java来编写Selenium测试阿里,你可以选择TestNG parallel runs或者Parallel JUnit。如果你更喜欢Ruby,那么应该了解一下DeepTest或者spawn。总之,依赖于你选择的变成语言和开发平台是否提供并行执行测试案例的解决方案。
标签:Control,Remote,Selenium,案例,Grid,测试,软件测试 From: https://blog.51cto.com/u_15605684/7351707