这是本节的多页打印视图。
点击此处打印.
返回本页常规视图.
Grid
要在多台计算机上并行运行测试吗? 那么, Grid正是为你准备的.
通过将客户端命令发送到远程浏览器的实例,
Selenium Grid 允许在远程计算机 (虚拟或真实) 上执行WebDriver脚本.
它旨在提供一种在多台计算机上并行运行测试的简便方法.
Selenium Grid允许我们在多台计算机上并行运行测试,
并集中管理不同的浏览器版本和浏览器配置
(而不是在每个独立的测试中).
Selenium Grid不是银弹.
它解决了一些常见的委派和分布式问题,
但是例如无法管理基础架构这样的问题,
可能不适合您的特定需求.
目的和主要功能
- 为所有的测试提供统一的入口
- 管理和控制运行着浏览器的节点/环境
- 扩展
- 并行测试
- 跨平台(操作系统)测试
- 负载测试
Selenium Grid 4
Grid 4有一种实现可以利用许多新技术来促进扩展,
同时仍然允许本地执行.
Selenium Grid 4 是全新的实现,
并且不共享之前版本的代码库.
关于Grid 4组件的所有详细信息,
了解其工作原理以及如何设置自己的组件,
请浏览以下章节.
1 - Selenium Grid快速起步
一步一步地说明如何运行简单的Selenium Grid.
Grid roles
Several components compose a Selenium Grid. Depending
on your needs, you can start each one of them on its own, or a few at the same time by using a
Grid role.
Standalone
Standalone is the union of all components, and to the user’s eyes, they are executed as one.
A fully functional Grid of one is available after starting it in the Standalone mode.
Standalone is also the easiest mode to spin up a Selenium Grid. By default, the server
will be listening on http://localhost:4444
, and that’s the URL you should point your
RemoteWebDriver
tests. The server will detect the available drivers that it can use
from the System PATH
.
java -jar selenium-server-<version>.jar standalone
Hub and Node(s)
It enables the classic Hub & Node(s) setup. These roles are suitable for small
and middle-sized Grids.
Hub
A Hub is the union of the following components:
- Router
- Distributor
- Session Map
- New Session Queue
- Event Bus
java -jar selenium-server-<version>.jar hub
By default, the server will be listening on http://localhost:4444
, and that’s the URL
you should point your RemoteWebDriver
tests.
Node(s)
One or more Nodes can be started in this setup, and the server will detect the available
drivers that it can use from the System PATH
.
java -jar selenium-server-<version>.jar node
Distributed
On Distributed mode, each component needs to be started on its own. This setup is more suitable
for large Grids.
The startup order of the components is not important, however, we recommend following these
steps when starting a distributed Grid.
- Event Bus: serves as a communication path to other Grid components in subsequent steps.
java -jar selenium-server-<version>.jar event-bus
- Session Map: responsible for mapping session IDs to the Node where the session is running.
java -jar selenium-server-<version>.jar sessions
- New Session Queue: adds the new session request to a queue, then the distributor processes it.
java -jar selenium-server-<version>.jar sessionqueue
- Distributor: Nodes register to it, and assigns a Node for a session request.
java -jar selenium-server-<version>.jar distributor --sessions http://localhost:5556 --sessionqueue http://localhost:5559 --bind-bus false
- Router: the Grid entrypoint, in charge of redirecting requests to the right component.
java -jar selenium-server-<version>.jar router --sessions http://localhost:5556 --distributor http://localhost:5553 --sessionqueue http://localhost:5559
- Node(s)
java -jar selenium-server-<version>.jar node
Running tests
To run tests after starting successfully Selenium Grid, you can use a RemoteWebDriver
.
Head to the RemoteWebDriver
section for
more details.
You can add metadata to your tests and consume it via GraphQL
or visualize parts of it through the Selenium Grid UI. Metadata can be added by prefixing the metadata with se:
.
Here is a quick example in Java showing how to do that.
ChromeOptions chromeOptions = new ChromeOptions();
chromeOptions.setCapability("browserVersion", "100");
chromeOptions.setCapability("platformName", "Windows");
// Showing a test name instead of the session id in the Grid UI
chromeOptions.setCapability("se:name", "My simple test");
// Other type of metadata can be seen in the Grid UI by clicking on the
// session info or via GraphQL
chromeOptions.setCapability("se:sampleMetadata", "Sample metadata value");
WebDriver driver = new RemoteWebDriver(new URL("http://gridUrl:4444"), chromeOptions);
driver.get("http://www.google.com");
driver.quit();
Querying Selenium Grid
After starting a Grid, there are mainly two ways of querying its status, through the Grid
UI or via an API call.
The Grid UI can be reached by opening your preferred browser and heading to
http://localhost:4444.
API calls can be done through the http://localhost:4444/status
endpoint or using GraphQL
For simplicity, all command examples shown in this page assume that components are running
locally. More detailed examples and usages can be found in the
Configuring Components section.
提醒
Selenium服务网格需要使用合适的防火墙许可来隔离外部访问。
如果不能有效的保护你的服务网格,可能会导致以下问题:
- 提供了一个开发的接口来访问服务网格的基础设施
- 你将会允许第三方来访问内部web服务和文件
- 你将会允许第三方来执行定制的二进制文件
请参考这篇文章Detectify, 这里给了一个很好的概要,
关于暴露一个服务网格后会如何被滥用:Don’t Leave your Grid Wide Open.
2 - 什么时候应该使用Grid
Grid是适合您的工具吗?
通常来说,有2个原因你需要使用Grid。
- 在多种浏览器,多种版本的浏览器,不同操作系统里的浏览器里执行你的测试
- 缩短完成测试的时间
Grid通过使用多台终端机器来并行执行测试,以达到加速测试执行的目的。
比如的测试套件里包含100个测试,你的Grid支持4种不同的终端(虚拟机或者独立的物理设备)
来执行这些测试,相比你只有一台终端来执行,你的测试套件只需要4分之1的时间。
在一些大型测试套件,或者一些长时间执行的测试比如执行大量的数据校验,这样做会节约大量的时间。
一些测试会需要几个小时。另一个改善的动力来自缩短这种耗时的测试的是为了开发人员从提交代码到获得测试结果的期间。软件开发团队实践敏捷开发时期望尽可能早的得到测试反馈,而不是一晚一晚的等测试通过。
Grid也会被用来支持在不同的运行环境的测试,比如,在同一实践针对不同浏览器的测试。
比如,一个由虚拟机组成的Grid,每一个终端机可以支持一个不同的应用程序需要支持的浏览器。
比如终端1有IE8,终端2有IE9,终端3有最新的Chrmoe,终端4有最新的Firefox。当所有的测试套件都执行了,
Selenium Grid会接受每个测试浏览器组合的要求,然后安排每个测试被执行在所要求的浏览器上。
另外,一个Grid可以包含同样的浏览器,类型,版本。比如,你可以有一个包含4台终端,没个终端包含3个
Firefox70的实例的网格,提供了一个服务器集群提供可用的Firefox实例。当测试套件被执行的时候,每个被提交进Grid的测试会被分发到可用的Firefox实例。在这个情况下,同一时间可以有12个测试被并行的执行,
显著的缩短的整个测试完成的时间。
Grid是弹性的。这2个例子可以被组合来创建多种实例的浏览器和版本。通过配置,可以提供并行执行以加速测试,或者支持多种浏览器版本的模拟2中能力。
3 - 服务网格的组件
检查不同的Grid组件以了解如何使用它们.
路由
路由负责将请求转发到正确的组件.
它是Grid的入口点, 所有外部请求都将由其接收.
路由的行为因请求而异.
当请求一个新的会话时, 路由将把它添加到新的会话队列中.
分发器定期检查是否有空闲槽.
若有, 则从新会话队列中删除第一个匹配请求.
如果请求属于存量会话,
这个路由将会话id发送到会话表,
会话表将返回正在运行会话的节点.
在此之后, 路由将
将请求转发到节点.
为了更好地发挥效力,
路由通过将请求发送到组件的方式,
来平衡Grid的负载,
从而使处理过程中不会有任何的过载组件.
分发器
分发器知道所有节点及其功能.
它的主要作用是接收新的会话请求
并找到可以在其中创建会话的适当节点.
创建会话后, 分发器在会话集合中存储会话ID与正在执行会话的节点之间的关系.
节点
一个节点可以在网格中出现多次.
每个节点负责管理其运行机器的可用浏览器的插槽.
节点通过事件总线将其自身注册到分发服务器,
并且将其配置作为注册消息的组成部分一起发送.
默认情况下,
节点自动注册其运行机器路径上的
所有可用浏览器驱动程序.
它还为基于Chromium的浏览器和Firefox的
每个可用CPU创建一个插槽.
对于Safari和Internet Explorer,
只创建一个插槽.
通过特定的配置,
它可以在Docker容器或中继命令中运行会话.
您可以在下一 章节
中看到更多配置详细信息.
节点仅执行接收到的命令,
它不进行评估、做出判断或控制任何事情.
运行节点的计算机不需要与其他组件具有相同的操作系统.
例如, Windows节点可以具有将Internet Explorer作为浏览器选项的功能,
而在Linux或Mac上则无法实现.
会话表
会话表是一种数据存储的方式,
用于保存会话id和会话运行的节点的信息.
它作为路由支持,
在向节点转发请求的过程中起作用.
路由将通过会话表获取与会话id关联的节点.
新会话队列
新会话队列以先进先出的顺序保存所有新会话请求.
其具有用于设置请求超时和请求重试间隔的可配置参数.
路由将新会话请求添加到新会话队列并等待响应.
新会话队列定期检查队列中的任何请求是否已超时,
若有,则请求将被拒绝并立即删除.
分发器定期检查是否有可用槽.
若有, 分发器将为第一个匹配的请求索取新会话队列.
然后分发器会尝试创建新的会话.
一旦请求的功能与任何空闲节点槽匹配,
分发器将尝试获取可用槽.
如果没有空闲槽,
分发器会要求队列将请求添加到队列前面.
如果请求在重试或添加到队列头时超时,
则该请求将被拒绝.
成功创建会话后,
分发器将会话信息发送到新会话队列.
新会话队列将响应发送回客户端.
事件总线
事件总线充当节点、分发服务器、新的会话队列器和会话表之间的通信路径.
网格通过消息进行大部分内部通信, 避免了昂贵的HTTP调用.
当以完全分布式模式启动网格时, 事件总线是应该启动的第一个组件.
运行你自己的Grid
期待使用所有组件并运行自己的Grid?
前往
“配置自己的服务网格” ,
了解如何将所有零件组合在一起.
4 - 配置组件
在这里,您可以看到如何根据公共配置值和特定于组件的配置值分别配置每个网格组件.
4.1 - 配置帮助
获取有关配置网格的所有可用选项的信息.
Help命令显示基于当前代码实现的信息.
因此, 如果文档没有更新, 它将提供准确的信息.
这是了解任何新版本Grid4配置的最便捷方法.
信息命令
Info命令提供以下主题的详细文档:
配置帮助
通过运行以下命令快速获取配置帮助:
java -jar selenium-server-<version>.jar info config
安全
获取构建网格服务器的详细信息,
用于安全通信和节点注册.
java -jar selenium-server-<version>.jar info security
会话表配置
默认情况下,
网格使用本地会话表来存储会话信息.
网格支持额外的存储选项,
比如Redis和JDBC-SQL支持的数据库.
要设置不同的会话存储,
请使用以下命令获取设置步骤:
java -jar selenium-server-<version>.jar info sessionmap
基于OpenTelemetry和Jaeger的追踪配置
默认情况下, 追踪是启用的.
要通过Jaeger导出追踪并将其可视化,
请使用以下命令进行说明:
java -jar selenium-server-<version>.jar info tracing
列出Selenium网格的命令
java -jar selenium-server-<version>.jar --config-help
上述命令将显示所有可用的命令及其描述.
组件帮助命令
在Selenium后面键入–help的配置选项,
以获取特定组件的配置信息.
Standalone
java -jar selenium-server-<version>.jar standalone --help
Hub
java -jar selenium-server-<version>.jar hub --help
Sessions
java -jar selenium-server-<version>.jar sessions --help
队列器
java -jar selenium-server-<version>.jar sessionqueue --help
Distributor
java -jar selenium-server-<version>.jar distributor --help
Router
java -jar selenium-server-<version>.jar router --help
Node
java -jar selenium-server-<version>.jar node --help
4.2 - CLI 选项
所有网格组件配置CLI选项的详细信息.
Page being translated from
English to Chinese. Do you speak Chinese? Help us to translate
it by sending us pull requests!
Different sections are available to configure a Grid. Each section has options can be configured
through command line arguments.
A complete description of the component to section mapping can be seen below.
Note that this documentation could be outdated if an option was modified or added
but has not been documented yet. In case you bump into this situation, please check
the “Config help” section and feel free to send us a
pull request updating this page.
Sections
Distributor
Option | Type | Value/Example | Description |
---|
--grid-model | string | org.openqa.selenium.grid.distributor.GridModel | Full classname of non-default grid model. This is used to store the states of all the registered Nodes. |
--healthcheck-interval | int | 120 | How often, in seconds, will the health check run for all Nodes. This ensures the server can ping all the Nodes successfully. |
--distributor | uri | http://localhost:5553 | Url of the distributor. |
--distributor-host | string | localhost | Host on which the distributor is listening. |
--distributor-implementation | string | org.openqa.selenium.grid.distributor.local.LocalDistributor | Full class name of non-default distributor implementation |
--distributor-port | int | 5553 | Port on which the distributor is listening. |
--reject-unsupported-caps | boolean | false | Allow the Distributor to reject a request immediately if the Grid does not support the requested capability. Rejecting requests immediately is suitable for a Grid setup that does not spin up Nodes on demand. |
--slot-matcher | string | org.openqa.selenium.grid.data.DefaultSlotMatcher | Full class name of non-default slot matcher to use. This is used to determine whether a Node can support a particular session. |
--slot-selector | string | org.openqa.selenium.grid.distributor.selector.DefaultSlotSelector | Full class name of non-default slot selector. This is used to select a slot in a Node once the Node has been matched. |
Docker
Option | Type | Value/Example | Description |
---|
--docker-assets-path | string | /opt/selenium/assets | Absolute path where assets will be stored |
--docker- | string[] | selenium/standalone-firefox:latest '{"browserName": "firefox"}' | Docker configs which map image name to stereotype capabilities (example `-D selenium/standalone-firefox:latest ‘{“browserName”: “firefox”}’) |
--docker-devices | string[] | /dev/kvm:/dev/kvm | Exposes devices to a container. Each device mapping declaration must have at least the path of the device in both host and container separated by a colon like in this example: /device/path/in/host:/device/path/in/container |
--docker-host | string | localhost | Host name where the Docker daemon is running |
--docker-port | int | 2375 | Port where the Docker daemon is running |
--docker-url | string | http://localhost:2375 | URL for connecting to the Docker daemon |
--docker-video-image | string | selenium/video:latest | Docker image to be used when video recording is enabled |
Events
Option | Type | Value/Example | Description |
---|
--bind-bus | boolean | false | Whether the connection string should be bound or connected. When true, the component will be bound to the Event Bus (as in the Event Bus will also be started by the component, typically by the Distributor and the Hub). When false, the component will connect to the Event Bus. |
--events-implementation | string | org.openqa.selenium.events.zeromq.ZeroMqEventBus | Full class name of non-default event bus implementation |
--publish-events | string | tcp://*:4442 | Connection string for publishing events to the event bus |
--subscribe-events | string | tcp://*:4443 | Connection string for subscribing to events from the event bus |
Logging
Option | Type | Value/Example | Description |
---|
--http-logs | boolean | false | Enable http logging. Tracing should be enabled to log http logs. |
--log-encoding | string | UTF-8 | Log encoding |
--log | string | Windows path example :
'\path\to\file\gridlog.log' or
'C:\path\path\to\file\gridlog.log'
Linux/Unix/MacOS path example :
'/path/to/file/gridlog.log' | File to write out logs. Ensure the file path is compatible with the operating system’s file path. |
--log-level | string | “INFO” | Log level. Default logging level is INFO. Log levels are described here https://docs.oracle.com/javase/7/docs/api/java/util/logging/Level.html |
--plain-logs | boolean | true | Use plain log lines |
--structured-logs | boolean | false | Use structured logs |
--tracing | boolean | true | Enable trace collection |
--log-timestamp-format | string | HH:mm:ss.SSS | Allows the configure log timestamp format |
Network
Option | Type | Value/Example | Description |
---|
--relax-checks | boolean | false | Relax checks on origin header and content type of incoming requests, in contravention of strict W3C spec compliance. |
Node
Option | Type | Value/Example | Description | |
---|
--detect-drivers | boolean | true | Autodetect which drivers are available on the current system, and add them to the Node. | |
--driver-configuration | string[] | display-name="Firefox Nightly" max-sessions=2 webdriver-path="/usr/local/bin/geckodriver" stereotype='{"browserName": "firefox", "browserVersion": "86", "moz:firefoxOptions": {"binary":"/Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin"}}' | List of configured drivers a Node supports. It is recommended to provide this type of configuration through a toml config file to improve readability | |
--driver-factory | string[] | org.openqa.selenium.example.LynxDriverFactory '{"browserName": "lynx"}' | Mapping of fully qualified class name to a browser configuration that this matches against. | |
--driver-implementation | string[] | "firefox" | Drivers that should be checked. If specified, will skip autoconfiguration. | |
--node-implementation | string | "org.openqa.selenium.grid.node.local.LocalNodeFactory" | Full classname of non-default Node implementation. This is used to manage a session’s lifecycle. | |
--grid-url | string | https://grid.example.com | Public URL of the Grid as a whole (typically the address of the Hub or the Router) | |
--heartbeat-period | int | 60 | How often, in seconds, will the Node send heartbeat events to the Distributor to inform it that the Node is up. | |
--max-sessions | int | 8 | Maximum number of concurrent sessions. Default value is the number of available processors. | |
--override-max-sessions | boolean | false | The # of available processors is the recommended max sessions value (1 browser session per processor). Setting this flag to true allows the recommended max value to be overwritten. Session stability and reliability might suffer as the host could run out of resources. | |
--register-cycle | int | 10 | How often, in seconds, the Node will try to register itself for the first time to the Distributor. | |
--register-period | int | 120 | How long, in seconds, will the Node try to register to the Distributor for the first time. After this period is completed, the Node will not attempt to register again. | |
--session-timeout | int | 300 | Let X be the session-timeout in seconds. The Node will automatically kill a session that has not had any activity in the last X seconds. This will release the slot for other tests. | |
--vnc-env-var | string | START_XVFB | Environment variable to check in order to determine if a vnc stream is available or not. | |
--no-vnc-port | int | 7900 | If VNC is available, sets the port where the local noVNC stream can be obtained | |
--drain-after-session-count | int | 1 | Drain and shutdown the Node after X sessions have been executed. Useful for environments like Kubernetes. A value higher than zero enables this feature. | |
--hub | string | http://localhost:4444 | The address of the Hub in a Hub-and-Node configuration. Can be a hostname or IP address (hostname ), in which case the Hub will be assumed to be http://hostname:4444 , the --grid-url will be the same --publish-events will be tcp://hostname:4442 and --subscribe-events will be tcp://hostname:4443 . If hostname contains a port number, that will be used for --grid-url but the URIs for the event bus will remain the same. Any of these default values may be overridden but setting the correct flags. If the hostname has a protocol (such as https ) that will be used too. | |
--enable-cdp | boolean | true | Enable CDP proxying in Grid. A Grid admin can disable CDP if the network doesnot allow websockets. True by default. | |
Relay
Option | Type | Value/Example | Description |
---|
--service-url | string | http://localhost:4723 | URL for connecting to the service that supports WebDriver commands like an Appium server or a cloud service. |
--service-host | string | localhost | Host name where the service that supports WebDriver commands is running |
--service-port | int | 4723 | Port where the service that supports WebDriver commands is running |
--service-status-endpoint | string | /status | Optional, endpoint to query the WebDriver service status, an HTTP 200 response is expected |
--service-configuration | string[] | max-sessions=2 stereotype='{"browserName": "safari", "platformName": "iOS", "appium:platformVersion": "14.5"}}' | Configuration for the service where calls will be relayed to. It is recommended to provide this type of configuration through a toml config file to improve readability. |
Router
Option | Type | Value/Example | Description |
---|
--password | string | myStrongPassword | Password clients must use to connect to the server. Both this and the username need to be set in order to be used. |
--username | string | admin | User name clients must use to connect to the server. Both this and the password need to be set in order to be used. |
Server
Option | Type | Value/Example | Description |
---|
--allow-cors | boolean | true | Whether the Selenium server should allow web browser connections from any host |
--host | string | localhost | Server IP or hostname: usually determined automatically. |
--bind-host | boolean | true | Whether the server should bind to the host address/name, or only use it to" report its reachable url. Helpful in complex network topologies where the server cannot report itself with the current IP/hostname but rather an external IP or hostname (e.g. inside a Docker container) |
--https-certificate | path | /path/to/cert.pem | Server certificate for https. Get more detailed information by running “java -jar selenium-server.jar info security” |
--https-private-key | path | /path/to/key.pkcs8 | Private key for https. Get more detailed information by running “java -jar selenium-server.jar info security” |
--max-threads | int | 24 | Maximum number of listener threads. Default value is: (available processors) * 3. |
--port | int | 4444 | Port to listen on. There is no default as this parameter is used by different components, for example, Router/Hub/Standalone will use 4444 and Node will use 5555. |
SessionQueue
Option | Type | Value/Example | Description |
---|
--sessionqueue | uri | http://localhost:1237 | Address of the session queue server. |
-sessionqueue-host | string | localhost | Host on which the session queue server is listening. |
--sessionqueue-port | int | 1234 | Port on which the session queue server is listening. |
--session-request-timeout | int | 300 | Timeout in seconds. A new incoming session request is added to the queue. Requests sitting in the queue for longer than the configured time will timeout. |
--session-retry-interval | int | 5 | Retry interval in seconds. If all slots are busy, new session request will be retried after the given interval. |
Sessions
Option | Type | Value/Example | Description |
---|
--sessions | uri | http://localhost:1234 | Address of the session map server. |
--sessions-host | string | localhost | Host on which the session map server is listening. |
--sessions-port | int | 1234 | Port on which the session map server is listening. |
Configuration examples
All the options mentioned above can be used when starting the Grid components. They are a good
way of exploring the Grid options, and trying out values to find a suitable configuration.
We recommend the use of Toml files to configure a Grid.
Configuration files improve readability, and you can also check them in source control.
When needed, you can combine a Toml file configuration with CLI arguments.
Command-line flags
To pass config options as command-line flags, identify the valid options for the component
and follow the template below.
java -jar selenium-server-<version>.jar <component> --<option> value
Standalone, setting max sessions and main port
java -jar selenium-server-<version>.jar standalone --max-sessions 4 --port 4444
Hub, setting a new session request timeout, a main port, and disabling tracing
java -jar selenium-server-<version>.jar hub --session-request-timeout 500 --port 3333 --tracing false
Node, with 4 max sessions, with debug(fine) log, 7777 as port, and only with Firefox and Edge
java -jar selenium-server-<version>.jar node --max-sessions 4 --log-level "fine" --port 7777 --driver-implementation "firefox" --driver-implementation "edge"
Distributor, setting Session Map server url, Session Queue server url, and disabling bus
java -jar selenium-server-<version>.jar distributor --sessions http://localhost:5556 --sessionqueue http://localhost:5559 --bind-bus false
Setting custom capabilities for matching specific Nodes
Important: Custom capabilities need to be set in the configuration in all Nodes. They also
need to be included always in every session request.
Start the Hub
java -jar selenium-server-<version>.jar hub
Start the Node A with custom cap set to true
java -jar selenium-server-<version>.jar node --detect-drivers false --driver-configuration display-name="Chrome (custom capability true)" max-sessions=1 stereotype='{"browserName":"chrome","gsg:customcap":true}' --port 6161
Start the Node B with custom cap set to false
java -jar selenium-server-<version>.jar node --detect-drivers false --driver-configuration display-name="Chrome (custom capability true)" max-sessions=1 stereotype='{"browserName":"chrome","gsg:customcap":false}' --port 6262
Matching Node A
ChromeOptions options = new ChromeOptions();
options.setCapability("gsg:customcap", true);
WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444"), options);
driver.get("https://selenium.dev");
driver.quit();
Set the custom capability to false
in order to match the Node B.
4.3 - Toml配置选项
使用Toml文件的Grid配置示例.
CLI选项 中
显示的所有选项都可以通过
TOML 文件进行配置.
此页面显示不同Grid组件的配置示例.
请注意, 如果修改或添加了选项,
但尚未记录, 则此文档可能已过时.
如果您遇到这种情况,
请查看 “配置帮助” 部分,
并随时向我们发送更新此页面的请求.
概述
Selenium Grid对配置文件使用 TOML 格式.
配置文件由多个部分组成,
每个部分都有选项及其各自的值.
有关详细的使用指南,
请参阅TOML文档 .
如果出现解析错误,
请使用 TOML linter 验证配置.
一般配置结构具有以下模式:
[section1]
option1="value"
[section2]
option2=["value1","value2"]
option3=true
下面是一些使用Toml文件配置的
Grid组件示例,
该组件可以
从下面的方式开始:
java -jar selenium-server-<version>.jar <component> --config /path/to/file/<file-name>.toml
单机模式
单机服务器,
在端口4449上运行,
新会话请求超时500秒.
[server]
port = 4449
[sessionqueue]
session-request-timeout = 500
特定浏览器和最大会话数限制
默认情况下仅启用Firefox
和Chrome的单机服务器或节点.
[node]
drivers = ["chrome", "firefox"]
max-sessions = 3
配置和定制驱动程序
具有定制驱动程序的单机或节点服务器,
允许使用Firefox试用或者每日构建的功能,
并且有不同的浏览器版本.
[node]
detect-drivers = false
[[node.driver-configuration]]
max-sessions = 100
display-name = "Firefox Nightly"
stereotype = "{\"browserName\": \"firefox\", \"browserVersion\": \"93\", \"platformName\": \"MAC\", \"moz:firefoxOptions\": {\"binary\": \"/Applications/Firefox Nightly.app/Contents/MacOS/firefox-bin\"}}"
[[node.driver-configuration]]
display-name = "Chrome Beta"
stereotype = "{\"browserName\": \"chrome\", \"browserVersion\": \"94\", \"platformName\": \"MAC\", \"goog:chromeOptions\": {\"binary\": \"/Applications/Google Chrome Beta.app/Contents/MacOS/Google Chrome Beta\"}}"
[[node.driver-configuration]]
display-name = "Chrome Dev"
stereotype = "{\"browserName\": \"chrome\", \"browserVersion\": \"95\", \"platformName\": \"MAC\", \"goog:chromeOptions\": {\"binary\": \"/Applications/Google Chrome Dev.app/Contents/MacOS/Google Chrome Dev\"}}"
webdriver-executable = '/path/to/chromedriver/95/chromedriver'
带Docker的单机或节点
单机或节点服务器能够在Docker容器中运行每个新会话.
禁用驱动程序检测,
则最多有2个并发会话.
原型配置需要映射一个Docker映像,
Docker的守护进程需要通过http/tcp公开.
此外,可以通过 devices
属性定义在主机上可访问的哪些设备文件将在容器中可用。
有关 docker 设备映射如何工作的更多信息,请参阅 docker 文档。
[node]
detect-drivers = false
max-sessions = 2
[docker]
configs = [
"selenium/standalone-chrome:93.0", "{\"browserName\": \"chrome\", \"browserVersion\": \"91\"}",
"selenium/standalone-firefox:92.0", "{\"browserName\": \"firefox\", \"browserVersion\": \"92\"}"
]
#Optionally define all device files that should be mapped to docker containers
#devices = [
# "/dev/kvm:/dev/kvm"
#]
url = "http://localhost:2375"
video-image = "selenium/video:latest"
将命令中继到支持WebDriver的服务端点
连接到支持WebDriver外部服务
的Selenium Grid非常有用.
这种服务的一个例子可以是
云提供商或Appium服务器. 这样,
Grid可以实现对本地不存在的平台和版本的更多覆盖.
下面是一个将Appium服务器连接到Grid的示例.
[server]
port = 5555
[node]
detect-drivers = false
[relay]
# Default Appium server endpoint
url = "http://localhost:4723/wd/hub"
status-endpoint = "/status"
# Stereotypes supported by the service
configs = [
"1", "{\"browserName\": \"chrome\", \"platformName\": \"android\", \"appium:platformVersion\": \"11\"}"
]
启用基本身份验证
通过配置包含用户名和密码的
路由器/集线器/单机的方式,
可以使用这样的基本身份验证保护Grid.
加载Grid UI或者开始一个新的会话时
需要此用户/密码组合.
[router]
username = "admin"
password = "myStrongPassword"
下面是一个Java示例, 演示如何使用配置的用户和密码启动会话.
URL gridUrl = new URL("http://admin:myStrongPassword@localhost:4444");
RemoteWebDriver webDriver = new RemoteWebDriver(gridUrl, new ChromeOptions());
Setting custom capabilities for matching specific Nodes
Important: Custom capabilities need to be set in the configuration in all Nodes. They also
need to be included always in every session request.
[node]
detect-drivers = false
[[node.driver-configuration]]
display-name = "firefox"
stereotype = '{"browserName": "firefox", "platformName": "macOS", "browserVersion":"96", "networkname:applicationName":"node_1", "nodename:applicationName":"app_1" }'
max-sessions = 5
Here is a Java example showing how to match that Node
FirefoxOptions options = new FirefoxOptions();
options.setCapability("networkname:applicationName", "node_2");
options.setCapability("nodename:applicationName", "app_2");
options.setBrowserVersion("96");
options.setPlatformName("macOS");
WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444"), options);
driver.get("https://selenium.dev");
driver.quit();
5 - Grid架构
Page being translated from
English to Chinese. Do you speak Chinese? Help us to translate
it by sending us pull requests!
The Grid is designed as a set of components that all fulfill a role in
maintaining the Grid. It can seem quite complicated, but hopefully
this document can help clear up any confusion.
The Key Components
The main components of the Grid are:
- Event Bus
- Used for sending messages which may be received asynchronously
between the other components.
- Session Queue
- Maintains a list of incoming sessions which have yet to be
assigned to a Node by the Distributor.
- Distributor
- Responsible for maintaining a model of the available locations in
the Grid where a session may run (known as "slots") and taking any
incoming new
session requests and assigning them to a slot.
- Node
- Runs a WebDriver
session. Each session is assigned to a slot, and each node has
one or more slots.
- Session Map
- Maintains a mapping between the session
ID and the address of the Node the session is running on.
- Router
- Acts as the front-end of the Grid. This is the only part of the
Grid which _may_ be exposed to the wider Web (though we strongly
caution against it). This routes incoming requests to either the
New Session Queue or the Node on which the session is running.
While discussing the Grid, there are some other useful concepts to
keep in mind:
- A slot is the place where a session can run.
- Each slot has a stereotype. This is the minimal set of
capabilities that a new session session request must match
before the Distributor will send that request to the Node owning
the slot.
- The Grid Model is how the Distributor tracks the state of the
Grid. As the name suggests, this may sometimes fall out of sync
with reality (perhaps because the Distributor has only just
started). It is used in preference to querying each Node so that
the Distributor can quickly assign a slot to a New Session request.
Synchronous and Asynchronous Calls
There are two main communication mechanisms used within the Grid:
- Synchronous “REST-ish” JSON over HTTP requests.
- Asynchronous events sent to the Event Bus.
How do we pick which communication mechanism to use? After all, we
could model the entire Grid in an event-based way, and it would work
out just fine.
The answer is that if the action being performed is synchronous
(eg. most WebDriver calls), or if missing the response would be
problematic, the Grid uses a synchronous call. If, instead, we want to
broadcast information to anyone who’s interested, or if missing the
response doesn’t matter, then we prefer to use the event bus.
One interesting thing to note is that the async calls are more
decoupled from their listeners than the synchronous calls are.
Start Up Sequence and Dependencies Between Components
Although the Grid is designed to allow components to start up in any
order, conceptually the order in which components starts is:
- The Event Bus and Session Map start first. These have no other
dependencies, not even on each other, and so are safe to start in
parallel.
- The Session Queue starts next.
- It is now possible to start the Distributor. This will periodically
connect to the Session Queue and poll for jobs, though this polling
might be initiated either by an event (that a New Session has been
added to the queue) or at regular intervals.
- The Router(s) can be started. New Session requests will be directed
to the Session Queue, and the Distributor will attempt to find a
slot to run the session on.
- We are now able to start a Node. See below for details about how
the Node is registered with the Grid. Once registration is
complete, the Grid is ready to serve traffic.
You can picture the dependencies between components this way, where a
“✅” indicates that there is a synchronous dependency between the
components.
| Event Bus | Distributor | Node | Router | Session Map | Session Queue |
---|
Event Bus | X | | | | | |
Distributor | ✅ | X | ✅ | | | ✅ |
Node | ✅ | | X | | | |
Router | | | ✅ | X | ✅ | |
Session Map | | | | | X | |
Session Queue | ✅ | | | | | X |
Node Registration
The process of registering a new Node to the Grid is lightweight.
- When the Node starts, it should emit a “heart beat” event on a
regular basis. This heartbeat contains the node status.
- The Distributor listens for the heart beat events. When it sees
one, it attempts to
GET
the /status
endpoint of the Node. It
is from this information that the Grid is set up.
The Distributor will use the same /status
endpoint to check the Node
on a regular basis, but the Node should continue sending heart beat
events even after started so that a Distributor without a persistent
store of the Grid state can be restarted and will (eventually) be up
to date and correct.
The Node Status Object
The Node Status is a JSON blob with the following fields:
Name | Type | Description |
---|
availability | string | A string which is one of up , draining , or down . The important one is draining , which indicates that no new sessions should be sent to the Node, and once the last session on it closes, the Node will exit or restart. |
externalUrl | string | The URI that the other components in the Grid should connect to. |
lastSessionCreated | integer | The epoch timestamp of when the last session was created on this Node. The Distributor will attempt to send new sessions to the Node that has been idle longest if all other things are equal. |
maxSessionCount | integer | Although a session count can be inferred by counting the number of available slots, this integer value is used to determine the maximum number of sessions that should be running simultaneously on the Node before it is considered “full”. |
nodeId | string | A UUID used to identify this instance of the Node. |
osInfo | object | An object with arch , name , and version fields. This is used by the Grid UI and the GraphQL queries. |
slots | array | An array of Slot objects (described below) |
version | string | The version of the Node (for Selenium, this will match the Selenium version number) |
It is recommended to put values in all fields.
The Slot Object
The Slot object represents a single slot within a Node. A “slot” is
where a single session may be run. It is possible that a Node will
have more slots than it can run concurrently. For example, a node may
be able to run up 10 sessions, but they could be any combination of
Chrome, Edge, or Firefox; in this case, the Node would indicate a “max
session count” of 10, and then also say it has 10 slots for Chrome, 10
for Edge, and 10 for Firefox.
Name | Type | Description |
---|
id | string | UUID to refer to the slot |
lastStarted | string | When the slot last had a session started, in ISO-8601 format |
stereotype | object | The minimal set of capabilities this slot will match against. A minimal example is {"browserName": "firefox"} |
session | object | The Session object (see below) |
The Session Object
This represents a running session within a slot
Name | Type | Description |
---|
capabilities | object | The actual capabilities provided by the session. Will match the return value from the new session command |
startTime | string | The start time of the session in ISO-8601 format |
stereotype | object | The minimal set of capabilities this slot will match against. A minimal example is {"browserName": "firefox"} |
uri | string | The URI used by the Node to communicate with the session |
6 - 高级功能
要获得高级功能的所有详细信息, 了解其工作原理, 以及如何设置自己的功能, 请浏览以下部分.
6.1 - 可观测性
Page being translated from
English to Chinese. Do you speak Chinese? Help us to translate
it by sending us pull requests!
Table of Contents
Selenium Grid
Grid aids in scaling and distributing tests by executing tests on various browser and operating system combinations.
Observability
Observability has three pillars: traces, metrics and logs. Since Selenium Grid 4 is designed to be fully distributed, observability will make it easier to understand and debug the internals.
Distributed tracing
A single request or transaction spans multiple services and components. Tracing tracks the request lifecycle as each service executes the request. It is useful in debugging in an error scenario.
Some key terms used in tracing context are:
Trace
Tracing allows one to trace a request through multiple services, starting from its origin to its final destination. This request’s journey helps in debugging, monitoring the end-to-end flow, and identifying failures. A trace depicts the end-to-end request flow. Each trace has a unique id as its identifier.
Span
Each trace is made up of timed operations called spans. A span has a start and end time and it represents operations done by a service. The granularity of span depends on how it is instrumented. Each span has a unique identifier. All spans within a trace have the same trace id.
Span Attributes
Span attributes are key-value pairs which provide additional information about each span.
Events
Events are timed-stamped logs within a span. They provide additional context to the existing spans. Events also contain key-value pairs as event attributes.
Event logging
Logging is essential to debug an application. Logging is often done in a human-readable format. But for machines to search and analyze the logs, it has to have a well-defined format. Structured logging is a common practice of recording logs consistently in a fixed format. It commonly contains fields like:
- Timestamp
- Logging level
- Logger class
- Log message (This is further broken down into fields relevant to the operation where the log was recorded)
Logs and events are closely related. Events encapsulate all the possible information available to do a single unit of work. Logs are essentially subsets of an event. At the crux, both aid in debugging.
Refer following resources for detailed understanding:
- https://www.honeycomb.io/blog/how-are-structured-logs-different-from-events/
- https://charity.wtf/2019/02/05/logs-vs-structured-events/
Grid Observability
Selenium server is instrumented with tracing using OpenTelemetry. Every request to the server is traced from start to end. Each trace consists of a series of spans as a request is executed within the server.
Most spans in the Selenium server consist of two events:
- Normal event - records all information about a unit of work and marks successful completion of the work.
- Error event - records all information till the error occurs and then records the error information. Marks an exception event.
Running Selenium server
- Standalone
- Hub and Node
- Fully Distributed
- Docker
Visualizing Traces
All spans, events and their respective attributes are part of a trace. Tracing works while running the server in all of the above-mentioned modes.
By default, tracing is enabled in the Selenium server. Selenium server exports the traces via two exporters:
- Console - Logs all traces and their included spans at FINE level. By default, Selenium server prints logs at INFO level and above.
The log-level flag can be used to pass a logging level of choice while running the Selenium Grid jar/s.
java -jar selenium-server-4.0.0-<selenium-version>.jar standalone --log-level FINE
- Jaeger UI - OpenTelemetry provides the APIs and SDKs to instrument traces in the code. Whereas Jaeger is a tracing backend, that aids in collecting the tracing telemetry data and providing querying, filtering and visualizing features for the data.
Detailed instructions of visualizing traces using Jaeger UI can be obtained by running the command :
java -jar selenium-server-4.0.0-<selenium-version>.jar info tracing
A very good example and scripts to run the server and send traces to Jaeger
Leveraging event logs
Tracing has to be enabled for event logging as well, even if one does not wish to export traces to visualize them.
By default, tracing is enabled. No additional parameters need to be passed to see logs on the console.
All events within a span are logged at FINE level. Error events are logged at WARN level.
All event logs have the following fields :
Field | Field value | Description |
---|
Event time | eventId | Timestamp of the event record in epoch nanoseconds. |
Trace Id | tracedId | Each trace is uniquely identified by a trace id. |
Span Id | spanId | Each span within a trace is uniquely identified by a span id. |
Span Kind | spanKind | Span kind is a property of span indicating the type of span. It helps in understanding the nature of the unit of work done by the Span. |
Event name | eventName | This maps to the log message. |
Event attributes | eventAttributes | This forms the crux of the event logs, based on the operation executed, it has JSON formatted key-value pairs. This also includes a handler class attribute, to show the logger class. |
Sample log
FINE [LoggingOptions$1.lambda$export$1] - {
"traceId": "fc8aef1d44b3cc8bc09eb8e581c4a8eb",
"spanId": "b7d3b9865d3ddd45",
"spanKind": "INTERNAL",
"eventTime": 1597819675128886121,
"eventName": "Session request execution complete",
"attributes": {
"http.status_code": 200,
"http.handler_class": "org.openqa.selenium.grid.router.HandleSession",
"http.url": "\u002fsession\u002fdd35257f104bb43fdfb06242953f4c85",
"http.method": "DELETE",
"session.id": "dd35257f104bb43fdfb06242953f4c85"
}
}
In addition to the above fields, based on OpenTelemetry specification error logs consist of :
Field | Field value | Description |
---|
Exception type | exception.type | The class name of the exception. |
Exception message | exception.message | Reason for the exception. |
Exception stacktrace | exception.stacktrace | Prints the call stack at the point of time when the exception was thrown. Helps in understanding the origin of the exception. |
Sample error log
WARN [LoggingOptions$1.lambda$export$1] - {
"traceId": "7efa5ea57e02f89cdf8de586fe09f564",
"spanId": "914df6bc9a1f6e2b",
"spanKind": "INTERNAL",
"eventTime": 1597820253450580272,
"eventName": "exception",
"attributes": {
"exception.type": "org.openqa.selenium.ScriptTimeoutException",
"exception.message": "Unable to execute request: java.sql.SQLSyntaxErrorException: Table 'mysql.sessions_mappa' doesn't exist ..." (full message will be printed),
"exception.stacktrace": "org.openqa.selenium.ScriptTimeoutException: java.sql.SQLSyntaxErrorException: Table 'mysql.sessions_mappa' doesn't exist\nBuild info: version: '4.0.0-alpha-7', revision: 'Unknown'\nSystem info: host: 'XYZ-MacBook-Pro.local', ip: 'fe80:0:0:0:10d5:b63a:bdc6:1aff%en0', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.13.6', java.version: '11.0.7'\nDriver info: driver.version: unknown ...." (full stack will be printed),
"http.handler_class": "org.openqa.selenium.grid.distributor.remote.RemoteDistributor",
"http.url": "\u002fsession",
"http.method": "POST"
}
}
Note: Logs are pretty printed above for readability. Pretty printing for logs is turned off in Selenium server.
The steps above should set you up for seeing traces and logs.
References
- Understanding Tracing
- OpenTelemetry Tracing API Specification
- Selenium Wiki
- Structured logs vs events
- Jaeger framework
6.2 - GraphQL查询支持
GraphQL 是一种用于API的查询语言, 也是用于使用现有数据完成这些查询的运行时. 其仅仅是使用户能够准确地获取所需.
枚举
枚举是表示字段的可能值的集合.
例如, Node
对象具有一个称为status
的字段. 状态是一个枚举 (特别是Status
类型) , 因为它可能是UP
, DRAINING
或 UNAVAILABLE
.
标量
标量是基本类型的值: Int
, Float
, String
, Boolean
, 或 ID
.
在调用GraphQL API时, 必须指定嵌套子字段, 直到只返回标量.
模式的结构
网格模式的结构如下:
{
session(id: "<session-id>") : {
id,
capabilities,
startTime,
uri,
nodeId,
nodeUri,
sessionDurationMillis
slot : {
id,
stereotype,
lastStarted
}
}
grid: {
uri,
totalSlots,
nodeCount,
maxSession,
sessionCount,
version,
sessionQueueSize
}
sessionsInfo: {
sessionQueueRequests,
sessions: [
{
id,
capabilities,
startTime,
uri,
nodeId,
nodeUri,
sessionDurationMillis
slot : {
id,
stereotype,
lastStarted
}
}
]
}
nodesInfo: {
nodes : [
{
id,
uri,
status,
maxSession,
slotCount,
sessions: [
{
id,
capabilities,
startTime,
uri,
nodeId,
nodeUri,
sessionDurationMillis
slot : {
id,
stereotype,
lastStarted
}
}
],
sessionCount,
stereotypes,
version,
osInfo: {
arch,
name,
version
}
}
]
}
}
查询 GraphQL
查询GraphQL的最佳方法是使用curl
请求. GraphQL允许您仅获取所需的数据, 仅此而已.
下面给出了一些GraphQL查询的示例. 您可以根据需要构建自己的查询.
查询网格中 maxSession
和 sessionCount
的数量:
curl -X POST -H "Content-Type: application/json" --data '{"query": "{ grid { maxSession, sessionCount } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
通常在本地机器上 <LINK_TO_GRAPHQL_ENDPOINT>
会是 http://localhost:4444/graphql
查询全部会话、及节点以及网格的详情 :
curl -X POST -H "Content-Type: application/json" --data '{"query":"{ grid { uri, maxSession, sessionCount }, nodesInfo { nodes { id, uri, status, sessions { id, capabilities, startTime, uri, nodeId, nodeUri, sessionDurationMillis, slot { id, stereotype, lastStarted } }, slotCount, sessionCount }} }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
查询以获取当前网格的会话总数 :
curl -X POST -H "Content-Type: application/json" --data '{"query":"{ grid { sessionCount } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
查询以获取网格中的最大会话数量 :
curl -X POST -H "Content-Type: application/json" --data '{"query":"{ grid { maxSession } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
查询以获取网格中所有节点的全部会话详情 :
curl -X POST -H "Content-Type: application/json" --data '{"query":"{ sessionsInfo { sessions { id, capabilities, startTime, uri, nodeId, nodeId, sessionDurationMillis } } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
查询以获取网格中每个节点中所有会话的插槽信息 :
curl -X POST -H "Content-Type: application/json" --data '{"query":"{ sessionsInfo { sessions { id, slot { id, stereotype, lastStarted } } } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
查询以获取给定会话的会话信息查询以获取给定会话的会话信息 :
curl -X POST -H "Content-Type: application/json" --data '{"query":"{ session (id: \"<session-id>\") { id, capabilities, startTime, uri, nodeId, nodeUri, sessionDurationMillis, slot { id, stereotype, lastStarted } } } "}' -s <LINK_TO_GRAPHQL_ENDPOINT>
查询网格中每个节点的功能 :
curl -X POST -H "Content-Type: application/json" --data '{"query": "{ nodesInfo { nodes { stereotypes } } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
查询网格中每个节点的状态 :
curl -X POST -H "Content-Type: application/json" --data '{"query": "{ nodesInfo { nodes { status } } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
查询每个节点和网格的 URI :
curl -X POST -H "Content-Type: application/json" --data '{"query": "{ nodesInfo { nodes { uri } } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
Query for getting the current requests in the New Session Queue:
curl -X POST -H "Content-Type: application/json" --data '{"query":"{ sessionsInfo { sessionQueueRequests } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
Query for getting the New Session Queue size :
curl -X POST -H "Content-Type: application/json" --data '{"query":"{ grid { sessionQueueSize } }"}' -s <LINK_TO_GRAPHQL_ENDPOINT>
6.3 - Grid端点
Grid
Grid 状态
Grid状态提供Grid的当前状态.
它包含每个注册节点的详细信息.
对于每个节点,
状态包括有关节点可用性、会话和插槽的信息.
cURL GET 'http://localhost:4444/status'
在独立模式下, Grid URL是独立服务器的地址.
在集线器节点模式下, Grid URL是集线器服务器的地址.
在完全分布式模式下, Grid URL是路由服务器的地址.
以上所有模式的默认URL皆为http://localhost:4444.
分发器
删除节点
要从Grid中删除节点,
请使用下面列出的cURL命令.
它不会停止在该节点上运行的任何持续中的会话.
除非显式终止, 否则节点将继续按原样运行.
分发器不再知晓该节点,
因此任何匹配的新会话请求
也不会转发到该节点.
在独立模式下, 分发器URL是独立服务器的地址.
在集线器节点模式下, 分发器URL是集线器服务器的地址.
cURL --request DELETE 'http://localhost:4444/se/grid/distributor/node/<node-id>' --header 'X-REGISTRATION-SECRET: <secret> '
在完全分布式模式下, URL是分发器的地址.
cURL --request DELETE 'http://localhost:5553/se/grid/distributor/node/<node-id>' --header 'X-REGISTRATION-SECRET: <secret>'
如果在设置Grid时未配置注册密码,
则使用
cURL --request DELETE 'http://<Distributor-URL>/se/grid/distributor/node/<node-id>' --header 'X-REGISTRATION-SECRET;'
放空节点
节点放空命令用于优雅地关闭节点.
放空节点将在所有持续中的会话完成后停止节点.
但是, 它不接受任何新的会话请求.
在独立模式下, 分发器URL是独立服务器的地址.
在集线器节点模式下, 分发器URL是集线器服务器的地址.
cURL --request POST 'http://localhost:4444/se/grid/distributor/node/<node-id>/drain' --header 'X-REGISTRATION-SECRET: <secret> '
在完全分布式模式下, URL是分发服务器的地址.
cURL --request POST 'http://localhost:5553/se/grid/distributor/node/<node-id>/drain' --header 'X-REGISTRATION-SECRET: <secret>'
如果在设置Grid时未配置注册密码,
则使用
cURL --request POST 'http://<Distributor-URL>/se/grid/distributor/node/<node-id>/drain' --header 'X-REGISTRATION-SECRET;'
节点
本节中的端点适用于
集线器节点模式和
节点独立运行的完全分布式网格模式.
在一个节点的情况下, 默认节点的URL为 http://localhost:5555 .
如果有多个节点,
请使用 Grid 状态 获取所有节点详细信息
以及定位地址.
状态
节点状态本质上是节点的运行状况检查.
分发器定期ping节点状态,
并相应地更新Grid模型.
状态包括相关的可用性, 会话和插槽的信息.
cURL --request GET 'http://localhost:5555/status'
放空
分发器将 放空 命令传递给
由node-id标识的相应节点.
要直接放空节点,
请使用下面列出的cuRL命令.
两个端点都有效并产生相同的结果.
放空会等待持续中的会话完成后
才停止节点.
cURL --request POST 'http://localhost:5555/se/grid/node/drain' --header 'X-REGISTRATION-SECRET: <secret>'
如果在设置Grid时未配置注册密码,
则使用
cURL --request POST 'http://<node-URL>/se/grid/node/drain' --header 'X-REGISTRATION-SECRET;'
检查会话所有者
要检查会话是否属于某一节点, 请使用下面列出的cURL命令.
cURL --request GET 'http://localhost:5555/se/grid/node/owner/<session-id>' --header 'X-REGISTRATION-SECRET: <secret>'
如果在设置Grid时未配置注册密码,
则使用
cURL --request GET 'http://<node-URL>/se/grid/node/owner/<session-id>' --header 'X-REGISTRATION-SECRET;'
如果会话属于该节点,
则返回true,
否则返回false.
删除会话
删除会话将终止WebDriver会话,
退出驱动程序
并将其从活动会话集合中删除.
任何使用删除的会话id
或重用驱动程序实例的请求
都将抛出错误.
cURL --request DELETE 'http://localhost:5555/se/grid/node/session/<session-id>' --header 'X-REGISTRATION-SECRET: <secret>'
如果在设置Grid时未配置注册密码,
则使用
cURL --request DELETE 'http://<node-URL>/se/grid/node/session/<session-id>' --header 'X-REGISTRATION-SECRET;'
新会话队列
清除新会话队列
新会话请求队列保存新会话请求.
要清除队列,
请使用下面列出的cURL命令.
清除队列将拒绝队列中的所有请求.
对于每个这样的请求,
服务器都会向相应的客户端返回一个错误响应.
清除命令的返回结果是
已删除请求的总数.
在独立模式下, 队列URL是独立服务器的地址.
在集线器节点模式下, 队列URL是集线器服务器的地址.
cURL --request DELETE 'http://localhost:4444/se/grid/newsessionqueue/queue' --header 'X-REGISTRATION-SECRET: <secret>'
在完全分布式模式下,
队列URL是新会话队列服务器的地址.
cURL --request DELETE 'http://localhost:5559/se/grid/newsessionqueue/queue' --header 'X-REGISTRATION-SECRET: <secret>'
如果在设置Grid时未配置注册密码,
则使用
cURL --request DELETE 'http://<URL>/se/grid/newsessionqueue/queue' --header 'X-REGISTRATION-SECRET;'
获取新会话队列请求
New Session Request Queue holds the new session requests.
To get the current requests in the queue, use the cURL command enlisted below.
The response returns the total number of requests in the queue and the request payloads.
新会话请求队列保存新会话请求.
要获取队列中的当前请求,
请使用下面列出的cURL命令.
响应会返回队列中的请求总数以及请求内容.
在独立模式下, 队列URL是独立服务器的地址.
在集线器节点模式下, 队列URL是集线器服务器的地址.
cURL --request GET 'http://localhost:4444/se/grid/newsessionqueue/queue'
在完全分布式模式下,
队列URL是新会话队列服务器的地址.
cURL --request GET 'http://localhost:5559/se/grid/newsessionqueue/queue'