Тестовая среда и тестовый стенд (Test Environment / Test Bed)

Что такое тестовая среда и тестовый стенд (test environment / test bed): определение, основные принципы, примеры и практические советы. Изучайте продвинутом тестировании с подробными объяснениями для начинающих специалистов.

Тестовая среда и тестовый стенд (Test Environment / Test Bed).

Тестовое окружение (test environment): Окружение, включающее в себя аппаратное обеспечение, измерительную аппаратуру, имитаторы, программный инструментарий и прочие инструменты, необходимые для проведения теста. (IEEE 610)

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

Существует несколько сред:

Среда разработки (Development Env).

В ней разработчики пишут код, проводят отладку, исправляют ошибки, выполняют Unit-тестирование. За эту среду отвечают также разработчики.

Среда тестирования (Test Env).

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

Интеграционная среда (Integration Env).

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

Превью среда (Preview, Preprod Env).

В идеале, это среда идентичная или максимально приближенная к продуктивной: те же данные, то же аппаратно-программное окружение, та же производительность. Используется, чтобы сделать финальную проверку ПО в условиях максимально приближенным к «боевым». Здесь тестировщики проводят заключительное end-to-end тестирование функционала, бизнес и / или пользователи проводят UAT, а команды поддержки L3 и L2 выполняют DryRun (пробную установку релиза). Как правило за эту среду отвечает группа L3 поддержки.

Продакшн среда (Production Env).

Среда, в которой работают пользователи. С этой средой работает команда L2 поддержки устанавливая поставки ПО или патчи с исправлениями, выполняя настройки, отвечая за работоспособность всех систем. Инциденты и проблемы требующие исправления ПО передаются в работу команде на L3.

Испытательный стенд (Test Bed).

Более глобальная сущность и включает в себя operating system, configuration management for the products, hardware, network topology и т.д. Настраиваются в соответствии с требованиями тестируемого приложения. В некоторых случаях испытательный стенд может представлять собой комбинацию тестовой среды и тестовых данных, которые он использует.

Настройка правильной среды тестирования гарантирует успех тестирования ПО. Любые недостатки в этом процессе могут привести к дополнительным затратам и времени для клиента.

Следующие люди участвуют в настройке тестовой среды: Системные администраторы, Разработчики, Тестировщики.

Jenkins.

Jenkins — не просто инструмент CI / CD. Это Framework, потому что он:

  • Гибок и расширяем. Jenkins — опенсорсный проект с множеством внешних расширений.
  • Минимален из коробки. У Jenkins есть контроллер. К нему можно подключить несколько слоев и уже на этом сетапе собрать минимальный пайплайн, который позволит автоматизировать работу по обновлению сервисов.
  • Требует настройки. Jenkins — один из кубиков, с помощью которого можно построить большую систему автоматизации. Но прежде чем сделать что-то, его придётся настроить.

Jenkins — это Java-приложение. У него есть контроллер или Master Mode — управляющий центр, который занимается планированием задач. Он запускает задачи согласно установленному расписанию на слэйвах, которые к нему прикреплены. Помимо этого контроллер хранит логи наших задач. Вся история хранится только на Master Mode, поэтому важно помнить о настройке правильной ротации логов.

Слэйвы или агенты — это то, что непосредственно выполняет сами задания.

Коротко их взаимодействие можно описать так: контроллер запускает задачу и говорит агенту выполнить её, агент выполняет задачу и возвращает результат контроллеру. Контроллер получает результат и сохраняет его в build-логе.