![](/sites/default/files/social_buttons/ohloh.png)
![](/sites/default/files/social_buttons/vimeo.png)
![](/sites/default/files/social_buttons/github.png)
![](/sites/default/files/gplus.png)
![](/sites/default/files/feed.png)
![](/sites/default/files/social_buttons/linkedin.png)
![](/sites/default/files/social_buttons/facebook.png)
![](/sites/default/files/social_buttons/twitter.png)
![](/sites/default/files/social_buttons/vkontakte.png)
![](/sites/default/files/social_buttons/youtube.png)
Весь из себя Python
Реплика Александры Федоровой, руководителя команды CI (Москва, Россия).![]()
От редакции
Когда мы решили регулярно публиковать обновления в корпоративном аккаунте в Facebook на русском языке, то лелеяли надежду, что аудитория, заинтересованная в OpenStack-теме, начнет разговаривать с нами. И вот, это произошло! Мы начали получать вопросы от читателей. И это очень, очень важно для нас! Пожалуйста, не останавливайтесь!
Вопрос, ответ на который мы подготовили сегодня, касается тестирования и звучит следующим образом:
Можете ли вы описать в общих чертах процесс тестирования на Python ваших продуктов OpenStack, так как очень сложно разобраться в взаимосвязях их отдельных элементов.Для первой беседы на тему тестирования мы пригласили Александру Федорову, руководителя команды CI из московского офиса нашей компании. И вот что она рассказала…
Виды тестирования, применяемые в OpenStack
OpenStack — это много разных Python-проектов. Каждый проект тестируется на нескольких уровнях. Если точнее — на четырех:
- unit-тесты (или модульные тесты),
- функциональные тесты,
- интеграционные тесты
- и системные тесты.
Начнем по порядку. Специфика OpenStack в том, что это набор из большого числа достаточно независимых проектов. У каждого проекта есть свой фреймворк для unit-тестов. Функциональные тесты так же, как unit-тесты, связаны с особенностями использования того или иного сервиса. Управляются и автоматизируются эти тесты, опять же, на уровне одного конкретного проекта. Для Python-кода при этом используется стандартный подход запуска кода в tox-окружении.
Интеграционные тесты позволяют протестировать совместную работу нескольких проектов. Для этого принято использовать так называемый Devstack — написанный на Bash фреймворк для деплоймента базового OpenStack-окружения. На развернутом окружении далее прогоняется Python-based Tempest framework, он и позволяет тестировать сценарии взаимодействия между разными сервисами экосистемы OpenStack. Например, для создания compute-ноды нужно авторизоваться в Keystone, получить базовый образ из Glance и IP-адрес из Neutron.
Длинные цепочки взаимодействия между сервисами тестируются в апстриме на девелоперском окружении (DevStack), с помощью Tempest.Нет ли конкуренции между фреймворками Tempest и Rally внутри экосистемы OpenStack?
Нет, сейчас эти два проекта сотрудничают друг с другом. Rally отвечает за бенчмарк-тестирование (или проверку производительности системы) и нагрузочное тестирование. Tempest — это про сценарии, про логику взаимодействия между сервисами, а Rally — про нагрузку: что произойдет, если я “прогоню” этот сценарий 100500 раз? Сколько времени это займет? Часто тестировщики “гоняют” Rally поверх Tempest. Или используют Tempest как Rally-case.
Итак, модульные, функциональные и интеграционные тесты есть в апстриме. Остальное — фреймворки системных тестов.Фреймворки системных тестов
![]()
Почему это специфично было для Fuel? Потому что Fuel — это сервис развертывания OpenStack, и мы тестируем не просто сервисы и их работу друг с другом, а проверяем полный цикл, от установки управляющей Fuel-ноды на «пустой» сервер, предоставления доступа к OpenStack Dashboard, проигрывания типичных сценариев работы с облаком, до апгрейда кластера. Еще тестируем отдельно много разнообразных сценариев установки.
В апстриме DevStack предполагает довольно однообразное базовое девелоперское развертывание OpenStack: на одной ноде разворачиваются все сервисы, каждый из которых получает собственную screen-сессию, где разработчик может интерактивно выполнять какие-то операции, смотреть лог или даже патчить код «наживую». Во Fuel поддерживается установка OpenStack в HA-режиме с несколькими контроллерами, с разнообразными конфигурациями сети. Это тестирование более «тяжелое» — базовый системный тест занимает около полутора часов на «стандартном» bare-metal сервере.
Для системных тестов опять используется фреймворк, основанный на Python, который состоит из двух частей: Fuel devops, который готовит окружение из 5-10 виртуальных машин, и Fuel QA — тестовый фреймворк на базе Proboscis, в котором, собственно, содержится вся логика тестовых сценариев и реализация работы с Fuel и OpenStack.
Человек готовится к собеседованию в Mirantis: что ему нужно знать о тестировании?
С моей точки зрения, у нас QA-процессы построены на многих взаимодействиях с низкоуровневыми вещами. Например, процесс создает виртуальные машины, делает запрос к низкоуровневому API, “ходит” по серверам… Это не чисто python-в-себе. Из него всегда есть выходы на какие-то системные или OpenStack-сервисы. То есть ты не можешь ограничиваться только знанием python-фреймворка, нужна хорошая база. Но основные принципы те же. Возьмем, например, nose test фреймворк: тест-кейсы, настройка начального окружения, реверт к стандартному окружению, зависимости… Но наполнение каждого из этих шагов может быть нестандартным для классической python-разработки, потому что всегда есть “хвосты” наружу, которые смотрят из Python и дергают что-то еще…
Продолжение следует!