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 AWS IoT Device Tester pour la AWS IoT Greengrass V2
AWS IoT Device Tester (IDT) est un framework de test téléchargeable qui vous permet de valider les appareils IoT. Vous pouvez utiliser IDT AWS IoT Greengrass pour exécuter la suite de AWS IoT Greengrass qualification et créer et exécuter des suites de tests personnalisées pour vos 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 AWS IoT Device Tester for AWS IoT Greengrass V2 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 déployer des composants et les mettre à niveau.
Si vous souhaitez ajouter votre matériel au catalogue des AWS Partner appareils, exécutez la suite de AWS IoT Greengrass qualification pour générer des rapports de test auxquels vous pouvez les soumettre AWS IoT. Pour de plus amples informations, veuillez consulter [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
![\[Vue d'ensemble de la façon dont le AWS IoT Device Tester for AWS IoT Greengrass V2 vérifie que le logiciel AWS IoT Greengrass Core s'exécute sur votre matériel et peut communiquer avec le AWS Cloud.\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/images/devicetester_gg.png)
IDT for AWS IoT Greengrass V2 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 test est l'ensemble de tests individuels liés à une fonctionnalité particulière, telle que les déploiements de composants.
Pour de plus amples informations, veuillez consulter [Utiliser IDT pour exécuter la suite de AWS IoT Greengrass qualifications](idt-greengrass-qualification.md).
## Suites de tests personnalisées
À partir de IDT v4.0.1, IDT pour AWS IoT Greengrass V2 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 for AWS IoT Greengrass V2
Cette rubrique répertorie les versions prises en charge d'IDT pour AWS IoT Greengrass V2. À titre de bonne pratique, nous vous recommandons d'utiliser la dernière version d'IDT pour AWS IoT Greengrass V2 qui prend en charge votre version cible de la AWS IoT Greengrass V2. Les nouvelles versions de AWS IoT Greengrass peuvent vous obliger à télécharger une nouvelle version d'IDT pour AWS IoT Greengrass V2. Vous recevez une notification lorsque vous lancez un test si IDT pour AWS IoT Greengrass V2 n'est pas compatible avec la version AWS IoT Greengrass que vous utilisez.
En téléchargeant le logiciel, vous acceptez le [contrat AWS IoT Device Tester de licence](https://docs.aws.amazon.com/greengrass/v2/developerguide/idt-license.html).
**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.
## Dernière version IDT pour V2 AWS IoT Greengrass
Vous pouvez utiliser cette version d'IDT pour AWS IoT Greengrass V2 avec la AWS IoT Greengrass version répertoriée ici.
**IDT v4.9.4 pour AWS IoT Greengrass**
AWS IoT Greengrass Versions prises en charge :
+ [Greengrass Nucleus](greengrass-nucleus-component.md) v2.12.0, v2.11.0, v2.10.0 et v2.9.5
Téléchargements du logiciel IDT :
+ [IDT v4.9.4 avec suite GGV2 de tests Q\$12.5.4 pour Linux](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_linux.zip)
+ [IDT v4.9.4 avec suite GGV2 de tests Q\$12.5.4 pour macOS](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_mac.zip)
+ [IDT v4.9.4 avec suite GGV2 de tests Q\$12.5.4 pour Windows](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_win.zip)
Notes de mise à jour :
+ Permet la validation et la qualification des appareils exécutant les versions 2.12.0, 2.11.0, 2.10.0 et 2.9.5 du logiciel AWS IoT Greengrass Core.
+ Supprime le gestionnaire de flux et les groupes de tests d'apprentissage automatique.
Remarques supplémentaires :
+ Si votre appareil utilise un HSM et que vous utilisez nucleus 2.10.x, migrez vers Greengrass nucleus version 2.11.0 ou ultérieure.
Versions de suite de tests :
`GGV2Q_2.5.4`
+ Publié le 03/05/2020
## Versions IDT antérieures pour AWS IoT Greengrass
Les versions antérieures suivantes d'IDT pour AWS IoT Greengrass V2 sont également prises en charge.
**IDT v4.9.3 pour AWS IoT Greengrass**
AWS IoT Greengrass Versions prises en charge :
+ [Greengrass Nucleus](greengrass-nucleus-component.md) v2.12.0, v2.11.0, v2.10.0 et v2.9.5
Téléchargements du logiciel IDT :
+ [IDT v4.9.3 avec suite GGV2 de tests Q\$12.5.3 pour Linux](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.3_testsuite_2.5.3_linux.zip)
+ [IDT v4.9.3 avec suite GGV2 de tests Q\$12.5.3 pour macOS](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.3_testsuite_2.5.3_mac.zip)
+ [IDT v4.9.3 avec suite GGV2 de tests Q\$12.5.3 pour Windows](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.3_testsuite_2.5.3_win.zip)
Notes de mise à jour :
+ Résout un problème lors des tests de composants lors du test d'un périphérique Linux à partir d'un hôte Windows ou vice versa.
+ Supprime le `localcomponent` scénario de test du groupe de `component` test. Ce cas de test n'est plus requis pour la qualification.
Remarques supplémentaires :
+ Si votre appareil utilise un HSM et que vous utilisez nucleus 2.10.x, migrez vers Greengrass nucleus version 2.11.0 ou ultérieure.
Versions de suite de tests :
`GGV2Q_2.5.3`
+ Publié le 2024.04.05
## Versions non prises en charge de AWS IoT Device Tester for V2 AWS IoT Greengrass
Cette rubrique répertorie les versions non prises en charge d'IDT pour AWS IoT Greengrass V2. 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 AWS IoT Device Tester pour AWS IoT Greengrass](idt-support-policy.md).
**IDT v4.9.2 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Résout un problème d'échec de la suite de tests Lambda en raison de l'obsolescence de Java 8.
Versions de suite de tests :
`GGV2Q_2.5.2`
+ Publié le 2024.03.18
**IDT v4.9.1 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant les versions 2.12.0, 2.11.0, 2.10.0 et 2.9.5 du logiciel AWS IoT Greengrass Core.
+ Correctifs de bogues mineurs.
Versions de suite de tests :
`GGV2Q_2.5.1`
+ Publié le 2023.10.05
**IDT v4.7.0 pour AWS IoT Greengrass**
AWS IoT Greengrass Versions prises en charge :
+ [Greengrass Nucleus](greengrass-nucleus-component.md) v2.11.0, v2.10.0 et v2.9.5
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant les versions 2.11.0, 2.10.0 et 2.9.5 du logiciel AWS IoT Greengrass Core.
+ Permet de stocker les valeurs des données utilisateur IDT dans le AWS Systems Manager Parameter Store et de les récupérer dans la configuration à l'aide de la syntaxe des espaces réservés.
+ Correctifs de bogues mineurs.
Versions de suite de tests :
`GGV2Q_2.5.0`
+ Publié le 13 décembre 2020
**IDT v4.5.11 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant les versions 2.9.1, 2.9.0, 2.8.1, 2.8.0, 2.7.0 et 2.6.0 du logiciel AWS IoT Greengrass Core.
+ Permet de tester PreInstalled Greengrass sur un appareil principal.
+ Correctifs de bogues mineurs.
Versions de suite de tests :
`GGV2Q_2.4.1`
+ Publié le 2022.10.13
**IDT v4.5.8 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant les versions 2.7.0, 2.6.0 et 2.5.6 du logiciel AWS IoT Greengrass Core.
+ Vous permet de tester avec PreInstalled Greengrass sur un appareil principal.
+ Correctifs de bogues mineurs.
Versions de suite de tests :
`GGV2Q_2.4.0`
+ Publié le 12/08/2022
**IDT v4.5.3 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant les versions 2.7.0, 2.6.0, 2.5.6, 2.5.5, 2.5.4 et 2.5.3 du logiciel AWS IoT Greengrass Core.
+ Les mises à jour DockerApplicationManager testent pour utiliser une image docker basée sur l'ECR.
+ Correctifs de bogues mineurs.
Versions de suite de tests :
`GGV2Q_2.3.1`
+ Publié le 15 avril 2020
**IDT v4.5.1 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant le logiciel AWS IoT Greengrass Core v2.5.3.
+ Ajoute la prise en charge de la validation et de la qualification des appareils basés sur Linux qui utilisent un module de sécurité matériel (HSM) pour stocker la clé privée et le certificat utilisés par le logiciel Core. AWS IoT Greengrass
+ Implémente le nouvel orchestrateur de tests IDT pour configurer des suites de tests personnalisées. Pour de plus amples informations, veuillez consulter [Configuration de l'orchestrateur de test IDT](idt-test-orchestrator.md).
+ Corrections de bogues mineurs supplémentaires.
Versions de suite de tests :
`GGV2Q_2.3.0`
+ Publié le 2022.01.11
**IDT v4.4.1 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant le logiciel AWS IoT Greengrass Core v2.5.2.
+ Prend en charge l'utilisation d'un rôle IAM défini par l'utilisateur en tant que rôle d'échange de jetons que le périphérique testé suppose d'interagir avec AWS les ressources.
Vous pouvez spécifier le rôle IAM dans le [`userdata.json`fichier](set-config.md#userdata-config). Si vous spécifiez un rôle personnalisé, IDT utilise ce rôle au lieu de créer le rôle d'échange de jetons par défaut lors du test.
+ Corrections de bogues mineurs supplémentaires.
Versions de suite de tests :
`GGV2Q_2.2.1`
+ Publié le 12 décembre 2021
**IDT v4.4.0 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant le logiciel AWS IoT Greengrass Core v2.5.0.
+ Ajoute la prise en charge de la validation et de la qualification des appareils exécutant le logiciel AWS IoT Greengrass Core sous Windows.
+ Prend en charge l'utilisation de la validation par clé publique pour les connexions de périphériques Secure Shell (SSH).
+ Améliore la politique IAM relative aux autorisations IDT grâce aux meilleures pratiques de sécurité.
+ Corrections de bogues mineurs supplémentaires.
Versions de suite de tests :
`GGV2Q_2.1.0`
+ Publié le 2021.11.19
**IDT v4.2.0 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Inclut la prise en charge de la qualification des fonctionnalités suivantes sur les appareils exécutant le logiciel AWS IoT Greengrass Core v2.2.0 et versions ultérieures :
+ Docker : confirme que les appareils peuvent télécharger une image de conteneur Docker depuis Amazon Elastic Container Registry (Amazon ECR).
+ [Apprentissage automatique : vérifie que les appareils peuvent effectuer des inférences d'apprentissage automatique (ML) à l'aide des frameworks [Deep Learning Runtime](https://github.com/neo-ai/neo-ai-dlr) ou Lite ML. TensorFlow ](https://www.tensorflow.org/lite/guide/python)
+ Gestionnaire de flux : vérifie que les appareils peuvent télécharger, installer et exécuter le gestionnaire de flux. AWS IoT Greengrass
+ Vous permet de valider et de qualifier les appareils exécutant le logiciel AWS IoT Greengrass Core v2.4.0, v2.3.0, v2.2.0 et v2.1.0.
+ Regroupe les journaux de test pour chaque cas de test dans un ** dossier distinct au sein du `/results//logs/` répertoire.
+ Corrections de bogues mineurs supplémentaires.
Versions de suite de tests :
`GGV2Q_2.0.1`
+ Publié le 31 août 2021
**IDT v4.1.0 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant le logiciel AWS IoT Greengrass Core v2.3.0, v2.2.0, v2.1.0 et v2.0.5.
+ Améliore la `userdata.json` configuration en supprimant l'obligation de spécifier les `GreengrassCLIVersion` propriétés `GreengrassNucleusVersion` et.
+ Inclut la prise en charge de la qualification des fonctionnalités Lambda et MQTT pour le logiciel AWS IoT Greengrass Core v2.1.0 et versions ultérieures. Vous pouvez désormais utiliser IDT for AWS IoT Greengrass V2 pour valider que votre périphérique principal peut exécuter des fonctions Lambda et qu'il peut publier des sujets MQTT et s'y AWS IoT Core abonner.
+ Améliore les capacités de journalisation.
+ Corrections de bogues mineurs supplémentaires.
Versions de suite de tests :
`GGV2Q_1.1.1`
+ Publié le 2021.06.18
**IDT v4.0.2 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant le logiciel AWS IoT Greengrass Core v2.1.0.
+ Ajoute la prise en charge de la qualification des fonctionnalités Lambda et MQTT pour le logiciel AWS IoT Greengrass Core v2.1.0 et les versions ultérieures. Vous pouvez désormais utiliser IDT for AWS IoT Greengrass V2 pour valider que votre périphérique principal peut exécuter des fonctions Lambda et qu'il peut publier des sujets MQTT et s'y AWS IoT Core abonner.
+ Améliore les capacités de journalisation.
+ Corrections de bogues mineurs supplémentaires.
Versions de suite de tests :
`GGV2Q_1.1.1`
+ Publié le 2021.05.05
**IDT v4.0.1 pour AWS IoT Greengrass**
Notes de mise à jour :
+ Vous permet de valider et de qualifier les appareils exécutant le logiciel AWS IoT Greengrass version 2.
+ Vous permet de développer et d'exécuter vos suites de tests personnalisées à l'aide AWS IoT Device Tester de for 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. Sur macOS, 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#security-exception-macos).
Versions de suite de tests :
`GGV2Q_1.0.0`
+ Publié le 22 décembre 2020
+ La suite de tests exécute uniquement les tests requis pour la qualification, sauf si vous définissez la valeur correspondante `value` dans le `features` tableau sur`yes`.
# Télécharger IDT pour V2 AWS IoT Greengrass
Cette rubrique décrit les options de téléchargement AWS IoT Device Tester pour la AWS IoT Greengrass version 2. Vous pouvez utiliser l'un des liens de téléchargement de logiciels suivants ou suivre les instructions pour télécharger IDT par programmation.
**Topics**
+ [Télécharger IDT manuellement](#idt-download-options)
+ [Téléchargez IDT par programmation](#idt-programmatic-download-process)
En téléchargeant le logiciel, vous acceptez le [contrat AWS IoT Device Tester de licence](https://docs.aws.amazon.com/greengrass/v2/developerguide/idt-license.html).
**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.
## Télécharger IDT manuellement
Cette rubrique répertorie les versions prises en charge d'IDT pour AWS IoT Greengrass V2. À titre de bonne pratique, nous vous recommandons d'utiliser la dernière version d'IDT pour AWS IoT Greengrass V2 qui prend en charge votre version cible de la AWS IoT Greengrass V2. Les nouvelles versions de AWS IoT Greengrass peuvent vous obliger à télécharger une nouvelle version d'IDT pour AWS IoT Greengrass V2. Vous recevez une notification lorsque vous lancez un test si IDT pour AWS IoT Greengrass V2 n'est pas compatible avec la version AWS IoT Greengrass que vous utilisez.
**IDT v4.9.4 pour AWS IoT Greengrass**
AWS IoT Greengrass Versions prises en charge :
+ [Greengrass Nucleus](greengrass-nucleus-component.md) v2.12.0, v2.11.0, v2.10.0 et v2.9.5
Téléchargements du logiciel IDT :
+ [IDT v4.9.4 avec suite GGV2 de tests Q\$12.5.4 pour Linux](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_linux.zip)
+ [IDT v4.9.4 avec suite GGV2 de tests Q\$12.5.4 pour macOS](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_mac.zip)
+ [IDT v4.9.4 avec suite GGV2 de tests Q\$12.5.4 pour Windows](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_win.zip)
Notes de mise à jour :
+ Permet la validation et la qualification des appareils exécutant les versions 2.12.0, 2.11.0, 2.10.0 et 2.9.5 du logiciel AWS IoT Greengrass Core.
+ Supprime le gestionnaire de flux et les groupes de tests d'apprentissage automatique.
Remarques supplémentaires :
+ Si votre appareil utilise un HSM et que vous utilisez nucleus 2.10.x, migrez vers Greengrass nucleus version 2.11.0 ou ultérieure.
Versions de suite de tests :
`GGV2Q_2.5.4`
+ Publié le 03/05/2020
## Téléchargez IDT par programmation
IDT fournit une opération d'API que vous pouvez utiliser pour récupérer une URL où vous pouvez télécharger IDT par programmation. Vous pouvez également utiliser cette opération d'API pour vérifier si vous disposez de la dernière version d'IDT. Cette opération d'API possède le point de terminaison suivant.
```
https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt
```
Pour appeler cette opération d'API, vous devez être autorisé à effectuer l'**iot-device-tester:LatestIdt**action. Incluez votre AWS signature et `iot-device-tester` utilisez-la comme nom de service.
### Demande d'API
HostOs — Le système d'exploitation de la machine hôte. Sélectionnez parmi les options suivantes :
+ `mac`
+ `linux`
+ `windows`
TestSuiteType — Le type de suite de tests. Choisissez l'option suivante :
`GGV2`— IDT pour V2 AWS IoT Greengrass
ProductVersion
(Facultatif) La version du noyau Greengrass. Le service renvoie la dernière version compatible d'IDT pour cette version du noyau Greengrass. Si vous ne spécifiez pas cette option, le service renvoie la dernière version d'IDT.
### Réponse de l'API
La réponse de l'API est au format suivant. `DownloadURL`Inclut un fichier zip.
```
{
"Success": True or False,
"Message": Message,
"LatestBk": {
"Version": The version of the IDT binary,
"TestSuiteVersion": The version of the test suite,
"DownloadURL": The URL to download the IDT Bundle, valid for one hour
}
}
```
### Exemples
Vous pouvez vous référer aux exemples suivants pour télécharger IDT par programmation. Ces exemples utilisent des informations d'identification que vous stockez dans les variables d'`AWS_SECRET_ACCESS_KEY`environnement `AWS_ACCESS_KEY_ID` et. Pour suivre les meilleures pratiques de sécurité, ne stockez pas vos informations d'identification dans votre code.
**Example Exemple : téléchargement à l'aide de la version 7.75.0 ou ultérieure de cURL (Mac et Linux)**
Si vous utilisez la version 7.75.0 ou ultérieure de cURL, vous pouvez utiliser le `aws-sigv4` drapeau pour signer la demande d'API. Cet exemple utilise [jq](https://stedolan.github.io/jq/) pour analyser l'URL de téléchargement à partir de la réponse.
L'`aws-sigv4`indicateur nécessite que les paramètres de requête de la requête CURL GET soient dans l'ordre de **HostOs/ProductVersion/TestSuiteType** ou**HostOs/TestSuiteType**. Les commandes non conformes entraîneront une erreur lors de l'obtention de signatures non concordantes pour la chaîne canonique par l'API Gateway.
Si le paramètre facultatif **ProductVersion** est inclus, vous devez utiliser une version de produit prise en charge, comme indiqué dans [Versions prises en charge de AWS IoT Device Tester for AWS IoT Greengrass V2](dev-test-versions.md).
+ *us-west-2*Remplacez-le par votre Région AWS. Pour la liste des codes de région, voir [Points de terminaison régionaux](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ *linux*Remplacez-le par le système d'exploitation de votre machine hôte.
+ *2.5.3*Remplacez-le par votre version de AWS IoT Greengrass Nucleus.
```
url=$(curl --request GET "https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&ProductVersion=2.5.3&TestSuiteType=GGV2" \
--user $AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY \
--aws-sigv4 "aws:amz:us-west-2:iot-device-tester" \
| jq -r '.LatestBk["DownloadURL"]')
curl $url --output devicetester.zip
```
**Example Exemple : téléchargement à l'aide d'une version antérieure de cURL (Mac et Linux)**
Vous pouvez utiliser la commande cURL suivante avec une AWS signature que vous signez et calculez. Pour plus d'informations sur la façon de signer et de calculer une AWS signature, consultez [Signature des demandes AWS d'API](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html).
+ *linux*Remplacez-le par le système d'exploitation de votre machine hôte.
+ Remplacez *Timestamp* par la date et l'heure, par exemple**20220210T004606Z**.
+ Remplacez *Date* par la date, telle que**20220210**.
+ *AWSRegion*Remplacez-le par votre Région AWS. Pour la liste des codes de région, voir [Points de terminaison régionaux](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ *AWSSignature*Remplacez-le par la [AWS signature](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html) que vous générez.
```
curl --location --request GET 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&TestSuiteType=GGV2' \
--header 'X-Amz-Date: Timestamp \
--header 'Authorization: AWS4-HMAC-SHA256 Credential=$AWS_ACCESS_KEY_ID/Date/AWSRegion/iot-device-tester/aws4_request, SignedHeaders=host;x-amz-date, Signature=AWSSignature'
```
**Example Exemple : téléchargement à l'aide d'un script Python**
Cet exemple utilise la bibliothèque de [requêtes](https://pypi.org/project/requests/) Python. Cet exemple est adapté de l'exemple Python pour [signer une demande d' AWS API](https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html) dans la *référence AWS générale*.
+ Remplacez *us-west-2* par votre région. Pour la liste des codes de région, voir [Points de terminaison régionaux](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ *linux*Remplacez-le par le système d'exploitation de votre machine hôte.
```
# Copyright 2010-2022 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# This file is licensed under the Apache License, Version 2.0 (the "License").
# You may not use this file except in compliance with the License. A copy of the
#License is located at
#
# http://aws.amazon.com/apache2.0/
#
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
# OF ANY KIND, either express or implied. See the License for the specific
# language governing permissions and limitations under the License.
# See: http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html
# This version makes a GET request and passes the signature
# in the Authorization header.
import sys, os, base64, datetime, hashlib, hmac
import requests # pip install requests
# ************* REQUEST VALUES *************
method = 'GET'
service = 'iot-device-tester'
host = 'download.devicetester.iotdevicesecosystem.amazonaws.com'
region = 'us-west-2'
endpoint = 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt'
request_parameters = 'HostOs=linux&TestSuiteType=GGV2'
# Key derivation functions. See:
# http://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html#signature-v4-examples-python
def sign(key, msg):
return hmac.new(key, msg.encode('utf-8'), hashlib.sha256).digest()
def getSignatureKey(key, dateStamp, regionName, serviceName):
kDate = sign(('AWS4' + key).encode('utf-8'), dateStamp)
kRegion = sign(kDate, regionName)
kService = sign(kRegion, serviceName)
kSigning = sign(kService, 'aws4_request')
return kSigning
# Read AWS access key from env. variables or configuration file. Best practice is NOT
# to embed credentials in code.
access_key = os.environ.get('AWS_ACCESS_KEY_ID')
secret_key = os.environ.get('AWS_SECRET_ACCESS_KEY')
if access_key is None or secret_key is None:
print('No access key is available.')
sys.exit()
# Create a date for headers and the credential string
t = datetime.datetime.utcnow()
amzdate = t.strftime('%Y%m%dT%H%M%SZ')
datestamp = t.strftime('%Y%m%d') # Date w/o time, used in credential scope
# ************* TASK 1: CREATE A CANONICAL REQUEST *************
# http://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
# Step 1 is to define the verb (GET, POST, etc.)--already done.
# Step 2: Create canonical URI--the part of the URI from domain to query
# string (use '/' if no path)
canonical_uri = '/latestidt'
# Step 3: Create the canonical query string. In this example (a GET request),
# request parameters are in the query string. Query string values must
# be URL-encoded (space=%20). The parameters must be sorted by name.
# For this example, the query string is pre-formatted in the request_parameters variable.
canonical_querystring = request_parameters
# Step 4: Create the canonical headers and signed headers. Header names
# must be trimmed and lowercase, and sorted in code point order from
# low to high. Note that there is a trailing \n.
canonical_headers = 'host:' + host + '\n' + 'x-amz-date:' + amzdate + '\n'
# Step 5: Create the list of signed headers. This lists the headers
# in the canonical_headers list, delimited with ";" and in alpha order.
# Note: The request can include any headers; canonical_headers and
# signed_headers lists those that you want to be included in the
# hash of the request. "Host" and "x-amz-date" are always required.
signed_headers = 'host;x-amz-date'
# Step 6: Create payload hash (hash of the request body content). For GET
# requests, the payload is an empty string ("").
payload_hash = hashlib.sha256(('').encode('utf-8')).hexdigest()
# Step 7: Combine elements to create canonical request
canonical_request = method + '\n' + canonical_uri + '\n' + canonical_querystring + '\n' + canonical_headers + '\n' + signed_headers + '\n' + payload_hash
# ************* TASK 2: CREATE THE STRING TO SIGN*************
# Match the algorithm to the hashing algorithm you use, either SHA-1 or
# SHA-256 (recommended)
algorithm = 'AWS4-HMAC-SHA256'
credential_scope = datestamp + '/' + region + '/' + service + '/' + 'aws4_request'
string_to_sign = algorithm + '\n' + amzdate + '\n' + credential_scope + '\n' + hashlib.sha256(canonical_request.encode('utf-8')).hexdigest()
# ************* TASK 3: CALCULATE THE SIGNATURE *************
# Create the signing key using the function defined above.
signing_key = getSignatureKey(secret_key, datestamp, region, service)
# Sign the string_to_sign using the signing_key
signature = hmac.new(signing_key, (string_to_sign).encode('utf-8'), hashlib.sha256).hexdigest()
# ************* TASK 4: ADD SIGNING INFORMATION TO THE REQUEST *************
# The signing information can be either in a query string value or in
# a header named Authorization. This code shows how to use a header.
# Create authorization header and add to request headers
authorization_header = algorithm + ' ' + 'Credential=' + access_key + '/' + credential_scope + ', ' + 'SignedHeaders=' + signed_headers + ', ' + 'Signature=' + signature
# The request can include any headers, but MUST include "host", "x-amz-date",
# and (for this scenario) "Authorization". "host" and "x-amz-date" must
# be included in the canonical_headers and signed_headers, as noted
# earlier. Order here is not significant.
# Python note: The 'host' header is added automatically by the Python 'requests' library.
headers = {'x-amz-date':amzdate, 'Authorization':authorization_header}
# ************* SEND THE REQUEST *************
request_url = endpoint + '?' + canonical_querystring
print('\nBEGIN REQUEST++++++++++++++++++++++++++++++++++++')
print('Request URL = ' + request_url)
response = requests.get(request_url, headers=headers)
print('\nRESPONSE++++++++++++++++++++++++++++++++++++')
print('Response code: %d\n' % response.status_code)
print(response.text)
download_url = response.json()["LatestBk"]["DownloadURL"]
r = requests.get(download_url)
open('devicetester.zip', 'wb').write(r.content)
```
# Utiliser IDT pour exécuter la suite de AWS IoT Greengrass qualifications
Vous pouvez utiliser AWS IoT Device Tester for AWS IoT Greengrass V2 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 déployer des composants et les mettre à niveau.
Outre les appareils de test, IDT for AWS IoT Greengrass V2 crée des ressources (par exemple, des AWS IoT objets, des groupes, etc.) dans votre Compte AWS corps afin de faciliter le processus de qualification.
Pour créer ces ressources, IDT for AWS IoT Greengrass V2 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 for AWS IoT Greengrass V2 pour exécuter la suite de AWS IoT Greengrass qualification, celle-ci exécute les étapes suivantes :
1. Chargement et validation des informations d'identification et de la configuration de votre appareil.
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ération de rapports de tests indiquant si votre carte a réussi les tests obligatoires pour la qualification.
## Versions de la suite de tests
IDT for AWS IoT Greengrass V2 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 test est l'ensemble de tests individuels liés à une fonctionnalité particulière, telle que les déploiements de composants.
Les suites de tests sont versionnées à l'aide d'un `major.minor.patch` format, par exemple`GGV2Q_1.0.0`. Lorsque vous téléchargez IDT, le package inclut la dernière version de la suite de qualification Greengrass.
**Important**
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. Pour de plus amples informations, veuillez consulter [Politique de support AWS IoT Device Tester pour AWS IoT Greengrass](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.
## Descriptions des groupes de tests
**Groupes de test requis pour la qualification du noyau**
Ces groupes de test sont nécessaires pour qualifier votre appareil AWS IoT Greengrass V2 pour le catalogue AWS Partner d'appareils.
Dépendances fondamentales
Vérifie que l'appareil répond à toutes les exigences logicielles et matérielles du logiciel AWS IoT Greengrass Core. Ce groupe de test inclut le cas de test suivant :
Version de Java
Vérifie que la version Java requise est installée sur l'appareil testé. AWS IoT Greengrass nécessite Java 8 ou une version ultérieure.
PreTest Validation
Vérifie que l'appareil répond à la configuration logicielle requise pour exécuter des tests.
+ Pour les appareils basés sur Linux, ce test vérifie si le périphérique peut exécuter les commandes Linux suivantes :
`chmod`, `cp`, `echo`, `grep`, `kill`, `ln`, `mkinfo`, `ps`, `rm`, `sh`, `uname`
+ Pour les appareils Windows, ce test vérifie si les logiciels Microsoft suivants sont installés sur l'appareil :
[Powershell](https://learn.microsoft.com/en-us/powershell/?view=powershell-7.1) [v5.1 ou version ultérieure, [.NET](https://learn.microsoft.com/en-us/dotnet/) v4.6.1 ou version ultérieure, [Visual C\$1\$1](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170) 2017 ou version ultérieure, utilitaire PsExec](https://learn.microsoft.com/en-us/sysinternals/downloads/psexec)
Vérificateur de version
Vérifie que la version AWS IoT Greengrass fournie est compatible avec la version de AWS IoT Device Tester que vous utilisez.
Composant
Vérifie que l'appareil peut déployer des composants et les mettre à niveau. Ce groupe de test comprend les tests suivants :
Composant cloud
Valide les capacités de l'appareil pour les composants du cloud.
Composant local
Valide la capacité de l'appareil pour les composants locaux.
Lambda
Ce test ne s'applique pas aux appareils Windows.
Vérifie que le périphérique peut déployer des composants de fonctions Lambda qui utilisent l'environnement d'exécution Java et que les fonctions Lambda peuvent AWS IoT Core utiliser des sujets MQTT comme sources d'événements pour les messages professionnels.
MQTT
Valide que l'appareil peut s'abonner et publier sur des sujets AWS IoT Core MQTT.
**Groupes de test facultatifs**
Ces groupes de test sont facultatifs et utilisés uniquement pour les appareils principaux Greengrass basés sur Linux éligibles. 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 Docker
Vérifie que l'appareil répond à toutes les dépendances techniques requises pour utiliser le composant Docker application manager () AWS`aws.greengrass.DockerApplicationManager` fourni.
Qualification du gestionnaire d'applications Docker
Vérifie que l'appareil peut télécharger une image de conteneur Docker depuis Amazon ECR.
Dépendances du Machine Learning
Le groupe de test optionnel d'apprentissage automatique n'est pris en charge que dans IDT v4.9.3.
Valide que l'appareil répond à toutes les dépendances techniques requises pour utiliser les composants d'apprentissage automatique (ML) AWS fournis.
Tests d'inférence pour le Machine Learning
Le groupe de test optionnel d'apprentissage automatique n'est pris en charge que dans IDT v4.9.3.
Valide que le périphérique peut effectuer une inférence ML à l'aide des frameworks [Deep Learning Runtime](https://github.com/neo-ai/neo-ai-dlr) et [TensorFlow Lite](https://www.tensorflow.org/lite/guide/python) ML.
Dépendances du Stream Manager
Le groupe de test optionnel du gestionnaire de flux n'est pris en charge que dans IDT v4.9.3.
Vérifie que l'appareil peut télécharger, installer et exécuter le [gestionnaire de AWS IoT Greengrass flux](manage-data-streams.md).
Intégration de sécurité matérielle (HSI)
Ce test est disponible dans IDT v4.9.3 et versions ultérieures pour les appareils basés sur Linux uniquement. AWS IoT Greengrass ne prend actuellement pas en charge l'intégration de la sécurité matérielle pour les appareils Windows.
Vérifie que le périphérique peut authentifier les connexions aux AWS IoT Greengrass services AWS IoT et à l'aide d'une clé privée et d'un certificat stockés dans un module de sécurité matériel (HSM). Ce test vérifie également que le [composant fournisseur PKCS \$111 AWS](pkcs11-provider-component.md) fourni peut s'interfacer avec le HSM à l'aide d'une bibliothèque PKCS \$111 fournie par le fournisseur. Pour de plus amples informations, veuillez consulter [Intégration de sécurité matérielle](hardware-security.md).
# 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) pour. AWS IoT Greengrass
## Téléchargez la dernière version de AWS IoT Device Tester for AWS IoT Greengrass
Téléchargez la [dernière version](idt-programmatic-download.md) d'IDT et extrayez le logiciel dans un emplacement (**) de votre système de fichiers où vous disposez d'autorisations de lecture/é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.
## Téléchargez le AWS IoT Greengrass logiciel
IDT for AWS IoT Greengrass V2 teste la compatibilité de votre appareil avec une version spécifique de AWS IoT Greengrass. Exécutez la commande suivante pour télécharger le logiciel AWS IoT Greengrass Core dans un fichier nommé`aws.greengrass.nucleus.zip`. *version*Remplacez-le par une [version de composant Nucleus prise en charge](dev-test-versions.md) pour votre version IDT.
------
#### [ Linux or Unix ]
```
curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-version.zip > aws.greengrass.nucleus.zip
```
------
#### [ Windows Command Prompt (CMD) ]
```
curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-version.zip > aws.greengrass.nucleus.zip
```
------
#### [ PowerShell ]
```
iwr -Uri https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-version.zip -OutFile aws.greengrass.nucleus.zip
```
------
Placez le `aws.greengrass.nucleus.zip` fichier téléchargé dans le `/products/` dossier.
**Note**
Ne placez pas plusieurs fichiers dans ce répertoire pour le même système d'exploitation et la même architecture.
## Créez et configurez un Compte AWS
Avant de pouvoir utiliser AWS IoT Device Tester la AWS IoT Greengrass version V2, vous devez effectuer les étapes suivantes :
1. [Configurez un Compte AWS.](#create-aws-account-for-idt) Si vous en avez déjà un Compte AWS, passez à l'étape 2.
1. [Configurez les autorisations pour IDT.](#configure-idt-permissions)
Ces autorisations de compte permettent à IDT d'accéder aux AWS services et de créer AWS des ressources, telles que AWS IoT des objets et AWS IoT Greengrass des composants, en votre nom.
Pour créer ces ressources, IDT for AWS IoT Greengrass V2 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 AWS gratuit](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 : Configurez un Compte AWS
Dans cette étape, créez et configurez un Compte AWS. Si vous disposez déjà d'un Compte AWS, passez directement à l'étape [Étape 2 : Configurer les autorisations pour IDT](#configure-idt-permissions).
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).
Afin de créer un utilisateur administrateur, choisissez l'une des options suivantes :
****
| Choisissez un moyen de gérer votre administrateur | À | En | Vous pouvez également |
| --- | --- | --- | --- |
| Dans IAM Identity Center (Recommandé) | Utiliser des informations d’identification à court terme pour accéder à AWS.C’est conforme aux bonnes pratiques en matière de sécurité. Pour plus d’informations sur les bonnes pratiques, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *Guide de l’utilisateur IAM*. | Suivant les instructions fournies dans [Mise en route](https://docs.aws.amazon.com//singlesignon/latest/userguide/getting-started.html) dans le Guide de l’utilisateur AWS IAM Identity Center . | Configurez l'accès par programmation en [configurant le AWS CLI à utiliser AWS IAM Identity Center](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-sso.html) dans le guide de l'AWS Command Line Interface utilisateur. |
| Dans IAM (Non recommandé) | Utiliser les informations d’identification à long terme pour accéder à AWS. | Suivant les instructions fournies dans [Création d’un utilisateur IAM pour l’accès d’urgence](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started-emergency-iam-user.html) dans le Guide de l’utilisateur IAM. | Configurer l’accès par programmation en suivant les instructions fournies dans [Gestion des clés d’accès pour les utilisateurs IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html) dans le Guide de l’utilisateur IAM. |
### Étape 2 : Configurer les autorisations pour IDT
Dans cette étape, configurez les autorisations utilisées par IDT pour AWS IoT Greengrass V2 pour exécuter des tests et collecter des données d'utilisation IDT. Vous pouvez utiliser le [AWS Management Console](#configure-idt-permissions-console)ou [AWS Command Line Interface (AWS CLI)](#configure-idt-permissions-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 de test pour IDT, passez directement à[Configurez votre appareil pour exécuter des tests IDT](device-config-setup.md).
#### Pour configurer des autorisations pour IDT (console)
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. Si vous ne l'utilisez pas PreInstalled, dans l'onglet **JSON**, remplacez le contenu de l'espace réservé par la politique suivante. Si vous utilisez PreInstalled, passez à l'étape suivante.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/idt-*",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
},
{
"Sid":"lambdaResources",
"Effect":"Allow",
"Action":[
"lambda:CreateFunction",
"lambda:PublishVersion",
"lambda:DeleteFunction",
"lambda:GetFunction"
],
"Resource":[
"arn:aws:lambda:*:*:function:idt-*"
]
},
{
"Sid":"iotResources",
"Effect":"Allow",
"Action":[
"iot:CreateThing",
"iot:DeleteThing",
"iot:DescribeThing",
"iot:CreateThingGroup",
"iot:DeleteThingGroup",
"iot:DescribeThingGroup",
"iot:AddThingToThingGroup",
"iot:RemoveThingFromThingGroup",
"iot:AttachThingPrincipal",
"iot:DetachThingPrincipal",
"iot:UpdateCertificate",
"iot:DeleteCertificate",
"iot:CreatePolicy",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"iot:GetPolicy",
"iot:Publish",
"iot:TagResource",
"iot:ListThingPrincipals",
"iot:ListAttachedPolicies",
"iot:ListTargetsForPolicy",
"iot:ListThingGroupsForThing",
"iot:ListThingsInThingGroup",
"iot:CreateJob",
"iot:DescribeJob",
"iot:DescribeJobExecution",
"iot:CancelJob"
],
"Resource":[
"arn:aws:iot:*:*:thing/idt-*",
"arn:aws:iot:*:*:thinggroup/idt-*",
"arn:aws:iot:*:*:policy/idt-*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:topic/idt-*",
"arn:aws:iot:*:*:job/*"
]
},
{
"Sid":"s3Resources",
"Effect":"Allow",
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:CreateBucket",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:DeleteBucket",
"s3:PutObjectTagging",
"s3:PutBucketTagging"
],
"Resource":"arn:aws:s3::*:idt-*"
},
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/idt-*",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid":"idtExecuteAndCollectMetrics",
"Effect":"Allow",
"Action":[
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource":"*"
},
{
"Sid":"genericResources",
"Effect":"Allow",
"Action":[
"greengrass:*",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"iot:ListThings",
"iot:DescribeEndpoint",
"iot:CreateKeysAndCertificate"
],
"Resource":"*"
},
{
"Sid":"iamResourcesUpdate",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:DeleteRole",
"iam:CreatePolicy",
"iam:DeletePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:TagRole",
"iam:TagPolicy",
"iam:GetPolicy",
"iam:ListAttachedRolePolicies",
"iam:ListEntitiesForPolicy"
],
"Resource":[
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:policy/idt-*"
]
}
]
}
```
1. Si vous utilisez PreInstalled, dans l'onglet **JSON**, remplacez le contenu de l'espace réservé par la politique suivante. Assurez-vous de :
+ Remplacez *thingName* et *thingGroup* dans l'`iotResources`instruction par le nom de l'objet et le groupe d'objets créés lors de l'installation de Greengrass sur votre appareil testé (DUT) pour ajouter des autorisations.
+ Remplacez le *passRole* et *roleAlias* dans l'`roleAliasResources`instruction et l'`passRoleForResources`instruction par les rôles créés lors de l'installation de Greengrass sur votre DUT.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/passRole",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
},
{
"Sid":"lambdaResources",
"Effect":"Allow",
"Action":[
"lambda:CreateFunction",
"lambda:PublishVersion",
"lambda:DeleteFunction",
"lambda:GetFunction"
],
"Resource":[
"arn:aws:lambda:*:*:function:idt-*"
]
},
{
"Sid":"iotResources",
"Effect":"Allow",
"Action":[
"iot:CreateThing",
"iot:DeleteThing",
"iot:DescribeThing",
"iot:CreateThingGroup",
"iot:DeleteThingGroup",
"iot:DescribeThingGroup",
"iot:AddThingToThingGroup",
"iot:RemoveThingFromThingGroup",
"iot:AttachThingPrincipal",
"iot:DetachThingPrincipal",
"iot:UpdateCertificate",
"iot:DeleteCertificate",
"iot:CreatePolicy",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"iot:GetPolicy",
"iot:Publish",
"iot:TagResource",
"iot:ListThingPrincipals",
"iot:ListAttachedPolicies",
"iot:ListTargetsForPolicy",
"iot:ListThingGroupsForThing",
"iot:ListThingsInThingGroup",
"iot:CreateJob",
"iot:DescribeJob",
"iot:DescribeJobExecution",
"iot:CancelJob"
],
"Resource":[
"arn:aws:iot:*:*:thing/thingName",
"arn:aws:iot:*:*:thinggroup/thingGroup",
"arn:aws:iot:*:*:policy/idt-*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:topic/idt-*",
"arn:aws:iot:*:*:job/*"
]
},
{
"Sid":"s3Resources",
"Effect":"Allow",
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:CreateBucket",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:DeleteBucket",
"s3:PutObjectTagging",
"s3:PutBucketTagging"
],
"Resource":"arn:aws:s3::*:idt-*"
},
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/roleAlias",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid":"idtExecuteAndCollectMetrics",
"Effect":"Allow",
"Action":[
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource":"*"
},
{
"Sid":"genericResources",
"Effect":"Allow",
"Action":[
"greengrass:*",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"iot:ListThings",
"iot:DescribeEndpoint",
"iot:CreateKeysAndCertificate"
],
"Resource":"*"
},
{
"Sid":"iamResourcesUpdate",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:DeleteRole",
"iam:CreatePolicy",
"iam:DeletePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:TagRole",
"iam:TagPolicy",
"iam:GetPolicy",
"iam:ListAttachedRolePolicies",
"iam:ListEntitiesForPolicy"
],
"Resource":[
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:policy/idt-*"
]
}
]
}
```
**Note**
Si vous souhaitez utiliser un rôle [IAM personnalisé comme rôle d'échange de jetons](set-config.md#custom-token-exchange-role-idt) pour votre appareil testé, assurez-vous de mettre à jour la `roleAliasResources` déclaration et la `passRoleForResources` déclaration de votre politique afin d'autoriser votre ressource de rôle IAM personnalisée.
1. Choisissez **Examiner une politique**.
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 **Attacher directement les stratégies existantes à l'utilisateur**.
1. Recherchez la **IDTGreengrassIAMPermissions**politique 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.
1. Étape suivante : Configurez votre [appareil physique](device-config-setup.md).
#### Pour configurer des autorisations pour IDT (AWS CLI)
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 .
1. Si vous ne l'utilisez pas PreInstalled, ouvrez un éditeur de texte et enregistrez le contenu de la politique ci-dessous dans un fichier JSON. Si vous utilisez PreInstalled, passez à l'étape suivante.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/idt-*",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
},
{
"Sid":"lambdaResources",
"Effect":"Allow",
"Action":[
"lambda:CreateFunction",
"lambda:PublishVersion",
"lambda:DeleteFunction",
"lambda:GetFunction"
],
"Resource":[
"arn:aws:lambda:*:*:function:idt-*"
]
},
{
"Sid":"iotResources",
"Effect":"Allow",
"Action":[
"iot:CreateThing",
"iot:DeleteThing",
"iot:DescribeThing",
"iot:CreateThingGroup",
"iot:DeleteThingGroup",
"iot:DescribeThingGroup",
"iot:AddThingToThingGroup",
"iot:RemoveThingFromThingGroup",
"iot:AttachThingPrincipal",
"iot:DetachThingPrincipal",
"iot:UpdateCertificate",
"iot:DeleteCertificate",
"iot:CreatePolicy",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"iot:GetPolicy",
"iot:Publish",
"iot:TagResource",
"iot:ListThingPrincipals",
"iot:ListAttachedPolicies",
"iot:ListTargetsForPolicy",
"iot:ListThingGroupsForThing",
"iot:ListThingsInThingGroup",
"iot:CreateJob",
"iot:DescribeJob",
"iot:DescribeJobExecution",
"iot:CancelJob"
],
"Resource":[
"arn:aws:iot:*:*:thing/idt-*",
"arn:aws:iot:*:*:thinggroup/idt-*",
"arn:aws:iot:*:*:policy/idt-*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:topic/idt-*",
"arn:aws:iot:*:*:job/*"
]
},
{
"Sid":"s3Resources",
"Effect":"Allow",
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:CreateBucket",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:DeleteBucket",
"s3:PutObjectTagging",
"s3:PutBucketTagging"
],
"Resource":"arn:aws:s3::*:idt-*"
},
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/idt-*",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid":"idtExecuteAndCollectMetrics",
"Effect":"Allow",
"Action":[
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource":"*"
},
{
"Sid":"genericResources",
"Effect":"Allow",
"Action":[
"greengrass:*",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"iot:ListThings",
"iot:DescribeEndpoint",
"iot:CreateKeysAndCertificate"
],
"Resource":"*"
},
{
"Sid":"iamResourcesUpdate",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:DeleteRole",
"iam:CreatePolicy",
"iam:DeletePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:TagRole",
"iam:TagPolicy",
"iam:GetPolicy",
"iam:ListAttachedRolePolicies",
"iam:ListEntitiesForPolicy"
],
"Resource":[
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:policy/idt-*"
]
}
]
}
```
1. Si vous en utilisez un PreInstalled, ouvrez un éditeur de texte et enregistrez le contenu de la politique ci-dessous dans un fichier JSON. Assurez-vous de :
+ Remplacez *thingName* et *thingGroup* dans la `iotResources` déclaration créée lors de l'installation de Greengrass sur votre appareil testé (DUT) pour ajouter des autorisations.
+ Remplacez le *passRole* et *roleAlias* dans l'`roleAliasResources`instruction et l'`passRoleForResources`instruction par les rôles créés lors de l'installation de Greengrass sur votre DUT.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/passRole",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
},
{
"Sid":"lambdaResources",
"Effect":"Allow",
"Action":[
"lambda:CreateFunction",
"lambda:PublishVersion",
"lambda:DeleteFunction",
"lambda:GetFunction"
],
"Resource":[
"arn:aws:lambda:*:*:function:idt-*"
]
},
{
"Sid":"iotResources",
"Effect":"Allow",
"Action":[
"iot:CreateThing",
"iot:DeleteThing",
"iot:DescribeThing",
"iot:CreateThingGroup",
"iot:DeleteThingGroup",
"iot:DescribeThingGroup",
"iot:AddThingToThingGroup",
"iot:RemoveThingFromThingGroup",
"iot:AttachThingPrincipal",
"iot:DetachThingPrincipal",
"iot:UpdateCertificate",
"iot:DeleteCertificate",
"iot:CreatePolicy",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"iot:GetPolicy",
"iot:Publish",
"iot:TagResource",
"iot:ListThingPrincipals",
"iot:ListAttachedPolicies",
"iot:ListTargetsForPolicy",
"iot:ListThingGroupsForThing",
"iot:ListThingsInThingGroup",
"iot:CreateJob",
"iot:DescribeJob",
"iot:DescribeJobExecution",
"iot:CancelJob"
],
"Resource":[
"arn:aws:iot:*:*:thing/thingName",
"arn:aws:iot:*:*:thinggroup/thingGroup",
"arn:aws:iot:*:*:policy/idt-*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:topic/idt-*",
"arn:aws:iot:*:*:job/*"
]
},
{
"Sid":"s3Resources",
"Effect":"Allow",
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:CreateBucket",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:DeleteBucket",
"s3:PutObjectTagging",
"s3:PutBucketTagging"
],
"Resource":"arn:aws:s3::*:idt-*"
},
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/roleAlias",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid":"idtExecuteAndCollectMetrics",
"Effect":"Allow",
"Action":[
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource":"*"
},
{
"Sid":"genericResources",
"Effect":"Allow",
"Action":[
"greengrass:*",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"iot:ListThings",
"iot:DescribeEndpoint",
"iot:CreateKeysAndCertificate"
],
"Resource":"*"
},
{
"Sid":"iamResourcesUpdate",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:DeleteRole",
"iam:CreatePolicy",
"iam:DeletePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:TagRole",
"iam:TagPolicy",
"iam:GetPolicy",
"iam:ListAttachedRolePolicies",
"iam:ListEntitiesForPolicy"
],
"Resource":[
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:policy/idt-*"
]
}
]
}
```
**Note**
Si vous souhaitez utiliser un rôle [IAM personnalisé comme rôle d'échange de jetons](set-config.md#custom-token-exchange-role-idt) pour votre appareil testé, assurez-vous de mettre à jour la `roleAliasResources` déclaration et la `passRoleForResources` déclaration de votre politique afin d'autoriser votre ressource de rôle IAM personnalisée.
1. Exécutez la commande suivante pour créer une politique gérée par le client nommée`IDTGreengrassIAMPermissions`. `policy.json`Remplacez-le par le chemin complet du fichier JSON que vous avez créé à l'étape précédente.
```
aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document file://policy.json
```
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. 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 IoT Device Tester autorisations
Les politiques suivantes décrivent AWS IoT Device Tester les autorisations.
AWS IoT Device Tester nécessite ces autorisations pour les fonctionnalités de vérification des versions et de mise à jour automatique.
+ `iot-device-tester:SupportedVersion`
Accorde AWS IoT Device Tester l'autorisation de récupérer la liste des produits pris en charge, des suites de tests et des versions IDT.
+ `iot-device-tester:LatestIdt`
Accorde AWS IoT Device Tester l'autorisation de récupérer la dernière version d'IDT disponible au téléchargement.
+ `iot-device-tester:CheckVersion`
Accorde AWS IoT Device Tester l'autorisation de vérifier la compatibilité des versions pour IDT, les suites de tests et les produits.
+ `iot-device-tester:DownloadTestSuite`
AWS IoT Device Tester Autorise le téléchargement des mises à jour des suites de tests.
AWS IoT Device Tester utilise également l'autorisation suivante pour les rapports de mesures facultatifs :
+ `iot-device-tester:SendMetrics`
Accorde l'autorisation AWS de collecter des statistiques sur l'utilisation AWS IoT Device Tester interne. Si cette autorisation est omise, ces statistiques ne seront pas collectées.
# Configurez votre appareil pour exécuter des tests IDT
Pour permettre à IDT d'exécuter des tests de qualification des appareils, vous devez configurer votre ordinateur hôte pour accéder à votre appareil et configurer les autorisations utilisateur sur votre appareil.
## Installation de Java sur l'ordinateur hôte
À partir de la version 4.2.0 d'IDT, les tests de qualification facultatifs AWS IoT Greengrass nécessitent l'exécution de Java.
Vous pouvez utiliser la version 8 ou supérieure de Java. Nous vous recommandons d'utiliser les versions de support à long terme d'[Amazon Corretto](https://aws.amazon.com/corretto/) [ou](https://openjdk.java.net/) d'OpenJDK. La version 8 ou supérieure est requise.
## 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`.
## Configuration des informations d'identification utilisateur pour les appareils Windows
Pour qualifier un appareil Windows, vous devez configurer les informations d'identification utilisateur dans le LocalSystem compte de l'appareil testé pour les utilisateurs suivants :
+ L'utilisateur Greengrass par défaut ()`ggc_user`.
+ L'utilisateur que vous utilisez pour vous connecter à l'appareil testé. Vous configurez cet utilisateur dans le [`device.json`fichier](set-config.md#device-config).
Vous devez créer chaque utilisateur du LocalSystem compte sur l'appareil testé, puis enregistrer le nom d'utilisateur et le mot de passe de l'utilisateur dans l'instance Credential Manager du LocalSystem compte.
**Pour configurer les utilisateurs sur les appareils Windows**
1. Ouvrez l'invite de commande Windows (`cmd.exe`) en tant qu'administrateur.
1. Créez les utilisateurs dans le LocalSystem compte sur l'appareil Windows. Exécutez la commande suivante pour chaque utilisateur que vous souhaitez créer. Pour l'utilisateur Greengrass par défaut, remplacez par*user-name*. `ggc_user` *password*Remplacez-le par un mot de passe sécurisé.
```
net user /add user-name password
```
1. Téléchargez et installez l'[PsExecutilitaire](https://docs.microsoft.com/en-us/sysinternals/downloads/psexec) de Microsoft sur l'appareil.
1. Utilisez l' PsExec utilitaire pour stocker le nom d'utilisateur et le mot de passe de l'utilisateur par défaut dans l'instance Credential Manager du LocalSystem compte.
Exécutez la commande suivante pour chaque utilisateur que vous souhaitez configurer dans Credential Manager. Pour l'utilisateur Greengrass par défaut, remplacez par*user-name*. `ggc_user` *password*Remplacez-le par le mot de passe utilisateur que vous avez défini précédemment.
```
psexec -s cmd /c cmdkey /generic:user-name /user:user-name /pass:password
```
S'il **PsExec License Agreement**s'ouvre, choisissez **Accept**d'accepter la licence et exécutez la commande.
**Note**
Sur les appareils Windows, le LocalSystem compte exécute le noyau Greengrass, et vous devez utiliser l' PsExec utilitaire pour stocker les informations utilisateur dans le LocalSystem compte. L'application Credential Manager stocke ces informations dans le compte Windows de l'utilisateur actuellement connecté, plutôt que dans le LocalSystem compte.
## 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 pour AWS IoT Greengrass V2 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 un rôle d'échange de jetons personnalisé
Vous pouvez choisir d'utiliser un rôle IAM personnalisé comme rôle d'échange de jetons que le périphérique testé suppose d'interagir avec les AWS ressources. Pour plus d'informations sur la création d'un rôle IAM, consultez la section [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) dans le Guide de l'utilisateur *IAM*.
Vous devez satisfaire aux exigences suivantes pour permettre à IDT d'utiliser votre rôle IAM personnalisé. Nous vous recommandons vivement de n'ajouter que le minimum d'actions de stratégie requises à ce rôle.
+ Le fichier de configuration [userdata.json](set-config.md#custom-token-exchange-role-idt) doit être mis à jour pour que le `GreengrassV2TokenExchangeRole` paramètre soit défini sur. `true`
+ Le rôle IAM personnalisé doit être configuré avec la politique de confiance minimale suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":[
"credentials.iot.amazonaws.com",
"lambda.amazonaws.com",
"sagemaker.amazonaws.com"
]
},
"Action":"sts:AssumeRole"
}
]
}
```
------
+ Le rôle IAM personnalisé doit être configuré selon la politique d'autorisation minimale suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"iot:DescribeCertificate",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams",
"iot:Connect",
"iot:Publish",
"iot:Subscribe",
"iot:Receive",
"iot:ListThingPrincipals",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Resource":"*"
}
]
}
```
------
+ Le nom du rôle IAM personnalisé doit correspondre à la ressource de rôle IAM que vous spécifiez dans les autorisations IAM pour l'utilisateur de test. Par défaut, la [politique des utilisateurs de test](dev-tst-prereqs.md#configure-idt-permissions) autorise l'accès aux rôles IAM dont le nom de rôle contient le `idt-` préfixe. Si le nom de votre rôle IAM n'utilise pas ce préfixe, ajoutez la `arn:aws:iam::*:role/custom-iam-role-name` ressource à l'`roleAliasResources`instruction et à l'`passRoleForResources`instruction dans votre politique utilisateur de test, comme indiqué dans les exemples suivants :
**Example `passRoleForResources` déclaration**
```
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/custom-iam-role-name",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
}
```
**Example `roleAliasResources` déclaration**
```
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/idt-*",
"arn:aws:iam::*:role/custom-iam-role-name"
]
}
```
## Configurer votre appareil pour tester des fonctions facultatives
Cette section décrit la configuration requise pour exécuter des tests IDT pour les fonctionnalités optionnelles de Docker et d'apprentissage automatique (ML). Les fonctionnalités ML ne sont prises en charge que dans IDT v4.9.3. Vous devez vous assurer que votre appareil répond à ces exigences uniquement si vous souhaitez tester ces fonctionnalités. Dans le cas contraire, passez à [Configurer les paramètres IDT pour exécuter la suite de AWS IoT Greengrass qualification](set-config.md).
**Topics**
+ [Exigences de qualification pour Docker](#idt-config-docker-components)
+ [Exigences de qualification ML](#idt-config-ml-components)
+ [Exigences de qualification HSM](#idt-config-hsm-components)
### Exigences de qualification pour Docker
IDT for AWS IoT Greengrass V2 propose des tests de qualification Docker pour valider que vos appareils peuvent utiliser le composant du [gestionnaire d'applications Docker AWS](docker-application-manager-component.md) fourni pour télécharger des images de conteneur Docker que vous pouvez exécuter à l'aide de composants de conteneur Docker personnalisés. Pour plus d'informations sur la création de composants Docker personnalisés, consultez[Exécuter un conteneur Docker](run-docker-container.md).
Pour exécuter les tests de qualification Docker, vos appareils testés doivent répondre aux exigences suivantes pour déployer le composant du gestionnaire d'applications Docker.
+ [Docker Engine](https://docs.docker.com/engine/) 1.9.1 ou version ultérieure installé sur le périphérique principal de Greengrass. La version 20.10 est la dernière version vérifiée pour fonctionner avec le logiciel AWS IoT Greengrass Core. Vous devez installer Docker directement sur le périphérique principal avant de déployer des composants qui exécutent des conteneurs Docker.
+ Le daemon Docker a démarré et s'est exécuté sur le périphérique principal avant que vous ne déployiez ce composant.
+ L'utilisateur du système qui exécute un composant de conteneur Docker doit disposer des autorisations root ou administrateur, ou vous devez configurer Docker pour l'exécuter en tant qu'utilisateur non root ou non administrateur.
+ Sur les appareils Linux, vous pouvez ajouter un utilisateur au `docker` groupe sans lequel vous pouvez appeler `docker` des commandes`sudo`.
+ Sur les appareils Windows, vous pouvez ajouter un utilisateur au `docker-users` groupe pour appeler des `docker` commandes sans privilèges d'administrateur.
------
#### [ Linux or Unix ]
Pour ajouter `ggc_user` au `docker` groupe l'utilisateur non root que vous utilisez pour exécuter les composants du conteneur Docker, exécutez la commande suivante.
```
sudo usermod -aG docker ggc_user
```
Pour plus d'informations, consultez [Gérer Docker en tant qu'utilisateur non root](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user).
------
#### [ Windows Command Prompt (CMD) ]
Pour ajouter `ggc_user` au `docker-users` groupe l'utilisateur que vous utilisez pour exécuter les composants du conteneur Docker, exécutez la commande suivante en tant qu'administrateur.
```
net localgroup docker-users ggc_user /add
```
------
#### [ Windows PowerShell ]
Pour ajouter `ggc_user` au `docker-users` groupe l'utilisateur que vous utilisez pour exécuter les composants du conteneur Docker, exécutez la commande suivante en tant qu'administrateur.
```
Add-LocalGroupMember -Group docker-users -Member ggc_user
```
------
### Exigences de qualification ML
**Note**
La fonctionnalité d'apprentissage automatique n'est prise en charge que dans IDT v4.9.3.
IDT for AWS IoT Greengrass V2 propose des tests de qualification ML pour valider que vos appareils peuvent utiliser les [composants d'apprentissage automatique AWS](machine-learning-components.md) fournis pour effectuer une inférence ML localement à l'aide des frameworks [Deep Learning Runtime](https://github.com/neo-ai/neo-ai-dlr) ou [TensorFlow Lite](https://www.tensorflow.org/lite/guide/python) ML. Pour plus d'informations sur l'exécution de l'inférence ML sur les appareils Greengrass, consultez. [Exécuter l'inférence de Machine Learning](perform-machine-learning-inference.md)
Pour exécuter des tests de qualification ML, vos appareils testés doivent répondre aux exigences suivantes pour déployer les composants d'apprentissage automatique.
+ Sur les appareils principaux de Greengrass exécutant Amazon Linux 2 ou Ubuntu 18.04, la version 2.27 ou ultérieure de la [bibliothèque GNU C](https://www.gnu.org/software/libc/) (glibc) est installée sur l'appareil.
+ Sur les appareils ARMv7L, tels que le Raspberry Pi, les dépendances pour OpenCV-Python sont installées sur l'appareil. Exécutez la commande suivante pour installer les dépendances.
```
sudo apt-get install libopenjp2-7 libilmbase23 libopenexr-dev libavcodec-dev libavformat-dev libswscale-dev libv4l-dev libgtk-3-0 libwebp-dev
```
+ Les appareils Raspberry Pi qui exécutent le système d'exploitation Raspberry Pi Bullseye doivent répondre aux exigences suivantes :
+ NumPy 1.22.4 ou version ultérieure installée sur l'appareil. Raspberry Pi OS Bullseye inclut une version antérieure de NumPy. Vous pouvez donc exécuter la commande suivante pour effectuer la mise à niveau NumPy sur l'appareil.
```
pip3 install --upgrade numpy
```
+ L'ancienne pile de caméras activée sur l'appareil. Raspberry Pi OS Bullseye inclut une nouvelle pile de caméras activée par défaut et non compatible. Vous devez donc activer la pile de caméras existante.
**Pour activer l'ancienne pile de caméras**
1. Exécutez la commande suivante pour ouvrir l'outil de configuration du Raspberry Pi.
```
sudo raspi-config
```
1. Sélectionnez **Options d'interface**.
1. Sélectionnez **Legacy camera** pour activer l'ancienne pile de caméras.
1. Redémarrez l'appareil Raspberry Pi.
### Exigences de qualification HSM
AWS IoT Greengrass fournit un [composant fournisseur PKCS \$111](pkcs11-provider-component.md) à intégrer au module de sécurité matérielle (HSM) PKCS du périphérique. La configuration du HSM dépend de votre appareil et du module HSM que vous avez choisi. Tant que la configuration HSM attendue, telle que décrite dans les [paramètres de configuration IDT](set-config.md), est fournie, IDT disposera des informations nécessaires pour exécuter ce test de qualification des fonctionnalités optionnel.
# 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.
## Configurer les AWS informations d'identification dans config.json
Vous devez configurer vos informations d'identification d'utilisateur IAM dans le `/configs/config.json` fichier. Utilisez les informations d'identification de l'utilisateur IDT pour AWS IoT Greengrass V2 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 :
+ Dans un fichier d'informations d'identification
+ En tant que variables d'environnement
### Configuration des AWS informations d'identification à l'aide d'un fichier 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 pour AWS IoT Greengrass V2 afin AWS d'utiliser les informations d'identification de votre `credentials` fichier, modifiez votre `config.json` fichier comme suit :
```
{
"awsRegion": "region",
"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 pour AWS IoT Greengrass V2 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": "region",
"auth": {
"method": "environment"
}
}
```
## Configurer device.json
**Note**
IDT v4.9.3 permet de tester les fonctionnalités `ml``docker`, et. `streamManagement` IDT v4.9.4 et versions ultérieures prennent en charge les tests. `docker` Si vous ne souhaitez pas tester ces fonctionnalités, définissez la valeur correspondante sur`no`.
Outre les AWS informations d'identification, IDT pour AWS IoT Greengrass V2 a besoin d'informations sur les appareils sur lesquels les tests sont exécutés. Des exemples d'informations pourraient être l'adresse IP, les informations de connexion, le système d'exploitation et l'architecture du processeur.
Vous pouvez fournir ces informations à l'aide du modèle `device.json` situé dans ` /configs/device.json` :
------
#### [ IDT v4.9.3 ]
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "arch",
"value": "x86_64 | armv6l | armv7l | aarch64"
},
{
"name": "ml",
"value": "dlr | tensorflowlite | dlr,tensorflowlite | no"
},
{
"name": "docker",
"value": "yes | no"
},
{
"name": "streamManagement",
"value": "yes | no"
},
{
"name": "hsi",
"value": "hsm | no"
}
],
"devices": [
{
"id": "",
"operatingSystem": "Linux | Windows",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": 22,
"publicKeyPath": "",
"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`.
Toutes les propriétés contenant des valeurs sont obligatoires, comme décrit 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 répertorier votre appareil dans le catalogue des AWS Partner appareils, le SKU que vous spécifiez ici doit correspondre au SKU que vous utilisez dans le processus de mise en vente.
`features`
Un tableau contenant les fonctions prises en charge de l'appareil. Toutes les fonctionnalités sont requises.
`arch`
Les architectures de système d'exploitation prises en charge validées par le test. Les valeurs valides sont :
+ `x86_64`
+ `armv6l`
+ `armv7l`
+ `aarch64`
`ml`
Valide que l'appareil répond à toutes les dépendances techniques requises pour utiliser les composants d'apprentissage automatique (ML) AWS fournis.
L'activation de cette fonctionnalité confirme également que l'appareil peut effectuer une inférence ML à l'aide des frameworks [Deep Learning Runtime](https://github.com/neo-ai/neo-ai-dlr) et [TensorFlow Lite](https://www.tensorflow.org/lite/guide/python) ML.
Les valeurs valides sont n'importe quelle combinaison `tensorflowlite` de `dlr` et ou`no`.
`docker`
Vérifie que l'appareil répond à toutes les dépendances techniques requises pour utiliser le composant Docker application manager () AWS`aws.greengrass.DockerApplicationManager` fourni.
L'activation de cette fonctionnalité confirme également que l'appareil peut télécharger une image de conteneur Docker depuis Amazon ECR.
Les valeurs valides sont n'importe quelle combinaison de `yes` ou`no`.
`streamManagement`
Vérifie que l'appareil peut télécharger, installer et exécuter le [gestionnaire de AWS IoT Greengrass flux](manage-data-streams.md).
Les valeurs valides sont n'importe quelle combinaison de `yes` ou`no`.
`hsi`
Valide que le périphérique peut authentifier les connexions aux AWS IoT Greengrass services AWS IoT et à l'aide d'une clé privée et d'un certificat stockés dans un module de sécurité matériel (HSM). Ce test vérifie également que le [composant fournisseur PKCS \$111 AWS](pkcs11-provider-component.md) fourni peut s'interfacer avec le HSM à l'aide d'une bibliothèque PKCS \$111 fournie par le fournisseur. Pour de plus amples informations, veuillez consulter [Intégration de sécurité matérielle](hardware-security.md).
Les valeurs valides sont `hsm` ou `no`.
Le test n'`hsi`est disponible qu'avec IDT v4.9.3 et versions ultérieures.
`devices.id`
Un identificateur unique défini par l'utilisateur pour l'appareil testé.
`devices.operatingSystem`
Le système d'exploitation de l'appareil. Les valeurs prises en charge sont `Linux` et `Windows`.
`connectivity.protocol`
Le protocole de communication utilisé pour communiquer avec cet appareil. Actuellement, la seule valeur prise en charge `ssh` concerne les appareils physiques.
`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.publicKeyPath`
Facultatif. Le chemin complet vers la clé publique utilisée pour authentifier les connexions à l'appareil testé.
Lorsque vous spécifiez le`publicKeyPath`, IDT valide la clé publique de l'appareil lorsqu'il établit une connexion SSH avec le périphérique testé. Si cette valeur n'est pas spécifiée, IDT crée une connexion SSH, mais ne valide pas la clé publique de l'appareil.
Nous vous recommandons vivement de spécifier le chemin d'accès à la clé publique et d'utiliser une méthode sécurisée pour récupérer cette clé publique. Pour les clients SSH standard basés sur une ligne de commande, la clé publique est fournie dans le `known_hosts` fichier. Si vous spécifiez un fichier de clé publique distinct, ce fichier doit utiliser le même format que le `known_hosts` fichier, c'est-à-dire` ip-address key-type public-key`. S'il existe plusieurs entrées avec la même adresse IP, l'entrée correspondant au type de clé utilisé par IDT doit se trouver avant les autres entrées du fichier.
`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é.
------
#### [ IDT v4.9.4 ]
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "arch",
"value": "x86_64 | armv6l | armv7l | aarch64"
},
{
"name": "docker",
"value": "yes | no"
},
{
"name": "hsi",
"value": "hsm | no"
}
],
"devices": [
{
"id": "",
"operatingSystem": "Linux | Windows",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": 22,
"publicKeyPath": "",
"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`.
Toutes les propriétés contenant des valeurs sont obligatoires, comme décrit 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 répertorier votre appareil dans le catalogue des AWS Partner appareils, le SKU que vous spécifiez ici doit correspondre au SKU que vous utilisez dans le processus de mise en vente.
`features`
Un tableau contenant les fonctions prises en charge de l'appareil. Toutes les fonctionnalités sont requises.
`arch`
Les architectures de système d'exploitation prises en charge validées par le test. Les valeurs valides sont :
+ `x86_64`
+ `armv6l`
+ `armv7l`
+ `aarch64`
`docker`
Vérifie que l'appareil répond à toutes les dépendances techniques requises pour utiliser le composant Docker application manager () AWS`aws.greengrass.DockerApplicationManager` fourni.
L'activation de cette fonctionnalité confirme également que l'appareil peut télécharger une image de conteneur Docker depuis Amazon ECR.
Les valeurs valides sont n'importe quelle combinaison de `yes` ou`no`.
`hsi`
Valide que le périphérique peut authentifier les connexions aux AWS IoT Greengrass services AWS IoT et à l'aide d'une clé privée et d'un certificat stockés dans un module de sécurité matériel (HSM). Ce test vérifie également que le [composant fournisseur PKCS \$111 AWS](pkcs11-provider-component.md) fourni peut s'interfacer avec le HSM à l'aide d'une bibliothèque PKCS \$111 fournie par le fournisseur. Pour de plus amples informations, veuillez consulter [Intégration de sécurité matérielle](hardware-security.md).
Les valeurs valides sont `hsm` ou `no`.
Le test n'`hsi`est disponible qu'avec IDT v4.9.3 et versions ultérieures.
`devices.id`
Un identificateur unique défini par l'utilisateur pour l'appareil testé.
`devices.operatingSystem`
Le système d'exploitation de l'appareil. Les valeurs prises en charge sont `Linux` et `Windows`.
`connectivity.protocol`
Le protocole de communication utilisé pour communiquer avec cet appareil. Actuellement, la seule valeur prise en charge `ssh` concerne les appareils physiques.
`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.publicKeyPath`
Facultatif. Le chemin complet vers la clé publique utilisée pour authentifier les connexions à l'appareil testé.
Lorsque vous spécifiez le`publicKeyPath`, IDT valide la clé publique de l'appareil lorsqu'il établit une connexion SSH avec le périphérique testé. Si cette valeur n'est pas spécifiée, IDT crée une connexion SSH, mais ne valide pas la clé publique de l'appareil.
Nous vous recommandons vivement de spécifier le chemin d'accès à la clé publique et d'utiliser une méthode sécurisée pour récupérer cette clé publique. Pour les clients SSH standard basés sur une ligne de commande, la clé publique est fournie dans le `known_hosts` fichier. Si vous spécifiez un fichier de clé publique distinct, ce fichier doit utiliser le même format que le `known_hosts` fichier, c'est-à-dire` ip-address key-type public-key`. S'il existe plusieurs entrées avec la même adresse IP, l'entrée correspondant au type de clé utilisé par IDT doit se trouver avant les autres entrées du fichier.
`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é.
------
## Configurer userdata.json
IDT for AWS IoT Greengrass V2 a également besoin d'informations supplémentaires sur l'emplacement des artefacts de test et des AWS IoT Greengrass logiciels.
Vous pouvez fournir ces informations à l'aide du modèle `userdata.json` situé dans ` /configs/userdata.json` :
```
{
"TempResourcesDirOnDevice": "/path/to/temp/folder",
"InstallationDirRootOnDevice": "/path/to/installation/folder",
"GreengrassNucleusZip": "/path/to/aws.greengrass.nucleus.zip",
"PreInstalled": "yes/no",
"GreengrassV2TokenExchangeRole": "custom-iam-role-name",
"hsm": {
"greengrassPkcsPluginJar": "/path/to/aws.greengrass.crypto.Pkcs11Provider-latest.jar",
"pkcs11ProviderLibrary": "/path/to/pkcs11-vendor-library",
"slotId": "slot-id",
"slotLabel": "slot-label",
"slotUserPin": "slot-pin",
"keyLabel": "key-label",
"preloadedCertificateArn": "certificate-arn"
"rootCA": "path/to/root-ca"
}
}
```
Toutes les propriétés contenant des valeurs sont obligatoires, comme décrit ici :
`TempResourcesDirOnDevice`
Le chemin complet vers un dossier temporaire sur le périphérique testé dans lequel stocker les artefacts de test. Assurez-vous que les autorisations sudo ne sont pas requises pour écrire dans ce répertoire.
IDT supprime le contenu de ce dossier une fois le test terminé.
`InstallationDirRootOnDevice`
Le chemin complet vers un dossier de l'appareil dans lequel effectuer l'installation AWS IoT Greengrass. Pour PreInstalled Greengrass, il s'agit du chemin d'accès au répertoire d'installation de Greengrass.
Vous devez définir les autorisations de fichier requises pour ce dossier. Exécutez la commande suivante pour chaque dossier du chemin d'installation.
```
sudo chmod 755 folder-name
```
`GreengrassNucleusZip`
Le chemin complet vers le fichier ZIP (`greengrass-nucleus-latest.zip`) du noyau de Greengrass sur votre ordinateur hôte. Ce champ n'est pas obligatoire pour les tests avec PreInstalled Greengrass.
Pour plus d'informations sur les versions prises en charge du noyau Greengrass pour IDT, consultez. AWS IoT Greengrass[Dernière version IDT pour V2 AWS IoT Greengrass](dev-test-versions.md#idt-latest-version) Pour télécharger la dernière version du logiciel Greengrass, voir [Télécharger le AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-tst-prereqs.html#config-gg) logiciel.
`PreInstalled`
Cette fonctionnalité est disponible pour IDT v4.5.8 et versions ultérieures uniquement sur les appareils Linux.
(Facultatif) Lorsque la valeur est*yes*, IDT supposera que le chemin indiqué est le répertoire dans `InstallationDirRootOnDevice` lequel Greengrass est installé.
Pour plus d'informations sur l'installation de Greengrass sur votre appareil, consultez. [Installation AWS IoT Greengrass du logiciel Core avec provisionnement automatique des ressources](quick-installation.md) En cas d'[installation avec provisionnement manuel](https://docs.aws.amazon.com/greengrass/v2/developerguide/manual-installation.html), incluez l'étape « Ajouter l' AWS IoT objet à un nouveau groupe d'objets ou à un groupe d'objets existant » lors de la création manuelle d'un [AWS IoT objet](https://docs.aws.amazon.com/greengrass/v2/developerguide/manual-installation.html#create-iot-thing). IDT part du principe que l'objet et le groupe d'objets sont créés lors de la configuration de l'installation. Assurez-vous que ces valeurs sont reflétées dans le `effectiveConfig.yaml` fichier. IDT vérifie la présence du fichier ci-dessous`effectiveConfig.yaml`. `/config/effectiveConfig.yaml`
Pour exécuter des tests avec HSM, assurez-vous que le `aws.greengrass.crypto.Pkcs11Provider` champ est mis à jour dans`effectiveConfig.yaml`.
`GreengrassV2TokenExchangeRole`
(Facultatif) Le rôle IAM personnalisé que vous souhaitez utiliser comme rôle d'échange de jetons que le périphérique testé suppose d'interagir avec les AWS ressources.
IDT utilise ce rôle IAM personnalisé au lieu de créer le rôle d'échange de jetons par défaut lors du test. Si vous utilisez un rôle personnalisé, vous pouvez mettre à jour les [autorisations IAM pour l'utilisateur de test afin d'](dev-tst-prereqs.md#configure-idt-permissions)exclure l'`iamResourcesUpdate`instruction qui permet à l'utilisateur de créer et de supprimer des rôles et des politiques IAM.
Pour plus d'informations sur la création d'un rôle IAM personnalisé en tant que rôle d'échange de jetons, consultez[Configurer un rôle d'échange de jetons personnalisé](device-config-setup.md#configure-custom-tes-role-for-idt).
`hsm`
Cette fonctionnalité est disponible pour IDT v4.5.1 et versions ultérieures.
(Facultatif) Les 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`.
La configuration HSM peut être considérée comme une donnée sensible si le module de sécurité matériel est partagé entre IDT et un autre système. Dans ce cas, vous pouvez éviter de sécuriser ces valeurs de configuration en texte brut en les stockant dans un AWS paramètre Parameter Store SecureString et en configurant IDT pour qu'il les récupère pendant l'exécution du test. Pour de plus amples informations, consultez [Extraire la configuration depuis le magasin de AWS paramètres](#fetch-config).
`hsm.greengrassPkcsPluginJar`
Le chemin complet vers le [composant fournisseur PKCS \$111](pkcs11-provider-component.md) que vous téléchargez sur la machine hôte IDT. AWS IoT Greengrass fournit ce composant sous forme de fichier JAR que vous pouvez télécharger pour le spécifier en tant que plugin de provisionnement lors de l'installation. Vous pouvez télécharger la dernière version du fichier JAR du composant à l'adresse suivante : [https://d2s8p88vqu9w66.cloudfront. net/releases/Pkcs11Provider/aws.greengrass.crypto.pkcs11Provider-Latest.jar](https://d2s8p88vqu9w66.cloudfront.net/releases/Pkcs11Provider/aws.greengrass.crypto.Pkcs11Provider-latest.jar).
`hsm.pkcs11ProviderLibrary`
Le chemin complet vers la bibliothèque PKCS \$111 fournie par le fournisseur du module de sécurité matérielle (HSM) pour interagir avec le HSM.
`hsm.slotId`
ID de slot utilisé pour identifier le slot HSM dans lequel vous chargez la clé et le certificat.
`hsm.slotLabel`
L'étiquette d'emplacement utilisée pour identifier l'emplacement HSM dans lequel vous chargez la clé et le certificat.
`hsm.slotUserPin`
Le code PIN utilisateur utilisé par IDT pour authentifier le logiciel AWS IoT Greengrass Core auprès du HSM.
Pour des raisons de sécurité, n'utilisez pas le même code PIN utilisateur sur les appareils de production.
`hsm.keyLabel`
Étiquette utilisée pour identifier la clé dans le module matériel. La clé et le certificat doivent utiliser la même étiquette de clé.
`hsm.preloadedCertificateArn`
Le nom de ressource Amazon (ARN) du certificat d'appareil téléchargé dans le AWS IoT cloud.
Vous devez avoir préalablement généré ce certificat à l'aide de la clé du HSM, l'avoir importé dans votre HSM et l'avoir chargé dans le AWS IoT cloud. Pour plus d'informations sur la génération et l'importation du certificat, consultez la documentation de votre HSM.
Vous devez télécharger le certificat sur le même compte et dans la même région que ceux que vous avez fournis dans [config.json.](#cfg-aws-gg) . Pour plus d'informations sur le téléchargement de votre certificat vers AWS IoT, voir [Enregistrer un certificat client manuellement](https://docs.aws.amazon.com/iot/latest/developerguide/manual-cert-registration.html) dans le *Guide du AWS IoT développeur*.
`hsm.rootCAPath`
(Facultatif) Le chemin complet sur la machine hôte IDT vers l'autorité de certification racine (CA) qui a signé votre certificat. Cela est nécessaire si le certificat de votre HSM créé n'est pas signé par l'autorité de certification racine Amazon.
## Extraire la configuration depuis le magasin de AWS paramètres
AWS IoT Device Tester (IDT) inclut une fonctionnalité optionnelle permettant de récupérer les valeurs de configuration depuis le magasin de [paramètres de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). AWS Parameter Store permet le stockage sécurisé et crypté des configurations. Une fois configuré, IDT peut récupérer les paramètres depuis le AWS Parameter Store au lieu de les stocker en texte brut dans le fichier. `userdata.json` Cela est utile pour toutes les données sensibles qui doivent être stockées cryptées, telles que les mots de passe, les codes PIN et autres secrets.
1. Pour utiliser cette fonctionnalité, vous devez mettre à jour les autorisations utilisées lors de la création de votre [utilisateur IDT afin d'](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-tst-prereqs.html)autoriser l' GetParameter action sur les paramètres pour lesquels IDT est configuré pour utiliser. Vous trouverez ci-dessous un exemple de déclaration d'autorisation qui peut être ajoutée à l'utilisateur IDT. Pour plus d'informations, consultez le [AWS Systems Manager guide de l'utilisateur](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-access.html).
```
{
"Sid":"parameterStoreResources",
"Effect": "Allow",
"Action": [
"ssm:GetParameter"
],
"Resource": "arn:aws:ssm:*:*:parameter/IDT*"
}
```
L'autorisation ci-dessus est configurée pour permettre de récupérer tous les paramètres dont le nom commence par`IDT`, en utilisant le caractère générique. `*` Vous devez le personnaliser en fonction de vos besoins afin qu'IDT ait accès à tous les paramètres configurés en fonction du nom des paramètres que vous utilisez.
1. Vous devez stocker vos valeurs de configuration dans AWS Paramater Store. Cela peut être fait à partir de la AWS console ou de la AWS CLI. AWS Parameter Store vous permet de choisir un stockage crypté ou non chiffré. Pour le stockage de valeurs sensibles telles que les secrets, les mots de passe et les codes PIN, vous devez utiliser l'option cryptée qui est un type de paramètre de SecureString. Pour télécharger un paramètre à l'aide de la AWS CLI, vous pouvez utiliser la commande suivante :
```
aws ssm put-parameter --name IDT-example-name --value IDT-example-value --type SecureString
```
Vous pouvez vérifier qu'un paramètre est enregistré à l'aide de la commande suivante. (Facultatif) Utilisez l'`--with-decryption`indicateur pour récupérer un paramètre SecureString déchiffré.
```
aws ssm get-parameter --name IDT-example-name
```
L'utilisation de la AWS CLI téléchargera le paramètre dans la AWS région de l'utilisateur CLI actuel et IDT récupérera les paramètres de la région configurée dans. `config.json` Pour vérifier votre région à partir de la AWS CLI, utilisez ce qui suit :
```
aws configure get region
```
1. Une fois que vous avez une valeur de configuration dans le AWS cloud, vous pouvez mettre à jour n'importe quelle valeur dans la configuration IDT pour la récupérer depuis le AWS cloud. Pour ce faire, vous utilisez un espace réservé dans votre configuration IDT du formulaire `{{AWS.Parameter.parameter_name}}` pour récupérer le paramètre portant ce nom dans le Parameter Store. AWS
Supposons, par exemple, que vous souhaitiez utiliser le `IDT-example-name` paramètre de l'étape 2 en tant que KeyLabel HSM dans votre configuration HSM. Pour ce faire, vous pouvez mettre à jour votre `userdata.json` compte comme suit :
```
"hsm": {
"keyLabel": "{{AWS.Parameter.IDT-example-name}}",
[...]
}
```
IDT récupérera la valeur de ce paramètre au moment de l'exécution qui a été définie `IDT-example-value` à l'étape 2. Cette configuration est similaire au paramètre, `"keyLabel": "IDT-example-value"` mais cette valeur est stockée sous forme cryptée dans le AWS Cloud.
# 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.
Utilisez la `run-suite` commande suivante pour exécuter une série de tests.
```
devicetester_[linux | mac | win]_x86-64 run-suite \\
--suite-id suite-id \\
--group-id group-id \\
--pool-id your-device-pool \\
--test-id test-id \\
--update-idt y|n \\
--userdata userdata.json
```
Toutes les options sont facultatives. Par exemple, vous pouvez omettre `pool-id` si un seul pool de périphériques, qui est un ensemble d'appareils identiques, est défini dans votre `device.json` fichier. 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 [Versions de la suite de tests](idt-greengrass-qualification.md#idt-test-suite-versions).
## Exemples de commandes pour exécuter la suite de qualifications
Les exemples de ligne de commande suivants vous montrent comment exécuter les tests de qualification pour un pool de périphériques. Pour plus d'informations sur `run-suite` et d'autres commandes IDT, veuillez consulter [IDT pour les commandes AWS IoT Greengrass V2](#bk-cli).
Utilisez la commande suivante pour exécuter tous les groupes de tests dans une suite de tests spécifiée. La `list-suites` commande répertorie les suites de tests qui se trouvent dans le `tests` dossier.
```
devicetester_[linux | mac | win]_x86-64 run-suite \
--suite-id GGV2Q_1.0.0 \
--pool-id \
--userdata userdata.json
```
Utilisez la commande suivante pour exécuter un groupe de tests spécifique dans une suite de tests. La `list-groups` commande répertorie les groupes de tests d'une suite de tests.
```
devicetester_[linux | mac | win]_x86-64 run-suite \
--suite-id GGV2Q_1.0.0 \
--group-id \
--pool-id \
--userdata userdata.json
```
Utilisez la commande suivante pour exécuter un scénario de test spécifique dans un groupe de test.
```
devicetester_[linux | mac | win]_x86-64 run-suite \
--group-id \
--test-id \
--userdata userdata.json
```
Utilisez la commande suivante pour exécuter plusieurs scénarios de test dans un groupe de test.
```
devicetester_[linux | mac | win]_x86-64 run-suite \
--group-id \
--test-id ,
--userdata userdata.json
```
Utilisez la commande suivante pour répertorier tous les cas de test d'un groupe de test.
```
devicetester_[linux | mac | win]_x86-64 list-test-cases --group-id
```
Nous vous recommandons d'exécuter la suite complète de tests de qualification, qui exécute les dépendances des groupes de test dans le bon ordre. Si vous choisissez d'exécuter des groupes de test spécifiques, nous vous recommandons d'exécuter d'abord le groupe de test du vérificateur de dépendances pour vous assurer que toutes les dépendances de Greengrass sont installées avant d'exécuter les groupes de test associés. Par exemple :
+ Exécutez `coredependencies` avant les groupes de tests de qualification du noyau.
## IDT pour les commandes AWS IoT Greengrass V2
Les commandes IDT se trouvent dans le répertoire `/bin`. Pour exécuter une suite de tests, vous devez fournir la commande au format suivant :
`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 ce n'est pas spécifié, IDT exécute tous les groupes de tests appropriés dans la suite de tests en fonction des paramètres configurés dans`device.json`. IDT n'exécute aucun groupe de test que l'appareil ne prend en charge en fonction de vos paramètres configurés, même si ces groupes de test sont spécifiés dans la `group-id` liste.
+ `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`.
+ `stop-on-first-failure`. Configure IDT pour qu'il cesse de fonctionner lors du premier échec. Utilisez cette option `group-id` lorsque vous souhaitez déboguer les groupes de test 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. La `Y` réponse arrête l'exécution du test si IDT détecte qu'il existe une version plus récente. La `N` réponse poursuit l'exécution du test.
+ `userdata`. Le chemin complet du `userdata.json` fichier contenant des informations sur les chemins des artefacts de test. Cette option est obligatoire pour la `run-suite` commande. Le `userdata.json` fichier doit se trouver dans le répertoire *devicetester\$1extract\$1location* /devicetester\$1ggv2\$1 *[win\$1mac\$1linux]* /configs/.
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.
Pour résoudre les erreurs, voir[Résolution des problèmes liés à IDT pour V2 AWS IoT Greengrass](idt-troubleshooting.md).
## 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 dans`/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 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.
+ Répartition des résultats des tests par bibliothèques testées en fonction des fonctionnalités de l'appareil, telles que l'accès aux ressources locales, le shadow et le MQTT.
Le `GGV2Q_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 AWS IoT Device Tester des résultats
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é du test. Par exemple :
```
```Attributs utilisés dans la balise ``
`name`
Nom de la suite de tests.
`time`
Le temps, en secondes, nécessaire à l'exécution de la suite de qualification.
`tests`
Le nombre de tests exécutés.
`failures`
Nombre de tests exécutés mais dont le résultat n'est pas probant.
`errors`
Le nombre de tests qu'IDT n'a pas pu exécuter.
`disabled`
Ignorez cet attribut. Elle n'est pas utilisée.
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`.
```
```
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 contient des `` balises pour chaque test effectué pour un groupe de test. Par exemple :
```
>
```Attributs utilisés dans la balise ``
`name`
Nom du test.
`attempts`
Le nombre de fois où IDT a exécuté le scénario de 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 des tests effectués. `/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, lambdaDeploymentTest.log)`
Journaux du scénario de test au sein du groupe de test, y compris les journaux du périphérique testé. À partir de la version 4.2.0 d'IDT, IDT regroupe les journaux de test pour chaque cas de test dans un ** dossier distinct au sein du répertoire. `/results//logs//`
# Utilisez IDT pour développer et exécuter vos propres suites de tests
À partir de IDT v4.0.1, IDT pour AWS IoT Greengrass V2 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 for AWS IoT Greengrass
Téléchargez la [dernière version](idt-programmatic-download.md) d'IDT et extrayez le logiciel dans un emplacement (**) de votre système de fichiers où vous disposez d'autorisations de lecture/é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 fournissant à 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](idt-json-config.md) pour votre suite de tests.
1. [Créez des exécutables de cas de test](create-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-custom-idt-config.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-debug-custom-tests.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 AWS IoT Device Tester téléchargement 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 vous pouvez utiliser IDT 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 pour voir divers exemples d'exécutables de scénarios de test et de fichiers JSON de configuration de test.
**Note**
L'exemple de suite de tests inclut le code source python. N'incluez pas d'informations sensibles dans le code de votre suite de tests.
É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 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](#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**
+ 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
Votre suite de tests doit contenir les [fichiers de configuration](idt-json-config.md) requis suivants :Fichiers de configuration 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](create-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 tout problème lié à 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 que vous incluez lorsque vous écrivez une suite de tests personnalisée.Fichiers de configuration 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 de configuration facultatifs
`test_orchestrator.yaml` ou `state_machine.json`
Définit la manière dont les tests sont exécutés lorsque IDT exécute la suite de tests. SSe [Configurer test\$1orchestrator.yaml](#test-orchestrator-config).
À partir de IDT v4.5.1, vous utilisez le `test_orchestrator.yaml` fichier pour définir le flux de travail de test. Dans les versions précédentes d'IDT, vous utilisiez le `state_machine.json` fichier. Pour plus d'informations sur la machine à états, consultez[Configuration de la machine d'état IDT](idt-state-machine.md).
`userdata_schema.json`
Définit le schéma du [`userdata.json`fichier](set-custom-idt-config.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 sont placés dans votre dossier``, comme indiqué ici.
```
└── suite
├── suite.json
├── test_orchestrator.yaml
├── 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 peut 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](create-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 peut 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 lanceur de test 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](create-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 test\$1orchestrator.yaml
Un orchestrateur de tests 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 d'orchestrateur de test défini par l'utilisateur, IDT générera un orchestrateur de tests pour vous.
L'orchestrateur de test 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 l'orchestrateur de test IDT, consultez. [Configuration de l'orchestrateur de test IDT](idt-test-orchestrator.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 l'[orchestrateur de test](idt-state-machine.md#state-machine-context).
# Configuration de l'orchestrateur de test IDT
*À partir de IDT v4.5.1, IDT inclut un nouveau composant d'orchestrateur de test.* L'orchestrateur de tests est un composant IDT qui contrôle le flux d'exécution de la suite de tests et génère le rapport de test une fois que IDT a terminé d'exécuter tous les tests. L'orchestrateur de tests détermine la sélection des tests et l'ordre dans lequel les tests sont exécutés en fonction des règles définies par l'utilisateur.
Si votre suite de tests n'inclut pas d'orchestrateur de test défini par l'utilisateur, IDT générera un orchestrateur de tests pour vous.
L'orchestrateur de test 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.
L'orchestrateur de test remplace l'orchestrateur de test IDT. Nous vous recommandons vivement d'utiliser l'orchestrateur de tests pour développer vos suites de tests au lieu de l'orchestrateur de tests IDT. L'orchestrateur de test fournit les fonctionnalités améliorées suivantes :
+ Utilise un format déclaratif par rapport au format impératif utilisé par la machine d'état IDT. Cela vous permet de spécifier les tests que vous souhaitez exécuter et le moment où vous souhaitez les exécuter.
+ Gère la gestion de groupes spécifiques, la génération de rapports, la gestion des erreurs et le suivi des résultats afin que vous n'ayez pas à gérer manuellement ces actions.
+ Utilise le format YAML, qui prend en charge les commentaires par défaut.
+ Nécessite 80 % d'espace disque en moins que l'orchestrateur de test pour définir le même flux de travail.
+ Ajoute une validation préalable pour vérifier que la définition de votre flux de travail ne contient pas de tests IDs ou de dépendances circulaires incorrects.
## Tester le format de l'orchestrateur
Vous pouvez utiliser le modèle suivant pour configurer votre propre `/suite/test_orchestrator.yaml` fichier :
```
Aliases:
string: context-expression
ConditionalTests:
- Condition: context-expression
Tests:
- test-descriptor
Order:
- - group-descriptor
- group-descriptor
Features:
- Name: feature-name
Value: support-description
Condition: context-expression
Tests:
- test-descriptor
OneOfTests:
- test-descriptor
IsRequired: boolean
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
`Aliases`
Facultatif. Chaînes définies par l'utilisateur qui correspondent à des expressions de contexte. Les alias vous permettent de générer des noms conviviaux pour identifier les expressions contextuelles dans la configuration de votre orchestrateur de test. Cela est particulièrement utile si vous créez des expressions contextuelles complexes ou des expressions que vous utilisez à plusieurs endroits.
Vous pouvez utiliser des expressions contextuelles pour stocker des requêtes contextuelles qui vous permettent d'accéder aux données d'autres configurations IDT. Pour de plus amples informations, veuillez consulter [Accédez aux données dans le contexte](idt-context.md#accessing-context-data).
**Example exemple**
```
Aliases:
FizzChosen: "'{{$pool.features[?(@.name == 'Fizz')].value[0]}}' == 'yes'"
BuzzChosen: "'{{$pool.features[?(@.name == 'Buzz')].value[0]}}' == 'yes'"
FizzBuzzChosen: "'{{$aliases.FizzChosen}}' && '{{$aliases.BuzzChosen}}'"
```
`ConditionalTests`
Facultatif. Une liste de conditions et les cas de test correspondants qui sont exécutés lorsque chaque condition est satisfaite. Chaque condition peut comporter plusieurs scénarios de test ; toutefois, vous ne pouvez attribuer un scénario de test donné qu'à une seule condition.
Par défaut, IDT exécute tout scénario de test qui n'est pas affecté à une condition de cette liste. Si vous ne spécifiez pas cette section, IDT exécute tous les groupes de tests de la suite de tests.
Chaque élément de la `ConditionalTests` liste inclut les paramètres suivants :
`Condition`
Expression de contexte qui correspond à une valeur booléenne. Si la valeur évaluée est vraie, IDT exécute les scénarios de test spécifiés dans le `Tests` paramètre.
`Tests`
La liste des descripteurs de test.
Chaque descripteur de test utilise l'identifiant du groupe de test et un ou plusieurs cas de test IDs pour identifier les tests individuels à exécuter à partir d'un groupe de test spécifique. Le descripteur de test utilise le format suivant :
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
**Example exemple**
L'exemple suivant utilise des expressions contextuelles génériques que vous pouvez définir comme telles`Aliases`.
```
ConditionalTests:
- Condition: "{{$aliases.Condition1}}"
Tests:
- GroupId: A
- GroupId: B
- Condition: "{{$aliases.Condition2}}"
Tests:
- GroupId: D
- Condition: "{{$aliases.Condition1}} || {{$aliases.Condition2}}"
Tests:
- GroupId: C
```
Sur la base des conditions définies, IDT sélectionne les groupes de test comme suit :
+ Si `Condition1` c'est vrai, IDT exécute les tests dans les groupes de tests A, B et C.
+ Si `Condition2` c'est vrai, IDT exécute les tests dans les groupes de test C et D.
`Order`
Facultatif. Ordre dans lequel les tests doivent être exécutés. Vous spécifiez l'ordre des tests au niveau du groupe de test. Si vous ne spécifiez pas cette section, IDT exécute tous les groupes de test applicables dans un ordre aléatoire. La valeur de `Order` est une liste de listes de descripteurs de groupes. Tout groupe de test non répertorié peut être exécuté en `Order` parallèle avec n'importe quel autre groupe de test répertorié.
Chaque liste de descripteurs de groupe contient un ou plusieurs descripteurs de groupe et identifie l'ordre dans lequel exécuter les groupes spécifiés dans chaque descripteur. Vous pouvez utiliser les formats suivants pour définir des descripteurs de groupes individuels :
+ `group-id`: l'ID de groupe d'un groupe de test existant.
+ `[group-id, group-id]`—Liste des groupes de tests qui peuvent être exécutés dans n'importe quel ordre les uns par rapport aux autres.
+ `"*"`—Wildcard. Cela équivaut à la liste de tous les groupes de test qui ne sont pas déjà spécifiés dans la liste actuelle des descripteurs de groupes.
La valeur pour `Order` doit également répondre aux exigences suivantes :
+ Le groupe de test IDs que vous spécifiez dans un descripteur de groupe doit exister dans votre suite de tests.
+ Chaque liste de descripteurs de groupes doit inclure au moins un groupe de test.
+ Chaque liste de descripteurs de groupes doit contenir un groupe IDs unique. Vous ne pouvez pas répéter un identifiant de groupe de test dans des descripteurs de groupe individuels.
+ Une liste de descripteurs de groupes peut comporter au maximum un descripteur de groupe générique. Le descripteur de groupe générique doit être le premier ou le dernier élément de la liste.
**Example Exemples**
Pour une suite de tests contenant les groupes de tests A, B, C, D et E, la liste d'exemples suivante montre différentes manières de spécifier qu'IDT doit d'abord exécuter le groupe de test A, puis exécuter le groupe de test B, puis exécuter les groupes de test C, D et E dans n'importe quel ordre.
+
```
Order:
- - A
- B
- [C, D, E]
```
+
```
Order:
- - A
- B
- "*"
```
+
```
Order:
- - A
- B
- - B
- C
- - B
- D
- - B
- E
```
`Features`
Facultatif. Liste des fonctionnalités du produit que vous souhaitez qu'IDT ajoute au `awsiotdevicetester_report.xml` fichier. Si vous ne spécifiez pas cette section, IDT n'ajoutera aucune fonctionnalité du produit au rapport.
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é du produit MQTT peut indiquer que l'appareil publie correctement les messages MQTT. Dans`awsiotdevicetester_report.xml`, les fonctionnalités du produit sont définies sous la forme de `supported``not-supported`, ou d'une valeur personnalisée définie par l'utilisateur, en fonction de la réussite des tests spécifiés.
Chaque élément de la `Features` liste comprend les paramètres suivants :
`Name`
Le nom de la fonctionnalité.
`Value`
Facultatif. La valeur personnalisée que vous souhaitez utiliser dans le rapport à la place de`supported`. Si cette valeur n'est pas spécifiée, l'IDT basé sur le paramètre définit la valeur de la fonction sur `supported` ou en `not-supported` fonction des résultats des tests. Si vous testez la même fonctionnalité dans des conditions différentes, vous pouvez utiliser une valeur personnalisée pour chaque instance de cette fonctionnalité dans la `Features` liste, et IDT concatène les valeurs des entités pour les conditions prises en charge. Pour plus d'informations, veuillez consulter la rubrique
`Condition`
Expression de contexte qui correspond à une valeur booléenne. Si la valeur évaluée est vraie, IDT ajoute la fonctionnalité au rapport de test une fois l'exécution de la suite de tests terminée. Si la valeur évaluée est fausse, le test n'est pas inclus dans le rapport.
`Tests`
Facultatif. La liste des descripteurs de test. Tous les tests spécifiés dans cette liste doivent réussir pour que la fonctionnalité soit prise en charge.
Chaque descripteur de test de cette liste utilise l'ID du groupe de test et un ou plusieurs cas de test IDs pour identifier les tests individuels à exécuter à partir d'un groupe de test spécifique. Le descripteur de test utilise le format suivant :
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
Vous devez spécifier l'une `Tests` ou l'autre des fonctionnalités de la `Features` liste ou `OneOfTests` pour chacune d'entre elles.
`OneOfTests`
Facultatif. La liste des descripteurs de test. Au moins l'un des tests spécifiés dans cette liste doit réussir pour que la fonctionnalité soit prise en charge.
Chaque descripteur de test de cette liste utilise l'ID du groupe de test et un ou plusieurs cas de test IDs pour identifier les tests individuels à exécuter à partir d'un groupe de test spécifique. Le descripteur de test utilise le format suivant :
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
Vous devez spécifier l'une `Tests` ou l'autre des fonctionnalités de la `Features` liste ou `OneOfTests` pour chacune d'entre elles.
`IsRequired`
La valeur booléenne qui définit si la fonctionnalité est requise dans le rapport de test. La valeur par défaut est `false`.
**Example**
## Contexte de l'orchestrateur de tests
Le contexte de l'orchestrateur de test est un document JSON en lecture seule qui contient les données mises à la disposition de l'orchestrateur de test pendant l'exécution. Le contexte de l'orchestrateur de test n'est accessible que depuis l'orchestrateur de test 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 l'orchestrateur de test utilise le format suivant :
```
{
"pool": {
},
"userData": {
},
"config": {
}
}
```
`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 contenues dans le `config.json` fichier.
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}}`. Lorsque vous accédez aux données depuis le contexte de l'orchestrateur de test, assurez-vous que chaque valeur correspond à une chaîne, un nombre ou 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).
# Configuration de la machine d'état IDT
**Important**
À partir de IDT v4.5.1, cette machine à états est obsolète. Nous vous recommandons vivement d'utiliser le nouvel orchestrateur de test. Pour de plus amples informations, veuillez consulter [Configuration de l'orchestrateur de test IDT](idt-test-orchestrator.md).
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, plutôt que 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 associe 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 `RunTask` les deux `Choice` états dans votre `state_machine.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](create-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.
Comme 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 passe à l'état suivant uniquement 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 seront exécutés 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 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 lorsqu'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 lance 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
+ SDK client IDT pour Java
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 étayer ces arguments, l'orchestrateur de tests de votre suite de tests doit inclure un ensemble `RunTask` et des `Choice` états spécifiques dans votre orchestrateur de tests. Si vous n'utilisez pas de machine à états personnalisée, l'orchestrateur de test 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 un orchestrateur de test personnalisé, utilisez-le [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 orchestrateur de test.
Pour plus d'informations sur les commandes IDT CLI, consultez[Déboguer et exécuter des suites de tests personnalisées](run-debug-custom-tests.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 d'accès au 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 cesse de s'exécuter avant qu'il ne soit terminé 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.
Étant donné que les terminaux propagent 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](set-custom-idt-config.md#config-json-custom). 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-custom-idt-config.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-custom-idt-config.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`test_orchestrator.yaml`, tu utilises`{{query}}`.
Si vous utilisez la machine à états obsolète, alors dans`state_machine.json`, vous utilisez. `{{$.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. Comme la valeur de contexte de premier niveau pour IDT est 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 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-debug-custom-tests.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 l'orchestrateur de test](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 `ssh`.
`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 `ssh`.
Pour vérifier si les testeurs configurent la mauvaise connexion aux appareils pour un test, vous pouvez la récupérer dans le contexte `pool.Devices[0].Connectivity.Protocol` de l'orchestrateur de test 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 `ssh`.
`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 `ssh`.
## (Facultatif) Configurer config.json
Le `config.json` fichier contient des informations de configuration pour IDT. Généralement, 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 les 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-custom-idt-config.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 de débogage, IDT ne lance pas réellement la suite de tests ni n'exécute l'orchestrateur de test ; 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 l'orchestrateur de test 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 requis pour exécuter 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'elle 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é. En général, le niveau du message enregistré est l'un `info` des `warn` suivants : 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`
L'ID du scénario de test en cours d'exécution.
`deviceId`
Identifiant de l'appareil testé utilisé par le scénario de test en cours.
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 orchestrateur de test. 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 Device Tester schéma de rapport
`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 figurant à la fois 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 à l'exécution de 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 soumet les 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 AWS CLI commandes IDT utilisées pour exécuter les tests
+ Les suites de tests exécutées
+ 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/