Test di lunga durata - AWS IoT Core

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Test di lunga durata

I test di lunga durata sono una nuova suite di test che monitorano il comportamento di un dispositivo quando funziona per periodi di tempo più lunghi. Rispetto all'esecuzione di singoli test che si concentrano sui comportamenti specifici di un dispositivo, il test di lunga durata esamina il comportamento del dispositivo in una varietà di scenari del mondo reale nel corso del ciclo di vita del dispositivo. Device Advisor orchestra i test nell'ordine più efficiente possibile. Il test genera risultati e log, incluso un log di riepilogo con metriche utili sulle prestazioni del dispositivo durante il test.

MQTTtest case di lunga durata

Nel caso di test di MQTT lunga durata, il comportamento del dispositivo viene inizialmente osservato in scenari positivi come MQTT Connect, Subscribe, Publish e Reconnect. Quindi, il dispositivo viene osservato in diversi scenari di errore complessi come MQTT Reconnect Backoff, Long Server Disconnect e Intermittent Connectivity.

MQTTflusso di esecuzione di test case di lunga durata

Esistono tre fasi nell'esecuzione di un test case di MQTT lunga durata:

L' "Esecuzione del test di MQTT lunga durata» che mostra l'esecuzione dei test di base, l'esecuzione dei test avanzati e il tempo di esecuzione aggiuntivo.

Esecuzione di test di base

In questa fase, il test case esegue semplici test in parallelo. Il test verifica se il dispositivo dispone delle operazioni selezionate nella configurazione.

Il set di test di base può includere quanto specificato di seguito, in base alle operazioni selezionate.

CONNECT

Questo scenario convalida se il dispositivo è in grado di stabilire una connessione con il broker.

Il flusso di connessione di base che include un dispositivo che invia un CONNECT messaggio e Broker risponde con un CONNACK messaggio con un codice di ritorno corretto.

PUBLISH

Questo scenario convalida se il dispositivo pubblica tramite il broker.

QoS 0

Questo test case convalida se il dispositivo invia un messaggio PUBLISH al broker durante una pubblicazione con QoS 0. Il test non attende che il messaggio PUBACK venga ricevuto dal dispositivo.

Il flusso PUBLISH QoS 0 che include un dispositivo che invia un PUBLISH messaggio con livello QoS 0.
QoS 1

In questo test case, si prevede che il dispositivo invii due messaggi PUBLISH al broker con QoS 1. Dopo il primo messaggio PUBLISH, il broker attende per un massimo di 15 secondi prima di rispondere. Il dispositivo deve riprovare a inviare il messaggio PUBLISH originale con lo stesso identificatore di pacchetto entro 15 secondi. In tal caso, il broker risponde con un messaggio PUBACK e il test viene convalidato. Se il dispositivo non riprova a inviare PUBLISH, il PUBACK originale viene inviato al dispositivo e il test viene contrassegnato come Pass with warnings (Superato con avvertenze), insieme a un messaggio di sistema. Durante l'esecuzione del test, se il dispositivo perde la connessione e si riconnette, lo scenario di test viene ripristinato senza errori e il dispositivo deve eseguire nuovamente i passaggi dello scenario di test.

Il flusso PUBLISH QoS 1 che include un dispositivo che invia un PUBLISH messaggio con livello QoS 1 e interazioni multiple con il broker.

SUBSCRIBE

Questo scenario convalida se il dispositivo esegue la sottoscrizione tramite il broker.

QoS 0

Questo test case convalida se il dispositivo invia un messaggio SUBSCRIBE al broker durante una sottoscrizione con QoS 0. Il test non attende che il dispositivo riceva un SUBACK messaggio.

Il flusso SUBSCRIBE QoS 0 che include un dispositivo che invia un SUBSCRIBE messaggio con livello QoS 0 e un broker che risponde con un SUBACK messaggio e il codice Success Maximum QoS 0.
QoS 1

In questo test case, si prevede che il dispositivo invii due messaggi SUBSCRIBE al broker con QoS 1. Dopo il primo messaggio SUBSCRIBE, il broker attende per un massimo di 15 secondi prima di rispondere. Il dispositivo deve riprovare a inviare il messaggio SUBSCRIBE originale con lo stesso identificatore di pacchetto entro 15 secondi. In tal caso, il broker risponde con un messaggio SUBACK e il test viene convalidato. Se il dispositivo non riprova a inviare SUBSCRIBE, il SUBACK originale viene inviato al dispositivo e il test viene contrassegnato come Pass with warnings (Superato con avvertenze), insieme a un messaggio di sistema. Durante l'esecuzione del test, se il dispositivo perde la connessione e si riconnette, lo scenario di test viene ripristinato senza errori e il dispositivo deve eseguire nuovamente i passaggi dello scenario di test.

Il flusso SUBSCRIBE QoS 1 che include un dispositivo che invia un SUBSCRIBE messaggio con livello QoS 1 e interazioni multiple con il broker.

RECONNECT

Questo scenario convalida se il dispositivo si riconnette al broker dopo che il dispositivo è stato disconnesso da una connessione. Device Advisor non disconnette il dispositivo se in precedenza si è connesso più di una volta durante la suite di test. Invece, contrassegnerà il test come Pass (Superato).

Il RECONNECT flusso tra DUT e il broker.

Esecuzione di test avanzati

In questa fase, il test case esegue test più complessi in serie per verificare se il dispositivo segue le best practice. Questi test avanzati sono disponibili per la selezione e possono essere disattivati se non necessari. Ogni test avanzato dispone del proprio valore di timeout in base a ciò che lo scenario richiede.

RETURNPUBACKSU QoS 1 SUBSCRIPTION

Nota

Selezionare questo scenario solo se il dispositivo è in grado di eseguire sottoscrizioni QoS 1.

Questo scenario convalida se il dispositivo restituisce un messaggio PUBACK dopo che esegue la sottoscrizione a un argomento e riceve un messaggio PUBLISH dal broker.

Il SUBSCTIPTION flusso RETURN PUBACK ON QoS 1 tra DUT e il broker.

RECEIVE LARGE PAYLOAD

Nota

Selezionare questo scenario se il dispositivo è in grado di eseguire sottoscrizioni QoS 1.

Questo scenario convalida se il dispositivo risponde con un messaggio PUBACK dopo aver ricevuto un messaggio PUBLISH dal broker per un argomento QoS 1 con un payload di grandi dimensioni. Il formato di payload previsto può essere configurato utilizzando l'opzione LONG_PAYLOAD_FORMAT.

Il RECEIVE LARGE PAYLOAD flusso tra DUT e il broker.

PERSISTENT SESSION

Nota

Selezionare questo scenario se il dispositivo è in grado di eseguire sottoscrizioni QoS 1 e mantenere una sessione persistente.

Questo scenario convalida il comportamento del dispositivo nel mantenimento di sessioni persistenti. Il test convalida quando vengono soddisfatte le seguenti condizioni:

  • Il dispositivo si connette al broker con una sottoscrizione QoS 1 attivo e sessioni persistenti abilitate.

  • Il dispositivo si disconnette dal broker durante la sessione.

  • Il dispositivo si riconnette al broker e riprende le sottoscrizioni agli argomenti trigger senza effettuare nuovamente la sottoscrizione a questi argomenti in maniera esplicita.

  • Il dispositivo riceve i messaggi archiviati dal broker per gli argomenti sottoscritti e funziona come previsto.

Per ulteriori informazioni sulle sessioni AWS IoT persistenti, consulta Utilizzo delle sessioni MQTT persistenti.

Il PERSISTENT SESSION flusso tra DUT e il broker.

KEEP ALIVE

Questo scenario cpmvalida se il dispositivo si disconnette dopo che non riceve una risposta ping dal broker. È necessario che nella connessione sia configurato timer keep-alive valido. Come parte di questo test, il broker blocca tutte le risposte inviate per i messaggi PUBLISH, SUBSCRIBE e PINGREQ. Verifica inoltre se il dispositivo sottoposto a test disconnette la MQTT connessione.

Il KEEP ALIVE flusso tra DUT e il broker.

INTERMITTENT CONNECTIVITY

Questo scenario convalida se il dispositivo può riconnettersi al broker dopo che scollega il dispositivo a intervalli casuali per un periodo di tempo casuale.

Il INTERMITTENT CONNECTIVITY flusso tra DUT e il broker.

RECONNECT BACKOFF

Questo scenario convalida se il dispositivo dispone di un meccanismo di backoff implementato quando il broker si disconnette più volte. Device Advisor segnala il tipo di backoff come esponenziale, jitter, lineare o costante. Il numero di tentativi di backoff è configurabile utilizzando l'opzione BACKOFF_CONNECTION_ATTEMPTS. Il valore predefinito è 5. Il valore è configurabile tra 5 e 10.

Per superare questo test, si consiglia di implementare il meccanismo Exponential Backoff And Jitter (Backoff esponenziale e jitter) sul dispositivo in fase di test.

Il RECONNECT BACKOFF flusso tra DUT e il broker.

LONG SERVER DISCONNECT

Questo scenario convalida se il dispositivo può riconnettersi dopo che il broker scollega il dispositivo per un lungo periodo di tempo (fino a 120 minuti). L'ora di disconnessione del server può essere configurata utilizzando l'opzione LONG_SERVER_DISCONNECT_TIME. Il valore predefinito è di 120 minuti. Questo valore è configurabile da 30 a 120 minuti.

Il LONG SERVER DISCONNECT flusso tra DUT e il broker.

Tempo di esecuzione aggiuntivo

Il tempo di esecuzione aggiuntivo è il tempo che il test attende dopo il completamento di tutti i test precedenti e prima di terminare il test case. I clienti utilizzano questo periodo di tempo aggiuntivo per monitorare e registrare tutte le comunicazioni tra il dispositivo e il broker. Il tempo di esecuzione aggiuntivo può essere configurato utilizzando l'opzione ADDITIONAL_EXECUTION_TIME. Per impostazione predefinita, questa opzione è impostata su 0 minuti e può essere compresa tra 0 e 120 minuti.

MQTTopzioni di configurazione del test di lunga durata

Tutte le opzioni di configurazione fornite per il test di MQTT lunga durata sono opzionali. Sono disponibili le seguenti opzioni:

OPERATIONS

L'elenco delle operazioni eseguite dal dispositivo, ad esempio CONNECT, PUBLISH e SUBSCRIBE. Il test case esegue scenari in base alle operazioni specificate. Le operazioni non specificate sono considerate valide.

{ "OPERATIONS": ["PUBLISH", "SUBSCRIBE"] //by default the test assumes device can CONNECT }
SCENARIOS

In base alle operazioni selezionate, il test case esegue scenari per convalidare il comportamento del dispositivo. Esistono due tipi di scenari:

  • Gli scenari di base sono semplici test che verificano se il dispositivo è in grado di eseguire le operazioni selezionate in precedenza come parte della configurazione. Questi sono preselezionati in base alle operazioni specificate nella configurazione. Non è richiesto alcun ulteriore input nella configurazione.

  • Gli scenari avanzati sono scenari più complessi che vengono eseguiti rispetto al dispositivo per convalidare se il dispositivo segue le best practice quando soddisfa le condizioni del mondo reale. Questi sono opzionali e possono essere superati come una serie di scenari per l'input di configurazione della suite di test.

{ "SCENARIOS": [ // list of advanced scenarios "PUBACK_QOS_1", "RECEIVE_LARGE_PAYLOAD", "PERSISTENT_SESSION", "KEEP_ALIVE", "INTERMITTENT_CONNECTIVITY", "RECONNECT_BACK_OFF", "LONG_SERVER_DISCONNECT" ] }
BASIC_TESTS_EXECUTION_TIME_OUT:

Il periodo di tempo massimo che il test case attende per il completamento di tutti i test di base. Il valore predefinito è di 60 minuti. Questo valore è configurabile da 30 a 120 minuti.

LONG_SERVER_DISCONNECT_TIME:

Il tempo richiesto dal test case per scollegare e ricollegare il dispositivo durante il test Disconnessione server di lunga durata. Il valore predefinito è di 60 minuti. Questo valore è configurabile da 30 a 120 minuti.

ADDITIONAL_EXECUTION_TIME:

La configurazione di questa opzione fornisce una finestra temporale dopo il completamento di tutti i test, per monitorare gli eventi tra il dispositivo e il broker. Il valore predefinito è di 0 minuti. Questo valore è configurabile da 0 a 120 minuti.

BACKOFF_CONNECTION_ATTEMPTS:

Questa opzione configura il numero di volte in cui il dispositivo viene disconnesso dal test case. Viene utilizzato dal test Riconnessione backoff. Il valore predefinito è 5. Questo valore è configurabile da 5 a 10.

LONG_PAYLOAD_FORMAT:

Il formato del payload del messaggio atteso dal dispositivo quando il test case viene pubblicato in un argomento QoS 1 sottoscritto dal dispositivo.

APIdefinizione del test case:

{ "tests":[ { "name":"my_mqtt_long_duration_test", "configuration": { // optional "OPERATIONS": ["PUBLISH", "SUBSCRIBE"], "SCENARIOS": [ "LONG_SERVER_DISCONNECT", "RECONNECT_BACK_OFF", "KEEP_ALIVE", "RECEIVE_LARGE_PAYLOAD", "INTERMITTENT_CONNECTIVITY", "PERSISTENT_SESSION", ], "BASIC_TESTS_EXECUTION_TIMEOUT": 60, // in minutes (60 minutes by default) "LONG_SERVER_DISCONNECT_TIME": 60, // in minutes (120 minutes by default) "ADDITIONAL_EXECUTION_TIME": 60, // in minutes (0 minutes by default) "BACKOFF_CONNECTION_ATTEMPTS": "5", "LONG_PAYLOAD_FORMAT":"{"message":"${payload}"}" }, "test":{ "id":"MQTT_Long_Duration", "version":"0.0.0" } } ] }

MQTTregistro di riepilogo dei casi di test di lunga durata

Il test case di MQTT lunga durata dura più a lungo rispetto ai normali casi di test. Durante l'esecuzione, viene fornito un log di riepilogo separato, contenente eventi importanti come connessioni dispositivo, pubblicazione e sottoscrizione. I dettagli includono l'oggetto del test, gli elementi esclusi dal test e gli eventuali errori. Alla fine del log, il test include un riepilogo di tutti gli eventi che si sono verificati durante l'esecuzione del test case. Questo include:

  • Timer Keep Alive configurato sul dispositivo.

  • Flag sessione persistente configurato sul dispositivo.

  • Il numero di connessioni del dispositivo durante l'esecuzione del test.

  • Il tipo di riconnessione backoff del dispositivo, se convalidato per il test di riconnessione backoff.

  • Gli argomenti su cui il dispositivo ha pubblicato durante l'esecuzione del test case.

  • Gli argomenti sottoscritti dal dispositivo, durante l'esecuzione del test case.