Avis de fin de support : le 7 octobre 2026, AWS le support de. AWS IoT Greengrass Version 1 Après le 7 octobre 2026, vous ne pourrez plus accéder aux AWS IoT Greengrass V1 ressources. Pour plus d'informations, rendez-vous sur [Migrer depuis AWS IoT Greengrass Version 1](https://docs.aws.amazon.com/greengrass/v2/developerguide/migrate-from-v1.html). 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. # Utilisation de AWS IoT Device Tester pour AWS IoT Greengrass V1 AWS IoT Device Tester (IDT) est un framework de test téléchargeable qui vous permet de valider les appareils IoT. Étant AWS IoT Greengrass Version 1 donné qu'IDT est passé en [mode maintenance](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html), IDT AWS IoT Greengrass V1 ne génère plus de rapports de qualification signés. Vous ne serez plus en mesure de qualifier les nouveaux AWS IoT Greengrass V1 appareils à répertorier dans le [catalogue des AWS Partner appareils](https://devices.amazonaws.com/) dans le cadre du [programme de qualification des AWS appareils](https://aws.amazon.com/partners/dqp/). Cependant, vous pouvez continuer à utiliser IDT AWS IoT Greengrass V1 pour tester vos appareils Greengrass V1. Nous vous recommandons d'utiliser [IDT pour qualifier et AWS IoT Greengrass V2 répertorier les](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) appareils Greengrass dans [AWS Partner le](https://devices.amazonaws.com/) catalogue des appareils. IDT for AWS IoT Greengrass s'exécute sur votre ordinateur hôte (Windows, macOS ou Linux) connecté à l'appareil à tester. L'outil exécute des tests et regroupe les résultats. Il fournit également une interface de ligne de commande pour gérer le processus de test. ## AWS IoT Greengrass suite de qualifications Utilisez IDT AWS IoT Greengrass pour vérifier que le logiciel AWS IoT Greengrass Core s'exécute sur votre matériel et peut communiquer avec le AWS Cloud. Il effectue également end-to-end des tests avec AWS IoT Core. Par exemple, il vérifie que votre appareil peut envoyer et recevoir des messages MQTT et les traiter correctement. ![\[Vue d'ensemble de la façon dont le AWS IoT Device Tester vérifie que le logiciel AWS IoT Greengrass principal s'exécute sur votre matériel et peut communiquer avec le AWS Cloud.\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/images/devicetester_gg.png) AWS IoT Device Tester AWS IoT Greengrass organise les tests en utilisant les concepts de *suites de tests* et de *groupes de tests*. + Une suite de tests est l'ensemble des groupes de tests utilisés pour vérifier qu'un appareil fonctionne avec des versions particulières de AWS IoT Greengrass. + Un groupe de tests est l'ensemble de tests individuels liés à une fonctionnalité particulière, tels que les déploiements de groupe Greengrass et la messagerie MQTT. Pour de plus amples informations, veuillez consulter [Utiliser IDT pour exécuter la suite de AWS IoT Greengrass qualifications](idt-gg-qualification.md). ## Suites de tests personnalisées À partir de IDT v4.0.0, IDT for AWS IoT Greengrass combine une configuration standardisée et un format de résultat avec un environnement de suites de tests qui vous permet de développer des suites de tests personnalisées pour vos appareils et leurs logiciels. Vous pouvez ajouter des tests personnalisés pour votre propre validation interne ou les fournir à vos clients pour la vérification des appareils. La façon dont un rédacteur de tests configure une suite de tests personnalisée détermine les configurations de paramètres requises pour exécuter des suites de tests personnalisées. Pour de plus amples informations, veuillez consulter [Utilisez IDT pour développer et exécuter vos propres suites de tests](idt-custom-tests.md). # Versions prises en charge de AWS IoT Device Tester pour AWS IoT Greengrass V1 Étant AWS IoT Greengrass Version 1 donné qu'IDT est passé en [mode maintenance](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html), IDT AWS IoT Greengrass V1 ne génère plus de rapports de qualification signés. Nous vous recommandons d'utiliser [IDT pour AWS IoT Greengrass V2.](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) Pour plus d'informations sur IDT pour la AWS IoT Greengrass V2, consultez la section [Utilisation du testeur de AWS IoT périphériques AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) dans le *guide du AWS IoT Greengrass V2 développeur*. **Note** Vous recevez une notification lorsque vous lancez un test si IDT for n' AWS IoT Greengrass est pas compatible avec la version AWS IoT Greengrass que vous utilisez. En téléchargeant le logiciel, vous acceptez le [Contrat de licence AWS IoT Device Tester](https://docs.aws.amazon.com/greengrass/latest/developerguide/idt-license.html). ## Versions IDT non prises en charge pour pour AWS IoT Greengrass Cette rubrique répertorie les versions non prises en charge d'IDT pour. AWS IoT Greengrass Les versions non prises en charge ne reçoivent pas de corrections de bogues ou de mises à jour. Pour de plus amples informations, veuillez consulter [Politique de support pour AWS IoT Device Tester pour AWS IoT Greengrass V1](idt-support-policy.md). **IDT v4.4.1 pour les AWS IoT Greengrass versions v1.11.6, v1.10.5** Notes de mise à jour : + Vous permet de valider et de qualifier les appareils exécutant les logiciels AWS IoT Greengrass principaux v1.11.6 et v1.10.5. + Contient des corrections de bugs mineurs. Versions de suite de tests : `GGQ_1.3.1` + Publié le 2021.12.20 **IDT v4.1.0 pour les AWS IoT Greengrass versions v1.11.4, v1.10.4** Notes de mise à jour : + Vous permet de valider et de qualifier les appareils exécutant les logiciels AWS IoT Greengrass principaux v1.11.4 et v1.10.4. + Résout un problème à cause duquel les journaux affichés lors d'un test utilisaient des balises redondantes. Versions de suite de tests : `GGQ_1.3.0` + Publié le 23 juin 2021 + Ajoute de nouvelles tentatives pour les appels d'API à Lambda, IAM, AWS STS et pour améliorer la gestion des problèmes de limitation ou de serveur. + Ajoute le support de Python 3.8 aux scénarios de test ML et Docker. **IDT v4.0.2 pour les AWS IoT Greengrass versions v1.11.1, v1.11.0, v1.10.3** Notes de mise à jour : + Correction d'un problème en raison duquel IDT masquait les erreurs HSI (Hardware Security Integration). + Vous permet de développer et d'exécuter vos suites de tests personnalisées à l'aide de AWS IoT Device Tester pour AWS IoT Greengrass. Pour de plus amples informations, veuillez consulter [Utilisez IDT pour développer et exécuter vos propres suites de tests](idt-custom-tests.md). + Fournit des applications IDT signées par code pour macOS et Windows. Sous macOS, si un message d'avertissement de sécurité s'affiche, vous devrez peut-être accorder une exception de sécurité pour IDT. Pour de plus amples informations, veuillez consulter [Exception de sécurité sur macOS](idt-troubleshooting.md#macos-notarization-exception). AWS IoT Greengrass ne fournit pas de Dockerfile ou d'image Docker pour la version 1.11.1 du logiciel principal. AWS IoT Greengrass Pour tester la qualification Docker de votre appareil, utilisez une version antérieure du logiciel AWS IoT Greengrass principal.   **IDT v3.2.0 pour les AWS IoT Greengrass versions v1.11.0, v1.10.1, v1.10.0** Notes de mise à jour : + Par défaut, IDT exécute uniquement les tests requis pour la qualification. Pour bénéficier de fonctionnalités supplémentaires, vous pouvez modifier le [`device.json`](set-config.md#device-config)fichier. + Ajout d'un numéro de port `device.json` que vous pouvez configurer pour les connexions SSH. + Docker ne prend en charge que le [gestionnaire de flux](stream-manager.md) et l'apprentissage automatique (ML) sans conteneurisation. Container, Docker et Hardware Security Integration (HSI) ne sont pas disponibles pour les appareils Docker. + Nous avons fusionné `device-ml.json` et avons `device-hsm.json` intégré`device.json`.   **IDT v3.1.3 pour les AWS IoT Greengrass versions : v1.10.x, v1.9.x, v1.8.x** Notes de mise à jour : + Ajout du support pour la qualification des fonctionnalités ML pour les AWS IoT Greengrass versions v1.10.x et v1.9.x. Vous pouvez désormais utiliser IDT pour valider le fait que vos appareils peuvent effectuer des inférences ML localement avec des modèles stockés et formés dans le cloud. + `--stop-on-first-failure` a été ajouté pour la commande `run-suite`. Vous pouvez utiliser cette option pour configurer IDT afin qu'il cesse de fonctionner lors du premier échec. Nous vous recommandons d'utiliser cette option lors de l'étape de débogage au niveau des groupes de tests. + Ajout d'une vérification de la dérive de l'horloge pour les tests MQTT afin de garantir que le périphérique testé utilise l'heure système correcte. Le temps utilisé doit se situer dans un intervalle de temps acceptable. + `--update-idt` a été ajouté pour la commande `run-suite`. Vous pouvez utiliser cette option pour définir la réponse à l'invite de mise à jour d'IDT. + `--update-managed-policy` a été ajouté pour la commande `run-suite`. Vous pouvez utiliser cette option pour définir la réponse à l'invite de mise à jour de la politique gérée. + Ajout d'une correction de bogue pour les mises à jour automatiques des versions de la suite de tests IDT. Le correctif garantit qu'IDT peut exécuter les dernières suites de tests disponibles pour votre AWS IoT Greengrass version.   **IDT v3.0.1 pour AWS IoT Greengrass** Notes de mise à jour : + Ajout du support pour la AWS IoT Greengrass v1.10.1. + Mises à jour automatiques des versions de la suite de tests IDT. IDT peut télécharger les dernières suites de tests disponibles pour votre AWS IoT Greengrass version. Avec cette fonctionnalité : + Les suites de tests sont versionnées à l'aide d'un format `major.minor.patch`. La version initiale de la suite de tests est `GGQ_1.0.0`. + Vous pouvez télécharger de nouvelles suites de tests de manière interactive dans l'interface de ligne de commande ou définir l'indicateur `upgrade-test-suite` lorsque vous démarrez IDT. Pour de plus amples informations, veuillez consulter [Versions de la suite de tests](idt-gg-qualification.md#idt-test-suite-versions). + Ajouté `list-supported-products`. Vous pouvez utiliser cette commande pour répertorier les versions de AWS IoT Greengrass et de suites de tests prises en charge par la version installée d'IDT. + Ajouté `list-test-cases`. Vous pouvez utiliser cette commande pour répertorier les scénarios de test disponibles dans un groupe de test. + `test-id` a été ajouté pour la commande `run-suite`. Vous pouvez utiliser cette option pour exécuter des scénarios de test individuels dans un groupe de test.   **IDT v2.3.0 pour AWS IoT Greengrass v1.10, v1.9.x et v1.8.x** Lors des tests sur un appareil physique, les versions AWS IoT Greengrass v1.10, v1.9.x et v1.8.x sont prises en charge. Lors d'un test dans un conteneur Docker, les versions AWS IoT Greengrass v1.10 et v1.9.x sont prises en charge. Notes de mise à jour : + Ajout de la prise en charge de [Exécution AWS IoT Greengrass dans un conteneur Docker](run-gg-in-docker-container.md). Vous pouvez désormais utiliser IDT pour qualifier et valider que vos appareils peuvent fonctionner AWS IoT Greengrass dans un conteneur Docker. + Ajout d'une [politique AWS gérée](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) (`AWSIoTDeviceTesterForGreengrassFullAccess`) qui définit les autorisations requises pour exécuter AWS IoT Device Tester. Si les nouvelles versions nécessitent des autorisations supplémentaires, AWS ajoutez-les à cette politique gérée afin de ne pas avoir à mettre à jour vos autorisations IAM. + Des vérifications ont été introduites pour valider que votre environnement (par exemple, la connectivité des appareils et la connectivité Internet) est configuré correctement avant d'exécuter les scénarios de test. + Amélioration du vérificateur de dépendance Greengrass dans IDT pour le rendre plus flexible lors de la vérification de la libc sur les appareils.   **IDT v2.2.0 pour AWS IoT Greengrass v1.10, v1.9.x et v1.8.x** Notes de mise à jour : + Ajout du support pour la AWS IoT Greengrass v1.10. + Ajout de la prise en charge du connecteur de [déploiement d'application Greengrass Docker](docker-app-connector.md). + Ajout du support pour le [gestionnaire de AWS IoT Greengrass flux](stream-manager.md). + Ajout du support pour AWS IoT Greengrass la région de Chine (Pékin).   **IDT v2.1.0 pour AWS IoT Greengrass v1.9.x, v1.8.x et v1.7.x** Notes de mise à jour : + Ajout du support pour la AWS IoT Greengrass v1.9.4. + Ajout du support pour les ARMv6l appareils Linux.   **IDT v2.0.0 pour AWS IoT Greengrass v1.9.3, v1.9.2, v.1.9.1, v1.9.0, v1.8.4, v1.8.3 et v1.8.2** Notes de mise à jour : + Suppression de la dépendance sur Python pour l'appareil testé. + Le temps d'exécution de la suite de tests a été réduit de plus de 50 %, ce qui accélère le processus de qualification. + La taille exécutable a été réduite de plus de 50 %, ce qui accélère le téléchargement et l'installation. + Amélioration de [la prise en charge du multiplicateur de délai d'attente](idt-troubleshooting.md#test-timeout) pour tous les scénarios de test. + Messages de post-diagnostic améliorés pour résoudre les erreurs plus rapidement. + Mise à jour du modèle de stratégie d'autorisations requis pour exécuter IDT. + Ajout du support pour la AWS IoT Greengrass v1.9.3.   **IDT v1.3.3 pour AWS IoT Greengrass v1.9.2, v1.9.1, v1.9.0, v1.8.3 et v1.8.2** Notes de mise à jour : + Ajout de la prise en charge de Greengrass versions 1.9.2 et 1.8.3. + Ajout du support pour Greengrass OpenWrt. + Ajout de la connexion au périphérique du nom d'utilisateur et du mot de passe SSH. + Ajout d'un correctif de bogue de test natif pour OpenWrt - ARMv7l platform.   **IDT v1.2 pour v1.8.1 AWS IoT Greengrass ** Notes de mise à jour : + Ajout d'un multiplicateur de délai d'expiration configurable pour traiter et résoudre des problèmes de dépassement de délai (par exemple, les connexions à bande passante faible).   **IDT v1.1 pour v1.8.0 AWS IoT Greengrass ** Notes de mise à jour : + Ajout du support pour l'intégration de la sécurité AWS IoT Greengrass matérielle (HSI). + Support ajouté pour le AWS IoT Greengrass conteneur et pas de conteneur. + Ajout de la création automatique AWS IoT Greengrass de rôles de service. + Amélioration du nettoyage de la ressource test. + Ajout du rapport récapitulatif de l'exécution de test.   **IDT v1.1 pour v1.7.1 AWS IoT Greengrass ** Notes de mise à jour : + Ajout du support pour l'intégration de la sécurité AWS IoT Greengrass matérielle (HSI). + Support ajouté pour le AWS IoT Greengrass conteneur et pas de conteneur. + Ajout de la création automatique AWS IoT Greengrass de rôles de service. + Amélioration du nettoyage de la ressource test. + Ajout du rapport récapitulatif de l'exécution de test.   **IDT v1.0 pour v1.6.1 AWS IoT Greengrass ** Notes de mise à jour : + Ajout d'un correctif de bogue de test OTA pour AWS IoT Greengrass la compatibilité des versions futures. [Si vous utilisez IDT v1.0 pour la AWS IoT Greengrass v1.6.1, vous devez créer un rôle de service Greengrass.](service-role.md) Dans les versions ultérieures, IDT crée le rôle de service pour vous. # Utiliser IDT pour exécuter la suite de AWS IoT Greengrass qualifications Vous pouvez utiliser AWS IoT Device Tester (IDT) AWS IoT Greengrass pour vérifier que le logiciel AWS IoT Greengrass Core s'exécute sur votre matériel et peut communiquer avec le AWS Cloud. Il effectue également end-to-end des tests avec AWS IoT Core. Par exemple, il vérifie que votre appareil peut envoyer et recevoir des messages MQTT et les traiter correctement. Étant AWS IoT Greengrass Version 1 donné qu'IDT est passé en [mode maintenance](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html), IDT AWS IoT Greengrass V1 ne génère plus de rapports de qualification signés. Si vous souhaitez ajouter votre matériel au catalogue des AWS Partner appareils, exécutez la suite de AWS IoT Greengrass V2 qualification pour générer des rapports de test auxquels vous pouvez les soumettre AWS IoT. Pour plus d'informations, consultez le [programme de qualification des AWS appareils](https://aws.amazon.com/partners/dqp/) et [les versions prises en charge d'IDT pour AWS IoT Greengrass V2.](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html) Outre les appareils de test, IDT for AWS IoT Greengrass crée des ressources (par exemple, des AWS IoT objets, des AWS IoT Greengrass groupes, des fonctions Lambda, etc.) dans Compte AWS votre corps afin de faciliter le processus de qualification. Pour créer ces ressources, IDT for AWS IoT Greengrass utilise les AWS informations d'identification configurées dans le `config.json` fichier pour effectuer des appels d'API en votre nom. Ces ressources sont allouées à différents moments d'un test. Lorsque vous utilisez IDT AWS IoT Greengrass pour exécuter la suite de AWS IoT Greengrass qualification, IDT effectue les étapes suivantes : 1. Charge et valide les configurations de votre appareil et de vos identifiants. 1. Tests sélectionnés avec les ressources locales et les ressources cloud requises. 1. Élimination des ressources locales et des ressources cloud. 1. Génère des rapports de tests qui indiquent si votre appareil a réussi les tests requis pour la qualification. ## Versions de la suite de tests IDT for AWS IoT Greengrass organise les tests en suites de tests et en groupes de tests. + Une suite de tests est l'ensemble des groupes de tests utilisés pour vérifier qu'un appareil fonctionne avec des versions particulières de AWS IoT Greengrass. + Un groupe de tests est l'ensemble de tests individuels liés à une fonctionnalité particulière, tels que les déploiements de groupe Greengrass et la messagerie MQTT. À partir de IDT v3.0.0, les suites de tests sont versionnées à l'aide d'un format `major.minor.patch`, par exemple `GGQ_1.0.0`. Lorsque vous téléchargez IDT, le package inclut la version de suite de tests la plus récente. **Important** IDT prend en charge les trois dernières versions de la suite de tests pour la qualification des périphériques. Pour de plus amples informations, veuillez consulter [Politique de support pour AWS IoT Device Tester pour AWS IoT Greengrass V1](idt-support-policy.md). Vous pouvez exécuter `list-supported-products` pour répertorier les versions AWS IoT Greengrass et les suites de tests prises en charge par votre version actuelle d'IDT. Les tests des versions de suite de tests non prises en charge ne sont pas valides pour la qualification des périphériques. IDT n'imprime pas les rapports de qualification pour les versions non prises en charge. ### Mises à jour des paramètres de configuration IDT De nouveaux tests peuvent introduire de nouveaux paramètres de configuration IDT. + Si les paramètres sont facultatifs, IDT continue d'exécuter les tests. + Si les paramètres sont requis, IDT vous en avertit et arrête l'exécution. Après avoir configuré les paramètres, redémarrez l'exécution des tests. Les paramètres de configuration se trouvent dans le dossier `/configs`. Pour de plus amples informations, veuillez consulter [Configurer les paramètres IDT pour exécuter la suite de AWS IoT Greengrass qualification](set-config.md). Si une version de la suite de tests mise à jour ajoute des paramètres de configuration, IDT crée une copie du fichier de configuration d'origine dans `/configs`. ## Descriptions des groupes de tests ------ #### [ IDT v2.0.0 and later ] **Groupes de test requis pour la qualification du noyau** Ces groupes de test sont nécessaires pour qualifier votre AWS IoT Greengrass appareil pour le catalogue AWS Partner d'appareils. AWS IoT Greengrass Dépendances fondamentales Vérifie que votre appareil répond à toutes les exigences logicielles et matérielles du logiciel AWS IoT Greengrass Core. Le cas test `Software Packages Dependencies` de ce groupe de test n'est pas applicable lors d'un test dans un [conteneur Docker](docker-config-setup.md). Déploiement Valide que les fonctions Lambda peuvent être déployées sur votre appareil. MQTT Vérifie le fonctionnement du routeur de AWS IoT Greengrass messages en vérifiant la communication locale entre le cœur de Greengrass et les appareils clients, qui sont des appareils IoT locaux. Over-the-Air (OTA) Valide que votre appareil peut effectuer avec succès une mise à jour OTA du logiciel AWS IoT Greengrass Core. Ce groupe de test n'est pas applicable lors d'un test dans un [conteneur Docker](docker-config-setup.md). Version Vérifie que la version AWS IoT Greengrass fournie est compatible avec la version de AWS IoT Device Tester que vous utilisez. **Groupes de test facultatifs** Ces groupes de test sont facultatifs. Si vous choisissez de vous qualifier pour les tests facultatifs, votre appareil est répertorié avec des fonctionnalités supplémentaires dans le catalogue des AWS Partner appareils. Dépendances de conteneur Vérifie que l'appareil répond à toutes les exigences logicielles et matérielles pour exécuter les fonctions Lambda en mode conteneur sur un cœur Greengrass. Ce groupe de test n'est pas applicable lors d'un test dans un [conteneur Docker](docker-config-setup.md). Conteneur de déploiement Valide que les fonctions Lambda peuvent être déployées sur l'appareil et exécutées en mode conteneur sur un noyau Greengrass. Ce groupe de test n'est pas applicable lors d'un test dans un [conteneur Docker](docker-config-setup.md). Dépendances Docker (prises en charge pour IDT v2.2.0 et versions ultérieures) Vérifie que l'appareil répond à toutes les dépendances techniques requises pour utiliser le connecteur de déploiement d'applications Greengrass Docker pour exécuter des conteneurs Ce groupe de test n'est pas applicable lors d'un test dans un [conteneur Docker](docker-config-setup.md). Intégration de sécurité matérielle (HSI) Vérifie que la bibliothèque partagée HSI fournie peut s'interfacer avec le module de sécurité matériel (HSM) et implémente correctement le PKCS \$111 requis. APIs La bibliothèque partagée/HSM doit signer une CSR, effectuer des opérations TLS et fournir les longueurs de clé et l'algorithme de clé publique corrects. Dépendances du gestionnaire de flux (prises en charge pour IDT v2.2.0 et versions ultérieures) Vérifie que l'appareil répond à toutes les dépendances techniques requises pour exécuter le gestionnaire de AWS IoT Greengrass flux. Dépendances de Machine Learning (prises en charge pour IDT v3.1.0 et versions ultérieures) Valide que l'appareil est conforme à toutes les dépendances techniques requises pour pouvoir exécuter une inférence ML localement. Tests d'inférence de Machine Learning (pris en charge pour IDT v3.1.0 et versions ultérieures) Valide que l'inférence ML peut être effectuée sur l'appareil testé. Pour de plus amples informations, veuillez consulter [Facultatif : Configuration de votre appareil pour la qualification ML](idt-ml-qualification.md). Tests de conteneur d'inférence de Machine Learning (pris en charge pour IDT v3.1.0 et versions ultérieures) Valide que l'inférence ML peut être effectuée sur l'appareil testé et exécutée en mode conteneur sur un noyau Greengrass. Pour de plus amples informations, veuillez consulter [Facultatif : Configuration de votre appareil pour la qualification ML](idt-ml-qualification.md). ------ #### [ IDT v1.3.3 and earlier ] **Groupes de test requis pour la qualification du noyau** Ces tests sont nécessaires pour qualifier votre AWS IoT Greengrass appareil pour le catalogue AWS Partner d'appareils. AWS IoT Greengrass Dépendances fondamentales Vérifie que votre appareil répond à toutes les exigences logicielles et matérielles du logiciel AWS IoT Greengrass Core. Combinaison (interaction de sécurité de l'appareil) Vérifie la fonctionnalité du détecteur IP et du gestionnaire de certificat d'appareil du noyau Greengrass en modifiant les informations de connectivité au niveau du groupe Greengrass dans le cloud. Le groupe de test fait pivoter le certificat AWS IoT Greengrass du serveur et vérifie que les connexions sont autorisées AWS IoT Greengrass . Déploiement (requis pour IDT v1.2 et versions antérieures) Valide que les fonctions Lambda peuvent être déployées sur votre appareil. Gestionnaire de certificats de l'appareil Vérifie que le gestionnaire de certificats de l' AWS IoT Greengrass appareil peut générer un certificat de serveur au démarrage et alterner les certificats s'ils sont proches de leur expiration. Détection IP (IDP) Vérifie que les informations sur la connectivité du noyau sont mises à jour en cas de modifications d'adresses IP sur un appareil Greengrass Core. Pour de plus amples informations, veuillez consulter [Activation de la la détection IP automatique](gg-core.md#ip-auto-detect). Journalisation Vérifie que le service de AWS IoT Greengrass journalisation peut écrire dans un fichier journal à l'aide d'une fonction Lambda utilisateur écrite en Python. MQTT Vérifie le fonctionnement du routeur de AWS IoT Greengrass messages en envoyant des messages sur un sujet qui est acheminé vers deux fonctions Lambda. Natif Vérifie que les fonctions Lambda natives (compilées) AWS IoT Greengrass peuvent être exécutées. Over-the-Air (OTA) Valide que votre appareil peut effectuer avec succès une mise à jour OTA du logiciel AWS IoT Greengrass Core. Pénétration Vérifie que le logiciel AWS IoT Greengrass Core ne démarre pas si la protection des liens matériels/logiciels et [seccomp](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt) ne sont pas activés. Il vérifie également d'autres fonctions liées à la sécurité. Shadow Vérifie la fonctionnalité shadow locale et la fonctionnalité de synchronisation du Cloud shadow. Spooler Vérifie que les messages MQTT sont mis en file d'attente avec la configuration du spooler par défaut. Service d'échange de jeton (TES) Vérifie qu'il est AWS IoT Greengrass possible d'échanger son certificat principal contre des AWS informations d'identification valides. Version Vérifie que la version AWS IoT Greengrass fournie est compatible avec la version de AWS IoT Device Tester que vous utilisez. **Groupes de test facultatifs** Ces tests sont facultatifs. Si vous choisissez de vous qualifier pour les tests facultatifs, votre appareil est répertorié avec des fonctionnalités supplémentaires dans le catalogue des AWS Partner appareils. Dépendances de conteneur Vérifie que le périphérique répond à toutes les dépendances requises pour exécuter les fonctions Lambda en mode conteneur. Intégration de sécurité matérielle (HSI) Vérifie que la bibliothèque partagée HSI fournie peut s'interfacer avec le module de sécurité matériel (HSM) et implémente correctement le PKCS \$111 requis. APIs La bibliothèque partagée/HSM doit signer une CSR, effectuer des opérations TLS et fournir les longueurs de clé et l'algorithme de clé publique corrects. Accès aux ressources locales Vérifie la fonctionnalité d'accès aux ressources locales (LRA) AWS IoT Greengrass en fournissant un accès aux fichiers et répertoires locaux appartenant à divers utilisateurs et groupes Linux aux fonctions Lambda conteneurisées via LRA. AWS IoT Greengrass APIs L'accès aux ressources locales doit être autorisé ou refusé aux fonctions Lambda en fonction de la configuration de l'accès aux ressources locales. Réseau Vérifie que les connexions socket peuvent être établies à partir d'une fonction Lambda. Ces connexions socket doivent être autorisées ou refusées en fonction de la configuration du noyau Greengrass. ------ # Conditions préalables à l'exécution de la suite de AWS IoT Greengrass qualifications Cette section décrit les conditions préalables à l'utilisation de AWS IoT Device Tester (IDT) AWS IoT Greengrass pour exécuter la suite de AWS IoT Greengrass qualification. ## Téléchargez la dernière version de AWS IoT Device Tester pour AWS IoT Greengrass Téléchargez la [dernière version](dev-test-versions.md) d'IDT et extrayez le logiciel dans un emplacement de votre système de fichiers où vous disposez d'autorisations de lecture et d'écriture. **Note** IDT ne prend pas en charge son exécution par plusieurs utilisateurs à partir d'un emplacement partagé, tel qu'un répertoire NFS ou un dossier partagé réseau Windows. Nous vous recommandons d'extraire le package IDT sur une unité locale et d'exécuter le fichier binaire IDT sur votre station de travail locale. Pour Windows, la limitation de la longueur du chemin est de 260 caractères. Si vous utilisez Windows, décompressez IDT dans un répertoire racine comme `C:\ ` ou `D:\` afin que la longueur de vos chemins respecte la limite de 260 caractères. ## Créez et configurez un Compte AWS Avant de pouvoir utiliser IDT pour AWS IoT Greengrass, vous devez effectuer les étapes suivantes : 1. [Créez un Compte AWS.]() Si vous en avez déjà un Compte AWS, passez à l'étape 2. 1. [Configurez les autorisations pour IDT.]() Ces autorisations de compte permettent à IDT d'accéder aux AWS services et de créer des AWS ressources, telles que des AWS IoT objets, des groupes Greengrass et des fonctions Lambda, en votre nom. Pour créer ces ressources, IDT for AWS IoT Greengrass utilise les AWS informations d'identification configurées dans le `config.json` fichier pour effectuer des appels d'API en votre nom. Ces ressources sont allouées à différents moments d'un test. **Note** Bien que la plupart des tests soient éligibles au [niveau gratuit d'Amazon Web Services](https://aws.amazon.com/free), vous devez fournir une carte de crédit lorsque vous vous inscrivez à un Compte AWS. Pour de plus amples informations, veuillez consulter [Pourquoi ai-je besoin d'un mode de paiement si mon compte est couvert par le niveau gratuit ?](https://aws.amazon.com/premiumsupport/knowledge-center/free-tier-payment-method/). ### Étape 1 : Création d'un Compte AWS Dans cette étape, créez et configurez un Compte AWS. Si vous en avez déjà un Compte AWS, passez directement à[Étape 2 : Configurer les autorisations pour IDT](#configure-idt-permissions). #### Inscrivez-vous pour un Compte AWS Si vous n'en avez pas Compte AWS, procédez comme suit pour en créer un. **Pour vous inscrire à un Compte AWS** 1. Ouvrez l'[https://portal.aws.amazon.com/billing/inscription.](https://portal.aws.amazon.com/billing/signup) 1. Suivez les instructions en ligne. Dans le cadre de la procédure d’inscription, vous recevrez un appel téléphonique ou un SMS et vous saisirez un code de vérification en utilisant le clavier numérique du téléphone. Lorsque vous vous inscrivez à un Compte AWS, un *Utilisateur racine d'un compte AWS*est créé. Par défaut, seul l’utilisateur racine a accès à l’ensemble des Services AWS et des ressources de ce compte. La meilleure pratique de sécurité consiste à attribuer un accès administratif à un utilisateur, et à utiliser uniquement l’utilisateur racine pour effectuer les [tâches nécessitant un accès utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks). AWS vous envoie un e-mail de confirmation une fois le processus d'inscription terminé. À tout moment, vous pouvez consulter l'activité actuelle de votre compte et le gérer en accédant à [https://aws.amazon.com/](https://aws.amazon.com/)et en choisissant **Mon compte**. #### Création d’un utilisateur doté d’un accès administratif Après vous être inscrit à un Compte AWS, sécurisez Utilisateur racine d'un compte AWS AWS IAM Identity Center, activez et créez un utilisateur administratif afin de ne pas utiliser l'utilisateur root pour les tâches quotidiennes. **Sécurisez votre Utilisateur racine d'un compte AWS** 1. Connectez-vous en [AWS Management Console](https://console.aws.amazon.com/)tant que propriétaire du compte en choisissant **Utilisateur root** et en saisissant votre adresse Compte AWS e-mail. Sur la page suivante, saisissez votre mot de passe. Pour obtenir de l’aide pour vous connecter en utilisant l’utilisateur racine, consultez [Connexion en tant qu’utilisateur racine](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) dans le *Guide de l’utilisateur Connexion à AWS *. 1. Activez l’authentification multifactorielle (MFA) pour votre utilisateur racine. Pour obtenir des instructions, voir [Activer un périphérique MFA virtuel pour votre utilisateur Compte AWS root (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) dans le guide de l'utilisateur *IAM*. **Création d’un utilisateur doté d’un accès administratif** 1. Activez IAM Identity Center. Pour obtenir des instructions, consultez [Activation d’ AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *. 1. Dans IAM Identity Center, octroyez un accès administratif à un utilisateur. Pour un didacticiel sur l'utilisation du Répertoire IAM Identity Center comme source d'identité, voir [Configurer l'accès utilisateur par défaut Répertoire IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) dans le *Guide de AWS IAM Identity Center l'utilisateur*. **Connexion en tant qu’utilisateur doté d’un accès administratif** + Pour vous connecter avec votre utilisateur IAM Identity Center, utilisez l’URL de connexion qui a été envoyée à votre adresse e-mail lorsque vous avez créé l’utilisateur IAM Identity Center. Pour obtenir de l'aide pour vous connecter en utilisant un utilisateur d'IAM Identity Center, consultez la section [Connexion au portail AWS d'accès](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) dans le *guide de l'Connexion à AWS utilisateur*. **Attribution d’un accès à d’autres utilisateurs** 1. Dans IAM Identity Center, créez un ensemble d’autorisations qui respecte la bonne pratique consistant à appliquer les autorisations de moindre privilège. Pour obtenir des instructions, consultez [Création d’un ensemble d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *. 1. Attribuez des utilisateurs à un groupe, puis attribuez un accès par authentification unique au groupe. Pour obtenir des instructions, consultez [Ajout de groupes](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *. ### Étape 2 : Configurer les autorisations pour IDT Dans cette étape, configurez les autorisations qu'IDT for AWS IoT Greengrass utilise pour exécuter des tests et collecter des données d'utilisation IDT. Vous pouvez utiliser le AWS Management Console ou AWS Command Line Interface (AWS CLI) pour créer une stratégie IAM et un utilisateur de test pour IDT, puis associer des politiques à l'utilisateur. Si vous avez déjà créé un utilisateur test pour IDT, passez à [Configurez votre appareil pour exécuter des tests IDT](device-config-setup.md) ou [Facultatif : Configuration de votre conteneur Docker pour IDT pour AWS IoT Greengrass](docker-config-setup.md). + [Pour configurer des autorisations pour IDT (console)](#configure-idt-permissions-console) + [Pour configurer des autorisations pour IDT (AWS CLI)](#configure-idt-permissions-cli) **Pour configurer des autorisations pour IDT (console)** Procédez comme suit pour utiliser la console afin de configurer les autorisations pour IDT pour AWS IoT Greengrass. 1. Connectez-vous à la [console IAM](https://console.aws.amazon.com/iam). 1. Créez une stratégie gérée par le client qui accorde des autorisations de création des rôles avec des autorisations spécifiques. 1. Dans le volet de navigation, sélectionnez **Politiques**, puis **Créer une politique**. 1. Sur l'onglet **JSON**, remplacez le contenu de l'espace réservé par la stratégie suivante. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ManageRolePoliciesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:DetachRolePolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::*:role/idt-*", "arn:aws:iam::*:role/GreengrassServiceRole" ], "Condition": { "ArnEquals": { "iam:PolicyARN": [ "arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy", "arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess", "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" ] } } }, { "Sid": "ManageRolesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:DeleteRole", "iam:PassRole", "iam:GetRole" ], "Resource": [ "arn:aws:iam::123456789012:role/idt-*", "arn:aws:iam::123456789012:role/GreengrassServiceRole" ] } ] } ``` ------ **Important** La stratégie suivante accorde l'autorisation de créer et de gérer les rôles requis par IDT pour AWS IoT Greengrass. Cela inclut les autorisations permettant d'associer les politiques AWS gérées suivantes : [AWSGreengrassResourceAccessRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy) [Greengrass OTAUpdate ArtifactAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess) [AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole) 1. Choisissez **Suivant : Balises**. 1. Choisissez **Suivant : Vérification**. 1. Pour **Nom**, saisissez **IDTGreengrassIAMPermissions**. Sous **Résumé**, vérifiez les autorisations accordées par votre stratégie. 1. Choisissez **Create Policy** (Créer une politique). 1. Créez un utilisateur IAM et associez les autorisations requises par IDT pour. AWS IoT Greengrass 1. Créez un utilisateur IAM. Suivez les étapes 1 à 5 de la section [Création d'utilisateurs IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) dans le guide de l'*utilisateur IAM*. 1. Associez les autorisations à votre utilisateur IAM : 1. Sur la page **Définir les autorisations**, choisissez **Joindre directement les politiques existantes**. 1. Recherchez la **IDTGreengrassIAMPermissions**politique que vous avez créée à l'étape précédente. Activez la case à cocher. 1. Recherchez la **AWSIoTDeviceTesterForGreengrassFullAccess**politique. Activez la case à cocher. **Note** [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)Il s'agit d'une politique AWS gérée qui définit les autorisations dont IDT a besoin pour créer et accéder aux AWS ressources utilisées pour les tests. Pour de plus amples informations, veuillez consulter [AWS politique gérée pour AWS IoT Device Tester](#idt-managed-policy). 1. Choisissez **Suivant : Identifications**. 1. Choisissez **Suivant : Réviser** pour afficher un résumé de vos choix. 1. Choisissez **Create user (Créer un utilisateur)**. 1. Pour afficher les clés d'accès de l'utilisateur (clé d'accès IDs et clés d'accès secrètes), choisissez **Afficher** à côté du mot de passe et de la clé d'accès. Pour enregistrer les clés d'accès, choisissez **Télécharger .csv**, puis enregistrez le fichier dans un emplacement sécurisé sur votre ordinateur. Vous utiliserez ces informations ultérieurement pour configurer votre fichier AWS d'informations d'identification. 1. Étape suivante : Configurez votre [appareil physique](device-config-setup.md).   **Pour configurer des autorisations pour IDT (AWS CLI)** Suivez ces étapes pour utiliser le AWS CLI afin de configurer les autorisations pour IDT pour AWS IoT Greengrass. Si vous avez déjà configuré des autorisations dans la console, passez à [Configurez votre appareil pour exécuter des tests IDT](device-config-setup.md) ou [Facultatif : Configuration de votre conteneur Docker pour IDT pour AWS IoT Greengrass](docker-config-setup.md). 1. Sur votre ordinateur, installez et configurez le AWS CLI s'il n'est pas déjà installé. Suivez les étapes décrites AWS CLI dans [la section Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) du *guide de AWS Command Line Interface l'utilisateur*. **Note** AWS CLI Il s'agit d'un outil open source que vous pouvez utiliser pour interagir avec les AWS services à partir de votre shell de ligne de commande. 1. Créez une stratégie gérée par le client qui accorde les autorisations pour gérer IDT et les rôles AWS IoT Greengrass . ------ #### [ Linux, macOS, or Unix ] ``` aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document '{ "Version":"2012-10-17", "Statement": [ { "Sid": "ManageRolePoliciesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:DetachRolePolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::*:role/idt-*", "arn:aws:iam::*:role/GreengrassServiceRole" ], "Condition": { "ArnEquals": { "iam:PolicyARN": [ "arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy", "arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess", "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" ] } } }, { "Sid": "ManageRolesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:DeleteRole", "iam:PassRole", "iam:GetRole" ], "Resource": [ "arn:aws:iam::123456789012:role/idt-*", "arn:aws:iam::123456789012:role/GreengrassServiceRole" ] } ] }' ``` ------ #### [ Windows command prompt ] ``` aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document '{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"ManageRolePoliciesForIDTGreengrass\",\"Effect\": \"Allow\",\"Action\": [\"iam:DetachRolePolicy\", \"iam:AttachRolePolicy\"], \"Resource\": [\"arn:aws:iam::*:role/idt-*\",\"arn:aws:iam::*:role/GreengrassServiceRole\"],\"Condition\": {\"ArnEquals\": {\"iam:PolicyARN\": [\"arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy\",\"arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess\",\"arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole\"]}}},{\"Sid\": \"ManageRolesForIDTGreengrass\",\"Effect\": \"Allow\",\"Action\": [\"iam:CreateRole\",\"iam:DeleteRole\", \"iam:PassRole\", \"iam:GetRole\"],\"Resource\": [\"arn:aws:iam::*:role/idt-*\",\"arn:aws:iam::*:role/GreengrassServiceRole\"]}]}' ``` **Note** Cette étape inclut un exemple d'invite de commande Windows car elle utilise une syntaxe JSON différente de celle des commandes de terminal Linux, macOS ou Unix. ------ 1. Créez un utilisateur IAM et associez les autorisations requises par IDT pour. AWS IoT Greengrass 1. Créez un utilisateur IAM. Dans cet exemple de configuration, l'utilisateur est nommé `IDTGreengrassUser`. ``` aws iam create-user --user-name IDTGreengrassUser ``` 1. Attachez la `IDTGreengrassIAMPermissions` politique que vous avez créée à l'étape 2 à votre utilisateur IAM. Remplacez ** dans la commande par l'identifiant de votre Compte AWS. ``` aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions ``` 1. Attachez la `AWSIoTDeviceTesterForGreengrassFullAccess` politique à votre utilisateur IAM. ``` aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess ``` **Note** [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)Il s'agit d'une politique AWS gérée qui définit les autorisations dont IDT a besoin pour créer et accéder aux AWS ressources utilisées pour les tests. Pour de plus amples informations, veuillez consulter [AWS politique gérée pour AWS IoT Device Tester](#idt-managed-policy). 1. Créez une clé d'accès secrète pour l'utilisateur. ``` aws iam create-access-key --user-name IDTGreengrassUser ``` Stockez la sortie dans un emplacement sécurisé. Vous utiliserez ces informations ultérieurement pour configurer votre fichier AWS d'informations d'identification. 1. Étape suivante : Configurez votre [appareil physique](device-config-setup.md). ## AWS politique gérée pour AWS IoT Device Tester La politique [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)gérée permet à IDT d'exécuter des opérations et de collecter des métriques d'utilisation. Cette stratégie accorde les autorisations IDT suivantes : + `iot-device-tester:CheckVersion`. Vérifiez si un ensemble de versions AWS IoT Greengrass, une suite de tests et une version IDT sont compatibles. + `iot-device-tester:DownloadTestSuite`. Téléchargez les suites de tests. + `iot-device-tester:LatestIdt`. Obtenez des informations sur la dernière version d'IDT disponible en téléchargement. + `iot-device-tester:SendMetrics`. Publiez les données d'utilisation collectées par IDT à propos de vos tests. + `iot-device-tester:SupportedVersion`. Obtenez la liste des versions AWS IoT Greengrass de la suite de tests prises en charge par IDT. Ces informations apparaissent dans la fenêtre de ligne de commande. # Configurez votre appareil pour exécuter des tests IDT Pour configurer votre appareil, vous devez installer des AWS IoT Greengrass dépendances, configurer le logiciel AWS IoT Greengrass principal, configurer votre ordinateur hôte pour accéder à votre appareil et configurer les autorisations utilisateur sur votre appareil. ## Vérifiez AWS IoT Greengrass les dépendances sur l'appareil testé Avant qu'IDT for AWS IoT Greengrass puisse tester vos appareils, assurez-vous que vous les avez configurés comme décrit dans la section [Mise en route avec AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-gs.html). Pour de plus amples informations sur les plateformes prises en charge, veuillez consulter [Plateformes prises en charge](https://docs.aws.amazon.com/greengrass/latest/developerguide/what-is-gg.html#gg-platforms). ## Configuration du AWS IoT Greengrass logiciel IDT pour AWS IoT Greengrass tester la compatibilité de votre appareil avec une version spécifique de AWS IoT Greengrass. IDT propose deux options pour effectuer des tests AWS IoT Greengrass sur vos appareils : + Téléchargez et utilisez une version du [logiciel AWS IoT Greengrass Core](what-is-gg.md#gg-core-download-tab). IDT installe le logiciel pour vous. + Utilisez une version du logiciel AWS IoT Greengrass Core déjà installée sur votre appareil. **Note** Chaque version de AWS IoT Greengrass possède une version IDT correspondante. Vous devez télécharger la version d'IDT qui correspond à la version que AWS IoT Greengrass vous utilisez. Les sections suivantes décrivent ces options. Vous devez en choisir une seule. ### Option 1 : télécharger le logiciel AWS IoT Greengrass principal et configurer AWS IoT Device Tester pour l'utiliser Vous pouvez télécharger le logiciel AWS IoT Greengrass Core depuis la page de téléchargement du [logiciel AWS IoT Greengrass Core](what-is-gg.md#gg-core-download-tab). 1. Identifiez l'architecture et la distribution Linux appropriées, puis choisissez **Download (Télécharger)**. 1. Copiez le fichier tar.gz dans `/products/greengrass/ggc`. **Note** Ne modifiez pas le nom du fichier AWS IoT Greengrass tar.gz. Ne placez pas plusieurs fichiers dans ce répertoire pour le même système d'exploitation et la même architecture. Par exemple, si les fichiers `greengrass-linux-armv7l-1.7.1.tar.gz` et `greengrass-linux-armv7l-1.8.1.tar.gz` figurent tous les deux dans ce répertoire, le test échoue. ### Option 2 : utiliser une installation existante de AWS IoT Greengrass avec AWS IoT Device Tester Configurez IDT pour tester le logiciel AWS IoT Greengrass Core installé sur votre appareil en ajoutant l'`greengrassLocation`attribut au `device.json` fichier du `/configs` dossier. Par exemple : ``` "greengrassLocation" : "" ``` Pour plus d'informations sur le fichier `device.json`, consultez [Configurer device.json](set-config.md#device-config). Sur les appareils Linux, l'emplacement par défaut du logiciel AWS IoT Greengrass Core est`/greengrass`. **Note** Le logiciel AWS IoT Greengrass Core doit être installé sur votre appareil mais celui-ci n'a pas encore été démarré. Vérifiez que vous avez ajouté l'utilisateur `ggc_user` et `ggc_group` sur votre appareil. Pour de plus amples informations, veuillez consulter [Configuration de l'environnement pour AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/module1.html). ## Configurer votre ordinateur hôte pour accéder à l'appareil testé IDT s'exécute sur votre ordinateur hôte et doit être en mesure d'utiliser SSH pour se connecter à votre appareil. Il existe deux options pour permettre à IDT d'obtenir un accès SSH à vos appareils testés : 1. Suivez les instructions indiquées ici pour créer une paire de clés SSH et autoriser votre clé à se connecter à votre appareil testé sans spécifier de mot de passe. 1. Fournissez un nom d'utilisateur et un mot de passe pour chaque appareil du fichier `device.json`. Pour de plus amples informations, veuillez consulter [Configurer device.json](set-config.md#device-config). Vous pouvez utiliser n'importe quelle implémentation SSL pour créer une clé SSH. Les instructions suivantes vous montrent comment utiliser [SSH-KEYGEN](https://www.ssh.com/ssh/keygen/) ou [Pu TTYgen](https://www.ssh.com/ssh/putty/windows/puttygen) (pour Windows). Si vous utilisez une autre implémentation SSL, veuillez vous reporter à la documentation correspondante. IDT utilise les clés SSH pour s'authentifier avec votre appareil testé. **Pour créer une clé SSH avec SSH-KEYGEN** 1. Créez une clé SSH. Vous pouvez utiliser la commande **ssh-keygen** Open SSH pour créer une paire de clés SSH. Si vous disposez déjà d'une paire de clés SSH sur votre ordinateur hôte, la bonne pratique consiste à créer une paire de clés SSH spécifique pour IDT. Ainsi, une fois que vous avez terminé le test, votre ordinateur hôte ne peut plus se connecter à votre appareil sans saisir de mot de passe. Cela vous permet également de restreindre l'accès à l'appareil à distance aux seules personnes qui en ont besoin. **Note** Windows n'a pas de client SSH installé. Pour plus d'informations sur l'installation d'un client SSH sous Windows, consultez [Download SSH Client Software](https://www.ssh.com/ssh/#sec-Download-client-software). La commande **ssh-keygen** vous invite à indiquer un nom et un chemin d'accès pour stocker la paire de clés. Par défaut, les fichiers de la paire de clés sont nommés `id_rsa` (clé privée) et `id_rsa.pub` (clé publique). Sur Mac OS et Linux, l'emplacement par défaut de ces fichiers est `~/.ssh/`. Sur Windows, l'emplacement par défaut est `C:\Users\\.ssh`. Lorsque vous y êtes invité, saisissez une expression clé pour protéger votre clé SSH. Pour de plus amples informations, veuillez consulter [Generate a New SSH key](https://www.ssh.com/ssh/keygen/). 1. Ajoutez des clés SSH autorisées à l'appareil testé. IDT doit utiliser votre clé SSH privée pour se connecter à l'appareil testé. Pour autoriser votre clé SSH privée à se connecter à l'appareil testé, utilisez la commande **ssh-copy-id** à partir de votre ordinateur hôte. Cette commande ajoute votre clé publique au fichier `~/.ssh/authorized_keys` sur l'appareil testé. Par exemple : **\$1 ssh-copy-id **@**** Où *remote-ssh-user* sont le nom d'utilisateur utilisé pour vous connecter à votre appareil testé et *remote-device-ip* l'adresse IP de l'appareil testé sur lequel effectuer les tests ? Par exemple : **ssh-copy-id pi@192.168.1.5** Lorsque vous y êtes invité, entrez le mot de passe du nom d'utilisateur que vous avez spécifié dans la commande **ssh-copy-id**. **ssh-copy-id** suppose que la clé publique est nommée `id_rsa.pub` et est stockée à l'emplacement par défaut (sur Mac OS et Linux, `~/.ssh/` et sur Windows, `C:\Users\\.ssh`). Si vous avez donné à la clé publique un autre nom ou si vous l'avez stockée à un autre emplacement, vous devez spécifier le chemin d'accès qualifié complet de votre clé publique SSH à l'aide de l'option **-i** pour **ssh-copy-id** (par exemple, **ssh-copy-id -i \$1/my/path/myKey.pub**). Pour plus d'informations sur la création de clés SSH et la copie des clés publiques, consultez [SSH-COPY-ID](https://www.ssh.com/ssh/copy-id). **Pour créer une clé SSH à l'aide de Pu TTYgen (Windows uniquement)** 1. Assurez-vous que le serveur et le client OpenSSH sont installés sur votre appareil testé. Pour plus d'informations, consultez [OpenSSH](https://www.openssh.com/). 1. Installez [Pu TTYgen](https://www.puttygen.com/) sur votre appareil en cours de test. 1. Ouvrez PuTTYgen. 1. Choisissez **Generate (Générer)** et déplacez le curseur de la souris dans la zone pour générer une clé privée. 1. Dans le menu **Conversions** choisissez **Export OpenSSH key**, et enregistrez la clé privée avec une extension de fichier `.pem`. 1. Ajoutez la clé publique au fichier `/home//.ssh/authorized_keys` sur l'appareil testé. 1. Copiez le texte de la clé publique depuis la TTYgen fenêtre Pu. 1. Utilisez PuTTY pour créer une session sur votre appareil testé. 1. À partir d'une invite de commande ou d'une fenêtre Windows Powershell, exécutez la commande suivante : **C:/**/putty.exe -ssh **@**** 1. Lorsque vous y êtes invité, entrez le mot de passe de votre appareil. 1. Utilisez vi ou un autre éditeur de texte pour ajouter la clé publique au fichier `/home//.ssh/authorized_keys` sur votre appareil testé. 1. Mettez à jour votre fichier `device.json` avec votre nom d'utilisateur, l'adresse IP et le chemin d'accès au fichier de clé privée que vous venez d'enregistrer sur votre ordinateur hôte pour chaque appareil testé. Pour de plus amples informations, veuillez consulter [Configurer device.json](set-config.md#device-config). Assurez-vous de fournir le chemin d'accès complet et le nom de fichier à la clé privée et d'utiliser des barres obliques (« / »). Par exemple, pour le chemin Windows `C:\DT\privatekey.pem`, utilisez `C:/DT/privatekey.pem` dans le fichier `device.json`. ## Configurer les autorisations utilisateur sur votre appareil IDT effectue des opérations sur différents répertoires et fichiers d'un appareil testé. Certaines de ces opérations nécessitent des autorisations d'un niveau élevé (à l'aide de la commande **sudo**). Pour automatiser ces opérations, IDT for AWS IoT Greengrass doit être capable d'exécuter des commandes avec sudo sans qu'un mot de passe ne soit demandé. Suivez ces étapes sur l'appareil testé afin d'autoriser l'accès sudo sans avoir à saisir un mot de passe. **Note** `username` fait référence à l'utilisateur SSH utilisé par IDT pour accéder à l'appareil testé. **Pour ajouter l'utilisateur au groupe sudo** 1. Sur l'appareil testé, exécutez `sudo usermod -aG sudo ` 1. Déconnectez-vous, puis reconnectez-vous pour que les modifications entrent en vigueur. 1. Vérifiez que votre nom d'utilisateur a été correctement ajouté et exécutez **sudo echo test**. Si vous n'êtes pas invité à saisir un mot de passe, cela signifie que votre utilisateur est configuré correctement. 1. Ouvrez le fichier `/etc/sudoers`, puis ajoutez la ligne suivante à la fin du fichier : ` ALL=(ALL) NOPASSWD: ALL` ## Configurer votre appareil pour tester des fonctions facultatives Les rubriques suivantes décrivent comment configurer vos appareils pour exécuter des tests IDT pour des fonctions facultatives. Suivez ces étapes de configuration uniquement si vous souhaitez tester ces fonctions. Dans le cas contraire, passez à [Configurer les paramètres IDT pour exécuter la suite de AWS IoT Greengrass qualification](set-config.md). **Topics** + [ ## Vérifiez AWS IoT Greengrass les dépendances sur l'appareil testé ](#install-gg-dependencies) + [ ## Configuration du AWS IoT Greengrass logiciel ](#config-gg) + [ ## Configurer votre ordinateur hôte pour accéder à l'appareil testé ](#configure-host) + [ ## Configurer les autorisations utilisateur sur votre appareil ](#root-access) + [ ## Configurer votre appareil pour tester des fonctions facultatives ](#optional-feature-config) + [ # Facultatif : Configuration de votre conteneur Docker pour IDT pour AWS IoT Greengrass ](docker-config-setup.md) + [ # Facultatif : Configuration de votre appareil pour la qualification ML ](idt-ml-qualification.md) # Facultatif : Configuration de votre conteneur Docker pour IDT pour AWS IoT Greengrass AWS IoT Greengrass fournit une image Docker et un Dockerfile qui facilitent l'exécution du logiciel AWS IoT Greengrass Core dans un conteneur Docker. Après avoir configuré le AWS IoT Greengrass conteneur, vous pouvez exécuter des tests IDT. Actuellement, seules les architectures Docker x86\$164 sont prises en charge pour exécuter IDT pour AWS IoT Greengrass. Cette fonctionnalité nécessite IDT v2.3.0 ou une version ultérieure. Le processus de configuration du conteneur Docker pour exécuter des tests IDT dépend de l'utilisation de l'image Docker ou du Dockerfile fourni par. AWS IoT Greengrass + [Utilisez l'image Docker](#docker-config-setup-docker-image). Le logiciel AWS IoT Greengrass Core et ses dépendances sont installés sur l'image Docker. + [Utilisez le Dockerfile](#docker-config-setup-dockerfile). Le Dockerfile contient le code source que vous pouvez utiliser pour créer des images de AWS IoT Greengrass conteneur personnalisées. L'image peut être modifiée pour s'exécuter sur différentes architectures de plateformes ou pour réduire la taille de l'image. **Note** AWS IoT Greengrass ne fournit pas de Dockerfiles ou d'images Docker pour la version 1.11.1 du logiciel AWS IoT Greengrass de base. Pour exécuter des tests IDT sur vos propres images de conteneur personnalisées, votre image doit inclure les dépendances définies dans le Dockerfile fourni par. AWS IoT Greengrass Les fonctionnalités suivantes ne sont pas disponibles lorsque vous exécutez AWS IoT Greengrass dans un conteneur Docker : + [Connecteurs](connectors.md) qui s'exécutent en mode **Greengrass container (Conteneur Greengrass)**. Pour exécuter un connecteur dans un conteneur Docker, le connecteur doit s'exécuter en mode **No container (Aucun conteneur)**. Pour rechercher des connecteurs prenant en charge le mode **No container (Aucun conteneur)** veuillez consulter [AWS- connecteurs Greengrass fournis](connectors-list.md). Certains de ces connecteurs ont un paramètre de mode d'isolement que vous devez définir sur **Aucun conteneur**. + [Ressources de volumes et d'appareils locales](access-local-resources.md). Vos fonctions Lambda définies par l'utilisateur qui s'exécutent dans le conteneur Docker doivent accéder directement aux appareils et aux volumes du cœur. ## Configurez l'image Docker fournie par AWS IoT Greengrass Suivez ces étapes pour configurer l'image AWS IoT Greengrass Docker afin d'exécuter des tests IDT. **Conditions préalables** Avant de commencer ce didacticiel, vous devez effectuer les opérations suivantes. + Vous devez installer les logiciels et versions suivants sur votre ordinateur hôte en fonction de la version AWS Command Line Interface (AWS CLI) que vous avez choisie. ------ #### [ AWS CLI version 2 ] + [Docker](https://docs.docker.com/install/) version 18.09 ou ultérieure. Les versions antérieures peuvent également fonctionner, mais nous recommandons la version 18.09 ou ultérieure. + AWS CLI version 2.0.0 ou ultérieure. + Pour installer la AWS CLI version 2, voir [Installation de la AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html). + Pour configurer le AWS CLI, reportez-vous à [la section Configuration du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html). **Note** Pour effectuer une mise à niveau vers une AWS CLI version 2 ultérieure sur un ordinateur Windows, vous devez répéter le processus [d'installation de MSI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-windows.html). ------ #### [ AWS CLI version 1 ] + [Docker](https://docs.docker.com/install/) version 18.09 ou ultérieure. Les versions antérieures peuvent également fonctionner, mais nous recommandons la version 18.09 ou ultérieure. + [Python](https://www.python.org/downloads/) version 3.6 ou ultérieure. + [pip](https://pip.pypa.io/en/stable/installing) version 18.1 ou suivante. + AWS CLI version 1.17.10 ou ultérieure + Pour installer la AWS CLI version 1, voir [Installation de la AWS CLI version 1](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html). + Pour configurer le AWS CLI, reportez-vous à [la section Configuration du AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html). + Pour effectuer une mise à niveau vers la dernière AWS CLI version de la version 1, exécutez la commande suivante. ``` pip install awscli --upgrade --user ``` **Note** Si vous utilisez l'[installation MSI](https://docs.aws.amazon.com/cli/latest/userguide/install-windows.html#msi-on-windows) de la AWS CLI version 1 sous Windows, tenez compte des points suivants : Si l'installation de la AWS CLI version 1 ne parvient pas à installer botocore, essayez d'utiliser l'installation [Python et pip](https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-windows.html#awscli-install-windows-pip). Pour effectuer une mise à niveau vers une AWS CLI version 1 ultérieure, vous devez répéter le processus d'installation de MSI. ------ + Pour accéder aux ressources d'Amazon Elastic Container Registry (Amazon ECR), vous devez accorder l'autorisation suivante. + Amazon ECR demande aux utilisateurs d'accorder l'`ecr:GetAuthorizationToken`autorisation par le biais d'une politique Gestion des identités et des accès AWS (IAM) avant de pouvoir s'authentifier auprès d'un registre et envoyer ou extraire des images d'un référentiel Amazon ECR. Pour plus d'informations, consultez les [exemples de politiques relatives aux référentiels Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html) et [l'accès à un référentiel Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-access-one-bucket) dans le guide de l'*utilisateur d'Amazon Elastic Container Registry*.   1. Téléchargez l'image Docker et configurez le conteneur. Vous pouvez télécharger l'image prédéfinie depuis [Docker Hub](https://hub.docker.com/r/amazon/aws-iot-greengrass) ou [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) (Amazon ECR) et l'exécuter sur les plateformes Windows, macOS et Linux (x86\$164). Pour télécharger l'image Docker depuis Amazon ECR, suivez toutes les étapes décrites dans. [Étape 1 : obtenir l'image du AWS IoT Greengrass conteneur depuis Amazon ECR](run-gg-in-docker-container.md#docker-pull-image) Revenez ensuite à cette rubrique pour continuer la configuration. 1. Utilisateurs Linux uniquement : assurez-vous que l'utilisateur qui exécute IDT a l'autorisation d'exécuter les commandes Docker. Pour de plus amples informations, veuillez consulter [Gérer Docker en tant qu'utilisateur non-racine](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user) dans la documentation Docker. 1. Pour exécuter le AWS IoT Greengrass conteneur, utilisez la commande correspondant à votre système d'exploitation : ------ #### [ Linux ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ -v : \ : ``` + Remplacez-le ** par le chemin du fichier de configuration du noyau sur l'hôte et ** par le chemin où le volume est monté dans le conteneur. Le fichier de configuration du noyau sur l'hôte se trouve généralement dans `/proc/config.gz` ou `/boot/config-`. Vous pouvez courir `uname -r` pour trouver la ** valeur. **Exemple :** Pour monter le fichier de configuration à partir de `/boot/config-` ``` -v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \ ``` **Exemple :** Pour monter le fichier de configuration à partir de `proc/config.gz` ``` -v /proc/config.gz:/proc/config.gz \ ``` + Remplacez ** : ** dans la commande par le nom du référentiel et le tag de l'image cible. **Exemple :** pour pointer vers la dernière version du logiciel de AWS IoT Greengrass base ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Pour obtenir la liste des images AWS IoT Greengrass Docker, exécutez la commande suivante. ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ macOS ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Remplacez ** : ** dans la commande par le nom du référentiel et le tag de l'image cible. **Exemple :** pour pointer vers la dernière version du logiciel de AWS IoT Greengrass base ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Pour obtenir la liste des images AWS IoT Greengrass Docker, exécutez la commande suivante : ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ Windows ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Remplacez ** : ** dans la commande par le nom du référentiel et le tag de l'image cible. **Exemple :** pour pointer vers la dernière version du logiciel de AWS IoT Greengrass base ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Pour obtenir la liste des images AWS IoT Greengrass Docker, exécutez la commande suivante : ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ **Important** Lorsque vous testez avec IDT, n'incluez pas l'`--entrypoint /greengrass-entrypoint.sh \`argument utilisé pour exécuter l'image pour un AWS IoT Greengrass usage général. 1. Étape suivante : [configurez vos AWS informations d'identification et votre `device.json` fichier](set-config.md). ## Configurez le fichier docker fourni par AWS IoT Greengrass Suivez ces étapes pour configurer l'image Docker créée à partir du AWS IoT Greengrass Dockerfile afin d'exécuter des tests IDT. 1. À partir de [AWS IoT Greengrass Logiciel Docker](what-is-gg.md#gg-docker-download), téléchargez le package Dockerfile sur votre ordinateur hôte et extrayez-le. 1. Ouvrir `README.md`. Les trois étapes suivantes font référence aux sections de ce fichier. 1. Assurez-vous que vous remplissez les conditions requises indiquées dans la section **Conditions préalables**. 1. Utilisateurs de Linux uniquement : suivez les étapes **Activer la protection des liens symboliques et physiques** et **Activer le transfert IPv4 réseau**. 1. Pour créer l'image Docker, suivez toutes les étapes de l'**étape 1. Créez l'image AWS IoT Greengrass Docker**. Revenez ensuite à cette rubrique pour continuer la configuration. 1. Pour exécuter le AWS IoT Greengrass conteneur, utilisez la commande correspondant à votre système d'exploitation : ------ #### [ Linux ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ -v : \ : ``` + Remplacez-le ** par le chemin du fichier de configuration du noyau sur l'hôte et ** par le chemin où le volume est monté dans le conteneur. Le fichier de configuration du noyau sur l'hôte se trouve généralement dans `/proc/config.gz` ou `/boot/config-`. Vous pouvez courir `uname -r` pour trouver la ** valeur. **Exemple :** Pour monter le fichier de configuration à partir de `/boot/config-` ``` -v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \ ``` **Exemple :** Pour monter le fichier de configuration à partir de `proc/config.gz` ``` -v /proc/config.gz:/proc/config.gz \ ``` + Remplacez ** : ** dans la commande par le nom du référentiel et le tag de l'image cible. **Exemple :** pour pointer vers la dernière version du logiciel de AWS IoT Greengrass base ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Pour obtenir la liste des images AWS IoT Greengrass Docker, exécutez la commande suivante. ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ macOS ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Remplacez ** : ** dans la commande par le nom du référentiel et le tag de l'image cible. **Exemple :** pour pointer vers la dernière version du logiciel de AWS IoT Greengrass base ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Pour obtenir la liste des images AWS IoT Greengrass Docker, exécutez la commande suivante : ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ Windows ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Remplacez ** : ** dans la commande par le nom du référentiel et le tag de l'image cible. **Exemple :** pour pointer vers la dernière version du logiciel de AWS IoT Greengrass base ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Pour obtenir la liste des images AWS IoT Greengrass Docker, exécutez la commande suivante : ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ **Important** Lorsque vous testez avec IDT, n'incluez pas l'`--entrypoint /greengrass-entrypoint.sh \`argument utilisé pour exécuter l'image pour un AWS IoT Greengrass usage général. 1. Étape suivante : [configurez vos AWS informations d'identification et votre `device.json` fichier](set-config.md). ## Résolution des problèmes de configuration de votre conteneur Docker pour IDT pour AWS IoT Greengrass Utilisez les informations suivantes pour résoudre les problèmes liés à l'exécution d'un conteneur Docker pour IDT à des fins de test. AWS IoT Greengrass ### AVERTISSEMENT : Erreur lors du chargement de la configurationfile:/home/user/.docker/config.json - stat /home//.docker/config.json : autorisation refusée Si vous obtenez cette erreur lors de l'exécution des commandes `docker` sous Linux, exécutez la commande suivante. Remplacez ** la commande suivante par l'utilisateur qui exécute IDT. ``` sudo chown : /home//.docker -R sudo chmod g+rwx /home//.docker -R ``` # Facultatif : Configuration de votre appareil pour la qualification ML IDT for AWS IoT Greengrass propose des tests de qualification pour le machine learning (ML) afin de valider que vos appareils peuvent effectuer des inférences de machine learning localement à l'aide de modèles conçus dans le cloud. Pour exécuter des tests de qualification ML, vous devez d'abord configurer vos appareils comme décrit dans [Configurez votre appareil pour exécuter des tests IDT](device-config-setup.md). Ensuite, suivez les étapes de cette rubrique pour installer les dépendances pour les frameworks ML que vous souhaitez exécuter. IDT v3.1.0 ou version ultérieure est nécessaire pour exécuter les tests de qualification ML. ## Installation des dépendances du framework ML Toutes les dépendances du framework ML doivent être installées sous le répertoire `/usr/local/lib/python3.x/site-packages`. Pour vous assurer qu'elles sont installées dans le répertoire correct, nous vous recommandons d'utiliser les autorisations racine `sudo` lors de l'installation des dépendances. Les environnements virtuels ne sont pas pris en charge pour les tests de qualification. **Note** Si vous testez des fonctions Lambda qui s'exécutent avec la [conteneurisation (](lambda-group-config.md#lambda-containerization-considerations)en mode **conteneur Greengrass**), la création de liens symboliques pour les bibliothèques Python n'est pas prise en charge. `/usr/local/lib/python3.x` Pour éviter les erreurs, vous devez installer les dépendances dans le répertoire correct. Suivez les étapes pour installer les dépendances pour votre framework cible : + [Installer MXNet les dépendances](#ml-qualification-mxnet-dependencies) + [Installer TensorFlow les dépendances](#ml-qualification-tensorflow-dependencies) + [Installation des dépendances DLR](#ml-qualification-dlr-dependencies)   ## Installation des MXNet dépendances Apache Les tests de qualification IDT pour ce framework ont les dépendances suivantes : + Python 3.6 ou Python 3.7. **Note** Si vous utilisez Python 3.6, vous devez créer un lien symbolique entre les fichiers binaires de Python 3.7 vers Python 3.6. Ceci configure votre appareil de sorte qu'il réponde aux exigence de Python pour AWS IoT Greengrass. Par exemple : ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + Apache MXNet v1.2.1 ou version ultérieure. + NumPy. La version doit être compatible avec MXNet la vôtre. ### Installation MXNet Suivez les instructions de la MXNet documentation pour procéder à [l'installation MXNet](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&). **Note** Si Python 2.x et Python 3.x sont tous deux installés sur votre appareil, utilisez Python 3.x dans les commandes que vous exécutez pour installer les dépendances. ### Validation de l'installation MXNet Choisissez l'une des options suivantes pour valider l' MXNet installation. #### Option 1 : SSH dans votre appareil et exécuter des scripts 1. SSH dans votre appareil. 1. Exécutez les scripts suivants pour vérifier que les dépendances sont correctement installées. ``` sudo python3.7 -c "import mxnet; print(mxnet.__version__)" ``` ``` sudo python3.7 -c "import numpy; print(numpy.__version__)" ``` La sortie imprime le numéro de version et le script doit se terminer sans erreur. #### Option 2 : Exécuter le test de dépendance IDT 1. Assurez-vous que le fichier `device.json` est configuré pour la qualification ML. Pour de plus amples informations, veuillez consulter [Configurer device.json pour la qualification ML](set-config.md#device-json-ml-qualification). 1. Exécutez le test des dépendances pour le framework. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id mxnet_dependency_check ``` Le récapitulatif du test affiche un résultat `PASSED` pour `mldependencies`.   ## Installer TensorFlow les dépendances Les tests de qualification IDT pour ce framework ont les dépendances suivantes : + Python 3.6 ou Python 3.7. **Note** Si vous utilisez Python 3.6, vous devez créer un lien symbolique entre les fichiers binaires de Python 3.7 vers Python 3.6. Ceci configure votre appareil de sorte qu'il réponde aux exigence de Python pour AWS IoT Greengrass. Par exemple : ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + TensorFlow 1.x. ### Installation TensorFlow Suivez les instructions de la TensorFlow documentation pour installer TensorFlow 1.x [avec pip](https://www.tensorflow.org/install/pip) ou [depuis](https://www.tensorflow.org/install/source) les sources. **Note** Si Python 2.x et Python 3.x sont tous deux installés sur votre appareil, utilisez Python 3.x dans les commandes que vous exécutez pour installer les dépendances. ### Validation de l'installation TensorFlow Choisissez l'une des options suivantes pour valider l' TensorFlow installation. #### Option 1 : SSH dans votre appareil et exécuter un script 1. SSH dans votre appareil. 1. Exécutez le script suivant pour vérifier que la dépendance est correctement installée. ``` sudo python3.7 -c "import tensorflow; print(tensorflow.__version__)" ``` La sortie imprime le numéro de version et le script doit se terminer sans erreur. #### Option 2 : Exécuter le test de dépendance IDT 1. Assurez-vous que le fichier `device.json` est configuré pour la qualification ML. Pour de plus amples informations, veuillez consulter [Configurer device.json pour la qualification ML](set-config.md#device-json-ml-qualification). 1. Exécutez le test des dépendances pour le framework. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id tensorflow_dependency_check ``` Le récapitulatif du test affiche un résultat `PASSED` pour `mldependencies`.   ## Installer les dépendances d'Amazon SageMaker AI Neo Deep Learning Runtime (DLR) Les tests de qualification IDT pour ce framework ont les dépendances suivantes : + Python 3.6 ou Python 3.7. **Note** Si vous utilisez Python 3.6, vous devez créer un lien symbolique entre les fichiers binaires de Python 3.7 vers Python 3.6. Ceci configure votre appareil de sorte qu'il réponde aux exigence de Python pour AWS IoT Greengrass. Par exemple : ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + SageMaker AI Neo DLR. + numpy. Après avoir installé les dépendances de test DLR, vous devez [compiler le modèle](#ml-qualification-dlr-compile-model). ### Installation de DLR Suivez les instructions de la documentation DLR pour [installer le Neo DLR](https://neo-ai-dlr.readthedocs.io/en/latest/install.html#building-on-linux). **Note** Si Python 2.x et Python 3.x sont tous deux installés sur votre appareil, utilisez Python 3.x dans les commandes que vous exécutez pour installer les dépendances. ### Validation de l'installation de DLR Choisissez une des options suivantes pour valider l'installation de DLR. #### Option 1 : SSH dans votre appareil et exécuter des scripts 1. SSH dans votre appareil. 1. Exécutez les scripts suivants pour vérifier que les dépendances sont correctement installées. ``` sudo python3.7 -c "import dlr; print(dlr.__version__)" ``` ``` sudo python3.7 -c "import numpy; print(numpy.__version__)" ``` La sortie imprime le numéro de version et le script doit se terminer sans erreur. #### Option 2 : Exécuter le test de dépendance IDT 1. Assurez-vous que le fichier `device.json` est configuré pour la qualification ML. Pour de plus amples informations, veuillez consulter [Configurer device.json pour la qualification ML](set-config.md#device-json-ml-qualification). 1. Exécutez le test des dépendances pour le framework. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id dlr_dependency_check ``` Le récapitulatif du test affiche un résultat `PASSED` pour `mldependencies`. ## Compilation du modèle DLR Vous devez compiler le modèle DLR avant de pouvoir l'utiliser pour les tests de qualification ML. Pour les étapes, choisissez une des options suivantes : ### Option 1 : utiliser Amazon SageMaker AI pour compiler le modèle Suivez ces étapes pour utiliser l' SageMaker IA afin de compiler le modèle ML fourni par IDT. Ce modèle est préentraîné avec Apache MXNet. 1. Vérifiez que votre type d'appareil est compatible avec l' SageMaker IA. Pour plus d'informations, consultez les [options de l'appareil cible](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_OutputConfig.html#sagemaker-Type-OutputConfig-TargetDevice) dans le *manuel Amazon SageMaker AI API Reference*. Si votre type d'appareil n'est actuellement pas pris en charge par l' SageMaker IA, suivez les étapes décrites dans[Option 2 : Utiliser TVM pour compiler le modèle DLR](#ml-qualification-compile-dlr-option-2). **Note** L'exécution du test DLR avec un modèle compilé par SageMaker AI peut prendre 4 ou 5 minutes. N'arrêtez pas IDT au cours de cette période. 1. Téléchargez le fichier tarball qui contient le MXNet modèle préentraîné et non compilé pour le DLR : + [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html) 1. Décompressez le fichier tarball. Cette commande génère la structure de répertoire suivante. ![\[Le répertoire resnet18 contient trois fichiers.\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png) 1. Déplacez `synset.txt` hors du répertoire `resnet18`. Notez le nouvel emplacement. Vous copierez ce fichier dans le répertoire du modèle compilé ultérieurement. 1. Compressez le contenu du répertoire `resnet18`. ``` tar cvfz model.tar.gz resnet18v1-symbol.json resnet18v1-0000.params ``` 1. Téléchargez le fichier compressé dans un compartiment Amazon S3 de votre Compte AWS, puis suivez les étapes décrites dans [Compiler un modèle (console)](https://docs.aws.amazon.com/sagemaker/latest/dg/neo-job-compilation-console.html) pour créer une tâche de compilation. 1. Pour **Configuration d'entrée**, utilisez les valeurs suivantes : + Pour **Configuration d'entrée de données**, entrez `{"data": [1, 3, 224, 224]}`. + Pour **Cadre de machine learning**, choisissez `MXNet`. 1. Pour **Configuration de sortie**, utilisez les valeurs suivantes : + Pour l'**emplacement de sortie S3**, entrez le chemin d'accès au compartiment ou au dossier Amazon S3 dans lequel vous souhaitez stocker le modèle compilé. + Pour **Périphérique cible**, choisissez votre type d'appareil. 1. Téléchargez le modèle compilé à partir de l'emplacement de sortie spécifié, puis décompressez le fichier. 1. Copiez `synset.txt` dans le répertoire du modèle compilé. 1. Renommez le répertoire du modèle compilé en `resnet18`. Votre répertoire de modèle compilé doit avoir la structure de répertoire suivante. ![\[Le répertoire du modèle compilé resnet18 contient quatre fichiers.\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-sm.png) ### Option 2 : Utiliser TVM pour compiler le modèle DLR Suivez ces étapes pour utiliser TVM afin de compiler le modèle ML fourni par IDT. Ce modèle étant préentraîné avec Apache MXNet, vous devez l'installer MXNet sur l'ordinateur ou le périphérique sur lequel vous compilez le modèle. Pour l'installer MXNet, suivez les instructions de la [ MXNet documentation](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&). **Note** Nous vous recommandons de compiler le modèle sur votre appareil cible. Cette pratique est facultative, mais elle peut aider à assurer la compatibilité et à atténuer les problèmes potentiels.   1. Téléchargez le fichier tarball qui contient le MXNet modèle préentraîné et non compilé pour le DLR : + [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html) 1. Décompressez le fichier tarball. Cette commande génère la structure de répertoire suivante. ![\[Le répertoire resnet18 contient trois fichiers.\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png) 1. Suivez les instructions de la documentation TVM pour [créer et installer TVM à partir de la source pour votre plateforme](https://docs.tvm.ai/install/from_source.html). 1. Une fois TVM créé, exécutez la compilation TVM pour le modèle resnet18. Les étapes suivantes sont basées sur le didacticiel [Quick Start Tutorial for Compiling Deep Learning Models](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#sphx-glr-tutorials-get-started-relay-quick-start-py), de la documentation TVM. 1. Ouvrez le fichier `relay_quick_start.py` à partir du référentiel TVM cloné. 1. Mettez à jour le code qui [définit un réseau neuronal en relais](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#define-neural-network-in-relay). Vous pouvez utiliser une des options suivantes : + Option 1 : Utiliser `mxnet.gluon.model_zoo.vision.get_model` pour obtenir le module et les paramètres de relais : ``` from mxnet.gluon.model_zoo.vision import get_model block = get_model('resnet18_v1', pretrained=True) mod, params = relay.frontend.from_mxnet(block, {"data": data_shape}) ``` + Option 2 : À partir du modèle non compilé que vous avez téléchargé à l'étape 1, copier les fichiers suivants dans le même répertoire que le fichier `relay_quick_start.py`. Ces fichiers contiennent le module et les paramètres de relais. + `resnet18v1-symbol.json` + `resnet18v1-0000.params` 1. Mettez à jour le code qui [enregistre et charge le module compilé](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#save-and-load-compiled-module) pour utiliser le code suivant. ``` from tvm.contrib import util path_lib = "deploy_lib.so" # Export the model library based on your device architecture lib.export_library("deploy_lib.so", cc="aarch64-linux-gnu-g++") with open("deploy_graph.json", "w") as fo: fo.write(graph) with open("deploy_param.params", "wb") as fo: fo.write(relay.save_param_dict(params)) ``` 1. Créez le modèle : ``` python3 tutorials/relay_quick_start.py --build-dir ./model ``` Cette commande génère les fichiers suivants. + `deploy_graph.json` + `deploy_lib.so` + `deploy_param.params` 1. Copiez les fichiers du modèle généré dans un répertoire nommé `resnet18`. Ceci est votre répertoire de modèle compilé. 1. Copiez le répertoire de modèle compilé sur votre ordinateur hôte. Copiez ensuite `synset.txt` à partir du modèle non compilé que vous avez téléchargé à l'étape 1 dans le répertoire de modèle compilé. Votre répertoire de modèle compilé doit avoir la structure de répertoire suivante. ![\[Le répertoire du modèle compilé resnet18 contient quatre fichiers.\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-tvm.png) [Configurez ensuite vos AWS informations d'identification et votre `device.json` fichier](set-config.md). # Configurer les paramètres IDT pour exécuter la suite de AWS IoT Greengrass qualification Avant d'exécuter les tests, vous devez configurer les paramètres des AWS informations d'identification et des périphériques sur votre ordinateur hôte. ## Configurez vos AWS informations d'identification Vous devez configurer vos informations d'identification d'utilisateur IAM dans le ` /configs/config.json` fichier. Utilisez les informations d'identification de l'IDT pour AWS IoT Greengrass l'utilisateur créé dans[Créez et configurez un Compte AWS](dev-tst-prereqs.md#config-aws-account-for-idt). Vous pouvez spécifier vos informations d'identification de deux manières : + Fichier d’informations d’identification + Variables d’environnement ### Configurer les AWS informations d'identification avec un fichier d'informations d'identification IDT utilise le même fichier d'informations d'identification que l' AWS CLI. Pour de plus amples informations, veuillez consulter [Fichiers de configuration et d'informations d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html). L'emplacement du fichier d'informations d'identification varie en fonction du système d'exploitation que vous utilisez : + macOS, Linux : `~/.aws/credentials` + Windows: `C:\Users\UserName\.aws\credentials` Ajoutez vos AWS informations d'identification au `credentials` fichier au format suivant : ``` [default] aws_access_key_id = aws_secret_access_key = ``` Pour configurer IDT AWS IoT Greengrass afin d'utiliser les AWS informations d'identification de votre `credentials` fichier, modifiez votre `config.json` fichier comme suit : ``` { "awsRegion": "us-west-2", "auth": { "method": "file", "credentials": { "profile": "default" } } } ``` **Note** Si vous n'utilisez pas le `default` AWS profil, veillez à modifier le nom du profil dans votre `config.json` fichier. Pour de plus amples informations, veuillez consulter [Profils nommés](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html). ### Configurer les AWS informations d'identification avec des variables d'environnement Les variables d'environnement sont des variables gérées par le système d'exploitation et utilisées par les commandes du système. Elles ne sont pas enregistrées si vous fermez la session SSH. IDT for AWS IoT Greengrass peut utiliser les variables d'`AWS_SECRET_ACCESS_KEY`environnement `AWS_ACCESS_KEY_ID` et pour stocker vos AWS informations d'identification. Pour définir ces variables sous Linux, macOS ou Unix, utilisez **export**: ``` export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= ``` Pour définir ces variables sous Windows, utilisez **set** : ``` set AWS_ACCESS_KEY_ID= set AWS_SECRET_ACCESS_KEY= ``` Pour configurer l'IDT afin que l'outil utilise les variables d'environnement, modifiez la section `auth` dans votre fichier `config.json`. Voici un exemple : ``` { "awsRegion": "us-west-2", "auth": { "method": "environment" } } ``` ## Configurer device.json Outre les AWS informations d'identification, IDT for AWS IoT Greengrass a besoin d'informations sur les appareils sur lesquels les tests sont exécutés (par exemple, adresse IP, informations de connexion, système d'exploitation et architecture du processeur). Vous pouvez fournir ces informations à l'aide du modèle `device.json` situé dans ` /configs/device.json` : ------ #### [ Physical device ] ``` [ { "id": "", "sku": "", "features": [ { "name": "os", "value": "linux | ubuntu | openwrt" }, { "name": "arch", "value": "x86_64 | armv6l | armv7l | aarch64" }, { "name": "container", "value": "yes | no" }, { "name": "docker", "value": "yes | no" }, { "name": "streamManagement", "value": "yes | no" }, { "name": "hsi", "value": "yes | no" }, { "name": "ml", "value": "mxnet | tensorflow | dlr | mxnet,dlr,tensorflow | no" }, *********** Remove the section below if the device is not qualifying for ML **************, { "name": "mlLambdaContainerizationMode", "value": "container | process | both" }, { "name": "processor", "value": "cpu | gpu" }, ****************************************************************************************** ], *********** Remove the section below if the device is not qualifying for HSI *************** "hsm": { "p11Provider": "/path/to/pkcs11ProviderLibrary", "slotLabel": "", "slotUserPin": "", "privateKeyLabel": "", "openSSLEngine": "/path/to/openssl/engine" }, ******************************************************************************************** *********** Remove the section below if the device is not qualifying for ML **************** "machineLearning": { "dlrModelPath": "/path/to/compiled/dlr/model", "environmentVariables": [ { "key": "", "value": "" } ], "deviceResources": [ { "name": "", "path": "", "type": "device | volume" } ] }, ****************************************************************************************** "kernelConfigLocation": "", "greengrassLocation": "", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": 22, "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` **Note** Spécifiez `privKeyPath` uniquement si `method` est défini sur `pki`. Spécifiez `password` uniquement si `method` est défini sur `password`. ------ #### [ Docker container ] ``` [ { "id": "", "sku": "", "features": [ { "name": "os", "value": "linux | ubuntu | openwrt" }, { "name": "arch", "value": "x86_64" }, { "name": "container", "value": "no" }, { "name": "docker", "value": "no" }, { "name": "streamManagement", "value": "yes | no" }, { "name": "hsi", "value": "no" }, { "name": "ml", "value": "mxnet | tensorflow | dlr | mxnet,dlr,tensorflow | no" }, *********** Remove the section below if the device is not qualifying for ML **************, { "name": "mlLambdaContainerizationMode", "value": "process" }, { "name": "processor", "value": "cpu | gpu" }, ****************************************************************************************** ], *********** Remove the section below if the device is not qualifying for ML **************** "machineLearning": { "dlrModelPath": "/path/to/compiled/dlr/model", "environmentVariables": [ { "key": "", "value": "" } ], "deviceResources": [ { "name": "", "path": "", "type": "device | volume" } ] }, ****************************************************************************************** "kernelConfigLocation": "", "greengrassLocation": "", "devices": [ { "id": "", "connectivity": { "protocol": "docker", "containerId": "", "containerUser": "" } } ] } ] ``` ------ Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `id` ID alphanumérique défini par l'utilisateur qui identifie de façon unique un ensemble d'appareils appelé un *groupe d'appareils*. Le matériel doit être identique pour les appareils d'un même groupe. Lorsque vous exécutez une suite de tests, les appareils du groupe sont utilisés pour paralléliser la charge de travail. Plusieurs appareils sont utilisés pour exécuter différents tests. `sku` Valeur alphanumérique qui identifie de façon unique l'appareil que vous testez. La référence est utilisée pour effectuer le suivi des cartes qualifiées. Si vous souhaitez mettre votre carte en vente dans le catalogue des AWS Partner appareils, le SKU que vous spécifiez ici doit correspondre au SKU que vous avez utilisé lors du processus de mise en vente. `features` Un tableau contenant les fonctions prises en charge de l'appareil. Toutes les fonctionnalités sont requises. `os` et `arch` Combinaisons de systèmes d'exploitation (OS) et d'architectures prises en charge : + `linux`, `x86_64` + `linux`, `armv6l` + `linux`, `armv7l` + `linux`, `aarch64` + `ubuntu`, `x86_64` + `openwrt`, `armv7l` + `openwrt`, `aarch64` Si vous utilisez IDT pour tester l' AWS IoT Greengrass exécution dans un conteneur Docker, seule l'architecture Docker x86\$164 est prise en charge. `container` Vérifie que l'appareil répond à toutes les exigences logicielles et matérielles pour exécuter les fonctions Lambda en mode conteneur sur un cœur Greengrass. La valeur valide est `yes` ou`no`. `docker` Vérifie que l'appareil répond à toutes les dépendances techniques requises pour utiliser le connecteur de déploiement d'applications Greengrass Docker pour exécuter des conteneurs La valeur valide est `yes` ou`no`. `streamManagement` Vérifie que l'appareil répond à toutes les dépendances techniques requises pour exécuter le gestionnaire de AWS IoT Greengrass flux. La valeur valide est `yes` ou`no`. `hsi` Vérifie que la bibliothèque partagée HSI fournie peut s'interfacer avec le module de sécurité matériel (HSM) et implémente correctement le PKCS \$111 requis. APIs La bibliothèque partagée/HSM doit signer une CSR, effectuer des opérations TLS et fournir les longueurs de clé et l'algorithme de clé publique corrects. La valeur valide est `yes` ou`no`. `ml` Valide que l'appareil est conforme à toutes les dépendances techniques requises pour pouvoir exécuter une inférence ML localement. La valeur valide peut être n'importe quelle combinaison de `mxnet` `tensorflow``dlr`,, et `no` (par exemple`mxnet`,`mxnet,tensorflow`,`mxnet,tensorflow,dlr`, ou`no`). `mlLambdaContainerizationMode` Valide que l'appareil répond à toutes les dépendances techniques requises pour effectuer une inférence ML en mode conteneur sur un appareil Greengrass. La valeur valide est `container``process`, ou`both`. `processor` Vérifie que le périphérique répond à toutes les exigences matérielles pour le type de processeur spécifié. La valeur valide est `cpu` ou`gpu`. Si vous ne souhaitez pas utiliser la `ml` fonctionnalité`container`,`docker`, ou `streamManager``hsi`, ou, vous pouvez définir la fonction correspondante `value` sur`no`. Docker ne prend en charge que la qualification des fonctionnalités pour `streamManagement` et. `ml` `machineLearning` Facultatif. Informations de configuration pour les tests de qualification ML. Pour de plus amples informations, veuillez consulter [Configurer device.json pour la qualification ML](#device-json-ml-qualification). `hsm` Facultatif. Informations de configuration pour les tests avec un module de sécurité AWS IoT Greengrass matériel (HSM). Sinon, la propriété `hsm` doit être omise. Pour de plus amples informations, veuillez consulter [Intégration de sécurité matérielle](hardware-security.md). Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `hsm.p11Provider` Chemin absolu vers la bibliothèque libdl-loadable d'implémentation PKCS \$1 11. `hsm.slotLabel` Étiquette d'emplacement utilisée pour identifier le module matériel. `hsm.slotUserPin` Le code PIN utilisateur utilisé pour authentifier le AWS IoT Greengrass noyau auprès du module. `hsm.privateKeyLabel` Étiquette utilisée pour identifier la clé dans le module matériel. `hsm.openSSLEngine` Chemin d'accès absolu au fichier `.so` du moteur OpenSSL qui active la prise en charge PKCS \$1 11 sur OpenSSL. Utilisé par l'agent de mise à jour AWS IoT Greengrass OTA. `devices.id` Un identificateur unique défini par l'utilisateur pour l'appareil testé. `connectivity.protocol` Le protocole de communication utilisé pour communiquer avec cet appareil. Actuellement, les seules valeurs prises en charge concernent `ssh` pour les appareils physiques et `docker` pour les conteneurs Docker. `connectivity.ip` L'adresse IP de l'appareil testé. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.containerId` ID de conteneur ou nom du conteneur Docker en cours de test. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `docker`. `connectivity.auth` Informations d'authentification pour la connexion. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.auth.method` Méthode d'authentification utilisée pour accéder à un appareil sur le protocole de connectivité donné. Les valeurs prises en charge sont : + `pki` + `password` `connectivity.auth.credentials` Informations d'identification utilisées pour l'authentification. `connectivity.auth.credentials.password` Mot de passe utilisé pour se connecter à l'appareil à tester. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `password`. `connectivity.auth.credentials.privKeyPath` Chemin complet de la clé privée utilisée pour se connecter à l'appareil testé. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `pki`. `connectivity.auth.credentials.user` Nom d'utilisateur pour la connexion à l'appareil testé. `connectivity.auth.credentials.privKeyPath` Chemin complet à la clé privée utilisée pour se connecter à l'appareil testé. `connectivity.port` Facultatif. Le numéro de port à utiliser pour les connexions SSH. La valeur par défaut est 22. Cette propriété ne s'applique que si elle `connectivity.protocol` est définie sur`ssh`. `greengrassLocation` L'emplacement du logiciel AWS IoT Greengrass Core sur vos appareils. Pour les appareils physiques, cette valeur n'est utilisée que lorsque vous utilisez une installation existante de AWS IoT Greengrass. Utilisez cet attribut pour indiquer à IDT qu'il doit utiliser le logiciel AWS IoT Greengrass Core installé sur vos appareils. Lorsque vous exécutez des tests dans un conteneur Docker à partir d'une image Docker ou d'un Dockerfile fourni par AWS IoT Greengrass, définissez cette valeur sur. `/greengrass` `kernelConfigLocation` Facultatif. Le chemin d'accès au fichier de configuration du noyau. AWS IoT Device Tester utilise ce fichier pour vérifier si les fonctionnalités du noyau requises sont activées sur les périphériques. S'il n'est pas spécifié, IDT utilise les chemins suivants pour rechercher le fichier de configuration du noyau : `/proc/config.gz` et`/boot/config-`. AWS IoT Device Tester utilise le premier chemin qu'il trouve. ## Configurer device.json pour la qualification ML Cette section décrit les propriétés facultatives du fichier de configuration d'appareil qui s'appliquent à la qualification ML. Si vous prévoyez d'exécuter des tests pour la qualification ML, vous devez définir les propriétés qui s'appliquent à votre cas d'utilisation. Vous pouvez utiliser le modèle `device-ml.json` pour définir les paramètres de configuration de votre appareil. Ce modèle contient les propriétés ML facultatives. Vous pouvez également utiliser `device.json` et ajouter les propriétés de qualification ML. Ces fichiers se trouvent dans `/configs` et incluent les propriétés de qualification ML. Si vous utilisez `device-ml.json`, vous devez renommer le fichier `device.json` avant d'exécuter des tests IDT. Pour de plus amples informations sur les propriétés de configuration d'appareil qui ne s'appliquent pas à la qualification ML, veuillez consulter [Configurer device.json](#device-config).   `ml` dans le tableau `features` Les frameworks ML que votre carte prend en charge. Cette propriété nécessite IDT v3.1.0 ou version ultérieure. + Si votre carte ne prend en charge qu'un seul framework, spécifiez le framework. Par exemple : ``` { "name": "ml", "value": "mxnet" } ``` + Si votre carte prend en charge plusieurs frameworks, spécifiez les frameworks sous la forme d'une liste séparée par des virgules. Par exemple : ``` { "name": "ml", "value": "mxnet,tensorflow" } ``` `mlLambdaContainerizationMode` dans le tableau `features` [Mode de conteneurisation](lambda-group-config.md#lambda-containerization-considerations) que vous souhaitez utiliser pour le test. Cette propriété nécessite IDT v3.1.0 ou version ultérieure. + Choisissez `process` d'exécuter le code d'inférence ML avec une fonction Lambda non conteneurisée. Cette option nécessite la AWS IoT Greengrass version v1.10.x ou ultérieure. + Choisissez `container` d'exécuter le code d'inférence ML avec une fonction Lambda conteneurisée. + Choisissez `both` pour exécuter le code d'inférence ML avec les deux modes. Cette option nécessite la AWS IoT Greengrass version v1.10.x ou ultérieure. `processor` dans le tableau `features` Indique l'accélérateur matériel pris en charge par votre carte. Cette propriété nécessite IDT v3.1.0 ou version ultérieure. + Choisissez `cpu` si votre carte utilise un processeur de type CPU. + Choisissez `gpu` si votre carte utilise un processeur de type GPU. `machineLearning` Facultatif. Informations de configuration pour les tests de qualification ML. Cette propriété nécessite IDT v3.1.0 ou version ultérieure. `dlrModelPath` Requis pour utiliser le framework `dlr`. Chemin absolu vers le répertoire de votre modèle compilé DLR, qui doit être nommé `resnet18`. Pour de plus amples informations, veuillez consulter [Compilation du modèle DLR](idt-ml-qualification.md#ml-qualification-dlr-compile-model). Voici un exemple de chemin d'accès sur macOS : `/Users//Downloads/resnet18`. `environmentVariables` Tableau de paires clé-valeur qui peuvent transmettre dynamiquement des paramètres aux tests d'inférence ML. Facultatif pour les appareils avec processeur de type CPU. Vous pouvez utiliser cette section pour ajouter des variables d'environnement spécifiques au framework requises par votre type d'appareil. Pour de plus amples informations sur ces exigences, veuillez consulter le site Web officiel du framework ou de l'appareil. Par exemple, pour exécuter des tests MXNet d'inférence sur certains appareils, les variables d'environnement suivantes peuvent être requises. ``` "environmentVariables": [ ... { "key": "PYTHONPATH", "value": "$MXNET_HOME/python:$PYTHONPATH" }, { "key": "MXNET_HOME", "value": "$HOME/mxnet/" }, ... ] ``` Le `value` champ peut varier en fonction de votre MXNet installation. Si vous testez des fonctions Lambda qui s'exécutent avec la [conteneurisation](lambda-group-config.md#lambda-containerization-considerations) sur des périphériques GPU, ajoutez des variables d'environnement pour la bibliothèque GPU. Cela permet au GPU d'effectuer des calculs. Pour utiliser des bibliothèques GPU différentes, veuillez consulter la documentation officielle de la bibliothèque ou de l'appareil. Configurez les clés suivantes si la fonction `mlLambdaContainerizationMode` est définie sur `container` ou `both`. ``` "environmentVariables": [ { "key": "PATH", "value": ":$PATH" }, { "key": "LD_LIBRARY_PATH", "value": "" }, ... ] ``` `deviceResources` Requis par les appareils GPU. Contient des [ressources locales](access-local-resources.md#lra-resource-types) accessibles par les fonctions Lambda. Utilisez cette section pour ajouter des ressources d'appareil et de volume locales. + Pour les ressources d'appareil, spécifiez `"type": "device"`. Pour les appareils GPU, les ressources d'appareil doivent être des fichiers d'appareil liés au GPU sous `/dev`. **Note** Le répertoire `/dev/shm` est une exception. Il peut être configuré en tant que ressource de volume uniquement. + Pour les ressources de volume, spécifiez `"type": "volume"`. # Exécutez la suite AWS IoT Greengrass de qualifications Après avoir [défini la configuration requise](set-config.md), vous pouvez démarrer les tests. L'exécution de l'ensemble de la suite de tests dépend de votre matériel. Pour référence, il faut environ 30 minutes pour terminer la suite de tests complète sur un Raspberry Pi 3B. Les exemples de commande `run-suite` suivants vous montrent comment exécuter les tests de qualification pour un groupe de périphériques. Un groupe de périphériques est un ensemble de périphériques identiques. ------ #### [ IDT v3.0.0 and later ] Exécutez tous les groupes de tests dans une suite de tests spécifiée. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --pool-id ``` Utilisez la commande `list-suites` pour répertorier les suites de tests qui se trouvent dans le dossier `tests`. Exécutez un groupe de tests spécifique dans une suite de tests. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --group-id --pool-id ``` Utilisez la commande `list-groups` pour répertorier les groupes de tests dans une suite de tests. Exécutez un cas de test spécifique dans un groupe de tests. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id ``` Exécutez plusieurs scénarios de test dans un groupe de tests. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id , ``` Répertoriez les scénarios de test dans un groupe de tests. ``` devicetester_[linux | mac | win_x86-64] list-test-cases --group-id ``` Les options de la commande `run-suite` sont facultatives. Par exemple, vous pouvez omettre `pool-id` si un seul groupe de périphériques est défini dans votre fichier `device.json`. Ou, vous pouvez omettre `suite-id` si vous souhaitez exécuter la dernière version de la suite de tests dans le dossier `tests`. **Note** IDT vous demande si une version de suite de tests plus récente est disponible en ligne. Pour de plus amples informations, veuillez consulter [Définir le comportement de mise à jour par défaut](#idt-update-behavior). Pour plus d'informations sur `run-suite` et d'autres commandes IDT, veuillez consulter [IDT pour les commandes AWS IoT Greengrass](#bk-cli). ------ #### [ IDT v2.3.0 and earlier ] Exécutez tous les groupes de tests dans une suite spécifiée. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --pool-id ``` Exécutez un groupe de tests spécifique. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --group-id --pool-id ``` `suite-id` et `pool-id` sont facultatifs si vous exécutez une suite de tests unique sur un groupe de périphériques unique. Cela signifie que vous n'avez qu'un seul groupe de périphériques défini dans votre fichier `device.json`. ------ ## Vérifiez les dépendances de Greengrass Nous vous recommandons d'exécuter le groupe de test du vérificateur de dépendance pour vous assurer que toutes les dépendances Greengrass sont installées avant d'exécuter des groupes de test associés. Par exemple : + Exécutez `ggcdependencies` avant les groupes de tests de qualification du noyau. + Exécutez `containerdependencies` avant les groupes de tests spécifiques au conteneur. + Exécutez `dockerdependencies` avant les groupes de tests spécifiques à Docker. + Exécutez `ggcstreammanagementdependencies` avant les groupes de tests spécifiques au gestionnaire de flux. ## Définir le comportement de mise à jour par défaut Lorsque vous démarrez un test, IDT recherche en ligne une version plus récente de la suite de tests. Si une version est disponible, IDT vous invite à utiliser la dernière version disponible. Vous pouvez définir l'indicateur `upgrade-test-suite` (ou `u`) pour contrôler le comportement de mise à jour par défaut. Les valeurs valides sont : + `y`. IDT télécharge et utilise la dernière version disponible. + `n` (default). IDT utilise la version spécifiée dans l'option `suite-id`. Si `suite-id` ce n'est pas spécifié, IDT utilise la dernière version du `tests` dossier. Si vous n'incluez pas l'indicateur `upgrade-test-suite`, IDT vous invite lorsqu'une mise à jour est disponible et attend votre réponse (`y` ou `n`) pendant 30 secondes. Si vous n’entrez pas de réponse, la valeur par défaut `n` est utilisée et l’exécution des tests se poursuit. Les exemples suivants illustrent les cas d'utilisation courants de cette fonctionnalité : **Utiliser automatiquement les derniers tests disponibles pour un groupe de tests.** ``` devicetester_linux run-suite -u y --group-id mqtt --pool-id DevicePool1 ``` **Exécuter des tests dans une version de suite de tests spécifique.** ``` devicetester_linux run-suite -u n --suite-id GGQ_1.0.0 --group-id mqtt --pool-id DevicePool1 ``` **Demander des mises à jour lors de l'exécution.** ``` devicetester_linux run-suite --pool-id DevicePool1 ``` ## IDT pour les commandes AWS IoT Greengrass Les commandes IDT se trouvent dans le répertoire `/bin`. Utilisez-les pour les opérations suivantes : ------ #### [ IDT v3.0.0 and later ] `help` Répertorie les informations sur la commande spécifiée. `list-groups` Répertorie les groupes dans une suite de tests donnée. `list-suites` Répertorie les suites de tests disponibles. `list-supported-products` Répertorie les produits pris en charge, dans ce cas AWS IoT Greengrass les versions, et les versions de la suite de tests pour la version IDT actuelle. `list-test-cases` Répertorie les cas de tests d'un groupe de tests donné. L'option suivante est prise en charge : + `group-id`. Le groupe de test à rechercher. Cette option est obligatoire et doit spécifier un groupe unique. `run-suite` Exécute une suite de tests sur un groupe d'appareils. Voici quelques options prises en charge : + `suite-id`. Version de la suite de tests à exécuter. Si celle-ci n’est pas spécifiée, IDT utilise la dernière version dans le dossier `tests`. + `group-id`. Les groupes de test à exécuter, sous forme de liste séparée par des virgules. Si cette option n'est pas spécifiée, IDT exécute tous les groupes de tests de la suite de tests. + `test-id`. Les cas de test à exécuter, sous forme de liste séparée par des virgules. Lorsqu'il est spécifié, `group-id` doit spécifier un seul groupe. + `pool-id`. Le pool d'appareils à tester. Vous devez spécifier un groupe si plusieurs groupes de périphériques sont définis dans votre fichier `device.json`. + `upgrade-test-suite`. Contrôle la manière dont les mises à jour des versions de la suite de tests sont gérées. À partir de IDT v3.0.0, IDT vérifie en ligne les versions mises à jour de la suite de tests. Pour de plus amples informations, veuillez consulter [Versions de la suite de tests](idt-gg-qualification.md#idt-test-suite-versions). + `stop-on-first-failure`. Configure IDT pour arrêter l'exécution lors du premier échec. Cette option doit être utilisée avec `group-id` pour déboguer les groupes de tests spécifiés. N'utilisez pas cette option lors de l'exécution d'une suite de tests complète pour générer un rapport de qualification. + `update-idt`. Définit la réponse à l'invite de mise à jour de l'IDT. `Y`car input arrête l'exécution du test si IDT détecte qu'il existe une version plus récente. `N`au fur et à mesure que l'entrée poursuit l'exécution du test. + `update-managed-policy`. Entrer `Y` permet d'arrêter l'exécution du test si IDT détecte que la stratégie gérée de l'utilisateur n'est pas mise à jour. Entrer `N` permet de poursuivre l'exécution du test. Pour de plus amples informations sur les options `run-suite`, utilisez l' option `help` suivante : ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` ------ #### [ IDT v2.3.0 and earlier ] `help` Répertorie les informations sur la commande spécifiée. `list-groups` Répertorie les groupes dans une suite de tests donnée. `list-suites` Répertorie les suites de tests disponibles. `run-suite` Exécute une suite de tests sur un groupe d'appareils. Pour de plus amples informations sur les options `run-suite`, utilisez l' option `help` suivante : ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` ------ # Présentation des résultats et des journaux Cette section explique comment afficher et interpréter les journaux et les rapports de résultats IDT. ## Affichage des résultats Lorsqu'il s'exécute, IDT écrit les erreurs sur la console, les fichiers journaux et les rapports de tests. Une fois que l'outil a terminé la suite de tests, il génère deux rapports de tests. Ces rapports se trouvent à l'emplacement `/results//`. Les deux rapports capturent les résultats de l'exécution de la suite de tests de qualification. `awsiotdevicetester_report.xml`Il s'agit du rapport de test de qualification que vous soumettez AWS pour répertorier votre appareil dans le catalogue des AWS Partner appareils. Ce rapport contient les éléments suivants : + La version IDT. + AWS IoT Greengrass Version qui a été testée. + La référence et le nom du groupe d'appareils spécifié dans le fichier `device.json`. + Les caractéristiques du groupe d'appareils spécifié dans le fichier `device.json`. + Le récapitulatif des résultats des tests. + La répartition des résultats des tests pour les bibliothèques qui ont été testées en fonction des caractéristiques de l'appareil (par exemple, l'accès aux ressources locales, shadow, MQTT, etc). Le `GGQ_Result.xml` rapport est au [format JUnit XML](https://llg.cubic.org/docs/junit/). Vous pouvez intégrer des plateformes de déploiement/d'intégration continues tels que [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo), etc. Ce rapport contient les éléments suivants : + Un récapitulatif des résultats des tests. + Répartition des résultats des tests en AWS IoT Greengrass fonction de la fonctionnalité testée. ## Interprétation des rapports IDT La section de rapport dans les fichiers `awsiotdevicetester_report.xml` ou `awsiotdevicetester_report.xml` répertorie les tests qui ont été exécutés ainsi que leurs résultats. La première balise XML `` contient le résumé de l'exécution des tests. Par exemple : ``` ```Attributs utilisés dans la balise `` `name` Nom de la suite de tests. `time` Durée, en secondes, nécessaire pour exécuter la suite de qualification. `tests` Nombre de tests exécutés. `failures` Nombre de tests exécutés mais dont le résultat n'est pas probant. `errors` Nombre de tests qu'IDT n'a pas pu exécuter. `disabled` Cet attribut n'est pas utilisé et peut être ignoré. Le fichier `awsiotdevicetester_report.xml` contient une balise `` qui contient des informations relatives au produit testé et les caractéristiques du produit qui ont été validées par une suite de tests.Attributs utilisés dans la balise `` `name` Nom du produit testé. `version` Version du produit testé. `features` Caractéristiques validées. Les caractéristiques portant la mention `required` sont requises pour pouvoir envoyer votre carte en vue de sa certification. L'extrait de code suivant montre comment ces informations apparaissent dans le fichier `awsiotdevicetester_report.xml`. ``` ``` Les fonctionnalités marquées comme `optional` ne sont pas requises pour l'éligibilité. Les extraits suivants illustrent des fonctions facultatives. ``` 
 ``` En l'absence d'échec des tests ou d'erreurs pour les fonctionnalités requises, votre appareil répond aux exigences techniques requises pour fonctionner AWS IoT Greengrass et peut interagir avec les AWS IoT services. Si vous souhaitez répertorier votre appareil dans le catalogue des AWS Partner appareils, vous pouvez utiliser ce rapport comme preuve de qualification. En cas d'erreurs ou d'échecs de tests, vous pouvez identifier les tests concernés à l'aide des balises XML ``. Les balises XML `` au sein de la balise `` montrent le récapitulatif des résultats d'un groupe de tests. Par exemple : ``` ``` Le format est similaire à la balise ``, mais avec un attribut appelé `skipped` qui n'est pas utilisé et qui ne peut pas être ignoré. Chaque balise XML `` inclut des balises `` pour chaque test exécuté pour un groupe de tests. Par exemple : ``` > ```Attributs utilisés dans la balise `` `name` Nom du test. `attempts` Nombre de fois où IDT a exécuté le test. Lorsqu'un test échoue ou qu'une erreur se produit, les balises `` ou `` sont ajoutées à la balise `` avec des informations relatives au dépannage. Par exemple : ``` Reason for the test failure Reason for the test execution error ``` ## Affichage des journaux IDT génère des journaux à partir de l'exécution du test dans `/results//logs`. Deux ensembles de journaux sont générés : `test_manager.log` Journaux générés à partir du composant Test Manager de AWS IoT Device Tester (par exemple, journaux relatifs à la configuration, au séquençage des tests et à la génération de rapports). `.log (for example, ota.log)` Journaux du groupe de tests, y compris les journaux liés à l'appareil qui est testé. Lorsqu'un test échoue, un fichier tar.gz qui contient les journaux de l'appareil testé pour le test correspondant est créé (par exemple, `ota_prod_test_1_ggc_logs.tar.gz`). Pour de plus amples informations, veuillez consulter [IDT pour le dépannage AWS IoT Greengrass](idt-troubleshooting.md). # Utilisez IDT pour développer et exécuter vos propres suites de tests À partir de IDT v4.0.0, IDT for AWS IoT Greengrass combine une configuration standardisée et un format de résultat avec un environnement de suites de tests qui vous permet de développer des suites de tests personnalisées pour vos appareils et leurs logiciels. Vous pouvez ajouter des tests personnalisés pour votre propre validation interne ou les fournir à vos clients pour la vérification des appareils. Utilisez IDT pour développer et exécuter des suites de tests personnalisées, comme suit : **Pour développer des suites de tests personnalisées** + Créez des suites de tests avec une logique de test personnalisée pour l'appareil Greengrass que vous souhaitez tester. + Fournissez à IDT vos suites de tests personnalisées aux testeurs. Incluez des informations sur les configurations de paramètres spécifiques de vos suites de tests. **Pour exécuter des suites de tests personnalisées** + Configurez l'appareil que vous souhaitez tester. + Implémentez les configurations de paramètres requises par les suites de tests que vous souhaitez utiliser. + Utilisez IDT pour exécuter vos suites de tests personnalisées. + Consultez les résultats des tests et les journaux d'exécution des tests exécutés par IDT. ## Téléchargez la dernière version de AWS IoT Device Tester pour AWS IoT Greengrass Téléchargez la [dernière version](dev-test-versions.md) d'IDT et extrayez le logiciel dans un emplacement de votre système de fichiers où vous disposez d'autorisations de lecture et d'écriture. **Note** IDT ne prend pas en charge son exécution par plusieurs utilisateurs à partir d'un emplacement partagé, tel qu'un répertoire NFS ou un dossier partagé réseau Windows. Nous vous recommandons d'extraire le package IDT sur une unité locale et d'exécuter le fichier binaire IDT sur votre station de travail locale. Pour Windows, la limitation de la longueur du chemin est de 260 caractères. Si vous utilisez Windows, décompressez IDT dans un répertoire racine comme `C:\ ` ou `D:\` afin que la longueur de vos chemins respecte la limite de 260 caractères. ## Flux de travail de création de suites de tests Les suites de tests sont composées de trois types de fichiers : + Fichiers de configuration JSON qui fournissent à IDT des informations sur la façon d'exécuter la suite de tests. + Testez les fichiers exécutables utilisés par IDT pour exécuter des scénarios de test. + Des fichiers supplémentaires sont nécessaires pour exécuter les tests. Suivez les étapes de base suivantes pour créer des tests IDT personnalisés : 1. [Créez des fichiers de configuration JSON](idt-json-config.md) pour votre suite de tests. 1. [Créez des exécutables de cas de test](test-executables.md) contenant la logique de test de votre suite de tests. 1. Vérifiez et documentez les [informations de configuration requises pour que les testeurs](set-config-custom.md) exécutent la suite de tests. 1. Vérifiez qu'IDT peut exécuter votre suite de tests et produire les [résultats des tests](run-tests-custom.md) comme prévu. Pour créer rapidement un exemple de suite personnalisée et l'exécuter, suivez les instructions figurant dans[Tutoriel : création et exécution de l'exemple de suite de tests IDT](build-sample-suite.md). Pour commencer à créer une suite de tests personnalisée en Python, consultez[Tutoriel : Développement d'une suite de tests IDT simple](create-custom-tests.md). # Tutoriel : création et exécution de l'exemple de suite de tests IDT Le téléchargement de AWS IoT Device Tester inclut le code source d'un exemple de suite de tests. Vous pouvez suivre ce didacticiel pour créer et exécuter l'exemple de suite de tests afin de comprendre comment utiliser AWS IoT Device Tester AWS IoT Greengrass pour exécuter des suites de tests personnalisées. Dans ce didacticiel, vous allez effectuer les étapes suivantes : 1. [Créez la suite d'exemples de tests](#build-sample) 1. [Utiliser IDT pour exécuter l'exemple de suite de tests](#run-sample) ## Conditions préalables Pour suivre ce didacticiel, vous aurez besoin des éléments suivants : + **Exigences relatives à l'ordinateur hôte** + Dernière version de AWS IoT Device Tester + [Python](https://www.python.org/downloads/) 3.7 ou version ultérieure Pour vérifier la version de Python installée sur votre ordinateur, exécutez la commande suivante : ``` python3 --version ``` Sous Windows, si l'utilisation de cette commande renvoie une erreur, utilisez-la à la `python --version` place. Si le numéro de version renvoyé est 3.7 ou supérieur, exécutez la commande suivante dans un terminal Powershell pour la définir `python3` comme alias pour votre `python` commande. ``` Set-Alias -Name "python3" -Value "python" ``` Si aucune information de version n'est renvoyée ou si le numéro de version est inférieur à 3.7, suivez les instructions de la section [Télécharger Python](https://wiki.python.org/moin/BeginnersGuide/Download) pour installer Python 3.7\$1. Pour plus d'informations, consultez la [documentation Python](https://docs.python.org). + [urllib3](https://urllib3.readthedocs.io/en/latest/) Pour vérifier qu'`urllib3`il est correctement installé, exécutez la commande suivante : ``` python3 -c 'import urllib3' ``` S'il n'`urllib3`est pas installé, exécutez la commande suivante pour l'installer : ``` python3 -m pip install urllib3 ``` + **Exigences relatives aux dispositifs** + Appareil doté d'un système d'exploitation Linux et d'une connexion réseau au même réseau que votre ordinateur hôte. Nous vous recommandons d'utiliser un [Raspberry Pi](https://www.raspberrypi.org/) avec le système d'exploitation Raspberry Pi. Assurez-vous de configurer [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) sur votre Raspberry Pi pour vous y connecter à distance. ## Configurer les informations de l'appareil pour IDT Configurez les informations de votre appareil pour qu'IDT exécute le test. Vous devez mettre à jour le `device.json` modèle situé dans le `/configs` dossier avec les informations suivantes. ``` [ { "id": "pool", "sku": "N/A", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": "", "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` Dans l'`devices`objet, fournissez les informations suivantes : `id` Identifiant unique défini par l'utilisateur pour votre appareil. `connectivity.ip` L'adresse IP de votre appareil. `connectivity.port` Facultatif. Le numéro de port à utiliser pour les connexions SSH à votre appareil. `connectivity.auth` Informations d'authentification pour la connexion. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.auth.method` Méthode d'authentification utilisée pour accéder à un appareil sur le protocole de connectivité donné. Les valeurs prises en charge sont : + `pki` + `password` `connectivity.auth.credentials` Informations d'identification utilisées pour l'authentification. `connectivity.auth.credentials.user` Le nom d'utilisateur utilisé pour vous connecter à votre appareil. `connectivity.auth.credentials.privKeyPath` Le chemin complet vers la clé privée utilisée pour vous connecter à votre appareil. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `pki`. `devices.connectivity.auth.credentials.password` Le mot de passe utilisé pour vous connecter à votre appareil. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `password`. **Note** Spécifiez `privKeyPath` uniquement si `method` est défini sur `pki`. Spécifiez `password` uniquement si `method` est défini sur `password`. ## Créez la suite d'exemples de tests Le `/samples/python` dossier contient des exemples de fichiers de configuration, du code source et le SDK du client IDT que vous pouvez combiner dans une suite de tests à l'aide des scripts de génération fournis. L'arborescence de répertoires suivante indique l'emplacement de ces exemples de fichiers : ``` ├── ... ├── tests ├── samples │ ├── ... │ └── python │ ├── configuration │ ├── src │ └── build-scripts │ ├── build.sh │ └── build.ps1 └── sdks ├── ... └── python └── idt_client ``` Pour créer la suite de tests, exécutez les commandes suivantes sur votre ordinateur hôte : ------ #### [ Windows ] ``` cd /samples/python/build-scripts ./build.ps1 ``` ------ #### [ Linux, macOS, or UNIX ] ``` cd /samples/python/build-scripts ./build.sh ``` ------ Cela crée l'exemple de suite de tests dans le `IDTSampleSuitePython_1.0.0` dossier situé à l'intérieur du `/tests` dossier. Passez en revue les fichiers du `IDTSampleSuitePython_1.0.0` dossier pour comprendre comment l'exemple de suite de tests est structuré et découvrez divers exemples d'exécutables de scénarios de test et de fichiers JSON de configuration de test. Étape suivante : utilisez IDT pour [exécuter l'exemple de suite de tests](#run-sample) que vous avez créée. ## Utiliser IDT pour exécuter l'exemple de suite de tests Pour exécuter l'exemple de suite de tests, exécutez les commandes suivantes sur votre ordinateur hôte : ``` cd /bin ./devicetester_[linux | mac | win_x86-64] run-suite --suite-id IDTSampleSuitePython ``` IDT exécute la suite d'exemples de tests et diffuse les résultats sur la console. Lorsque le test est terminé, les informations suivantes s'affichent : ``` ========== Test Summary ========== Execution Time: 5s Tests Completed: 4 Tests Passed: 4 Tests Failed: 0 Tests Skipped: 0 ---------------------------------- Test Groups: sample_group: PASSED ---------------------------------- Path to IoT Device Tester Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/awsiotdevicetester_report.xml Path to Test Execution Logs: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/logs Path to Aggregated JUnit Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/IDTSampleSuitePython_Report.xml ``` ## Résolution des problèmes Utilisez les informations suivantes pour résoudre les problèmes rencontrés lors de l'exécution du didacticiel. **Le scénario de test ne s'exécute pas correctement** Si le test échoue, IDT diffuse les journaux d'erreurs sur la console afin de vous aider à résoudre les problèmes liés à l'exécution du test. Assurez-vous de remplir toutes les [conditions requises](#prereqs-tutorial-sample) pour ce didacticiel. **Impossible de se connecter à l'appareil testé** Vérifiez les paramètres suivants : + Votre `device.json` fichier contient l'adresse IP, le port et les informations d'authentification corrects. + Vous pouvez vous connecter à votre appareil via SSH depuis votre ordinateur hôte. # Tutoriel : Développement d'une suite de tests IDT simple Une suite de tests combine les éléments suivants : + Exécutables de test contenant la logique de test + fichiers de configuration JSON décrivant la suite de tests Ce didacticiel vous montre comment utiliser IDT AWS IoT Greengrass pour développer une suite de tests Python contenant un seul cas de test. Dans ce didacticiel, vous allez effectuer les étapes suivantes : 1. [Création d'un répertoire de suites de tests](#test-suite-dir) 1. [Création de fichiers de configuration JSON](#test-suite-json) 1. [Création de l'exécutable du scénario de test](#test-suite-exe) 1. [Exécutez la suite de tests](#run-test-suite) ## Conditions préalables Pour suivre ce didacticiel, vous aurez besoin des éléments suivants : + **Exigences relatives à l'ordinateur hôte** + Dernière version de AWS IoT Device Tester + [Python](https://www.python.org/downloads/) 3.7 ou version ultérieure Pour vérifier la version de Python installée sur votre ordinateur, exécutez la commande suivante : ``` python3 --version ``` Sous Windows, si l'utilisation de cette commande renvoie une erreur, utilisez-la à la `python --version` place. Si le numéro de version renvoyé est 3.7 ou supérieur, exécutez la commande suivante dans un terminal Powershell pour la définir `python3` comme alias pour votre `python` commande. ``` Set-Alias -Name "python3" -Value "python" ``` Si aucune information de version n'est renvoyée ou si le numéro de version est inférieur à 3.7, suivez les instructions de la section [Télécharger Python](https://wiki.python.org/moin/BeginnersGuide/Download) pour installer Python 3.7\$1. Pour plus d'informations, consultez la [documentation Python](https://docs.python.org). + [urllib3](https://urllib3.readthedocs.io/en/latest/) Pour vérifier qu'`urllib3`il est correctement installé, exécutez la commande suivante : ``` python3 -c 'import urllib3' ``` S'il n'`urllib3`est pas installé, exécutez la commande suivante pour l'installer : ``` python3 -m pip install urllib3 ``` + **Exigences relatives aux dispositifs** + Un appareil doté d'un système d'exploitation Linux et d'une connexion réseau au même réseau que votre ordinateur hôte. Nous vous recommandons d'utiliser un [Raspberry Pi](https://www.raspberrypi.org/) avec le système d'exploitation Raspberry Pi. Assurez-vous de configurer [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) sur votre Raspberry Pi pour vous y connecter à distance. ## Création d'un répertoire de suites de tests IDT sépare logiquement les cas de test en groupes de tests au sein de chaque suite de tests. Chaque cas de test doit faire partie d'un groupe de test. Pour ce didacticiel, créez un dossier appelé `MyTestSuite_1.0.0` et créez l'arborescence de répertoires suivante dans ce dossier : ``` MyTestSuite_1.0.0 └── suite └── myTestGroup └── myTestCase ``` ## Création de fichiers de configuration JSON Votre suite de tests doit contenir les [fichiers de configuration JSON](idt-json-config.md) requis suivants :Fichiers JSON requis `suite.json` Contient des informations sur la suite de tests. Consultez [Configurer suite.json](idt-json-config.md#suite-json). `group.json` Contient des informations sur un groupe de test. Vous devez créer un `group.json` fichier pour chaque groupe de test de votre suite de tests. Consultez [Configurer group.json](idt-json-config.md#group-json). `test.json` Contient des informations sur un scénario de test. Vous devez créer un `test.json` fichier pour chaque scénario de test de votre suite de tests. Consultez [Configurer test.json](idt-json-config.md#test-json). 1. Dans le `MyTestSuite_1.0.0/suite` dossier, créez un `suite.json` fichier avec la structure suivante : ``` { "id": "MyTestSuite_1.0.0", "title": "My Test Suite", "details": "This is my test suite.", "userDataRequired": false } ``` 1. Dans le `MyTestSuite_1.0.0/myTestGroup` dossier, créez un `group.json` fichier avec la structure suivante : ``` { "id": "MyTestGroup", "title": "My Test Group", "details": "This is my test group.", "optional": false } ``` 1. Dans le `MyTestSuite_1.0.0/myTestGroup/myTestCase` dossier, créez un `test.json` fichier avec la structure suivante : ``` { "id": "MyTestCase", "title": "My Test Case", "details": "This is my test case.", "execution": { "timeout": 300000, "linux": { "cmd": "python3", "args": [ "myTestCase.py" ] }, "mac": { "cmd": "python3", "args": [ "myTestCase.py" ] }, "win": { "cmd": "python3", "args": [ "myTestCase.py" ] } } } ``` L'arborescence de votre `MyTestSuite_1.0.0` dossier doit désormais ressembler à ce qui suit : ``` MyTestSuite_1.0.0 └── suite ├── suite.json └── myTestGroup ├── group.json └── myTestCase └── test.json ``` ## Obtenez le SDK du client IDT Vous utilisez le [SDK du client IDT](test-executables.md#idt-client-sdk) pour permettre à IDT d'interagir avec l'appareil testé et de communiquer les résultats des tests. Pour ce didacticiel, vous allez utiliser la version Python du SDK. Depuis le `/sdks/python/` dossier, `idt_client` copiez-le dans votre `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` dossier. Pour vérifier que le SDK a bien été copié, exécutez la commande suivante. ``` cd MyTestSuite_1.0.0/suite/myTestGroup/myTestCase python3 -c 'import idt_client' ``` ## Création de l'exécutable du scénario de test Les exécutables du scénario de test contiennent la logique de test que vous souhaitez exécuter. Une suite de tests peut contenir plusieurs exécutables de scénarios de test. Pour ce didacticiel, vous ne créerez qu'un seul exécutable de scénario de test. 1. Créez le fichier de suite de tests. Dans le `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` dossier, créez un `myTestCase.py` fichier avec le contenu suivant : ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() if __name__ == "__main__": main() ``` 1. Utilisez les fonctions du SDK client pour ajouter la logique de test suivante à votre `myTestCase.py` fichier : 1. Exécutez une commande SSH sur le périphérique testé. ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() # Create an execute on device request exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'")) # Run the command exec_resp = client.execute_on_device(exec_req) # Print the standard output print(exec_resp.stdout) if __name__ == "__main__": main() ``` 1. Envoyez le résultat du test à IDT. ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() # Create an execute on device request exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'")) # Run the command exec_resp = client.execute_on_device(exec_req) # Print the standard output print(exec_resp.stdout) # Create a send result request sr_req = SendResultRequest(TestResult(passed=True)) # Send the result client.send_result(sr_req) if __name__ == "__main__": main() ``` ## Configurer les informations de l'appareil pour IDT Configurez les informations de votre appareil pour qu'IDT exécute le test. Vous devez mettre à jour le `device.json` modèle situé dans le `/configs` dossier avec les informations suivantes. ``` [ { "id": "pool", "sku": "N/A", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": "", "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` Dans l'`devices`objet, fournissez les informations suivantes : `id` Identifiant unique défini par l'utilisateur pour votre appareil. `connectivity.ip` L'adresse IP de votre appareil. `connectivity.port` Facultatif. Le numéro de port à utiliser pour les connexions SSH à votre appareil. `connectivity.auth` Informations d'authentification pour la connexion. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.auth.method` Méthode d'authentification utilisée pour accéder à un appareil sur le protocole de connectivité donné. Les valeurs prises en charge sont : + `pki` + `password` `connectivity.auth.credentials` Informations d'identification utilisées pour l'authentification. `connectivity.auth.credentials.user` Le nom d'utilisateur utilisé pour vous connecter à votre appareil. `connectivity.auth.credentials.privKeyPath` Le chemin complet vers la clé privée utilisée pour vous connecter à votre appareil. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `pki`. `devices.connectivity.auth.credentials.password` Le mot de passe utilisé pour vous connecter à votre appareil. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `password`. **Note** Spécifiez `privKeyPath` uniquement si `method` est défini sur `pki`. Spécifiez `password` uniquement si `method` est défini sur `password`. ## Exécutez la suite de tests Après avoir créé votre suite de tests, vous devez vous assurer qu'elle fonctionne comme prévu. Pour ce faire, procédez comme suit pour exécuter la suite de tests avec votre pool d'appareils existant. 1. Copiez votre `MyTestSuite_1.0.0` dossier dans`/tests`. 1. Exécutez les commandes suivantes : ``` cd /bin ./devicetester_[linux | mac | win_x86-64] run-suite --suite-id MyTestSuite ``` IDT exécute votre suite de tests et diffuse les résultats sur la console. Lorsque le test est terminé, les informations suivantes s'affichent : ``` time="2020-10-19T09:24:47-07:00" level=info msg=Using pool: pool time="2020-10-19T09:24:47-07:00" level=info msg=Using test suite "MyTestSuite_1.0.0" for execution time="2020-10-19T09:24:47-07:00" level=info msg=b'hello world\n' suiteId=MyTestSuite groupId=myTestGroup testCaseId=myTestCase deviceId=my-device executionId=9a52f362-1227-11eb-86c9-8c8590419f30 time="2020-10-19T09:24:47-07:00" level=info msg=All tests finished. executionId=9a52f362-1227-11eb-86c9-8c8590419f30 time="2020-10-19T09:24:48-07:00" level=info msg= ========== Test Summary ========== Execution Time: 1s Tests Completed: 1 Tests Passed: 1 Tests Failed: 0 Tests Skipped: 0 ---------------------------------- Test Groups: myTestGroup: PASSED ---------------------------------- Path to IoT Device Tester Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/awsiotdevicetester_report.xml Path to Test Execution Logs: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/logs Path to Aggregated JUnit Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/MyTestSuite_Report.xml ``` ## Résolution des problèmes Utilisez les informations suivantes pour résoudre les problèmes rencontrés lors de l'exécution du didacticiel. **Le scénario de test ne s'exécute pas correctement** Si le test échoue, IDT diffuse les journaux d'erreurs sur la console afin de vous aider à résoudre les problèmes liés à l'exécution du test. Avant de consulter les journaux d'erreurs, vérifiez les points suivants : + Le SDK du client IDT se trouve dans le bon dossier, comme décrit dans [cette](#add-idt-sdk) étape. + Vous répondez à tous les [prérequis](#prereqs-tutorial-custom) pour ce didacticiel. **Impossible de se connecter à l'appareil testé** Vérifiez les paramètres suivants : + Votre `device.json` fichier contient l'adresse IP, le port et les informations d'authentification corrects. + Vous pouvez vous connecter à votre appareil via SSH depuis votre ordinateur hôte. # Création de fichiers de configuration de la suite de tests IDT Cette section décrit les formats dans lesquels vous créez des fichiers de configuration JSON que vous incluez lorsque vous écrivez une suite de tests personnalisée.Fichiers JSON requis `suite.json` Contient des informations sur la suite de tests. Consultez [Configurer suite.json](#suite-json). `group.json` Contient des informations sur un groupe de test. Vous devez créer un `group.json` fichier pour chaque groupe de test de votre suite de tests. Consultez [Configurer group.json](#group-json). `test.json` Contient des informations sur un scénario de test. Vous devez créer un `test.json` fichier pour chaque scénario de test de votre suite de tests. Consultez [Configurer test.json](#test-json).Fichiers JSON facultatifs `state_machine.json` Définit le mode d'exécution des tests lorsque IDT exécute la suite de tests. Consultez [Configurer state\$1machine.json](#state-machine-json). `userdata_schema.json` Définit le schéma du [`userdata.json`fichier](set-config-custom.md#userdata-config-custom) que les testeurs peuvent inclure dans leur configuration de configuration. Le `userdata.json` fichier est utilisé pour toute information de configuration supplémentaire requise pour exécuter le test mais absente du `device.json` fichier. Consultez [Configurer userdata\$1schema.json](#userdata-schema-json). Les fichiers de configuration JSON sont placés dans votre `` répertoire, comme indiqué ici. ``` └── suite ├── suite.json ├── state_machine.json ├── userdata_schema.json ├── ├── group.json ├── └── test.json ``` ## Configurer suite.json Le `suite.json` fichier définit les variables d'environnement et détermine si les données utilisateur sont nécessaires pour exécuter la suite de tests. Utilisez le modèle suivant pour configurer votre `/suite/suite.json` fichier : ``` { "id": "_", "title": "", "details": "", "userDataRequired": true | false, "environmentVariables": [ { "key": "", "value": "", }, ... { "key": "", "value": "", } ] } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `id` Un identifiant unique défini par l'utilisateur pour la suite de tests. La valeur de `id` doit correspondre au nom du dossier de la suite de tests dans lequel se trouve le `suite.json` fichier. Le nom et la version de la suite doivent également répondre aux exigences suivantes : + ``ne peut pas contenir de traits de soulignement. + ``est noté`x.x.x`, où `x` est un nombre. L'ID est indiqué dans les rapports de test générés par IDT. `title` Nom défini par l'utilisateur pour le produit ou la fonctionnalité testé par cette suite de tests. Le nom est affiché dans la CLI IDT pour les testeurs. `details` Brève description de l'objectif de la suite de tests. `userDataRequired` Définit si les testeurs doivent inclure des informations personnalisées dans un `userdata.json` fichier. Si vous définissez cette valeur sur`true`, vous devez également inclure le [`userdata_schema.json`fichier](#userdata-schema-json) dans le dossier de votre suite de tests. `environmentVariables` Facultatif. Un tableau de variables d'environnement à définir pour cette suite de tests. `environmentVariables.key` Le nom de la variable d'environnement. `environmentVariables.value` Valeur de la variable d'environnement. ## Configurer group.json Le `group.json` fichier définit si un groupe de test est obligatoire ou facultatif. Utilisez le modèle suivant pour configurer votre `/suite//group.json` fichier : ``` { "id": "", "title": "", "details": "", "optional": true | false, } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `id` Un identifiant unique défini par l'utilisateur pour le groupe de test. La valeur de `id` doit correspondre au nom du dossier du groupe de test dans lequel se trouve le `group.json` fichier et ne doit pas contenir de traits de soulignement (`_`). L'ID est utilisé dans les rapports de test générés par IDT. `title` Nom descriptif du groupe de test. Le nom est affiché dans la CLI IDT pour les testeurs. `details` Brève description de l'objectif du groupe de test. `optional` Facultatif. Définissez sur `true` pour afficher ce groupe de test en tant que groupe facultatif une fois qu'IDT a terminé d'exécuter les tests requis. La valeur par défaut est `false`. ## Configurer test.json Le `test.json` fichier détermine les exécutables du scénario de test et les variables d'environnement utilisées par un scénario de test. Pour plus d'informations sur la création d'exécutables de scénarios de test, consultez. [Création d'exécutables de scénarios de test IDT](test-executables.md) Utilisez le modèle suivant pour configurer votre `/suite///test.json` fichier : ``` { "id": "", "title": "", "details": "", "requireDUT": true | false, "requiredResources": [ { "name": "", "features": [ { "name": "", "version": "", "jobSlots": } ] } ], "execution": { "timeout": , "mac": { "cmd": "/path/to/executable", "args": [ "" ], }, "linux": { "cmd": "/path/to/executable", "args": [ "" ], }, "win": { "cmd": "/path/to/executable", "args": [ "" ] } }, "environmentVariables": [ { "key": "", "value": "", } ] } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `id` Un identifiant unique défini par l'utilisateur pour le scénario de test. La valeur de `id` doit correspondre au nom du dossier de scénario de test dans lequel se trouve le `test.json` fichier et ne doit pas contenir de traits de soulignement (`_`). L'ID est utilisé dans les rapports de test générés par IDT. `title` Nom descriptif du scénario de test. Le nom est affiché dans la CLI IDT pour les testeurs. `details` Brève description de l'objectif du scénario de test. `requireDUT` Facultatif. Réglez sur `true` si un appareil est requis pour exécuter ce test, sinon sur`false`. La valeur par défaut est `true`. Les testeurs configureront les appareils qu'ils utiliseront pour exécuter le test dans leur `device.json` fichier. `requiredResources` Facultatif. Un tableau qui fournit des informations sur les périphériques de ressources nécessaires pour exécuter ce test. `requiredResources.name` Le nom unique à attribuer au périphérique de ressource lors de l'exécution de ce test. `requiredResources.features` Un ensemble de fonctionnalités de périphérique de ressources définies par l'utilisateur. `requiredResources.features.name` Nom de la fonctionnalité. Fonctionnalité de l'appareil pour laquelle vous souhaitez utiliser cet appareil. Ce nom est comparé au nom de la fonctionnalité fourni par le testeur dans le `resource.json` fichier. `requiredResources.features.version` Facultatif. Version de la fonctionnalité. Cette valeur est comparée à la version de fonctionnalité fournie par le testeur dans le `resource.json` fichier. Si aucune version n'est fournie, la fonctionnalité n'est pas cochée. Si aucun numéro de version n'est requis pour la fonctionnalité, laissez ce champ vide. `requiredResources.features.jobSlots` Facultatif. Le nombre de tests simultanés que cette fonctionnalité peut prendre en charge. La valeur par défaut est `1`. Si vous souhaitez qu'IDT utilise des appareils distincts pour des fonctionnalités individuelles, nous vous recommandons de définir cette valeur sur`1`. `execution.timeout` Durée (en millisecondes) pendant laquelle IDT attend la fin du test. Pour plus d'informations sur la définition de cette valeur, consultez[Création d'exécutables de scénarios de test IDT](test-executables.md). `execution.os` Les exécutables du scénario de test à exécuter sont basés sur le système d'exploitation de l'ordinateur hôte qui exécute IDT. Les valeurs prises en charge sont `linux`, `mac` et `win`. `execution.os.cmd` Le chemin d'accès au fichier exécutable du scénario de test que vous souhaitez exécuter pour le système d'exploitation spécifié. Cet emplacement doit se trouver dans le chemin du système. `execution.os.args` Facultatif. Les arguments à fournir pour exécuter l'exécutable du scénario de test. `environmentVariables` Facultatif. Un tableau de variables d'environnement défini pour ce cas de test. `environmentVariables.key` Le nom de la variable d'environnement. `environmentVariables.value` Valeur de la variable d'environnement. Si vous spécifiez la même variable d'environnement dans le `test.json` fichier et dans le `suite.json` fichier, la valeur du `test.json` fichier est prioritaire. ## Configurer state\$1machine.json Une machine à états est une construction qui contrôle le flux d'exécution de la suite de tests. Il détermine l'état de départ d'une suite de tests, gère les transitions d'état en fonction de règles définies par l'utilisateur et continue de passer par ces états jusqu'à ce qu'il atteigne l'état final. Si votre suite de tests n'inclut pas de machine à états définie par l'utilisateur, IDT générera une machine à états pour vous. La machine à états par défaut exécute les fonctions suivantes : + Permet aux testeurs de sélectionner et d'exécuter des groupes de tests spécifiques, au lieu de recourir à la suite de tests complète. + Si aucun groupe de test spécifique n'est sélectionné, exécute chaque groupe de test de la suite de tests dans un ordre aléatoire. + Génère des rapports et imprime un résumé de console présentant les résultats des tests pour chaque groupe de test et chaque cas de test. Pour plus d'informations sur le fonctionnement de la machine à états IDT, consultez[Configuration de la machine d'état IDT](idt-state-machine.md). ## Configurer userdata\$1schema.json Le `userdata_schema.json` fichier détermine le schéma dans lequel les testeurs fournissent les données utilisateur. Les données utilisateur sont requises si votre suite de tests nécessite des informations qui ne figurent pas dans le `device.json` fichier. Par exemple, vos tests peuvent nécessiter des informations d'identification du réseau Wi-Fi, des ports ouverts spécifiques ou des certificats qu'un utilisateur doit fournir. Ces informations peuvent être fournies à IDT sous la forme d'un paramètre d'entrée appelé`userdata`, dont la valeur est un `userdata.json` fichier, que les utilisateurs créent dans leur `/config` dossier. Le format du `userdata.json` fichier est basé sur le `userdata_schema.json` fichier que vous incluez dans la suite de tests. Pour indiquer que les testeurs doivent fournir un `userdata.json` fichier : 1. Dans le `suite.json` fichier, définissez `userDataRequired` sur`true`. 1. Dans votre``, créez un `userdata_schema.json` fichier. 1. Modifiez le `userdata_schema.json` fichier pour créer un schéma [JSON IETF Draft v4](https://json-schema.org/specification-links.html#draft-4) valide. Lorsque IDT exécute votre suite de tests, il lit automatiquement le schéma et l'utilise pour valider le `userdata.json` fichier fourni par le testeur. S'il est valide, le contenu du `userdata.json` fichier est disponible à la fois dans le contexte [IDT et dans le contexte](idt-context.md) de la [machine à états](idt-state-machine.md#state-machine-context). # Configuration de la machine d'état IDT Une machine à états est une construction qui contrôle le flux d'exécution de la suite de tests. Il détermine l'état de départ d'une suite de tests, gère les transitions d'état en fonction de règles définies par l'utilisateur et continue de passer par ces états jusqu'à ce qu'il atteigne l'état final. Si votre suite de tests n'inclut pas de machine à états définie par l'utilisateur, IDT générera une machine à états pour vous. La machine à états par défaut exécute les fonctions suivantes : + Permet aux testeurs de sélectionner et d'exécuter des groupes de tests spécifiques, au lieu de recourir à la suite de tests complète. + Si aucun groupe de test spécifique n'est sélectionné, exécute chaque groupe de test de la suite de tests dans un ordre aléatoire. + Génère des rapports et imprime un résumé de console présentant les résultats des tests pour chaque groupe de test et chaque cas de test. La machine d'état d'une suite de tests IDT doit répondre aux critères suivants : + Chaque état correspond à une action que doit effectuer IDT, par exemple exécuter un groupe de test ou produire un fichier de rapport. + Le passage à un état exécute l'action associée à cet état. + Chaque état définit la règle de transition pour l'état suivant. + L'état final doit être l'un `Succeed` ou l'autre`Fail`. ## Format de la machine à états Vous pouvez utiliser le modèle suivant pour configurer votre propre `/suite/state_machine.json` fichier : ``` { "Comment": "", "StartAt": "", "States": { "": { "Type": "", // Additional state configuration } // Required states "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `Comment` Description de la machine à états. `StartAt` Nom de l'état dans lequel IDT commence à exécuter la suite de tests. La valeur de `StartAt` doit être définie sur l'un des états répertoriés dans l'`States`objet. `States` Objet qui fait correspondre les noms d'état définis par l'utilisateur à des états IDT valides. Chaque État. *state-name*l'objet contient la définition d'un état valide mappé à. *state-name* L'`States`objet doit inclure les `Fail` états `Succeed` et. Pour plus d'informations sur les états valides, consultez[États valides et définitions d'états](#valid-states). ## États valides et définitions d'états Cette section décrit les définitions d'état de tous les états valides qui peuvent être utilisés dans la machine d'état IDT. Certains des états suivants prennent en charge les configurations au niveau du scénario de test. Toutefois, nous vous recommandons de configurer les règles de transition d'état au niveau du groupe de test plutôt qu'au niveau du cas de test, sauf si cela est absolument nécessaire. **Topics** + [ ### RunTask ](#state-runtask) + [ ### Choice ](#state-choice) + [ ### Parallèle ](#state-parallel) + [ ### AddProductFeatures ](#state-addproductfeatures) + [ ### Rapport ](#state-report) + [ ### LogMessage ](#state-logmessage) + [ ### SelectGroup ](#state-selectgroup) + [ ### Fail ](#state-fail) + [ ### Succeed ](#state-succeed) ### RunTask L'`RunTask`État exécute des scénarios de test à partir d'un groupe de tests défini dans la suite de tests. ``` { "Type": "RunTask", "Next": "", "TestGroup": "", "TestCases": [ "" ], "ResultVar": "" } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `Next` Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel. `TestGroup` Facultatif. ID du groupe de test à exécuter. Si cette valeur n'est pas spécifiée, IDT exécute le groupe de test sélectionné par le testeur. `TestCases` Facultatif. Un tableau de scénarios de test IDs provenant du groupe spécifié dans`TestGroup`. Sur la base des valeurs de `TestGroup` et`TestCases`, IDT détermine le comportement d'exécution du test comme suit : + Lorsque `TestGroup` les deux `TestCases` sont spécifiés, IDT exécute les cas de test spécifiés à partir du groupe de test. + Lorsqu'ils `TestCases` sont spécifiés mais `TestGroup` non spécifiés, IDT exécute les cas de test spécifiés. + Lorsqu'il `TestGroup` est spécifié, mais `TestCases` non spécifié, IDT exécute tous les cas de test au sein du groupe de test spécifié. + Lorsque ni l'`TestGroup`un ni l'autre n'`TestCases`est spécifié, IDT exécute tous les cas de test à partir du groupe de test sélectionné par le lanceur de tests dans la CLI IDT. Pour permettre la sélection de groupes pour les testeurs, vous devez inclure à la fois les `Choice` états `RunTask` et les états dans votre `statemachine.json` fichier. Pour un exemple de la façon dont cela fonctionne, voir [Exemple de machine à états : exécuter des groupes de test sélectionnés par l'utilisateur](#allow-specific-groups). Pour plus d'informations sur l'activation des commandes IDT CLI pour les testeurs, consultez[Activer les commandes IDT CLI](test-executables.md#idt-cli-coop). `ResultVar` Nom de la variable de contexte à définir avec les résultats du test. Ne spécifiez pas cette valeur si vous n'avez pas indiqué de valeur pour`TestGroup`. IDT définit la valeur de la variable que vous définissez dans `true` ou `ResultVar` en `false` fonction des éléments suivants : + Si le nom de la variable est au format`text_text_passed`, la valeur est définie de manière à indiquer si tous les tests du premier groupe de tests ont été réussis ou ignorés. + Dans tous les autres cas, la valeur est définie selon que tous les tests de tous les groupes de tests ont été réussis ou ignorés. Généralement, vous utiliserez `RunTask` state pour spécifier un identifiant de groupe de test sans spécifier de cas de test individuel IDs, de sorte qu'IDT exécute tous les cas de test dans le groupe de test spécifié. Tous les cas de test exécutés par cet état sont exécutés en parallèle, dans un ordre aléatoire. Toutefois, si tous les scénarios de test nécessitent l'exécution d'un périphérique et qu'un seul périphérique est disponible, les scénarios de test seront exécutés de manière séquentielle. **Gestion des erreurs** Si l'un des groupes de tests ou des scénarios de test IDs spécifiés n'est pas valide, cet état génère l'erreur d'`RunTaskError`exécution. Si l'état rencontre une erreur d'exécution, il définit également la `hasExecutionError` variable dans le contexte de la machine à états sur`true`. ### Choice L'`Choice`état vous permet de définir dynamiquement l'état suivant vers lequel passer en fonction des conditions définies par l'utilisateur. ``` { "Type": "Choice", "Default": "", "FallthroughOnError": true | false, "Choices": [ { "Expression": "", "Next": "" } ] } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `Default` État par défaut vers lequel passer si aucune des expressions définies dans ne `Choices` peut être évaluée`true`. `FallthroughOnError` Facultatif. Spécifie le comportement lorsque l'état rencontre une erreur lors de l'évaluation des expressions. Définissez cette `true` valeur si vous souhaitez ignorer une expression si l'évaluation entraîne une erreur. Si aucune expression ne correspond, la machine à états passe à l'`Default`état. Si la `FallthroughOnError` valeur n'est pas spécifiée, elle est définie par défaut sur`false`. `Choices` Tableau d'expressions et d'états permettant de déterminer l'état vers lequel passer après avoir exécuté les actions dans l'état actuel. `Choices.Expression` Chaîne d'expression dont l'évaluation correspond à une valeur booléenne. Si l'expression est évaluée à`true`, la machine à états passe à l'état défini dans`Choices.Next`. Les chaînes d'expression récupèrent les valeurs du contexte de la machine à états, puis exécutent des opérations sur celles-ci pour obtenir une valeur booléenne. Pour plus d'informations sur l'accès au contexte de la machine à états, consultez[Contexte de la machine à états](#state-machine-context). `Choices.Next` Nom de l'état vers lequel passer si l'expression définie dans `Choices.Expression` correspond à`true`. **Gestion des erreurs** L'`Choice`état peut nécessiter la gestion des erreurs dans les cas suivants : + Certaines variables des expressions de choix n'existent pas dans le contexte de la machine à états. + Le résultat d'une expression n'est pas une valeur booléenne. + Le résultat d'une recherche JSON n'est pas une chaîne, un nombre ou un booléen. Vous ne pouvez pas utiliser un `Catch` bloc pour gérer les erreurs dans cet état. Si vous souhaitez arrêter l'exécution de la machine d'état lorsqu'elle rencontre une erreur, vous devez `FallthroughOnError` définir sur`false`. Toutefois, nous vous recommandons de configurer l'une des `FallthroughOnError` options suivantes et`true`, en fonction de votre cas d'utilisation, d'effectuer l'une des opérations suivantes : + Si une variable à laquelle vous accédez ne devrait pas exister dans certains cas, utilisez la valeur de `Default` et des `Choices` blocs supplémentaires pour spécifier l'état suivant. + Si une variable à laquelle vous accédez doit toujours exister, définissez son `Default` état sur`Fail`. ### Parallèle L'`Parallel`état vous permet de définir et d'exécuter de nouvelles machines à états en parallèle les unes avec les autres. ``` { "Type": "Parallel", "Next": "", "Branches": [ ] } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `Next` Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel. `Branches` Un tableau de définitions de machines à états à exécuter. Chaque définition de machine à états doit contenir ses propres `Fail` états `StartAt``Succeed`, et. Les définitions de machines à états de ce tableau ne peuvent pas faire référence à des états en dehors de leur propre définition. Étant donné que chaque machine d'état de branche partage le même contexte de machine d'état, le fait de définir des variables dans une branche puis de lire ces variables dans une autre branche peut entraîner un comportement inattendu. L'`Parallel`état ne passe à l'état suivant qu'après avoir exécuté toutes les machines d'état de branche. Chaque état nécessitant un appareil attendra de fonctionner jusqu'à ce que l'appareil soit disponible. Si plusieurs appareils sont disponibles, cet état exécute des scénarios de test à partir de plusieurs groupes en parallèle. Si un nombre suffisant de périphériques ne sont pas disponibles, les scénarios de test s'exécuteront de manière séquentielle. Comme les scénarios de test sont exécutés dans un ordre aléatoire lorsqu'ils sont exécutés en parallèle, différents appareils peuvent être utilisés pour exécuter des tests à partir du même groupe de test. **Gestion des erreurs** Assurez-vous que la machine d'état de branche et la machine d'état parent passent à l'`Fail`état pour gérer les erreurs d'exécution. Comme les machines d'état de branche ne transmettent pas d'erreurs d'exécution à la machine d'état parent, vous ne pouvez pas utiliser de `Catch` bloc pour gérer les erreurs d'exécution dans les machines d'état de branche. Utilisez plutôt la `hasExecutionErrors` valeur dans le contexte de la machine à états partagés. Pour un exemple de la façon dont cela fonctionne, voir[Exemple de machine à états : exécuter deux groupes de tests en parallèle](#run-in-parallel). ### AddProductFeatures L'`AddProductFeatures`état vous permet d'ajouter des fonctionnalités du produit au `awsiotdevicetester_report.xml` fichier généré par IDT. Les fonctionnalités d'un produit sont des informations définies par l'utilisateur concernant des critères spécifiques auxquels un appareil peut répondre. Par exemple, la fonctionnalité `MQTT` du produit peut indiquer que l'appareil publie correctement les messages MQTT. Dans le rapport, les fonctionnalités du produit sont définies sous `supported` la forme d'une valeur ou d'une valeur personnalisée, en fonction de la réussite des tests spécifiés. `not-supported` **Note** L'`AddProductFeatures`État ne produit pas de rapports par lui-même. Cet état doit passer à l'[`Report`état permettant](#state-report) de générer des rapports. ``` { "Type": "Parallel", "Next": "", "Features": [ { "Feature": "", "Groups": [ "" ], "OneOfGroups": [ "" ], "TestCases": [ "" ], "IsRequired": true | false, "ExecutionMethods": [ "" ] } ] } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `Next` Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel. `Features` Un ensemble de fonctionnalités du produit à afficher dans le `awsiotdevicetester_report.xml` fichier. `Feature` Le nom de la fonctionnalité `FeatureValue` Facultatif. La valeur personnalisée à utiliser dans le rapport à la place de`supported`. Si cette valeur n'est pas spécifiée, la valeur de la fonction est définie sur `supported` ou en fonction des résultats des tests`not-supported`. Si vous utilisez une valeur personnalisée pour`FeatureValue`, vous pouvez tester la même fonctionnalité dans des conditions différentes, et IDT concatène les valeurs des caractéristiques pour les conditions prises en charge. Par exemple, l'extrait suivant montre l'`MyFeature`entité avec deux valeurs de fonction distinctes : ``` ... { "Feature": "MyFeature", "FeatureValue": "first-feature-supported", "Groups": ["first-feature-group"] }, { "Feature": "MyFeature", "FeatureValue": "second-feature-supported", "Groups": ["second-feature-group"] }, ... ``` Si les deux groupes de test réussissent, la valeur de la fonctionnalité est définie sur`first-feature-supported, second-feature-supported`. `Groups` Facultatif. Un ensemble de groupes de test IDs. Tous les tests au sein de chaque groupe de test spécifié doivent réussir pour que la fonctionnalité soit prise en charge. `OneOfGroups` Facultatif. Un ensemble de groupes de test IDs. Tous les tests au sein d'au moins un des groupes de tests spécifiés doivent réussir pour que la fonctionnalité soit prise en charge. `TestCases` Facultatif. Un ensemble de scénarios de test IDs. Si vous spécifiez cette valeur, les règles suivantes s'appliquent : + Tous les scénarios de test spécifiés doivent être réussis pour que la fonctionnalité soit prise en charge. + `Groups`ne doit contenir qu'un seul identifiant de groupe de test. + `OneOfGroups`ne doit pas être spécifiée. `IsRequired` Facultatif. Réglez `false` sur pour marquer cette fonctionnalité comme fonctionnalité facultative dans le rapport. La valeur par défaut est `true`. `ExecutionMethods` Facultatif. Tableau de méthodes d'exécution correspondant à la `protocol` valeur spécifiée dans le `device.json` fichier. Si cette valeur est spécifiée, les testeurs doivent spécifier une `protocol` valeur correspondant à l'une des valeurs de ce tableau pour inclure la fonctionnalité dans le rapport. Si cette valeur n'est pas spécifiée, la fonctionnalité sera toujours incluse dans le rapport. Pour utiliser l'`AddProductFeatures`état, vous devez définir la valeur de `ResultVar` in the `RunTask` state sur l'une des valeurs suivantes : + Si vous avez spécifié un scénario de test individuel IDs, réglez `ResultVar` sur`group-id_test-id_passed`. + Si vous n'avez pas spécifié de scénario de test individuel IDs, réglez `ResultVar` sur`group-id_passed`. L'`AddProductFeatures`État vérifie les résultats des tests de la manière suivante : + Si vous n'avez spécifié aucun scénario de test IDs, le résultat de chaque groupe de test est déterminé à partir de la valeur de la `group-id_passed` variable dans le contexte de la machine à états. + Si vous avez spécifié un scénario de test IDs, le résultat de chacun des tests est déterminé à partir de la valeur de la `group-id_test-id_passed` variable dans le contexte de la machine à états. **Gestion des erreurs** Si un identifiant de groupe fourni dans cet état n'est pas un identifiant de groupe valide, cet état entraîne une erreur d'`AddProductFeaturesError`exécution. Si l'état rencontre une erreur d'exécution, il définit également la `hasExecutionErrors` variable dans le contexte de la machine à états sur`true`. ### Rapport L'`Report`état génère les `awsiotdevicetester_report.xml` fichiers `suite-name_Report.xml` et. Cet état diffuse également le rapport vers la console. ``` { "Type": "Report", "Next": "" } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `Next` Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel. Vous devez toujours passer à l'`Report`état vers la fin du flux d'exécution des tests afin que les testeurs puissent voir les résultats des tests. Généralement, l'état suivant après cet état est`Succeed`. **Gestion des erreurs** Si cet état rencontre des problèmes lors de la génération des rapports, il émet l'erreur d'`ReportError`exécution. ### LogMessage L'`LogMessage`état génère le `test_manager.log` fichier et transmet le message du journal à la console. ``` { "Type": "LogMessage", "Next": "" "Level": "info | warn | error" "Message": "" } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `Next` Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel. `Level` Le niveau d'erreur auquel le message de journal doit être créé. Si vous spécifiez un niveau non valide, cet état génère un message d'erreur et le supprime. `Message` Le message à enregistrer. ### SelectGroup L'`SelectGroup`état met à jour le contexte de la machine à états pour indiquer quels groupes sont sélectionnés. Les valeurs définies par cet état sont utilisées par tous `Choice` les états suivants. ``` { "Type": "SelectGroup", "Next": "" "TestGroups": [ " ] } ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `Next` Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel. `TestGroups` Un ensemble de groupes de test qui seront marqués comme sélectionnés. Pour chaque ID de groupe de test de ce tableau, la `group-id_selected` variable est définie sur `true` dans le contexte. Assurez-vous de fournir un groupe de test valide IDs car IDT ne valide pas l'existence des groupes spécifiés. ### Fail L'`Fail`état indique que la machine à états ne s'est pas exécutée correctement. Il s'agit d'un état final pour la machine à états, et chaque définition de machine à états doit inclure cet état. ``` { "Type": "Fail" } ``` ### Succeed L'`Succeed`état indique que la machine à états s'est exécutée correctement. Il s'agit d'un état final pour la machine à états, et chaque définition de machine à états doit inclure cet état. ``` { "Type": "Succeed" } ``` ## Contexte de la machine à états Le contexte de la machine à états est un document JSON en lecture seule qui contient les données mises à la disposition de la machine à états pendant l'exécution. Le contexte de la machine à états n'est accessible qu'à partir de la machine à états et contient des informations qui déterminent le flux de test. Par exemple, vous pouvez utiliser les informations configurées par les testeurs dans le `userdata.json` fichier pour déterminer si un test spécifique est requis pour être exécuté. Le contexte de la machine à états utilise le format suivant : ``` { "pool": { }, "userData": { }, "config": { }, "suiteFailed": true | false, "specificTestGroups": [ "" ], "specificTestCases": [ "" ], "hasExecutionErrors": true } ``` `pool` Informations sur le pool de périphériques sélectionné pour le test. Pour un pool de périphériques sélectionné, ces informations sont extraites de l'élément de tableau de pool de périphériques de niveau supérieur correspondant défini dans le `device.json` fichier. `userData` Informations contenues dans le `userdata.json` fichier. `config` Informations épinglez le `config.json` fichier. `suiteFailed` La valeur est définie sur le `false` démarrage de la machine à états. Si un groupe de test échoue dans un `RunTask` état, cette valeur est définie sur la durée restante `true` de l'exécution de la machine à états. `specificTestGroups` Si le testeur sélectionne des groupes de tests spécifiques à exécuter au lieu de l'ensemble de la suite de tests, cette clé est créée et contient la liste des groupes de tests spécifiques IDs. `specificTestCases` Si le lanceur de tests sélectionne des cas de test spécifiques à exécuter au lieu de la suite de tests complète, cette clé est créée et contient la liste des cas de test spécifiques IDs. `hasExecutionErrors` Ne se ferme pas au démarrage de la machine à états. Si un état rencontre une erreur d'exécution, cette variable est créée et définie `true` pour la durée restante de l'exécution de la machine à états. Vous pouvez interroger le contexte à l'aide de la JSONPath notation. La syntaxe des JSONPath requêtes dans les définitions d'état est`{{$.query}}`. Vous pouvez utiliser des JSONPath requêtes comme chaînes d'espace réservé dans certains États. IDT remplace les chaînes d'espace réservé par la valeur de la JSONPath requête évaluée à partir du contexte. Vous pouvez utiliser des espaces réservés pour les valeurs suivantes : + La `TestCases` valeur exprimée en `RunTask` états. + `Choice`État de `Expression` la valeur. Lorsque vous accédez aux données depuis le contexte de la machine à états, assurez-vous que les conditions suivantes sont remplies : + Vos chemins JSON doivent commencer par `$.` + Chaque valeur doit être évaluée sous la forme d'une chaîne, d'un nombre ou d'un booléen. Pour plus d'informations sur l'utilisation de la JSONPath notation pour accéder aux données depuis le contexte, consultez[Utiliser le contexte IDT](idt-context.md). ## Erreurs d'exécution Les erreurs d'exécution sont des erreurs dans la définition de la machine à états que la machine à états rencontre lors de l'exécution d'un état. IDT enregistre les informations relatives à chaque erreur dans le `test_manager.log` fichier et transmet le message de journal à la console. Vous pouvez utiliser les méthodes suivantes pour gérer les erreurs d'exécution : + Ajoutez un [`Catch`bloc](#catch) dans la définition de l'état. + Vérifiez la valeur de la [`hasExecutionErrors`valeur](#context) dans le contexte de la machine à états. ### Attraper Pour l'utiliser`Catch`, ajoutez ce qui suit à la définition de votre état : ``` "Catch": [ { "ErrorEquals": [ "" ] "Next": "" } ] ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `Catch.ErrorEquals` Tableau des types d'erreurs à détecter. Si une erreur d'exécution correspond à l'une des valeurs spécifiées, la machine à états passe à l'état spécifié dans`Catch.Next`. Consultez la définition de chaque état pour obtenir des informations sur le type d'erreur qu'il produit. `Catch.Next` État suivant vers lequel passer si l'état actuel rencontre une erreur d'exécution correspondant à l'une des valeurs spécifiées dans`Catch.ErrorEquals`. Les blocs de capture sont gérés de manière séquentielle jusqu'à ce qu'un d'entre eux corresponde. Si aucune erreur ne correspond à celles répertoriées dans les blocs Catch, les machines d'état continuent de s'exécuter. Les erreurs d'exécution étant le résultat de définitions d'état incorrectes, nous vous recommandons de passer à l'état Fail lorsqu'un état rencontre une erreur d'exécution. ### hasExecutionError Lorsque certains états rencontrent des erreurs d'exécution, en plus d'émettre l'erreur, ils définissent également la `hasExecutionError` valeur sur `true` dans le contexte de la machine à états. Vous pouvez utiliser cette valeur pour détecter le moment où une erreur se produit, puis utiliser un `Choice` état pour faire passer la machine à états à `Fail` cet état. Cette méthode présente les caractéristiques suivantes. + La machine à états ne démarre avec aucune valeur assignée à`hasExecutionError`, et cette valeur n'est pas disponible tant qu'un état particulier ne la définit pas. Cela signifie que vous devez définir explicitement la valeur `FallthroughOnError` to `false` pour les `Choice` états qui accèdent à cette valeur afin d'empêcher l'arrêt de la machine à états si aucune erreur d'exécution ne se produit. + Une fois défini sur`true`, il n'`hasExecutionError`est jamais défini sur false ni supprimé du contexte. Cela signifie que cette valeur n'est utile que la première fois qu'elle est définie sur`true`, et pour tous les états suivants, elle ne fournit pas de valeur significative. + La `hasExecutionError` valeur est partagée avec toutes les machines d'état de branche de l'`Parallel`état, ce qui peut entraîner des résultats inattendus en fonction de l'ordre dans lequel elle est consultée. En raison de ces caractéristiques, nous vous déconseillons d'utiliser cette méthode si vous pouvez utiliser un bloc Catch à la place. ## Exemples de machines à états Cette section fournit des exemples de configurations de machines à états. **Topics** + [ ### Exemple de machine à états : exécuter un seul groupe de test ](#single-test-group) + [ ### Exemple de machine à états : exécuter des groupes de test sélectionnés par l'utilisateur ](#allow-specific-groups) + [ ### Exemple de machine à états : exécuter un seul groupe de test avec les fonctionnalités du produit ](#run-with-product-features) + [ ### Exemple de machine à états : exécuter deux groupes de tests en parallèle ](#run-in-parallel) ### Exemple de machine à états : exécuter un seul groupe de test Cette machine à états : + Exécute le groupe de test avec un identifiant`GroupA`, qui doit être présent dans la suite dans un `group.json` fichier. + Vérifie l'absence d'erreurs d'exécution et effectue la transition vers le `Fail` cas échéant. + Génère un rapport et passe à `Succeed` s'il n'y a pas d'erreur, et `Fail` sinon. ``` { "Comment": "Runs a single group and then generates a report.", "StartAt": "RunGroupA", "States": { "RunGroupA": { "Type": "RunTask", "Next": "Report", "TestGroup": "GroupA", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` ### Exemple de machine à états : exécuter des groupes de test sélectionnés par l'utilisateur Cette machine à états : + Vérifie si le testeur a sélectionné des groupes de test spécifiques. La machine à états ne vérifie pas les cas de test spécifiques car les testeurs ne peuvent pas sélectionner de cas de test sans sélectionner également un groupe de test. + Si des groupes de test sont sélectionnés : + Exécute les scénarios de test au sein des groupes de test sélectionnés. Pour ce faire, la machine d'état ne spécifie pas explicitement de groupes de test ou de cas de test dans l'`RunTask`état. + Génère un rapport après avoir exécuté tous les tests et sorties. + Si les groupes de test ne sont pas sélectionnés : + Exécute des tests dans le groupe de test`GroupA`. + Génère des rapports et des sorties. ``` { "Comment": "Runs specific groups if the test runner chose to do that, otherwise runs GroupA.", "StartAt": "SpecificGroupsCheck", "States": { "SpecificGroupsCheck": { "Type": "Choice", "Default": "RunGroupA", "FallthroughOnError": true, "Choices": [ { "Expression": "{{$.specificTestGroups[0]}} != ''", "Next": "RunSpecificGroups" } ] }, "RunSpecificGroups": { "Type": "RunTask", "Next": "Report", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "RunGroupA": { "Type": "RunTask", "Next": "Report", "TestGroup": "GroupA", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` ### Exemple de machine à états : exécuter un seul groupe de test avec les fonctionnalités du produit Cette machine à états : + Exécute le groupe de test`GroupA`. + Vérifie l'absence d'erreurs d'exécution et effectue la transition vers le `Fail` cas échéant. + Ajoute la `FeatureThatDependsOnGroupA` fonctionnalité au `awsiotdevicetester_report.xml` fichier : + En `GroupA` cas de réussite, la fonctionnalité est réglée sur`supported`. + La fonctionnalité n'est pas marquée comme facultative dans le rapport. + Génère un rapport et passe à `Succeed` s'il n'y a pas d'erreur, et `Fail` sinon ``` { "Comment": "Runs GroupA and adds product features based on GroupA", "StartAt": "RunGroupA", "States": { "RunGroupA": { "Type": "RunTask", "Next": "AddProductFeatures", "TestGroup": "GroupA", "ResultVar": "GroupA_passed", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "AddProductFeatures": { "Type": "AddProductFeatures", "Next": "Report", "Features": [ { "Feature": "FeatureThatDependsOnGroupA", "Groups": [ "GroupA" ], "IsRequired": true } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` ### Exemple de machine à états : exécuter deux groupes de tests en parallèle Cette machine à états : + Exécute les groupes `GroupA` de `GroupB` test et de test en parallèle. Les `ResultVar` variables stockées dans le contexte par les `RunTask` états dans les machines à états de branche sont disponibles pour l'`AddProductFeatures`état. + Vérifie l'absence d'erreurs d'exécution et effectue la transition vers le `Fail` cas échéant. Cette machine d'état n'utilise pas de `Catch` bloc car cette méthode ne détecte pas les erreurs d'exécution dans les machines d'état de branche. + Ajoute des fonctionnalités au `awsiotdevicetester_report.xml` fichier en fonction des groupes qui passent + En `GroupA` cas de réussite, la fonctionnalité est réglée sur`supported`. + La fonctionnalité n'est pas marquée comme facultative dans le rapport. + Génère un rapport et passe à `Succeed` s'il n'y a pas d'erreur, et `Fail` sinon Si deux appareils sont configurés dans le pool de périphériques, `GroupA` les deux `GroupB` peuvent fonctionner en même temps. Toutefois, si l'`GroupA`un ou l'autre `GroupB` contient plusieurs tests, les deux appareils peuvent être affectés à ces tests. Si un seul appareil est configuré, les groupes de test s'exécuteront de manière séquentielle. ``` { "Comment": "Runs GroupA and GroupB in parallel", "StartAt": "RunGroupAAndB", "States": { "RunGroupAAndB": { "Type": "Parallel", "Next": "CheckForErrors", "Branches": [ { "Comment": "Run GroupA state machine", "StartAt": "RunGroupA", "States": { "RunGroupA": { "Type": "RunTask", "Next": "Succeed", "TestGroup": "GroupA", "ResultVar": "GroupA_passed", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } }, { "Comment": "Run GroupB state machine", "StartAt": "RunGroupB", "States": { "RunGroupA": { "Type": "RunTask", "Next": "Succeed", "TestGroup": "GroupB", "ResultVar": "GroupB_passed", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ] }, "CheckForErrors": { "Type": "Choice", "Default": "AddProductFeatures", "FallthroughOnError": true, "Choices": [ { "Expression": "{{$.hasExecutionErrors}} == true", "Next": "Fail" } ] }, "AddProductFeatures": { "Type": "AddProductFeatures", "Next": "Report", "Features": [ { "Feature": "FeatureThatDependsOnGroupA", "Groups": [ "GroupA" ], "IsRequired": true }, { "Feature": "FeatureThatDependsOnGroupB", "Groups": [ "GroupB" ], "IsRequired": true } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` # Création d'exécutables de scénarios de test IDT Vous pouvez créer et placer des exécutables de scénarios de test dans un dossier de suite de tests de la manière suivante : + Pour les suites de tests qui utilisent des arguments ou des variables d'environnement provenant des `test.json` fichiers pour déterminer les tests à exécuter, vous pouvez créer un seul scénario de test exécutable pour l'ensemble de la suite de tests, ou un exécutable de test pour chaque groupe de tests de la suite de tests. + Pour une suite de tests dans laquelle vous souhaitez exécuter des tests spécifiques en fonction de commandes spécifiées, vous devez créer un fichier exécutable pour chaque cas de test de la suite de tests. En tant que rédacteur de tests, vous pouvez déterminer quelle approche convient à votre cas d'utilisation et structurer l'exécutable de votre scénario de test en conséquence. Assurez-vous de fournir le chemin exécutable du scénario de test correct dans chaque `test.json` fichier et que le fichier exécutable spécifié s'exécute correctement. Lorsque tous les appareils sont prêts pour l'exécution d'un scénario de test, IDT lit les fichiers suivants : + Le `test.json` scénario de test sélectionné détermine les processus à démarrer et les variables d'environnement à définir. + Le `suite.json` for the test suite détermine les variables d'environnement à définir. IDT démarre le processus exécutable de test requis en fonction des commandes et des arguments spécifiés dans le `test.json` fichier, et transmet les variables d'environnement requises au processus. ## Utiliser le SDK du client IDT Le client IDT vous permet SDKs de simplifier la façon dont vous écrivez la logique de test dans votre exécutable de test grâce à des commandes d'API que vous pouvez utiliser pour interagir avec IDT et vos appareils testés. IDT fournit actuellement les services suivants : SDKs + SDK client IDT pour Python + SDK client IDT pour Go Ils se SDKs trouvent dans le `/sdks` dossier. Lorsque vous créez un nouvel exécutable de scénario de test, vous devez copier le SDK que vous souhaitez utiliser dans le dossier contenant votre exécutable de scénario de test et référencer le SDK dans votre code. Cette section fournit une brève description des commandes d'API disponibles que vous pouvez utiliser dans les exécutables de vos scénarios de test. **Topics** + [ ### Interaction avec les appareils ](#api-device-interaction) + [ ### Interaction avec IDT ](#api-idt-interaction) + [ ### Interaction avec l'hôte ](#api-host-interaction) ### Interaction avec les appareils Les commandes suivantes vous permettent de communiquer avec l'appareil testé sans avoir à implémenter de fonctions supplémentaires d'interaction avec l'appareil et de gestion de la connectivité. `ExecuteOnDevice` Permet aux suites de tests d'exécuter des commandes shell sur un appareil prenant en charge les connexions SSH ou Docker shell. `CopyToDevice` Permet aux suites de tests de copier un fichier local depuis la machine hôte qui exécute IDT vers un emplacement spécifié sur un appareil prenant en charge les connexions SSH ou Docker shell. `ReadFromDevice` Permet aux suites de tests de lire à partir du port série des appareils prenant en charge les connexions UART. **Note** IDT ne gérant pas les connexions directes aux appareils établies à l'aide des informations d'accès aux appareils issues du contexte, nous vous recommandons d'utiliser ces commandes API d'interaction avec les appareils dans les exécutables de vos scénarios de test. Toutefois, si ces commandes ne répondent pas aux exigences de votre scénario de test, vous pouvez récupérer les informations d'accès à l'appareil à partir du contexte IDT et les utiliser pour établir une connexion directe avec l'appareil à partir de la suite de tests. Pour établir une connexion directe, récupérez les informations dans les `resource.devices.connectivity` champs `device.connectivity` et pour votre appareil testé et pour les périphériques ressources, respectivement. Pour plus d'informations sur l'utilisation du contexte IDT, consultez[Utiliser le contexte IDT](idt-context.md). ### Interaction avec IDT Les commandes suivantes permettent à vos suites de tests de communiquer avec IDT. `PollForNotifications` Permet aux suites de tests de vérifier les notifications provenant d'IDT. `GetContextValue ` et `GetContextString` Permet aux suites de tests de récupérer des valeurs à partir du contexte IDT. Pour de plus amples informations, veuillez consulter [Utiliser le contexte IDT](idt-context.md). `SendResult` Permet aux suites de tests de communiquer les résultats des scénarios de test à IDT. Cette commande doit être appelée à la fin de chaque scénario de test dans une suite de tests. ### Interaction avec l'hôte La commande suivante permet à vos suites de tests de communiquer avec la machine hôte. `PollForNotifications` Permet aux suites de tests de vérifier les notifications provenant d'IDT. `GetContextValue ` et `GetContextString` Permet aux suites de tests de récupérer des valeurs à partir du contexte IDT. Pour de plus amples informations, veuillez consulter [Utiliser le contexte IDT](idt-context.md). `ExecuteOnHost` Permet aux suites de tests d'exécuter des commandes sur la machine locale et permet à IDT de gérer le cycle de vie des exécutables des scénarios de test. ## Activer les commandes IDT CLI La `run-suite` commande IDT CLI fournit plusieurs options qui permettent au lanceur de tests de personnaliser l'exécution des tests. Pour permettre aux testeurs d'utiliser ces options pour exécuter votre suite de tests personnalisée, vous implémentez le support de la CLI IDT. Si vous n'implémentez pas le support, les testeurs pourront toujours exécuter des tests, mais certaines options de la CLI ne fonctionneront pas correctement. Pour offrir une expérience client optimale, nous vous recommandons de mettre en œuvre la prise en charge des arguments suivants pour la `run-suite` commande dans la CLI IDT : `timeout-multiplier` Spécifie une valeur supérieure à 1,0 qui sera appliquée à tous les délais d'expiration lors de l'exécution des tests. Les testeurs peuvent utiliser cet argument pour augmenter le délai d'expiration des scénarios de test qu'ils souhaitent exécuter. Lorsqu'un lanceur de tests spécifie cet argument dans sa `run-suite` commande, IDT l'utilise pour calculer la valeur de la variable d'environnement IDT\$1TEST\$1TIMEOUT et définit le champ dans le contexte IDT. `config.timeoutMultiplier` Pour étayer cet argument, vous devez procéder comme suit : + Au lieu d'utiliser directement la valeur de délai d'attente du `test.json` fichier, lisez la variable d'environnement IDT\$1TEST\$1TIMEOUT pour obtenir la valeur de délai d'expiration correctement calculée. + Récupérez la `config.timeoutMultiplier` valeur dans le contexte IDT et appliquez-la à des délais d'expiration prolongés. Pour plus d'informations sur la fermeture anticipée en raison d'événements liés au délai imparti, consultez. [Spécifier le comportement de sortie](#test-exec-exiting) `stop-on-first-failure` Spécifie qu'IDT doit arrêter d'exécuter tous les tests en cas d'échec. Lorsqu'un lanceur de tests spécifie cet argument dans sa `run-suite` commande, IDT arrête d'exécuter les tests dès qu'il rencontre un échec. Toutefois, si les scénarios de test sont exécutés en parallèle, cela peut entraîner des résultats inattendus. Pour mettre en œuvre le support, assurez-vous que si IDT rencontre cet événement, votre logique de test indique à tous les scénarios de test en cours d'exécution de s'arrêter, de nettoyer les ressources temporaires et de communiquer un résultat de test à IDT. Pour plus d'informations sur la gestion anticipée des défaillances, consultez[Spécifier le comportement de sortie](#test-exec-exiting). `group-id` et `test-id` Spécifie qu'IDT ne doit exécuter que les groupes de tests ou les cas de test sélectionnés. Les testeurs peuvent utiliser ces arguments avec leur `run-suite` commande pour spécifier le comportement d'exécution du test suivant : + Exécutez tous les tests au sein des groupes de tests spécifiés. + Exécutez une sélection de tests au sein d'un groupe de tests spécifié. Pour prendre en charge ces arguments, la machine à états de votre suite de tests doit inclure un ensemble spécifique d'`Choice`états `RunTask` et dans votre machine à états. Si vous n'utilisez pas de machine à états personnalisée, la machine à états IDT par défaut inclut les états requis pour vous et vous n'avez pas besoin de prendre d'autres mesures. Toutefois, si vous utilisez une machine à états personnalisée, utilisez-la [Exemple de machine à états : exécuter des groupes de test sélectionnés par l'utilisateur](idt-state-machine.md#allow-specific-groups) comme exemple pour ajouter les états requis dans votre machine à états. Pour plus d'informations sur les commandes IDT CLI, consultez[Déboguer et exécuter des suites de tests personnalisées](run-tests-custom.md). ## Rédiger des journaux d'événements Pendant le test, vous envoyez des données à la console `stdout` et vous `stderr` devez y écrire des journaux d'événements et des messages d'erreur. Pour plus d'informations sur le format des messages de console, consultez[Format des messages de console](idt-review-results-logs.md#idt-console-format). Lorsque l'IDT a terminé d'exécuter la suite de tests, ces informations sont également disponibles dans le `test_manager.log` fichier situé dans le `/results//logs` dossier. Vous pouvez configurer chaque scénario de test pour écrire les journaux de son exécution, y compris les journaux du périphérique testé, dans le `_` fichier situé dans le `/results/execution-id/logs` dossier. Pour ce faire, récupérez le chemin du fichier journal à partir du contexte IDT contenant la `testData.logFilePath` requête, créez un fichier sur ce chemin et inscrivez le contenu que vous souhaitez y insérer. IDT met automatiquement à jour le chemin en fonction du scénario de test en cours d'exécution. Si vous choisissez de ne pas créer le fichier journal pour un scénario de test, aucun fichier n'est généré pour ce scénario de test. Vous pouvez également configurer votre exécutable texte pour créer des fichiers journaux supplémentaires, selon les besoins, dans le `/logs` dossier. Nous vous recommandons de spécifier des préfixes uniques pour les noms de fichiers journaux afin que vos fichiers ne soient pas remplacés. ## Signaler les résultats à IDT IDT écrit les résultats des tests dans les fichiers `awsiotdevicetester_report.xml` et les `suite-name_report.xml` fichiers. Ces fichiers de rapport se trouvent dans`/results//`. Les deux rapports capturent les résultats de l'exécution de la suite de tests. Pour plus d'informations sur les schémas utilisés par IDT pour ces rapports, voir [Consulter les résultats et les journaux des tests IDT](idt-review-results-logs.md) Pour renseigner le contenu du `suite-name_report.xml` fichier, vous devez utiliser la `SendResult` commande pour communiquer les résultats des tests à IDT avant la fin de l'exécution du test. Si IDT ne trouve pas les résultats d'un test, il émet une erreur pour le scénario de test. L'extrait Python suivant montre les commandes permettant d'envoyer un résultat de test à IDT : ``` request-variable = SendResultRequest(TestResult(result)) client.send_result(request-variable) ``` Si vous ne communiquez pas les résultats via l'API, IDT recherche les résultats des tests dans le dossier des artefacts de test. Le chemin d'accès à ce dossier est stocké dans le `testData.testArtifactsPath` fichier dans le contexte IDT. Dans ce dossier, IDT utilise le premier fichier XML trié par ordre alphabétique qu'il trouve comme résultat du test. Si votre logique de test produit des résultats JUnit XML, vous pouvez écrire les résultats du test dans un fichier XML dans le dossier des artefacts pour fournir directement les résultats à IDT au lieu de les analyser puis d'utiliser l'API pour les envoyer à IDT. Si vous utilisez cette méthode, assurez-vous que votre logique de test résume correctement les résultats du test et formatez votre fichier de résultats dans le même format que le `suite-name_report.xml` fichier. IDT n'effectue aucune validation des données que vous fournissez, sauf dans les cas suivants : + IDT ignore toutes les propriétés de la `testsuites` balise. Au lieu de cela, il calcule les propriétés des balises à partir des résultats d'autres groupes de test rapportés. + Au moins une `testsuite` balise doit figurer à l'intérieur`testsuites`. Étant donné qu'IDT utilise le même dossier d'artefacts pour tous les scénarios de test et ne supprime pas les fichiers de résultats entre les tests, cette méthode peut également entraîner des rapports erronés si IDT lit le mauvais fichier. Nous vous recommandons d'utiliser le même nom pour le fichier de résultats XML généré dans tous les scénarios de test afin de remplacer les résultats de chaque scénario de test et de vous assurer que les résultats corrects sont disponibles pour IDT. Bien que vous puissiez utiliser une approche mixte pour créer des rapports dans votre suite de tests, c'est-à-dire utiliser un fichier de résultats XML pour certains cas de test et soumettre les résultats via l'API pour d'autres, nous ne recommandons pas cette approche. ## Spécifier le comportement de sortie Configurez votre exécutable texte pour qu'il se ferme toujours avec un code de sortie de 0, même si un scénario de test indique un échec ou un résultat d'erreur. Utilisez des codes de sortie différents de zéro uniquement pour indiquer qu'un scénario de test n'a pas été exécuté ou si l'exécutable du scénario de test n'a pas pu communiquer de résultats à IDT. Lorsque IDT reçoit un code de sortie différent de zéro, cela indique que le scénario de test a rencontré une erreur qui l'a empêché de s'exécuter. IDT peut demander ou s'attendre à ce qu'un scénario de test s'arrête avant sa fin dans les événements suivants. Utilisez ces informations pour configurer le fichier exécutable de votre scénario de test afin de détecter chacun de ces événements dans le scénario de test : **Expiration** Se produit lorsqu'un scénario de test s'exécute pendant une durée supérieure à la valeur de délai spécifiée dans le `test.json` fichier. Si le lanceur de test a utilisé l'`timeout-multiplier`argument pour spécifier un multiplicateur de délai d'attente, IDT calcule la valeur du délai d'expiration avec le multiplicateur. Pour détecter cet événement, utilisez la variable d'environnement IDT\$1TEST\$1TIMEOUT. Lorsqu'un lanceur de tests lance un test, IDT définit la valeur de la variable d'environnement IDT\$1TEST\$1TIMEOUT sur la valeur du délai d'attente calculée (en secondes) et transmet la variable à l'exécutable du scénario de test. Vous pouvez lire la valeur de la variable pour définir un temporisateur approprié. **Interrompre** Survient lorsque le lanceur de test interrompt l'IDT. Par exemple, en appuyant surCtrl\$1C. Comme les terminaux transmettent les signaux à tous les processus enfants, vous pouvez simplement configurer un gestionnaire de signaux dans vos scénarios de test pour détecter les signaux d'interruption. Vous pouvez également interroger régulièrement l'API pour vérifier la valeur du `CancellationRequested` booléen dans la réponse de l'`PollForNotifications`API. Lorsque IDT reçoit un signal d'interruption, il définit la valeur du `CancellationRequested` booléen sur. `true` **Arrêt dès le premier échec** Se produit lorsqu'un scénario de test exécuté en parallèle avec le scénario de test en cours échoue et que le lanceur de test a utilisé l'`stop-on-first-failure`argument pour spécifier qu'IDT doit s'arrêter en cas de défaillance. Pour détecter cet événement, vous pouvez interroger régulièrement l'API afin de vérifier la valeur du `CancellationRequested` booléen dans la réponse de l'`PollForNotifications`API. Lorsqu'IDT rencontre une défaillance et est configuré pour s'arrêter lors du premier échec, il définit la valeur du `CancellationRequested` booléen sur. `true` Lorsque l'un de ces événements se produit, IDT attend 5 minutes que les scénarios de test en cours soient terminés. Si tous les scénarios de test en cours ne se terminent pas dans les 5 minutes, IDT force l'arrêt de chacun de leurs processus. Si IDT n'a pas reçu les résultats des tests avant la fin des processus, il marquera les cas de test comme ayant expiré. Il est recommandé de veiller à ce que vos scénarios de test exécutent les actions suivantes lorsqu'ils rencontrent l'un des événements : 1. Arrêtez d'exécuter la logique de test normale. 1. Nettoyez toutes les ressources temporaires, telles que les artefacts de test présents sur l'appareil testé. 1. Signalez un résultat de test à IDT, tel qu'un échec ou une erreur. 1. Sortir. # Utiliser le contexte IDT Lorsque IDT exécute une suite de tests, celle-ci peut accéder à un ensemble de données qui peuvent être utilisées pour déterminer le mode d'exécution de chaque test. Ces données sont appelées contexte IDT. Par exemple, la configuration des données utilisateur fournie par les testeurs dans un `userdata.json` fichier est mise à la disposition des suites de tests dans le contexte IDT. Le contexte IDT peut être considéré comme un document JSON en lecture seule. Les suites de tests peuvent récupérer des données et écrire des données dans le contexte à l'aide de types de données JSON standard tels que des objets, des tableaux, des nombres, etc. ## Schéma de contexte Le contexte IDT utilise le format suivant : ``` { "config": { "timeoutMultiplier": timeout-multiplier }, "device": { }, "devicePool": { }, "resource": { "devices": [ { "name": "" } ] }, "testData": { "awsCredentials": { "awsAccessKeyId": "", "awsSecretAccessKey": "", "awsSessionToken": "" }, "logFilePath": "/path/to/log/file" }, "userData": { } } ``` `config` Informations contenues dans le [`config.json`fichier](gg-core.md#config-json). Le `config` champ contient également le champ supplémentaire suivant : `config.timeoutMultiplier` Le multiplicateur pour toute valeur de délai d'attente utilisée par la suite de tests. Cette valeur est spécifiée par le lanceur de tests à partir de la CLI IDT. La valeur par défaut est `1`. `device` Informations sur le périphérique sélectionné pour le test. Ces informations sont équivalentes à l'élément du `devices` tableau dans le [`device.json`fichier](set-config-custom.md#device-config-custom) du périphérique sélectionné. `devicePool` Informations sur le pool de périphériques sélectionné pour le test. Ces informations sont équivalentes à l'élément de tableau de pool de périphériques de niveau supérieur défini dans le `device.json` fichier pour le pool de périphériques sélectionné. `resource` Informations sur les périphériques de ressources contenues dans le `resource.json` fichier. `resource.devices` Ces informations sont équivalentes au `devices` tableau défini dans le `resource.json` fichier. Chaque `devices` élément inclut le champ supplémentaire suivant : `resource.device.name` Nom du périphérique ressource. Cette valeur est définie sur la `requiredResource.name` valeur du `test.json` fichier. `testData.awsCredentials` Les AWS informations d'identification utilisées par le test pour se connecter au AWS cloud. Ces informations sont extraites du `config.json` fichier. `testData.logFilePath` Le chemin d'accès au fichier journal dans lequel le scénario de test écrit les messages de journal. La suite de tests crée ce fichier s'il n'existe pas. `userData` Informations fournies par le testeur dans le [`userdata.json`fichier](set-config-custom.md#userdata-config-custom). ## Accédez aux données dans le contexte Vous pouvez interroger le contexte en utilisant la JSONPath notation de vos fichiers JSON et de votre exécutable texte avec le `GetContextValue` et `GetContextString` APIs. La syntaxe des JSONPath chaînes permettant d'accéder au contexte IDT varie comme suit : + Dans `suite.json` et`test.json`, tu utilises`{{query}}`. En d'autres termes, n'utilisez pas l'élément racine `$.` pour démarrer votre expression. + Dans`statemachine.json`, tu utilises`{{$.query}}`. + Dans les commandes d'API, vous utilisez `query` ou`{{$.query}}`, selon la commande. Pour plus d'informations, consultez la documentation intégrée dans le SDKs. Le tableau suivant décrit les opérateurs d'une JSONPath expression typique : | Opérateur | Description | | --- |--- | | \$1 | L'élément racine. La valeur de contexte de haut niveau pour IDT étant un objet, vous l'utiliserez généralement \$1. pour démarrer vos requêtes. | | .childName | Accède à l'élément enfant dont le nom childName provient d'un objet. S'il est appliqué à un tableau, il produit un nouveau tableau avec cet opérateur appliqué à chaque élément. Le nom de l'élément distingue les majuscules et minuscules. Par exemple, la requête pour accéder à la awsRegion valeur de l'configobjet est\$1.config.awsRegion. | | [start:end] | Filtre les éléments d'un tableau, en récupérant les éléments en commençant par l'startindex et en remontant jusqu'à l'endindex, dans les deux cas inclus. | | [index1, index2, ... , indexN] | Filtre les éléments d'un tableau, en récupérant les éléments uniquement à partir des indices spécifiés. | | [?(expr)] | Filtre les éléments d'un tableau à l'aide de l'exprexpression. Cette expression doit être évaluée à une valeur booléenne. | Pour créer des expressions de filtre, utilisez la syntaxe suivante : ``` | operator | ``` Dans cette syntaxe : + `jsonpath`est un JSONPath qui utilise la syntaxe JSON standard. + `value`est une valeur personnalisée qui utilise la syntaxe JSON standard. + `operator`est l'un des opérateurs suivants : + `<`(Inférieur à) + `<=`(Inférieur ou égal à) + `==`(Égal à) Si la valeur JSONPath ou de votre expression est un tableau, une valeur booléenne ou une valeur d'objet, il s'agit du seul opérateur binaire pris en charge que vous pouvez utiliser. + `>=`(Supérieur ou égal à) + `>`(Supérieur à) + `=~`(Correspondance d'expressions régulières). Pour utiliser cet opérateur dans une expression de filtre, la valeur JSONPath ou sur le côté gauche de votre expression doit être une chaîne et le côté droit doit être une valeur de modèle conforme à la [RE2syntaxe](https://github.com/google/re2/wiki/Syntax). Vous pouvez utiliser JSONPath des requêtes sous la forme \$1\$1*query*\$1\$1 comme chaînes d'espace réservé dans les `environmentVariables` champs `args` et `test.json` des fichiers et dans les `environmentVariables` champs des `suite.json` fichiers. IDT effectue une recherche contextuelle et remplit les champs avec la valeur évaluée de la requête. Par exemple, dans le `suite.json` fichier, vous pouvez utiliser des chaînes d'espace réservé pour spécifier des valeurs de variables d'environnement qui changent avec chaque scénario de test et IDT remplira les variables d'environnement avec la valeur correcte pour chaque cas de test. Toutefois, lorsque vous utilisez des chaînes d'espace réservé dans des `suite.json` fichiers `test.json` et, les considérations suivantes s'appliquent à vos requêtes : + Vous devez écrire toutes les occurrences de la `devicePool` clé dans votre requête en minuscules. C'est-à-dire, utilisez `devicepool` plutôt. + Pour les tableaux, vous ne pouvez utiliser que des tableaux de chaînes. De plus, les tableaux utilisent un format non standard. `item1, item2,...,itemN` Si le tableau ne contient qu'un seul élément, il est sérialisé en tant que tel`item`, ce qui le rend impossible à distinguer d'un champ de chaîne. + Vous ne pouvez pas utiliser d'espaces réservés pour récupérer des objets depuis le contexte. En raison de ces considérations, nous vous recommandons, dans la mesure du possible, d'utiliser l'API pour accéder au contexte de votre logique de test au lieu d'utiliser des chaînes de caractères dans `suite.json` les fichiers `test.json` et. Toutefois, dans certains cas, il peut être plus pratique d'utiliser des JSONPath espaces réservés pour récupérer des chaînes uniques à définir comme variables d'environnement. # Configuration des paramètres pour les testeurs Pour exécuter des suites de tests personnalisées, les testeurs doivent configurer leurs paramètres en fonction de la suite de tests qu'ils souhaitent exécuter. Les paramètres sont spécifiés en fonction des modèles de fichiers de configuration JSON situés dans le `/configs/` dossier. Si nécessaire, les testeurs doivent également configurer des AWS informations d'identification qu'IDT utilisera pour se connecter au AWS cloud. En tant que rédacteur de tests, vous devrez configurer ces fichiers pour [déboguer votre suite de tests](run-tests-custom.md). Vous devez fournir des instructions aux testeurs afin qu'ils puissent configurer les paramètres suivants selon les besoins pour exécuter vos suites de tests. ## Configurer device.json Le `device.json` fichier contient des informations sur les appareils sur lesquels les tests sont exécutés (par exemple, adresse IP, informations de connexion, système d'exploitation et architecture du processeur). Les testeurs peuvent fournir ces informations à l'aide du `device.json` fichier modèle suivant situé dans le `/configs/` dossier. ``` [ { "id": "", "sku": "", "features": [ { "name": "", "value": "", "configs": [ { "name": "", "value": "" } ], } ], "devices": [ { "id": "", "connectivity": { "protocol": "ssh | uart | docker", // ssh "ip": "", "port": , "auth": { "method": "pki | password", "credentials": { "user": "", // pki "privKeyPath": "/path/to/private/key", // password "password": "", } }, // uart "serialPort": "", // docker "containerId": "", "containerUser": "", } } ] } ] ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `id` ID alphanumérique défini par l'utilisateur qui identifie de façon unique un ensemble d'appareils appelé un *groupe d'appareils*. Le matériel doit être identique pour les appareils d'un même groupe. Lorsque vous exécutez une suite de tests, les appareils du groupe sont utilisés pour paralléliser la charge de travail. Plusieurs appareils sont utilisés pour exécuter différents tests. `sku` Valeur alphanumérique qui identifie de façon unique l'appareil que vous testez. Le SKU est utilisé pour suivre les appareils qualifiés. Si vous souhaitez mettre votre carte en vente dans le catalogue des AWS Partner appareils, le SKU que vous spécifiez ici doit correspondre au SKU que vous avez utilisé lors du processus de mise en vente. `features` Facultatif. Un tableau contenant les fonctions prises en charge de l'appareil. Les fonctionnalités de l'appareil sont des valeurs définies par l'utilisateur que vous configurez dans votre suite de tests. Vous devez fournir à vos testeurs des informations sur les noms et les valeurs des fonctionnalités à inclure dans le `device.json` fichier. Par exemple, si vous souhaitez tester un périphérique qui fonctionne comme un serveur MQTT pour d'autres appareils, vous pouvez configurer votre logique de test pour valider les niveaux pris en charge spécifiques pour une fonctionnalité nommée`MQTT_QOS`. Les testeurs fournissent le nom de cette fonctionnalité et définissent la valeur de la fonctionnalité en fonction des niveaux de QOS pris en charge par leur appareil. Vous pouvez récupérer les informations fournies depuis le [contexte IDT](idt-context.md) avec la `devicePool.features` requête ou depuis le [contexte de la machine à états](idt-state-machine.md#state-machine-context) avec la `pool.features` requête. `features.name` Nom de la fonctionnalité. `features.value` Les valeurs des fonctionnalités prises en charge. `features.configs` Paramètres de configuration, si nécessaire, pour la fonctionnalité. `features.config.name` Nom du paramètre de configuration. `features.config.value` Les valeurs de réglage prises en charge. `devices` Un ensemble d'appareils du pool à tester. Au moins un appareil est requis. `devices.id` Un identificateur unique défini par l'utilisateur pour l'appareil testé. `connectivity.protocol` Le protocole de communication utilisé pour communiquer avec cet appareil. Chaque appareil d'un pool doit utiliser le même protocole. Actuellement, les seules valeurs prises en charge sont `ssh` et `uart` pour les appareils physiques, ainsi que `docker` pour les conteneurs Docker. `connectivity.ip` L'adresse IP de l'appareil testé. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.port` Facultatif. Le numéro de port à utiliser pour les connexions SSH. La valeur par défaut est 22. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.auth` Informations d'authentification pour la connexion. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.auth.method` Méthode d'authentification utilisée pour accéder à un appareil sur le protocole de connectivité donné. Les valeurs prises en charge sont : + `pki` + `password` `connectivity.auth.credentials` Informations d'identification utilisées pour l'authentification. `connectivity.auth.credentials.password` Mot de passe utilisé pour se connecter à l'appareil à tester. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `password`. `connectivity.auth.credentials.privKeyPath` Chemin complet de la clé privée utilisée pour se connecter à l'appareil testé. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `pki`. `connectivity.auth.credentials.user` Nom d'utilisateur pour la connexion à l'appareil testé. `connectivity.serialPort` Facultatif. Port série auquel le périphérique est connecté. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `uart`. `connectivity.containerId` ID de conteneur ou nom du conteneur Docker en cours de test. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `docker`. `connectivity.containerUser` Facultatif. Le nom de l'utilisateur à l'intérieur du conteneur. La valeur par défaut est l'utilisateur indiqué dans le Dockerfile. La valeur par défaut est 22. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `docker`. Pour vérifier si les testeurs configurent la mauvaise connexion au périphérique pour un test, vous pouvez la récupérer dans le contexte `pool.Devices[0].Connectivity.Protocol` de la machine à états et la comparer à la valeur attendue dans un `Choice` état. Si un protocole incorrect est utilisé, imprimez un message en utilisant l'`LogMessage`état et passez à l'`Fail`état. Vous pouvez également utiliser un code de gestion des erreurs pour signaler un échec de test pour des types de périphériques incorrects. ## (Facultatif) Configurer userdata.json Le `userdata.json` fichier contient toutes les informations supplémentaires requises par une suite de tests mais qui ne sont pas spécifiées dans le `device.json` fichier. Le format de ce fichier dépend du [`userdata_scheme.json`fichier](idt-json-config.md#userdata-schema-json) défini dans la suite de tests. Si vous êtes rédacteur de tests, assurez-vous de fournir ces informations aux utilisateurs qui exécuteront les suites de tests que vous écrivez. ## (Facultatif) Configurer resource.json Le `resource.json` fichier contient des informations sur les périphériques qui seront utilisés comme périphériques de ressources. Les périphériques ressources sont des appareils nécessaires pour tester certaines fonctionnalités d'un périphérique testé. Par exemple, pour tester la capacité Bluetooth d'un appareil, vous pouvez utiliser un périphérique ressource pour vérifier si votre appareil peut s'y connecter correctement. Les périphériques de ressources sont facultatifs et vous pouvez avoir besoin d'autant de périphériques de ressources que nécessaire. En tant que rédacteur de test, vous utilisez le [fichier test.json](idt-json-config.md#test-json) pour définir les fonctionnalités du périphérique de ressources requises pour un test. Les testeurs utilisent ensuite le `resource.json` fichier pour fournir un pool de périphériques de ressources dotés des fonctionnalités requises. Assurez-vous de fournir ces informations aux utilisateurs qui exécuteront les suites de tests que vous écrivez. Les testeurs peuvent fournir ces informations à l'aide du `resource.json` fichier modèle suivant situé dans le `/configs/` dossier. ``` [ { "id": "", "features": [ { "name": "", "version": "", "jobSlots": } ], "devices": [ { "id": "", "connectivity": { "protocol": "ssh | uart | docker", // ssh "ip": "", "port": , "auth": { "method": "pki | password", "credentials": { "user": "", // pki "privKeyPath": "/path/to/private/key", // password "password": "", } }, // uart "serialPort": "", // docker "containerId": "", "containerUser": "", } } ] } ] ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : `id` ID alphanumérique défini par l'utilisateur qui identifie de façon unique un ensemble d'appareils appelé un *groupe d'appareils*. Le matériel doit être identique pour les appareils d'un même groupe. Lorsque vous exécutez une suite de tests, les appareils du groupe sont utilisés pour paralléliser la charge de travail. Plusieurs appareils sont utilisés pour exécuter différents tests. `features` Facultatif. Un tableau contenant les fonctions prises en charge de l'appareil. Les informations requises dans ce champ sont définies dans les [fichiers test.json](idt-json-config.md#test-json) de la suite de tests et déterminent les tests à exécuter et la manière de les exécuter. Si la suite de tests ne nécessite aucune fonctionnalité, ce champ n'est pas obligatoire. `features.name` Nom de la fonctionnalité. `features.version` La version fonctionnelle. `features.jobSlots` Paramètre pour indiquer le nombre de tests pouvant utiliser simultanément l'appareil. La valeur par défaut est `1`. `devices` Un ensemble d'appareils du pool à tester. Au moins un appareil est requis. `devices.id` Un identificateur unique défini par l'utilisateur pour l'appareil testé. `connectivity.protocol` Le protocole de communication utilisé pour communiquer avec cet appareil. Chaque appareil d'un pool doit utiliser le même protocole. Actuellement, les seules valeurs prises en charge sont `ssh` et `uart` pour les appareils physiques, ainsi que `docker` pour les conteneurs Docker. `connectivity.ip` L'adresse IP de l'appareil testé. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.port` Facultatif. Le numéro de port à utiliser pour les connexions SSH. La valeur par défaut est 22. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.auth` Informations d'authentification pour la connexion. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`. `connectivity.auth.method` Méthode d'authentification utilisée pour accéder à un appareil sur le protocole de connectivité donné. Les valeurs prises en charge sont : + `pki` + `password` `connectivity.auth.credentials` Informations d'identification utilisées pour l'authentification. `connectivity.auth.credentials.password` Mot de passe utilisé pour se connecter à l'appareil à tester. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `password`. `connectivity.auth.credentials.privKeyPath` Chemin complet de la clé privée utilisée pour se connecter à l'appareil testé. Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `pki`. `connectivity.auth.credentials.user` Nom d'utilisateur pour la connexion à l'appareil testé. `connectivity.serialPort` Facultatif. Port série auquel le périphérique est connecté. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `uart`. `connectivity.containerId` ID de conteneur ou nom du conteneur Docker en cours de test. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `docker`. `connectivity.containerUser` Facultatif. Le nom de l'utilisateur à l'intérieur du conteneur. La valeur par défaut est l'utilisateur indiqué dans le Dockerfile. La valeur par défaut est 22. Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `docker`. ## (Facultatif) Configurer config.json Le `config.json` fichier contient des informations de configuration pour IDT. En règle générale, les testeurs n'ont pas besoin de modifier ce fichier, sauf pour fournir leurs informations AWS d'identification utilisateur pour IDT et, éventuellement, pour une AWS région. Si des AWS informations d'identification avec les autorisations requises sont fournies, AWS IoT Device Tester collecte et soumet des statistiques d'utilisation à AWS. Il s'agit d'une fonctionnalité opt-in utilisée pour améliorer la fonctionnalité IDT. Pour de plus amples informations, veuillez consulter [Métriques d'utilisation de l'IDT](idt-usage-metrics.md). Les testeurs peuvent configurer leurs AWS informations d'identification de l'une des manières suivantes : + **Fichier d'informations d'identification** IDT utilise le même fichier d'informations d'identification que l' AWS CLI. Pour de plus amples informations, veuillez consulter [Fichiers de configuration et d'informations d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html). L'emplacement du fichier d'informations d'identification varie en fonction du système d'exploitation que vous utilisez : + macOS, Linux : `~/.aws/credentials` + Windows: `C:\Users\UserName\.aws\credentials` + **Variables d'environnement** Les variables d'environnement sont des variables gérées par le système d'exploitation et utilisées par les commandes du système. Les variables définies au cours d'une session SSH ne sont pas disponibles après la fermeture de cette session. IDT peut utiliser les variables d'`AWS_SECRET_ACCESS_KEY`environnement `AWS_ACCESS_KEY_ID` et pour stocker les informations d'identification AWS Pour définir ces variables sous Linux, macOS ou Unix, utilisez **export**: ``` export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= ``` Pour définir ces variables sous Windows, utilisez **set** : ``` set AWS_ACCESS_KEY_ID= set AWS_SECRET_ACCESS_KEY= ``` Pour configurer les AWS informations d'identification pour IDT, les testeurs modifient la `auth` section du `config.json` fichier situé dans le `/configs/` dossier. ``` { "log": { "location": "logs" }, "configFiles": { "root": "configs", "device": "configs/device.json" }, "testPath": "tests", "reportPath": "results", "awsRegion": "", "auth": { "method": "file | environment", "credentials": { "profile": "" } } } ] ``` Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici : **Note** Tous les chemins de ce fichier sont définis par rapport à**. `log.location` Le chemin d'accès au dossier des journaux dans le**. `configFiles.root` Le chemin d'accès au dossier contenant les fichiers de configuration. `configFiles.device` Le chemin d'accès au `device.json` fichier. `testPath` Le chemin d'accès au dossier contenant les suites de tests. `reportPath` Le chemin d'accès au dossier qui contiendra les résultats des tests une fois qu'IDT aura exécuté une suite de tests. `awsRegion` Facultatif. La AWS région que les suites de tests utiliseront. Si ce paramètre n'est pas défini, les suites de tests utiliseront la région par défaut spécifiée dans chaque suite de tests. `auth.method` Méthode utilisée par IDT pour récupérer les AWS informations d'identification. Les valeurs prises en charge sont `file` la récupération des informations d'identification à partir d'un fichier d'informations d'identification et la récupération `environment` des informations d'identification à l'aide de variables d'environnement. `auth.credentials.profile` Le profil d'informations d'identification à utiliser à partir du fichier d'informations d'identification. Cette propriété s'applique uniquement si `auth.method` est défini sur `file`. # Déboguer et exécuter des suites de tests personnalisées Une fois la [configuration requise](set-config-custom.md) définie, IDT peut exécuter votre suite de tests. Le temps d'exécution de la suite de tests complète dépend du matériel et de la composition de la suite de tests. À titre de référence, il faut environ 30 minutes pour terminer la suite complète de tests de AWS IoT Greengrass qualification sur un Raspberry Pi 3B. Lorsque vous écrivez votre suite de tests, vous pouvez utiliser IDT pour exécuter la suite de tests en mode débogage afin de vérifier votre code avant de l'exécuter ou de le fournir aux testeurs. ## Exécutez IDT en mode debug Étant donné que les suites de tests dépendent de l'IDT pour interagir avec les appareils, fournir le contexte et recevoir les résultats, vous ne pouvez pas simplement déboguer vos suites de tests dans un IDE sans aucune interaction IDT. Pour ce faire, la CLI IDT fournit la `debug-test-suite` commande qui vous permet d'exécuter IDT en mode de débogage. Exécutez la commande suivante pour afficher les options disponibles pour `debug-test-suite` : ``` devicetester_[linux | mac | win_x86-64] debug-test-suite -h ``` Lorsque vous exécutez IDT en mode débogage, IDT ne lance pas réellement la suite de tests ni n'exécute la machine d'état ; il interagit plutôt avec votre IDE pour répondre aux demandes émanant de la suite de tests exécutée dans l'IDE et imprime les journaux sur la console. L'IDT n'expire pas et attend de sortir jusqu'à ce qu'il soit interrompu manuellement. En mode débogage, IDT n'exécute pas non plus la machine d'état et ne génère aucun fichier de rapport. Pour déboguer votre suite de tests, vous devez utiliser votre IDE pour fournir certaines informations que IDT obtient généralement à partir des fichiers JSON de configuration. Assurez-vous de fournir les informations suivantes : + Variables d'environnement et arguments pour chaque test. IDT ne lira pas ces informations depuis `test.json` ou`suite.json`. + Arguments pour sélectionner les périphériques de ressources. IDT ne lira pas ces informations depuis`test.json`. Pour déboguer vos suites de tests, procédez comme suit : 1. Créez les fichiers de configuration des paramètres nécessaires à l'exécution de la suite de tests. Par exemple, si votre suite de tests nécessite le `device.json``resource.json`, et`user data.json`, assurez-vous de tous les configurer selon vos besoins. 1. Exécutez la commande suivante pour placer IDT en mode de débogage et sélectionnez les appareils nécessaires pour exécuter le test. ``` devicetester_[linux | mac | win_x86-64] debug-test-suite [options] ``` Après avoir exécuté cette commande, IDT attend les demandes de la suite de tests, puis y répond. IDT génère également les variables d'environnement requises pour le traitement des dossiers pour le SDK client IDT. 1. Dans votre IDE, utilisez la `debug` configuration `run` or pour effectuer les opérations suivantes : 1. Définissez les valeurs des variables d'environnement générées par IDT. 1. Définissez la valeur de toutes les variables ou arguments d'environnement que vous avez spécifiés dans votre `suite.json` fichier `test.json` and. 1. Définissez les points d'arrêt selon vos besoins. 1. Exécutez la suite de tests dans votre IDE. Vous pouvez déboguer et réexécuter la suite de tests autant de fois que nécessaire. Le délai d'expiration de l'IDT n'est pas dépassé en mode débogage. 1. Une fois le débogage terminé, interrompez IDT pour quitter le mode de débogage. ## Commandes IDT CLI pour exécuter des tests La section suivante décrit les commandes de la CLI IDT : ------ #### [ IDT v4.0.0 ] `help` Répertorie les informations sur la commande spécifiée. `list-groups` Répertorie les groupes dans une suite de tests donnée. `list-suites` Répertorie les suites de tests disponibles. `list-supported-products` Répertorie les produits pris en charge pour votre version d'IDT, en l'occurrence AWS IoT Greengrass les versions, et les versions de la suite de tests de AWS IoT Greengrass qualification disponibles pour la version IDT actuelle. `list-test-cases` Répertorie les cas de tests d'un groupe de tests donné. L'option suivante est prise en charge : + `group-id`. Le groupe de test à rechercher. Cette option est obligatoire et doit spécifier un groupe unique. `run-suite` Exécute une suite de tests sur un groupe d'appareils. Les options les plus fréquemment utilisées sont les suivantes : + `suite-id`. Version de la suite de tests à exécuter. Si celle-ci n’est pas spécifiée, IDT utilise la dernière version dans le dossier `tests`. + `group-id`. Les groupes de test à exécuter, sous forme de liste séparée par des virgules. Si cette option n'est pas spécifiée, IDT exécute tous les groupes de tests de la suite de tests. + `test-id`. Les cas de test à exécuter, sous forme de liste séparée par des virgules. Lorsqu'il est spécifié, `group-id` doit spécifier un seul groupe. + `pool-id`. Le pool d'appareils à tester. Les testeurs doivent spécifier un pool s'ils ont plusieurs pools d'appareils définis dans votre `device.json` fichier. + `timeout-multiplier`. Configure IDT pour modifier le délai d'exécution du test spécifié dans le `test.json` fichier pour un test avec un multiplicateur défini par l'utilisateur. + `stop-on-first-failure`. Configure IDT pour arrêter l'exécution lors du premier échec. Cette option doit être utilisée avec `group-id` pour déboguer les groupes de tests spécifiés. + `userdata`. Définit le fichier contenant les informations de données utilisateur requises pour exécuter la suite de tests. Cela n'est obligatoire que s'`userdataRequired`il est défini sur true dans le `suite.json` fichier de la suite de tests. Pour de plus amples informations sur les options `run-suite`, utilisez l' option `help` suivante : ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` `debug-test-suite` Exécutez la suite de tests en mode debug. Pour de plus amples informations, veuillez consulter [Exécutez IDT en mode debug](#idt-debug-mode). ------ # Consulter les résultats et les journaux des tests IDT Cette section décrit le format dans lequel IDT génère les journaux de console et les rapports de test. ## Format des messages de console AWS IoT Device Tester utilise un format standard pour imprimer des messages sur la console lorsqu'il démarre une suite de tests. L'extrait suivant montre un exemple de message de console généré par IDT. ``` time="2000-01-02T03:04:05-07:00" level=info msg=Using suite: MyTestSuite_1.0.0 executionId=9a52f362-1227-11eb-86c9-8c8590419f30 ``` La plupart des messages de console contiennent les champs suivants : `time` Un horodatage ISO 8601 complet pour l'événement enregistré. `level` Le niveau du message pour l'événement enregistré. Généralement, le niveau du message enregistré est l'un `info` des suivants `warn` : ou`error`. IDT émet un `panic` message `fatal` OR s'il rencontre un événement attendu qui entraîne sa fermeture anticipée. `msg` Le message enregistré. `executionId` Chaîne d'identification unique pour le processus IDT en cours. Cet identifiant est utilisé pour différencier les essais IDT individuels. Les messages de console générés à partir d'une suite de tests fournissent des informations supplémentaires sur le périphérique testé, ainsi que sur la suite de tests, le groupe de test et les scénarios de test exécutés par IDT. L'extrait suivant montre un exemple de message de console généré à partir d'une suite de tests. ``` time="2000-01-02T03:04:05-07:00" level=info msg=Hello world! suiteId=MyTestSuite groupId=myTestGroup testCaseId=myTestCase deviceId=my-device executionId=9a52f362-1227-11eb-86c9-8c8590419f30 ``` La partie spécifique à la suite de tests du message de console contient les champs suivants : `suiteId` Nom de la suite de tests en cours d'exécution. `groupId` ID du groupe de test en cours d'exécution. `testCaseId` ID du scénario de test en cours d'exécution. `deviceId` Identifiant de l'appareil testé utilisé par le scénario de test actuel. Pour imprimer un résumé de test sur la console lorsqu'un IDT a terminé d'exécuter un test, vous devez inclure un [`Report`état](idt-state-machine.md#state-report) dans votre machine à états. Le résumé des tests contient des informations sur la suite de tests, les résultats des tests pour chaque groupe exécuté, ainsi que l'emplacement des journaux et des fichiers de rapport générés. L'exemple suivant montre un message récapitulatif du test. ``` ========== Test Summary ========== Execution Time: 5m00s Tests Completed: 4 Tests Passed: 3 Tests Failed: 1 Tests Skipped: 0 ---------------------------------- Test Groups: GroupA: PASSED GroupB: FAILED ---------------------------------- Failed Tests: Group Name: GroupB Test Name: TestB1 Reason: Something bad happened ---------------------------------- Path to IoT Device Tester Report: /path/to/awsiotdevicetester_report.xml Path to Test Execution Logs: /path/to/logs Path to Aggregated JUnit Report: /path/to/MyTestSuite_Report.xml ``` ## AWS IoT Schéma de rapport du Device Tester `awsiotdevicetester_report.xml`est un rapport signé qui contient les informations suivantes : + La version IDT. + La version de la suite de tests. + Signature du rapport et clé utilisées pour signer le rapport. + Le SKU de l'appareil et le nom du pool d'appareils spécifiés dans le `device.json` fichier. + La version du produit et les fonctionnalités de l'appareil testées. + Le récapitulatif des résultats des tests. Ces informations sont les mêmes que celles contenues dans le `suite-name_report.xml` fichier. ``` idt-version test-suite-version signature keyname execution-id start-time end-time product-name product-version device-sku device-name ssh | uart | docker ``` Le fichier `awsiotdevicetester_report.xml` contient une balise `` qui contient des informations relatives au produit testé et les caractéristiques du produit qui ont été validées par une suite de tests.Attributs utilisés dans la balise `` `name` Nom du produit testé. `version` Version du produit testé. `features` Caractéristiques validées. Les fonctionnalités marquées comme `required` étant requises pour que la suite de tests valide le dispositif. L'extrait de code suivant montre comment ces informations apparaissent dans le fichier `awsiotdevicetester_report.xml`. ``` ``` Les fonctionnalités marquées comme ne `optional` sont pas requises pour la validation. Les extraits suivants illustrent des fonctions facultatives. ``` 
 ``` ## Schéma de rapport de la suite de tests Le `suite-name_Result.xml` rapport est au [format JUnit XML](https://llg.cubic.org/docs/junit/). Vous pouvez intégrer des plateformes de déploiement/d'intégration continues tels que [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo), etc. Le rapport contient un résumé global des résultats des tests. ``` reason reason reason ``` La section du rapport dans le `awsiotdevicetester_report.xml` ou `suite-name_report.xml` répertorie les tests effectués et les résultats. La première balise XML `` contient le résumé de l'exécution des tests. Par exemple : ``` ```Attributs utilisés dans la balise `` `name` Nom de la suite de tests. `time` Le temps, en secondes, nécessaire pour exécuter la suite de tests. `tests` Nombre de tests exécutés. `failures` Nombre de tests exécutés mais dont le résultat n'est pas probant. `errors` Nombre de tests qu'IDT n'a pas pu exécuter. `disabled` Cet attribut n'est pas utilisé et peut être ignoré. En cas d'erreurs ou d'échecs de tests, vous pouvez identifier les tests concernés à l'aide des balises XML ``. Les balises XML `` au sein de la balise `` montrent le récapitulatif des résultats d'un groupe de tests. Par exemple : ``` ``` Le format est similaire à la balise ``, mais avec un attribut appelé `skipped` qui n'est pas utilisé et qui ne peut pas être ignoré. Chaque balise XML `` inclut des balises `` pour chaque test exécuté pour un groupe de tests. Par exemple : ``` > ```Attributs utilisés dans la balise `` `name` Nom du test. `attempts` Nombre de fois où IDT a exécuté le test. Lorsqu'un test échoue ou qu'une erreur se produit, les balises `` ou `` sont ajoutées à la balise `` avec des informations relatives au dépannage. Par exemple : ``` Reason for the test failure Reason for the test execution error ``` # Métriques d'utilisation de l'IDT Si vous fournissez des AWS informations d'identification avec les autorisations requises, AWS IoT Device Tester collecte et envoie des statistiques d'utilisation à AWS. Il s'agit d'une fonctionnalité opt-in utilisée pour améliorer la fonctionnalité IDT. IDT collecte des informations telles que les suivantes : + L' Compte AWS ID utilisé pour exécuter IDT + Les commandes IDT CLI utilisées pour exécuter des tests + La suite de tests exécutée + Les suites de tests dans le ** dossier + Le nombre d'appareils configurés dans le pool de périphériques + Noms des scénarios de test et durées d'exécution + Informations sur les résultats des tests, par exemple si les tests ont été réussis, ont échoué, ont rencontré des erreurs ou ont été ignorés + Caractéristiques du produit testées + Comportement de sortie IDT, tel que les sorties inattendues ou anticipées Toutes les informations envoyées par IDT sont également enregistrées dans un `metrics.log` fichier du `/results//` dossier. Vous pouvez consulter le fichier journal pour voir les informations collectées lors d'un test. Ce fichier est généré uniquement si vous choisissez de collecter des statistiques d'utilisation. Pour désactiver la collecte des métriques, il n'est pas nécessaire de prendre d'autres mesures. Ne stockez simplement pas vos AWS informations d'identification et, si vous en avez, ne configurez pas le fichier `config.jso` n pour y accéder. AWS ## Configurez vos AWS informations d'identification Si vous n'en avez pas déjà un Compte AWS, vous devez en [créer un](#idt-metrics-aws-account). Si vous en avez déjà un Compte AWS, il vous suffit de [configurer les autorisations requises](#idt-metrics-permissions) pour votre compte qui permettent à IDT d'envoyer des statistiques d'utilisation en votre AWS nom. ### Étape 1 : Création d'un Compte AWS Dans cette étape, créez et configurez un Compte AWS. Si vous en avez déjà un Compte AWS, passez directement à[Étape 2 : Configurer les autorisations pour IDT](#idt-metrics-permissions). #### Inscrivez-vous pour un Compte AWS Si vous n'en avez pas Compte AWS, procédez comme suit pour en créer un. **Pour vous inscrire à un Compte AWS** 1. Ouvrez l'[https://portal.aws.amazon.com/billing/inscription.](https://portal.aws.amazon.com/billing/signup) 1. Suivez les instructions en ligne. Dans le cadre de la procédure d’inscription, vous recevrez un appel téléphonique ou un SMS et vous saisirez un code de vérification en utilisant le clavier numérique du téléphone. Lorsque vous vous inscrivez à un Compte AWS, un *Utilisateur racine d'un compte AWS*est créé. Par défaut, seul l’utilisateur racine a accès à l’ensemble des Services AWS et des ressources de ce compte. La meilleure pratique de sécurité consiste à attribuer un accès administratif à un utilisateur, et à utiliser uniquement l’utilisateur racine pour effectuer les [tâches nécessitant un accès utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks). AWS vous envoie un e-mail de confirmation une fois le processus d'inscription terminé. À tout moment, vous pouvez consulter l'activité actuelle de votre compte et le gérer en accédant à [https://aws.amazon.com/](https://aws.amazon.com/)et en choisissant **Mon compte**. #### Création d’un utilisateur doté d’un accès administratif Après vous être inscrit à un Compte AWS, sécurisez Utilisateur racine d'un compte AWS AWS IAM Identity Center, activez et créez un utilisateur administratif afin de ne pas utiliser l'utilisateur root pour les tâches quotidiennes. **Sécurisez votre Utilisateur racine d'un compte AWS** 1. Connectez-vous en [AWS Management Console](https://console.aws.amazon.com/)tant que propriétaire du compte en choisissant **Utilisateur root** et en saisissant votre adresse Compte AWS e-mail. Sur la page suivante, saisissez votre mot de passe. Pour obtenir de l’aide pour vous connecter en utilisant l’utilisateur racine, consultez [Connexion en tant qu’utilisateur racine](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) dans le *Guide de l’utilisateur Connexion à AWS *. 1. Activez l’authentification multifactorielle (MFA) pour votre utilisateur racine. Pour obtenir des instructions, voir [Activer un périphérique MFA virtuel pour votre utilisateur Compte AWS root (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) dans le guide de l'utilisateur *IAM*. **Création d’un utilisateur doté d’un accès administratif** 1. Activez IAM Identity Center. Pour obtenir des instructions, consultez [Activation d’ AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *. 1. Dans IAM Identity Center, octroyez un accès administratif à un utilisateur. Pour un didacticiel sur l'utilisation du Répertoire IAM Identity Center comme source d'identité, voir [Configurer l'accès utilisateur par défaut Répertoire IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) dans le *Guide de AWS IAM Identity Center l'utilisateur*. **Connexion en tant qu’utilisateur doté d’un accès administratif** + Pour vous connecter avec votre utilisateur IAM Identity Center, utilisez l’URL de connexion qui a été envoyée à votre adresse e-mail lorsque vous avez créé l’utilisateur IAM Identity Center. Pour obtenir de l'aide pour vous connecter en utilisant un utilisateur d'IAM Identity Center, consultez la section [Connexion au portail AWS d'accès](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) dans le *guide de l'Connexion à AWS utilisateur*. **Attribution d’un accès à d’autres utilisateurs** 1. Dans IAM Identity Center, créez un ensemble d’autorisations qui respecte la bonne pratique consistant à appliquer les autorisations de moindre privilège. Pour obtenir des instructions, consultez [Création d’un ensemble d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *. 1. Attribuez des utilisateurs à un groupe, puis attribuez un accès par authentification unique au groupe. Pour obtenir des instructions, consultez [Ajout de groupes](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *. ### Étape 2 : Configurer les autorisations pour IDT Au cours de cette étape, configurez les autorisations utilisées par IDT pour exécuter des tests et collecter les données d'utilisation de l'IDT. Vous pouvez utiliser le AWS Management Console ou AWS Command Line Interface (AWS CLI) pour créer une stratégie IAM et un utilisateur pour IDT, puis associer des politiques à l'utilisateur. + [Pour configurer des autorisations pour IDT (console)](#idt-metrics-permissions-console) + [Pour configurer des autorisations pour IDT (AWS CLI)](#idt-metrics-permissions-cli) **Pour configurer des autorisations pour IDT (console)** Procédez comme suit pour utiliser la console afin de configurer les autorisations pour IDT pour AWS IoT Greengrass. 1. Connectez-vous à la [console IAM](https://console.aws.amazon.com/iam). 1. Créez une stratégie gérée par le client qui accorde des autorisations de création des rôles avec des autorisations spécifiques. 1. Dans le volet de navigation, sélectionnez **Politiques**, puis **Créer une politique**. 1. Sur l'onglet **JSON**, remplacez le contenu de l'espace réservé par la stratégie suivante. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot-device-tester:SendMetrics" ], "Resource": "*" } ] } ``` ------ 1. Choisissez **Suivant : Balises**. 1. Choisissez **Suivant : Vérification**. 1. Pour **Nom**, saisissez **IDTUsageMetricsIAMPermissions**. Sous **Résumé**, vérifiez les autorisations accordées par votre stratégie. 1. Choisissez **Create Policy** (Créer une politique). 1. Créez un utilisateur IAM et associez-lui des autorisations. 1. Créez un utilisateur IAM. Suivez les étapes 1 à 5 de la section [Création d'utilisateurs IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) dans le guide de l'*utilisateur IAM*. Si vous avez déjà créé un utilisateur IAM, passez à l'étape suivante. 1. Associez les autorisations à votre utilisateur IAM : 1. Sur la page **Définir les autorisations**, choisissez **Joindre directement les politiques existantes**. 1. Recherchez la IAMPermissions politique de **IDTUsagemesures** que vous avez créée à l'étape précédente. Activez la case à cocher. 1. Choisissez **Suivant : Balises**. 1. Choisissez **Suivant : Réviser** pour afficher un résumé de vos choix. 1. Choisissez **Create user (Créer un utilisateur)**. 1. Pour afficher les clés d'accès de l'utilisateur (clé d'accès IDs et clés d'accès secrètes), choisissez **Afficher** à côté du mot de passe et de la clé d'accès. Pour enregistrer les clés d'accès, choisissez **Télécharger .csv**, puis enregistrez le fichier dans un emplacement sécurisé sur votre ordinateur. Vous utiliserez ces informations ultérieurement pour configurer votre fichier AWS d'informations d'identification.   **Pour configurer des autorisations pour IDT (AWS CLI)** Suivez ces étapes pour utiliser le AWS CLI afin de configurer les autorisations pour IDT pour AWS IoT Greengrass. Si vous avez déjà configuré des autorisations dans la console, passez à [Configurez votre appareil pour exécuter des tests IDT](device-config-setup.md) ou [Facultatif : Configuration de votre conteneur Docker pour IDT pour AWS IoT Greengrass](docker-config-setup.md). 1. Sur votre ordinateur, installez et configurez le AWS CLI s'il n'est pas déjà installé. Suivez les étapes décrites AWS CLI dans [la section Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) du *guide de AWS Command Line Interface l'utilisateur*. **Note** AWS CLI Il s'agit d'un outil open source que vous pouvez utiliser pour interagir avec les AWS services à partir de votre shell de ligne de commande. 1. Créez la politique gérée par le client suivante qui accorde des autorisations pour gérer l'IDT et AWS IoT Greengrass les rôles. ------ #### [ Linux, macOS, or Unix ] ``` aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot-device-tester:SendMetrics" ], "Resource": "*" } ] }' ``` ------ #### [ Windows command prompt ] ``` aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{\"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": [\"iot-device-tester:SendMetrics\"], \"Resource": \"*\"}]}' ``` **Note** Cette étape inclut un exemple d'invite de commande Windows car elle utilise une syntaxe JSON différente de celle des commandes de terminal Linux, macOS ou Unix. ------ 1. Créez un utilisateur IAM et associez les autorisations requises par IDT pour. AWS IoT Greengrass 1. Créez un utilisateur IAM. ``` aws iam create-user --user-name user-name ``` 1. Attachez la `IDTUsageMetricsIAMPermissions` politique que vous avez créée à votre utilisateur IAM. *user-name*Remplacez-le par votre nom d'utilisateur IAM et ** dans la commande par l'ID de votre Compte AWS. ``` aws iam attach-user-policy --user-name user-name --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions ``` 1. Créez une clé d'accès secrète pour l'utilisateur. ``` aws iam create-access-key --user-name user-name ``` Stockez la sortie dans un emplacement sécurisé. Vous utiliserez ces informations ultérieurement pour configurer votre fichier AWS d'informations d'identification. ## Fournir des AWS informations d'identification à IDT Pour autoriser IDT à accéder à vos AWS informations d'identification et à envoyer des statistiques AWS, procédez comme suit : 1. Stockez les AWS informations d'identification de votre utilisateur IAM sous forme de variables d'environnement ou dans un fichier d'informations d'identification : 1. Pour utiliser des variables d'environnement, exécutez la commande suivante : ``` AWS_ACCESS_KEY_ID=access-key AWS_SECRET_ACCESS_KEY=secret-access-key ``` 1. Pour utiliser le fichier d'informations d'identification, ajoutez les informations suivantes au `.aws/credentials file:` ``` [profile-name] aws_access_key_id=access-key aws_secret_access_key=secret-access-key ``` 1. Configurez la `auth` section du `config.json` fichier. Pour de plus amples informations, veuillez consulter [(Facultatif) Configurer config.json](set-config-custom.md#config-json-custom). # IDT pour le dépannage AWS IoT Greengrass IDT for AWS IoT Greengrass écrit ces erreurs à différents emplacements en fonction du type d'erreur. Les erreurs sont écrites dans la console, les fichiers journaux et les rapports de tests. ## Codes d’erreur Le tableau suivant répertorie les codes d'erreur générés par IDT pour AWS IoT Greengrass. | Code d’erreur | Nom du code d'erreur | Cause racine possible | Résolution des problèmes | | --- | --- | --- | --- | | 101 | InternalError | Une erreur interne s’est produite. | Vérifiez les journaux du répertoire `/results`. Si vous ne parvenez pas à résoudre le problème, contactez le [Support aux AWS développeurs](https://aws.amazon.com/premiumsupport/plans/developers/). | | 102 | TimeoutError | Le test ne peut pas être réalisé dans une plage de temps limitée. Ceci peut se produire si : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 103 | PlatformNotSupportError | Combinaison Système d'exploitation/Architecture incorrecte spécifiée dans `device.json`. | Remplacez votre configuration par l'une des combinaisons prises en charge : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) Pour de plus amples informations, veuillez consulter [Configurer device.json](set-config.md#device-config). | | 104 | VersionNotSupportError | La version du logiciel AWS IoT Greengrass Core n'est pas prise en charge par la version d'IDT que vous utilisez. | Utilisez la **device\$1tester\$1bin version** commande pour trouver la version prise en charge du logiciel AWS IoT Greengrass Core. Par exemple, si vous utilisez macOS, utilisez : **./devicetester\$1mac\$1x86\$164 version**. Pour trouver la version du logiciel AWS IoT Greengrass Core que vous utilisez, procédez comme suit : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) Vous pouvez tester une autre version du logiciel AWS IoT Greengrass Core. Pour de plus amples informations, veuillez consulter [Commencer avec AWS IoT Greengrass](gg-gs.md). | | 105 | LanguageNotSupportError | IDT supporte Python pour les AWS IoT Greengrass bibliothèques et SDKs uniquement. | Vérifiez les éléments suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 106 | ValidationError | Certains champs de `device.json` ou de `config.json` sont non valides. | Vérifiez le message d'erreur situé à droite du code d'erreur dans le rapport. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 107 | SSHConnectionÉchoué | La machine de test ne peut pas se connecter à l'appareil configuré. | Vérifiez que les champs suivants sont corrects dans votre fichier `device.json` : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) Pour de plus amples informations, veuillez consulter [Configurer device.json](set-config.md#device-config). | | 108 | RunCommandError | Un test n'a pas réussi à exécuter une commande sur l'appareil testé. | Vérifiez que l'accès racine est autorisé pour l'utilisateur configuré dans `device.json`. Un mot de passe est requis par certains appareils lors de l'exécution de commandes avec accès racine. Assurez-vous que l'accès racine est autorisé sans mot de passe. Pour de plus amples informations, veuillez consulter la documentation relative à votre appareil. Essayez d'exécuter manuellement la commande qui a échoué sur votre appareil pour vérifier si une erreur se produit. | | 109 | PermissionDeniedError | Aucun accès racine. | Définissez l'accès racine pour l'utilisateur configuré sur votre appareil. | | 110 | CreateFileError | Impossible de créer un fichier. | Vérifiez l'espace disque de votre appareil et les autorisations sur les répertoires. | | 111 | CreateDirError | Impossible de créer un répertoire. | Vérifiez l'espace disque de votre appareil et les autorisations sur les répertoires. | | 112 | InvalidPathError | Le chemin d'accès au logiciel AWS IoT Greengrass Core est incorrect. | Vérifiez que le chemin indiqué dans le message d'erreur est valide. Ne modifiez aucun fichier sous le répertoire `devicetester_greengrass_`. | | 113 | InvalidFileError | Un fichier n'est pas valide. | Vérifiez que le fichier indiqué dans le message d'erreur est valide. | | 114 | ReadFileError | Le fichier spécifié ne peut pas être lu. | Vérifiez les paramètres suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) Si vous procédez aux tests sur Mac OS, augmentez le nombre limite de fichiers ouverts. La limite par défaut est 256, ce qui est suffisant pour les tests. | | 115 | FileNotFoundError | Un fichier requis est introuvable. | Vérifiez les paramètres suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 116 | OpenFileFailed | Impossible d'ouvrir le fichier spécifié. | Vérifiez les paramètres suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) Si vous procédez aux tests sur Mac OS, augmentez le nombre limite de fichiers ouverts. La limite par défaut est 256, ce qui est suffisant pour les tests. | | 117 | WriteFileFailed | Échec de l'écriture du fichier (peut être l'appareil testé ou la machine de test). | Vérifiez que le répertoire indiqué dans le message d'erreur existe et que vous disposez d'une autorisation d'écriture. | | 118 | FileCleanUpError | Pendant le test, le fichier ou le répertoire spécifié n'a pas pu être supprimé, ou le fichier spécifié n'a pas pu être démonté de l'appareil distant. | Si le fichier binaire est toujours en cours d'exécution, il est possible que le fichier soit verrouillé. Terminez le processus et supprimez le fichier spécifié. | | 119 | InvalidInputError | Configuration non valide. | Vérifiez que votre fichier `suite.json` est valide. | | 120 | InvalidCredentialError | AWS Informations d'identification non valides. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 121 | AWSSessionErreur | Impossible de créer une AWS session. | Cette erreur peut se produire si les AWS informations d'identification ne sont pas valides ou si la connexion Internet est instable. Essayez d'utiliser le AWS CLI pour appeler une opération d' AWS API. | | 122 | AWSApiCallError | Une erreur d' AWS API s'est produite. | Cette erreur peut être due à un problème de réseau. Vérifiez votre réseau avant de relancer le groupe de tests. | | 123 | IpNotExistError | L'adresse IP ne figure pas dans les informations de connectivité. | Vérifiez votre connexion Internet. Vous pouvez utiliser la AWS IoT Greengrass console pour vérifier les informations de connectivité relatives à l'élément AWS IoT Greengrass principal utilisé par le test. Si 10 points de terminaison figurent dans les informations de connectivité, vous pouvez en supprimer certains ou tous les supprimer, puis relancer le test. Pour de plus amples informations, veuillez consulter [Informations de connectivité](https://docs.aws.amazon.com/cli/latest/reference/greengrass/get-connectivity-info.html). | | 124 | OTAJobNotCompleteError | Une tâche OTA ne s'est pas terminée. | Vérifiez votre connexion réseau et réexécutez le groupe de tests OTA. | | 125 | CreateGreengrassServiceRoleError | L'une des erreurs suivantes s'est produite : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) | Configurez le rôle AWS IoT Greengrass de service. Pour de plus amples informations, veuillez consulter [Rôle de service Greengrass](service-role.md). | | 126 | DependenciesNotPresentError | Une ou plusieurs dépendances requises pour le test spécifique ne sont pas présentes sur l'appareil. | Consultez le journal de test pour voir quelles dépendances manquent sur votre appareil : `/results//logs/`. | | 127 | Non valide HSMConfiguration | La configuration HSM/PKCS fournie est incorrecte. | Dans votre fichier `device.json`, fournissez la configuration requise pour interagir avec HSM en utilisant PKCS\$111. | | 128 | OTAJobNotSuccededError | La tâche OTA n'a pas abouti. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 129 | NoConnectivityError | L'agent hôte ne parvient pas à se connecter à Internet. | Vérifiez vos paramètres de connexion réseau et de pare-feu. Réessayez le groupe de test une fois le problème de connectivité résolu. | | 130 | NoPermissionError | L'utilisateur IAM pour lequel vous exécutez IDT n'est AWS IoT Greengrass pas autorisé à créer les AWS ressources requises pour exécuter IDT. | Veuillez consulter [Modèle de stratégie d'autorisations](https://docs.aws.amazon.com/greengrass/latest/developerguide/policy-template.html) pour connaître le modèle de stratégie qui accorde les autorisations requises pour exécuter IDT pour AWS IoT Greengrass. | | 131 | LeftoverAgentExistError | Votre appareil exécute AWS IoT Greengrass des processus lorsque vous essayez de démarrer IDT pour AWS IoT Greengrass. | Assurez-vous qu'aucun démon Greengrass n'est en cours d'exécution sur votre appareil. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/idt-troubleshooting.html) Si vous utilisez une installation existante AWS IoT Greengrass configurée pour démarrer automatiquement après le redémarrage, vous devez arrêter le démon après le redémarrage et avant d'exécuter la suite de tests. | | 132 | DeviceTimeOffsetError | L'heure de l'appareil est incorrecte. | Réglez votre appareil sur l'heure correcte. | | 133 | Non valide MLConfiguration | La configuration ML fournie est incorrecte. | Dans votre fichier `device.json`, indiquez la configuration requise pour exécuter les tests d'inférence ML. Pour de plus amples informations, veuillez consulter [Facultatif : Configuration de votre appareil pour la qualification ML](idt-ml-qualification.md). | ## Résolution des erreurs liées à l'IDT AWS IoT Greengrass Lorsque vous utilisez IDT, vous devez mettre en place les fichiers de configuration appropriés avant d'exécuter IDT pour. AWS IoT Greengrass Si vous obtenez des erreurs d'analyse et de configuration, la première étape consiste à localiser et à utiliser un modèle de configuration approprié pour votre environnement. Si le problème persiste, consultez les processus de débogage suivants. **Topics** + [ ### Où puis-je rechercher les erreurs ? ](#where-to-look) + [ ### Erreurs d'analyse ](#parse-error) + [ ### Erreur liée à un paramètre obligatoire manquant ](#param-missing) + [ ### Erreur indiquant l'impossibilité de démarrer le test ](#could-not-start-test) + [ ### Erreur d'absence d'autorisation d’accès à la ressource ](#not-authorized-to-access-resource) + [ ### Erreurs de type « Autorisation refusée » ](#pwd-sudo) + [ ### Erreurs de connexion SSH ](#ssh-connect-errors) + [ ### Erreurs de délai d'attente ](#test-timeout) + [ ### Erreurs liées à des commandes introuvables lors des tests ](#cmd-not-found) + [ ### Exception de sécurité sur macOS ](#macos-notarization-exception) ### Où puis-je rechercher les erreurs ? Les erreurs de haut niveau sont affichées sur la console pendant l'exécution et un récapitulatif des tests ayant échoué avec indication de l'erreur s'affiche lorsque tous les tests sont terminés. `awsiotdevicetester_report.xml` contient un récapitulatif de toutes les erreurs qui provoquaient l'échec d'un test. Les fichiers journaux pour chaque série de tests sont stockés dans un répertoire dont le nom comporte un UUID relatif à l'exécution du test, affiché sur la console pendant la série de tests. Le répertoire des journaux de test est situé dans `/results//logs/`. Ce répertoire contient les fichiers suivants, qui sont utiles pour le débogage. | Fichier | Description | | --- | --- | | test\$1manager.log | Contient tous les journaux qui ont été écrits dans la console lors de l'exécution du test. Un récapitulatif des résultats est situé à la fin de ce fichier, et comprend une liste des tests qui ont échoué. Les journaux des erreurs et des avertissements de ce fichier peuvent vous donner des informations sur les défaillances. | | \$1\$1.log | Journaux détaillés pour le test spécifique. | | \$1ggc\$1logs.tar.gz | Une collection compressée de tous les journaux générés par le démon AWS IoT Greengrass principal pendant le test. Pour plus d'informations, consultez [Dépannage AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-troubleshooting.html). | | \$1ota\$1logs.tar.gz | Collection compressée de journaux générés par l'agent AWS IoT Greengrass OTA pendant le test. Pour les tests OTA uniquement. | | \$1basic\$1assertion\$1publisher\$1ggad\$1logs.tar.gz | Collection compressée de journaux générés par l'appareil de l'éditeur AWS IoT pendant le test. | | \$1basic\$1assertion\$1subscriber\$1ggad\$1logs.tar.gz | Ensemble compressé de journaux générés par l'appareil de l'abonné AWS IoT pendant le test. | ### Erreurs d'analyse Parfois, une faute de frappe dans une configuration JSON peut entraîner des erreurs d'analyse. La plupart du temps, le problème est lié à l'absence d'une virgule, d'une apostrophe ou d'un crochet dans le fichier JSON. IDT effectue la validation JSON et imprime les informations de débogage. Il imprime la ligne dans laquelle l'erreur s'est produite, le numéro de ligne et le numéro de colonne de l'erreur de syntaxe. Ces informations devraient être suffisantes pour vous aider à corriger l'erreur, mais si vous ne parvenez toujours pas à la localiser, vous pouvez effectuer la validation manuellement dans votre IDE, un éditeur de texte tel qu'Atom ou Sublime, ou via un outil en ligne tel que JSONLint. ### Erreur liée à un paramètre obligatoire manquant Les fichiers de configuration peuvent être modifiés pour refléter les nouvelles fonctions ajoutées régulièrement à IDT. L'utilisation d'un ancien fichier de configuration peut corrompre votre configuration. Si tel est le cas, le fichier `.log` sous `/results//logs` répertorie explicitement tous les paramètres manquants. IDT vérifie également les schémas de votre fichier de configuration JSON pour s'assurer que la dernière version prise en charge a bien été utilisée. ### Erreur indiquant l'impossibilité de démarrer le test Vous pouvez rencontrer des erreurs qui renvoient à une défaillance lors du démarrage du test. Il y a plusieurs causes possibles. Par conséquent, procédez de la façon suivante : + Assurez-vous que le nom du groupe que vous avez inclus dans votre commande d'exécution existe réellement. Le nom du groupe est référencé directement à partir du fichier `device.json`. + Assurez-vous que les appareils du groupe ont des paramètres de configuration corrects. ### Erreur d'absence d'autorisation d’accès à la ressource Vous pouvez voir le message d’erreur ` is not authorized to access this resource` dans la sortie du terminal ou dans le fichier `test_manager.log` sous `/results//logs`. Pour résoudre ce problème, attachez la stratégie gérée `AWSIoTDeviceTesterForGreengrassFullAccess` à votre utilisateur de test. Pour de plus amples informations, veuillez consulter [Créez et configurez un Compte AWS](dev-tst-prereqs.md#config-aws-account-for-idt). ### Erreurs de type « Autorisation refusée » IDT effectue des opérations sur différents répertoires et fichiers d'un appareil testé. Certaines de ces opérations nécessitent un accès racine. Pour automatiser ces opérations, IDT doit être en mesure d'exécuter des commandes avec la commande sudo sans avoir à saisir un mot de passe. Suivez les étapes ci-après pour autoriser l'accès sudo sans saisie de mot de passe. **Note** `user` et `username` font référence à l'utilisateur SSH utilisé par IDT pour accéder à l'appareil testé. 1. Utilisez **sudo usermod -aG sudo **** pour ajouter l'utilisateur SSH au groupe sudo. 1. Déconnectez-vous, puis reconnectez-vous pour que les modifications entrent en vigueur. 1. Ouvrez le fichier `/etc/sudoers`, puis ajoutez la ligne suivante à la fin du fichier : ` ALL=(ALL) NOPASSWD: ALL` **Note** En tant que bonne pratique, nous vous recommandons d'utiliser **sudo visudo** lorsque vous modifiez `/etc/sudoers`. ### Erreurs de connexion SSH Lorsqu'IDT ne parvient pas à se connecter à un appareil testé, les échecs de connexion sont consignés dans `/results//logs/.log`. Les messages d'échec SSH apparaissent en haut de ce fichier journal, car la connexion à un appareil testé est l'une des premières opérations effectuées par IDT. La plupart des configurations Windows utilisent l'application de TTy terminal Pu pour se connecter aux hôtes Linux. Cette application nécessite que les fichiers de clé privée PEM standard soient convertis dans un format propriétaire Windows appelé PPK. Lorsqu'IDT est configuré dans votre fichier `device.json`, utilisez les fichiers PEM uniquement. Si vous utilisez un fichier PPK, IDT ne peut pas créer de connexion SSH avec le AWS IoT Greengrass périphérique et ne peut pas exécuter de tests. ### Erreurs de délai d'attente Vous pouvez augmenter le délai d'attente pour chaque test en spécifiant un multiplicateur de délai d'attente, qui sera appliqué à la valeur par défaut du délai d'attente de chaque test. Toute valeur configurée pour cet indicateur doit être supérieure ou égale à 1.0. Pour utiliser le multiplicateur de délai d'attente, utilisez l'indicateur `--timeout-multiplier` lors de l'exécution de tests. Par exemple : ``` ./devicetester_linux run-suite --suite-id GGQ_1.0.0 --pool-id DevicePool1 --timeout-multiplier 2.5 ``` Pour de plus amples informations, exécutez `run-suite --help`. ### Erreurs liées à des commandes introuvables lors des tests Vous avez besoin d'une ancienne version de la bibliothèque OpenSSL (libssl1.0.0) pour exécuter des tests sur des appareils. AWS IoT Greengrass La plupart des distributions Linux récentes utilisent libssl 1.0.2 ou version ultérieure (v1.1.0). Par exemple, sur un Raspberry Pi, exécutez les commandes suivantes pour installer la version requise de libssl : 1. ``` wget http://ftp.us.debian.org/debian/pool/main/o/openssl/libssl1.0.0_1.0.2l-1~bpo8+1_armhf.deb ``` 1. ``` sudo dpkg -i libssl1.0.0_1.0.2l-1~bpo8+1_armhf.deb ``` ### Exception de sécurité sur macOS Lorsque vous exécutez IDT sur une machine hôte qui utilise macOS 10.15, le ticket de notarisation pour IDT n'est pas correctement détecté et son exécution est bloquée. Pour exécuter IDT, vous devez accorder une exception de sécurité à l'`devicetester_mac_x86-64`exécutable. **Pour accorder une exception de sécurité à l'exécutable IDT** 1. Lancez **les préférences système** depuis le menu Apple. 1. Choisissez **Sécurité et confidentialité**, puis dans l'onglet **Général**, cliquez sur l'icône représentant un cadenas pour modifier les paramètres de sécurité. 1. Recherchez le message `"devicetester_mac_x86-64" was blocked from use because it is not from an identified developer.` et choisissez **Autoriser quand même**. 1. Acceptez l'avertissement de sécurité. Si vous avez des questions concernant la politique d'assistance d'IDT, contactez [AWS le support client](https://aws.amazon.com/contact-us/). # Politique de support pour AWS IoT Device Tester pour AWS IoT Greengrass V1 AWS IoT Device Tester (IDT) pour AWS IoT Greengrass est un framework de test téléchargeable qui vous permet de valider et de [qualifier](https://aws.amazon.com/partners/dqp/) vos AWS IoT Greengrass appareils en vue de leur inclusion dans le [catalogue des AWS Partner appareils](https://devices.amazonaws.com/). Nous vous recommandons d'utiliser la version la plus récente AWS IoT Greengrass d'IDT pour tester ou qualifier vos appareils. Pour plus d'informations, consultez la section [Versions prises en charge d'IDT pour AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html) dans le *manuel du AWS IoT Greengrass Version 2 développeur*. Vous pouvez également utiliser l'une des versions prises en charge AWS IoT Greengrass d'IDT pour tester ou qualifier vos appareils. Bien que vous puissiez continuer à utiliser des [versions non prises en charge d'IDT](dev-test-versions.md#idt-unsupported-versions), ces versions ne reçoivent ni corrections de bogues ni mises à jour. **Important** Depuis le 4 avril 2022, AWS IoT Device Tester (IDT) AWS IoT Greengrass V1 ne génère plus de rapports de qualification signés. Vous ne pouvez plus qualifier de nouveaux AWS IoT Greengrass V1 appareils pour les répertorier dans le [catalogue des AWS Partner appareils](https://devices.amazonaws.com/) dans le cadre du [programme de qualification des AWS appareils](https://aws.amazon.com/partners/programs/dqp/). Bien que vous ne puissiez pas qualifier les appareils Greengrass V1, vous pouvez continuer à utiliser IDT AWS IoT Greengrass V1 pour tester vos appareils Greengrass V1. Nous vous recommandons d'utiliser [IDT pour qualifier et AWS IoT Greengrass V2 répertorier les](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) appareils Greengrass dans [AWS Partner le](https://devices.amazonaws.com/) catalogue des appareils. Si vous avez des questions sur la politique de support, contactez [le support client AWS](https://aws.amazon.com/contact-us/).