Это история про то, что тестировать внутреннюю платформу для запуска и разработки приложений сложно, но если подойти к вопросу творчески, то можно и попробовать. Своим успешным опытом выполнения этой непростой задачи поделится QA-инженер Лариса Седнина. Начнем с того, что разберемся, что такое PaaS.
PaaS (Platform as a Service) — внутренняя платформа для запуска и разработки приложений. Если коротко, то наш PaaS позволяет легко и, можно сказать, при нулевом знании внутренней кухни создать свой сервис и начать пилить продуктовые компоненты. Более длинное объяснение — в этом видео. Под катом небольшой рассказ о том, с какими проблемами пришлось столкнуться при первом приближении к тестированию продукта, как происходил сам процесс тестирования платформенных решений на примерах и какую пользу это принесло.
Меня зовут Лариса Седнина, я работаю QA-инженером в Авито в юните QA Center of Excellence. Наш юнит — это центр экспертизы по обеспечению качества, основная задача которого в распространении лучших практик тестирования, помощи в настройке процесса тестирования и разработке инструментов для тестирования.
И однажды пришла задача — прийти в платформенную команду и выявить потребность в необходимости тестирования решений, которые выпускает команда (сервисы/библиотеки/процесс). Расскажу три кейса по тестированию наших PaaS сервисов, это были очень интересные задачи и порой вызов, чтобы придумать как их протестировать.
Что из себя представляет PaaS в цифрах?
- Более 1000 пользователей сервиса (внутренние разработчики компании);
- Более 1400 микросервисов;
- Сотни деплоев в день;
- 70 тысяч RPS к бэкенду.
PaaS помогает снижать оверхэд на интеграцию с инфраструктурой, переиспользовать лучшие практики по всей компании, дает возможность централизованно контролировать технологии и решения, максимально автоматизировав все рутинные шаги. Например, когда приходит новый разработчик или собирается новая команда, им не надо думать, сколько ресурсов и памяти выделить для сервиса, на каких кластерах хоститься, какие фреймворки и методологии использовать.
Но сразу встает вопрос — как тестировать всю эту кухню, которая к тому же живет в нескольких дата центрах, и зачем? Давайте попробуем разобраться.
Для начала стоит сказать, что такое PaaS для пользователей — это командная утилита Avito CLI и дашборд PaaS, который помимо многих возможностей из cli также дает визуализацию по всем сервисам.
Avito CLI
Несколько примеров её работы:
- avito service canary deploy — когда мы деплоим сервис на часть трафика в заданное окружение;
- avito start — запуск локального окружения в миникубе для разработки сервиса;
- avito lint — проверка на линтеры, в данном случае для Golang.
PaaS дашборд:
А теперь рассмотрим что можно протестировать в PaaS на примерах.
Navigator
Посовещавшись с техлидом команды, первым подопытным решили взять opensource разработку Navigator. Это мультикластерная реализация паттерна Service mesh, в основе которого лежит envoy, с поддержкой канареечных релизов. Например, есть несколько кластеров Kubernetes, в которых крутится какое-то количество микросервисов. Этим сервисам не нужно знать в каком кластере и по какому адресу находится сервис, к которому он обращается. Навигатор позволяет им общаться как будто это один большой кластер.
В первую очередь было решено сделать тестовую модель библиотеки и посмотреть покрытие тестами, чтобы в принципе понять насколько покрыт тестами этот критически важный для нас сервис. Так как у нас есть инструмент для выгрузки тестов из кода — unit, интеграционные и e2e тесты были размечены в коде и выгружены в тестовую модель автоматически. Это помогло проанализировать покрытие тестами функционала и из итогов анализа поставить задачи на недостающие автотесты:
Дальше мы положили задачи в бэклог и подумали, а достаточно ли этого? Оказалось — нет, потому что спустя какое-то время на проде случился баг в алгоритме балансировки. В навигаторе есть логика понижения весов для балансировки трафика, и при вычислении веса в некоторых случаях переполнялся int, на envoy приходил битый конфиг, из-за этого мы не могли нормально роутить, и клиенту отдавалась ошибка.
Ну что ж, баг исправлен, шишка набита, выводы сделаны. Теперь попробуем в другом примере пойти со стороны задачи: внедрить какой-либо компонент в продакшен. Этой задачей стала страница кронов/воркеров.
27-28 июня в Москве впервые пройдет TestDriven Conf 2022 — профессиональная конференция для senior тестировщиков и QA-инженеров. Она будет посвящена всем вопросам автоматизации в тестировании и рядом. Расписание и тезисы докладов уже на сайте. И можно забронировать билеты по выгодной цене — чем ближе к конференции, тем будет дороже.
