---
title: "Среды, учётные данные и переменные"
id: "2067"
type: "page"
slug: "environments"
published_at: "2026-09-28T14:32:25+00:00"
modified_at: "2026-09-28T14:33:58+00:00"
url: "https://pastukhov.com/agents/test/docs/environments"
markdown_url: "https://pastukhov.com/agents/test/docs/environments.md"
excerpt: "Одни и те же проверки должны работать и на тестовом стенде, и на рабочем, и…"
---

# Среды, учётные данные и переменные

[https://pastukhov.com/agents/test/docs/environments.md](https://pastukhov.com/agents/test/docs/environments.md)

Одни и те же проверки должны работать и на тестовом стенде, и на рабочем, и на компьютере разработчика, а пароли и ключи при этом не должны попадать в файлы проекта. Для этого в Агенте тестирования есть **среды** — отдельные наборы адресов — и защищённое хранилище для учётных данных.

Зачем это нужно: без сред пришлось бы в каждом действии прописывать конкретный адрес, а при переходе на другой стенд переписывать все файлы заново. А пароль, записанный прямо в файл, рано или поздно окажется в хранилище версий и станет известен всем, у кого есть доступ к коду.

## Среды

У проекта есть список сред — по строке на каждый стенд. В строке задаются: базовый адрес, метка выпуска (например, версия или дата), порядок сортировки и признак «защищённая (рабочая)». Имя среды — строчные латинские буквы, цифры и дефисы.

Одна среда — **по умолчанию**. Она неявная: отдельной строки у неё нет, адрес берётся из настроек проекта, и удалить её нельзя. Все остальные среды команда заводит сама.

Действия читают адрес стенда как `ctx.vars.BASE_URL`. Это значит, что один и тот же сценарий работает на любом стенде: запуск называет среду, и адрес подставляется сам. Значения переменных среды, заданные в её строке, подмешиваются поверх переменных проекта в момент выдачи задания — и адрес оттуда тоже может перекрыть базовый.

Если запуск назвал среду, которой нет, он отклоняется ещё при постановке в очередь. И наоборот: среду, на которую ссылаются запланированные запуски, удалить нельзя — сначала должны выполниться они. Удалённая среда остаётся в истории меткой.

## Сравнение двух сред

Сравнить тестовый стенд с рабочим можно отдельным режимом сборки: в списке сборок (вкладка «Проверка») ставится сравнительная сборка, в которой названы обе среды.

Важная деталь: эталоны привязаны к среде, её метка входит в их подпись. Поэтому снимок с тестового стенда никогда не сравнивается с эталоном рабочего, и наоборот — иначе тихое отличие между самими стендами выдавалось бы за изменение приложения.

## Учётные данные

Пароли, токены и заголовки хранятся не в файлах, а в защищённом хранилище — **в зашифрованном виде** (шифрование AES-256-GCM). Ключ лежит на сервере в файле `/apps/tests/keys/visual-creds.key`. Значение показывается один раз, в момент сохранения; потом его нельзя прочитать снова — только заменить или удалить.

В запуск учётные данные подставляются в самый момент выдачи задания, прямо в процесс исполнителя. Они никогда не попадают в исходники, журналы, запросы к модели и выгрузку. Действия читают их как `ctx.vars.NAME`, причём учётные данные и переменная не могут называться одинаково. Если нужных данных не окажется, действие честно упадёт с ошибкой, а не выполнится с пустым паролем.

Есть замена значения, удаление и **смена ключа шифрования**: создаётся новое поколение ключа, и все сохранённые данные всех проектов перешифровываются под него. Запуски, которые уже идут, завершатся старым ключом. Отменить смену нельзя.

Виды учётных данных: пароль, токен, заголовок и «другое» — на случай нестандартного.

## Переменные

Переменные — это наборы обычных значений, не секретов: например, имя тестового пользователя. В одном наборе может быть несколько значений через запятую; действует всегда первое, остальные — запас на ручную замену. Правило «побеждает первое» работает железно, чтобы результат прогона не зависел от случая.

Когда записи много, оба вида значений пригодятся. Но для всего, что является секретом — пароля, ключа, токена, — используйте именно учётные данные: только они шифруются и не покидают продукт.

## Подготовка и очистка

У проекта можно задать действия «до» и «после» любого теста — например, вход в систему и выход из неё. Первые выполняются перед шагами теста, вторые — после. Очистка выполняется даже тогда, когда шаг теста упал: иначе следующий запуск начнётся с грязного состояния.

Если тест объявляет свои списки подготовки и очистки, он полностью заменяет проектные — они не смешиваются. Пустой объявленный список — это осознанный отказ от фазы, а не «возьмите проектные». Свои списки теста живут в его файле и правятся в конструкторе тестов; сохранение проектных требует роли администратора.

## Защита рабочего контура

В настройках проекта можно перечислить **рабочие хосты** — адреса, которые обход браузером не тронет без явного разрешения. Так обход, запущенный по ошибке, не пойдёт гулять по рабочему сайту: сначала нужно осознанно снять защиту.

Дальше: кто из людей что может в проекте, — в разделе [Пользователи и роли](/agents/test/docs/users)
.

[← Оглавление документации](/agents/test/docs)
