113 lines
5.8 KiB
Markdown
113 lines
5.8 KiB
Markdown
# 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
|