MQTT

Valide que le périphérique testé envoie une demande CONNECT.

Définition du cas de test de l'API :

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

Ce cas de test vérifiera si l'appareil (client) peut renvoyer un message PUBACK s'il a reçu un message de publication du broker après s'être abonné à un sujet avec QoS1.

Le contenu et la taille de la charge utile sont configurables pour ce cas de test. Si la taille de la charge utile est configurée, Device Advisor écrasera la valeur du contenu de la charge utile et enverra une charge utile prédéfinie au périphérique avec la taille souhaitée. La taille de la charge utile est une valeur comprise entre 0 et 128 et ne peut pas dépasser 128 Ko. AWS IoT Core rejette les demandes de publication et de connexion supérieures à 128 Ko, comme indiqué sur la page AWS IoT Core agent de messages et des limites et quotas du protocole.

Définition du cas de test de l'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"
        }
    }
]

Vérifie que le périphérique testé utilise le système de réduction de gigue approprié lorsqu'il se reconnecte au courtier au moins cinq fois. Le courtier enregistre l'horodatage de la demande CONNECT de l'appareil testé, effectue la validation des paquets, fait une pause sans envoyer de CONNACK à l'appareil testé et attend que l'appareil testé renvoie la demande. La sixième tentative de connexion est autorisée à passer et CONNACK est autorisé à revenir vers l'appareil testé.

Le processus précédent est recommencé. Au total, ce cas de test nécessite que l'appareil se connecte au moins 12 fois. Les horodatages collectés sont utilisés pour valider que l'atténuation de la gigue est utilisée par l'appareil testé. Si le délai de temporisation de l'appareil testé est strictement exponentiel, ce scénario de test sera validé avec des avertissements.

Nous recommandons d'implémenter le mécanisme Backoff exponentiel et Gigue sur l'appareil testé pour réussir ce scénario de test.

Définition du cas de test de l'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"
      }
   }
]

Vérifie que l’appareil testé utilise le backoff exponentiel approprié lors de la reconnexion au courtier au moins cinq fois. Le courtier enregistre l'horodatage de la requête CONNECT de l'appareil testé, effectue la validation des paquets, fait une pause sans envoyer de CONNACK à l'appareil client et attend que l'appareil testé renvoie la demande. Les horodatages collectés sont utilisés pour valider qu’une backoff exponentiel est utilisée par l'appareil testé.

Nous recommandons d'implémenter le mécanisme Backoff exponentiel et Gigue sur l'appareil testé pour réussir ce scénario de test.

Définition du cas de test de l'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"
      }
   }
]      

Valide si un appareil testé utilise l'instabilité et le ralentissement nécessaire lors de la reconnexion après avoir été déconnecté du serveur. Device Advisor déconnecte l'appareil du serveur au moins cinq fois et observe le comportement de l'appareil lors de la reconnexion MQTT. Device Advisor enregistre l'horodatage de la demande CONNECT pour le périphérique testé, effectue la validation des paquets, fait une pause sans envoyer de CONNACK à l’appareil client et attend que l’appareil testé renvoie la demande. Les horodatages collectés sont utilisés pour valider que l'appareil testé utilise la gigue et l'interruption lors de la reconnexion. Si l’appareil testé présente une backoff exponentiel stricte ou n'implémente pas un mécanisme d'atténuation de gigue approprié, ce scénario de test réussira avec des avertissements. Si le dispositif testé a mis en œuvre un mécanisme d'arrêt linéaire ou constant, le test échouera.

Pour réussir ce cas de test, nous vous recommandons d'implémenter Backoff exponentiel et Gigue sur l'appareil testé dans ce test.

Définition du cas de test de l'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"
      }
   }
]

Valide si un appareil testé utilise la gigue et l’intervalle de temps nécessaires lors de la reconnexion sur une connexion instable. Device Advisor déconnecte l'appareil du serveur après cinq connexions réussies et observe le comportement de l'appareil pour la reconnexion MQTT. Device Advisor enregistre l'horodatage de la demande CONNECT pour l'appareil testé, effectue la validation des paquets, renvoie CONNACK, se déconnecte, enregistre l'horodatage de la déconnexion et attend que l'appareil testé renvoie la demande. Les horodatages collectés sont utilisés pour valider que l'appareil testé utilise la gigue et l'interruption lors de la reconnexion après des connexions réussies mais instables. Si l’appareil testé présente une backoff exponentiel stricte ou n'implémente pas un mécanisme d'atténuation de gigue approprié, ce scénario de test réussira avec des avertissements. Si le dispositif testé a mis en œuvre un mécanisme d'arrêt linéaire ou constant, le test échouera.

Pour réussir ce cas de test, nous vous recommandons d'implémenter Backoff exponentiel et Gigue sur l'appareil testé dans ce test.

Définition du cas de test de l'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"
      }
   }
]

Valide que l'appareil testé publie un message avec QoS0 ou QoS1. Vous pouvez également valider la rubrique du message et la charge utile en spécifiant la valeur de la rubrique et la charge utile dans les paramètres de 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"
      }
   }
]      

Valide que l'appareil testé republie un message envoyé avec QoS1, si le courtier n'envoie pas PUBACK. Vous pouvez également valider le sujet du message en précisant ce sujet dans les paramètres du test. L'appareil client ne doit pas se déconnecter avant de republier le message. Ce test permet également de vérifier que le message republié possède le même identifiant de paquet que l'original. Pendant l'exécution du test, si l'appareil perd la connexion et se reconnecte, le scénario de test sera réinitialisé sans échec et l'appareil doit recommencer les étapes du scénario de test.

Définition du cas de test de l'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"
      }
   }
]      

Valide que l’appareil testé publie un message retainFlag set to true. (défini sur true) Vous pouvez valider la rubrique et la charge utile du message en définissant la valeur de rubrique et la charge utile dans les paramètres de test. Si le paramètre retainFlag envoyé dans le paquet PUBLISH n'est pas défini sur true, le scénario de test échouera.

Définition du cas de test de l'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"
      }
   }
]      

Valide que l’appareil testé publie un message avec la propriété utilisateur correcte. Vous pouvez valider la propriété utilisateur en définissant la paire nom-valeur dans les paramètres de test. Si la propriété utilisateur n'est pas fournie ou ne correspond pas, le scénario de test échoue.

Définition du cas de test de l'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"
      }
   }
]      

Vérifie que l'appareil testé est abonné aux rubriques MQTT. Vous pouvez également valider la rubrique à laquelle l'appareil testé est abonné en spécifiant cette rubrique dans les paramètres de test.

Définition du cas de test de l'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"
      }
   }
]      

Confirme que l'appareil testé tente à nouveau un abonnement ayant échoué aux sujets MQTT. Le serveur attend alors et n'envoie pas de SUBACK. Si l'appareil client ne réessaye pas l'abonnement, le test échoue. L'appareil client doit réessayer l'abonnement qui a échoué avec le même identifiant de paquet. Vous pouvez également valider la rubrique à laquelle l'appareil testé est abonné en spécifiant cette rubrique dans les paramètres de test. Pendant l'exécution du test, si l'appareil perd la connexion et se reconnecte, le scénario de test sera réinitialisé sans échec et l'appareil doit recommencer les étapes du scénario de test.

Définition du cas de test de l'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"
      }
   }
]      

Ce cas de test valide si le périphérique testé se déconnecte lorsqu'il ne reçoit pas de réponse ping. Dans le cadre de ce scénario de test, Device Advisor bloque les réponses envoyées AWS IoT Core depuis les demandes de publication, d'abonnement et de ping. Il vérifie également si l'appareil testé déconnecte la connexion MQTT.

Définition du cas de test de l'API :

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

Ce cas de test valide le comportement de l'appareil lorsqu'il est déconnecté d'une session persistante. Le scénario de test vérifie si l'appareil peut se reconnecter, reprendre les abonnements à ses rubriques de déclenchement sans se réabonner explicitement, recevoir les messages stockés dans les rubriques et fonctionner comme prévu pendant une session persistante. Lorsque ce scénario de test est réussi, cela indique que le dispositif client est capable de maintenir une session persistante avec le AWS IoT Core courtier de la manière attendue. Pour plus d'informations sur les sessions AWS IoT persistantes, consultez la section Utilisation des sessions persistantes MQTT.

Dans ce scénario de test, l’appareil client doit se CONNECTER au AWS IoT Core avec un indicateur de session propre défini sur false, puis s'abonner à une rubrique de déclenchement. Après un abonnement réussi, l'appareil sera déconnecté par AWS IoT Core Device Advisor. Lorsque l'appareil est déconnecté, une charge utile de message QoS 1 sera stockée dans cette rubrique. Device Advisor autorisera ensuite l'appareil client à se reconnecter au point de terminaison de test. À ce stade, étant donné qu'il existe une session persistante, le périphérique client est censé reprendre ses abonnements aux rubriques sans envoyer de paquets SUBSCRIBE supplémentaires et recevoir le message QoS 1 du courtier. Après la reconnexion, si le dispositif client se réabonne à nouveau à sa rubrique déclencheur en envoyant un paquet SUBSCRIBE supplémentaire et/ou si le client ne reçoit pas le message stocké de la rubrique déclencheur, le scénario de test échouera.

Définition du cas de test de l'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"
      }
   }
]      

Ce cas de test permet de valider le comportement de l'appareil lorsqu'un appareil déconnecté se reconnecte à une session persistante expirée. Une fois la session expirée, nous nous attendons à ce que l'appareil se réabonne aux rubriques auxquelles il était précédemment abonné en envoyant explicitement un nouveau paquet SUBSCRIBE.

Lors de la première connexion, nous nous attendons à ce que l'appareil de test SE CONNECTE au courtier AWS IoT, car son CleanSession indicateur est défini sur false pour lancer une session persistante. L'appareil doit ensuite s'abonner à une rubrique déclencheur. L'appareil est ensuite déconnecté par AWS IoT Core Device Advisor, après un abonnement réussi et le lancement d'une session persistante. Après la déconnexion, AWS IoT Core Device Advisor permet au périphérique de test de se reconnecter au point de terminaison de test. À ce stade, lorsque le périphérique de test envoie un autre paquet CONNECT, AWS IoT Core Device Advisor renvoie un paquet CONNACK indiquant que la session persistante a expiré. L’appareil de test doit interpréter ce paquet correctement et il est censé se réabonner à la même rubrique déclencheur à la fin de la session persistante. Si l’appareil de test ne se réabonne pas à son déclencheur de rubrique, le scénario de test échoue. Pour que le test réussisse, l'appareil doit comprendre que la session persistante est terminée et renvoyer un nouveau paquet SUBSCRIBE pour la même rubrique de déclenchement lors de la deuxième connexion.

Si ce scénario de test réussit pour un appareil de test, cela indique que l'appareil est capable de gérer la reconnexion à l'expiration de la session persistante de la manière attendue.

Définition du cas de test de l'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"
      }
   }
]