Одни и те же проверки должны работать и на тестовом стенде, и на рабочем, и на компьютере разработчика, а пароли и ключи при этом не должны попадать в файлы проекта. Для этого в Агенте тестирования есть среды — отдельные наборы адресов — и защищённое хранилище для учётных данных.
Зачем это нужно: без сред пришлось бы в каждом действии прописывать конкретный адрес, а при переходе на другой стенд переписывать все файлы заново. А пароль, записанный прямо в файл, рано или поздно окажется в хранилище версий и станет известен всем, у кого есть доступ к коду.
Среды
У проекта есть список сред — по строке на каждый стенд. В строке задаются: базовый адрес, метка выпуска (например, версия или дата), порядок сортировки и признак «защищённая (рабочая)». Имя среды — строчные латинские буквы, цифры и дефисы.
Одна среда — по умолчанию. Она неявная: отдельной строки у неё нет, адрес берётся из настроек проекта, и удалить её нельзя. Все остальные среды команда заводит сама.
Действия читают адрес стенда как ctx.vars.BASE_URL. Это значит, что один и тот же сценарий работает на любом стенде: запуск называет среду, и адрес подставляется сам. Значения переменных среды, заданные в её строке, подмешиваются поверх переменных проекта в момент выдачи задания — и адрес оттуда тоже может перекрыть базовый.
Если запуск назвал среду, которой нет, он отклоняется ещё при постановке в очередь. И наоборот: среду, на которую ссылаются запланированные запуски, удалить нельзя — сначала должны выполниться они. Удалённая среда остаётся в истории меткой.
Сравнение двух сред
Сравнить тестовый стенд с рабочим можно отдельным режимом сборки: в списке сборок (вкладка «Проверка») ставится сравнительная сборка, в которой названы обе среды.
Важная деталь: эталоны привязаны к среде, её метка входит в их подпись. Поэтому снимок с тестового стенда никогда не сравнивается с эталоном рабочего, и наоборот — иначе тихое отличие между самими стендами выдавалось бы за изменение приложения.
Учётные данные
Пароли, токены и заголовки хранятся не в файлах, а в защищённом хранилище — в зашифрованном виде (шифрование AES-256-GCM). Ключ лежит на сервере в файле /apps/tests/keys/visual-creds.key. Значение показывается один раз, в момент сохранения; потом его нельзя прочитать снова — только заменить или удалить.
В запуск учётные данные подставляются в самый момент выдачи задания, прямо в процесс исполнителя. Они никогда не попадают в исходники, журналы, запросы к модели и выгрузку. Действия читают их как ctx.vars.NAME, причём учётные данные и переменная не могут называться одинаково. Если нужных данных не окажется, действие честно упадёт с ошибкой, а не выполнится с пустым паролем.
Есть замена значения, удаление и смена ключа шифрования: создаётся новое поколение ключа, и все сохранённые данные всех проектов перешифровываются под него. Запуски, которые уже идут, завершатся старым ключом. Отменить смену нельзя.
Виды учётных данных: пароль, токен, заголовок и «другое» — на случай нестандартного.
Переменные
Переменные — это наборы обычных значений, не секретов: например, имя тестового пользователя. В одном наборе может быть несколько значений через запятую; действует всегда первое, остальные — запас на ручную замену. Правило «побеждает первое» работает железно, чтобы результат прогона не зависел от случая.
Когда записи много, оба вида значений пригодятся. Но для всего, что является секретом — пароля, ключа, токена, — используйте именно учётные данные: только они шифруются и не покидают продукт.
Подготовка и очистка
У проекта можно задать действия «до» и «после» любого теста — например, вход в систему и выход из неё. Первые выполняются перед шагами теста, вторые — после. Очистка выполняется даже тогда, когда шаг теста упал: иначе следующий запуск начнётся с грязного состояния.
Если тест объявляет свои списки подготовки и очистки, он полностью заменяет проектные — они не смешиваются. Пустой объявленный список — это осознанный отказ от фазы, а не «возьмите проектные». Свои списки теста живут в его файле и правятся в конструкторе тестов; сохранение проектных требует роли администратора.
Защита рабочего контура
В настройках проекта можно перечислить рабочие хосты — адреса, которые обход браузером не тронет без явного разрешения. Так обход, запущенный по ошибке, не пойдёт гулять по рабочему сайту: сначала нужно осознанно снять защиту.
Дальше: кто из людей что может в проекте, — в разделе Пользователи и роли.