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.
# Cas de test Device Advisor
Device Advisor propose des tests prédéfinis dans six catégories.
+ [TLS](device-advisor-tests-tls.md)
+ [MQTT](device-advisor-tests-mqtt.md)
+ [Shadow](device-advisor-tests-shadow.md)
+ [Exécution d’une tâche](device-advisor-tests-job-execution.md)
+ [Autorisations et politiques](device-advisor-tests-permissions-policies.md)
+ [Tests de longue durée](device-advisor-tests-long-duration.md)
## Device Advisor teste des scénarios pour se qualifier pour le programme de qualification des AWS appareils.
Votre appareil doit réussir les tests suivants pour être éligible conformément au [AWS Device Qualification Program](https://aws.amazon.com/partners/programs/dqp/). (Programme de qualification des appareils)
**Note**
Il s'agit d'une liste révisée des tests de qualification.
+ [Connexion TLS](device-advisor-tests-tls.md#TLS_Connect) (« Connexion TLS »)
+ [Certificat de serveur de nom de sujet incorrect TLS](device-advisor-tests-tls.md#TLS_Incorrect_Subject_Name) (« Nom commun du sujet (CN) /nom alternatif du sujet (SAN) incorrect »)
+ [Certificat de serveur TLS non sécurisé](device-advisor-tests-tls.md#TLS_Unsecure_Server_Cert) (« Non signé par une autorité de certification reconnue »)
+ [Support des appareils TLS pour les suites de AWS IoT chiffrement](device-advisor-tests-tls.md#TLS_DeviceSupport_For_IOT) (« Support des appareils TLS pour les suites de chiffrement AWS IoT recommandées »)
+ [TLS Receive Maximum Size Fragments](device-advisor-tests-tls.md#TLS_MaximumSize) (« TLS reçoit des fragments de taille maximale »)
+ [TLS Expired Server Cert](device-advisor-tests-tls.md#TLS_Expired_Server_Cert) (« Certificat de serveur expiré »)
+ [TLS Large Size Server Cert](device-advisor-tests-tls.md#TLS_LargeServerCert) (« certificat de serveur TLS de grande taille »)
+ [MQTT Connect](device-advisor-tests-mqtt.md#MQTT_Connect) (« L'appareil envoie le CONNECT à AWS IoT Core (Happy case) »)
+ [S'abonner à MQTT](device-advisor-tests-mqtt.md#MQTT_Subscribe) (« Peut s'abonner (Happy Case) »)
+ [MQTT Publish](device-advisor-tests-mqtt.md#MQTT_Publish) (« QoS0 (Happy Case) »)
+ [MQTT Connect Jitter Retries](device-advisor-tests-mqtt.md#MQTT_ConnectJitterBackoff) (« Nouvelles tentatives de connexion de l'appareil avec intervalle de gigue - Aucune réponse CONNACK »)
# TLS
Utilisez ces tests pour déterminer si le protocole de sécurité de la couche transport (TLS) entre vos appareils AWS IoT est sécurisé.
**Note**
Device Advisor prend désormais en charge TLS 1.3.
## Happy Path
**Connexion TLS**
Valide si le périphérique testé peut effectuer la prise de contact TLS avec. AWS IoT Ce test ne valide pas l'implémentation MQTT de l'appareil client.
**Example Définition du cas de test de l'API :**
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Pour de meilleurs résultats, nous recommandons un délai d'attente de 2 minutes.
```
"tests":[
{
"name":"my_tls_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Connect",
"version":"0.0.0"
}
}
]
```
**Example Sorties du scénario de test :**
+ **Réussite** — L'appareil testé a terminé la prise de contact TLS avec. AWS IoT
+ **Réussir avec des avertissements** — L'appareil testé a terminé la prise de contact TLS avec AWS IoT, mais des messages d'avertissement TLS ont été envoyés par l'appareil ou. AWS IoT
+ **Échec** : le périphérique testé n'a pas réussi à terminer la prise de contact TLS AWS IoT en raison d'une erreur de connexion.
**TLS reçoit des fragments de taille maximale**
Ce cas de test confirme que votre appareil peut recevoir et traiter des fragments de taille maximale TLS. Votre appareil de test doit s'abonner à une rubrique préconfigurée avec QoS 1 pour recevoir une charge utile importante. Vous pouvez personnaliser la charge utile avec la configuration `${payload}`.
**Example Définition du cas de test de l'API :**
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Pour de meilleurs résultats, nous recommandons un délai d'attente de 2 minutes.
```
"tests":[
{
"name":"TLS Receive Maximum Size Fragments",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
"PAYLOAD_FORMAT":"{"message":"${payload}"}", // A string with a placeholder ${payload}, or leave it empty to receive a plain string.
"TRIGGER_TOPIC": "test_1" // A topic to which a device will subscribe, and to which a test case will publish a large payload.
},
"test":{
"id":"TLS_Receive_Maximum_Size_Fragments",
"version":"0.0.0"
}
}
]
```
## Suites de chiffrement
**Support des appareils TLS pour les suites de AWS IoT chiffrement recommandées**
Vérifie que les suites de chiffrement figurant dans le message Hello du client TLS envoyé par le périphérique testé contiennent les [AWS IoT cipher suites](transport-security.md).(suites de chiffrement recommandées) Il fournit des informations supplémentaires sur les suites de chiffrement prises en charge par l'appareil.
**Example Définition du cas de test de l'API :**
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"tests":[
{
"name":"my_tls_support_aws_iot_cipher_suites_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Support_AWS_IoT_Cipher_Suites",
"version":"0.0.0"
}
}
]
```
**Example Sorties du scénario de test :**
+ **Réussite** — L'appareil testé contient au moins l'une des suites de AWS IoT chiffrement recommandées et ne contient aucune suite de chiffrement non prise en charge.
+ **Passez avec avertissements** : les suites de chiffrement de l'appareil contiennent au moins une suite de chiffrement AWS IoT , mais :
1. Il ne contient aucune des suites de chiffrement recommandées
1. Il contient des suites de chiffrement qui ne sont pas prises en charge par AWS IoT.
Nous vous suggérons de vérifier que toutes les suites de chiffrement non prises en charge sont sûres.
+ **Échec** : le périphérique soumis aux suites de chiffrement testées ne contient aucune des suites de chiffrement AWS IoT prises en charge.
## Certificat de serveur de plus grande taille
**Certificat de serveur TLS de grande taille**
Les validations sur votre appareil peuvent terminer la négociation TLS avec AWS IoT lorsqu'il reçoit et traite un certificat de serveur de plus grande taille. La taille du certificat de serveur (en octets) utilisé par ce test est supérieure de 20 à celle actuellement utilisée dans le cas de test **TLS Connect** et IoT Core. Au cours de ce scénario de AWS IoT test, testez l'espace tampon de votre appareil pour le TLS. Si l'espace tampon est suffisamment important, la poignée de main TLS se termine sans erreur. Ce test ne valide pas l'implémentation MQTT de l'appareil. Le scénario de test prend fin une fois le processus de handshake TLS terminé.
**Example Définition du cas de test de l'API :**
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Pour de meilleurs résultats, nous recommandons un délai d'attente de 2 minutes. Si ce scénario de test échoue mais que le test **TLS Connect** réussit, nous vous recommandons d'augmenter la limite d'espace tampon de votre appareil pour le protocole TLS. L'augmentation de la limite d'espace tampon garantit que votre appareil pourra traiter un certificat de serveur de plus grande taille au cas où la taille augmenterait.
```
"tests":[
{
"name":"my_tls_large_size_server_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Large_Size_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Sorties du scénario de test :**
+ **Réussite** — L'appareil testé a terminé la prise de contact TLS avec. AWS IoT
+ **Réussissez avec des avertissements** — L'appareil testé a terminé la prise de contact TLS avec AWS IoT, mais des messages d'avertissement TLS proviennent soit de l'appareil, soit. AWS IoT
+ **Échec** : le périphérique testé n'a pas réussi à terminer la prise de contact TLS en AWS IoT raison d'une erreur survenue lors du processus de prise de contact.
## Certificat de serveur non sécurisé TLS
**Non signé par une autorité de certification reconnue**
Confirme que l'appareil testé ferme la connexion s'il est présenté avec un certificat de serveur sans signature valide de l'autorité de certification ATS. Un appareil ne doit se connecter qu'à un point de terminaison présentant un certificat valide.
**Example Définition du cas de test de l'API :**
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"tests":[
{
"name":"my_tls_unsecure_server_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Unsecure_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Sorties du scénario de test :**
+ **Réussite** — L'appareil testé a fermé la connexion.
+ **Échec** — L'appareil testé a terminé la prise de contact TLS avec. AWS IoT
**Certificat de serveur du nom de sujet incorrect TLS / Nom commun de sujet (CN) / Nom alternatif du sujet (SAN) incorrect**
Valide que l'appareil testé ferme la connexion s'il reçoit un certificat de serveur pour un nom de domaine différent de celui demandé.
**Example Définition du cas de test de l'API :**
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"tests":[
{
"name":"my_tls_incorrect_subject_name_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Incorrect_Subject_Name_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Sorties du scénario de test :**
+ **Réussite** — L'appareil testé a fermé la connexion.
+ **Échec** : le périphérique testé a terminé la prise de contact TLS avec. AWS IoT
## Certificat de serveur TLS expiré
**Certificat de serveur expiré**
Confirme que l'appareil testé ferme la connexion s'il reçoit un certificat de serveur expiré.
**Example Définition du cas de test de l'API :**
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"tests":[
{
"name":"my_tls_expired_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Expired_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Sorties du scénario de test :**
+ **Réussite** — L'appareil testé refuse de terminer la prise de contact TLS avec. AWS IoT L'appareil envoie un message d'alerte TLS avant de fermer la connexion.
+ **Pass with warnings** — L'appareil testé refuse de terminer la prise de contact TLS avec AWS IoT. Cependant, il n'envoie pas de message d'alerte TLS avant de fermer la connexion.
+ **Échec** : le périphérique testé termine la prise de contact TLS avec. AWS IoT
# MQTT
## CONNECTEZ, DÉCONNECTEZ et RECONNECTEZ
**« L'appareil envoie le CONNECT à AWS IoT Core (Happy case) »**
Valide que le périphérique testé envoie une demande CONNECT.
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"tests":[
{
"name":"my_mqtt_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Connect",
"version":"0.0.0"
}
}
]
```
**« L'appareil peut renvoyer PUBACK à un sujet arbitraire pour QoS1 »**
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.](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits)
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes. `PAYLOAD_SIZE` peut être configuré à une valeur comprise entre 0 et 128 kilo-octets. La définition d'une taille de charge utile remplace le contenu de la charge utile, car Device Advisor renverra une charge utile prédéfinie avec la taille donnée à l'appareil.
```
"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"
}
}
]
```
**« Device connect réessaie avec intervalle de gigue - Aucune réponse CONNACK"**
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](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) sur l'appareil testé pour réussir ce scénario de test.
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 4 minutes.
```
"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"
}
}
]
```
**« Device connect réessaie avec backoff exponentiel - Aucune réponse CONNACK"**
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](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) sur l'appareil testé pour réussir ce scénario de test.
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 4 minutes.
```
"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"
}
}
]
```
**« Reconnexion de l'appareil avec atténuation de la gigue - Après la déconnexion du serveur »**
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](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) sur l'appareil testé dans ce test.
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 4 minutes.
Le nombre de tentatives de reconnexion pour valider le backoff peut être modifié en spécifiant le `RECONNECTION_ATTEMPTS`. Le nombre doit être compris entre 5 et 10. La valeur par défaut est 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"
}
}
]
```
**« Reconnexion de l'appareil avec réduction de la gigue - Sur connexion instable »**
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](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) sur l'appareil testé dans ce test.
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 4 minutes.
Le nombre de tentatives de reconnexion pour valider le backoff peut être modifié en spécifiant le `RECONNECTION_ATTEMPTS`. Le nombre doit être compris entre 5 et 10. La valeur par défaut est 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"
}
}
]
```
## Publication
**« QoS0 (Happy Case) »**
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.
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"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"
}
}
]
```
**« Nouvelle tentative de publication de QoS1 - Pas de PUBACK »**
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 :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Il est recommandé de le faire pendant au moins 4 minutes.
```
"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"
}
}
]
```
**« Publier les messages conservés »**
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 :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes. Pour exécuter ce scénario de test, ajoutez l'action`iot:RetainPublish` dans [rôle de votre appareil](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role).
```
"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"
}
}
]
```
**« Publier avec la propriété utilisateur »**
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 :*
Il s'agit d'un MQTT5 seul cas de test.
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"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"
}
}
]
```
## S’abonner
**« Je peux m'abonner (Happy Case) »**
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 :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"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"
}
}
]
```
**« Réessayer de s'abonner - Pas de SUBACK »**
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 :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 4 minutes.
```
"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 Ak PingResp »**
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 :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons un délai d'attente supérieur à 1,5 fois la valeur `keepAliveTime` .
La durée maximale `keepAliveTime` ne doit pas dépasser 230 secondes pour ce test.
```
"tests":[
{
"name":"Mqtt No Ack PingResp",
"configuration":
//optional:
"EXECUTION_TIMEOUT":"306", // in seconds
},
"test":{
"id":"MQTT_No_Ack_PingResp",
"version":"0.0.0"
}
}
]
```
## Session persistante
**« Session persistante (Happy Case) »**
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](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
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 à son sujet déclencheur en envoyant un paquet SUBSCRIBE supplémentaire and/or si le client ne reçoit pas le message stocké du sujet déclencheur, le scénario de test échouera.
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'au moins 4 minutes. Lors de la première connexion, l'appareil client doit s'abonner explicitement à un `TRIGGER_TOPIC` qui n'était pas abonné auparavant. Pour réussir le scénario de test, l'appareil client doit s'abonner avec succès à `TRIGGER_TOPIC` avec une QoS 1. Après la reconnexion, le dispositif client est censé comprendre qu'une session permanente est active ; il doit donc accepter le message stocké envoyé par la rubrique déclencheur et renvoyer PUBACK pour ce message spécifique.
```
"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"
}
}
]
```
**« Session persistante - Expiration de session »**
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 :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'au moins 4 minutes. L'appareil de test doit s'abonner explicitement à un `TRIGGER_TOPIC`, auquel il n'était pas abonné auparavant. Pour réussir le scénario de test, l'appareil de test doit envoyer un paquet CONNECT avec l'indicateur `CleanSession` défini sur false et s'abonner avec succès à une rubrique de déclenchement avec une QoS 1. Une fois la connexion établie, AWS IoT Core Device Advisor déconnecte l'appareil. Après la déconnexion, AWS IoT Core Device Advisor permet à l'appareil de se reconnecter, et l'appareil devrait s'abonner à nouveau à ce service, `TRIGGER_TOPIC` car AWS IoT Core Device Advisor aurait mis fin à la session persistante.
```
"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"
}
}
]
```
# Shadow
Utilisez ces tests pour vérifier que vos appareils testés utilisent correctement le service AWS IoT Device Shadow. Pour plus d’informations, consultez [AWS IoT Service Device Shadow](iot-device-shadows.md). Si ces cas de test sont configurés dans votre suite de tests, il est nécessaire de fournir un élément lors du démarrage de l'exécution de la suite.
**Le MQTT over** n' WebSocketest pas pris en charge pour le moment.
## Publication
***« L'appareil publie son état après sa connexion (Happy case) »***
Valide si un appareil peut publier son état après s'être connecté à AWS IoT Core
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"tests":[
{
"name":"my_shadow_publish_reported_state",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"SHADOW_NAME": "SHADOW_NAME",
"REPORTED_STATE": {
"STATE_ATTRIBUTE": "STATE_VALUE"
}
},
"test":{
"id":"Shadow_Publish_Reported_State",
"version":"0.0.0"
}
}
]
```
Les `REPORTED_STATE` peuvent être fournis pour une validation supplémentaire de l'état shadow exact de votre appareil, une fois celui-ci connecté. Par défaut, ce scénario de test valide l'état de publication de votre appareil.
Si `SHADOW_NAME` n'est pas fourni, le scénario de test recherche par défaut les messages publiés dans les préfixes de rubrique du type Unnamed (classic) shadow. Indiquez un nom shadow si votre appareil utilise le type shadow nommé. Consultez la section [Utilisation des shadows dans les appareils](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html) pour plus d'informations.
## Mettre à jour
***« L'appareil met à jour l'état signalé à l'état souhaité (Happy case) »***
Valide si votre appareil lit tous les messages de mise à jour reçus et synchronise l'état de l'appareil pour qu'il corresponde aux propriétés d'état souhaitées. Votre appareil devrait publier son dernier état signalé après la synchronisation. Si votre appareil dispose déjà d'un shadow existant avant d'exécuter le test, assurez-vous que l'état souhaité configuré pour le scénario de test et l'état signalé existant ne correspondent pas déjà. Vous pouvez identifier les messages de mise à jour de Shadow envoyés par Device Advisor en consultant le **ClientToken**champ tel qu'il sera dans le document Shadow`DeviceAdvisorShadowTestCaseSetup`.
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 2 minutes.
```
"tests":[
{
"name":"my_shadow_update_reported_state",
"configuration": {
"DESIRED_STATE": {
"STATE_ATTRIBUTE": "STATE_VALUE"
},
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"SHADOW_NAME": "SHADOW_NAME"
},
"test":{
"id":"Shadow_Update_Reported_State",
"version":"0.0.0"
}
}
]
```
Le `DESIRED_STATE` doit avoir au moins un attribut et une valeur associée.
Si `SHADOW_NAME` n'est pas fourni, alors le scénario de test recherche par défaut les messages publiés dans les préfixes de rubrique du type Unnamed (classic) shadow. Indiquez un nom shadow si votre appareil utilise le type shadow nommé. Consultez la section [Utilisation des shadows dans les appareils](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html) pour plus d'informations.
# Exécution d’une tâche
**« L'appareil peut terminer l'exécution d'une tâche »**
Ce cas de test vous permet de vérifier si votre appareil est en mesure de recevoir des mises à jour à l'aide de AWS IoT Jobs et de publier l'état des mises à jour réussies. Pour plus d'informations sur les AWS IoT offres d'emploi, consultez la section [Offres d'emploi](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
Pour exécuter ce scénario de test avec succès, vous devez attribuer votre [rôle d'appareil](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role) à deux AWS rubriques réservées. Pour vous abonner aux messages liés à l'activité professionnelle, utilisez les rubriques **notify** et **notify-next**. Le rôle de votre appareil doit autoriser l'action PUBLISH pour les rubriques suivantes :
+ \$1aws/things/**thingName**/jobs/**jobId**/get
+ \$1aws/things/**thingName**/jobs/**jobId**/update
Il est recommandé d'accorder les actions SUBSCRIBE et RECEIVE pour les rubriques suivantes :
+ **\$1aws/things/ ThingName/**jobs/get/accepted
+ \$1aws/things/**thingName**/jobs/**jobId**/get/rejected
+ \$1aws/things/**thingName**/jobs/**jobId**/update/accepted
+ \$1aws/things/**thingName**/jobs/**jobId**/update/rejected
Il est recommandé d'accorder l’action SUBSCRIBE pour la rubrique suivante :
+ \$1aws/things/**thingName**/jobs/notify-next
Pour plus d'informations sur ces sujets réservés, consultez la section rubriques réservées aux [AWS IoT Jobs](https://docs.aws.amazon.com/iot/latest/developerguide/reserved-topics.html#reserved-topics-job).
**Le MQTT over** n' WebSocketest pas pris en charge pour le moment.
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 5 minutes. Nous recommandons une valeur de délai d'attente de 3 minutes. En fonction du document ou de la source du AWS IoT Job fourni, ajustez la valeur du délai d'attente (par exemple, si l'exécution d'une tâche prend du temps, définissez une valeur de délai d'expiration plus longue pour le scénario de test). Pour exécuter le test, un document de AWS IoT Job valide ou un ID de job déjà existant est requis. Un document AWS IoT Job peut être fourni sous forme de document JSON ou de lien S3. Si un document job est fourni, la fourniture d’un identifiant job est facultative. Si un identifiant de travail est fourni, Device Advisor l'utilisera pour créer le AWS IoT Job en votre nom. Si le document job n'est pas fourni, vous pouvez fournir un identifiant existant qui se trouve dans la même région que celle dans laquelle vous exécutez le scénario de test. Dans ce cas, Device Advisor utilisera ce AWS IoT Job lors de l'exécution du scénario de test.
```
"tests": [
{
"name":"my_job_execution",
"configuration": {
// optional:
// Test case will create a job task by using either JOB_DOCUMENT or JOB_DOCUMENT_SOURCE.
// If you manage the job task on your own, leave it empty and provide the JOB_JOBID (self-managed job task).
// JOB_DOCUMENT is a JSON formatted string
"JOB_DOCUMENT": "{
\"operation\":\"reboot\",
\"files\" : {
\"fileName\" : \"install.py\",
\"url\" : \"${aws:iot:s3-presigned-url:https://s3.amazonaws.com/bucket-name/key}\"
}
}",
// JOB_DOCUMENT_SOURCE is an S3 link to the job document. It will be used only if JOB_DOCUMENT is not provided.
"JOB_DOCUMENT_SOURCE": "https://s3.amazonaws.com/bucket-name/key",
// JOB_JOBID is mandatory, only if neither document nor document source is provided. (Test case needs to know the self-managed job task id).
"JOB_JOBID": "String",
// JOB_PRESIGN_ROLE_ARN is used for the presign Url, which will replace the placeholder in the JOB_DOCUMENT field
"JOB_PRESIGN_ROLE_ARN": "String",
// Presigned Url expiration time. It must be between 60 and 3600 seconds, with the default value being 3600.
"JOB_PRESIGN_EXPIRES_IN_SEC": "Long"
"EXECUTION_TIMEOUT": "300", // in seconds
},
"test": {
"id": "Job_Execution",
"version": "0.0.0"
}
}
]
```
Pour plus d'informations sur la création et l'utilisation de documents job, consultez [document job](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
# Autorisations et politiques
Vous pouvez utiliser les tests suivants pour déterminer si les politiques associées aux certificats de vos appareils respectent les meilleures pratiques standard.
**Le MQTT over** n' WebSocketest pas pris en charge pour le moment.
**« Les politiques associées aux certificats de l'appareil ne contiennent pas de caractères génériques »**
Valide si les politiques d'autorisation associées à un appareil respectent les meilleures pratiques et n'accordent pas à l'appareil plus d'autorisations que nécessaire.
*Définition du cas de test de l'API :*
`EXECUTION_TIMEOUT` a une valeur par défaut de 1 minute. Nous vous recommandons de définir un délai d'au moins 30 secondes.
```
"tests":[
{
"name":"my_security_device_policies",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"60" // in seconds
},
"test": {
"id": "Security_Device_Policies",
"version": "0.0.0"
}
}
]
```
# 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.
## Cas de test MQTT de longue durée
Dans le cas de test MQTT de longue durée, le comportement de l'appareil est initialement observé dans des scénarios de cas heureux tels que MQTT Connect, Subscribe, Publish et Reconnect. Ensuite, l'appareil est observé dans plusieurs scénarios de défaillance complexes tels que l'interruption de reconnexion MQTT, la déconnexion longue du serveur et la connectivité intermittente.
## Flux d'exécution des scénarios de test MQTT de longue durée
L'exécution d'un scénario de test MQTT de longue durée comporte trois phases :
![\[L' « exécution des tests MQTT de longue durée » qui indique l'exécution des tests de base, l'exécution des tests avancés et le temps d'exécution supplémentaire.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/mqtt-execution-flow.png)
### 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 message CONNECT par un appareil et Broker répond par un message CONNACK avec un code de retour réussi.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/basic-connect.png)
#### 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 message PUBLISH avec le niveau QoS 0.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/Qos0.png)
##### 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`, `PUBACK`initial 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 message PUBLISH de niveau QoS 1 et de multiples interactions avec le courtier.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/Qos1.png)
#### 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 message SUBACK.
![\[Le flux SUBSCRIBE QoS 0 qui inclut un appareil envoyant un message SUBSCRIBE de niveau QoS 0 et un courtier répondant par un message SUBACK et le code Success Maximum QoS 0.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/subscribe-Qos0.png)
##### 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`, `SUBACK`initial 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 message SUBSCRIBE de niveau QoS 1 et de multiples interactions avec le courtier.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/subscribe-Qos1.png)
#### 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 flux RECONNECT entre DUT et le courtier.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/reconnect.png)
### 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.
#### RETURN PUBACK ON 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 flux d'abonnement RETURN PUBACK ON QoS 1 entre DUT et le broker.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/return-puback.png)
#### 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 flux RECEIVE LARGE PAYLOAD entre DUT et le courtier.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/large-payload.png)
#### 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 des sessions persistantes MQTT](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
![\[Le flux PERSISTENT SESSION entre DUT et le broker.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/persistent-session.png)
#### 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 `PUBLISH``SUBSCRIBE`, et les `PINGREQ` messages. Il vérifie également si l'appareil testé déconnecte la connexion MQTT.
![\[Le flux KEEP ALIVE entre DUT et le courtier.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/keep-alive.png)
#### 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 flux de CONNECTIVITÉ INTERMITTENT entre DUT et le courtier.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/intermittent.png)
#### 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](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) sur l'appareil testé dans ce test.
![\[Le flux RECONNECT BACKOFF entre DUT et le courtier.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/reconnect-backoff.png)
#### 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 flux LONG SERVER DISCONNECT entre DUT et le broker.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/longserver-disconnect.png)
### 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.
## Options de configuration des tests de longue durée MQTT
Toutes les options de configuration fournies pour le test de longue durée MQTT sont facultatives. Les options suivantes sont disponibles :
**OPERATIONS**
La liste des opérations effectuées par le périphérique, telles que`CONNECT`, `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\$1TESTS\$1EXECUTION\$1TIME\$1OUT:**
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\$1SERVER\$1DISCONNECT\$1TIME:**
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\$1EXECUTION\$1TIME:**
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\$1CONNECTION\$1ATTEMPTS:**
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\$1PAYLOAD\$1FORMAT:**
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é.
**Définition du cas de test de l'API :**
```
{
"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"
}
}
]
}
```
## Journal récapitulatif du scénario de test MQTT de longue durée
Le scénario de test de longue durée MQTT s'exécute sur une plus longue durée que les scénarios de test classiques. 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 inclut notamment les éléments suivants :
+ *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.*