MQTT

Convalida che il dispositivo sottoposto a test invia una richiesta CONNECT.

Definizione del test case API:

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

Questo test case verificherà se il dispositivo (client) può restituire un messaggio PUBACK 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.

Definizione del test case API:

"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"
        }
    }
]

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 sotto la richiesta CONNECT del test, esegue la convalida dei pacchetti, si interrompe senza inviare un CONNACK al dispositivo in fase di test e attende che il dispositivo sottoposto a test invii nuovamente la richiesta. Il sesto tentativo di connessione è consentito per passare attraverso e CONNACK è autorizzato a fluire di nuovo 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.

Definizione del test case API:

"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"
      }
   }
]

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 sotto la richiesta CONNECT del test, esegue la convalida dei pacchetti, si interrompe senza inviare un CONNACK al dispositivo client e attende che il dispositivo in fase di 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.

Definizione del test case API:

"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"
      }
   }
]      

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 per la riconnessione MQTT. Device Advisor registra il timestamp della richiesta CONNECT per il dispositivo in fase di test, esegue la convalida dei pacchetti, si interrompe senza inviare un CONNACK al dispositivo client e attende che il dispositivo in fase di 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.

Definizione del test case API:

"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"
      }
   }
]

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 valide e osserva il comportamento del dispositivo per la riconnessione MQTT. Device Advisor registra il timestamp della richiesta CONNECT per il dispositivo in fase di test, esegue la convalida dei pacchetti, invia un CONNACK, si disconnette, registra il timestamp della disconnessione e attende che il dispositivo in fase di 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.

Definizione del test case API:

"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"
      }
   }
]

Verifica che il dispositivo in 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.

"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"
      }
   }
]      

Convalida che il dispositivo in fase di test ripubblica 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.

Definizione del test case API:

"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"
      }
   }
]      

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 il retainFlag inviato all'interno del pacchetto PUBLISH non è impostato su true, il test case avrà esito negativo.

Definizione del test case API:

"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"
      }
   }
]      

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.

Definizione del test case API:

"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"
      }
   }
]      

Convalida che il dispositivo sottoposto a test si sottoscriva gli argomenti MQTT. È inoltre possibile convalidare l'argomento a cui il dispositivo sottoposto a test sottoscriva specificando questo argomento nelle impostazioni di test.

Definizione del test case API:

"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"
      }
   }
]      

Convalida che il dispositivo in fase di test tenta una sottoscrizione non riuscita agli argomenti MQTT. Il server 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.

Definizione del test case API:

"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"
      }
   }
]      

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. Convalida anche se il dispositivo sottoposto a test disconnette la connessione MQTT.

Definizione del test case API:

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

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, vedere Utilizzo delle sessioni persistenti MQTT.

In questo test case, è previsto che il dispositivo client esegua una richiesta CONNECT a AWS IoT Core con un flag di sessione pulita impostato su false, quindi effettui la sottoscrizione a 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 riprende le sottoscrizioni degli argomenti senza inviare pacchetti SUBSCRIBE aggiuntivi e ricevere il messaggio QoS 1 dal broker. Dopo la riconnessione, se il dispositivo client si sottoscrive nuovamente all'argomento di attivazione inviando un ulteriore pacchetto SUBSCRIBE e/o se il client non riesce a ricevere il messaggio archiviato dall'argomento di attivazione, il test case ha esito negativo.

Definizione del test case API:

"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"
      }
   }
]      

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, è previsto che il dispositivo sottoscriva nuovamente gli argomenti precedentemente sottoscritti inviando esplicitamente un nuovo pacchetto SUBSCRIBE.

Durante la prima connessione, ci aspettiamo che il dispositivo di test si CONNETTA 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 pacchetto CONNECT, AWS IoT Core Device Advisor restituisce un pacchetto CONNACK 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. Per superare il test, il dispositivo deve comprendere che la sessione persistente è terminata e inviare un nuovo pacchetto SUBSCRIBE 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.

Definizione del test case API:

"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"
      }
   }
]