Всем привет! Меня зовут Андрей Петухов, я техлид команды Testing Experience AvitoTech, занимаюсь разработкой систем тестирования в Авито. В этой статье рассказываю, как мы организовывали у себя процесс тестирования в условиях микросервисной архитектуры. Ниже вы узнаете о том, как применять Testing as a Service (TaaS), зачем нужны шлюзы качества и как все это помогло тестировщикам сосредоточиться.
Как мы пришли к Testing as a Service
Изначально Авито был монолитом. Тогда тестирование было устроено так:
один репозиторий и один набор тестов;
каждое изменение проходит через юниты, интеграционные и e2e-тесты;
тесты ловят баги, иногда флакуют, ответственные ребята следят за этим на релизах и всё хорошо.
Бизнес рос, а людей становилось больше. Монолит стал замедлять разработку и доставку фичей, тогда мы стали переезжать на микросервисную архитектуру.
Юниты и интеграционные тесты уехали в микросервисы, а вот end2end-тесты, например, остались в монолите. Причём монолит релизился всё реже, а микросервисы росли по экспоненте, в месяц добавлялось по 200 штук. В итоге у нас пропала единая точка входа в общий процесс тестирования.
Мы стали замечать проблему ещё до того, как она стала критичной. И пришли к решению — Testing as a Service (TaaS).
Testing as a Service в Авито
В основе нашего Testing as a Service — концепция Quality Gates (шлюзы качества). Это механизм контроля качества ПО, который проверяет код на соответствие заранее установленным критериям на разных уровнях — гейтах. Проверки могут быть от кода до работоспособности критических сценариев без привязки к команде. Если код проходит все гейты – он считается приемлемым для дальнейшего использования или выпуска. Если нет — требуется доработка.
Гейты применимы к любой сущности в рамках пайплайна: монолит, микросервис, большой сервис — неважно.
Мы хотели сделать систему, которая реализовывала бы концепцию Quality Gates так, чтобы каждая команда могла тонко настраивать гейты под свои потребности. И у нас это получилось, сейчас расскажу, как именно.
У нас пять Quality Gates. На схеме ниже их четыре, потому что пятый происходит после релиза и сейчас нам не так интересен.
Quality Gate 1. Интро — происходит на машине разработчика или в CI.
Quality Gate 2. Юниты и интеграционные тесты.
Quality Gate 3. End-to-end-тесты сервиса.
Quality Gate 4. End-to-end-тесты Авито как продукта.
Вот основные требования, в которые мы целились:
сохранение автономности, которую даёт микросервисная архитектура. Команды вольны разрабатывать и релизиться по своим циклам;
разные сервисы — разные потребности. Поскольку сервисы различаются по критичности, не каждому нужен набор всех проверок: юниты, интеграционные тесты, локальные и глобальные end2end. Например, если это маленький сервис, который раскладывает бейджи в профиле, проверять его end2end-тестами не нужно;
тестирование — зона ответственности команды, владельющей конкретным сервисом или кусочком функциональности.
Что умеет TaaS в Авито
Ниже – список фичей, которые уже поддерживает Testing as a Service в Авито:
разные механики запуска тестов. Вручную, на PR, по расписанию;
сбор метрик. Время на тестирование, флакинесс для е2е-тестов, процент успешности сборки с тестами;
централизованное управление критичными аспектами. Процент покрытия, недостаточность тестирования и тому подобное. Например, при недостаточном покрытии тестами важного сервиса мы просто не дадим задеплоить.
Не будем вдаваться в детали технической реализации, потому что она у нас очень специфическая и может отличаться от того, что есть у вас.
Как работает TaaS в Авито
В TaaS есть три точки входа:
сервисный дашборд. Внутренний UI, куда может зайти разработчик или тестировщик и запустить тест, например;
пайплайны (на схеме ниже — Deploy);
Pull-Requests.
Основной принцип TaaS — единая ответственность. TaaS не знает, как его используют. Он не знает, из какой точки входа поступает запрос: сервис, CLI, пользователь — неважно. Всё, что у него есть, — запрос «дай набор тестов для этого таргета».
Для разных сценариев мы используем разные флоу внутри. Если мы поймём, что нам дополнительно нужен, например, синхронный способ взаимодействия, мы просто сможем его прикрутить, опираясь на текущий интерфейс.
Такая простота — залог гибкости. Например, у нас не было крон-запусков, а ребятам нужны были ночные сборки. Мы оперативно прикрутили эту механику практически бесплатно.
Как выглядит TaaS в Авито
Сервисный дашборд для владельца сервиса выглядит вот так:
Каждый гейт можно раскрыть и...
посмотреть отчёты тестов гейта;
запустить тесты гейта;
отредактировать гейт;
удалить гейт.
Компромиссы, на которые мы пошли
Нам пришлось пойти на некоторое количество компромиссов, чтобы запустить TaaS. Вот допущения, с которыми мы пока миримся.
поддерживаются только backend-сервисы. Гораздо больше времени требуется, чтобы затащить в общий пайплайн фронтенд и мобильные сервисы;
не для всех этапов целесообразно добавлять прослойку в виде гейта. Например, юнит-тесты необязательно тащить в общий пайплайн, поскольку они всегда лежат рядом с сервисом. Мы про них знаем и тянем информацию на дашборд, но не даём управлять этим процессом;
на коммунальных сервисах может скопиться много разных гейтов. Мы ещё не полностью ушли от сервисов, в которые контрибьютит куча народу. Каждая команда навешивает свой гейт, в каждом из которых может быть по 50 тестов. Когда запускаются все гейты — всё лагает.
Бенефиты от TaaS в Авито
Несмотря на компромиссы, у нас получилось разработать систему, которая пока что отвечает всем нашим требованиям с точки зрения масштабируемости и автономности.
самоуправление. Создание, настройка и управление этапами автоматизированного тестирования находятся в зоне ответственности оунеров сервиса;
автономность. Убрали боттлнек для «подкапотных» процессов. Например, для создания билдов в CI и их настройки. Раньше для этого нужно было ходить к специальным людям и неделю ждать билд TeamCity. Теперь же достаточно покликать пару кнопок в UI и заполнить несколько строчек;
децентрализация тестирования. Каждый сервис тестируется тогда, когда ему это нужно, — вне зависимости от внешних факторов. Единой точки входа в автоматизацию нет;
интуитивность настроек запуска. Тестировщику ничего не нужно для запуска теста: теперь не надо погружаться в настройки СІ/CD и скриптовать на bash для запуска тестов на агенте. Тестер пишет тесты, а остальное делает TaaS.
Метрики продукта
Бенефиты — бенефитами, но мы в Авито очень любим конкретные цифры. И они у нас есть! По метрикам видно, что продуктом пользуются и он приносит пользу инженерным командам Авито.
732 конфига с е2е-тестами для 308 сервисов. Еще больше сервисов, где только юнит-тесты;
2867 раз за апрель 2024 пользователи зашли на дашборд и сделали целевое действие;
в 4 раза выросло использование основных фичей с момента запуска до настоящего времени.
Зачем это вам?
Компании растут, в таких условиях условиях можно обнаружить себя в ситуации, когда процесс разработки уехал вперед и подстроился под рост, а процесс тестирования — нет. Актуализируйте процессы и инструменты под этот рост.
Упрощение работы тестеров = больше фокуса на качестве, а не на рутине. Тестер должен тестировать и находить баги, а не подрабатывать в качестве DevOps. Один из вариантов организовать это — Testing as a Service.
Спасибо вам за уделенное статье время! А как вы проводите тесты в микросервисной архитектуре? Какие инструменты используете и какие решения считаете лучшими? Расскажите о своем опыте в комментариях!
О том, как разгрузить QA-инженера от ежедневной рутины на примере отдельно взятой команды Авито, читайте по этой ссылке. Из текста вы узнаете про наш эксперимент по написанию 5000 тестов и сборку генератора для тестирования.
А еще подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.