Tests de longue durée - AWS IoT Core

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Tests de longue durée

Les tests de longue durée sont une nouvelle suite de tests qui surveille le comportement d'un appareil lorsqu'il fonctionne sur de longues périodes. Comparé à l'exécution de tests individuels axés sur des comportements spécifiques d'un appareil, le test de longue durée examine le comportement de l'appareil dans divers scénarios réels au cours de sa durée de vie. Device Advisor orchestre les tests dans l'ordre le plus efficace possible. Le test génère des résultats et des journaux, y compris un journal récapitulatif contenant des mesures utiles sur les performances de l'appareil pendant le test.

MQTTcas de test de longue durée

Dans le cas d'un test de MQTT longue durée, le comportement de l'appareil est initialement observé dans des scénarios heureux tels que MQTT Connect, Subscribe, Publish et Reconnect. Le dispositif est ensuite observé dans de multiples scénarios de défaillance complexes tels que le report de MQTT reconnexion, la longue déconnexion du serveur et la connectivité intermittente.

MQTTflux d'exécution de cas de test de longue durée

L'exécution d'un scénario de test de MQTT longue durée comporte trois phases :

La « MQTT Longue durée d'exécution des tests » qui indique l'exécution des tests de base, l'exécution des tests avancés et le temps d'exécution supplémentaire.

Exécution de tests de base

Dans cette phase, le scénario de test exécute des tests simples en parallèle. Le test valide si l'appareil dispose des opérations sélectionnées dans la configuration.

L'ensemble de tests de base peut inclure les éléments suivants, en fonction des opérations sélectionnées :

CONNECT

Ce scénario permet de vérifier si l'appareil est capable d'établir une connexion réussie avec le courtier.

Le flux de connexion de base qui inclut l'envoi d'un CONNECT message par un appareil et auquel Broker répond par un CONNACK message contenant un code de retour valide.

PUBLISH

Ce scénario permet de vérifier si l'appareil publie avec succès auprès du courtier.

QoS 0

Ce cas de test valide si l'appareil envoie avec succès un message PUBLISH au courtier lors d'une publication avec QoS 0. Le test n'attend pas que le message PUBACK soit reçu par l'appareil.

Le flux PUBLISH QoS 0 qui inclut un appareil envoyant un PUBLISH message de niveau QoS 0.
QoS 1

Dans ce cas de test, l'appareil devrait envoyer deux messages PUBLISH au courtier avec QoS 1. Après le premier message PUBLISH, le courtier attend jusqu'à 15 secondes avant de répondre. L'appareil doit réessayer le message PUBLISH d'origine avec le même identifiant de paquet dans le délai de 15 secondes. Si c'est le cas, le courtier répond par un message PUBACK et le test est validé. Si l'appareil ne réessaie pas PUBLISH, PUBACKinitial lui est envoyé et le test est marqué comme réussi avec des avertissements, ainsi qu'un message système. 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 devra effectuer à nouveau les étapes du scénario de test.

Le flux PUBLISH QoS 1 qui inclut l'envoi par un appareil d'un PUBLISH message de niveau QoS 1 et de multiples interactions avec le courtier.

SUBSCRIBE

Ce scénario valide si l'appareil s'abonne avec succès auprès du courtier.

QoS 0

Ce cas de test valide si l'appareil envoie avec succès un message SUBSCRIBE au courtier lors d'un abonnement avec QoS 0. Le test n'attend pas que l'appareil reçoive un SUBACK message.

Le flux SUBSCRIBE QoS 0 qui inclut un appareil envoyant un SUBSCRIBE message de niveau QoS 0 et un courtier répondant par un SUBACK message et le code Success Maximum QoS 0.
QoS 1

Dans ce cas de test, l'appareil devrait envoyer deux messages SUBSCRIBE au courtier avec QoS 1. Après le premier message SUBSCRIBE, le courtier attend jusqu'à 15 secondes avant de répondre. L'appareil doit réessayer le message SUBSCRIBE d'origine avec le même identifiant de paquet dans le délai de 15 secondes. Si c'est le cas, le courtier répond par un message SUBACK et le test est validé. Si l'appareil ne réessaie pas SUBSCRIBE, SUBACKinitial lui est envoyé et le test est marqué comme réussi avec des avertissements, ainsi qu'un message système. 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 devra effectuer à nouveau les étapes du scénario de test.

Le flux SUBSCRIBE QoS 1 qui inclut l'envoi par un appareil d'un SUBSCRIBE message de niveau QoS 1 et de multiples interactions avec le courtier.

RECONNECT

Ce scénario vérifie si l'appareil se reconnecte avec succès au courtier une fois que l'appareil est déconnecté d'une connexion réussie. Device Advisor ne déconnecte pas l'appareil s'il s'est connecté plusieurs fois au cours de la suite de tests. Au lieu de cela, il marquera le test comme réussi.

Le RECONNECT flux entre DUT et le courtier.

Exécution de tests avancés

Au cours de cette phase, le scénario de test exécute des tests plus complexes en série pour valider si le dispositif suit les meilleures pratiques. Ces tests avancés peuvent être sélectionnés et peuvent être désactivés s'ils ne sont pas nécessaires. Chaque test avancé possède sa propre valeur de délai d'attente en fonction des exigences du scénario.

RETURNPUBACKSUR QoS 1 SUBSCRIPTION

Note

Sélectionnez ce scénario uniquement si votre appareil est capable d'exécuter des abonnements QoS 1.

Ce scénario valide si, une fois que l'appareil s'est abonné à une rubrique et a reçu un PUBLISH message du courtier, il renvoie un PUBACK message.

Le SUBSCTIPTION flux RETURN PUBACK ON QoS 1 entre DUT et le broker.

RECEIVE LARGE PAYLOAD

Note

Sélectionnez ce scénario si votre appareil est capable d'exécuter des abonnements QoS 1.

Ce scénario valide si l'appareil répond par un PUBACK message après avoir reçu un PUBLISH message du courtier pour un sujet QoS 1 avec une charge utile importante. Le format de la charge utile attendue peut être configuré à l'aide de l'option LONG_PAYLOAD_FORMAT.

Le RECEIVE LARGE PAYLOAD flux entre DUT et le courtier.

PERSISTENT SESSION

Note

Sélectionnez ce scénario uniquement si votre appareil est capable d'effectuer des abonnements QoS 1 et peut maintenir une session persistante.

Ce scénario valide le comportement de l'appareil lors du maintien de sessions persistantes. Le test valide lorsque les conditions suivantes sont réunies :

  • L'appareil se connecte au courtier avec un abonnement QoS 1 actif et des sessions persistantes activées.

  • L'appareil se déconnecte correctement du courtier pendant la session.

  • L'appareil se reconnecte au courtier et reprend les abonnements à ses rubriques de déclenchement sans se réabonner explicitement à ces rubriques.

  • L'appareil reçoit avec succès les messages stockés par le courtier pour les sujets auxquels il est abonné et fonctionne comme prévu.

Pour plus d'informations sur les sessions AWS IoT persistantes, consultez la section Utilisation de sessions MQTT persistantes.

Le PERSISTENT SESSION flux entre DUT et le courtier.

KEEP ALIVE

Ce scénario vérifie si l'appareil se déconnecte correctement après avoir reçu une réponse ping du courtier. La connexion doit avoir une minuterie de maintien valide configurée. Dans le cadre de ce test, le courtier bloque toutes les réponses envoyées pour PUBLISHSUBSCRIBE, et les PINGREQ messages. Il valide également si le périphérique testé déconnecte la MQTT connexion.

Le KEEP ALIVE flux entre DUT et le courtier.

INTERMITTENT CONNECTIVITY

Ce scénario valide si l'appareil peut se reconnecter au courtier après que celui-ci l'ait déconnecté à intervalles aléatoires pendant une période de temps aléatoire.

Le INTERMITTENT CONNECTIVITY flux entre DUT et le courtier.

RECONNECT BACKOFF

Ce scénario valide si l'appareil dispose d'un mécanisme de sauvegarde mis en œuvre lorsque le courtier s'en déconnecte plusieurs fois. Device Advisor signale le type d'intervalle comme exponentiel, instabilité, linéaire ou constant. Le nombre de tentatives d'interruption est configurable à l'aide de l'option BACKOFF_CONNECTION_ATTEMPTS. La valeur par défaut est 5. La valeur est configurable entre 5 et 10.

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

Le RECONNECT BACKOFF flux entre DUT et le courtier.

LONG SERVER DISCONNECT

Ce scénario vérifie si l'appareil peut se reconnecter avec succès après que le courtier l'a déconnecté pendant une longue période (jusqu'à 120 minutes). L'heure de déconnexion du serveur peut être configurée à l'aide de l'option LONG_SERVER_DISCONNECT_TIME. La valeur par défaut est de 120 minutes. Cette valeur est configurable entre 30 et 120 minutes.

Le LONG SERVER DISCONNECT flux entre DUT et le courtier.

Temps d'exécution supplémentaire

Le temps d'exécution supplémentaire est le temps pendant lequel le test attend après avoir terminé tous les tests ci-dessus et avant de terminer le scénario de test. Les clients utilisent cette période supplémentaire pour surveiller et enregistrer toutes les communications entre l'appareil et le courtier. Le temps d'exécution supplémentaire peut être configuré à l'aide de l'option ADDITIONAL_EXECUTION_TIME. Par défaut, cette option est définie sur 0 minute et peut aller de 0 à 120 minutes.

MQTToptions de configuration de test de longue durée

Toutes les options de configuration fournies pour le test de MQTT longue durée sont facultatives. Les options suivantes sont disponibles :

OPERATIONS

La liste des opérations effectuées par le périphérique, telles queCONNECT, PUBLISH et SUBSCRIBE. Le scénario de test exécute des scénarios basés sur les opérations spécifiées. Les opérations qui ne sont pas spécifiées sont considérées comme valides.

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

Sur la base des opérations sélectionnées, le scénario de test exécute des scénarios pour valider le comportement de l'appareil. Il existe deux types de scénarios :

  • Les scénarios de base sont des tests simples qui valident si le périphérique peut effectuer les opérations sélectionnées ci-dessus dans le cadre de la configuration. Ils sont présélectionnés en fonction des opérations spécifiées dans la configuration. Aucune autre saisie n'est requise dans la configuration.

  • Les scénarios avancés sont des scénarios plus complexes qui sont exécutés par rapport à l'appareil pour valider si celui-ci suit les meilleures pratiques lorsqu'il est confronté à des conditions réelles. Ils sont facultatifs et peuvent être transmis sous forme de tableau de scénarios à l'entrée de configuration de la suite de tests.

{ "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:

Durée maximale pendant laquelle le scénario de test attendra la fin de tous les tests de base. La valeur par défaut est de 60 minutes. Cette valeur est configurable entre 30 et 120 minutes.

LONG_SERVER_DISCONNECT_TIME:

Temps nécessaire au scénario de test pour déconnecter et reconnecter l’appareil pendant le test de déconnexion longue du serveur. La valeur par défaut est de 60 minutes. Cette valeur est configurable entre 30 et 120 minutes.

ADDITIONAL_EXECUTION_TIME:

La configuration de cette option fournit une fenêtre temporelle une fois tous les tests terminés, afin de surveiller les événements entre l'appareil et le courtier. La valeur par défaut est de 0 minutes. Cette valeur est configurable entre 0 et 120 minutes.

BACKOFF_CONNECTION_ATTEMPTS:

Cette option configure le nombre de fois que l’appareil est déconnecté par le scénario de test. Ceci est utilisé par le test Reconnect Backoff. La valeur par défaut est de 5 tentatives. Cette valeur est configurable entre 5 et 10.

LONG_PAYLOAD_FORMAT:

Format de la charge utile du message attendu par l'appareil lorsque le scénario de test est publié dans une rubrique QoS 1 à laquelle l'appareil est abonné.

APIdéfinition du cas de test :

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

MQTTjournal récapitulatif des cas de test de longue durée

Le scénario de test de MQTT longue durée s'exécute pendant une durée plus longue que les scénarios de test ordinaires. Un journal récapitulatif distinct est fourni, qui répertorie les événements importants tels que les connexions des appareils, la publication et l'abonnement pendant l'exécution. Les détails incluent ce qui a été testé, ce qui n'a pas été testé et ce qui a échoué. À la fin du journal, le test inclut un résumé de tous les événements survenus pendant l'exécution du scénario de test. Cela consiste notamment à :

  • Le minuteur Keep Alive est configuré sur l'appareil.

  • Indicateur de session persistante configuré sur l'appareil.

  • Le nombre de connexions de l'appareil pendant le test.

  • Type d'interruption de reconnexion de l'appareil, s'il est validé pour le test d'interruption de reconnexion.

  • Rubriques sur lesquelles l'appareil a publié, lors de l'exécution du scénario de test.

  • Rubriques sur lesquelles l'appareil s'est abonné pendant l'exécution du scénario de test.