Вступление
Привет, хаброжитель! Уже довольно давно я хотел написать статью о том, как у нас в Badoo устроена автоматизация тестирования. Хотелось написать о чем-то интересном и, в то же время, полезном. Поделиться опытом, который можно было бы легко интегрировать почти в любую систему. И вот, такая тема назрела…
Как многие из вас знают, Badoo — это социальная сеть, ориентированная на поиск новых друзей и знакомств. Одной из важнейших задач является верификация пользователя. Ведь всем нам хочется, чтобы привлекательная девушка, с которой у нас назначена встреча, не оказалась дядей Колей из Твери.
Для верификации пользователей у нас существует много различных способов. Некоторые из них довольно привычные, такие, как верификация по номеру телефона. Есть и более необычный — верификация по фотографии. Но самая простая и быстрая — верификация через социальные сети.
Такой способ верификации профиля возможен сразу на момент его создания — регистрация через социальную сеть. Во-первых, это быстро, всего один клик и никаких дополнительных манипуляций с телефоном или веб-камерой. Во-вторых, это удобно, так как при желании можно импортировать фотографии и информацию о себе, вместо того, чтобы вводить их вручную.
Сегодня я расскажу о том, как на Badoo устроена регистрация и верификация через Facebook и о том, как мы научили selenium-тесты ее проверять.
Итак, представим, что вы — новый пользователь сервиса Badoo. Вы заходите на сайт и видите вот такую форму регистрации. Заполнять все эти поля или кликнуть по кнопочке регистрации через Facebook? Для меня это — никогда не вопрос. Я бы заполнил все поля вручную и не стал бы привязывать свой аккаунт. Почему? Потому что я немного параноик, надеюсь, это не заразно. :)
На самом деле Badoo никогда не разместит какую-либо информацию из стороннего источника без согласия пользователя, так что спокойно кликаем по темно-синей кнопке и регистрируемся на сайте. Один клик, 10-15 секунд, и у нас есть свой верифицированный профиль на Badoo. Ура!
Как бы поступил настоящий QA-инженер после того, как создал профиль на сервисе так просто и быстро? Правильно, попробовал бы создать еще один. Как отреагирует сервис, если на тот же FB-аккаунт попробовать зарегистрировать еще один профиль?
Снова открываем страничку регистрации и кликаем по иконке FB. Ничего неожиданного не произошло, Badoo “узнало” FB-аккаунт и вместо регистрации сразу авторизовало. Все в порядке.
Первый selenium-тест на регистрацию
Теперь представим, что вы — QA-инженер в компании Badoo. Перед вами стоит задача — автоматизировать флоу регистрации и авторизации через FB аккаунт. На первый взгляд задача простая, вот что вам понадобится:
- аккаунт FB;
- локатор кнопочки FB на странице регистрации;
- метод, который ждет авторизационную cookie (чтобы убедиться, что тест залогинился на сайте);
- локатор sign out кнопочки, чтобы разлогиниться;
- метод, который ждет, когда авторизационная cookie пропадет.
После того, как были написаны необходимые методы, составляем сценарий:
- Открыть стартовую страницу;
- Кликнуть иконку Facebook’а;
- В открывшейся вкладке авторизоваться на Facebook;
- Дождаться авторизации на Badoo;
- Получить id пользователя (пусть будет first_user_id);
- Разлогиниться;
- Открыть стартовую страницу;
- Кликнуть иконку Facebook’a;
- Дождаться авторизации на Badoo;
- Получить id пользователя (пусть будет second_user_id);
- Убедиться, что first_user_id и second_user_id совпадают.
Итак, сценарий готов, вы запустили тест и он прошел. Все прекрасно. Самое время вставить котика в статью:
Коммитим код теста в ветку, кидаем задачу на ревью и идем пить кофе. Однако, не успели вы дойти до кухни, как приходит уведомление — задача не прошла ревью, тест не работает. Что-то пошло не так…
После перезапуска теста становится ясно, что проблема в следующем — у данного FB-аккаунта уже существует профиль на Badoo. Вместо регистрации тест сразу авторизовался. Делать нечего, надо удалять профиль по завершению теста. Слава Богу, у нас есть потрясающая штука — QaApi!
Несколько лет назад я рассказывал, как она интегрирована с нашими автотестами. Доклад назывался «Selenium тесты. От RC и одного пользователя к WebDriver, Page Object и пулу пользователей», найти его можно тут — habrahabr.ru/company/badoo/blog/216255.
Если коротко, это внутренний api, на который из теста можно отправить запрос и совершить некоторые манипуляции на стороне приложения. Вызывается он довольно просто:
QaApiHelper::deleteUser(user_id);
Само собой, QaApi умеет работать только с тестовыми пользователями и доступен только через внутреннюю сеть.
Когда тест научился удалять пользователя за собой, он стал работать стабильно и прекрасно. Но так было не долго.
Этапы тестирования Badoo
О том, какие этапы тестирования существуют в нашей компании, мы рассказываем практически на каждой конференции. Здесь я перечислю коротко те, которые интересны с точки зрения selenium-тестов:
- Тестирование на девел-окружении. Девел — это копия продакшена со своими базами и внутренними сервисами.
- Тестирование на шоте. Шот — это продакшен-окружение, доступное из внутренней сети по определенному урлу и являющееся мержем кода мастера и тестируемой задачи.
- Тестирование на стейджинге. Стейджинг, традиционно — это результат мержа ветки релиза и мастера.
- Тестирование на продакшене.
Изначально мы гоняли тесты на девел-окружении и стейджинге. Однако, со временем, пришли в выводу, что тесты нужно уметь гонять и на шотах. Причина довольно простая — девел не всегда идеально копирует продакшен, а ловить баг на стейджинге и откатывать задачу из релиза — плохо. Это значит, что задача в этот релиз уже не попадет и уедет позже запланированного.
Второй selenium-тест на регистрацию
Вернемся к нашему тесту. Представим, что вы — все тот же QA-инженер, перед которым теперь стоит задача научить тест регистрации работать параллельно на нескольких шотах и стейджинге.
Напомню, что шоты работают в боевом окружении, то есть база пользователей у них одна. Вполне очевидно, что в текущей реализации запускать тесты параллельно не получится. Если запустить два этих теста с разницей в пару секунд на разных шотах, то второй попытается создать профиль на Badoo тогда, когда его уже создал первый, и неизбежно сломается:
Как решить нашу проблему? Как сделать так, чтобы у теста всегда был свежий пользователь FB?
Сначала я попытался решить проблему минимально просто. Создал mysql-табличку, в которую внес несколько созданных руками FB-пользователей и проставил им статусы — свободны. Тест брал пользователя из этой таблички, меняя ему статус на “занят”. Если свободного пользователя не было, тест падал с соответствующим сообщением.
У этой системы было несколько очевидных минусов. Прежде всего, если одновременно запускалось слишком много инстансов теста, аккаунтов не хватало и взять их было неоткуда. Также тест мог по какой-то причине не освободить пользователя в конце (например если он был остановлен нажатием “Ctrl+C”). Ничто из этого не радовало по утрам, когда до релиза оставалось меньше часа.
Довольно быстро устав от нестабильных падений и неконтролируемых состояний FB-аккаунтов, я начал искать решение получше…
The Graph API
У Facebook есть замечательный api, который позволяет создавать тестовых пользователей и манипулировать ими — developers.facebook.com/docs/graph-api. Организована она довольно просто: мы формируем необходимый запрос и посылаем его на сервер FB, ответ возвращается в формате json.
Пример запроса, который зарегистрирует тестового пользователя с именем Alex:
https://graph.facebook.com/{APP_ID}/accounts/test-users?name=Alex&access_token={APP_ID}|{SECRET}
Application id и secret мы получаем, регистрируя наше приложение на FB (подробнее тут — developers.facebook.com/docs/facebook-login/overview).
Настоящий пул Facebook пользователей
Что ж, давайте создавать пользователей! :)
Внимательно изучив graph-api и его особенности, мы составили список нюансов:
- Количество регистраций на одно приложение ограничено. Цитата: “Для каждого приложения можно создать не более 2000 тестовых пользователей.”.
Вывод: нужно вести учет созданных пользователей. - Только что созданный тестовый пользователь может взаимодействовать только с единственным приложением. В данном случае приложение — это домен, на котором разместился сервис. В Badoo стейджинг и шоты находятся на разных доменах.
Вывод: ведя учет пользователей, необходимо их разделять по app id. - Пользователь регистрируется довольно медленно. В среднем от 2 до 5 секунд.
Вывод: удобнее иметь заранее созданного пользователя FB, чтобы тест не тратил время на его создание. - Тест должен иметь дело с тем аккаунтом, который наверняка не используется в каком-то еще тесте, чтобы избежать флуктуационных race condition.
Данный пункт важен в рамках описываемого здесь теста.
Итого: было бы круто иметь кастомный пул пользователей FB, который соответствовал бы нашим “хотелкам”. По сути это должна быть табличка, которая будет содержать следующую информацию:
- Id пользователя;
- Email;
- Password;
- App id;
- App Secret;
- Состояние пользователя — занят тестом или нет;
- Timestamp создания пользователя.
В дополнение к этой табличке нам понадобилось несколько скриптов.
Первый ищет в нашем пуле пользователей, которые заняты более N минут и помечает их как свободных. Это сделано для того, чтобы пользователей можно было использовать не только в тесте (где можно прописать гарантированный анлок пользователя по завершении работы), но и для ручного тестирования.
Второй решает проблему долгого создания пользователя на стороне facebook. Выглядит это следующим образом:
Получение FB-пользователя мы обернули в специальный QaApi метод. Тест обращается к нему за свободным пользователем. Если такого нет, создается специальное задание. В рамках этого задания скрипт посылает curl-запрос к graph-api, дожидается ответа и записывает в табличку нового пользователя. Тест же получает ответ — “необходимо подождать”, закрывает коннект и делает еще одну попытку спустя несколько секунд. Таким образом мы решили две проблемы. Во-первых, логика работы с graph-api отделена от логики тестов. Во-вторых, тесты не держат долгие коннекты к сторонним сервисам, что существенно облегчает дебаг любых проблем, связанных с увеличением времени прохождения тестов.
Далее мы переписали необходимые тесты на новую систему получения FB аккаунтов и оставили тесты гоняться на ночь с нашем CI-сервером (мы используем Teamcity). К утру результат был готов. Создалось ровно столько пользователей, сколько было необходимо для использования в тестах.
У пула есть довольно удобный интерфейс методов. Он позволяет в любой момент времени получать соотношение свободных пользователей к общему на каждое приложение, получать количество созданных пользователей по дате. Это помогает контролировать равновесие пула при добавлении нового теста, использующего FB-аккаунты.
А есть ли такой удобный API у других социальных сетей?
Я интересовался у ребят из ВКонтакте:
И у ребят из Одноклассников:
Итог
На данный момент пул является неотъемлемой частью нашей системы. Вокруг него появились новые скрипты и новые методы. Благодаря гибкости и простоте систему удобно развивать и контролировать.
Немного о том, что получилось в итоге:
- Удобный инструмент для ручного и автоматизированного взаимодействия Badoo с Facebook;
- Более 20 уникальных тестов, использующих пул facebook-аккаунтов: регистрация/авторизация, верификация, загрузка фотографий с FB-аккаунта, поиск друзей на Badoo, шаринг наград и так далее;
- В пуле 9 различных приложений, использующих в общей сложности примерно 1.5к активных пользователей;
- QaApi-методы умеют создавать FB-аккаунты, делать их друзьями, заливать им фотографию, ассоциировать FB-аккаунты с нашими тестовыми пользователями;
- Система сама поддерживает необходимое количество FB-аккаунтов и чаще всего не требует никакого ручного вмешательства.
За более чем год использования api работал стабильно. Всего раз возникла проблема с токенами пользователей, но разработчики facebook пофиксили ее довольно быстро. Кому интересно подробнее — developers.facebook.com/bugs/1662068220677444.
В завершение хотелось бы поблагодарить наших ребят из разработки за их неоценимую помощь в создании всей этой системы. Вы — молодцы!
Спасибо за внимание!
Виталий Котов, QA-инженер по автоматизации.
