Тестовая среда и тестовый стенд (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-логе.