MQTT

CONNECT, e DISCONNECT RECONNECT

«Dispositivo inviato CONNECT a AWS IoT Core (Happy case)»

Verifica che il dispositivo sottoposto a test invii una CONNECT richiesta.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.

"tests":[
   {
      "name":"my_mqtt_connect_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",   // in seconds
      },
      "test":{
         "id":"MQTT_Connect",
         "version":"0.0.0"
      }
   }
]      

«Il dispositivo può tornare PUBACK a un argomento arbitrario per QoS1"

Questo test case verificherà se il dispositivo (client) può restituire un PUBACK messaggio se ha ricevuto un messaggio di pubblicazione dal broker dopo essersi iscritto a un argomento con QoS1.

Il contenuto e la dimensione del payload sono configurabili per questo test case. Se la dimensione del payload è configurata, Device Advisor sovrascriverà il valore del contenuto del payload e invierà un payload predefinito al dispositivo con le dimensioni desiderate. La dimensione del payload è un valore compreso tra 0 e 128 KB e non può superare i 128 KB. AWS IoT Core rifiuta le richieste di pubblicazione e di connessione superiori a 128 KB, come illustrato nella pagine Limiti e quote del protocollo e del broker di messaggi AWS IoT Core.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti. PAYLOAD_SIZE può essere configurato su un valore compreso tra 0 e 128 kilobyte. La definizione della dimensione di un payload sostituisce il contenuto del payload poiché Device Advisor invierà al dispositivo un payload predefinito con le dimensioni specificate.

"tests":[                            
{
        "name":"my_mqtt_client_puback_qos1",
        "configuration": {
            // optional:"TRIGGER_TOPIC": "myTopic",
            "EXECUTION_TIMEOUT":"300", // in seconds
            "PAYLOAD_FOR_PUBLISH_VALIDATION":"custom payload",
            "PAYLOAD_SIZE":"100" // in kilobytes
        },
        "test": {
            "id": "MQTT_Client_Puback_QoS1",
            "version": "0.0.0"
        }
    }
]

«Riprova di connessione del dispositivo con jitter backoff - Nessuna risposta» CONNACK

Convalida che il dispositivo in fase di test utilizza il backoff jitter corretto quando si ricollega con il broker per almeno cinque volte. Il broker registra il timestamp del dispositivo CONNECT su richiesta del test, esegue la convalida dei pacchetti, mette in pausa senza inviare un messaggio CONNACK al dispositivo in test e attende che il dispositivo in test invii nuovamente la richiesta. Il sesto tentativo di connessione può passare e CONNACK tornare al dispositivo in prova.

Il processo precedente viene eseguito di nuovo. In totale, questo test case richiede che il dispositivo si connetta almeno 12 volte in totale. I timestamp raccolti vengono utilizzati per convalidare che il jitter backoff venga utilizzato dal dispositivo in prova. Se il dispositivo sottoposto a test ha un ritardo di backoff strettamente esponenziale, questo test case sarà superato con avvertimenti.

Raccomandiamo l'implementazione del meccanismo Exponential Backoff And Jitter (Backoff esponenziale e jitter) sul dispositivo sottoposto a test per superare questo test case.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.

"tests":[
   {
      "name":"my_mqtt_jitter_backoff_retries_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",    // in seconds
      },
      "test":{
         "id":"MQTT_Connect_Jitter_Backoff_Retries",
         "version":"0.0.0"
      }
   }
]

«Tentativi di connessione del dispositivo con backoff esponenziale - Nessuna risposta» CONNACK

Verifica che il dispositivo sottoposto a test utilizzi il backoff esponenziale appropriato durante la riconnessione con il broker per almeno cinque volte. Il broker registra il timestamp del dispositivo CONNECT su richiesta del test, esegue la convalida dei pacchetti, mette in pausa senza inviare un messaggio al dispositivo client e attende che il dispositivo sottoposto CONNACK a test invii nuovamente la richiesta. I timestamp raccolti vengono utilizzati per convalidare che il backoff esponenziale venga utilizzato dal dispositivo in prova.

Raccomandiamo l'implementazione del meccanismo Exponential Backoff And Jitter (Backoff esponenziale e jitter) sul dispositivo sottoposto a test per superare questo test case.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.

"tests":[
   {
      "name":"my_mqtt_exponential_backoff_retries_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"600",  // in seconds
      },
      "test":{
         "id":"MQTT_Connect_Exponential_Backoff_Retries",
         "version":"0.0.0"
      }
   }
]      

"Riconnessione del dispositivo con jitter backoff - Dopo la disconnessione del server"

Convalida se un dispositivo sottoposto a test utilizza il jitter e il backoff necessari durante la riconnessione dopo che è stato disconnesso dal server. Device Advisor disconnette il dispositivo dal server per almeno cinque volte e osserva il comportamento del dispositivo durante la riconnessione. MQTT Device Advisor registra il timestamp della CONNECT richiesta per il dispositivo sottoposto a test, esegue la convalida dei pacchetti, si interrompe senza inviare un messaggio al dispositivo client e attende che il dispositivo sottoposto CONNACK a test invii nuovamente la richiesta. I timestamp raccolti vengono utilizzati per convalidare che il dispositivo sotttoposto a test utilizzi jitter e backoff durante la riconnessione. Se il dispositivo sottoposto a test ha un backoff strettamente esponenziale o non implementa un meccanismo jitter backoff appropriato, questo test case passerà con avvertimenti. Se il dispositivo sottoposto a test ha implementato un meccanismo di backoff lineare o un meccanismo di backoff costante, il test non andrà a buon fine.

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

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.

Il numero di tentativi di riconnessione da convalidare per il backoff può essere modificato specificando il RECONNECTION_ATTEMPTS. Il numero deve essere compreso tra 5 e 10. Il valore predefinito è 5.

"tests":[
   {
      "name":"my_mqtt_reconnect_backoff_retries_on_server_disconnect",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "RECONNECTION_ATTEMPTS": 5
      },
      "test":{
         "id":"MQTT_Reconnect_Backoff_Retries_On_Server_Disconnect",
         "version":"0.0.0"
      }
   }
]

"Device re-connect with jitter backoff - On unstable connection" (Riconnessione del dispositivo con jitter backoff - Connessione instabile)

Convalida se un dispositivo sottoposto a test utilizza il jitter e il backoff necessari durante la riconnessione su una connessione instabile. Device Advisor disconnette il dispositivo dal server dopo cinque connessioni riuscite e osserva il comportamento del dispositivo durante la riconnessione. MQTT Device Advisor registra il timestamp della CONNECT richiesta per il dispositivo sottoposto a test, esegue la convalida dei pacchetti, CONNACK restituisce, si disconnette, registra il timestamp della disconnessione e attende che il dispositivo sottoposto a test invii nuovamente la richiesta. I timestamp raccolti vengono utilizzati per convalidare che il dispositivo sottoposto a test utilizzi jitter e backoff durante connessioni corrette ma instabili. Se il dispositivo sottoposto a test ha un backoff strettamente esponenziale o non implementa un meccanismo jitter backoff appropriato, questo test case passerà con avvertimenti. Se il dispositivo sottoposto a test ha implementato un meccanismo di backoff lineare o un meccanismo di backoff costante, il test non andrà a buon fine.

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

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.

Il numero di tentativi di riconnessione da convalidare per il backoff può essere modificato specificando il RECONNECTION_ATTEMPTS. Il numero deve essere compreso tra 5 e 10. Il valore predefinito è 5.

"tests":[
   {
      "name":"my_mqtt_reconnect_backoff_retries_on_unstable_connection",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "RECONNECTION_ATTEMPTS": 5
      },
      "test":{
         "id":"MQTT_Reconnect_Backoff_Retries_On_Unstable_Connection",
         "version":"0.0.0"
      }
   }
]

Pubblicare

"QoS0 (Happy Case)"

Verifica che il dispositivo sottoposto a test pubblichi un messaggio con QoS0 o QoS1. È inoltre possibile convalidare l'argomento del messaggio e il payload specificando il valore dell'argomento e il payload nelle impostazioni di test.

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.

"tests":[
   {
      "name":"my_mqtt_publish_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish",
         "version":"0.0.0"
      }
   }
]      

«Riprova di pubblicazione con QoS1 - No» PUBACK

Verifica che il dispositivo in prova ripubblichi un messaggio inviato con QoS1, se il broker non invia. PUBACK È inoltre possibile convalidare l'argomento del messaggio specificando questo argomento nelle impostazioni di test. Il dispositivo client non deve disconnettersi prima di ripubblicare il messaggio. Questo test conferma inoltre che il messaggio ripubblicato abbia lo stesso identificatore di pacchetto dell'originale. Durante l'esecuzione del test, se il dispositivo perde la connessione e si riconnette, il test case si ripristina senza errori e il dispositivo deve eseguire nuovamente i passaggi del test case.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. È consigliato per almeno 4 minuti.

"tests":[
   {
      "name":"my_mqtt_publish_retry_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish_Retry_No_Puback",
         "version":"0.0.0"
      }
   }
]      

"Pubblica messaggi mantenuti"

Convalida che il dispositivo in fase di test pubblica un messaggio retainFlag impostato su true. È inoltre possibile convalidare l'argomento e il payload del messaggio impostando il valore dell'argomento e il payload nelle impostazioni di test. Se l'retainFlaginvio all'interno del PUBLISH pacchetto non è impostato su true, il test case avrà esito negativo.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti. Per eseguire questo test case, aggiungere l'azione iot:RetainPublish nel ruolo del dispositivo.

"tests":[
   {
      "name":"my_mqtt_publish_retained_messages_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_RETAINED_VALIDATION": "my_TOPIC_FOR_PUBLISH_RETAINED_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish_Retained_Messages",
         "version":"0.0.0"
      }
   }
]      

"Pubblica con proprietà utente"

Convalida che il dispositivo in fase di test pubblica un messaggio con la proprietà utente corretta. È possibile convalidare la proprietà utente impostando la coppia nome-valore nelle impostazioni del test. Se la proprietà utente non viene fornita o non corrisponde, il test case ha esito negativo.

APIdefinizione del test case:

Nota

Questo è un MQTT5 unico caso di test.

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.

"tests":[
   {
      "name":"my_mqtt_user_property_test",
      "test":{
        "USER_PROPERTIES": [
            {"name": "name1", "value":"value1"},
            {"name": "name2", "value":"value2"}
        ],
        "EXECUTION_TIMEOUT":"300",  // in seconds
      },
      "test":{
         "id":"MQTT_Publish_User_Property",
         "version":"0.0.0"
      }
   }
]      

Subscribe

"Puoi iscriverti (Happy Case)"

Verifica che il dispositivo sottoposto a test sia abbonato agli MQTT argomenti. È inoltre possibile convalidare l'argomento a cui il dispositivo sottoposto a test sottoscriva specificando questo argomento nelle impostazioni di test.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 2 minuti.

"tests":[
   {
      "name":"my_mqtt_subscribe_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["my_TOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
      },
      "test":{
         "id":"MQTT_Subscribe",
         "version":"0.0.0"
      }
   }
]      

«Iscriviti e riprova - NoSUBACK»

Verifica che il dispositivo in fase di test riprovi a effettuare una sottoscrizione agli argomenti non riuscita. MQTT Il server quindi attende e non invia un. SUBACK Se il dispositivo client non riprova la sottoscrizione, il test ha esito negativo. Il dispositivo client deve riprovare la sottoscrizione non riuscita con lo stesso pacchetto Id. È inoltre possibile convalidare l'argomento a cui il dispositivo sottoposto a test sottoscriva specificando questo argomento nelle impostazioni di test. Durante l'esecuzione del test, se il dispositivo perde la connessione e si riconnette, il test case si ripristina senza errori e il dispositivo deve eseguire nuovamente i passaggi del test case.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di 4 minuti.

"tests":[
   {
      "name":"my_mqtt_subscribe_retry_test",
      "configuration":{
         "EXECUTION_TIMEOUT":"300",  // in seconds
         // optional:
         "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["myTOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
      },
      "test":{
         "id":"MQTT_Subscribe_Retry_No_Suback",
         "version":"0.0.0"
      }
   }
]      

Keep-Alive

«Matt No Acc» PingResp

Questo test case convalida se il dispositivo sottoposto a test si disconnette quando non riceve una risposta ping. Nell'ambito di questo test case, Device Advisor blocca le risposte inviate AWS IoT Core per le richieste di pubblicazione, sottoscrizione e ping. Verifica inoltre se il dispositivo sottoposto a test disconnette la MQTT connessione.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un timeout superiore a 1,5 volte il valore keepAliveTime.

Il massimo non keepAliveTime deve essere superiore a 230 secondi per questo test.

"tests":[
    {
       "name":"Mqtt No Ack PingResp",
       "configuration": 
          //optional:
          "EXECUTION_TIMEOUT":"306",   // in seconds
       },
       "test":{
          "id":"MQTT_No_Ack_PingResp",
          "version":"0.0.0"
       }
    }
]

Sessione persistente

"Sessione persistente (happy case)"

Questo test case convalida il comportamento del dispositivo quando viene disconnesso da una sessione persistente. Il test case verifica se il dispositivo è in grado di riconnettersi, riprendere le sottoscrizioni agli argomenti di attivazione senza sottoscriversi nuovamente in modo esplicito, ricevere i messaggi archiviati negli argomenti e funzionare come previsto durante una sessione persistente. Quando questo test case viene superato, indica che il dispositivo client è in grado di mantenere una sessione persistente con il AWS IoT Core broker nel modo previsto. Per ulteriori informazioni sulle sessioni AWS IoT persistenti, consulta Utilizzo delle sessioni MQTT persistenti.

In questo caso di test, si prevede che il dispositivo client CONNECT abbia il flag AWS IoT Core with a clean session impostato su false e quindi sottoscriva un argomento di attivazione. Dopo un abbonamento riuscito, il dispositivo verrà disconnesso da AWS IoT Core Device Advisor. Mentre il dispositivo si trova nello stato disconnesso, in tale argomento verrà memorizzato un payload del messaggio QoS 1. Device Advisor consentirà quindi al dispositivo client di connettersi nuovamente con l'endpoint di test. A questo punto, poiché esiste una sessione persistente, il dispositivo client dovrebbe riprendere le sottoscrizioni agli argomenti senza inviare SUBSCRIBE pacchetti aggiuntivi e ricevere il messaggio QoS 1 dal broker. Dopo la riconnessione, se il dispositivo client si iscrive nuovamente all'argomento di attivazione inviando un SUBSCRIBE pacchetto aggiuntivo e/o se il client non riesce a ricevere il messaggio memorizzato dall'argomento di attivazione, il test case avrà esito negativo.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di almeno 4 minuti. Alla prima connessione, il dispositivo client deve sottoscrivere esplicitamente un TRIGGER_TOPIC non sottoscritto in precedenza. Per superare il test case, il dispositivo client deve sottoscrivere correttamente TRIGGER_TOPIC con un QoS 1. Dopo la riconnessione, ci si aspetta che il dispositivo client capisca che c'è una sessione persistente attiva; quindi dovrebbe accettare il messaggio memorizzato inviato dall'argomento di attivazione e restituire PUBACK quel messaggio specifico.

"tests":[
   {
      "name":"my_mqtt_persistent_session_happy_case",
      "configuration":{
         //required:
         "TRIGGER_TOPIC": "myTrigger/topic",
         // optional:
         // if Payload not provided, a string will be stored in the trigger topic to be sent back to the client device
         "PAYLOAD": "The message which should be received from AWS IoT Broker after re-connecting to a persistent session from the specified trigger topic.",            
         "EXECUTION_TIMEOUT":"300" // in seconds
      },
      "test":{
         "id":"MQTT_Persistent_Session_Happy_Case",
         "version":"0.0.0"
      }
   }
]      

"Sessione persistente - Scadenza della sessione"

Questo test case aiuta a convalidare il comportamento del dispositivo quando un dispositivo disconnesso si riconnette a una sessione persistente scaduta. Dopo la scadenza della sessione, ci aspettiamo che il dispositivo si iscriva nuovamente agli argomenti precedentemente sottoscritti inviando esplicitamente un nuovo pacchetto. SUBSCRIBE

Durante la prima connessione, ci aspettiamo che il dispositivo di test CONNECT acceda al broker AWS IoT, poiché il suo CleanSession flag è impostato su false per avviare una sessione persistente. Il dispositivo deve quindi sottoscrivere un argomento di attivazione. Quindi il dispositivo viene disconnesso da AWS IoT Core Device Advisor, dopo una sottoscrizione riuscita e l'avvio di una sessione persistente. Dopo la disconnessione, AWS IoT Core Device Advisor consente al dispositivo di test di riconnettersi all'endpoint di test. A questo punto, quando il dispositivo di test invia un altro CONNECT pacchetto, AWS IoT Core Device Advisor restituisce un CONNACK pacchetto che indica che la sessione persistente è scaduta. Il dispositivo di test deve interpretare correttamente questo pacchetto e si prevede che sottoscriva nuovamente lo stesso argomento di attivazione quando la sessione persistente viene terminata. Se il dispositivo di test non sottoscrive di nuovo l'argomento, il test case non riesce. Affinché il test abbia esito positivo, il dispositivo deve capire che la sessione persistente è terminata e inviare un nuovo SUBSCRIBE pacchetto per lo stesso argomento di attivazione nella seconda connessione.

Se il test case di un dispositivo di test riesce, significa che il dispositivo è in grado di gestire la riconnessione alla scadenza della sessione persistente nel modo previsto.

APIdefinizione del test case:

Nota

EXECUTION_TIMEOUT dispone di un valore predefinito di 5 minuti. Consigliamo un valore di timeout di almeno 4 minuti. Il dispositivo client deve sottoscrivere esplicitamente un TRIGGER_TOPIC non sottoscritto in precedenza. Per superare il test case, il dispositivo di test deve inviare un CONNECT pacchetto con CleanSession flag impostato su false e sottoscrivere correttamente un argomento di attivazione con QoS 1. Dopo una connessione riuscita, AWS IoT Core Device Advisor disconnette il dispositivo. Dopo la disconnessione, AWS IoT Core Device Advisor consente al dispositivo di riconnettersi e si prevede che il dispositivo si iscriva nuovamente alla stessa, TRIGGER_TOPIC poiché AWS IoT Core Device Advisor avrebbe interrotto la sessione persistente.

"tests":[
   {
      "name":"my_expired_persistent_session_test",
      "configuration":{
         //required:
         "TRIGGER_TOPIC": "myTrigger/topic",
         // optional:       
         "EXECUTION_TIMEOUT":"300" // in seconds
      },
      "test":{
         "id":"MQTT_Expired_Persistent_Session",
         "version":"0.0.0"
      }
   }
]