Это заключительная часть серии из трех статей (первая статья, вторая статья), которые посвящены автоматизированному тестированию программных продуктов в Openshift Origin. В данной статье будут рассмотрены аспекты тестирования в контейнерах и особенности выстраивания CI/CD при участии таких продуктов как:
- Openshit Origin — как система для развертывания тестовых окружений.
- Jenkins — как инструмент непрерывной интеграции.
- Testlink — как система управления тестами.
Robot Framework — как framework для написания тестов.
Для лучшей репрезентативности я подготовил образ Vagrant, который содержит преднастроенную среду из вышеперечисленных продуктов (все перечисленные в данной статье объекты и механизмы могут быть легко проинспектированы). Чтобы повысить градус понимания материала я создал две задачи: задачу сборки, задачу тестирования. Обе задачи разбиты на этапы и детально описаны.
Быстрый старт:
- Загрузить Vagrant образ и Vagrantfile
vagrant box add --name viewshift viewshift-1.0.box && vagrant up
Создание полноценного окружения не входило в мои планы, но проиграв несколько сценариев со связыванием minishift c docker контейнерами пришло понимание, что это категорически неудобно и чревато ошибками. Тренировать воображение читателей с помощью одного текста считаю бесполезным занятием.
По умолчанию окружение стартует в графическом режиме. Сделано это для того, чтобы обойти проблему с доступом к продуктам извне. Настроен автоматический вход пользователя. Пользовательский Firefox содержит сохраненные закладки и учетные данные для доступа к продуктам.
Системные пользователи user и vagrant имеют неограниченный sudo доступ.
Задействованное ПО:
Название | Версия | Учетные данные |
---|---|---|
Openshift | 1.5.1 | admin:admin |
Jenkins | 2.60.1 | admin:admin |
Testlink | 1.9.16 | admin:admin |
Gogs | 0.11.19.0609 | git:git |
Mariadb | 5.5.52 | root:root |
OpenShift Pipeline Jenkins Plugin | 1.0.47 | - |
TestLink Plugin | 3.12 | - |
Robot Framework plugin | 1.6.4 | - |
Post-Build Script Plug-in | 0.17 | - |
system | - | root:root |
system | - | user:user |
system | - | vagrant:vagrant |
SHA1:
0992d621809446e570be318067b70fe2b8e786b2 viewshift-1.0.box
Задача сборки:
Задача сборки подразумевает под собой сборку образа Docker с приложением "curl", которое в последующем будет участвовать в задаче тестирования.
Примечание: в качестве корневого процесса (PID 1) в контейнере используется supervisord. supervisord и другие похожие инструменты очень полезны в тех случаях, когда нужно завершить работу приложения полностью или управлять процессами удаленно.
Принципиальная схема:
Этапы:
Определяем переменные, которые будут задействованы в задаче:
PROJECT — название проекта Openshift. Для данного проекта был создан ServiceAccount "jenkins", который обладает правами администратора в проекте. Данный ServiceAccount используется для доступа к проекту из Jenkins (данный аккаунт также используется в задаче тестирования).
APP_NAME и APP_VERSION — условное название и версия приложения, которые, тем не менее, фигурируют в нескольких местах: название и таг результирующего образа Docker, название запускаемого Build и т.д.
После того, как требуемые переменные были определены (продумана гранулярность/отличимость задач в проекте), требуется разнести их по всем YAML конфигурациям Openshift и другим шагам Jenkins.
На данном этапе создается объект BuildConfig, на базе которого будет создан и выполнен объект Build.
Происходит запуск процесс сборки на основе созданного BuildConfig. В случае успеха результирующий образ будет помещен во внутренний Docker регистр.
- Все созданные объекты удаляются вне зависимости от успешности сборки.
Задача тестирования:
Под задачей тестирования подразумевается процесс тестирования приложения "curl", которое взаимодействует с сервисом "nginx" по протоколу HTTP. Мы хотим удостовериться, что приложение работает корректно и проходит заданные тесты.
Принципиальная схема:
Этапы:
Определяем параметры, которые будут задействованы в задаче:
PROJECT — название проекта Openshift.
TESTPLAN — название тест-плана в Testlink. Задача завершится ошибкой, если указанный тест-план отсутствует в Testlink.
APP_NAME и APP_VERSION — условное название и версия приложения, которые аналогичным образом как и в задаче сборки.
TEST_CMD — переменная, которая содержит название исполняемого файла, который будет запущен внутри контейнера. Аргументы командной строки указаываются в соотвествующем шаге Jenkins.
TEST_TIMEOUT — численное выражение, которое задает время ожидания выполнения команды внутри контейнера. По истечении данного времени Jenkins задача завершает своё выполнение с ошибкой.
см. задачу сборки.
На данном этапе задается конфигурация Testlink, в которой указывается: с каким сервером будет установлена связь, какой тест-план будет использоваться (из тест-плана загружаются все назначенные данном тест-плану тесты для последующего сравнения), под какой платформой проводилось тестирование и т.д. Всё это требуется для последующей публикации пройденных тестов обратно в Testlink и отображения отчета тестирования непосредственно в Jenkins.
Данный этап предназначен для создания Service. Создаваемые сервисы будут указывать на приложения, которые будут запущены позднее. Через данные сервисы осуществляется проверка доступности приложений.
На данном этапе создается Pod для приложения "nginx".
На данном этапе создается Pod для приложения "curl". Образом для данного контейнера является образ, который создается в процессе задачи сборки. В отличии от "nginx", в данный образ добавлен том данных "share", который позволит контейнеру коммуницировать с файловой системой рабочего узла.
После того, как все Pod созданы, требуется проверка доступности приложений через опубликованные раннее сервисы.
На данном этапе происходит запуск команды тестирования в Pod с последующим ожиданием завершения выполнения данной команды.
После прохождения всех тестов происходит копирование отчета о тестировании в workspace задачи для последующего иморта в Testlink.
На данном этапе указывается стратегия (может быть не одна) сопоставления пройденных тестов с тем, что было получено из указанного раннее тест-плана. В данном случае идет простое сравнение названий тест-кейсов. После всех операции происходит публикация отчета о тестировании в Testlink.
Помимо отчета Teslink в формате Junit присутствует отчет о тестировании в формате Robot Framework, который установит статус выполненной задачи исходя из пороговых значений пройденных тестов.
- На данном этапе происходит удаление всех созданных в процессе выполнения задачи объектов Openshift.
Всё вместе:
Преимущества и недостатки тестирования в контейнерах:
Недостатки:
- Только Linux. Развивается так называемая "легкая" виртуализация и стоит, наверное, ожидать изменений в ситуациии, но пока только Linux.
- Единая версия ядра для всех контейнеров. Возможно в п.1
- Только x86_64. Нет, безусловно, ваш образ может быть x86, но ядро будет x86_64. Для кого-то это может стать препятствием.
- Отсутствие вложенного SELinux (вложенные CGroups существуют).
- Отсутствие полноценного видеоустройства и доступа к экрану. Возможно в п.1
Плюсы:
- Скорость работы и гибкость запускаемых окружений, высокая плотность.
- Унифицированный способ доставки, переносимости и повторяемости приложений.
Заключение:
Openshift Origin в связке с другими инструментами позволяет добиться впечатляющей гибкости и эффективности. Продуманная схема именования проектов/объектов позволяет избежать возникновения ошибок при массовых запусках задач тестирования.
Благодарность:
Хочу выразить благодарность сотрудникам компании Google за то, что сделали такую замечательную платформу.
Хочу выразить благодарность сотрудникам компании Red Hat, которые сделали из замечательной платформы законченный продукт.
Полезные ссылки:
Комментарии (5)
neonTest
16.07.2017 11:56Уже сталкивались с проблемой актуализации/соотвествия тестов в TestLink и «шагов» в коде тестов?
Т.к софт имеет свойство изменяться => нужно исправлять тест-кейс и в тест-менеджмент среде (TestLink), и в коде тестов.
Собственно, вопрос в том, как часто приходится «синхронизировать» код тестов и TestLink?livelace
16.07.2017 12:07Собственно, вопрос в том, как часто приходится «синхронизировать» код тестов и TestLink?
Не до конца понял суть вопроса, но:
1. Код теста не хранится в Testlink, совсем. В Testlink хранится только детальное описание теста + метка теста, которая совпадает с названием теста в Robot Framework. Testlink стоит рассматривать как «органайзер» тестов/тест-планов/платформ/отчётов и т.д. и т.п.
2. В Robot Framework можно «вести документацию», но это совершенно не репрезентативно + не отвечает требованиям ведения процесса тестирования.
livelace
16.07.2017 12:17Если же вы спрашиваете о сихронизации самого теста в коде Robot Framework и описания теста в Testlink — это непрерывный процесс. Изменился функционал ПО -> измени тест -> измени описание к тесту.
neonTest
17.07.2017 19:56да. именно это и имел ввиду (поменять описание в TestLink + изменить код теста).
можно, в принципе, автоматически создавать шаги для тест-кейса в TestLink из кода теста. (если TestLink это позволяет).
однако это не всегда подходит под каждый конкретный workflow разработки на разных проектах.
oleg-x2001