Pastein: Инструкция для пользователей Что проверяют автотесты Что считается набором данных (dataset / suite) Какие наборы

Загрузка данных
Инструкция для пользователей
Что проверяют автотесты
Что считается набором данных (dataset / suite)
Какие наборы данных покрыты сейчас
Запуск из пайпа (основной сценарий)
Запуск тестов на режимы СОУ 
Запуск тестов на отбраковки
Как запустить только один тест (точечно)
Где смотреть результат
Как добавить новый dataset (покрытие "в ширину")
Инструкция для разработчиков
Краткое описание архитектуры
Жизненный цикл прогона: setup → autotests → teardown
Коллекция тестов (pytest collection)
Фильтрация по --suites и отключённые тесты
Группировка по suite и расчёт длительности имитатора
Setup/teardown выполняются при смене набора данных
Инфраструктурная внутрянка
Компоненты (кто за что отвечает)
Что именно приходит из datasets в инфраструктуру
Поток setup (пошагово)
Поток teardown 
Переменные окружения (инфраструктурный минимум)
Типовые точки отказа инфраструктуры
Как устроены WS контракты (sync и async=subscribe)
WebSocketClient: SignalR invocation
Утилиты для сценариев
Парсинг сообщений
Где "лежит покрытие": datasets и scenarios
Покрытие "в ширину" = datasets
Покрытие "в глубину" = scenarios
Как добавить новый dataset (suite)
Как добавить новую проверку (новый тест/сценарий)
Добавить сценарий
Добавить pytest‑тест
Подключить маркеры
Teardown и выгрузка отчёта
Схема
Инструкция для пользователей

Пользователь автотестов - это тестировщик, который:
- запускает автотесты из CI/CD (пайплайн) на своём стенде
- может найти результат в TestOps (кейсы + testruns) - расширяет покрытие “в ширину”, добавляя datasets под новые наборы данных (при наличии исходных данных/архива) в TestOps
Данные автотестов: Z:\УАСУТПДП\Общее для работников\СОУ\Данные\Данные автотестов

Что проверяют автотесты
Автотесты имитируют запросы фронта в api-gateway по WebSocket (SignalR, messagepack) и проверяют ответы бэка.

Ключевое:
- мы проверяем те же "контракты", которые использует UI, только без кликов.
- проверки проходят только на контурах dev - test
- проверки можно проводить только на стенде, который настроен на чтение конфигурации из файла


Что считается набором данных (dataset / suite)
Один dataset = один файл конфигурации в test_config/datasets/ (например select_6.py).
Dataset определяет:
- какой архив данных имитатора использовать (archive_name)
- когда именно выполнять каждую проверку (offset, минуты)
- какие проверки включены (какие тесты "активны")
- входные параметры для тестов
- ожидаемый результат для всех тестов в том числе (координата/объём/окно времени)


Какие наборы данных покрыты сейчас
Текущий список suites (по файлам test_config/datasets/):
select_*.py:
  - Select_4_tn3_215km_113 — режим остановленной перекачки (STOPPED), 1 утечка
  - Select_6_tn3_56km_113 — стационар, 1 утечка 
  - Select_7_tn3_130km_113 — стационар, 1 утечка + несколько соседних ДУ
  - Select_11_tn3_nps_56 — стационар, 1 утечка на нпс
  - Select_17_tn3_75km_417 — 1 утечка (больший объём/другие окна времени)
  - Select_19_20_tn3_75_181km_649 — 2 утечки (multi‑leak), есть доп. тест на переход в нестационар
  - Select_21_tn3_75km_400 — нестационар, 1 утечка + несколько соседних ДУ
  - Select_22_tn3_75km_375 — нестационар, 1 утечка + несколько соседних ДУ
  - Select_24_tn3_181km_1900 — нестационар, 1 утечка + тесты на окончание утечки
  - Select_25_tn3_6km_56 — стационар, 1 утечка + несколько соседних ДУ
  - Select_32_tn3_229km_56 — стационар, 1 утечка + несколько соседних ДУ

case_masking_du.py:
  - Case_masking_du — Отбор select 6 + проверка маскирования ДУ + тесты на маскирование и имитацию

Проверка режимов работы СОУ:
lds_status_regress_bik.py:
  - Lds_status_regress_bik — Режим МТ: стационар. "Ухудшенные характеристики" по причинам связанным с БИК

lds_status_regress_inflow.py:
  - Lds_status_regress_inflow — Режим МТ: стационар. Основной сценарий проверки режимов работы СОУ

lds_status_regress_stopping.py:
  - Lds_status_regress_stopping — Режим МТ: остановка. Проверки режимов работы СОУ

Проверка отбраковок:
is_rejected_regress.py:
  - is_rejected_regress — Набор для проверки отбраковок.


Запуск из пайпа (основной сценарий)
Старт пайпа на ветке develop New pipeline · LDS / lds-autotests · GitLab

Обязательная переменная
- STAND_NAME — имя стенда, на котором запускаем (например dev1, test3 и т.п.).
Это влияет на:
- адреса стенда (внутренний маппинг)
- подготовку окружения (контейнеры, redis)
- то, какой api-gateway будет использован для WS

### Вариант A: запуск "смок" наборов по suite через SMOKE_PATH
В пайпе задаётся переменная SMOKE_PATH, в которую надо просто вписать название вашего suite - Select_6_tn3_56km_113
Под капотом SMOKE_PATH спрятана команда "pytest tests/test_smoke.py --suites="

- пример:
SMOKE_PATH=Select_6_tn3_56km_113
STAND_NAME=test4

- пример:
SMOKE_PATH=Case_maskig_du
STAND_NAME=test4


Важно про --suites:
- можно одно значение или список через запятую select_6,select_25 (на данный момент не более 4х наборов по 60-65 минут в одном запуске)
- сравнение делается по подстроке (case-insensitive)

### Вариант B: Запуск остальных наборов TEST_PATH + альтернативный способ запустить "смок" наборы
TEST_PATH — это полная команда, у которой под капотом только "pytest ":
- пример (запуск конкретного "смок" suite):
TEST_PATH=tests/test_smoke.py --suites=Select_19_20_tn3_75_181km_649
STAND_NAME=test4


Когда нужен TEST_PATH:
- если надо запустить один тест (точечно)
- если надо комбинировать --suites и -k
- если ваш модуль с тестами не test_smoke.py

Запуск тестов на режимы СОУ 
запуск тестов в течении:

STAND_NAME=test4
TEST_PATH=tests/test_lds_status_regress.py --suites=Lds_status_regress_in_flow

запуск тестов на БИК:

STAND_NAME=test4
TEST_PATH=tests/test_lds_status_regress.py --suites=Lds_status_regress_bik


запуск тестов остановки:

STAND_NAME=test4
TEST_PATH=tests/test_lds_status_regress.py --suites=Lds_status_regress_stopping

Запуск тестов на отбраковки
STAND_NAME=test4
TEST_PATH=tests/test_is_rejected_regress.py --suites=is_rejected_regress

Как запустить только один тест (точечно)
nodeid pytest
Suite-level тест:
TEST_PATH=tests/test_smoke.py::TestSuiteScenarios::test_lds_status_initialization_out[Select_6_tn3_56km_113]

Leak-level тест (для multi‑leak есть суффикс _leak_N):
TEST_PATH=tests/test_smoke.py::TestLeakScenarios::test_leaks_content[Select_19_20_tn3_75_181km_649_leak_1] - но мы это не тестировали

через -k
- pytest tests/test_smoke.py --suites=select_6 -k "test_basic_info"
- pytest tests/test_smoke.py --suites=select_19_20 -k "test_leaks_content and leak_2"


Где смотреть результат
TestOps: тест‑кейсы (TMS)
В TestOps вы находите:
- тест‑кейс по test_case_id (он задан в datasets)
- описание, шаги, вложения (например архивы данных)

TestOps: testruns (Список отчётов) 
В testruns вы смотрите:
- статус прогона (passed/failed)
- шаги Allure и вложения (включая диагностические значения)
- группировку по suite (набору данных)
Больше возможностей при регистрации:
