Selenium grid. OK version
•Download as PPTX, PDF•
0 likes•919 views
How we manage selenium grid problems with microservices
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Selenium grid. OK version
Similar to Selenium grid. OK version (20)
More from Nikita Makarov
More from Nikita Makarov (9)
Selenium grid. OK version
- 1. Selenium Grid. OK Version
- 2. О себе • В IT c 2006 • В автоматизации тестирования с 2007 • Руковожу автоматизацией с 2009 @PapaMinos http://test-failed.blogspot.com 2
- 3. Selenium 3
- 4. Selenium Grid HUB NODE1 NODE 2 NODE 3 NODE N NODE 4
- 5. Что мы хотим от автотестов Надежность Скорость Удобство Трудные места Окружения
- 6. Скорость 6 15 минут Еще про графики
- 7. Как укладываться в 15 минут 7
- 8. Масштабирование Grid NODE1 NODE 2 HUB NODE1 NODE 2 NODE 3 NODE 4 HUB
- 9. Скриншоты Память Трафик Информативность
- 10. Обычные команды Selenium HUB NODE1 NODE 2 NODE 3 NODE N NODE 4 ± 1 Кб ± 1 Кб
- 11. Скриншоты HUB NODE1 NODE 2 NODE 3 NODE N NODE 4 300-700 Кб 1 Кб
- 13. Правда жизни
- 14. Как оно должно быть • Стоять внутри ноды • Хранить все внутри • Доступно снаружи • Просто в обращении 14
- 15. Микросервисы • Микро(!) - всего несколько функций • Простой протокол для работы извне • Простая и понятная цель • Сервис(!) - может быть недоступен 15 https://github.com/egorzamaraev/sample-jetty-service
- 18. Транскодирование
- 19. Скорость: Скриншоты • Быстрые (1,5-2х) и компактные (5-10х) • Скриншоты хранятся на всей ферме • Самоочистка по квоте • Нативный скриншот
- 20. +Агенты NODE1 NODE 3 NODE 5 NODE N HUB . . . NODE 2 NODE 4
- 22. Расширим агента 172.6.3.23:4947 /Screenshot /Killer
- 23. Решенные проблемы Node Agent /screenshot /killer /cache /distr /hosts
- 24. Как укладываться в 15 минут 24
- 25. Как выглядят тесты BEFORE (30%) TEST (40%) AFTER (30%) t t Теста
- 26. Как должны выглядеть тесты TEST1 TEST2 TEST3 t
- 27. Как бы это сделать…? Статические данные ? BEFORE TEST AFTER Делегирование
- 28. Окружения 28
- 29. Колхозить if-ами 29 if (env==PROD){ … } else if (env==TEST){ … } else if (env==STAGING){ … } else if (env==DEV) { … } else { … }
- 32. KEY Bot 1 Bot 2 Bot 3 Ботнеты
- 33. Ботнеты в природе 33
- 34. Ботнеты в природе 34
- 35. Взаимодействие API TEST mnemonic.getMessage("key").getForCurrent();
- 37. •Регистрировать ботов •Удалять ботов •Контролировать состояние ботов
- 38. Как это работает API TEST sk.getBot() sk.deleteBot(bot)
- 39. Storekeeper: Результаты • Ускорение тестов • Профит при увеличении числа ботов • Запас ботов • Локальный запуск • +1 сервис
- 40. Было NODE1 NODE 2 NODE 3 NODE 4 HUB
- 41. Стало NODE1 NODE 2 NODE 3 NODE 4 HUB
- 42. Правила для микросервисов • Простой • Без состояния (если возможно) • Здоровый и наблюдаемый • Отключаемый 42
- 43. Мысль measure performance before and after each attempted optimization. Joshua Bloch, Effective Java 43
- 44. Куда идти? • Selenium-Grid-Extras • Grible • Курсы от 10gen по mongodb (бесплатные) • Мартин Фаулер о микросервисах 44 Цель. Элияху Голдратт
- 45. Технологии http://www.eclipse.org/jetty/ DropWizard - http://dropwizard.codahale.com/ http://www.mongodb.org/ https://developers.google.com/speed/webp/ http://www.quartz-scheduler.org/
- 46. Спасибо! Никита Макаров Руководитель группы автоматизации тестирования, Одноклассники nikita.makarov@odnoklassniki.ru
- 47. И, да… есть такая работа – сидеть в «Одноклассниках» http://v.ok.ru 47
Editor's Notes
- Представится. Коллеги, давайте для разминки маленький соц опросик ?Мне это нужно чтобы понимать сколько где и чего рассказывать. кто в аудитории причастен к тестированию вообще ? К тестированиию вэба ? К автоматизации тестирования вэба ? кто занает/работает/сылшал про Selenium/WebDriver? Кто знает или пользовался Selenium Grid? Ок, спасибо.
- Selenium - это пожалуй уникальный инструмент. Судите сами - ему скоро будет 10 лет а он все еще живой, первая версия вышла в 2004. Он стандарт де-факто для автоматизации тестирования web, скоро даже станет де-юре - драфт спецификации в w3c уже давно обсуждается. Я бы даже сказал больше - он является монополистом, потому что ни один вендор инструментов автоматизции тестирования пока ничего лучше не смог предложить даже за деньги. Проект опенсорсный, у него активное сообщество и его поддерживают большие компании типа google, facebook, ebay, salesforce. Проект поддерживает все ведущие браузеры и промышленные языки программирования.
- Пара слов про Selenium Grid. Если у вас много браузерных тестов, то они выполняются долго. Разумная мысль - распараллелить их выполнение и управлять такой инфраструктурой. Собственно для этого был придуман Selenium Grid. Тесты у вас (как допустим у нас ) бегут на Дженкинсе, браузеры запущены на нодах, а взаимодействие одних с другими происходит через хаб. Браузеры нынче перестали стесняться жрать память, поэтому развернуть большую ферму может быть достаточно затратным занятием. Нет денег на свою такую вот ферму - можно арендовать в облаке, есть сервисы типа Sauce Labs, GridLastic, Browserstack. Давайте к делу.
- итак чего мы обычно хотим от автотестов вообще, и от автотестов на Selenium в частности. Мы хотим скорости - онии должны бегать максимально быстро, чтобы мы могли получать обратную связь как можно быстрее. Мы хотим чтобы они были надежными и падали только тогда когда должны падать, Мы хотим чтобы их было удобно писать, мы хотим запускать эти тесты на разных окружениях - и на тестоовом, и на боевом , и на девелоперском, и мы хотим, точнее нам приходится проверять трудные места - там где с тестируемостью решений плохо. Окей, давайте начнем со скорости так как вопрос наверное самый частый.
- У нас (я имею ввиду команду автоматизации тестирования в Одноклассниках) есть большая цель - полное автоматизированное тестирование всего нашего портала за 5 минут. Она пока недостижима, но мы стараемся к ней идти. И есть внешнее ограничение - 15 минут. Почему так ? Потому что у нас есть большая система бизнес-аналитики которая показывает нам графики с 5-минутным интервалом, и в принципе имея три точки на графике за 15 минут мы уже можем понимать куда идет тренд - отвалилось что-то или нет. То есть если автотесты бегают больше 15 минут - ценность их результатов падает. За эти 15 минут мы постоянно боремся. Все автотесты должны проходить за 15 минут.
- Как укладываться в 15 минут ? Ну первый вариант - иметь очень большую ферму, в идеале такую чтобы все тесты запускались сразу, каждый на своей машине и пробегали за время выполнения самого долгого теста из всех. Это дорого, но (!) например SalesForce так делает - они арендуют мощности у 4 облачных провайдеров, и запускают все тесты в параллельном режиме. Это экстенсивный путь развития. Второй подход - сделать очень быстрые тесты. Это интенсивный путь развития. Естественно мы используем оба - когда других средств ускорения тестов нет - мы увеличиваем размер фермы и вновь начинаем искать пути ускорения тестов, потому что их в любом случае станет больше. Ну и давайте начнем с экстенсивного.
- Если вы хотите нарастить мощность своего грида то вам достаточно добавить в него новых нод. Это реально работает. До определенного предела конечно. Сначала у нас было 2 ноды, потом 4, 10, 20, 40. Каждое увеличение размера грида вдвое пропорционально сокращало время выполнения тестов. Каждое увеличение происходит не бесплатно. Вы напрямую платите за то количество машин которое вы добавляется - памятью, процессорами, дисками. Диски сейчас дешевые, память тоже дешевеет. С процессорами - хуже всего. Отмасштабировать их не так просто, а сожрать - можно очень быстро. Есть и скрытые издержки - вам нужно будет еще «прокачивать» хаб и тот сервер на котором запускаются ваши тесты. Но есть и то что просчитать нельзя.
- Для нас таким сюрпризом при масштабировании были скриншоты, хотя дело не в них одних. Грид хорошо работает с тем для чего он предназначен - управление браузером. У Selenium есть функция создания скриншота, но она очень сильно отличается от основной природы его деятельности. мы любим делать скриншоты. Мы делаем их часто и их получается много, сейчас уже в районе 10000 на запуск автотестов и цифра продолжает расти.
- С точки зрения внутренностей Selenium-а скриншоты - это дорогостоящая операция. Получение скриншота очень сильно отличается от поиска кнопки или написания текста, потому что поиск элемента - это дешевая операция умешающаяся в пакет на пару килобайт, и выполняемая за 60-100 миллисекунд с полным проходом по гриду и обратно,
- Скриншоты отличаются и очень сильно. При запросе скриншота с сервера где выполняются тесты отправлятся такая жа команда весом килобайт и менее, а вот размер ответа уже отличается - это уже сотни килобайт, мегабайты. И все они проходят через хаб, который как вы можете является бутылочным горлышком. Если на пустом гриде операция получения скриншота занимала у нас 400-500 миллисекунд, то с ростом числа нод при масштабировании здесь стал происходить затык -снятие скриншота стало занимать секунду и более. Казалось бы что такое секунда для автотестов на селениуме - но эти вот секунды давали 2 минуты прироста. увидеть такую проблему можно только в масштабе. Но это только начало. После прохождения через хаб наши тысячи скриншотов попадали на jenkins который должен был бросать их на диски, что тоже отнимало время. Когда мы начали решать проблему со скриншотами их на один запуск автотестов уже было более 3 гигабайт. 3 гигабайта за раз - не сильно большая цифра, но - во первых она растет, а во вторых - ходить и регулярно чистить их не очень хочется.
- Селениум не может снять скриншоты пока у вас на странице есть alert. Как вы понимаетет не все сборки от девелоперов попадающие на тест одинаково хороши - такое не редкость.
- И еще - браузер внутри ноды - он все таки не является сферическим конем, а потому не находится в вакууме. Он стоит внутри ральной операционной системы в которой тоже происходят различные явления и процессы. Скриншоты от Selenium естественно ничего кроме viewport-а страницы вам не покажут. А там бывает - в windows больше, в linux меньше, но есть везде.
- Проблему нужно было решать, стали думать. Очевидно, что снимать скриншот нужно изнутри операционной системы, снимать весь десктоп - и браузер и все остальное. Второе что также очевидно - этот скриншот нужно не выпускать из этой ноды - зачем его куда-то таскать, где сделали - там пусть и лежит. К созданному скриншоту нужно иметь доступ извне чтобы его можно было посмотреть. Ну и у всего этого должен быть простой и понятный человеческий и машинный интерфейс для общения.
- Вспомнили про микросервисную архитектуру, которая очень хорошо вписывалась данную задачу. Функциональный интерфейс того, что нужно было сделать действительно был микроскопическим - сделать скриншот, получить скриншот. Он не должен быть чем-то сложным,разобраться в этом должно быть просто. И это все-таки сервис - то есть принципиально подразумевается, что в случае выхода его из строя мы должны уметь жить без него. Для того чтобы обеспечить связь с этим сервисом извне мы использовали сервер Jetty который позволяет встраивать себя внутрь другого приложения.
- Итак как оно все выглядит вместе. У нас есть наша нода - внутри есть селениум, браузеры, драйверы браузеров. Рядом с ними, по соседству на отдельном порту стартует наш jetty который дает нам возможность дергать наш сервис по HTTP извне. Jetty хорошо для экосистем замкнутых на джаву, но реализовать такую схему работы можно на всех промышленных языках программирования.
- Как оно все работает вместе. Сервер имеет пару простых RESTовых ручек - takeScreenshot для создания и getScreenshot для получения. Каждый раз когда тест дергает этот сервис за такую ручку сервис запускает утилиту которая снимает скриншот и сохраняет его в png файл с уникальным именем. Сервис тут же отдает клиенту ответ - имя файла скриншота, время затраченное на снятие и размер получившегося png файла. Метод получения скриншота просто отдает сам скриншота в http-ответе.
- Но это только половина. Вторая - гораздо интереснее. После того как клиенту отправлен ответ начинается асинхронный процесс перекодирования полученного скриншота из png в webp . webp - очень компактный формат хранения изображений от Google. Мы перекодируем изображение в webp , сохраняем его в файл с таким же именем и удаляем оригинальный png файл. Таким образом 350 килобайт превращаются в 66.При отдаче скриншота сервис может транскодировать его обратно в png а может отдавать напрямую в webp
- Во что это в итоге вылилось. Мы убрали затык на операциях снятия скриншотов, скриншоты стали сниматься быстрее, весить стали меньше и очень существенно. Скриншоты равномерно размазаны по всей ферме. Чтобы они не заполонили все диски мы добавили простейший механизм самоочистки - в случае исчерпания квоты места удаляются самые старые скриншоты - но обычно это скриншоты 3-4 месячной давности. Но есть и обратная стороная медали - это уже не голая нода с Selenium, на ней есть еще что -то и за этим тоже нужно следить.
- Это был лишь первый раунд тюнинга нашего грида чтобы он мог масштабируем. Мы добавили микросервис внутрь каждой ноды который помогал бы нам делать скриншоты. И это было только начало - раз уж мы поставили микросервис внутрь каждой ноды грида из этого нужно извлекать максимум пользы.
- Вторая довольно часто встречающаяся проблема - нестабильность работы браузера. Браузер завис, браузер не закрылся, браузер вышибло и после этого остались какие-то артефакты которые мешают его повторному запуску. Это место у селениума проработано слабо - вы не можете сделать ничего кроме отправки команды закрытия браузера, но отправлять ее в зависший браузер не очень эффективно.
- И мы решили немного расширить микросервис стоящий на ноде превратив его в агента. Он научился не только снимать скриншоты, но и прибивать браузеры. Реализация - очень простая, пользы много. После того как у нас появилась такая возможность мы внутри команды ввели правило которое гласит что «тесты бывают шустрые и мертвые» - если тест бежит дольше трех минут, то он будет беспощадно прибит киллером, а в отчете будет красивая кровавая надпись на эту тему.
- Таким образом наш микросервис приобрел совершенно другую роль - он стал помогать нам делать все то что сам селениум делает плохо или несправляется вовсе. Нужно пройти мимо балансировщика чтобы протестировать один вэб сервер с новой версией - ок, это не проблема, есть возможность поправить файл хостов. Сбросить кэш internet explorer-у, перезагрузить ноду, или еще что-то - да, это все можно сделать и сделать достаточно дешево. М
- Давайте теперь вернемся немножко назад - опять к нашим 15 минутам. Мы рассмотрели как что может случаться при маштабировании грида, когда вы пытаетесь поднять большую ферму для ускорения тестов. Это всего лишь самые экзотический и интересный пример - случается гораздо больше простых вещей. Большая ферма - это способ, но экстенсивный. Если вы начинаете массово писать тесты на вэб, то у вас может наступить момент когда темпы прироста числа тестов превысят ваши финансовые и технические возможности масштабировать ферму. Если этот день для вас наступит, то вы сядете и начнете думать над тем как ускорить тесты не увеличивая рамзер фермы. Мы тоже регуларно садимся и думаем на эту и смежные темы на наших ретроспективах.
- Вот так выглядит стандартный интеграционный тест чего угодно с webdriver-ом он или без . Кроме самого теста, в его полное время прохождения включена подготовка данных и зачистка (тоесть возвращение теста к точке контекста). Внимательно посмотрев, мы заметили, что Before и After иногда равны времени прохождения самого теста, а иногда и превосходят его. Это обусловлено отчасти спецификой проекта, иногда нужно подготовить долгие данные. Например: На фотографию можно поставить метку кого-то из друзей (отметить его). И есть например бизнес-правило, если пользователя блокируют, то он удаляется со всех фотографий. Чтобы проверить это, надо подготовить много данных, что-то можно сделать только через UI. На это тратится колоссальное количество времени. Потом еще это надо как-то зачистить. Разблокировать пользователя, удалить фотометки и.т.д.
- Очень хотелось бы видеть вот такую картину. Нет никаких подготовок, нет зачисток. Только тесты. Это могло бы дать сильное ускорение. Как можно это сделать?
- Если отвлечься от этого мира и просто по фантазировать, то в голову приходят сразу 2 идеи. Во-первых, почти всё или многое можно заменить на статические данные и тогда не придется их подготавливать. Если вам надо например попробовать к фотографии добавить описание, то не обязательно загружать фотографию, можно ведь просто хранить id или адрес этой фотографии, чтобы можно было к ней быстро перейти. Фантазируя дальше, приходит идея о том, что данные остаются динамическими, но их подготовка происходит асинхронно с тестом, кем то еще, а тест лишь просит нужные данные и отдает использованные. Мы решили попробовать обе эти концепции у себя. Начнем со статических данных.
- Давайте для начала поговорим про статические данные. Наверное у вас у всех в вашем проекте или продукте есть какое-то тестовое окружение, на котором вы тестируете и боевое. У нас они тоже есть, только у нас их не два, а четыре. Отличаются они друг от друга степенью изолированности от друг от друга. В процессе реализации фич код плавненько перетекает с дэва на тест, оттуда на стейджинг, ну а дальше раскатывается на продакшн.
- И раз окружения изолированы друг от друга то и статические данные придется готовить для каждого окружения. вот допустим у вас есть тест проверяющий возможность изменить описание у фотографии. Для этого не нужно каждый раз загружать фотографию - достаточно одной которую можно загрузить руками на каждое окружение. Вы залили фотографию на все 4 окружения и в тесте вам нужно хранить только id фотографии. Точнее 4 id-шника 4 фотографий. А еще вам придется написать кусочек кода в тесте который будет выбирать какую же фотографию ему использовать на данном окружении. Выглядеть оно будет приблизительно вот так, мы это между собой называем «поколхозить if-ами»
- Чтобы не допускать такого «колхоза» в коде мы разработали специальный микросервис который должен помнить о том какие даные использовать для какого окружения. Мы назвали его «мнемоник» в честь замечательного произведения Уильяма Гибсонаи не менее замечательного фильма.
- У этого сервиса есть два аспекта работы. Первый - он работает хранилищем ключ-значение для статических данных. Статические данные могут быть просто парой ключ-значение, а могут быть несколько сложнее - ключ и значения на все наши 4 окружения.
- Второй аспект работы мнемоника - ботнеты. У нас есть тестовые пользователи которыми мы выполняем какие-то действия. Эти пользователи иногда объединяются в графы определенной структуры или просто передруживаются с каким-то одним пользователем и вот такую вот конструкцию мы называем ботнетом. Для чего это нужно я вам попробую рассказать на примере.
- У вас есть следующий тестовый сценарий - пользователь создает группу, приглашает в нее троих людей, все они отказываются от вступления в группу, жалуются при этом на спам и создатель группы лишается возможности на три часа создавать группы. Окей, создали группу, отправили приглашения, нас наказал антиспам. Если мы повторно запустим тест на том же боте то он просто не отработает, потому что возможность создавать группы этому пользователю уже прикрыли. Поэтому мы подключаем к тесту ботнет из мнемоника.
- И на каждый запуск берем свежего бота из ботнета. Чтобы это делать нужно не только получать данные из мнемоника, но и обновлять их - обновляя состояние каждого использованного бота в ботнете, как минимум отмечая дату и время его последнего использования
- Работа с таким сервисом организована через HTTP API который завернуто в код отдельной библиотеки - этот сервис используется уже не только для selenium тестов. В тесте работа с мнемоником сводится в 1-2 строчкам кода. Такой сервис позволил нам тестировать сложный функицонал портала с помощью ботнетов и гибко управлять статическими данными, которые ускорили работу тестов.
- Вторая идея была в делегировании подготовки данных. Проанализировав некоторые из своих тестов мы увидели что для части из них нам требуются одноразовые боты. Почему боты одноразовые ? Потому что реально проще и быстрее создать бота с нуля, попользоваться и удалить его чем вычищать все артефакты которые у него останутся. Мы проанализировали сколько раз нам требуются такие боты и сколько у нас занимает процесс их регистрации в тестах. Оказалось что все это съедало нам полторы минуты времени, то есть в этом месте мы тратим 10% от дозволенного нам времени выполнения тестов только на это. Мы решили что тесты не должны заниматься , и ….
- Построили сторкипера. Сторкипер - это очень красивое название, когда появилась идея его создания мы все таки называли его «завскладом». Это сервис который управляет складом ботов, вовремя регистрирует новых, удаляет старых.
- Сторкипер состоит из двух частей. Первая общается с клиентом, то есть с тестами. Есть 2 запроса getBot(), который вернет в json свеженького бота, если такой имеется в пуле и deleteBot. Вы передаете id бота сторкиперу, и, если этот бот его, сторкипер его удалит. Вторая часть как раз отвечает за сам склад. Боты регистрируются и удаляются оп расписанию, автивируются и разблокируются. Все это делается таким образом чтобы это не было заметно на графиках и статистике
- Получили ускорение тестов, правда не такое, как хотелось. Но при использовании оказалось , что есть и другие плюсы от такого решения. Во-первых, чем больше ботов будет использоваться, тем больше будет выгода. Во-вторых, это некая кладовка с определенным запасом. Даже если что-то случится плохое с регистрацией или около нее, то тесты продолжат тестировать портал какое-то время. Один раз это случилось. И есть еще 1 плюс. Есть у нас несколько тестов, в которых регистрируются скажем, 2 пользователя, потом еще в админке им что-то добавляется из привелегий, и затем небольшой тест быстрый и эти польхователи удаляются. Вам надо поправить чтото внутри теста и вы начинаете дебажить.. Ждете полторы минуты и потом делаете изменение.. И так возмоэно не 1 раз. Это ужасно. Сторкипер делает это сразу. Не надо ждать. Появилась некая идея развития таких подготовок данных, не только регистрация, но что-то большее и более умное.
- Окей. давайт пот тизоньку я буду закругляться. Вот так выглядел наш грид когда мы начинали 2 с лишним года назад.
- Вот так он выглядит сейчас. Он оброс микросервисами, к прокачан агентаам на нодах, что позволяет нам выжимать из него максимум. Некоторые проблемы нам пока не удалось решить, но мы будем над этим работать.
- Несколько правил того как писать микросервисы которые мы вынесли из своего практического опыта. Микросервис должен быть решать маленькую понятную задачу.Максимально изолированную. У него не должно быть состояния если это конечно возможно - в случае со сторкипером нам не удалось сделать его без состояний, это обходится дороже. У него должны быть методы проверки того здоров ли он и возможность мониторить его. Тот кусок вашего кода который опирается на микросервис должен понимать и адекватно реагировать на отключение микросервиса. Тут должна быть альтернатива или просто возможность работать без микросервиса.
- Коллеги, я сегодня часто упоминал некие количественные показатели - милисекунды, килобайты и проценты. Это все неспроста - в основе всех наших телодвижений лежит возможность измерить то или иное действие количественно. Когда вы знаете что на самом деле съедает ваше время и ресурсы, тогда вы сможете что-то с этим сделать. Не важно каким способом вы будете это измерять, начните хоть как-нибудь - через лог файлы, через профилирование кода.не важно.
- А теперь я бы хотел вас всех послать. Идите на гитхаб, посмотрите проект Selenium-Grid-Extras который отчасти похож на нашего агента. Посмотрите на такой инструмент как Grible - он позволяет централизованно управлять тестовыми данными - и отчасти похож на наш мнемоник. Самым страждущим я бы посоветовал сходит на сайт компании делающей mongodb - там есть бесплатные и очень неплохие курсы на платформе дистанционного обучения edx. И вообще всем я бы порекомендовал сходить в свой любимый книжный магазин и купить книжку Элияху Голдрата «Цель».
- Это список технологий на которых мы это делаем, здесь все бесплатно. мы используем Java-стек, если вы живете в другой экосистеме то я думаю вы сможете найти аналоги.
- На этом у меня все, спасибо за внимание, буду рад ответить на ваши вопросы.