up

tests/venue/README.md

@@ -62,7 +62,8 @@ python3 tests/venue/flow.py --apply --browser
 (`offline`). Проверяются клавиатурный focus, отказ на ход с сохранением ввода,
 блокировка повторной отправки и кнопки на паузе при уже введённом коде.
 Локальный HTTP-прокси переключает один публичный адрес между двумя реальными
-backend, имитируя смену DNS; API-ответы не подменяются. Тестовые ссылки, ZIP,
+backend, имитируя смену DNS; Игровые API-ответы не подменяются; ошибки, пустой список и состояния Wi-Fi
+панели мониторинга дополнительно проверяются управляемыми ответами GetDevices. Тестовые ссылки, ZIP,
 профиль Firefox и сборки остаются во временном каталоге до конца прогона.
 
 `--results` дополнительно проверяет этап 9: серверный сервис собирает ZIP
@@ -155,3 +156,52 @@ Firefox проверяет игрока, организатора и экран
 ошибку/восстановление и отбрасывание ответов после смены игры, ухода и unmount.
 Временные границы connected остаются в тестах сервиса этапа 12 с управляемыми
 часами; клиент пороги не пересчитывает.
+
+
+## Wi-Fi и нагрузка (этапы 14–15)
+
+```sh
+python3 tests/venue/load.py
+python3 tests/venue/flow.py --apply --browser
+```
+
+`load.py` использует тот же одноразовый стенд без WAN: 100 виртуальных UUID,
+25 новых команд по четыре браузера, 60 секунд. Каждый профиль отправляет
+heartbeat раз в 20 секунд и читает историю раз в 5 секунд; по одному профилю
+команды выполняют два хода и сохраняют ответ. Организатор опрашивает состояние
+раз в 5 секунд. Проверяются ровно 100 доступных устройств, 50 сохранённых ходов,
+25 ответивших команд и отсутствие HTTP-ошибок. Отчёт содержит число запросов,
+p50/p95/max; p95 ≤ 2 секунды — бюджет этого теста, не обещание для любого железа.
+Запросы идут прямо к backend по HTTP: DNS, HTTPS и прокси проверяются отдельно
+`dns.py --docker` и `https.py --docker`. Это нагрузка backend, не проверка радио.
+
+Go-тесты адаптера Cudy проверяют вход/продление сессии, ограничение URL/ответа,
+разбор обеих полос, отсутствующий сигнал, ошибку при неизвестной разметке,
+атомарный снимок, свежесть с управляемыми часами и venue/prod/роли. Firefox
+проверяет MAC/IP/диапазон/dBm, устаревание, ошибку и отсутствие сигнала; эти
+состояния Wi-Fi задаются fixture. Отдельно адаптер проверен чтением настоящего
+TR3000 V1 2.5.27-20260804-183625 без изменения настроек роутера.
+
+### Аппаратная контрольная точка этапа 15
+
+После согласованного обновления реальной площадки, только на тестовой игре:
+
+1. Включить сбор Cudy по корневому README; отключить WAN и мобильные данные.
+   На Android/iPhone открыть прежние домены, проверить DNS и доверенный HTTPS.
+2. Подключить 100 настоящих Wi-Fi-устройств (несколько вкладок одного профиля
+   не заменяют устройства); открыть игру 25 командами, держать нагрузку
+   минимум 60 секунд, выполнять ходы и сохранять ответы.
+3. Сверить клиентов Cudy с панелью, диапазоны и доступный сигнал; пройти края
+   и проблемные зоны площадки, проверить материалы и действия в каждой зоне.
+   MAC/UUID не сопоставлять предположениями; «Нет связи» относится к heartbeat.
+4. Проверить паузу/продолжение, перезапуск venue и повторную регистрацию
+   браузеров, смену контекста/несколько вкладок; убедиться, что панели в prod нет.
+5. Временно остановить сборщик: через 30 секунд снимок должен устареть,
+   прежние данные и время остаться видимыми. Запустить снова и проверить
+   восстановление. Потерю API и восстановление проверить без потери снимка.
+6. Завершить игру, вернуть ZIP на источник, проверить результаты и прежние
+   ссылки. Зафиксировать оборудование, число клиентов, длительность,
+   задержки/ошибки и покрытие; сообщить результат для приёмки ED-029.
+
+Автоматические проверки не заменяют эту приёмку. Пока она не подтверждена,
+ED-029 остаётся `IN_PROGRESS`. Фактический ZIP 1 ГиБ также не проверен.