wiki/tasks/flightradar24/docs/TEST_PLAN.md

FR24 / RTL-SDR test plan

1. Цель

Проверить, что локальный RTL-SDR ingest-контур работает корректно, устойчиво восстанавливается после сбоев и отдаёт данные в noisemap / карту без потерь и без разъезда состояния.

2. Уровни тестирования

2.1 Smoke tests

Быстрая проверка, что стек вообще поднялся:

• Docker Compose стартует без ошибок
• postgres доступен внутри сети compose
• capture стартует и видит RTL-SDR
• preprocess стартует и подключается к БД
• api отвечает на health endpoint

2.2 Integration tests

Проверка связности компонентов:

• capture пишет записи в raw_packets
• preprocess читает raw_packets и обновляет processing_state
• preprocess создаёт/обновляет flights, tracks, track_points
• api читает данные из БД и отдаёт их в формате, нужном для карты
• PostGIS-функции работают на геометриях

2.3 Recovery tests

Проверка восстановления после сбоя:

• остановить preprocess
• продолжить запись сырья
• поднять preprocess
• убедиться, что он автоматически догоняет пропущенный диапазон
• проверить, что overlap не даёт дублей

2.4 Retention tests

Проверка хранения сырья:

• raw-данные доступны не менее 3 дней
• после истечения retention raw-слой чистится автоматически
• обработанные данные не удаляются вместе с raw без причины

2.5 Resource tests

Проверка в рамках лимитов VM:

• CPU не выходит за разумный потолок при live-режиме
• RAM не утекает при длительном прогоне
• диск не растёт неконтролируемо
• логирование и БД не съедают всё место

3. Минимальный smoke checklist

• VM загружается
• USB passthrough RTL-SDR работает
• docker compose up -d успешен
• postgres живой и PostGIS включён
• capture видит устройство
• preprocess пишет state
• api отвечает /health
• хотя бы одна тестовая запись проходит путь raw → core

4. Минимальный integration checklist

• raw packet попадает в raw_packets
• создаётся/обновляется captures
• создаётся/обновляется aircraft
• создаётся/обновляется flights
• создаются track_points
• обновляется tracks
• processing_state отражает последний checkpoint
• api возвращает данные для визуализации

5. Recovery сценарий

Сценарий A: preprocess down

1. Остановить preprocess
2. Записать часть сырья
3. Запустить preprocess
4. Проверить, что недостающий диапазон дочитан
5. Проверить отсутствие дублей на overlap

Сценарий B: temporary DB restart

1. Перезапустить postgres
2. Проверить, что контейнеры восстанавливают соединение
3. Проверить, что capture и preprocess не теряют состояние навсегда

Сценарий C: capture restart

1. Перезапустить capture
2. Проверить, что new live поток продолжает попадать в raw слой
3. Проверить, что recovery не ломается после краткой паузы

6. Data correctness checks

• координаты в допустимых диапазонах
• время монотонно внутри одного трека/сессии там, где это ожидается
• track_points привязаны к правильному flight/track
• tracks и flights не расходятся по времени и объёму
• геометрии PostGIS валидны

7. Performance checks

• нет резкого роста latency на ingest
• процесс recovery не блокирует live ingest
• API отвечает в приемлемое время на типовые запросы карты
• индексы реально используются, а не декоративны

8. What must be proven before handoff to Слава

Перед передачей Славе должны быть подтверждены:

• compose stack поднимается и переживает restart
• USB RTL-SDR стабильно доступен в VM
• raw retention работает
• recovery работает
• карта может читать данные из API
• БД и схема не вываливаются за лимиты VM
• базовые smoke/integration tests пройдены

9. Что должен вернуть Dev-агент

В отчёте Dev-агента должны быть:

• список тестов, которые он запускал
• команды, которыми он тестировал
• результаты smoke/integration/recovery tests
• замечания по рискам
• список того, что требует реального RTL-SDR железа для final verification