4k+ знаков про тестовое окружение

Тестовое окружение – неизменный спутник тестирования. Неважно, какое ПО мы тестируем, без разницы, какую используем методологию: если мы выполняем тест, то, как минимум, нам нужен объект тестирования в подходящем состоянии. И как только этот объект появляется, появляется и оно, тестовое окружение.

Тестовое окружение (ТО) может готовиться заранее, а может «возникать» прямо в момент выполнения теста. Разным проектам нужны разные ТО, что естественно. ТО меняется вместе с развитием продукта, требованиями к нему, бюджетом и пониманием роли тестирования. Короче, как водится, идеального-вообще ТО не бывает, бывает – адекватное здесь-и-сейчас, решающее текущие задачи при данных обстоятельствах (ну и желательно с каким-то заделом на обозримое будущее).

Говорят, хороший интерфейс ПО – тот, который пользователь «не замечает», а просто решает свои задачи, работая с программой. Про ТО можно сказать что-то подобное: чем проще подготовка и выполнение тестов, воспроизведение дефектов, работа с прочими артефактами, тем лучше ТО. Чем меньше мы спотыкаемся о разложенные нами же грабли, не относящиеся к тестируемому продукту, тем больше мы спотыкаемся о грабли в продукте, разбросанные разработчиками. А этого от нас и ждут, ага.

Создание такого ТО, понятно, требует труда. По сути, это такой сопутствующий проект – со своими требованиями, дедлайнами и потребителями. Скорее всего, этот проект будет длиться не меньше, чем собственно разработка system under test (SUT). От этого проекта серьёзно зависит успех производимого продукта.

Можно выделить несколько требований, актуальных для большинства ТО.

Применимость

ТО должно отвечать поставленным задачам. Железо должно соответствовать требованиям к SUT. Хорошо бы, чтоб конфигурации были подобны тем, что используются в боевом режиме (или мы хотя бы знали diff).

Конечно, ТО должно позволять выполнить необходимые тесты и прочие активности. Должна быть возможность проверить различные важные конфигурации (поддерживаемые ОС, БД, локализации, и т.д.). В общем, тестировщики должны иметь возможность тестировать, иначе зачем всё?

Изолированность

По-хорошему, SUT должна запускаться на отдельных серверах, реальных или виртуальных. Это не должны быть сервера разработчиков. Это не должны быть рабочие станции сотрудников. Это не должны быть сервера взятые на час взаймы у соседнего отдела.

Подобная изолированность защищает, с одной стороны, от особенностей конфигурации отдельных машин. С другой – от потери данных из-за нестабильности SUT. С третьей – упрощает контроль за состоянием SUT и конфигурациями, обеспечивает воспроизводимость тестов. Ладно, даёт шанс обеспечить воспроизводимость.

В более долгосрочной перспективе – позволяет настраивать нетривиальное окружение, варьировать настройки и подходы, проверять идеи и подозрения. Масса пользы в общем.

Доступность и простота

Если нет каких-то особых причин для обратного, ТО должно быть легко доступно для всех, кто с ним работает – тестировщиков, программистов, аналитиков и других интересующихся.

Не должно быть проблем с созданием нового экземпляра SUT в требуемой конфигурации.

Нам нужна возможность без особых затрат отслеживать состояние и использование ТО – что где находится и почему, кто использует тот или иной объект (например, копию SUT), где у нас есть свободные ресурсы, и т.д.

По возможности следует исключить конфликты использования общих ресурсов/объектов.

Если отдельные проверки требуют специфичных данных, имеет смысл их подготовить заранее и сложить в какое-то общее хранилище. Не в ущерб качеству тестов, конечно.

Управляемость

ТО должно быть управляемо. Добавление или замена серверов должны происходить максимально просто. Внезапные падения старых машин не должны вести к фатальным последствиям (ну, хотя бы не всегда). Перенос данных между серверами тоже не должен становиться проблемой.

Перераспределение машин под ту или иную задачу, перенастройка, обновление, развертывание SUT – все это должно быть возможно, и желательно – легко выполнимо.

Стабильность

Пусть SUT сколь угодно нестабильна, ей можно, а ТО должно быть здоровым и непотопляемым. Тут стоит задействовать практики рекомендованные системным администраторам (кстати, невредно с ними проконсультироваться, если есть с кем) – мониторинг состояния железа, контроль нагрузки на сервера, регулярные бэкапы и подготовка сценариев на случай внезапной смерти Самого Важного Сервера…

В общем, все, что выглядит нужным и применимым.

Пожалуй, для начала достаточно этих пяти небольших китов. На них можно построить вполне себе приличное тестовое окружение. Особенно, если не забывать думать хотя бы на полшага вперёд и планировать развитие ТО, отталкиваясь от нужд проекта.