Piano di test in dev (Fase 5)
Da eseguire su Coolify dev con i box di test (T1.1). Ogni caso va eseguito per ogni combinazione indicata e il risultato annotato (✅ / ❌ con nota / ➖ non applicabile). Niente dati dei clienti nelle note.
Combinazioni: A = v3 + box 3.2.9 · B = v3 + box della linea stage · C = v3 + box 3.1.9 (se disponibile) · R = riferimento v2 (dev Flask) + box 3.2.9.
1. Ciclo di vita del box
| # |
Caso |
Come si verifica |
A |
B |
C |
| 1.1 |
Registrazione nuovo box |
installer → compare in "nuove installazioni" → completamento dal pannello |
|
|
|
| 1.2 |
Stato periodico |
il box compare online nel pannello con versione, telecamere, carico |
|
|
|
| 1.3 |
Offline |
staccare il box: diventa offline entro intervallo + 20 s, una notifica |
|
|
|
| 1.4 |
Ritorno online |
riattaccare: torna online, una notifica |
|
|
|
| 1.5 |
Errori |
provocare un errore sul box: arriva a common/installation/error e si vede nel pannello |
|
|
|
| 1.6 |
Log |
il box invia i log (receive_log): visibili dove previsto |
|
|
|
2. Comandi dal pannello
| # |
Caso |
A |
B |
C |
| 2.1 |
Inserimento / disinserimento (con e senza snapshot al cliente) |
|
|
|
| 2.2 |
Stato alarm_in (GET e POST) |
|
|
|
| 2.3 |
Suono sulla tromba, configurazione audio, stop |
|
|
|
| 2.4 |
Privacy mode su una telecamera |
|
|
|
| 2.5 |
Azioni di gruppo sulle telecamere |
|
|
|
| 2.6 |
Riavvio Frigate, wrapper, box |
|
|
|
| 2.7 |
Backup e restore della configurazione |
|
|
|
| 2.8 |
Lettura log dei container |
|
|
|
| 2.9 |
Comando asincrono lungo (async/callback) |
|
|
|
| 2.10 |
Informazioni cliente da BSQ |
|
|
|
| 2.11 |
Log ed errori delle richieste (request/logs, request/erros) |
|
|
|
| 2.12 |
Configurazione IO (solo B) |
➖ |
|
➖ |
| 2.13 |
Cluster master/slave (solo B, se disponibili 2 box): registrazione dello slave, MAC derivato <mac>-01, inserimento propagato con conferme, comando inoltrato a un solo slave, pianificazione solo sul master, slave offline durante un inserimento (dettagli) |
➖ |
|
➖ |
| 2.14 |
Pannello senza PIN: nessun errore |
|
|
|
3. Video
| # |
Caso |
A |
B |
C |
| 3.1 |
Live dal pannello |
|
|
|
| 3.2 |
Live da qAlarm |
|
|
|
| 3.3 |
Live Protexia: avvio dal player interno, video in movimento, fullscreen/ritorno, stop e riconnessione; nessuna apertura browser (D27). Verificare destinazione e compatibilita JWT del percorso attuale BSQ, ancora aperte (D28), e rifiuto di accesso a impianto non autorizzato. |
|
|
|
| 3.5 |
Comandi dall'app Protexia passando da api.bsq (inserimento, privacy mode, suono, snapshot) |
|
|
|
| 3.4 |
Il video va all'OME dev (dopo T2.2) |
|
|
|
4. Eventi e qAlarm
| # |
Caso |
A |
B |
C |
| 4.1 |
Evento di intrusione → stream event_stream → qAlarm in tempo reale con foto |
|
|
|
| 4.2 |
Ogni evento compare una sola volta (anche con 2 istanze del midserver) |
|
|
|
| 4.3 |
Aggiornamenti successivi della stessa review di Frigate |
|
|
|
| 4.4 |
Notifica all'app Protexia |
|
|
|
| 4.5 |
Chat operatore ↔ cliente (singola e di gruppo) |
|
|
|
| 4.6 |
Barra degli impianti offline aggiornata (T4.9) |
|
|
|
| 4.7 |
Worker riavviato a metà: gli eventi pendenti vengono recuperati (T4.7) |
|
|
|
5. Robustezza
| # |
Caso |
Atteso |
| 5.1 |
Redeploy del midserver con loop di richieste ogni 0,2 s |
nessun 502/503 |
| 5.2 |
Eventi MQTT inviati durante il redeploy |
nessuno perso, nessuno doppio |
| 5.3 |
Kill dell'istanza leader del lock |
un'altra istanza subentra entro il TTL |
| 5.4 |
docker compose down + up dei servizi con stato |
Redis e MySQL intatti |
| 5.5 |
Riavvio di Mosquitto |
box e midserver si ricollegano da soli |
| 5.6 |
Redis irraggiungibile per 1 minuto |
il midserver si riprende senza intervento |
| 5.7 |
Ripristino da dump (T5.3) |
dati coerenti, tempo misurato |
6. Accettazione della centrale (qAlarm)
Da definire con un operatore (T1.4): le azioni che fa ogni notte, in ordine, con il tempo che impiega oggi su Telegram e quello su qAlarm.