Библиотека сайта rus-linux.net
Проект Selenium WebDriver
Автор:Simon Stewart
Перевод: Н.Ромоданов
16.8. Selenium RC
Не всегда можно подключиться непосредственно к конкретному браузеру. В таких случаях, WebDriver возвращается к исходному механизму, используемому в Selenium. Это означает использование чистого Javascript-фреймворка Selenium Core, у которого есть ряд недостатков, т. к. он выполняется исключительно в контексте песочницы Javascript. В отличие от использования интерфейса WebDriver API это означает, что сразу сильно сокращается список поддерживаемых браузеров, причем интеграция с некоторыми из них очень хорошая и имеются исключительные возможности управления, а для других, управляемыми через Javascript, реализован точно такой же уровень управления, что и в исходном Selenium RC.
На рис.16.8 показывается, что концептуально используемая схема является сравнительно простой.
Рис.16.8: Общая схема архитектуры Selenium RC
Видно, что здесь есть три части: код клиента, промежуточный сервер и код Javascript-фреймворка Selenium Core, работающий в браузере. Со стороны клиента это только HTTP-клиент, который сериализует команды, посылаемые на серверную сторону. В отличие от дистанционно работающего WebDriver, здесь есть только одноточечный запрос, а выполняемое действие HTTP большой роли не играет. Это отчасти потому, что протокол Selenium RC создан на основе табличного интерфейса API, предоставляемого в Selenium Core, а это значит, что весь интерфейс API можно описать в адресе URL с помощью трех параметров запроса.
Когда клиент запускает новую сессию, сервер Selenium ищет в запросе «строку браузера» для того, чтобы выбрать лаунчер (программу запуска — прим.пер.), соответствующий браузеру. На лаунчер возложена обязанность сконфигурировать и запустить экземпляр запрашиваемого браузера. В случае с Firefox, это столь же просто, как раскрыть встроенный профиль с несколькими предварительно установленными расширениями (одно — для обработки команды выхода quit, а другое - для моделирования состояния готовности document.readyState, отсутствующее в старых релизах Firefox, которые мы до сих пор поддерживаем). Ключевая часть выполняемого конфигурирования представляет собой настройку сервера для его использования в качестве прокси для браузера, что означает, что через него проходят по крайней мере некоторые запросы (те, что для /selenium-server). Selenium RC может работать в одном из трех режимов: управление фреймом в единственном окне (режим одного окна singlewindow), управления AUT в отдельном втором окне (многооконный режим multiwindow) или внедрение в страницы через прокси-сервер (режим прокси-иньекции proxyinjection). В зависимости от того, какой режим работы выбран, через прокси могут проходить все запросы.
Когда браузер сконфигурирован, он запускается с первоначальным адресом URL, указывающим на страницу, размещенную на сервере Selenium - RemoteRunner.html. Эта страница отвечает за развертывание процесса загрузки всех файлов Javascript, необходимых для Selenium Core. После завершения загрузки вызывается функция runSeleniumTest, запускающая тестирование. Здесь объект Selenium используется для инициализации списка команд, которыми можно воспользоваться перед запуском основного цикла обработки команд.
Javascript, исполняемый в браузере, отправляет по URL запрос XMLHttpRequest ожидающему серверу (/selenium-server/driver), при этом предполагается, что сервер является прокси-сервером для всех запросов, тем самым позволяя проверять, что запрос, куда бы он не был направлен, является допустимым. Вместо того, чтобы делать запрос, первое, что делается, это отправляется ответ на ранее выполненную команду или OK в случае, если браузер был только что запущен. Затем сервер поддерживает запрос открытым до тех пор, пока от теста, выполняемого пользователем, не будет через клиентскую часть получена новая команда, которая затем посылается в качестве ответа для ожидающего Javascript. Этот механизм первоначально был назван «Response/Request» («ответ/запрос»), но теперь его было бы правильнее назвать «Comet with AJAX long polling» (Comet с пролонгированным AJAX-запросом).
Почему RC работает таким образом? Сервер нужно настроить как прокси-сервер для того, чтобы он мог перехватывать любые запросы, которые делаются, и не обращался к JavaScript, т. к. последнее нарушает политику «Single Host Origin», которая гласит, что с помощью Javascript можно запрашивать ресурсы только с того же сервера, откуда был получен скрипт. Это одна из мер безопасности, но, с точки зрения разработчика фреймворка автоматизации браузера, эта мера является проблемой и ее необходимо обходить.
Запрос XmlHttpRequest отправляется на сервер по следующим двум причинам. Первая, и самая главная, что пока сокеты WebSockets , как часть HTML5, не стали доступными в большинстве браузеров, нет способа из браузера гарантированно запустить процесс на сервере. Это значит, что сервер нужно оживлять как-нибудь иначе. Вторая причина в том, запрос XMLHttpRequest запускает функцию обратного вызова ответа асинхронно, а это означает, что пока мы ждем следующую команду, ничего другое не изменит обычное исполнение браузера. Двумя другими способами ожидания следующей команды мог бы быть регулярный опрос сервера с тем, чтобы посмотреть, нет ли на выпонение другой команды, из-за чего в пользовательских тестах возникали бы задержки, или можно было бы поместить команду Javascript в цикл с большой нагрузкой для того, чтобы он через край загрузил процессор и помешал бы в браузере выполнению другой команды Javascript (поскольку в контексте одного окна выполняется только один поток Javascript).
Внутри Selenium Core есть две основные части. Это главный объект selenium, который для всех имеющихся команд выступает в роли хоста и отображает интерфейс API, предлагаемый пользователям. Второй частью является бот browserbot. Он используется объектом selenium для абстрагирования от различий, имеющихся в каждом браузере, и представляет собой идеализированное представление об обычных функциональных возможностях браузера. Это означает, что функции в объекте selenium становятся более понятными и их легче поддерживать, а все особенности сосредоточены в browserbot.
Для того, чтобы можно было использовать атомы автоматизации Automation Atoms, компонента Core все изменяется все больше и больше. Обе части selenium и browserbot, вероятно, должны остаться, поскольку есть достаточно много кода, использующего интерфейс API, который они предоставляют, но предполагается, что, в конечном итоге, они станут оболочками классов, осуществляющих перенаправление к атомам настолько быстро, насколько это будет возможным.
Продолжение статьи - Оглядываясь назад и Заглядывая в будущее.