Webdriver

Как и многим, нам в Veeam нужны разработчики автотестов. Обычно на эту позицию претендуют специалисты с опытом в ручном тестировании ПО, но зачастую у них может не быть навыков программирования. А программисты, как правило, нечасто стремятся в разработку автотестов. Между тем у нас в компании есть автоматизаторы, которые изначально были не тестировщиками, а программистами, и они очень хорошо себя проявили в автоматизации. В статье я расскажу почему такой вариант развития карьеры может быть интересен для разработчиков.

Лирическое отступление

Это только присказка, сказка впереди

В начале 2000-x я работал в IT-компании, которая выполняла несколько аутсорсинговых проектов для компании Integrated Genomics. Проекты были связаны с расшифровкой геномов простейших организмов. К примеру, одна из утилит искала фрагменты (праймеры) с определенными свойствами в геноме кишечной палочки. На входе утилиты была последовательность ДНК, загружаемая из публичной базы геномов ERGO и состоящая из азотистых оснований. На выходе таблица фрагментов и их позиция в цепочке ДНК. Далее эти фрагменты использовались биологами для синтеза геномов. Задача была сравнительно простой. Нужно было лишь позаботиться о том, чтобы программа не выжирала всю оперативную память довольно слабых машин, которые были у нас на тот момент. Сложность других проектов заключалась в том, что они находились на стыке трех дисциплин: биологии, математики и информатики. В тех случаях, когда алгоритм задачи был понятен, его реализация в программном коде не представляла трудности. Но когда сама задача была неопределенной, и не находилось никого кто мог бы ее формализовать, это был серьезный вызов.

Выяснилось, что для того, чтобы успешно решать такие задачи, нужны фундаментальные знания по биологии и высшей математике. Нас, молодых и горячих, это не остановило. Мы нашли англоязычную книгу по биоинформатике профессора Павла Певзнера и приступили к изучению. Поначалу повествование было легким и непринужденным. Во вступлении Павел рассказывал о том, как выживал в Москве в студенческие годы, и это было поистине приятное и расслабляющее чтение. Далее в первых главах речь шла про азотистые основания нуклеотидов ДНК аденин, гуанин, тимин и цитозин и про комплиментарность нуклеиновых кислот, а именно: как основания нуклеотидов способны формировать парные комплексы аденинтимин и гуанинцитозин при взаимодействии цепей нуклеиновых кислот. Было понятно, что такое свойство нуклеотидов играет ключевую роль в репликации ДНК. Я помню, что испытывал подъем и состояние потока, читая это объяснение, и мысленно представлял, как мы сейчас быстренько все это освоим (подумаешь, биология) и сможем брать более серьезные задачи. Мы даже думали о том, что сможем написать свой геномный ассемблер и взяться за расшифровку простейших геномов. Продолжаю читать книгу, и тут бах система уравнений на полстраницы без каких-либо объяснений. Из контекста подразумевалось, что эта система проще пареной репы, и любое объяснение будет оскорблением для читателя. Не было даже сноски для факультативного чтения. Я решил эту страницу пропустить, вернуться к ней позже и пока что продолжить читать дальше вдруг станет понятно. Перелистываю страницу а там еще одна система уравнений уже на всю страницу и скупое описание, часть слов из которого мы не нашли в словаре. Стало понятно, что эту область знаний на стыке геномики и математики нахрапом не возьмешь. Также стало понятно, почему подавляющее большинство коллег, с которыми мы взаимодействовали, имели биологическое и/или математическое образование. В конечном итоге, шаг за шагом погружаясь в основы геномики, нам удалось создать несколько программных продуктов, и тогда я в первый раз всерьез задумался о том насколько результативной и интересной может быть деятельность на стыке нескольких дисциплин.

С тех пор еще не раз мне довелось сменить сферу деятельности, и в каждом случае навыки разработчика служили трамплином для решения новых задач. Так произошло и с автоматизацией тестирования ПО.

Перспективы разработчика в автоматизации тестирования ПО

Перспективы разработчика в этой области трудно переоценить. Как и биоинформатика, разработка автотестов находится на стыке двух дисциплин, и навыки программиста здесь все чаще выступают на первый план.

Исторически сложилось так, что в автоматизацию приходят специалисты с опытом в ручном тестировании ПО. В какой-то момент они осознают, что рутинные операции можно и нужно автоматизировать, либо просто желают попробовать себя в новом качестве. Опыт, привносимый ручными тестировщиками в проект автоматизации, бывает архиполезным. Никто лучше них не знает возможности и слабые места продукта, наиболее трудоемкие сценарии для тестирования, окружение, в котором работает продукт, а также пожелания пользователей и планы на следующие релизы. Как правило, хороший ручной тестировщик четко понимает, что именно он хочет автоматизировать, но с написанием автотестов порой возникают сложности. Почему? Потому что автотесты это такой же программный продукт, как и продукт, который они призваны тестировать. Нужно продумать архитектуру системы автотестов, механизмы их запуска (Continuous Integration, CI) и самое главное нужно писать хороший код. По факту, для ручного тестировщика это зачастую оказывается непросто. Ведь здесь требуется создать полноценный проект, который можно интегрировать в CI, изменять, расширять и переиспользовать. Для этого нужны способности к программированию, накопленный опыт и набитые шишки.

Ручной тестировщик с глубоким пониманием продукта и методик тестирования и разработчик с опытом программирования отлично дополняют друг друга. Первый силен в постановке задачи (use case -> test case), второй в ее реализации. Встает вопрос: почему среди автоматизаторов встречается много ручных тестировщиков? На это есть несколько причин:

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

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

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

Опасение потерять в карьерном росте и зарплате.

Разберем эти моменты.

Автотесты это такой же продукт разработки, как и тот продукт, для которого эти автотесты создаются. Если разработчик идет на позицию автоматизатора в выделенную группу разработки автотестов, он остается на стезе написания программного кода. Да, ему надо иметь представление о тестировании ПО, но базовые знания можно сравнительно быстро получить, пролистав какое-либо руководство по тестированию ПО (например, вот эту книгу). Безусловно, автоматизатору нужно понимать продукт, для которого он пишет автотесты. Но освоить продукт на приемлемом уровне зачастую оказывается легче, чем научиться писать хороший код. Знания о продукте и методиках тестирования будут расширяться по мере ознакомления с багами, написанными на продукт, и общения с ручными тестировщиками. Разработчик не перестанет быть разработчиком, не превратится в ручного тестировщика. Это не его путь. Путь разработчика писать хорошие автотесты.

Задачи у автоматизатора интересные и зачастую сложные. В первую очередь стоит вспомнить про знаменитую пирамиду Фаулера. Модульные, интеграционные, end-to-end тесты подразумевают вдумчивый подход к структуре тестов и выбору инструментов в соответствии с функциональностью продуктов, для которых пишем автотесты. Если говорить о продуктах, разрабатываемых в Veeam, то автоматизатору понадобится работать с REST, WebDriver, Microsoft SQL Server, Amazon Web Services, Microsoft Azure, VMware vCenter, Hyper-V список не исчерпан. У каждого из облаков и гипервизоров свой API и свои скелеты в шкафу. Порой приходится писать код на различных языках программирования, использовать заглушки, семафоры, создавать свои обертки и т.п.

Одну и ту же задачу можно решить по-разному, и автоматизатор ищет наиболее эффективное решение. Вот лишь один из примеров сценарий, реализованный для продукта Veeam ONE. Один из компонентов продукта Business View, который позволяет группировать элементы виртуальной инфраструктуры по различным критериям. Критериев и вариантов их комбинирования очень много, поэтому проверка этой функциональности вручную занимает много времени. Написание автотестов в лоб с имитацией действий ручных тестировщиков было бы неэффективным: тесты для графического интерфейса десктопных приложений, как правило, сложны и трудоемки в разработке, являются хрупкими, их тяжело модифицировать, и выполняются они долго. Мы нашли другое решение: поскольку действия пользователя в UI интерполируются в SQL-запросы к базе данных, мы используем SQL-запросы для создания категорий и групп. Это позволило нам в разумные сроки покрыть автотестами все свойства и операторы, задействованные в Business View.

Как сделать так, чтобы тесты, запускаемые параллельно ради уменьшения общего времени запуска, не мешали друг другу? Как измерить покрытие продукта автотестами? Анализ покрытия кода? Анализ покрытия пользовательских сценариев? Как отслеживать падения сервисов? Как интегрировать автотесты с репортинговыми фреймворками? Как интегрировать автотесты со сборкой билдов в CI? Как прогонять тесты по pull-реквестам? И многое-многое другое.

Нужно обратить внимание на качество самих автотестов. Кто сторожит сторожей? Какому автотесту можно доверять? Автотест должен быть эффективным по критерию количество затраченных на него усилий / полученный результат, автономным, стабильным (нехрупким), быстрым, надежным (никаких false positive и false negative). В автотесте должен быть понятный, хороший код с точки зрения возможностей языка программирования, чтобы этот код можно было легко расширять и изменять.

Начинающий автоматизатор приступает к написанию простых тестов в соответствии с согласованными планами/подходами/инструментами. Решает самые простые задачи, учится справляться с трудностями, находить решения, обрастает знаниями и навыками. Задачи становятся все более серьезными, кредит доверия автоматизатору растет. Если автоматизатор не останавливается в своем росте, то спустя какое-то время он дорастает до разработки комплексных технических решений и более глубокого участия в обсуждении стратегии и приоритетов в разработке автотестов. В один прекрасный день он принимает под свое крыло начинающих автоматизаторов, которые хотят приносить пользу и расти.

Что в Veeam?

В компании Veeam мы будем рады новым боевым товарищам с опытом программирования на C# (например, web-интерфейсы, десктопные приложения, консольные утилиты и т.п.). У нас в Veeam есть много продуктов. Технологии в них могут различаться. В автотестах для нескольких продуктов мы опираемся на REST и WebDriver. Если у вас нет опыта с этими технологиями, но вы уверенно себя чувствуете в написании кода на C# и питаете интерес к автоматизации тестирования, то, возможно, мы также найдем точки соприкосновения.

Мы будем рады вашему резюме и паре абзацев о том, что вас привлекает в автоматизации, о ваших сильных сторонах и профессиональных планах. Пишите нам на ящик qa@veeam.com внимательно прочитаем. Если укажете в теме письма [Хабр] (например, [Хабр] Позиция автоматизатора), будет плюс в карму =)

Да пребудет с Вами Сила.

На Хабре уже не раз писали о том, что у Selenium Grid есть проблемы, которые не решить простым способом (например: раз, два, три). В этой статье мы поделимся нашим опытом и расскажем, как нам в Wrike удалось построить стабильную инфраструктуру для Selenium-тестов.

TLDR: Мы написали своё open source решение и полностью заменили им Selenium Grid.

Мы уже рассказывали о том, как масштабировали свою Selenium-ферму с помощью Google Cloud Engine и Kubernetes. От очередей на запуск тестов мы избавились, но из QA-департамента регулярно поступали жалобы на нестабильность тестовой инфраструктуры.

Выбор пути

У нас не получилось заставить работать Selenium Grid в GKE так, чтобы нас это устраивало. В GKE мы использовали короткоживущие Preemptible VMs. Запуски тестов создают непродолжительную, но интенсивную нагрузку, и именно для таких случаев хорошо подходят эти короткоживущие инстансы. Их использование позволяет снизить расходы на инфраструктуру в несколько раз. Но, так как они могут быть выключены в любой момент, это увеличивает нестабильность Selenium Grid, который и сам по себе достаточно нестабилен. Так мы пришли к выводу, что надо искать ему замену.

Больше всего нам понравился Selenoid от Aerokube, в том числе потому, что в нём не используются компоненты Selenium Grid (Selenium Hub и Selenium Node). Но, к сожалению, он не работает в Kubernetes, а это было критично для нас: мы широко используем его в других частях нашей инфраструктуры.

В качестве альтернатив, работающих в Kubernetes, мы рассматривали Zalеnium, jsonwire-grid и Moon. Zalenium и jsonwire-grid используют в своей архитектуре Selenium Node, а мы очень хотели этого избежать. К тому же Zalenium прекратили разрабатывать.

Moon выглядел неплохо, но это платное решение с закрытым исходным кодом. У него богатая функциональность: например, в конфигурации Moon можно указать список поддерживаемых браузеров, организовав единую точку входа для всех тестов (такой подход используют в Яндексе). Нам это не требовалось, так как мы делали по-другому перед запуском тестов запускали Selenium Grid, настроенный на запуск определенной версии браузера, и после окончания тестов удаляли его.

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

Нужен ли свой велосипед?

Кодовая база Selenium Grid огромна. Но хорошая новость заключается в том, что писать такое же большое и сложное решение не нужно. Много кода в Selenium относится к работе с устаревшими версиями браузеров, а все популярные современные браузеры совместимы со стандартом W3C Webdriver.

В комплекте с каждым браузером идёт сервер, который предоставляет HTTP API (совместимый со стандартом W3C Webdriver) для управления этим браузером (дальше в тексте этот сервер будем называть просто веб-драйвером). Например, для Google Chrome это ChromeDriver, для Mozilla Firefox geckodriver и т. д. Поэтому при написании своего решения не требуется делать полноценную реализацию стандарта W3C она уже реализована в веб-драйвере.

Нам не требовалась единая точка входа для всех тестов, которая бы поддерживала запуск разных браузеров. Таким образом, мы отказались от логики обработки capabilities и решили запускать только один браузер определенной версии, указанной в конфигурации.

С учетом этих условий остается только 2 основные задачи запуск/удаление браузеров и маршрутизация запросов до браузеров. Именно этим и занимается Callisto open source решение, которое мы разработали. Для запуска/удаления браузеров мы написали небольшое приложение, используя готовую библиотеку для работы с Kubernetes, а за маршрутизацию запросов отвечает Nginx. Получилось простое и надежное решение.

Архитектура Callisto

В архитектуре Callisto три основных компонента: Nginx, Callisto и podы с браузером и веб-драйвером.

Nginx делит все запросы на 2 группы:

1. Запросы на создание/удаление сессии отправляет в Callisto.

2. Все остальные запросы отправляет напрямую веб-драйверу.

Callisto при получении запроса на создание сессии:

1. Создает pod с браузером и веб-драйвером.

2. Перенаправляет запрос на создание сессии веб-драйверу и возвращает ответ.

При получении запроса на удаление сессии:

1. Возвращает успешный ответ.

2. Удаляет pod с браузером.

В качестве Docker-образов с браузерами используются образы от Selenoid.

Маршрутизация запросов до браузеров

Важным моментом является маршрутизация запросов от тестов к нужному podу с браузером. Нужно где-то хранить соответствие между session_id, которое вернул веб-драйвер, и конкретным podом. Первое, что приходит в голову это хранение информации на стороне Callisto. Мы немного изучили этот вопрос и смогли найти более простое и изящное решение, благодаря которому Callisto остался stateless-решением.

Как это работает: после того, как веб-драйвер создал сессию, Callisto модифицирует поле session_id в ответе веб-драйвера, добавляя имя и ip-адрес podа, и после этого возвращает ответ тестам. Соответствие session_id pod_ip хранится на стороне тестов.

Благодаря тому, что в стандарте W3C Webdriver session_id используется только в URL-ах, вторую часть обработки достаточно просто выполнить на стороне Nginx. Когда на Nginx приходит запрос, содержащий модифицированный session_id, он извлекает ip-адрес podа и оригинальный session_id и перенаправляет запрос этому podу с оригинальным значением session_id.

Примечание: имя podа Callisto использует при обработке запроса на удаление сессии.

Пример на картинке:

Дополнительные возможности Callisto

Web UI. В качестве Web UI используется Selenoid UI.

В Callisto поддерживается:

• Отображение текущего статуса Selenium-сессий.

• VNC.

• Отображение логов веб-драйвера в реальном времени.

Таким образом можно удобно отлаживать тесты.

Примечание: поддерживаются не все функции Selenoid UI. Например, не работает ручное создание сессий и просмотр видеозаписей.

Мониторинг. Callisto экспортирует метрики в формате Prometheus: можно удобным образом наблюдать за состоянием Selenium-фермы.

Чистое окружение под каждый тест

Callisto, как и Selenoid, запускает свежий браузер под каждый тест. Таким образом исключается влияние тестов друг на друга. Практика показала, что это очень важно для стабильности тестовой инфраструктуры.

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

Время создания podа с браузером сильно зависит от используемой инфраструктуры, но ориентироваться можно на ~10 секунд (может занимать до 2-х минут, если в Kubernetes-кластере включен автоскейлинг).

С какими проблемами мы столкнулись при разработке Callisto

Кодовая база Callisto небольшая меньше 2000 строк кода. Рассказ о решении был бы неполным без описания проблем, с которыми мы столкнулись при его разработке. На их решение мы потратили больше времени и сил, чем на саму разработку. Надеемся, что для кого-то из читателей эта информация окажется полезной.

499-е ошибки на Nginx. В логах Nginx периодически попадались 499-е ошибки. Они воспроизводились нестабильно: при максимальной нагрузке на Kubernetes-кластер (в середине рабочего дня) их было больше, а утром и вечером они практически не появлялись. При этом на стороне тестов ошибка проявлялась как Server disconnected error.

Nginx считал, что проблема на стороне клиента, а тесты считали, что проблема на стороне сервера.

В результате исследований мы выяснили, что причина в некорректном значении параметра worker-shutdown-timeout. Его увеличение с 10 секунд (значение по-умолчанию) до 120 секунд помогло решить проблему.

Примечание: в ingress-nginx версии 0.26.0 значение по-умолчанию для этого параметра было увеличено с 10 до 240 секунд.

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

Такое решение является более простым не требуется модифицировать session_id, имя сервиса можно использовать как доменное имя, при этом конфигурация Nginx выглядит очень просто.

При проведении нагрузочных тестов мы столкнулись с проблемой: создание сервисов начинает выполняться очень медленно при росте нагрузки на кластер (мы проверяли на GKE 1.12):

Так как мы хотели запускать 1000+ тестов параллельно в одном кластере, такое положение дел нас не устраивало. Мы пришли к решению с модификацией session_id, которое описано в разделе про маршрутизацию запросов до браузеров.

Примечание: время создания podов с ростом нагрузки на кластер увеличивалось совсем незначительно, поэтому отказ от сервисов решил проблему.

Медленные ответы от Kubernetes-API. При 100 параллельных тестах Kubernetes-API отвечал довольно быстро, но при дальнейшем увеличении нагрузки время ответа составляло уже единицы секунд, что заметно сказывалось на общей производительности. При профилировании мы обнаружили, что количество запросов от Callisto к Kubernetes-API росло экспоненциально с увеличением количества тестов. Мы быстро нашли ошибку в коде и исправили ее.

Медленное создание podов с браузерами. Нам удалось достичь приемлемого времени создания/удаления podов при одновременно бегущих ~500 тестах. Но нам требовалось обслуживать больше 1000 параллельных тестов.

Проблема решилась при обновлении GKE кластера с версии 1.12 до 1.14. В версии 1.14 время создания podов не превышало 10 секунд при более чем 2000 параллельно бегущих тестах.

504-е ошибки на Nginx. Некоторое количество тестов падало из-за того, что Nginx возвращал 504-ую ошибку. Проблема оказалась в том, что мы использовали Preemptible VMs. Когда Google забирал VM, все запросы к podам на этой VM падали по таймауту, что и приводило к данной ошибке.

В итоге мы настроили таймауты на стороне Nginx (чтобы такие запросы не висели долго) и добавили обработку этой ошибки на стороне тестов: при ее возникновении тест перезапускается.

Результаты внедрения Callisto

У нас получилось сделать простое и надежное решение, которое позволило значительно повысить стабильность нашей тестовой инфраструктуры.

Кроме увеличения стабильности, оказалось, что при примерно том же количестве запускаемых тестов платить за GKE мы стали на 30-40% меньше. Такая экономия достигается за счет того, что Callisto более эффективно использует ресурсы кластера, запуская podы только тогда, когда от тестов приходят запросы. При использовании Selenium Grid pod'ы с браузерами часть времени находятся в запущенном состоянии, ожидая нагрузку. Также каждому pod'у с браузером нужно меньше ресурсов, т.к. не используется Selenium Node.

Красной линией отмечен переход с Selenium Grid на Callisto:

Репозитории:

• Callisto

• Helm chart

Мы каждый день используем Callisto, и его текущая функциональность нас устраивает. В данный момент мы не развиваем его активно, но готовы принимать пул-реквесты.

Будем рады ответить на вопросы и комментарии про наше решение.