Автор статьи: Павел Балахонов
Использует в своей работе только самые актуальные стеки технологий и инструменты в области автоматизации тестирования .
Многие, кто работает с Openstack или собирается разворачивать облако с его последующим использованием, начинают со временем задумываться о тестировании развернутой облачной платформы. Ведь мало развернуть облачную платформу и поставить ее конечному пользователю (тут я подразумеваю под пользователем заказчика и дальше буду также называть пользователем заказчиков, которым поставляется наша облачная платформа). При поставке облачного решения очень важно не просто предоставить продукт, а поставить продукт высокого качества. И тут возникает дилемма: как проводить тестирование продукта, который состоит из большого количества компонентов и сервисов, и все эти компоненты связаны между собой. Другая проблема заключается в том, что приватное облако компании состоит из множества компонентов, которые разработаны компанией и поставляются в коробке облака. И такие компоненты так же необходимо тестировать.
В данной статье будет говориться исключительно про функциональное API тестирование и не будет отражено тестирование UI и нагрузочное тестирование. Это отдельные большие темы для будущих статей.
Так вот, задача заключается в следующем: необходимо провести функциональное API тестирование приватного облака на Openstack. Давайте немного визуализируем структуру нашего SUT, с которым мы будем взаимодействовать из автотестов:
На данной схеме видно, что у нас наш SUT состоит из IAAS компонентов (компонентов инфраструктуры), PAAS компонентов (компонентов платформы) и различных дополнительных сервисов для решения самых различных задач (например, сервис миграций VM между хостами, IAM сервис).
И тут сразу выделяется несколько направлений в тестировании:
ручное тестирование платформы,
API автоматизация тестирования облачной платформы.
В данной статье мы рассмотрим процесс покрытия API автотестами нашего облака с гарантией высокого качества нашего продукта.
В качестве набора технологий для автоматизации тестирования был выбран стек Python 3, так как одна из хороших практик - использование в автоматизации тестирования того стека, который использует разработка. Из-за такого решения автотесты смогут поддерживать и развивать не только автоматизаторы, но и разработчики.
Каждая часть нашего облака, будь то IAAS или PAAS, состоит из большого количества взаимосвязанных компонентов. И при выборе стека было два пути:
взять классический стек на питоне pytest + allure report + requests (в качестве http клиента)
поискать на рынке готовый инструмент для написания функциональных API тестов и провести работы по интеграции данного инструмента в процесс тестирования в нашей команде.
Забегая немного вперед скажу, что мы выбрали второй путь и этому есть веская причина. Когда мы говорим по API автоматизацию, то чаще всего мы используем 2-х уровневую архитектуру:
На схеме видно, что имеется уровень клиентского взаимодействия с контроллерами SUT и второй уровень - уровень тестов, в котором создаются необходимые объекты клиентов (для каждого test suite создается свой набор клиентов, которые необходимы для тестирования определенной функциональной единицы). На схеме опущены DTO и другие сущности. Считаю, что они будут лишними и только усложнят понимание идеи данного дизайна в проектировании инструмента автоматизации тестирования.
Если бы мы использовали связку pytest + allure report + requests, то нам необходимо было бы:
потратить ресурсы на написание клиентов взаимодействия с компонентами IAAS нашего облака (например клиенты для compute API, клиенты для glance API, neutron API и т.д.).
написать механизм авторизации в нашем облаке. Получение auth токена из keystone не достаточно для авторизации в нашем приватном облаке, так как у нас отличается процесс авторизации в облаке от эталонного Openstack.
написать rest клиенты для взаимодействия с компонентами PAAS (например с trove, magnum и другими).
написать механизм простой выборки наших тестов с генерацией различных конфигураций для тестирования различных компонентов и еще много-много всего.
Получается, что для того, чтобы запустить нашу API автоматизацию тестирования, нам необходимо потратить огромное количество ресурсов, не считая того, что продукт развивается и требует ресурсы для поддержки.
Для решения поставленной проблемы мы посмотрели, а есть ли готовый инструмент для API автоматизации облака. И такой инструмент оказалось есть - Tempest.
Чем же хорош данный инструмент:
из коробки имеет интеграцию с Openstack,
имеет готовые IAAS клиенты,
имеет механизм чистки создаваемых автотестами ресурсов,
большое количество готовых ожиданий и инструментов для решения повседневных микрозадач автоматизации. Согласитесь, приятно вызвать метод у готового вейтера, чем писать набор ожиданий самому,
набор ассертов из коробки,
выборка тестов и возможность запускать тесты по атрибутам (из коробки можно запустить только по атрибуту smoke, но никто не мешает добавить те декораторы, которые хочется),
opensource. Это огромный плюс, так как наша коробка отличается от эталонного Openstack и необходима адаптация инструмента автоматизации тестирования под наш процесс взаимодействия с коробкой,
возможность организовать покомпонентное тестирование и ограничить контекст между компонентами за счет написания плагинов для различные IAAS и PAAS компоненты,
гибкость конфигурирования. Можно легко добавлять новые группы в конфигурацию для того или иного компонента облака, который мы тестируем,
динамические credentials. Возможность динамически создавать пользователей с определенными ролями перед запуском того или иного набора тестов или всеми наборами. Дает нам возможность легко и просто проверять ролевую модель на различных компонентах нашего облака.
Конечно же, все из перечисленного не является полным списком фишек данного инструмента, но в целом этот список является весомым аргументом, чтобы не писать свои IAAS рестовые клиенты.
Немного оговорюсь, что есть компоненты, которые не имеют готовых рестовых клиентов из коробки темпеста и их приходится писать. Но пишутся они путем наследования от объекта RestClient в темпесте, который через конструктор получает имя сервиса, регион и тип хоста и автоматически сетит хостнейм сервиса в контексте, который получает из каталога endpoints. А если сервиса нет в каталоге, то мы немного расширили этот клиент и передаем ему хостнейм на сервис, который чаще всего определяем в конфигурации того или иного компонента нашего облака.
Теперь давайте рассмотрим, как выглядят наши API автотесты на tempest:
Tempest IAAS Rest Clients – набор IAAS клиентов, которые используют наши автотесты.
Данные клиенты могут подключаться на базовом 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 наших тестов выглядит следующим образом:
создается слепок нашей облачной платформы,
запускаются тесты для IAAS компонентов и параллельно запускаются тесты для PAAS компонентов,
чистятся ресурсы после прогона тестов.
Если же рассмотреть pipeline наших тестов на IAAS компоненты, то выглядит он следующим образом:
Как видно схемы, для каждого компонента устанавливается свой tempest плагин, который определяет соответствующий контекст для автотестов. Также создается своя конфигурация тестирования и запускаются только те тесты, которые необходимы для тестирования того или иного компонента. Для каждого компонента генерируется и публикуется отчет о результатах тестирования. Все прогоны у нас параллелятся для уменьшения времени тестирования.
На данной схеме приведены только 3 компонента, но на самом деле их намного больше, но на сам pipeline прогона тестов это никак не влияет.
В данной статье мы рассмотрели базовые архитектурные решения, которые были приняты в команде автоматизации тестирования и позволяют успешно покрывать IAAS и PAAS компоненты функциональными API автотестами и делать наш продукт качественным.
Со временем доверие к автоматизации тестирования возрастает и появляется необходимость прогона тестов на окружении заказчика и интеграции процесса автотестирования в процесс поставки продукта конечному пользователю. При решении данной задачи возникают вопросы: как поставлять тесты? В каком виде их поставлять? На эти и другие вопросы Павел Балахонов ответит на бесплатном уроке, где рассмотрим как обернуть тесты на tempest в докер образы и поставить их заказчику и конечно же разберем докер как технологию. Регистрация на урок доступна по ссылке ниже.
