Перед выпуском в релиз любого сервиса обязательно идёт этап тестирования (иначе есть риск нарваться на баги после релиза и получить массу негатива от пользователей). Для тестов, как правило, нужно привлекать QA-команду, тратить время и ресурсы. Гораздо удобнее, если этот процесс можно автоматизировать.

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

Я Артём Згогурин, директор департамента тестирования ПО EdgeЦентр. И сегодня расскажу вам, как мы сделали свою автоматическую систему для тестирования видеозвонков.

Для чего нам понадобилась система тестирования видеозвонков

У EdgeЦентр есть свой сервис видеозвонков EdgeConf. Он постоянно дорабатывается, пополняется новыми функциями. И перед каждым релизом нужно проверять, действительно ли всё работает как надо.

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

У нас в компании есть собственный QA-центр: 80% наших ресурсов мы тратим на внешних заказчиков, и 20% — на внутренние задачи компании. И сначала мы привлекали наших сотрудников к тестированию EdgeConf. Но обновления у нас проходят часто. Чтобы не грузить команду задачами и автоматизировать процесс, мы решили сделать систему автоматического тестирования.

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

С чего всё начиналось

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

Кроме чата нужно было тестить ещё камеру и микрофон. И вторым шагом мы расширили функции ботов, добавили им возможность имитировать передачу звука и видео. Для этого у нас используются встроенные в chromium параметры — -use-file-for-fake-audio-capture и -use-file-for-fake-video-capture. С их помощью передаётся путь до видео- и аудиофайла, и браузер начинает зациклено эмулировать из этого сигнал с камеры или микрофна. Соответственно, работает это пока что только с браузерами на chromium. На остальных браузерных движках мы планируем реализовать функционал в ближайшее время.

Ботов мы делали на Python. Плюс использовали библиотеку Pytest (позволяет автоматизировать значительную часть процессов при создании автотестов).

Так как EdgeConf у нас работает в браузере, нам нужно было, чтобы боты могли производить действия в той же среде. И здесь мы использовали библиотеку Selenium WebDriver (позволяет взаимодействовать с браузером, имитируя действия реальных пользователей). С помощью этой библиотеки наши боты научились открывать EdgeConf, подключаться к звонку и делать скриншоты.

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

Итак, в основе наших ботов:

• Python

• Pytest

• Selenium WebDriver

И именно боты являются основой нашей системы автоматизированного тестирования. Чуть подробнее об особенностях работы ботов я расскажу ниже.

Но для решения всех наших задач этого было недостаточно. Ботов нельзя было запускать параллельно. Невозможно было управлять ими «на ходу» (например, велеть одному боту включить или выключить камеру в процессе тестирования). А для полноценного нагрузочного тестирования всё это было необходимо. И мы продолжили работать над системой.

Параллельное тестирование и управление ботами в реальном времени

Чтобы несколько ботов можно было запустить одновременно и посмотреть, как сервис справляется с нагрузкой, мы использовали Selenoid + Go Grid Router.

Selenoid — это инструмент, который и даёт возможность запускать несколько ботов параллельно. Каждый бот работает в отдельном Docker-контейнере изолированно от других. И все тесты могут проводиться одновременно, с использованием разных браузеров.

А Go Grid Router применяется для балансировки нагрузки. Это специальный хаб, который, условно, распределяет контейнеры с ботами по «железу».

А вот реализовать управление ботами «на лету» — прямо в процессе тестирования — было уже сложнее. На этот счёт у нас были разные идеи. Например, кто-то из разработчиков предлагал подключаться к видеозвонку вместе с ботами и посылать им команды прямо в чате EdgeConf. Но для этого пришлось бы делать ещё больше ботов, писать много кода. Мы сочли идею неудачной. После нескольких проб и ошибок мы нашли идеальный вариант — использовать Redis (СУБД с открытым исходным кодом).

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

Мы загружаем в Redis команды для ботов. А самих ботов немного доработали, чтобы они периодически проверяли СУБД. И если бот видит, что для него есть задание, он забирает его и удаляет из СУБД. Таким образом, у нас нет необходимости хранить большое количество данных, и при этом всё работает быстро.

В этой системе было только 1 ограничение — каждая команда рассчитана только на 1 бота. Сразу нескольким ботам задание дать было нельзя. Но и эту проблему мы тоже решили.

Создание интерфейса для управления системой

Для тестирования у нас уже были не только боты, но и система для их параллельного запуска и управления. Но хотелось большего — чтобы коллеги из команды EdgeConf могли сами проводить тесты без лишних сложностей. И для этого мы решили сделать пользовательский интерфейс.

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

Для разработки мы использовали фреймворк Django. Это позволило нам сильно ускорить процесс, так как в нём уже есть встроенный веб-сервер, механизмы авторизации, шаблоны интерфейсов — всё это нам не пришлось делать с нуля.

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

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

Для развёртывания всей системы нужно минимум 2 сервера (физических или виртуальных). Первый выступает в роли менеджера. На нём разворачивается веб-интерфейс, API, Go Grid Router (который распределяет нагрузку между воркерами) и Redis. А остальные серверы (один или несколько) играют роль воркеров. На них крутятся сами боты и Selenoid, с помощью которого задаётся их количество.

За счёт появления менеджера ботов нам удалось преодолеть ограничение Redis и отправлять одну команду сразу нескольким ботам. Менеджер реализован в виде API. Когда пользователь в интерфейсе указывает, сколько ботов должно быть с включёнными камерами и микрофонами, API формирует запрос и отправляет в Redis сразу несколько команд нескольким ботам. При этом всё это происходит в автоматическом режиме, и боты выбираются случайным образом. А ещё можно задать интервал между действиями: если юзер, например, не хочет, чтобы все боты включили камеру разом.

Если пользователю нужно, чтобы камеру включил какой-то конкретный бот, это тоже возможно сделать в интерфейсе.

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

Эмуляция троттлинга сети

Эмуляция троттлинга — это имитация снижения пропускной способности сети. В нашей системе она реализован в менеджере ботов. Но пока что не добавлена в веб-интерфейс, работает только через API.

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

Реализовали этот троттлинг с помощью средств ОС. Как я уже говорил, все боты у нас работают в контейнерах. И чтобы эмулировать троттлинг, мы берём контейнер и немного редактируем его. При создании Docker-файла мы копируем контейнер и устанавливаем в него разные нужные нам утилиты и библиотеки. Непосредственно для эмуляции троттлинга мы используем утилиту Net-tools и Throttle — специальный инструмент для симуляции более низкой пропускной способности сети, который позволяет резать скорость на уровне ОС.

При эмуляции из менеджера в воркер отправляется API-запрос, в котором указывается ID бота и профиль троттлинга. По умолчанию в качестве профиля задан 3G, т.е. скорость снижается до параметров 3G-сети. Всего доступно 6 профилей, и при желании скорость можно ограничить ещё сильнее.

Немного об особенностях работы ботов — набор тестов

Ну и напоследок расскажу немного об интересных особенностях работы ботов. Как я уже говорил выше, бот — это готовый скрипт, который выполняет определённые действия. В нашей системе к ботам прилагается ещё и набор тестов — это готовые скрипты для управления ботами.

Многие из этих скриптов предельно простые, отвечают исключительно за включение/выключение камеры или микрофона. Но если нужно, например, писать в чат — это уже более сложный набор действий, и скрипт, соответственно, получается более сложный. В таком скрипте задаётся количество ботов, количество сообщений, которые они отправляют, длина этих сообщений, временной промежуток между ними и т.д.

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

Для создания скриптов мы использовали специальный паттерн для автотестов — Page Object. Он позволяет инкапсулировать работу с отдельными элементами и уменьшить количество кода.

Код разбивается на модули, в которых описаны базовые операции на каждой из страниц тестируемого сервиса (страница подключения, страница комнаты и т.д.). Благодаря этим модулям мы не прописываем повторяющийся код для каждой конкретной страницы под каждое конкретное действие, а создаём классы. И потом при повторяющихся действиях просто на них ссылаемся.

Объясню на примере. Все наши боты умеют делать скриншоты. Когда мы запустили бота, то зачастую не знаем, на какой именно странице он находится: попал ли он уже в комнату видеозвонка или только подключается. Допустим, бот пытается подключиться к звонку, но у него возникает какая-то проблема. Перед тем, как отключиться, бот должен сделать скриншот, чтобы мы увидели, какая именно проблема у него возникла. И чтобы сделать этот скриншот, мы просто вызываем функцию, которая прописана у нас в одном модуле, и не плодим километры кода на каждую страницу. Если бы не было модулей и классов, нам бы пришлось писать скрипт со скриншотами на каждую отдельную страницу, и это бы увеличивало работу и количество кода в разы.

Как всё это помогает нам быстро адаптировать работу системы под заказчика? Мы используем локаторы — уникальные атрибуты элемента. Например, нам нужно, чтобы бот нажимал на кнопку «Включить камеру». У этой кнопки в ВКС есть свой локатор. И эту кнопку в процессе тестов боты будут нажимать очень часто.

Локатор этой кнопки, как и локаторы всех остальных элементов, мы вынесли в отдельный модуль. И, при адаптации системы, мы просто меняем локаторы на нужные — те, которые указаны у заказчика. Многие сервисы видеоконференцсвязи похожи между собой: у всех есть включение/выключение камеры, демонстрация экрана, чат. Элементы похожи, но их локаторы отличаются. Перед тем, как отдать систему заказчику, мы просто указываем его локатор в одном модуле и не меняем остальной код.

За счёт такой архитектуры мы очень сильно экономим время.

Что получилось в итоге

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

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

Также можно имитировать низкую пропускную способность сети с помощью эмуляции троттлинга. Это поможет понять, как сервис видеозвонков ведёт себя при плохом интернете у пользователей.

Как именно система справляется с нагрузкой, можно понять по скриншотам или посмотреть логи ботов.

Для запуска системы заказчику нужны виртуальные или физические серверы (минимум 2). Развернуть программу можно на своём оборудовании или арендовать мощности в нашем облаке.

Мы будем и дальше дорабатывать систему. Например, в ближайших планах у нас добавить масштабируемость — одновременно можно будет запускать до 1 000 ботов. Также планируем реализовать полноценную статистику по нагрузочному тестированию. На самом деле, предстоит ещё много работы. Но программой уже можно пользоваться для полноценного тестирования, не привлекая QA-инженеров.