Селениум - это не только инструмент, но и стандарт, который описывает единый унифицированный интерфейс драйвера, который позволяет управлять браузером.
Именно такой унифицированный единый интерфейс как раз и описан в стандарте W3C WebDriver.
С технической точки зрения - это сетевой протокол. Почему взаимодействие происходит по сети?
Потому что это самый простой способ, чтобы интерфейс был языковонезависимый. Есть универсальный сетевой протокол и для конкретного ЯП достаточно всего лишь написать несложную библиотеку, которая представляет собой клиент для этого сетевого протокола.
Т.е. она предоставляет набор классов или методов. При вызове этих методов формируется и отправляется запрос по протоколу W3C WebDriver, соответствующий вспомогательный исполняемый файл (chromedriver, geckodriver, IEDriverServer), он этот запрос принимает, преобразует в какое-то внутреннее представление (Remote Debug, Marionette, COM API). Это внутреннее представление понимает браузер. Взаимодействие между вспомогательным и исполняемым файлом и браузером происходит по некоторому внутреннему протоколу, стандарт это никак не описывает.
Каждый разработчик браузера имеет право сделать свой собственный протокол взаимодействия, открывать его или он может быть закрытым (проприетарным). Главное - чтобы существовал вспомогательный исполняемый файл (chromedriver, geckodriver, IEDriverServer), который умеет принимать команды по стандартному протоколу W3C WebDriver. Тогда любая клиентская библиотека, написанная на любом языке, которая умеет отправлять команды в соотвтствии с этим стандартом, будет работать с любым стандартным драйвером и соответственно можно будет управлять любым браузером.
Стандарт описывает именно протокол.
Когда мы как юзеры пишем сценарии с использованием инструмента Селениум, мы напрямую с этим протоколом не работаем. Мы берем библиотеку, например, Java, которая содержит какие-то методы и функции и вызываем эти функции. Набор функций и классов стандарт не описывает. Для некоторых ЯП существует несколько разных реализаций, которые представляют разные интерфейсы и у юзера есть выбор, та библиотека, которая больше нравится, та, которая предоставляет более удобный программный интерфейс, ту и можно использовать.
Главное, чтобы эта библиотека внутри поддерживала стандартный протокол W3C WebDriver.
Стандарт описывает:
https://www.w3.org/TR/webdriver/
Набор команд:
https://www.w3.org/TR/webdriver/#list-of-endpoints - каждая из этих команд в протоколе имеет свой уникальный адрес. Здесь перечислены адреса и для каждого адреса указана, какакя команда ему соответствует. В правой колонке - названия команд.
Алгоритмы:
Здесь выделены 3 самых важных и сложных.
https://www.w3.org/TR/webdriver/#element-displayedness - определение, является ли элемент видимым. Взаимодействовать с невидимыми элементами нельзя, т.к. реальный юзер тоже не может этого делать.
https://www.w3.org/TR/webdriver/#element-interactability - если элемент прозрачный.
Именно такой унифицированный единый интерфейс как раз и описан в стандарте W3C WebDriver.
С технической точки зрения - это сетевой протокол. Почему взаимодействие происходит по сети?
Потому что это самый простой способ, чтобы интерфейс был языковонезависимый. Есть универсальный сетевой протокол и для конкретного ЯП достаточно всего лишь написать несложную библиотеку, которая представляет собой клиент для этого сетевого протокола.
Т.е. она предоставляет набор классов или методов. При вызове этих методов формируется и отправляется запрос по протоколу W3C WebDriver, соответствующий вспомогательный исполняемый файл (chromedriver, geckodriver, IEDriverServer), он этот запрос принимает, преобразует в какое-то внутреннее представление (Remote Debug, Marionette, COM API). Это внутреннее представление понимает браузер. Взаимодействие между вспомогательным и исполняемым файлом и браузером происходит по некоторому внутреннему протоколу, стандарт это никак не описывает.
Каждый разработчик браузера имеет право сделать свой собственный протокол взаимодействия, открывать его или он может быть закрытым (проприетарным). Главное - чтобы существовал вспомогательный исполняемый файл (chromedriver, geckodriver, IEDriverServer), который умеет принимать команды по стандартному протоколу W3C WebDriver. Тогда любая клиентская библиотека, написанная на любом языке, которая умеет отправлять команды в соотвтствии с этим стандартом, будет работать с любым стандартным драйвером и соответственно можно будет управлять любым браузером.
Стандарт описывает именно протокол.
Когда мы как юзеры пишем сценарии с использованием инструмента Селениум, мы напрямую с этим протоколом не работаем. Мы берем библиотеку, например, Java, которая содержит какие-то методы и функции и вызываем эти функции. Набор функций и классов стандарт не описывает. Для некоторых ЯП существует несколько разных реализаций, которые представляют разные интерфейсы и у юзера есть выбор, та библиотека, которая больше нравится, та, которая предоставляет более удобный программный интерфейс, ту и можно использовать.
Главное, чтобы эта библиотека внутри поддерживала стандартный протокол W3C WebDriver.
Стандарт описывает:
https://www.w3.org/TR/webdriver/
Набор команд:
https://www.w3.org/TR/webdriver/#list-of-endpoints - каждая из этих команд в протоколе имеет свой уникальный адрес. Здесь перечислены адреса и для каждого адреса указана, какакя команда ему соответствует. В правой колонке - названия команд.
Алгоритмы:
Здесь выделены 3 самых важных и сложных.
https://www.w3.org/TR/webdriver/#element-displayedness - определение, является ли элемент видимым. Взаимодействовать с невидимыми элементами нельзя, т.к. реальный юзер тоже не может этого делать.
https://www.w3.org/TR/webdriver/#element-interactability - если элемент прозрачный.
https://www.w3.org/TR/webdriver/#get-element-text - определение текста документа.
Сетевой протокол.
БОльшая часть посвящена ему. Это важно для разрабов библиотек.
Механизм расширения протокола.
Например, для тестирования мобильных или декстопных приложений.
Сетевой протокол.
БОльшая часть посвящена ему. Это важно для разрабов библиотек.
Механизм расширения протокола.
Например, для тестирования мобильных или декстопных приложений.
Комментариев нет:
Отправить комментарий