Функциональный мониторинг с Selenium в Nerrvana

Functional monitoring with Nerrvana

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

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

Кстати, это не единственное применение, которое такая особенность Nerrvana сделала возможной. Вы, например, можете проверять наличие билетов или отслеживать доставку вам товара, но об этом мы напишем в другой раз. О том же зачем мониторить ваше приложение в продакшн хорошо написал Михаил Левин на Хабре (с его разрешения мы даже перевели эту заметку на английский).

Таким образом, вы уже могли запускать мониторинговые тесты в Nerrvana. Но нам не давали покоя две проблемы. Первая – нам хотелось получать единственное письмо со всеми ошибками найденными тестами на разных платформах. Вторая – нам не хотелось менять код тестов и включать в него отправку почты. Тесты, не являющиеся мониторинговыми, запускаются у нас сейчас сразу после очередного коммита в репозиторий Jenkins-ом и при наличии ошибок письмо отправляется коммитеру.

Итак, всё очень просто. Вы тестируете своё приложение и в один прекрасный день обнаруживаете, что “лёгким движением руки” вы можете взять часть ваших тестов, проверяющих ключевой функционал вашего приложения, и передать его отделу поддержки и системным администраторам, что бы они могли запускать его по расписанию, получать нотификации по почте или парсить их в мониторинговой системе компании. В таком случае система мониторинга решит, что делать дальше – игнорировать, отправить по почте или разбудить СМСкой. В общем вы решили помочь тем сотрудникам вашей компании, которые отвечают за доступность и бесперебойность работы вашего сайта.

В интерфейсе Test Run Nerrvana, в разделе запуска по расписанию мы добавили дополнительное поле ввода для адреса почты.
 
 
Nerrvana functional monitoring email setup
 
 
Это может быть персональный адрес или адрес такого сервиса, как например, PagerDuty. Далее мы добавили возможность просмотра, модификации и отправки тестового письма, так как всё-таки рассчитываем на то, что если вы используете Selenium для тестирования и понимаете важность функционального мониторинга, то ваши алерты уж точно, если и не сейчас, то в скором времени, будут обрабатываться автоматически. Поэтому для удобства настройки парсинга получаемых уведомлений мы и сделали такую дополнительную тюнинговую фичу. Кроме того, для обеспечения доставки несомненно важных мониторинговых уведомлений, мы стали использовать SendGrid.

Вот так выглядит полученное тестовое письмо:
 
 
Nerrvana functional monitoring email example
 
 
Структура письма чётко определена и меняться не будет. Заметьте, что вначале письма находится специальная строка, содержащая количество ошибок в виде опять же удобном для парсинга. Всё, что желательно сделать при конвертации тестов в мониторинговые скрипты – убедиться, что ваша мониторинговая система, которая будет получать уведомления, сможет принимать решения о том, что нужно делать по информации, находящейся в уведомлении.

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

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

Если ваши тесты ловят только критичные ошибки – вы можете отправлять их себе смс-ками и просыпаясь ночью точно знать, что есть проблема, которую нужно срочно решать. Проблема однако в том, что реалии (сеть между мониторинговой системой и вашим сайтом, сам Selenium и браузеры, которыми он пользуется), не даёт вам такой гарантии и нужны перепроверки. Согласитесь, что реакция на такие перезапуски будет зависеть и от того, что именно проверяется и от последовательности ответов от этих перезапусков:
- поломалось, работает, работает, работает
- поломалось, работает, поломалось, работает
- поломалось, поломалось, поломалось, поломалось

Поэтому использование мониторинговой системы предпочтительнее, поскольку она позволяет не реагировать сразу, а агрегировать результаты и использовать например такую логику – если ошибка не критичная и она повторилась три запуска подряд – уведомить персонал. Например, Yandex построил собственную систему Terra как раз для того, чтобы на лету анализировать и принимать решения о результатах работы большого количества мониторинговых тестов, в том числе, с возможностью анализа повторных запусков на основе Apache Camel.

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

В результате получился такой список.

1. Регистрация

2. Вход в систему

3. Смена пароля

4. Попытка регистрации с уже зарегистрированным мылом

5. Запуск демо тестов, которые доступны при регистрации и проверка успешного их выполнения

6. Создание нового Space

7. Создание нового Test Run

8. Выход из системы

9. Удаление акаунта

Мониторинговые тесты всегда используют одну и ту же регистрационную запись, о которой знает Nerrvana (* каким образом показано ниже). Первым делом любой тест Nerrvana проверяет наличие этой регистрационной записи со специальным почтовым адресом. Если такая запись не существует – тесты выполняют регистрацию. Затем меняется пароль, чтобы не вычислять, какой он в данный момент. Если он существует, то используется специальная страница сброса пароля где уникальная ссылка на страницу сброса показывается прямо в браузере, но работает она только для этой (!) тестовой учётной записи.

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

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

1. Пытаемся зарегистрироваться

2. Если тестовый пользователь уже есть в системе, то:

  2.1 Идем на страницу сброса пароля Nerrvana и кликаем кнопку ‘Reset’

  2.2 Идем на вторую специальную страницу, которая показывает ссылку, которая в обычном случае будет отправлена на почту, и кликаем на ней. Меняем пароль на тот, которым оперируют тесты.

  2.3 Логинимся в систему и удаляем тестовый аккаунт с помощью имеющейся в Nerrvana на странице редактирования профайла опции.

3. Если тестового пользователя нет в системе, то регистрируемся и используем первую специальную страницу чтобы подсмотреть юзернейм, который в обычном случае будет отправлен на почту.

4. Тестируем нужный функционал.

Тесты запускаются каждые 2 часа, но, как вы сами понимаете, изменение расписания запуска дело пары минут.

Print this post | Home

Comments are closed.