[recovery mode] API автотестирование приватного облака на Openstack

88e8b094b006efaf5064151d9a2bf1c0.png

bfbfa87c6fff4d8a11838ac5a5deeb41.jpgАвтор статьи: Павел Балахонов

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

Многие, кто работает с Openstack или собирается разворачивать облако с его последующим использованием, начинают со временем задумываться о тестировании развернутой облачной платформы. Ведь мало развернуть облачную платформу и поставить ее конечному пользователю (тут я подразумеваю под пользователем заказчика и дальше буду также называть пользователем заказчиков, которым поставляется наша облачная платформа). При поставке облачного решения очень важно не просто предоставить продукт, а поставить продукт высокого качества. И тут возникает дилемма: как проводить тестирование продукта, который состоит из большого количества компонентов и сервисов, и все эти компоненты связаны между собой. Другая проблема заключается в том, что приватное облако компании состоит из множества компонентов, которые разработаны компанией и поставляются в коробке облака. И такие компоненты так же необходимо тестировать.

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

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

aec905f75d3b3cccdd92f81465ef1fe5.png

На данной схеме видно, что у нас наш SUT состоит из IAAS компонентов (компонентов инфраструктуры), PAAS компонентов (компонентов платформы) и различных дополнительных сервисов для решения самых различных задач (например, сервис миграций VM между хостами, IAM сервис).

И тут сразу выделяется несколько направлений в тестировании:

  • ручное тестирование платформы,

  • API автоматизация тестирования облачной платформы.

В данной статье мы рассмотрим процесс покрытия API автотестами нашего облака с гарантией высокого качества нашего продукта.

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

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

  • взять классический стек на питоне pytest + allure report + requests (в качестве http клиента)

  • поискать на рынке готовый инструмент для написания функциональных API тестов и провести работы по интеграции данного инструмента в процесс тестирования в нашей команде.

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

ebbf8aa99b4d91d657ddcdd6982eb82d.png

На схеме видно, что имеется уровень клиентского взаимодействия с контроллерами SUT и второй уровень — уровень тестов, в котором создаются необходимые объекты клиентов (для каждого test suite создается свой набор клиентов, которые необходимы для тестирования определенной функциональной единицы). На схеме опущены DTO и другие сущности. Считаю, что они будут лишними и только усложнят понимание идеи данного дизайна в проектировании инструмента автоматизации тестирования.

Если бы мы использовали связку pytest + allure report + requests, то нам необходимо было бы:

  1. потратить ресурсы на написание клиентов взаимодействия с компонентами IAAS нашего облака (например клиенты для compute API, клиенты для glance API, neutron API и т.д.).

  2. написать механизм авторизации в нашем облаке. Получение auth токена из keystone не достаточно для авторизации в нашем приватном облаке, так как у нас отличается процесс авторизации в облаке от эталонного Openstack.

  3. написать rest клиенты для взаимодействия с компонентами PAAS (например с trove, magnum и другими).

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

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

Для решения поставленной проблемы мы посмотрели, а есть ли готовый инструмент для API автоматизации облака. И такой инструмент оказалось есть — Tempest.

Чем же хорош данный инструмент:

  • из коробки имеет интеграцию с Openstack,

  • имеет готовые IAAS клиенты,

  • имеет механизм чистки создаваемых автотестами ресурсов,

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

  • набор ассертов из коробки,

  • выборка тестов и возможность запускать тесты по атрибутам (из коробки можно запустить только по атрибуту smoke, но никто не мешает добавить те декораторы, которые хочется),

  • opensource. Это огромный плюс, так как наша коробка отличается от эталонного Openstack и необходима адаптация инструмента автоматизации тестирования под наш процесс взаимодействия с коробкой,

  • возможность организовать покомпонентное тестирование и ограничить контекст между компонентами за счет написания плагинов для различные IAAS и PAAS компоненты,

  • гибкость конфигурирования. Можно легко добавлять новые группы в конфигурацию для того или иного компонента облака, который мы тестируем,

  • динамические credentials. Возможность динамически создавать пользователей с определенными ролями перед запуском того или иного набора тестов или всеми наборами. Дает нам возможность легко и просто проверять ролевую модель на различных компонентах нашего облака.

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

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

Теперь давайте рассмотрим, как выглядят наши API автотесты на tempest:

34cae8485412ad9ba80b4754928adf0a.png

Данные клиенты могут подключаться на базовом test suite, если они используются для всех наборов функциональных тестов, либо могут подключаться для определенного набора тестов.

Например: для тестирования агрегатов через API не нужно клиент aggregates_client подключать в базовом сьюте, т.к. этот клиент будет использоваться только в наборе тестов, которые проверяют агрегаты. Кстати, для подключения объектов в tempest, есть метод класса setup_clients, который позволяет легко подключать необходимые клиенты и делает наш код читаемым и структурируемым: все клиенты в одном месте, что с точки зрения дизайна выглядит просто отлично, не нужно бегать по коду в поисках объектов клиентов.

  • Custom component rest Client — rest клиенты на кастомные компоненты нашего облака, которые не поддерживаются из коробки tempest.

К таким компонентам относятся дополнительные компоненты, которые пишут наши разработчики и делают наше приватное облако уникальным и универсальным. Данные рестовые клиенты мы наследуем от Tempest RestClient, что позволяет нам легко интегрировать наши клиенты в Tempest и получать auth токены для запросов для этих компонентов. Таким образом, добавление нового клиента сводится к тому, что мы описываем CRUD для контроллера компонента и передаем базовый хостнейм компонента, если его нет в каталоге endpoints, либо имя сервиса с регионом и типом endpoint, для получения его из каталога. Согласитесь намного проще, чем писать все это самому. И конечно же подключение данного клиента ничем не отличается от подключения клиентов tempest.

  • Base TestSuite — базовый testsuite от которого наследуются все наборы с тестами. Задача данной сущности — подключение общих клиентов, предоставление общего интерфейса для всех тестовых наборов и создание общих ресурсов, которые необходимы для прогона всех тестов на приватном облаке.

  • TestSuite — набор с тестами, на котором подключаются необходимые Rest клиенты и создаются необходимые ресурсы.

  • Resources — ресурсы, которые необходимы для тестирования функциональной единицы.

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

Наши функциональные API автотесты обладают определенными свойствами, которые делают их качественными и универсальными. Одно из свойств — самодостаточность.

Суть самодостаточности в том, что тест должен сам создавать необходимые ресурсы для тестирования и после тестирования подчищать за собой все ресурсы, которые были созданы. В Junit это легко решается за счет фикстур или реализации callback интерфейсов. Но в tempest это решается за счет resource setups и cleanup сервиса.

Tempest поддерживает несколько уровней чистки. Рассмотрим каждый из них:

  • регистрация tearDown события в коде.

    Суть его в том, что мы можем зарегистрировать событие в cleanup сервисе, и оно будет гарантированно вызвано после прогона теста, даже если тест будет остановлен по прерыванию. Все равно будет вызвана цепочка зарегистрированных tearDown событий и попытка чистки ресурсов. Ресурсы могут и не почиститься, если например они будут заняты другим ресурсом, но попытка чистки все равно будет. Таким образом мы получаем гибкость в написании тестов, так как сможем вызвать чистку там, где действительно она нам нужна

  • снятие snapshot платформы.

    Данный механизм чистки позволяет снять слепок с облачной платформы до прогона тестов и затем удалить все ресурсы, которые тесты создали. Причем соблюдается определенная последовательность чистки ресурсов. Данный механизм используем для финальной чистки (мало ли забыли добавить в коде tearDown событие и есть ресурсы, которые могут использоваться и мы не смогли их удалить через tearDown).

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

В конце статьи немного осветим запуск наших тестов. В данный момент pipeline наших тестов выглядит следующим образом:

afeb54159d3fef97cfda401fbae4426e.png

  • создается слепок нашей облачной платформы,

  • запускаются тесты для IAAS компонентов и параллельно запускаются тесты для PAAS компонентов,

  • чистятся ресурсы после прогона тестов.

Если же рассмотреть pipeline наших тестов на IAAS компоненты, то выглядит он следующим образом:

03379110445bcba5a6990854dcd41d9b.png

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

На данной схеме приведены только 3 компонента, но на самом деле их намного больше, но на сам pipeline прогона тестов это никак не влияет.

В данной статье мы рассмотрели базовые архитектурные решения, которые были приняты в команде автоматизации тестирования и позволяют успешно покрывать IAAS и PAAS компоненты функциональными API автотестами и делать наш продукт качественным.

Со временем доверие к автоматизации тестирования возрастает и появляется необходимость прогона тестов на окружении заказчика и интеграции процесса автотестирования в процесс поставки продукта конечному пользователю. При решении данной задачи возникают вопросы: как поставлять тесты? В каком виде их поставлять? На эти и другие вопросы Павел Балахонов ответит на бесплатном уроке, где рассмотрим как обернуть тесты на tempest в докер образы и поставить их заказчику и конечно же разберем докер как технологию. Регистрация на урок доступна по ссылке ниже.

© Habrahabr.ru