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

Меня зовут Павел Балахонов, я старший инженер по автоматизированному тестированию. В этой статье расскажу, как мы упростили и автоматизировали функциональное тестирование в Private Cloud от VK — платформе для построения частного облака в крупных компаниях и госорганизациях, какие решения использовали и что из того, что есть у нас в активе, открыто для общего использования.

Почему именно функциональное тестирование

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

Поэтому в нашей команде приоритетным стало именно функциональное API-тестирование. API-тесты быстрее, чем UI, меньше привязаны к структуре и изменениям в DOM страницы. А еще они позволяют проверить работу функциональности с параметрами, которые невозможно передать с фронтенда из-за специфики интерфейса. Скажем, когда вы создали базу данных в Trove, но не знаете наверняка, реализуется ли бэкап, не «ломаются» ли таблицы после него. 

В общем, API-тестирование — ключ к уверенности, что продукт жизнеспособен и работает в облаке. Поэтому первым объектом автоматизации стало именно оно. 

Выбор стека

На этапе выбора стека было три возможных варианта действий:

1. Взять классический стек: Pytest (test runner + assertions), Allure (report system) и Requests (http client).
   
2. Адаптировать фреймворки, которые использовали для тестирования в публичном облаке.
   
3. Взять готовый инструмент для написания функциональных API-тестов. 
   

Первый вариант отмели сразу по нескольким причинам.

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

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

Сложная интеграция с IAAS- и PAAS-компонентами облака, для которой нужно было бы добавлять огромное количество REST-клиентов.

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

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

В результате остановились на третьем варианте: взять готовый инструмент и адаптировать его под свои задачи. Таким инструментом стал Tempest.

Tempest: почему взяли, как адаптировали и что получилось

Почему решили остановиться на Tempest:

• Openstack. Фреймворк относится к категории открытого ПО;
  
• простая интеграция в конвейеры. Tempest написан на Python, как и большинство компонентов частного облака. Это упрощает адаптацию существующих и разработку новых тестов для разработчиков, которые пишут новые сервисы на этом языке;
  
• интеграция с IaaS серьезно упрощает адаптацию под наше облако;
  
• механизм чистки есть из «коробки». 
  

Как адаптировали Tempest

Первым делом пришлось настроить взаимодействие. Tempest «из коробки» заводит пользователей и проекты в Keystone, получает оттуда токен-авторизацию, подписывает все запросы и по умолчанию считает, что этого достаточно для взаимодействия с IaaS- и PaaS-компонентами. Нам этого было мало, поэтому сделали так. Сначала заходим в Keycloak, создаем пользователя в Realm и группу, которая синхронизируется с IAM. После этого создаем проект в IAM и распределяем роли в группе. Обмен токенами для авторизации с Keystone происходит только после всех этих действий — значит, все запросы отправляются под созданным пользователем, только в рамках реально созданного проекта и с теми ролями, которые мы добавили на группу. 

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

Кроме того, решили все PaaS-тесты запускать только под теми проектами, которые заводим в IAM, а IaaS — под пользователем в заданной роли. Роли можем менять, только если в тест-кейсе есть на это прямое указание, во всех других случаях IaaS-функциональность тестируется только под администратором облака.

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

Тест-дизайн

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

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

Архитектура

Архитектуру решили сделать двухуровневой: SUT, REST-клиенты взаимодействия и тесты. REST-клиенты состоят из базового интерфейса CRUID (create, read, update, insert, delete) и наследуются из родительского REST-клиента Tempest, в котором реализована одна из важных функций — возможность получения различных типов Endpoint для сервиса, например Public endpoint для Manila. На случай, если нужного сервиса в каталоге Endpoint не обнаружится, добавили в REST-клиент фреймворка возможность передачи base url на сервис.

Конфигурация

Одно из важных преимуществ Tempest — простота конфигурирования. Конфигурации можно определять, добавляя и регистрируя категории и опции в config.py, группы и параметры в группе. 

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

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

Сейчас, помимо автоматизаторов VK, пользоваться нашими тестами могут и сторонние команды — все, кому нужно готовое решение, чтобы протестировать собственные продукты в облаке. Для внешних автоматизаторов мы готовим Docker-образы плагинов для тестирования различных компонентов облака, с помощью которых можно легко запустить автотесты и тестировать отдельные компоненты в любом окружении — публичном или частном облаке, даже в любом «ванильном» OpenStack-сервисе. 

Ресурсы, скорость и поиск багов: как повысить доверие к автоматизации

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

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

Еще один важный момент — поиск багов. Одна из главных химер мира автоматизации — Flaky-тесты, когда один и тот же тест поочередно становится то зеленым, то красным, то опять зеленым. Так что никто до конца не знает, является это багом или просто ошибкой теста. 

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

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