Как Jenkins работает с вебдрайвером


(koshkavkleto4ku) #1

Привет, коллеги!
 

Объясните, пожалуйста, как Jenkins запускает тесты Selenium? В Jenkins создано задание, которые выполняет mvn test в командной строке. При запуске задания и прогоне тестов не поднимаются инстансы браузеров (в отличие от вызова непосредственно из командной строки или эклипса, например). Поэтому вопрос -- что вообще происходит? Где и как работает драйвер? (Тесты запускаются на машине с сервисом CI).

Связанный вопрос: в тестах делаю скриншоты. При запуске локалько на своей машине или на машине CI (где стоит Jenkins) при подключении по RDP все хорошо. При запуске через Jenkins удаленно или непосредственно на той машине для FF все хорошо, для IE получаются черные снимки. Сначала думала, что в IE так, потому что не поднимается браузер, нет картинки, но для лисы все оказалось хорошо. Chrome вообще не может запуститься из-за того, что не могут загрузиться какие-то начальные настройки (не через Jrnkins тоже все ок). Подскажите, в чем может быть дело? Особо интересует ситуация с IE!


(Sergey Korol) #2

В идеале, суть в том, чтобы подсунуть Jenkins билд файл, который скомпилирует и запустит ваши тесты при помощи, например, testng. Конечно и репозиторий ему нужно скормить, где ваши тесты лежат.

По поводу скринов частично тема обсуждалась тут.

По поводу удаленной работы читаем тут.


(koshkavkleto4ku) #3

Наверное, я недостаточно точно сформулировала (хотя старалась дать пояснение), меня интересует не как настроить запуск с моей стороны, а что делает Jenkins, когда запускает job. Тесты проходят как-то в бэкграунде и у меня есть подозрение, что черные экраные IE связаны именно с отсутствием картинки. Но почему-то для других браузеров все в порядке...

Видела частичное обсуждение проблемы по скринам по ссылке, но никакой информации не почерпнула. Тесты запускаются без грида на машине с Дженкинс..


(Maksym Barvinskyi) #4

Jenkins запущений користувачем SYSTEM, тому ніяких дій під реальним користувачем системи Ви не бачите. Насправді, навіть якщо Jenkins буде запущений від імені реального користувача системи, Ви теж, швидше за все, нічого не побачите, якщо він запущений як сервіс. Щоб Jenkins взаємодіяв із робочим столом (наприклад, якщо Ви використовуєте низькорівневі команди), створіть вузол Jenkins і прикрипіть його до тієї машини, де виконуються тести (це може бути та ж машина, може бути будь-яка інша із локальної мережі) за допомогою JNLP агента:

  1. Manage Jenkins -> Manage nodes -> New node -> оберіть Dumb Slave, в параметрах для "Launch method" вкажіть "Launch slave agents via Java Web Start".
  2. В конфігурації джобів, які мають виконуватись на цьому вузлі, відмітьте "Restrict where this project can be run" і вкажіть ім'я створеного вузла.
  3. На машині, де Ви хочете запустити вузол, зайдіть через браузер (бажано запустити браузер від адміністратора) на Jenkins, Manage Jenkins -> Manage nodes -> <Ім'я вашого вузла>, і натисніть велику помаранчеву кнопку Launch.

В результаті має скачатися .jnlp файл і система має вам запропонувати запустити його за допомого Java Web Start, якщо встановлений хоча б JRE (ну а куди ж без нього). Потім маєте побачити маленьке віконце з емблемою Jenkins і написом "Connected".


(koshkavkleto4ku) #5

Хоть мне и пришлось перевести кое-что из вашего комментария в гуглопереводчике, но это просто великолепно!

Спасибо большое!
 

Во-первых, стало все ясно с работой Jenkins, именно этого объяснения я и искала. Все встало на свои места!

Во-вторых, моя проблема с черными скриншотами решилась при запуске в графическом режиме через слэйва, который, кстати, является той же машиной, что и мастер.

Ты просто мой спаситель, предыдущие два дня чтения интернетов ни к чему особо не привели :)


(Galina.Bratchik) #6

Спасибо вам больше и от меня :)


(Sergey Korol) #7

Jenkins + Grid = No slaves configuration. Прежде чем использовать CI сервер, я бы в первую очередь задался вопросом - а зачем он мне?


(koshkavkleto4ku) #8

Насколько понимаю я Grid нужен для параллеленья тестов и прогона на разных платформах. Эти задачи (возможно, пока) не стоят, поэтому на данном этапе вообще не используется Grid.

А вот Jenkins используется для запуска теста "в один клик" на удаленной машине + дополнительные действия после тестов.

Если что-то в этом подходе в корне неверно и можно сделать правильнее/лучше, то расскажите, пожалуйста, как опытный товарищ. Для того и учимся.


(Sergey Korol) #9

А вот Jenkins используется для запуска теста "в один клик" на удаленной машине + дополнительные действия после тестов.

Схема работы грида: имеется центральный сервер - хаб, к которому подключены узлы - ноды. Работа осуществляется через хаб путем трансляции запросов узлам. Узлы могут быть запущены как на том же ПК, что и хаб, так и на других машинах. Запустить тесты удаленно в один клик можно и без дженкинса вовсе. И не обязательно их параллелить. Тип запуска тестов зависит строго от конфигурации в коде / нодах / xml. Именно поэтому я и написал риторический вопрос о целесообразности использования Jenkins'a.

Следующая концептуальная проблема заключается в запуске тестов на ПК с Jenkins. Представьте себе, что у вас есть 20 джобов для разных проектов. И вот 20 человек хотят одновременно их запустить. Далее, либо ваша машина "умрет" от количества запущенных браузеров, либо просто не хватит памяти даже для запуска. Это самый примитивный сценарий. Тесты должны запускаться на специально выделенном для этих целей незахламленном ничем окружении. Наиболее быстро и эффективно это достигается при помощи грида и набора виртуалок.

Поднимать слейвы дженкинса, используя селениум, - весьма сомнительная активность, ведь все, что нужно для удаленного запуска тестов, у вас под рукой и встроено в саму либу.

Следующий концептуальный момент касается использования ресурсов самого Jenkins'a. Если честно, тут можно разводить долгую полемику относительно того, какой профит от внедрения тулзы, процент использования которой не превышает 5-10... Использование CI должно быть обоснованным. По хорошему необходимо поднимать репозиторий, настраивать отчетность, параметризацию, скедьюлить выполнение тестов, продумывать зависимости и т.п. Это очень тонкий и кропотливый процесс. И поверьте, организацию всего этого процесса важно начинать еще с самой архитектуры вашего фреймворка. Ну настроите вы сейчас Jenkins. Завтра возникнет потребность в гриде и все придется переделывать / перенастраивать с нуля. Касательно роли архитектуры хорошая статья представлена тут.


(Elena Aizin) #10

Пришлось зарегистрироваться, что бы сказать вам спасибо :slight_smile:


(Sergey Korol) #11

Спасибо конечно, что всем сообщили, но некропостинг ради "спасибо" тут не приветствуется. Отметили сообщение, как понравившееся, - автор обязательно увидит и порадуется вместе с вами. :wink: В крайнем случае, можно делать это посредством личных сообщений.


(Ramon Menezes) #12

Добрый день,
случайно наткнулся на ваш коммент, это как раз то что я сделал у себя, интересует следующий вопрос:
при такой конфигурации можно ли запукать в одной джобе тесты на разных машинах (имею в виду 2+ одновременно, в разных потоках) ?


(Ramon Menezes) #13

нашел плагин для Дженкинса : Node Label Parameter plugin, по идее он позволит распаралелить тесты между вмками\слейвами, может кто подобное уже делал помогите плиз, пока в наличии только одна вм, так что готовлю только теор базу
PS. структура проекта : Testng + Selenide + Cucumber
PSS. подключение мастер слейв настроено через JNLP agent, не хочеться использовать стандартные возможности грида (не нравится он мне)