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.
# Device Advisor
[Device Advisor](https://aws.amazon.com/iot-core/features/) est une fonctionnalité de test entièrement gérée basée sur le cloud qui permet de valider les appareils IoT lors du développement du logiciel des appareils. Device Advisor propose des tests prédéfinis que vous pouvez utiliser pour valider les appareils IoT afin de garantir une connectivité fiable et sécurisée AWS IoT Core, avant de les déployer en production. Les tests prédéfinis de Device Advisor vous aident à valider le logiciel de votre appareil par rapport aux meilleures pratiques en matière d'utilisation des protocoles [TLS](https://docs.aws.amazon.com//iot/latest/developerguide/protocols.html), [MQTT](https://docs.aws.amazon.com//iot/latest/developerguide/protocols.html), [Device Shadow](https://docs.aws.amazon.com//iot/latest/developerguide/iot-device-shadows.html), et [IoT Jobs](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html). Vous pouvez également télécharger des rapports de qualification signés à soumettre au AWS Partner Network afin que votre appareil soit qualifié pour le [AWS Partner Device Catalog](https://devices.amazonaws.com/) (catalogue d'appareils partenaires) sans avoir à envoyer votre appareil et à attendre qu'il soit testé.
**Note**
Device Advisor est pris en charge dans les régions us-west-1 et eu-west-1.
Device Advisor prend en charge les appareils et les clients qui utilisent les protocoles MQTT et MQTT over WebSocket Secure (WSS) pour publier des messages et s'y abonner. Tous les protocoles prennent en charge IPv4 et IPv6.
Device Advisor prend en charge les certificats de serveur RSA.
Tout appareil conçu pour se connecter AWS IoT Core peut tirer parti de Device Advisor. Vous pouvez accéder à Device Advisor depuis la [AWS IoT console](https://us-east-1.console.aws.amazon.com/iot/home?region=us-east-1#/deviceadvisor/intro) ou à l'aide du AWS CLI SDK. Lorsque vous êtes prêt à tester votre appareil, enregistrez-le auprès du terminal Device Advisor AWS IoT Core et configurez-le avec le logiciel de l'appareil. Choisissez ensuite les tests prédéfinis, configurez-les, exécutez les tests sur votre appareil et obtenez les résultats des tests ainsi que des journaux détaillés ou un rapport de qualification.
Device Advisor est un point de terminaison de test dans le AWS cloud. Vous pouvez tester vos appareils en les configurant pour qu'ils se connectent au point de terminaison de test fourni par le Device Advisor. Une fois qu'un appareil est configuré pour se connecter au point de terminaison de test, vous pouvez accéder à la console Device Advisor ou utiliser le AWS SDK pour choisir les tests que vous souhaitez exécuter sur vos appareils. Device Advisor gère ensuite le cycle de vie complet d'un test, y compris le provisionnement des ressources, la planification du processus de test, la gestion de la machine d'état, l'enregistrement du comportement de l'appareil, l'enregistrement des résultats et la fourniture des résultats finaux sous forme de rapport de test.
**Protocoles TLS**
Le protocole TLS (Transport Layer Security) est utilisé pour chiffrer les données confidentielles sur des réseaux non sécurisés comme Internet. Le protocole TLS est le successeur du protocole Secure Sockets Layer (SSL).
Device Advisor prend en charge les protocoles TLS suivants :
+ TLS 1.3 (recommandé)
+ TLS 1.2
**Protocols, port mappings, and authentication** (Protocoles, mappages de ports et authentification)
Le protocole de communication de l'appareil est utilisé par un appareil ou un client pour se connecter au courtier de messages en utilisant un point de terminaison du dispositif. Le tableau suivant répertorie les protocoles pris en charge par les points de terminaison Device Advisor ainsi que les méthodes d'authentification et les ports utilisés.
**Protocoles, authentification et mappages de port**
| Protocole | Opérations prises en charge | Authentification | Port | Nom du protocole ALPN |
| --- | --- | --- | --- | --- |
| MQTT terminé WebSocket | Publier, S'abonner | Signature Version 4 | 443 | N/A |
| MQTT | Publier, S'abonner | Certificat de client X.509 | 8883 | `x-amzn-mqtt-ca` |
| MQTT | Publier, S'abonner | Certificat de client X.509 | 443 | N/A |
**Topics**
+ [Configuration](device-advisor-setting-up.md)
+ [Premiers pas avec Device Advisor dans la console](da-console-guide.md)
+ [Flux de travail Device Advisor](device-advisor-workflow.md)
+ [Flux de travail détaillé sur la console Device Advisor](device-advisor-console-tutorial.md)
+ [Flux de travail de la console de tests de longue durée](device-advisor-long-duration-console-tutorial.md)
+ [Points de terminaison d’un VPC Device Advisor (AWS PrivateLink)](device-advisor-vpc-endpoint.md)
+ [Cas de test Device Advisor](device-advisor-tests.md)
# Configuration
Avant d'utiliser Device Advisor pour la première fois, effectuez les tâches suivantes :
## Création d’un objet IoT
Tout d'abord, créez un objet IoT et associez un certificat. Pour un didacticiel sur la création d'objets, voir [Création d'un d'objet](https://docs.aws.amazon.com/iot/latest/developerguide/create-iot-resources.html#create-aws-thing).
## Créer un rôle IAM à utiliser comme rôle de périphérique
**Note**
Vous pouvez rapidement créer le rôle d'appareil à l'aide de la console Device Advisor. Pour savoir comment configurer le rôle de votre appareil avec la console Device Advisor, consultez [Commencer à utiliser Device Advisor dans la console](https://docs.aws.amazon.com/iot/latest/developerguide/da-console-guide.html).
1. Accédez à la [Gestion des identités et des accès AWS console](https://console.aws.amazon.com/iam/home?region=us-west-2#/home) et connectez-vous à celle que Compte AWS vous utilisez pour tester Device Advisor.
1. Dans le panneau de navigation de gauche, choisissez **Politiques**.
1. Choisissez **Create Policy** (Créer une politique).
1. Sous **Review Policy (Examiner une politique)**, procédez comme suit :
1. Pour **Service**, choisissez **loT**.
1. Sous **Actions**, effectuez l'une des opérations suivantes :
+ (Recommandé) Sélectionnez les actions en fonction de la politique associée à l'objet ou au certificat IoT que vous avez créé dans la section précédente.
+ Recherchez les actions suivantes dans **Filter action** (Action de filtrage) et sélectionnez-les :
+ `Connect`
+ `Publish`
+ `Subscribe`
+ `Receive`
+ `RetainPublish`
1. Sous **Ressources**, limitez le client, le sujet et les ressources du sujet. Restreindre ces ressources constitue une bonne pratique de sécurité. Pour limiter les ressources, procédez comme suit :
1. Choisissez **Spécifier l'ARN de la ressource client pour l'action Connect**.
1. Choisissez **Ajouter un ARN**, puis effectuez l'une des opérations suivantes :
**Note**
Le *clientId* est l'ID du client MQTT que votre appareil utilise pour interagir avec Device Advisor.
+ Spécifiez la **Région**, **accountID**, et le **clientID** dans l'éditeur visuel ARN.
+ Entrez manuellement les Amazon Resource Names (ARNs) des sujets IoT avec lesquels vous souhaitez exécuter vos scénarios de test.
1. Choisissez **Ajouter**.
1. Choisissez **Specify topic resource ARN for the Receive and one more action**. (Spécifiez l’ARN de la ressource de sujet pour la réception et une autre action)
1. Choisissez **Ajouter un ARN**, puis effectuez l'une des opérations suivantes :
**Note**
Le *topic name* (nom de rubrique) est lz rubrique MQTT sur lequel votre appareil publie des messages.
+ Spécifiez la **Région**, **accountID**, et le **Topic name** dans l'éditeur visuel ARN.
+ Entrez manuellement ARNs les sujets IoT avec lesquels vous souhaitez exécuter vos scénarios de test.
1. Choisissez **Ajouter**.
1. Choisissez **Spécifier l'ARN de la ressource TopicFilter pour l'action Subscribe**.
1. Choisissez **Ajouter un ARN**, puis effectuez l'une des opérations suivantes :
**Note**
Le *topic name* (nom de rubrique) est la rubrique MQTT à laquelle votre appareil est abonné.
+ Spécifiez la **Région**, **accountID**, et le **Topic name** dans l'éditeur visuel ARN.
+ Entrez manuellement ARNs les sujets IoT avec lesquels vous souhaitez exécuter vos scénarios de test.
1. Choisissez **Ajouter**.
1. Choisissez **Suivant : Balises**.
1. Choisissez **Suivant : Vérification**.
1. Sous **Review policy**, (Examiner une politique), saisissez un **Nom** pour votre politique.
1. Choisissez **Create Policy** (Créer une politique).
1. Dans le panneau de navigation de gauche, choisissez **Rôles**.
1. Choisissez **Create Role** (Créer un rôle).
1. Sous **Select trusted entity** (Sélectionner une entité de confiance) , choisissez **Custom trust policy**. (Stratégie de confiance personnalisée)
1. Entrez la politique de confiance suivante dans le champ **Custom trust policy** (Politique de confiance personnalisée) Ajoutez les clés de condition globale `[aws:SourceArn](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` et `[aws:SourceAccount](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` à la politique pour vous protéger contre le problème de l’adjoint confus.
**Important**
Votre `aws:SourceArn` doit se conformer à la section `format: arn:aws:iotdeviceadvisor:region:account-id:*.` Assurez-vous que `region` correspond à votre AWS IoT région et que `account-id` correspond à votre numéro de compte client. Pour plus d’informations, consultez [Prévention du problème de l’adjoint confus entre services](https://docs.aws.amazon.com/iot/latest/developerguide/security-best-practices.html#cross-service-confused-deputy-prevention-DA).
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAwsIoTCoreDeviceAdvisor",
"Effect": "Allow",
"Principal": {
"Service": "iotdeviceadvisor.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:iotdeviceadvisor:*:123456789012:suitedefinition/*"
}
}
}
]
}
```
1. Choisissez **Suivant**.
1. Choisissez la politique que vous avez créée à l'étape 4.
1. (Facultatif) Sous **Définir la limite d'autorisations**, choisissez **Utiliser une limite des autorisations pour contrôler les autorisations de rôle maximales**, puis sélectionnez la stratégie que vous avez créée.
1. Choisissez **Suivant**.
1. Entrez un **nom de rôle** et une **description**.
1. Choisissez **Créer un rôle**.
## Créez une politique gérée par le client pour qu'un utilisateur IAM puisse utiliser Device Advisor
1. Accédez à la console IAM à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. Si vous y êtes invité, saisissez vos informations d'identification AWS .
1. Dans le volet de navigation de gauche, choisissez **Politiques**.
1. Choisissez **Create policy (Créer une politique)**, puis choisissez l'onglet **JSON**.
1. Ajoutez les autorisations nécessaires pour utiliser Device Advisor. Le document de politique se trouve dans la rubrique [Bonnes pratiques en matière de sécurité](https://docs.aws.amazon.com/iot/latest/developerguide/security-best-practices.html#device-advisor-perms).
1. Choisissez **Review Policy (Examiner une stratégie)**.
1. Saisissez un **Name (Nom)** et une **Description**.
1. Choisissez **Create Policy (Créer une stratégie)**.
## Création d'un utilisateur IAM pour utiliser Device Advisor
**Note**
Nous vous recommandons de créer un utilisateur IAM à utiliser lorsque vous exécutez des tests Device Advisor. L'exécution de tests Device Advisor par un utilisateur administrateur peut présenter des risques de sécurité et n'est donc pas recommandée.
1. Accédez à la console IAM sur [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)Si vous y êtes invité, entrez vos AWS informations d'identification pour vous connecter.
1. Dans le volet de navigation de gauche, choisissez **Utilisateurs**.
1. Sélectionnez **Ajouter un utilisateur**.
1. Entrez un **nom d'utilisateur**.
1. Les utilisateurs ont besoin d'un accès programmatique s'ils souhaitent interagir avec AWS l'extérieur du AWS Management Console. La manière d'accorder un accès programmatique dépend du type d'utilisateur qui y accède AWS.
Pour accorder aux utilisateurs un accès programmatique, choisissez l’une des options suivantes.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/device-advisor-setting-up.html)
1. Choisissez **Suivant : Autorisations**.
1. Pour activer l’accès, ajoutez des autorisations à vos utilisateurs, groupes ou rôles :
+ Utilisateurs et groupes dans AWS IAM Identity Center :
Créez un jeu d’autorisations. Suivez les instructions de la rubrique [Création d’un jeu d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) du *Guide de l’utilisateur AWS IAM Identity Center *.
+ Utilisateurs gérés dans IAM par un fournisseur d’identité :
Créez un rôle pour la fédération d’identité. Suivez les instructions de la rubrique [Création d’un rôle pour un fournisseur d’identité tiers (fédération)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) dans le *Guide de l’utilisateur IAM*.
+ Utilisateurs IAM :
+ Créez un rôle que votre utilisateur peut assumer. Suivez les instructions de la rubrique [Création d’un rôle pour un utilisateur IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*.
+ (Non recommandé) Attachez une politique directement à un utilisateur ou ajoutez un utilisateur à un groupe d’utilisateurs. Suivez les instructions de la rubrique [Ajout d’autorisations à un utilisateur (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) du *Guide de l’utilisateur IAM*.
1. Entrez le nom de la politique gérée par le client que vous avez créée dans la zone de recherche. Cochez ensuite la case **Nom de la stratégie**.
1. Choisissez **Suivant : Balises**.
1. Choisissez **Next: Review (Suivant : Vérification)**.
1. Choisissez **Create user**.
1. Choisissez **Close (Fermer)**.
Device Advisor a besoin d'accéder à vos AWS ressources (objets, certificats et terminaux) en votre nom. Votre utilisateur IAM doit disposer des autorisations nécessaires. Device Advisor publiera également des journaux sur Amazon CloudWatch si vous associez la politique d'autorisation nécessaire à votre utilisateur IAM.
## Configurer votre appareil
Device Advisor utilise l'extension TLS d'indication de nom de serveur (SNI) pour appliquer les configurations TLS. Les appareils doivent utiliser cette extension lorsqu'ils se connectent et transmettent un nom de serveur identique à celui du point de terminaison de test Device Advisor.
Device Advisor autorise la connexion TLS lorsqu'un test est en cours `Running`. Il refuse la connexion TLS avant et après chaque test. C'est pourquoi nous vous recommandons d'utiliser le mécanisme de nouvelle tentative de connexion de l'appareil pour une expérience de test entièrement automatisée avec Device Advisor. Vous pouvez exécuter des suites de tests qui incluent plusieurs scénarios de test, telles que TLS connect, MQTT connect et MQTT publish. Si vous exécutez plusieurs scénarios de test, nous recommandons que votre appareil essaie de se connecter à notre point de terminaison de test toutes les cinq secondes. Vous pouvez ensuite automatiser l'exécution de plusieurs scénarios de test en séquence.
**Note**
Pour préparer le logiciel de votre appareil à des fins de test, nous vous recommandons d'utiliser un SDK auquel vous pouvez vous connecter AWS IoT Core. Vous devez ensuite mettre à jour le SDK avec le point de terminaison de test Device Advisor fourni pour votre Compte AWS.
Device Advisor prend en charge deux types de points de terminaison : les points de terminaison au niveau du compte et au niveau de l'appareil. Choisissez le point de terminaison qui correspond le mieux à votre cas d’utilisation. Pour exécuter simultanément plusieurs suites de tests pour différents appareils, utilisez un point de terminaison au niveau de l'appareil.
Exécutez la commande suivante pour obtenir le point de terminaison au niveau de l'appareil :
Pour les clients MQTT utilisant des certificats client X.509 :
```
aws iotdeviceadvisor get-endpoint --thing-arn your-thing-arn
```
or
```
aws iotdeviceadvisor get-endpoint --certificate-arn your-certificate-arn
```
Pour les WebSocket clients MQTT over utilisant Signature Version 4 :
```
aws iotdeviceadvisor get-endpoint --device-role-arn your-device-role-arn --authentication-method SignatureVersion4
```
Pour exécuter une suite de tests à la fois, choisissez un point de terminaison au niveau du compte. Exécutez la commande suivante pour obtenir le point de terminaison au niveau du compte :
```
aws iotdeviceadvisor get-endpoint
```
# Premiers pas avec Device Advisor dans la console
Ce didacticiel vous aide à démarrer AWS IoT Core Device Advisor sur la console. Device Advisor propose des fonctionnalités telles que les tests obligatoires et les rapports de qualification signés. Vous pouvez utiliser ces tests et rapports pour qualifier et répertorier les appareils dans [AWS Partner Device Catalog](https://devices.amazonaws.com/) (catalogue des appareils partenaires), comme indiqué dans le [programme de AWS IoT Core qualification](https://aws.amazon.com/partners/dqp/).
Pour plus d'informations sur l'utilisation de Device Advisor, consultez [Flux de travail Device Advisor](device-advisor-workflow.md) et [Flux de travail détaillé sur la console Device Advisor](device-advisor-console-tutorial.md).
Pour terminer ce didacticiel, suivez les étapes décrites dans [Configuration](device-advisor-setting-up.md).
**Note**
Device Advisor est compatible dans les domaines suivants Régions AWS :
USA Est (Virginie du Nord)
USA Ouest (Oregon)
Asie Pacifique (Tokyo)
Europe (Irlande)
**Prise en main**
1. Dans le volet de navigation de la[AWS IoT console](https://console.aws.amazon.com//iot), sous **Test**, choisissez **Device Advisor**. Cliquez ensuite sur le bouton **Démarrer la procédure pas à pas** sur la console.
![\[Device Advisor est une fonctionnalité de test entièrement gérée pour les appareils IoT qui permet de valider une interaction sécurisée avec AWS IoT Core, d'identifier les problèmes logiciels et d'obtenir les résultats des tests.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-gs.png)
1. La page **Commencer à utiliser Device Advisor** fournit un aperçu des étapes nécessaires pour créer une suite de tests et exécuter des tests sur votre appareil. Vous trouverez également le point de terminaison de test Device Advisor pour votre compte ici. Vous devez configurer le microprogramme ou le logiciel de l'appareil utilisé pour les tests afin de vous connecter à ce point de terminaison de test.
Pour terminer ce didacticiel, [créez d'abord un objet et un certificat](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-create-thing-certificate). Après avoir examiné les informations de la section **Fonctionnement**, choisissez **Suivant**.
![\[Étapes pour tester la connectivité des appareils IoT : sélectionner le protocole, créer une suite de tests, configurer les paramètres des appareils.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-gs1.png)
1. À **l'étape 1 : Sélectionnez un protocole**, sélectionnez un protocole parmi les options répertoriées. Ensuite, choisissez **Suivant**.
![\[Interface Device Advisor affichant les options permettant de sélectionner un protocole de communication (MQTT 3.1.1, MQTT 3.1.1 over WebSocket, MQTT 5 over) WebSocket pour tester un appareil IoT.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-protocol.png)
1. À **l'étape 2**, vous créez et configurez une suite de tests personnalisée. Une suite de tests personnalisée doit comporter au moins un groupe de test, et chaque groupe de test doit comporter au moins un cas de test. Nous avons ajouté le scénario de test **MQTT Connect** pour que vous puissiez commencer.
Choisissez **Propriétés de la suite de tests**.
![\[L'écran « Créer une suite de tests » dans Device Advisors, où les utilisateurs peuvent créer et configurer des groupes de test et des cas pour tester des appareils IoT avec le protocole MQTT.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-test-suite-create.png)
Indiquez les propriétés de la suite de tests lorsque vous créez votre suite de tests. Vous pouvez configurer les propriétés suivantes au niveau de la suite :
+ **Test suite name**: (Nom de la suite de tests) entrez le nom de votre suite de tests.
+ **Timeout** (optional) Délai(facultatif) délai d'expiration (en secondes) pour chaque scénario de test de la suite de tests actuelle. Si vous ne spécifiez pas de valeur de délai d'attente, la valeur par défaut est utilisée.
+ **Balises** (facultatif) : ajoutez des balises à la suite de tests.
Lorsque vous avez terminé, choisissez **Mettre à jour les propriétés**.
![\[Formulaire pour mettre à jour les propriétés d'une suite de tests, notamment le nom, le délai d'expiration et la possibilité d'ajouter des balises. Contient un bouton « Mettre à jour les propriétés ».\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-test-suite-properties.png)
1. (Facultatif) Pour mettre à jour la configuration du groupe de suites de tests, cliquez sur le bouton **Modifier** à côté du nom du groupe de tests.
+ **Name (Nom)** : Entrez un nom personnalisé pour le groupe de suites de tests.
+ **Timeout** (optional) Délai(facultatif) délai d'expiration (en secondes) pour chaque scénario de test de la suite de tests actuelle. Si vous ne spécifiez pas de valeur de délai d'attente, la valeur par défaut est utilisée.
Lorsque vous avez terminé, choisissez **Done** (Terminé) pour continuer.
![\[Un groupe de test nommé « Groupe de test 1 » s'affiche avec des options permettant de configurer le délai d'expiration et d'ajouter d'autres groupes de test.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-test-suite-config.png)
1. (Facultatif) Pour mettre à jour la configuration d'un scénario de test, choisissez le bouton **Edit** (Modifier) en regard du nom du scénario de test.
+ **Name (Nom)** : Entrez un nom personnalisé pour le groupe de suites de tests.
+ **Délai** (facultatif) : délai d'expiration (en secondes) pour le scénario de test sélectionné. Si vous ne spécifiez pas de valeur de délai d'attente, la valeur par défaut est utilisée.
Lorsque vous avez terminé, choisissez **Done** (Terminé) pour continuer.
![\[L'interface « Créer une suite de tests » qui affiche les options permettant de configurer une suite de tests, des groupes de tests et des cas de test individuels pour tester les appareils IoT.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-test-case-config.png)
1. (Facultatif) Pour ajouter d'autres groupes de tests à la suite de tests, choisissez **Ajouter un groupe de test**, puis suivez les instructions de l'étape 5.
1. (Facultatif) Pour ajouter d'autres scénarios de test, faites glisser les cas de test de la section **Cas** de test vers l'un de vos groupes de tests.
![\[L'interface « Créer une suite de tests » où les utilisateurs peuvent configurer des groupes de test et des cas de test pour les tests du protocole MQTT sur les appareils IoT.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-drag.png)
1. Vous pouvez modifier l'ordre de vos groupes de test et de vos scénarios de test. Pour apporter des modifications, faites glisser les scénarios de test répertoriés vers le haut ou vers le bas de la liste. Device Advisor exécute les tests dans l'ordre dans lequel vous les avez listés.
Après avoir configuré votre suite de tests, choisissez **Next**.
1. À **l'étape 3**, sélectionnez un AWS IoT objet ou un certificat à tester à l'aide de Device Advisor. Si vous n'avez aucun élément ou certificat existant, consultez la section [Configuration](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html).
![\[Les options de configuration qui incluent la sélection d'un protocole, la création d'une suite de tests, la configuration des paramètres de l'appareil et l'examen des essais et des résultats.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-device-settings.png)
1. Vous pouvez configurer un rôle d'appareil que Device Advisor utilise pour effectuer des actions AWS IoT MQTT au nom de votre périphérique de test. Pour le cas de test **MQTT Connect** uniquement, l'action **Connect** est sélectionnée automatiquement. Cela est dû au fait que le rôle d’appareil nécessite cette autorisation pour exécuter la suite de tests. Pour les autres cas de test, les actions correspondantes sont sélectionnées.
Indiquez les valeurs des ressources pour chacune des actions sélectionnées. Par exemple, pour l'action **Connect**, indiquez l'ID client que votre appareil utilise pour se connecter au point de terminaison Device Advisor. Vous pouvez fournir plusieurs valeurs séparées par des virgules et des valeurs de préfixe avec un caractère générique (\$1). Par exemple, pour autoriser la publication sur une rubrique commençant par `MyTopic`, entrez **MyTopic\$1** comme valeur de ressource.
![\[L'interface Device Advisor dans laquelle vous pouvez sélectionner un rôle d'appareil et définir des autorisations pour la connexion, la publication, l'abonnement et la gestion des sujets et des clients MQTT. IDs\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-device-role.png)
Pour utiliser un rôle d'appareil créé précédemment dans [Configuration](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html), choisissez **Sélectionner un rôle existant**. Choisissez ensuite le rôle de votre appareil sous **Sélectionner un rôle**.
![\[Interface de formulaire Web permettant de sélectionner un rôle sur l'appareil, avec des options permettant de créer un nouveau rôle ou de sélectionner un rôle existant nommé « DeviceAdvisorServiceRole ».\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-select-device-role.png)
Configurez le rôle de votre appareil à l'aide de l'une des deux options proposées, puis choisissez **Next**.
1. Dans la section **Tester le point de terminaison**, sélectionnez le point de terminaison qui convient le mieux à votre cas d'utilisation. Pour exécuter plusieurs suites de tests simultanément avec la même suite Compte AWS, sélectionnez le point de terminaison **au niveau de l'appareil**. Pour exécuter une suite de tests à la fois, sélectionnez **Point de terminaison au niveau du compte**.
![\[Options permettant de sélectionner un point de terminaison au niveau du compte ou au niveau de l'appareil à tester, avec une URL de point de terminaison fournie et le bouton Suivant.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-endpoint.png)
1. **L'étape 4** présente une vue d'ensemble du périphérique de test sélectionné, du point de terminaison de test, de la suite de tests et du rôle d’appareil de test configurés. Pour apporter des modifications à une section, choisissez le bouton **Edit (Modifier)** correspondant à la section que vous souhaitez modifier. Une fois que vous avez confirmé votre configuration de test, choisissez **Exécuter** pour créer la suite de tests et exécuter vos tests.
**Note**
Pour de meilleurs résultats, vous pouvez connecter l'appareil de test sélectionné au point de terminaison de test Device Advisor avant de démarrer l'exécution de la suite de tests. Nous vous recommandons de créer un mécanisme permettant à votre appareil d'essayer de se connecter à notre point de terminaison de test toutes les cinq secondes pendant une à deux minutes au maximum.
![\[Console de configuration de l'appareil qui affiche les détails du rôle de l'appareil, le point de terminaison de test et les options d'annulation, de retour en arrière ou d'exécution.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-device-review.png)
![\[Console de configuration de l'appareil qui affiche les détails du rôle de l'appareil, le point de terminaison de test et les options d'annulation, de retour en arrière ou d'exécution.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-device-review-contd.png)
1. Dans le volet de navigation, sous **Test**, choisissez **Device Advisor**, puis sélectionnez **Test runs and results (Tests et résultats)**. Sélectionnez l'exécution d'une suite de tests pour afficher les détails de son exécution et ses journaux.
![\[L'interface de la suite de tests qui indique qu'un test MQTT 3.1.1 est en cours pour le périphérique « »MyThing.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-console-runs-results.png)
1. Pour accéder aux CloudWatch journaux Amazon de la suite, exécutez :
+ Choisissez **Test suite log** pour afficher les CloudWatch journaux relatifs à l'exécution de la suite de tests.
+ Choisissez **Journal des cas de test** pour n'importe quel cas de test afin d'afficher les CloudWatch journaux spécifiques au cas de test.
1. En fonction des résultats de vos tests, [troubleshoot](https://docs.aws.amazon.com/iot/latest/developerguide/iot_troubleshooting.html#device-advisor-troubleshooting) (dépannez) votre appareil jusqu'à ce que tous les tests réussissent.
# Flux de travail Device Advisor
Ce didacticiel explique comment créer une suite de tests personnalisée et exécuter des tests sur le périphérique que vous souhaitez tester dans la console. Une fois les tests terminés, vous pouvez consulter les résultats et les journaux détaillés.
## Conditions préalables
Avant de commencer ce didacticiel, suivez les étapes décrites dans [Configuration](device-advisor-setting-up.md).
## Création d'une définition de suite de tests
[Installez d'abord un AWS SDK.](https://docs.aws.amazon.com/iot/latest/developerguide/iot-connect-service.html#iot-service-sdks)
### Syntaxe de `rootGroup`
Un groupe racine est une chaîne JSON qui indique les cas de test à inclure dans votre suite de tests. Il spécifie également toutes les configurations nécessaires pour ces cas de test. Utilisez le groupe racine pour structurer et organiser votre suite de tests en fonction de vos besoins. La hiérarchie d'une suite de tests est la suivante :
```
test suite → test group(s) → test case(s)
```
Une suite de tests doit comporter au moins un groupe de test, et chaque groupe de test doit comporter au moins un cas de test. Device Advisor exécute les tests dans l'ordre dans lequel vous définissez les groupes de tests et les scénarios de test.
Chaque groupe racine suit cette structure de base :
```
{
"configuration": { // for all tests in the test suite
"": ""
}
"tests": [{
"name": ""
"configuration": { // for all sub-groups in this test group
"": ""
},
"tests": [{
"name": ""
"configuration": { // for all test cases in this test group
"": ""
},
"test": {
"id": ""
"version": ""
}
}]
}]
}
```
Dans le groupe racine, vous définissez la suite de tests avec un `name``configuration`, et le `tests` qui contient le groupe. Le groupe `tests` contient les définitions des tests individuels. Vous définissez chaque test avec un `name``configuration`, et un `test` bloc qui définit les cas de test pour ce test. Enfin, chaque cas de test est défini avec un `id` et `version`.
Pour plus d'informations sur l'utilisation des champs `"id"` et `"version"` pour chaque cas de test (`test` bloc), consultez [Cas de test Device Advisor](device-advisor-tests.md). Cette section contient également des informations sur les paramètres `configuration` disponibles.
Le bloc suivant est un exemple de configuration de groupe racine. Cette configuration spécifie les cas de test *MQTT Connect Happy Case* et *MQTT Connect Exponential Backoff Retries*, ainsi que les descriptions des champs de configuration.
```
{
"configuration": {}, // Suite-level configuration
"tests": [ // Group definitions should be provided here
{
"name": "My_MQTT_Connect_Group", // Group definition name
"configuration": {} // Group definition-level configuration,
"tests": [ // Test case definitions should be provided here
{
"name": "My_MQTT_Connect_Happy_Case", // Test case definition name
"configuration": {
"EXECUTION_TIMEOUT": 300 // Test case definition-level configuration, in seconds
},
"test": {
"id": "MQTT_Connect", // test case id
"version": "0.0.0" // test case version
}
},
{
"name": "My_MQTT_Connect_Jitter_Backoff_Retries", // Test case definition name
"configuration": {
"EXECUTION_TIMEOUT": 600 // Test case definition-level configuration, in seconds
},
"test": {
"id": "MQTT_Connect_Jitter_Backoff_Retries", // test case id
"version": "0.0.0" // test case version
}
}]
}]
}
```
Vous devez fournir la configuration du groupe racine lorsque vous créez la définition de votre suite de tests. Enregistrez le `suiteDefinitionId` renvoyé dans l’objet de réponse. Vous pouvez utiliser cet ID pour récupérer les informations de définition de votre suite de tests et exécuter votre suite de tests.
Voici un exemple de SDK Java :
```
response = iotDeviceAdvisorClient.createSuiteDefinition(
CreateSuiteDefinitionRequest.builder()
.suiteDefinitionConfiguration(SuiteDefinitionConfiguration.builder()
.suiteDefinitionName("your-suite-definition-name")
.devices(
DeviceUnderTest.builder()
.thingArn("your-test-device-thing-arn")
.certificateArn("your-test-device-certificate-arn")
.deviceRoleArn("your-device-role-arn") //if using SigV4 for MQTT over WebSocket
.build()
)
.rootGroup("your-root-group-configuration")
.devicePermissionRoleArn("your-device-permission-role-arn")
.protocol("MqttV3_1_1 || MqttV5 || MqttV3_1_1_OverWebSocket || MqttV5_OverWebSocket")
.build()
)
.build()
)
```
## Obtenir une définition de suite de tests
Après avoir créé la définition de votre suite de tests, vous recevez `suiteDefinitionId` l'objet de réponse de l'opération d'API `CreateSuiteDefinition`.
Lorsque l'opération renvoie le `suiteDefinitionId`, vous pouvez voir de nouveaux champs `id` dans chaque groupe et une définition de cas de test dans le groupe racine. Vous pouvez les utiliser IDs pour exécuter un sous-ensemble de la définition de votre suite de tests.
Exemples de SDK Java
```
response = iotDeviceAdvisorClient.GetSuiteDefinition(
GetSuiteDefinitionRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.build()
)
```
## Obtenez un point de terminaison de test
Utilisez l'opération `GetEndpoint` API pour obtenir le point de terminaison de test utilisé par votre appareil. Sélectionnez le point de terminaison qui correspond le mieux à votre test. Pour exécuter simultanément plusieurs suites de tests, utilisez le point de terminaison au niveau de l'appareil en fournissant un `thing ARN`, `certificate ARN`, ou `device role ARN`. Pour exécuter une seule suite de tests, ne fournissez aucun argument à l' GetEndpoint opération permettant de choisir le point de terminaison au niveau du compte.
Exemples de kit SDK :
```
response = iotDeviceAdvisorClient.getEndpoint(GetEndpointRequest.builder()
.certificateArn("your-test-device-certificate-arn")
.thingArn("your-test-device-thing-arn")
.deviceRoleArn("your-device-role-arn") //if using SigV4 for MQTT over WebSocket
.build())
```
## Lancer l'exécution d'une suite de test
Après avoir créé une définition de suite de tests et configuré votre appareil de test pour qu'il se connecte à votre point de terminaison de test Device Advisor, exécutez votre suite de tests avec l'API `StartSuiteRun`.
Pour les clients MQTT, utilisez l'un ou l'autre `certificateArn` ou `thingArn` pour exécuter la suite de tests. Si les deux sont configurés, le certificat est utilisé s'il appartient à l'objet.
Pour MQTT over WebSocket customer, utilisez-le `deviceRoleArn` pour exécuter la suite de tests. Si le rôle spécifié est différent du rôle spécifié dans la définition de la suite de tests, le rôle spécifié remplace le rôle défini.
Pour `.parallelRun()`, utilisez `true` si vous utilisez un point de terminaison au niveau de l'appareil pour exécuter plusieurs suites de tests en parallèle en utilisant une seule Compte AWS.
Exemples de kit SDK :
```
response = iotDeviceAdvisorClient.startSuiteRun(StartSuiteRunRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunConfiguration(SuiteRunConfiguration.builder()
.primaryDevice(DeviceUnderTest.builder()
.certificateArn("your-test-device-certificate-arn")
.thingArn("your-test-device-thing-arn")
.deviceRoleArn("your-device-role-arn") //if using SigV4 for MQTT over WebSocket
.build())
.parallelRun(true | false)
.build())
.build())
```
Enregistrez le `suiteRunId` de la réponse. Vous l'utiliserez pour récupérer les résultats de cette suite de tests exécutée.
## Exécutez une suite de tests
Après avoir lancé l'exécution d'une suite de test, vous pouvez vérifier sa progression et ses résultats à l'aide de l'API `GetSuiteRun`.
Exemples de kit SDK :
```
// Using the SDK, call the GetSuiteRun API.
response = iotDeviceAdvisorClient.GetSuiteRun(
GetSuiteRunRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunId("your-suite-run-id")
.build())
```
## Arrêter l'exécution d'une suite de tests
Pour arrêter l'exécution d'une suite de tests toujours en cours, vous pouvez appeler l'opération API `StopSuiteRun`. Une fois que vous avez appelé l'opération `StopSuiteRun`, le service lance le processus de nettoyage. Pendant que le service exécute le processus de nettoyage, la suite de test exécute des mises à jour de statut sur `Stopping`. Le processus de nettoyage peut prendre plusieurs minutes. Une fois le processus terminé, la suite de tests exécute des mises à jour de statut sur `Stopped`. Une fois qu'un cycle de test est complètement arrêté, vous pouvez lancer une autre suite de test. Vous pouvez vérifier régulièrement l'état d'exécution de la suite à l'aide de l'opération API `GetSuiteRun`, comme indiqué dans la section précédente.
Exemples de kit SDK :
```
// Using the SDK, call the StopSuiteRun API.
response = iotDeviceAdvisorClient.StopSuiteRun(
StopSuiteRun.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunId("your-suite-run-id")
.build())
```
## Obtenez un rapport de qualification pour une exécution réussie de la suite de tests de qualification
Si vous exécutez une suite de tests de qualification qui se termine avec succès, vous pouvez récupérer un rapport de qualification avec l'opération d'API `GetSuiteRunReport`. Vous utilisez ce rapport de qualification pour qualifier votre appareil dans le cadre du programme AWS IoT Core de qualification. Pour déterminer si votre suite de tests est une suite de tests de qualification, vérifiez si le paramètre `intendedForQualification` est défini sur `true`. Après avoir appelé l'opération API `GetSuiteRunReport`, vous pouvez télécharger le rapport à partir de l'URL renvoyée pendant 90 secondes au maximum. Si plus de 90 secondes se sont écoulées depuis la dernière fois que vous avez appelé l'opération `GetSuiteRunReport`, appelez-la à nouveau pour récupérer une nouvelle URL valide.
Exemples de kit SDK :
```
// Using the SDK, call the getSuiteRunReport API.
response = iotDeviceAdvisorClient.getSuiteRunReport(
GetSuiteRunReportRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunId("your-suite-run-id")
.build()
)
```
# Flux de travail détaillé sur la console Device Advisor
Dans ce didacticiel, vous allez créer une suite de tests personnalisée et exécuter des tests sur l'appareil que vous souhaitez tester dans la console. Une fois les tests terminés, vous pouvez consulter les résultats et les journaux détaillés.
**Topics**
+ [Conditions préalables](#da-detailed-prereqs)
+ [Création d'une définition de suite de tests](#device-advisor-console-create-suite)
+ [Lancer l'exécution d'une suite de test](#device-advisor-console-run-test-suite)
+ [Arrêter l'exécution d'une suite de tests (facultatif)](#device-advisor-stop-test-run)
+ [Afficher les détails et les journaux d'exécution de la suite de tests](#device-advisor-console-view-logs)
+ [Téléchargez un rapport AWS IoT de qualification](#device-advisor-console-qualification-report)
## Conditions préalables
Pour effectuer ce didacticiel, vous devez [créer un objet et un certificat](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-create-thing-certificate).
## Création d'une définition de suite de tests
Créez une suite de tests afin de pouvoir l'exécuter sur vos appareils et effectuer la vérification.
1. Dans la [AWS IoT console](https://console.aws.amazon.com//iot), dans le volet de navigation, développez **Test**, **Device Advisor**, puis choisissez **Test suites**.
![\[L'interface Device Advisor propose des options permettant de créer des suites de tests pour les appareils éligibles, d'exécuter des tests de longue durée et des suites de tests personnalisées.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-testsuite.png)
Choisissez **Create Test Suite**.
1. Sélectionnez `Use the AWS Qualification test suite` ou `Create a new test suite`.
Pour le protocole, choisissez **MQTT 3.1.1** ou **MQTT** 5.
![\[« Créer une suite de tests » avec des options permettant de choisir le type de suite de tests (AWS IoT Core qualification, longue durée ou personnalisé) et le protocole (MQTT 3.1.1 ou MQTT 5).\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-create-test-suite.png)
Sélectionnez `Use the AWS Qualification test suite` cette option pour qualifier et inscrire votre appareil dans le catalogue des appareils AWS partenaires. En choisissant cette option, les scénarios de test requis pour la qualification de votre appareil dans le cadre du programme de qualification AWS IoT Core sont présélectionnés. Les groupes de test et les scénarios de test ne peuvent pas être ajoutés ou supprimés. Vous devrez tout de même configurer les propriétés de la suite de tests.
Sélectionnez `Create a new test suite` pour créer et configurer une suite de test personnalisée. Nous vous recommandons de commencer par cette option pour les tests initiaux et le dépannage. Une suite de tests personnalisée doit comporter au moins un groupe de test, et chaque groupe de test doit comporter au moins un cas de test. Dans le cadre de ce didacticiel, nous allons sélectionner cette option et choisir **Next**.
![\[Page de configuration de la suite de tests qui indique les étapes de création d'une suite de tests avec des groupes de tests et des cas pour tester des appareils IoT.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-configure-test-suite.png)
1. Choisissez **Propriétés de la suite de tests**. Vous devez créer les propriétés de la suite de tests lorsque vous créez votre suite de tests.
![\[L'interface « Configurer la suite de tests » qui affiche les options permettant de créer des groupes de test et d'ajouter des cas de test pour tester les fonctionnalités des appareils IoT.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-test-suite-properties.png)
Sous **Propriétés de la suite de tests**, renseignez les champs suivants :
+ **Nom de la suite de test** : vous pouvez créer la suite avec un nom personnalisé.
+ **Timeout** (optional) Délai(facultatif) délai d'expiration (en secondes) pour chaque scénario de test de la suite de tests actuelle. Si vous ne spécifiez pas de valeur de délai d'attente, la valeur par défaut est utilisée.
+ **Balises** (facultatif) : ajoutez des balises à la suite de tests.
![\[Fenêtre intitulée « Propriétés de la suite de tests » affichant les champs permettant de spécifier le nom de la suite de tests, le délai d'expiration et les balises personnalisées pour une suite de démonstration Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-test-suite-properties-1.png)
Lorsque vous avez terminé, choisissez **Mettre à jour les propriétés**.
1. Pour modifier la configuration au niveau du groupe, sous `Test group 1`, choisissez **Modifier**. Entrez ensuite un **nom** pour donner un nom personnalisé au groupe.
Facultativement, vous pouvez également saisir une valeur de **délai d'expiration** en secondes dans le groupe de test sélectionné. Si vous ne spécifiez pas de valeur de délai d'attente, la valeur par défaut est utilisée.
![\[L'interface « Configurer la suite de tests » permet de créer des groupes de tests et des cas afin de valider le fonctionnement des appareils IoT.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-edit-test-group.png)
Sélectionnez **Exécuté**.
1. Faites glisser l'un des scénarios de test disponibles depuis les scénarios de **test** vers le groupe de test.
![\[Interface de configuration permettant de créer une suite de tests dans Device Advisor, avec des options permettant d'ajouter des groupes de test et des cas de test pour tester les appareils IoT.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-configure-test-suite-step5.png)
1. Pour modifier la configuration au niveau du scénario de test que vous avez ajouté à votre groupe de test, choisissez **Modifier**. Entrez ensuite un **nom** pour donner un nom personnalisé au groupe.
Facultativement, vous pouvez également saisir une valeur de **délai d'expiration** en secondes dans le groupe de test sélectionné. Si vous ne spécifiez pas de valeur de délai d'attente, la valeur par défaut est utilisée.
![\[Interface de configuration de la suite de tests avec des options pour configurer les groupes de tests, les cas de test, les paramètres de délai d'expiration et les points de départ pour l'exécution de la suite de tests.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-edit-test-case.png)
Sélectionnez **Exécuté**.
**Note**
Pour ajouter d'autres groupes de tests à la suite de tests, choisissez **Ajouter un groupe de test**. Suivez les étapes précédentes pour créer et configurer d'autres groupes de test, ou pour ajouter d'autres cas de test à un ou plusieurs groupes de test. Les groupes de tests et les scénarios de test peuvent être réorganisés en choisissant un scénario de test et en le faisant glisser vers la position souhaitée. Device Advisor exécute les tests dans l'ordre dans lequel vous définissez les groupes de tests et les scénarios de test.
1. Choisissez **Suivant**.
1. À **l'étape 3**, configurez un rôle de périphérique que Device Advisor utilisera pour effectuer des actions AWS IoT MQTT au nom de votre périphérique de test.
Si vous avez sélectionné le scénario de test **MQTT Connect** uniquement à l'**étape 2**, l'action **Connect** sera sera vérifiée automatiquement puisque cette autorisation est requise sur le rôle de périphérique pour exécuter cette suite de tests. Si vous avez sélectionné d'autres scénarios de test, les actions requises correspondantes seront vérifiées. Assurez-vous que les valeurs des ressources sont fournies pour chacune des actions. Par exemple, pour l'action **Connect**, indiquez l'ID client que votre appareil utilise pour se connecter au point de terminaison Device Advisor. Vous pouvez fournir plusieurs valeurs en utilisant des virgules pour séparer les valeurs, et vous pouvez également fournir des valeurs de préfixe en utilisant un caractère générique (\$1). Par exemple, pour accorder l'autorisation de publier sur n'importe quel sujet commençant par `MyTopic`, vous pouvez fournir « `MyTopic*` » comme valeur de ressource.
![\[L'étape « Sélectionnez un rôle sur l'appareil » dans Device Advisor pour créer une suite de tests, avec des options pour créer un nouveau rôle ou sélectionner un rôle existant, et des champs pour spécifier le nom du rôle, les autorisations et les détails des ressources.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-connect-role.png)
Si vous avez déjà créé un rôle sur l'appareil et que vous souhaitez utiliser ce rôle, sélectionnez **Sélectionner un rôle existant** et choisissez votre rôle sur l'appareil sous **Sélectionner un rôle**.
![\[La page permettant de sélectionner un rôle sur l'appareil pour les tests de Device Advisor, avec des options permettant de créer un nouveau rôle ou d'en sélectionner un existant.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-existing-role.png)
Configurez le rôle de votre appareil à l'aide de l'une des deux options proposées et choisissez **Next (Suivant)**.
1. À **l'étape 4**, assurez-vous que la configuration fournie à chacune des étapes est précise. Pour modifier la configuration fournie pour une étape particulière, choisissez **Modifier** pour l'étape correspondante.
Après avoir vérifié la configuration, choisissez **Créer une suite de tests**.
La suite de tests devrait être créée avec succès et vous serez redirigé vers la page des **suites de tests** où vous pourrez voir toutes les suites de tests créées.
Si la création de la suite de tests a échoué, assurez-vous que la suite de tests, les groupes de tests, les scénarios de test et le rôle de l'appareil ont été configurés conformément aux instructions précédentes.
## Lancer l'exécution d'une suite de test
1. Dans la [AWS IoT console](https://console.aws.amazon.com//iot), dans le volet de navigation, développez **Test**, **Device Advisor**, puis choisissez **Test suites**.
1. Choisissez la suite de tests dont vous souhaitez consulter les détails.
![\[La console qui affiche une seule suite de tests nommée « suite de démonstration Device Advisor » créée le 11 mai 2021.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-test-suites.png)
La page détaillée de la suite de tests affiche toutes les informations relatives à la suite de tests.
1. Choisissez **Actions**, puis **Exécuter la suite de tests**.
![\[La page de la suite de démonstration avec un bouton « Exécuter la suite de tests » et un journal d'activité vide indiquant qu'aucune suite de tests n'a été exécutée auparavant.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-run-test-suites.png)
1. Sous **Exécuter la configuration**, vous devez sélectionner un AWS IoT objet ou un certificat à tester à l'aide de Device Advisor. Si vous n'avez aucun élément ou certificat existant, [créez d'abord des AWS IoT Core ressources](device-advisor-setting-up.md).
Dans la section **Tester le point de terminaison**, sélectionnez le point de terminaison qui convient le mieux à votre cas d'utilisation. Si vous prévoyez d'exécuter plusieurs suites de tests simultanément en utilisant le même AWS compte à l'avenir, sélectionnez Endpoint **au niveau de l'appareil**. Sinon, si vous prévoyez d'exécuter une seule suite de tests à la fois, sélectionnez **Point de terminaison au niveau du compte**.
Configurez votre appareil de test avec le point de terminaison de test du Device Advisor sélectionné.
Après avoir sélectionné un objet ou un certificat et choisi un point de terminaison Device Advisor, choisissez **Exécuter le test**.
![\[Configuration sur laquelle exécuter une suite de tests AWS IoT Core, vous permettant de sélectionner des appareils de test (objets ou certificats), de choisir un point de terminaison de test (au niveau du compte ou au niveau de l'appareil) et d'ajouter éventuellement des balises.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-choose-thing-certificate.png)
1. Choisissez **Accéder aux résultats** sur le bandeau supérieur pour afficher les détails du test.
![\[Détails d'une suite de tests personnalisée intitulée « Suite de démonstration Device Advisor » en cours avec le statut « En attente ».\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-test-run-results.png)
## Arrêter l'exécution d'une suite de tests (facultatif)
1. Dans la [AWS IoT console](https://console.aws.amazon.com//iot), dans le volet de navigation, développez **Test**, **Device Advisor**, puis choisissez **Tests et résultats**.
1. Choisissez la suite de tests en cours que vous souhaitez arrêter.
![\[Les résultats des tests s'exécutent sur la console Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-test-suite-to-stop.PNG)
1. Choisissez **Actions**, puis **Arrêter la suite de tests**.
![\[Les résultats des tests s'exécutent sur la console Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-stop-test-suite.PNG)
1. Le processus de nettoyage prendra plusieurs minutes. Pendant l'exécution du processus de nettoyage, l'état du test sera `STOPPING`. Attendez que le processus de nettoyage soit terminé et que l'état de la suite de tests passe au `STOPPED` statut actuel avant de démarrer une nouvelle exécution de suite.
![\[Les résultats interrompus des tests s'exécutent sur la console Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-stopped-test-suite.PNG)
## Afficher les détails et les journaux d'exécution de la suite de tests
1. Dans la [AWS IoT console](https://console.aws.amazon.com//iot), dans le volet de navigation, développez **Test**, **Device Advisor**, puis choisissez **Tests et résultats**.
Cette page affiche :
+ Nombre d'objets IoT
+ Nombre de certificats IoT
+ Nombre de suites de tests en cours d'exécution
+ Toutes les suites de tests exécutées qui ont été créées
1. Choisissez la suite de tests pour laquelle vous souhaitez afficher les détails et les journaux d'exécution.
![\[Une section de tests et de résultats qui affiche les détails d'une suite de tests nommée « suite de démonstration Device Advisor » actuellement en cours de réalisation.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-test-suite-run.png)
La page de résumé de l'exécution affiche l'état de l'exécution de la suite de tests en cours. Cette page est actualisée automatiquement toutes les 10 secondes. Nous vous recommandons de créer un mécanisme permettant à votre appareil d'essayer de se connecter à notre point de terminaison de test toutes les cinq secondes pendant une à deux minutes au maximum. Vous pouvez ensuite exécuter plusieurs scénarios de test en séquence de manière automatisée.
![\[Le journal des cas de test qui indique un test MQTT Connect réussi sans qu'aucun message système ne soit affiché.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-run-summary.png)
1. Pour accéder aux CloudWatch journaux relatifs à l'exécution de la suite de tests, choisissez **Test suite log**.
Pour accéder aux CloudWatch journaux de n'importe quel scénario de test, choisissez **Test case log**.
1. En fonction des résultats de vos tests, [troubleshoot](https://docs.aws.amazon.com/iot/latest/developerguide/iot_troubleshooting.html#device-advisor-troubleshooting) (dépannez) votre appareil jusqu'à ce que tous les tests réussissent.
## Téléchargez un rapport AWS IoT de qualification
Si vous avez choisi l'option **Utiliser la suite de tests de AWS IoT qualification** lors de la création d'une suite de tests et que vous avez pu exécuter une suite de tests de qualification, vous pouvez télécharger un rapport de qualification en choisissant **Télécharger le rapport de qualification** sur la page de résumé des tests.
![\[Résultats des tests du programme de qualification indiquant les tests réussis pour MQTT, TLS et d'autres composants.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/da-qualification-report.png)
# Flux de travail de la console de tests de longue durée
Ce didacticiel vous aide à démarrer les tests de longue durée sur Device Advisor à l'aide de la console. Pour terminer le didacticiel, suivez les étapes indiquées sur [Configuration](device-advisor-setting-up.md).
1. Dans la [AWS IoT console](https://console.aws.amazon.com/iot), dans le volet de navigation, développez **Test**, **Device Advisor**, puis choisissez **Suites de tests**. Sur la page, sélectionnez **Créer une suite de tests de longue durée**.
![\[La section Créer une suite de tests de longue durée de la console Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/create-ld-ts.png)
1. Sur la page **Créer une suite de tests**, sélectionnez **Suite de tests de longue durée**, puis cliquez sur **Suivant**.
Pour le protocole, choisissez **MQTT 3.1.1** ou **MQTT** 5.
![\[L'étape Créer une suite de tests de la console Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/choose-ld-ts.png)
1. Sur la page **Configurer l'événement de test**, procédez de la façon suivante :
1. Mettez à jour le champ **Nom de la suite de tests**.
1. Mettez à jour le champ **Nom de groupe de tests**.
1. Choisissez les **opérations** que l'appareil peut effectuer. Cela permettra de sélectionner les tests à exécuter.
1. Sélectionnez l'option **Paramètres**.
![\[L'étape Créer une suite de tests de la console Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/configure-ld-ts.png)
1. (Facultatif) Entrez la durée maximale pendant laquelle Device Advisor doit attendre la fin des tests de base. Cliquez sur **Enregistrer**.
![\[La case « Timeout (facultatif) » pour les « tests de base » de la console Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/timeout-ld-ts.png)
1. Procédez comme suit dans les sections **Tests avancés** et **Paramètres supplémentaires**.
1. Sélectionnez ou désélectionnez les **tests avancés** que vous souhaitez exécuter dans le cadre de ce test.
1. **Modifiez** les configurations pour les tests, le cas échéant.
1. Configurez le **temps d'exécution supplémentaire** **dans la section Paramètres supplémentaires**.
1. Choisissez **Next** (Suivant) pour passer à l'étape suivante.
![\[L'interface Device Advisor qui vous permet de configurer et d'exécuter des tests sur des appareils IoT.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/additional-ld-ts.png)
1. Dans cette étape, **créez un nouveau rôle** ou **sélectionnez un rôle existant**. Consultez [Créer un rôle IAM à utiliser comme rôle de périphérique](device-advisor-setting-up.md#da-iam-role) pour plus de détails.
![\[L'étape du rôle de l'appareil où vous pouvez créer un nouveau rôle ou sélectionner un rôle existant pour l'appareil testé. Le rôle autorise Device Advisor à effectuer des actions MQTT telles que Connect, Publish et Subscribe pour le compte de l'appareil de test.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/devicerole-ld-ts.png)
1. Passez en revue toutes les configurations créées jusqu'à cette étape et sélectionnez **Créer une suite de tests**.
![\[La page « Révision » où vous pouvez consulter tous les détails de la configuration de Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/finalconfigure1-ld-ts.png)
![\[La page de configuration où vous pouvez consulter tous les détails de Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/finalconfigure2-ld-ts.png)
1. La suite de tests créée se trouve dans la section **Suites de tests**. Sélectionnez la suite pour afficher les détails.
![\[Une nouvelle suite de tests nommée « Long Duration Demo » a été créée avec succès dans Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/finalts-ld-ts.png)
1. Pour exécuter la suite de tests créée, sélectionnez **Actions** puis **Exécuter la suite de tests**.
![\[Le menu déroulant Actions de la nouvelle suite de tests nommée « Long Duration Demo » dans l'interface Device Advisor.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/runts-ld-ts.png)
1. Choisissez les options de configuration sur la page **Exécuter la configuration**.
1. Sélectionnez les **objets** ou le **certificat** sur lesquels exécuter le test.
1. Sélectionnez le **point de terminaison au niveau du compte ** ou **le point de terminaison au niveau de l'appareil**.
1. Pour exécuter le test, choisissez **Exécuter le test**.
![\[La page de configuration Exécuter de l'interface Device Advisor. La page affiche Sélectionner les appareils de test, les objets, le point de terminaison de test et les balises.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/runconfiguration-ld-ts.png)
1. Pour afficher les résultats de l’exécution de la suite de tests, sélectionnez **Exécutions de tests et résultats** dans le volet de navigation de gauche. Choisissez la suite de tests exécutée pour afficher le détail des résultats.
![\[Le cas de test « Demo de longue durée » sur la page des tests et des résultats.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/results-ld-ts.png)
1. L'étape précédente fait apparaître la page de résumé du test. Tous les détails du test sont affichés sur cette page. Lorsque la console vous invite à démarrer la connexion de l'appareil, connectez votre appareil au point de terminaison fourni. La progression des tests est visible sur cette page.
![\[La page de résumé du test « Demo de longue durée » que vous avez créé.\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/summary-ld-ts.png)
1. Le test de longue durée fournit un **résumé supplémentaire du journal de test** sur le panneau latéral qui affiche tous les événements importants survenus entre l'appareil et le courtier en temps quasi réel. Pour afficher des journaux détaillés, cliquez sur **Journal des cas de test**.
![\[La section récapitulative du journal de test sur la page du test « Démo de longue durée ».\]](http://docs.aws.amazon.com/fr_fr/iot/latest/developerguide/images/log-ld-ts.png)
# Points de terminaison d’un VPC Device Advisor (AWS PrivateLink)
Vous pouvez établir une connexion privée entre votre VPC et le point de terminaison de AWS IoT Core Device Advisor test (plan de données) en créant un point de terminaison *VPC d'interface*. Vous pouvez utiliser ce point de terminaison pour valider AWS IoT les appareils afin de garantir une connectivité fiable et sécurisée AWS IoT Core avant de les déployer en production. Pour accéder aux journaux CloudWatch pour l'exécution de la suite de tests, choisissez [Journal de la suite de tests](https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html).
[AWS PrivateLink](https://aws.amazon.com/privatelink)alimente les points de terminaison d'interface utilisés avec vos appareils IoT. Ce service vous aide à accéder en privé au point de terminaison de test AWS IoT Core Device Advisor sans passerelle Internet, périphérique NAT, connexion VPN ni connexion Direct Connect . Les instances de votre VPC qui envoient des paquets TCP et MQTT n'ont pas besoin d'adresses IP publiques pour communiquer avec les points de terminaison de test. AWS IoT Core Device Advisor Le trafic entre votre VPC et celui qui AWS IoT Core Device Advisor ne sort pas. AWS Cloud Toutes les communications TLS et MQTT entre les appareils IoT et les scénarios de test Device Advisor restent dans les limites de vos ressources. Compte AWS
Chaque point de terminaison d'interface est représenté par une ou plusieurs [interfaces réseau Elastic](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) dans vos sous-réseaux.
Pour en savoir plus sur l'utilisation des points de terminaison d'un VPC d'interface, consultez [Points de terminaison de VPC d'interface (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) dans le *Guide de l'utilisateur Amazon VPC*.
## Considérations relatives aux points de AWS IoT Core Device Advisor terminaison VPC
Consultez les [ propriétés et les limitations du point de terminaison d'interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations) dans le *Guide de l'utilisateur Amazon VPC* avant de configurer les points de terminaison d'un VPC d'interface. Considérez les points suivants avant de continuer :
+ AWS IoT Core Device Advisor prend actuellement en charge les appels vers le point de terminaison de test Device Advisor (plan de données) depuis votre VPC. Un agent de messages utilise les communications par plan de données pour envoyer et recevoir des données. Il le fait à l'aide de paquets TLS et MQTT. Points de terminaison VPC pour AWS IoT Core Device Advisor connecter votre AWS IoT appareil aux points de terminaison de test Device Advisor. Les [actions d'API du plan de contrôle](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iotdeviceadvisor/index.html) ne sont pas utilisées par ce point de terminaison VPC. Pour créer ou exécuter une suite de tests ou un autre plan de contrôle APIs, utilisez la console, un AWS SDK ou une interface de ligne de AWS commande sur Internet public.
+ Les points de terminaison VPC suivants Régions AWS prennent en charge : AWS IoT Core Device Advisor
+ USA Est (Virginie du Nord)
+ USA Ouest (Oregon)
+ Asie Pacifique (Tokyo)
+ Europe (Irlande)
+ Device Advisor prend en charge le MQTT avec les certificats client X.509 et les certificats de serveur RSA.
+ Les [politiques de point de terminaison d’un VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) ne sont pas prises en charge pour le moment.
+ Consultez les [conditions requises](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#prerequisites-interface-endpoints) pour les points de terminaison VPC pour obtenir des instructions sur la façon de [créer des ressources](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) qui connectent les points de terminaison VPC. Vous devez créer un VPC et des sous-réseaux privés pour utiliser les points de terminaison AWS IoT Core Device Advisor VPC.
+ Vos AWS PrivateLink ressources sont soumises à des quotas. Pour plus d'informations, consultez [AWS PrivateLink Quotas](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html).
+ Les points de terminaison VPC ne prennent en charge que le trafic. IPv4
## Créez un point de terminaison VPC d'interface pour AWS IoT Core Device Advisor
Pour démarrer avec les points de terminaison d'un VPC, [ créez un point de terminaison d'un VPC d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). Ensuite, sélectionnez AWS IoT Core Device Advisor comme Service AWS. Si vous utilisez le AWS CLI, appelez [describe-vpc-endpoint-services](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpc-endpoint-services.html)pour confirmer qu'il AWS IoT Core Device Advisor est présent dans une zone de disponibilité de votre Région AWS. Vérifiez que le groupe de sécurité attaché au point de terminaison autorise les [communications par protocole TCP](https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html) pour le trafic MQTT et TLS. Par exemple, dans la région USA Est (Virginie du Nord), utilisez la commande suivante :
```
aws ec2 describe-vpc-endpoint-services --service-name com.amazonaws.us-east-1.deviceadvisor.iot
```
Vous pouvez créer un point de terminaison VPC à l' AWS IoT Core aide du nom de service suivant :
+ com.amazonaws.*region*.deviceadvisor.iot
Par défaut, le DNS privé est activé pour le point de terminaison. Cela garantit que l'utilisation du point de terminaison de test par défaut reste dans vos sous-réseaux privés. Pour obtenir un point de terminaison au niveau de votre compte ou de votre appareil, utilisez la console AWS CLI ou un AWS SDK. Par exemple, si vous exécutez [get-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iotdeviceadvisor/get-endpoint.html) dans un sous-réseau public ou sur Internet public, vous pouvez obtenir votre point de terminaison et l'utiliser pour vous connecter à Device Advisor. Pour plus d’informations, consultez [Accès à un service via un point de terminaison d’interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) dans le *Guide de l’utilisateur Amazon VPC*.
Pour connecter les clients MQTT aux interfaces de point de terminaison du VPC, AWS PrivateLink le service crée des enregistrements DNS dans une zone hébergée privée attachée à votre VPC. Ces enregistrements DNS dirigent les demandes de l'appareil AWS IoT vers le point de terminaison du VPC.
## Contrôle de l'accès aux points de AWS IoT Core Device Advisor terminaison via VPC
[Vous pouvez restreindre l'accès des appareils aux points de terminaison VPC AWS IoT Core Device Advisor et autoriser l'accès uniquement via ces points en utilisant les clés contextuelles de condition VPC.](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) AWS IoT Core prend en charge les clés de contexte liées au VPC suivantes :
+ [SourceVpc](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpc)
+ [SourceVpce](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpce)
+ [VPCSourcelp](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-vpcsourceip)
**Note**
AWS IoT Core Device Advisor ne prend pas en charge les [politiques de point de terminaison VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#vpc-endpoint-policies) pour le moment.
La politique suivante autorise la connexion à AWS IoT Core Device Advisor l'aide d'un ID client correspondant au nom de l'objet. Il publie également sur n'importe quelle rubrique préfixée par le nom de l'objet. La politique dépend de la connexion de l'appareil à un point de terminaison d’un VPC avec un ID de point de terminaison d’un VPC particulier. Cette politique refuse les tentatives de connexion à votre point de terminaison de test AWS IoT Core Device Advisor public.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot:Connect"
],
"Resource": [
"arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1a2b3c4d"
}
}
},
{
"Effect": "Allow",
"Action": [
"iot:Publish"
],
"Resource": [
"arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}/*"
]
}
]
}
```
# 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.*