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.
# AWS IoT Device Tester pour FreeRTOS
L'IDT pour FreeRTOS est un outil permettant de qualifier le débit de données avec le système d'exploitation FreeRTOS. Le testeur de périphériques (IDT) ouvre d'abord une connexion USB ou UART avec un appareil. Il fait ensuite clignoter une image de FreeRTOS configuré pour tester le fonctionnement de l'appareil dans diverses conditions. AWS IoT Device Tester les suites sont extensibles et IDT est utilisé pour l'orchestration des AWS IoT tests clients.
IDT pour FreeRTOS s'exécute sur un ordinateur hôte (Windows, macOS ou Linux) connecté à l'appareil testé. IDT configure et orchestre les cas de test, et agrège les résultats. Il fournit également une interface de ligne de commande pour gérer l'exécution des tests.
## Suite de qualifications FreeRTOS
IDT for FreeRTOS vérifie le port de FreeRTOS sur votre microcontrôleur et vérifie s'il peut communiquer efficacement de manière fiable et sécurisée. AWS IoT Plus précisément, il vérifie si les interfaces de la couche de portage pour les bibliothèques FreeRTOS sont correctement implémentées. Il effectue également end-to-end des tests avec AWS IoT Core. Par exemple, il vérifie si votre forum peut envoyer et recevoir des messages MQTT et les traiter correctement.
[La suite de qualification FreeRTOS (FRQ) 2.0 utilise des cas de tests et Device Advisor définis dans le Guide FreeRTOS-Libraries-Integration-Tests de qualification FreeRTOS.](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html#qualifying-your-device-idt)
IDT for FreeRTOS génère des rapports de test que vous pouvez soumettre AWS à Partner Network (APN) pour inclure vos appareils FreeRTOS dans le catalogue d'appareils partenaires. AWS Pour de plus amples informations, veuillez consulter [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
Le schéma suivant montre la configuration de l'infrastructure de test pour la qualification FreeRTOS.
![\[Organigramme qui montre comment AWS IoT Core interagit avec votre ordinateur et le microcontrôleur.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/devicetester_afr.png)
IDT pour FreeRTOS organise les ressources de test en suites de tests et en groupes de tests :
+ Une suite de tests est un ensemble de groupes de tests utilisés pour vérifier qu'un appareil fonctionne avec des versions spécifiques de FreeRTOS.
+ Un groupe de test est l'ensemble des cas de test individuels liés à une fonctionnalité particulière, telle que la messagerie BLE et MQTT.
Pour de plus amples informations, consultez [Versions de la suite de tests](idt-test-suite-versions.md).
## Comprendre les suites de tests personnalisées
IDT pour FreeRTOS combine une configuration standardisée et un format de résultat avec un environnement de suite de tests. Cet environnement 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 vous configurez les suites de tests personnalisées détermine les configurations de paramètres que vous devez fournir à vos utilisateurs pour exécuter vos suites de tests personnalisées. Pour de plus amples informations, veuillez consulter [Développez et exécutez vos propres suites de tests IDT](idt-custom-tests.md).
# Versions prises en charge de AWS IoT Device Tester
Cette rubrique répertorie les versions prises en charge de AWS IoT Device Tester for FreeRTOS. À titre de bonne pratique, nous vous recommandons d'utiliser la dernière version d'IDT pour FreeRTOS compatible avec votre version cible de FreeRTOS. Chaque version d'IDT pour FreeRTOS possède une ou plusieurs versions correspondantes de FreeRTOS qu'elle prend en charge. Nous vous recommandons de télécharger une nouvelle version d'IDT pour FreeRTOS lorsqu'une nouvelle version de FreeRTOS sera publiée.
En téléchargeant le logiciel, vous acceptez le contrat de AWS IoT Device Tester licence contenu dans l'archive de téléchargement.
**Note**
Lorsque vous utilisez AWS IoT Device Tester FreeRTOS, nous vous recommandons de passer à la dernière version de correctif de la dernière version de FreeRTOS-LTS.
**Important**
Depuis octobre 2022, AWS IoT Device Tester AWS IoT FreeRTOS Qualification (FRQ) 1.0 ne génère pas de rapports de qualification signés. Vous ne pouvez pas qualifier les nouveaux appareils AWS IoT FreeRTOS à répertorier dans [AWS le catalogue des appareils partenaires via le programme de qualification des appareils](https://partners.amazonaws.com/qualified-devices) [utilisant AWS les versions](https://aws.amazon.com/partners/programs/dqp/) IDT FRQ 1.0. Bien que vous ne puissiez pas qualifier les appareils FreeRTOS avec IDT FRQ 1.0, vous pouvez continuer à tester vos appareils FreeRTOS avec FRQ 1.0. [Nous vous recommandons d'utiliser [IDT FRQ 2.0 pour qualifier et répertorier](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) les appareils FreeRTOS dans le catalogue d'appareils partenaires.AWS](https://partners.amazonaws.com/qualified-devices)
## Dernière version de AWS IoT Device Tester for FreeRTOS
Utilisez les liens suivants pour télécharger les dernières versions d'IDT pour FreeRTOS.
**Dernière version de AWS IoT Device Tester for FreeRTOS**
| **AWS IoT Device Tester Version** | **Versions de la suite de tests** | **Versions de FreeRTOS prises en charge** | **Liens de téléchargement** | **Date de sortie** | **Notes de mise à jour** |
| --- | --- | --- | --- | --- | --- |
| IDT v4.9.0 | FRQ\$12.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) | 04/04/2023.04 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) |
**Note**
Nous ne recommandons pas l'exécution d'IDT par plusieurs utilisateurs à partir d'un emplacement partagé, tel qu'un répertoire NFS ou un dossier partagé réseau Windows. Cette pratique peut entraîner des pannes ou une corruption des données. 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.
## Versions IDT antérieures pour FreeRTOS
Les versions antérieures suivantes d'IDT pour FreeRTOS sont également prises en charge.
**Versions antérieures de AWS IoT Device Tester for FreeRTOS**
| **AWS IoT Device Tester Version** | **Versions de la suite de tests** | **Versions de FreeRTOS prises en charge** | **Liens de téléchargement** | **Date de sortie** | **Notes de mise à jour** |
| --- | --- | --- | --- | --- | --- |
| IDT v4.8.1 | FRQ\$12.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) | 23/01/2023 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) |
| IDT v4.6.0 | FRQ\$12.3.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) | 2022.11.16 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) |
| IDT v4.5.11 | FRQ\$12.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) | 2022.10.14 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dev-test-versions-afr.html) |
Pour de plus amples informations, veuillez consulter [Comprendre la politique de support pour AWS IoT Device Tester](idt-support-policy.md).
# Versions IDT non prises en charge pour FreeRTOS
Cette section répertorie les versions non prises en charge d'IDT pour FreeRTOS. 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 [Comprendre la politique de support pour AWS IoT Device Tester](idt-support-policy.md).
Les versions suivantes de IDT-Freertos ne sont plus prises en charge.
**Versions non prises en charge de AWS IoT Device Tester for FreeRTOS**
| **AWS IoT Device Tester Version** | **Versions des suites de tests** | **Versions de FreeRTOS prises en charge** | **Date de sortie** | **Notes de mise à jour** |
| --- | --- | --- | --- | --- |
| IDT v4.5.10 | FRQ\$12.1.4 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.09.02 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.9 | FRQ\$12.1.3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022,08,17 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.6 | FRQ\$12.1.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 29/06/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.5 | FRQ\$12.1.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.06.06 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.5 | FRQ\$12.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.05.31 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.4 | FRQ\$12.0.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.05.09 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.2 | FRQ\$11.6.2 | 202107,00 | 25/01/2022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.3 | FRQ\$11.5.1 | 202012,00 | 2021.07.30 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.3.0 | FRQ\$11.6.1 | 202107,00 | 26/07/2021.07 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.1.0 | FRQ\$11.6.0 | 202107,00 | 2021.07.21 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.1 | FRQ\$11.4.1 | 202012,00 | 2021.01.19 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.4.0 | FRQ\$11.3.0 | 202011,01 | 05/11/2020 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.3.0 | FRQ\$11.2.0 | 202007,00 | 2020,09,17 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.0.2 | FRQ\$11.0.1 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.7.1 | FRQ\$11.0.0 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.6.2 | FRQ\$11.0.0 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.5.2 | FRQ\$11.0.0 | 201910.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.4.1 | FRQ\$11.0.0 | 201908.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.3.2 | FRQ\$11.0.0 | 201906,00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT-Freertos v1.2 | FRQ\$11.0.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/idt-unsupported-versions-afr.html) | | Ajout du support pour tester les appareils FreeRTOS avec le système de construction CMAKE. |
| IDT-Freertos v1.1 | FRQ\$11.0.0 | | | |
| IDT-Freertos v1.0 | FRQ\$11.0.0 | | | |
# Télécharger IDT pour FreeRTOS
Cette rubrique décrit les options de téléchargement d'IDT pour FreeRTOS. Vous pouvez soit utiliser l'un des liens de téléchargement de logiciels suivants, soit suivre les instructions pour télécharger IDT par programmation.
**Important**
Depuis octobre 2022, AWS IoT Device Tester AWS IoT FreeRTOS Qualification (FRQ) 1.0 ne génère pas de rapports de qualification signés. Vous ne pouvez pas qualifier les nouveaux appareils AWS IoT FreeRTOS à répertorier dans le catalogue des appareils [partenaires dans AWS le cadre du programme de qualification des appareils](https://partners.amazonaws.com/qualified-devices) [utilisant AWS les versions](https://aws.amazon.com/partners/programs/dqp/) IDT FRQ 1.0. Bien que vous ne puissiez pas qualifier les appareils FreeRTOS avec IDT FRQ 1.0, vous pouvez continuer à tester vos appareils FreeRTOS avec FRQ 1.0. [Nous vous recommandons d'utiliser [IDT FRQ 2.0 pour qualifier et répertorier](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) les appareils FreeRTOS dans le catalogue d'appareils partenaires.AWS](https://partners.amazonaws.com/qualified-devices)
**Topics**
+ [Télécharger IDT manuellement](#idt-download-options)
+ [Téléchargez IDT par programmation](idt-programmatic-download-process.md)
En téléchargeant le logiciel, vous acceptez le contrat de AWS IoT Device Tester licence contenu dans l'archive de téléchargement.
**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 FreeRTOS. À titre de bonne pratique, nous vous recommandons d'utiliser la dernière version compatible avec votre version cible de FreeRTOS. AWS IoT Device Tester Les nouvelles versions de FreeRTOS peuvent nécessiter le téléchargement d'une nouvelle version de. AWS IoT Device Tester Vous recevez une notification lorsque vous lancez un test s'il n' AWS IoT Device Tester est pas compatible avec la version de FreeRTOS que vous utilisez.
Consultez [Versions prises en charge de AWS IoT Device Tester](dev-test-versions-afr.md).
# Téléchargez IDT par programmation
IDT fournit une opération d'API que vous pouvez utiliser pour récupérer une URL à partir de laquelle 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, avec `iot-device-tester` comme nom du 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 :
`FR`— IDT pour FreeRTOS
ProductVersion
(Facultatif) La version de FreeRTOS. Le service renvoie la dernière version compatible d'IDT pour cette version de FreeRTOS. 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 FreeRTOS](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html).
+ *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#regional-endpoints).
+ *linux*Remplacez-le par le système d'exploitation de votre machine hôte.
+ *202107.00*Remplacez-le par votre version de FreeRTOS.
```
url=$(curl --request GET "https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&ProductVersion=202107.00&TestSuiteType=FR" \
--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 la section [Signature des demandes AWS d'API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.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/IAM/latest/UserGuide/reference_sigv-create-signed-request.html) que vous générez.
```
curl --location --request GET 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&TestSuiteType=FR' \
--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/IAM/latest/UserGuide/reference_sigv.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=FR'
# 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)
```
# IDT avec suite de qualification FreeRTOS 2.0 (FRQ 2.0)
La suite de qualification FreeRTOS 2.0 est une version mise à jour de la suite de qualification FreeRTOS. Nous recommandons aux développeurs d'utiliser FRQ 2.0 car il contient des scénarios de test pertinents pour qualifier les appareils qui exécutent les bibliothèques FreeRTOS Long Term Support (LTS).
IDT pour FreeRTOS vérifie le port de FreeRTOS sur votre microcontrôleur et s'il communique efficacement avec. AWS IoT Plus précisément, il vérifie les interfaces de la couche de portage avec les bibliothèques FreeRTOS et si les référentiels de test FreeRTOS sont correctement implémentés. Il effectue également end-to-end des tests avec AWS IoT Core. [Les tests exécutés par IDT pour FreeRTOS sont définis dans le référentiel FreeRTOS. GitHub](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests)
IDT pour FreeRTOS exécute des tests sous forme d'applications intégrées qu'il fait clignoter sur le microcontrôleur testé. Les images binaires de l'application incluent FreeRTOS, les interfaces FreeRTOS portées et les pilotes de périphériques embarqués. Le but des tests est de vérifier que les interfaces FreeRTOS portées fonctionnent correctement au-dessus des pilotes de votre appareil.
IDT for FreeRTOS génère des rapports de test que vous pouvez soumettre AWS IoT pour que votre matériel soit répertorié dans le AWS catalogue des appareils partenaires. Pour de plus amples informations, veuillez consulter [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
IDT pour FreeRTOS s'exécute sur un ordinateur hôte (Windows, macOS ou Linux) connecté à l'appareil testé. IDT configure et orchestre les cas de test et agrège les résultats. Il fournit également une interface de ligne de commande pour gérer l'exécution des tests.
Afin de tester votre appareil, IDT for FreeRTOS crée des ressources telles que des AWS IoT objets, des groupes FreeRTOS, des fonctions Lambda. Pour créer ces ressources, IDT pour FreeRTOS utilise les informations d'identification configurées dans AWS le pour effectuer des appels d'API en `config.json` votre nom. Ces ressources sont allouées à différents moments d'un test.
Lorsque vous exécutez IDT pour FreeRTOS sur votre ordinateur hôte, il 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.
# Configurez les prérequis de qualification LTS
Cette section décrit les prérequis pour tester les microcontrôleurs avec. AWS IoT Device Tester
## Préparez-vous à la qualification FreeRTOS
**Note**
AWS IoT Device Tester for FreeRTOS recommande vivement d'utiliser le dernier correctif de la dernière version de FreeRTOS-LTS.
IDT pour FRQ 2.0 est une qualification pour FreeRTOS. *Avant de lancer IDT FRQ 2.0 pour la qualification, vous devez terminer la qualification de [votre plateau dans le guide de qualification](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html) FreeRTOS.* Pour porter des bibliothèques, les tester et les configurer`manifest.yml`, consultez la section Portage des bibliothèques [FreeRTOS dans le Guide de portage de *FreeRTOS*](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting.html). FRQ 2.0 contient un processus de qualification différent. Consultez [les derniers changements en matière de qualification](https://docs.aws.amazon.com/freertos/latest/qualificationguide/latest-changes.html) dans le guide de *qualification FreeRTOS pour plus de détails*.
Le référentiel [FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests) doit être présent pour qu'IDT puisse fonctionner. Consultez le [fichier README.md](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/README.md) pour savoir comment cloner et porter ce dépôt vers votre projet source. FreeRTOS-Libraries-Integration-Testsdoit inclure le contenu `manifest.yml` situé à la racine de votre projet, pour que IDT puisse fonctionner.
**Note**
IDT dépend de l'implémentation de`UNITY_OUTPUT_CHAR`. Les journaux des résultats des tests et les journaux des appareils ne doivent pas être entrelacés. Voir [la section Implémentation des macros de journalisation des bibliothèques](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html) dans le Guide de *portage de FreeRTOS* pour plus de détails.
## Télécharger IDT pour FreeRTOS
Chaque version de FreeRTOS possède une version correspondante d'IDT pour FreeRTOS afin d'effectuer des tests de qualification. Téléchargez la version appropriée d'IDT pour FreeRTOS à [partir des versions](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) prises en charge de pour FreeRTOS. AWS IoT Device Tester
Extrayez IDT pour FreeRTOS vers un emplacement du système de fichiers où vous disposez d'autorisations de lecture et d'écriture. Microsoft Windows ayant une limite de caractères pour la longueur du chemin, extrayez IDT pour FreeRTOS dans un répertoire racine tel que ou. `C:\` `D:\`
**Note**
Plusieurs utilisateurs ne doivent pas exécuter IDT à partir d'un emplacement partagé, tel qu'un répertoire NFS ou un dossier partagé sur le réseau Windows. Cela entraînera des pannes ou une corruption des données. Nous vous recommandons d'extraire le package IDT sur un disque local.
## Télécharger Git
Git doit être installé sur IDT comme condition préalable pour garantir l'intégrité du code source.
Suivez les instructions du [GitHub](https://github.com/git-guides/install-git)guide pour installer Git. Pour vérifier la version actuellement installée de Git, entrez la commande `git --version` sur le terminal.
**Avertissement**
IDT utilise Git pour s'aligner sur le statut propre ou sale d'un répertoire. Si Git n'est pas installé, les groupes de `FreeRTOSIntegrity` test échoueront ou ne s'exécuteront pas comme prévu. Si IDT renvoie une erreur telle que `git executable not found` ou`git command not found`, installez ou réinstallez Git et réessayez.
**Topics**
+ [Préparez-vous à la qualification FreeRTOS](#idt-preparing-qualification)
+ [Télécharger IDT pour FreeRTOS](#idt-download-dev-tester-afr)
+ [Télécharger Git](#idt-download-git)
+ [Créez un AWS compte](#lts-config-aws-account)
+ [AWS IoT Device Tester politique gérée](#managed-policy)
+ [(Facultatif) Installez le AWS Command Line Interface](#install-cli)
## Créez un AWS compte
**Note**
La suite de qualification IDT complète n'est prise en charge que dans les cas suivants Régions AWS
USA Est (Virginie du Nord)
USA Ouest (Oregon)
Asie Pacifique (Tokyo)
Europe (Irlande)
Afin de tester votre appareil, IDT for FreeRTOS crée des ressources telles que des AWS IoT objets, des groupes FreeRTOS et des fonctions Lambda. Pour créer ces ressources, IDT for FreeRTOS nécessite que vous créiez et configuriez AWS un compte, ainsi qu'une politique IAM qui accorde à IDT for FreeRTOS l'autorisation d'accéder aux ressources en votre nom lors de l'exécution des tests.
Les étapes suivantes consistent à créer et à configurer votre AWS compte.
1. Si vous avez déjà un AWS compte, passez à l'étape suivante. Sinon, créez un [AWS compte](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/).
1. Suivez les étapes décrites dans [Création de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html). N'ajoutez pas d'autorisations ou de politiques pour le moment.
1. Pour exécuter des tests de qualification OTA, passez à l'étape 4. Sinon, passez à l'étape 5.
1. Associez la politique intégrée d'autorisations OTA IAM à votre rôle IAM.
1.
**Important**
Le modèle de stratégie suivant accorde à IDT l'autorisation de créer des rôles, de créer des stratégies et d'attacher des stratégies à des rôles. IDT pour FreeRTOS utilise ces autorisations pour les tests qui créent des rôles. Bien que le modèle de politique ne fournisse pas de privilèges d'administrateur à l'utilisateur, les autorisations peuvent être utilisées pour obtenir un accès administrateur à votre AWS compte.
1. Suivez les étapes ci-dessous pour associer les autorisations nécessaires à votre rôle IAM :
1. Sur la page **Autorisations**, choisissez **Ajouter des autorisations**.
1. Choisissez **Créer une politique en ligne**.
1. Sélectionnez l'onglet **JSON** et copiez les autorisations suivantes dans la zone de texte **JSON**. Utilisez le modèle sous **La plupart des régions** si vous n'êtes pas dans la région de Chine. Si vous vous trouvez dans la région de Chine, utilisez le modèle sous **Régions de Pékin et du Ningxia**.
------
#### [ Most Regions ]
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iotdeviceadvisor:*",
"Resource": [
"arn:aws:iotdeviceadvisor:*:*:suiterun/*/*",
"arn:aws:iotdeviceadvisor:*:*:suitedefinition/*"
]
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/idt*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "iotdeviceadvisor.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke*",
"iam:ListRoles",
"iot:Connect",
"iot:CreateJob",
"iot:DeleteJob",
"iot:DescribeCertificate",
"iot:DescribeEndpoint",
"iot:DescribeJobExecution",
"iot:DescribeJob",
"iot:DescribeThing",
"iot:GetPolicy",
"iot:ListAttachedPolicies",
"iot:ListCertificates",
"iot:ListPrincipalPolicies",
"iot:ListThingPrincipals",
"iot:ListThings",
"iot:Publish",
"iot:UpdateThingShadow",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:PutRetentionPolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iotdeviceadvisor:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "logs:DeleteLogGroup",
"Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*"
},
{
"Effect": "Allow",
"Action": "logs:GetLogEvents",
"Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*:log-stream:*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreatePolicy",
"iam:DetachRolePolicy",
"iam:DeleteRolePolicy",
"iam:DeletePolicy",
"iam:CreateRole",
"iam:DeleteRole",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::*:policy/idt*",
"arn:aws:iam::*:role/idt*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters"
],
"Resource": [
"arn:aws:ssm:*::parameter/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:RunInstances",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateKeyPair",
"ec2:DeleteKeyPair"
],
"Resource": [
"arn:aws:ec2:*:*:key-pair/idt-ec2-ssh-key-*"
]
},
{
"Effect": "Allow",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:ResourceTag/Owner": "IoTDeviceTester"
}
},
"Action": [
"ec2:TerminateInstances",
"ec2:DeleteSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupIngress"
],
"Resource": [
"*"
]
}
]
}
```
------
------
#### [ Beijing and Ningxia Regions ]
Le modèle de politique suivant peut être utilisé dans les régions de Pékin et de Ningxia.
------
1. Lorsque vous avez terminé, sélectionnez **Review policy (Examiner une politique)**.
1. Entrez **IDTFreeRTOSIAMPermissions**comme nom de la politique.
1. Choisissez **Create Policy** (Créer une politique).
1. Associez **AWSIoTDeviceTesterForFreeRTOSFullAccess** à votre rôle IAM.
1. Pour associer les autorisations nécessaires à votre rôle IAM, procédez comme suit :
1. Sur la page **Autorisations**, choisissez **Ajouter des autorisations**.
1. Choisissez **Attacher des politiques**.
1. Recherchez la politique **AWSIoTDeviceTesterForFreeRTOSFulld'accès**. Cochez la case.
1. Choisissez **Ajouter des autorisations**.
1. Exportez les informations d'identification pour IDT. Voir [Obtenir les informations d'identification du rôle IAM pour l'accès à la CLI](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html) pour plus de détails.
## AWS IoT Device Tester politique gérée
La politique `AWSIoTDeviceTesterForFreeRTOSFullAccess` gérée contient les AWS IoT Device Tester autorisations suivantes pour la vérification des versions, les fonctionnalités de mise à jour automatique et la collecte de métriques.
+ `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 de la suite de tests.
+ `iot-device-tester:SendMetrics`
Accorde AWS l'autorisation de collecter des statistiques relatives à l'utilisation AWS IoT Device Tester interne.
## (Facultatif) Installez le AWS Command Line Interface
Vous préférerez peut-être utiliser le AWS CLI pour effectuer certaines opérations. Si vous ne l'avez pas AWS CLI installé, suivez les instructions de la section [Installer le AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html).
Configurez le AWS CLI pour la AWS région que vous souhaitez utiliser en l'exécutant à **aws configure** partir d'une ligne de commande. [Pour plus d'informations sur les AWS régions qui prennent en charge IDT pour FreeRTOS,AWS consultez Régions et points de terminaison.](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control) Pour plus d'informations sur la **aws configure** section [Configuration rapide avec **aws configure**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config).
# Premier test de votre carte microcontrôleur
Vous pouvez utiliser IDT pour FreeRTOS pour tester votre implémentation des bibliothèques FreeRTOS. Après avoir porté les bibliothèques FreeRTOS pour les pilotes de périphériques de votre carte, exécutez-les pour exécuter les tests AWS IoT Device Tester de qualification sur votre carte microcontrôleur.
## Ajouter des couches de transfert pour les bibliothèques
Pour transférer FreeRTOS sur votre appareil, consultez le Guide de portage de [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/porting-guide.html). Lors de l'implémentation du référentiel de tests FreeRTOS et du portage des couches FreeRTOS, vous devez fournir `manifest.yml` un chemin d'accès à chaque bibliothèque, y compris le référentiel de tests. Ce fichier se trouvera dans le répertoire racine de votre code source. Consultez les [instructions du fichier manifeste](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist-manifest-instr.html) pour plus de détails.
## Configurez vos AWS informations d'identification AWS IoT Device Tester pour communiquer avec le AWS cloud
Vous devez configurer vos AWS informations d'identification AWS IoT Device Tester pour pouvoir communiquer avec le AWS Cloud. Pour plus d'informations, voir [Configurer les AWS informations d'identification et la région pour le développement](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html). Les AWS informations d'identification valides sont spécifiées dans le fichier `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/config.json` de configuration.
```
"auth": {
"method": "environment"
}
"auth": {
"method": "file",
"credentials": {
"profile": ""
}
}
```
L'`auth`attribut du `config.json` fichier possède un champ de méthode qui contrôle AWS l'authentification et peut être déclaré en tant que fichier ou environnement. La définition du champ sur environnement extrait vos AWS informations d'identification des variables d'environnement de votre machine hôte. La définition du champ sur fichier permet d'importer un profil spécifié à partir du fichier de `.aws/credentials` configuration.
**Topics**
+ [Ajouter des couches de transfert pour les bibliothèques](#lts-add-port-layer)
+ [Configurez vos AWS informations d'identification AWS IoT Device Tester pour communiquer avec le AWS cloud](#lts-cfg-aws-afr)
+ [Créer un pool d'appareils dans IDT pour FreeRTOS](lts-cfg-dt-dp.md)
+ [Configurer les paramètres de création, de flash et de test](lts-cfg-dt-ud.md)
# Créer un pool d'appareils dans IDT pour FreeRTOS
Les appareils à tester sont organisés dans des groupes. Chaque groupe d'appareils se compose d'un ou de plusieurs appareils identiques. Vous pouvez configurer IDT pour FreeRTOS afin de tester un seul appareil ou plusieurs appareils dans un pool. Pour accélérer le processus de qualification, IDT for FreeRTOS peut tester des appareils avec les mêmes spécifications en parallèle. Il utilise une méthode séquentielle pour exécuter un groupe de tests différents pour chaque appareil d'un groupe.
Le `device.json` fichier possède un tableau à son niveau supérieur. Chaque attribut du tableau correspond à un nouveau pool de périphériques. Chaque pool de périphériques possède un attribut de tableau d'appareils, dans lequel plusieurs appareils sont déclarés. Dans le modèle, il existe un pool de périphériques et un seul appareil dans ce pool de périphériques. Vous pouvez ajouter un ou plusieurs appareils à un groupe d'appareils en modifiant la section `devices` du modèle `device.json` dans le dossier `configs`.
**Note**
Tous les appareils d'un même pool doivent avoir les mêmes spécifications techniques et le même SKU. Pour permettre des compilations parallèles du code source pour différents groupes de test, IDT pour FreeRTOS copie le code source dans un dossier de résultats à l'intérieur du dossier extrait d'IDT pour FreeRTOS. Vous devez référencer le chemin du code source dans votre commande de build ou de flash à l'aide de la `testdata.sourcePath` variable. IDT pour FreeRTOS remplace cette variable par un chemin temporaire du code source copié. Pour de plus amples informations, veuillez consulter [IDT pour les variables FreeRTOS](lts-dt-vars.md).
Voici un exemple de `device.json` fichier qui a été utilisé pour créer un pool de périphériques avec plusieurs appareils.
```
[
{
"id": "pool-id",
"sku": "sku",
"features": [
{
"name": "Wifi",
"value": "Yes | No"
},
{
"name": "Cellular",
"value": "Yes | No"
},
{
"name": "BLE",
"value": "Yes | No"
},
{
"name": "PKCS11",
"value": "RSA | ECC | Both"
},
{
"name": "OTA",
"value": "Yes | No",
"configs": [
{
"name": "OTADataPlaneProtocol",
"value": "MQTT | HTTP | None"
}
]
},
{
"name": "KeyProvisioning",
"value": "Onboard | Import | Both | No"
}
],
"devices": [
{
"id": "device-id",
"connectivity": {
"protocol": "uart",
"serialPort": "/dev/tty*"
},
"secureElementConfig" : {
"publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key",
"publiDeviceCertificateArn": "arn:partition:iot:region:account-id:resourcetype:resource:qualifier",
"secureElementSerialNumber": "secure-element-serialNo-value",
"preProvisioned" : "Yes | No",
"pkcs11JITPCodeVerifyRootCertSupport": "Yes | No"
},
"identifiers": [
{
"name": "serialNo",
"value": "serialNo-value"
}
]
}
]
}
]
```
Les attributs suivants sont utilisés dans le fichier `device.json` :
** `id` **
Un ID alphanumérique défini par l'utilisateur qui identifie de façon unique un groupe d'appareils. Les appareils appartenant à un groupe doivent être du même type. Lorsque vous exécutez une suite de tests, les appareils du groupe sont utilisés pour paralléliser la charge de travail.
** `sku` **
Une valeur alphanumérique qui identifie de façon unique la carte que vous testez. La référence est utilisée pour effectuer le suivi des cartes qualifiées.
Si vous souhaitez mettre votre carte en vente dans le catalogue des appareils AWS partenaires, le SKU que vous spécifiez ici doit correspondre au SKU que vous avez utilisé lors du processus de mise en vente.
** `features` **
Tableau contenant les fonctionnalités prises en charge par l'appareil. AWS IoT Device Tester utilise ces informations pour sélectionner les tests de qualification à exécuter.
Les valeurs prises en charge sont :
** `Wifi` **
Indique si la carte contient des fonctionnalités Wi-Fi.
** `Cellular` **
Indique si votre carte est dotée de fonctionnalités cellulaires.
** `PKCS11` **
Indique l'algorithme de cryptographie à clé publique pris en charge par la carte. PKCS11 est requis pour la qualification. Les valeurs prises en charge sont `ECC``RSA`, et`Both`. `Both`indique que le tableau prend en charge les deux `ECC` et`RSA`.
** `KeyProvisioning` **
Indique la méthode d'écriture d'un certificat client X.509 approuvé sur votre carte.
Les valeurs valides sont `Import``Onboard`, `Both` et`No`. `Onboard``Both`, ou l'approvisionnement `No` des clés est requis pour la qualification. `Import`à elle seule, n'est pas une option valide pour la qualification.
+ À utiliser `Import` uniquement si votre forum autorise l'importation de clés privées. `Import`La sélection n'est pas une configuration valide pour la qualification et ne doit être utilisée qu'à des fins de test, en particulier pour les cas de PKCS11 test. `Onboard`, `Both` ou `No` est requis pour la qualification.
+ À utiliser `Onboard` si votre carte prend en charge les clés privées intégrées (par exemple, si votre appareil possède un élément sécurisé ou si vous préférez générer votre propre paire de clés et votre propre certificat). Veillez à ajouter un élément `secureElementConfig` dans chacune des sections de l'appareil et indiquez le chemin absolu vers le fichier de clé publique dans le champ `publicKeyAsciiHexFilePath`.
+ À utiliser `Both` si votre tableau prend en charge à la fois l'importation de clés privées et la génération de clés intégrée pour le provisionnement des clés.
+ À utiliser `No` si votre tableau ne prend pas en charge l'approvisionnement en clés. `No`n'est une option valide que lorsque votre appareil est également préconfiguré.
** `OTA` **
Indique si votre carte mère prend en charge la fonctionnalité de mise à jour over-the-air (OTA). L'attribut `OtaDataPlaneProtocol` indique le protocole de plan de données OTA pris en charge par le périphérique. L'OTA avec le protocole de plan de données HTTP ou MQTT est requis pour la qualification. Pour ignorer l'exécution des tests OTA pendant les tests, définissez la fonctionnalité OTA sur `No` et l'`OtaDataPlaneProtocol`attribut sur`None`. Il ne s'agira pas d'une course de qualification.
** `BLE` **
Indique si la carte prend en charge Bluetooth Low Energy (BLE).
** `devices.id` **
Un identificateur unique défini par l'utilisateur pour l'appareil testé.
** `devices.connectivity.serialPort` **
Le port série de l'ordinateur hôte utilisé pour se connecter aux appareils testés.
** `devices.secureElementConfig.PublicKeyAsciiHexFilePath` **
Obligatoire si votre planche n'est PAS `pre-provisioned` ou n'`PublicDeviceCertificateArn`est pas fournie. Comme `Onboard` il s'agit d'un type obligatoire de fourniture de clés, ce champ est actuellement obligatoire pour le groupe de test FullTransportInterface TLS. Si votre appareil l'est`pre-provisioned`, `PublicKeyAsciiHexFilePath` il est facultatif et n'a pas besoin d'être inclus.
Le bloc suivant est un chemin absolu vers le fichier contenant la clé publique en octets hexadécimaux extraite de la clé `Onboard` privée.
```
3059 3013 0607 2a86 48ce 3d02 0106 082a
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c
```
Si votre clé publique est au format .der, vous pouvez l'encoder directement en hexadécimal pour générer le fichier hexadécimal.
Pour générer le fichier hexadécimal à partir d'une clé publique .der, entrez la commande suivante : **xxd**
```
xxd -p pubkey.der > outFile
```
Si votre clé publique est au format .pem, vous pouvez extraire les en-têtes et pieds de page codés en base64 et les décoder au format binaire. Ensuite, vous codez la chaîne binaire en hexadécimal pour générer le fichier hexadécimal.
Pour générer un fichier hexadécimal pour une clé publique .pem, procédez comme suit :
1. Exécutez la **base64** commande suivante pour supprimer l'en-tête et le pied de page base64 de la clé publique. La clé décodée, nommée`base64key`, est ensuite sortie dans le fichier `pubkey.der` :
```
base64 —decode base64key > pubkey.der
```
1. Exécutez la **xxd** commande suivante pour convertir `pubkey.der` au format hexadécimal. La clé obtenue est enregistrée sous `outFile`
```
xxd -p pubkey.der > outFile
```
** `devices.secureElementConfig.PublicDeviceCertificateArn` **
L'ARN du certificat de votre élément sécurisé qui est téléchargé vers AWS IoT Core. Pour plus d'informations sur le téléchargement de votre certificat vers AWS IoT Core, consultez la section [Certificats client X.509](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html) dans le guide du *AWS IoT développeur*.
** `devices.secureElementConfig.SecureElementSerialNumber` **
(Facultatif) Numéro de série de l'élément sécurisé. Le numéro de série est éventuellement utilisé pour créer des certificats d'appareil pour le provisionnement des clés JITR.
** `devices.secureElementConfig.preProvisioned` **
(Facultatif) Réglez sur « Oui » si l'appareil possède un élément sécurisé préconfiguré avec des informations d'identification verrouillées, qui ne peut pas importer, créer ou détruire des objets. Si cet attribut est défini sur **Oui**, vous devez fournir les étiquettes pkcs11 correspondantes.
** `devices.secureElementConfig.pkcs11JITPCodeVerifyRootCertSupport` **
(Facultatif) Définissez ce paramètre sur **Oui** si l'PKCS11 implémentation principale de l'appareil prend en charge le stockage pour JITP. Cela permettra le test JITP lors du `codeverify` test du noyau PKCS 11 et nécessitera la fourniture d'étiquettes de clé de vérification du code, de certificat JITP et de certificat racine PKCS 11.
** `identifiers` **
(Facultatif) Un tableau de paires nom-valeur arbitraires. Vous pouvez utiliser ces valeurs dans les commandes de création et flash décrites dans la section suivante.
# Configurer les paramètres de création, de flash et de test
IDT pour FreeRTOS crée et affiche automatiquement les tests sur votre carte. Pour activer cela, vous devez configurer IDT pour exécuter les commandes de compilation et de flash pour votre matériel. Les paramètres de création et flash sont configurés dans le modèle de fichier `userdata.json` situé dans le dossier `config`.
# Configurer les paramètres pour tester un seul appareil
Les paramètres de création, de flash et de test sont définis dans le fichier `configs/userdata.json`. L'exemple JSON suivant montre comment configurer IDT pour FreeRTOS afin de tester plusieurs appareils :
```
{
"sourcePath": "",
"retainModifiedSourceDirectories": true | false,
"freeRTOSVersion": "",
"freeRTOSTestParamConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_param_config.h",
"freeRTOSTestExecutionConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_execution_config.h",
"buildTool": {
"name": "your-build-tool-name",
"version": "your-build-tool-version",
"command": [
" -any-additional-flags {{testData.sourcePath}}"
]
},
"flashTool": {
"name": "your-flash-tool-name",
"version": "your-flash-tool-version",
"command": [
" -any-additional-flags {{testData.sourcePath}} -any-additional-flags"
]
},
"testStartDelayms": 0,
"echoServerConfiguration": {
"keyGenerationMethod": "EC | RSA",
"serverPort": 9000
},
"otaConfiguration": {
"otaE2EFirmwarePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process",
"otaPALCertificatePath": "/path/to/ota/pal/certificate/on/device",
"deviceFirmwarePath" : "/path/to/firmware/image/name/on/device",
"codeSigningConfiguration": {
"signingMethod": "AWS | Custom",
"signerHashingAlgorithm": "SHA1 | SHA256",
"signerSigningAlgorithm": "RSA | ECDSA",
"signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file",
"untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier",
"signerCertificateFileName": "signerCertificate-file-name",
"compileSignerCertificate": true | false,
// ***********Use signerPlatform if you choose AWS for signingMethod***************
"signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF"
]
}
},
**********
This section is used for PKCS #11 labels of private key, public key, device certificate, code verification key, JITP certificate, and root certificate.
When configuring PKCS11, you set up labels and you must provide the labels of the device certificate, public key,
and private key for the key generation type (EC or RSA) it was created with. If your device supports PKCS11 storage of JITP certificate,
code verification key, and root certificate, set 'pkcs11JITPCodeVerifyRootCertSupport' to 'Yes' in device.json and provide the corresponding labels.
**********
"pkcs11LabelConfiguration":{
"pkcs11LabelDevicePrivateKeyForTLS": "",
"pkcs11LabelDevicePublicKeyForTLS": "",
"pkcs11LabelDeviceCertificateForTLS": "",
"pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS": "",
"pkcs11LabelPreProvisionedECDevicePublicKeyForTLS": "",
"pkcs11LabelPreProvisionedECDeviceCertificateForTLS": "",
"pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS": "",
"pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS": "",
"pkcs11LabelPreProvisionedRSADeviceCertificateForTLS": "",
"pkcs11LabelCodeVerifyKey": "",
"pkcs11LabelJITPCertificate": "",
"pkcs11LabelRootCertificate": ""
}
}
```
Voici les attributs utilisés dans le fichier `userdata.json` :
** `sourcePath` **
Le chemin d'accès à la racine du code source FreeRTOS porté.
** `retainModifiedSourceDirectories` **
(Facultatif) Vérifie s'il faut conserver les répertoires sources modifiés utilisés lors de la construction et du flashage à des fins de débogage. S'il est défini sur`true`, les répertoires sources modifiés sont nommés RetainedSrc et se trouvent dans les dossiers du journal des résultats de chaque groupe de test exécuté. S'il n'est pas inclus, le champ est défini par défaut sur. `false`
** `freeRTOSTestParamConfigPath` **
Le chemin d'accès au `test_param_config.h` fichier à FreeRTOS-Libraries-Integration-Tests intégrer. Ce fichier doit utiliser la variable `{{testData.sourcePath}}` placeholder pour le rendre relatif à la racine du code source. AWS IoT Device Tester utilise les paramètres de ce fichier pour configurer les tests.
** `freeRTOSTestExecutionConfigPath` **
Le chemin d'accès au `test_execution_config.h` fichier à FreeRTOS-Libraries-Integration-Tests intégrer. Ce fichier doit utiliser la variable d'`{{testData.sourcePath}}`espace réservé pour le rendre relatif à la racine du dépôt. AWS IoT Device Tester utilise ce fichier pour contrôler les tests à exécuter.
** `freeRTOSVersion` **
La version de FreeRTOS, y compris la version de correctif utilisée dans votre implémentation. Voir [Versions prises en charge de AWS IoT Device Tester pour FreeRTOS](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) pour les versions de FreeRTOS compatibles avec FreeRTOS. AWS IoT Device Tester
** `buildTool` **
La commande permettant de créer votre code source. Toutes les références au chemin du code source dans la commande de construction doivent être remplacées par la AWS IoT Device Tester variable`{{testData.sourcePath}}`. Utilisez l'`{{config.idtRootPath}}`espace réservé pour référencer un script de génération relatif au chemin AWS IoT Device Tester racine.
** `flashTool` **
Commande permettant de flasher une image sur votre appareil. Toutes les références au chemin du code source dans la commande flash doivent être remplacées par la AWS IoT Device Tester variable`{{testData.sourcePath}}`. Utilisez l'`{{config.idtRootPath}}`espace réservé pour référencer un script flash relatif au chemin AWS IoT Device Tester racine.
La nouvelle structure des tests d'intégration avec FRQ 2.0 ne nécessite pas de variables de chemin telles que `{{enableTests}}` et`{{buildImageName}}`. Les tests OTA de bout en bout sont exécutés avec les modèles de configuration fournis dans le [ FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/config_template/) GitHub référentiel. Si les fichiers du GitHub référentiel sont présents dans votre projet source parent, le code source n'est pas modifié entre les tests. Si une image de compilation différente pour OTA de bout en bout est nécessaire, vous devez créer cette image dans le script de génération et la spécifier dans le `userdata.json` fichier spécifié ci-dessous`otaConfiguration`.
** `testStartDelayms` **
Spécifie le nombre de millisecondes que le lanceur de tests FreeRTOS attendra avant de commencer à exécuter les tests. Cela peut être utile si l'appareil testé commence à produire des informations de test importantes avant qu'IDT n'ait la chance de se connecter et de commencer à se connecter en raison de problèmes de réseau ou d'autres problèmes de latence. Cette valeur s'applique uniquement aux groupes de test FreeRTOS, et non aux autres groupes de test qui n'utilisent pas le lanceur de tests FreeRTOS, tels que les tests OTA. Si vous recevez une erreur liée à la valeur **10 attendue mais que vous en avez reçu 5**, ce champ doit être défini sur 5000.
** `echoServerConfiguration` **
Configuration permettant de configurer le serveur d'écho pour le test TLS. Ce champ est obligatoire.
** `keyGenerationMethod` **
Le serveur Echo est configuré avec cette option. Les options sont EC ou RSA.
** `serverPort` **
Le numéro de port sur lequel s'exécute le serveur Echo.
** `otaConfiguration` **
Configuration pour les tests OTA PAL et OTA E2E. Ce champ est obligatoire.
**`otaE2EFirmwarePath`**
Chemin d'accès à l'image du bin OTA qu'IDT utilise pour les tests OTA de bout en bout.
** `otaPALCertificatePath` **
Le chemin d'accès au certificat pour le test OTA PAL sur l'appareil. Ceci est utilisé pour vérifier la signature. Par exemple, **ecdsa-sha256-signer.crt.pem**.
** `deviceFirmwarePath` **
Chemin d'accès au nom codé en dur de l'image du microprogramme à démarrer. Si votre appareil n'utilise PAS le système de fichiers pour le démarrage du microprogramme, spécifiez ce champ sous la forme`'NA'`. Si votre appareil utilise le système de fichiers pour le démarrage du microprogramme, spécifiez le chemin ou le nom de l'image de démarrage du microprogramme.
** `codeSigningConfiguration` **
** `signingMethod` **
Méthode de signature de code. Les valeurs possibles sont AWS ou Custom.
Pour les régions de Pékin et de Ningxia, utilisez Custom. AWS la signature de code n'est pas prise en charge dans cette région.
** `signerHashingAlgorithm` **
Algorithme de hachage pris en charge sur le périphérique. Les valeurs possibles sont `SHA1` ou `SHA256`.
** `signerSigningAlgorithm` **
Algorithme de signature pris en charge sur le périphérique. Les valeurs possibles sont `RSA` ou `ECDSA`.
** `signerCertificate` **
Certificat de confiance utilisé pour l'OTA. Pour la méthode de signature AWS du code, utilisez l'Amazon Resource Name (ARN) pour le certificat sécurisé chargé sur le AWS Certificate Manager. Pour la méthode de signature de code personnalisée, utilisez le chemin absolu vers le fichier de certificat du signataire. Pour plus d'informations sur la création d'un certificat sécurisé, voir [Création d'un certificat de signature de code](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html).
** `untrustedSignerCertificate` **
L'ARN ou le chemin de fichier d'un deuxième certificat utilisé dans certains tests OTA en tant que certificat non fiable. Pour plus d'informations sur la création d'un certificat, voir [Création d'un certificat de signature de code](https://docs.aws.amazon.com//freertos/latest/userguide/ota-code-sign-cert.html).
** `signerCertificateFileName` **
Nom de fichier du certificat de signature de code sur l'appareil. Cette valeur doit correspondre au nom de fichier que vous avez fourni lors de l'exécution de la `aws acm import-certificate` commande.
** `compileSignerCertificate` **
Valeur booléenne qui détermine le statut du certificat de vérification de signature. Les valeurs valides sont `true` et `false`.
Définissez cette valeur sur **true** si le certificat de vérification de signature du signataire du code n'est pas fourni ou flashé. Il doit être compilé dans le projet. AWS IoT Device Tester récupère le certificat sécurisé et le compile dans. `aws_codesigner_certificate.h`
** `signerPlatform` **
Algorithme de signature et de hachage utilisé par AWS Code Signer lors de la création de la tâche de mise à jour OTA. Actuellement, les valeurs possibles pour ce champ sont `AmazonFreeRTOS-TI-CC3220SF` et `AmazonFreeRTOS-Default`.
+ Choisissez `AmazonFreeRTOS-TI-CC3220SF`, si `SHA1` et `RSA`.
+ Choisissez `AmazonFreeRTOS-Default`, si `SHA256` et `ECDSA`.
+ Si vous avez besoin de `SHA256` \$1 `RSA` ou `SHA1` \$1 `ECDSA` pour votre configuration, contactez-nous pour obtenir une assistance complémentaire.
+ Configurez `signCommand` si vous avez choisi `Custom` pour `signingMethod`.
** `signCommand` **
Deux espaces réservés `{{inputImageFilePath}}` et `{{outputSignatureFilePath}}` sont obligatoires dans la commande. `{{inputImageFilePath}}` est le chemin d'accès au fichier de l'image créée par IDT qu’il faut signer. `{{outputSignatureFilePath}} ` est le chemin d’accès au fichier de la signature qui sera généré par le script.
** `pkcs11LabelConfiguration` **
PKCS11 la configuration des étiquettes nécessite au moins un ensemble d'étiquettes d'étiquette de certificat de périphérique, d'étiquette de clé publique et d'étiquette de clé privée pour exécuter les groupes de PKCS11 test. Les PKCS11 étiquettes requises sont basées sur la configuration de votre appareil dans le `device.json` fichier. Si le paramètre pré-provisionné est défini sur **Oui**`device.json`, les étiquettes requises doivent être l'une des suivantes en fonction de ce qui est choisi pour la PKCS11 fonctionnalité.
+ `PreProvisionedEC`
+ `PreProvisionedRSA`
Si le préprovisionnement est défini sur **Non**`device.json`, les étiquettes requises sont les suivantes :
+ `pkcs11LabelDevicePrivateKeyForTLS`
+ `pkcs11LabelDevicePublicKeyForTLS`
+ `pkcs11LabelDeviceCertificateForTLS`
Les trois libellés suivants sont obligatoires uniquement si vous sélectionnez **Oui** pour `pkcs11JITPCodeVerifyRootCertSupport` dans votre `device.json` fichier.
+ `pkcs11LabelCodeVerifyKey`
+ `pkcs11LabelRootCertificate`
+ `pkcs11LabelJITPCertificate`
Les valeurs de ces champs doivent correspondre aux valeurs définies dans le Guide de portage de [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html).
** `pkcs11LabelDevicePrivateKeyForTLS` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé privée. Pour les appareils dotés d'un support intégré et d'importation pour l'approvisionnement des clés, cette étiquette est utilisée à des fins de test. Cette étiquette peut être différente de celle définie pour le boîtier préapprovisionné. Si le provisionnement des clés est défini sur **Non** et que le préprovisionnement est défini sur **Oui**`device.json`, ce paramètre ne sera pas défini.
** `pkcs11LabelDevicePublicKeyForTLS` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé publique. Pour les appareils dotés d'un support intégré et d'importation pour l'approvisionnement des clés, cette étiquette est utilisée à des fins de test. Cette étiquette peut être différente de celle définie pour le boîtier préapprovisionné. Si le provisionnement des clés est défini sur **Non** et que le préprovisionnement est défini sur **Oui**`device.json`, ce paramètre ne sera pas défini.
** `pkcs11LabelDeviceCertificateForTLS` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 du certificat de l'appareil. Pour les appareils dotés d'un support intégré et d'importation pour l'approvisionnement des clés, cette étiquette sera utilisée à des fins de test. Cette étiquette peut être différente de celle définie pour le boîtier préapprovisionné. Si le provisionnement des clés est défini sur **Non** et que le préprovisionnement est défini sur **Oui**`device.json`, ce paramètre ne sera pas défini.
** `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé privée. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préapprovisionnement avec une clé EC, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS`, doivent être fournies. Cette étiquette peut être différente de celle définie pour les valises à bord et les valises d'importation.
** `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé publique. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préapprovisionnement avec une clé EC, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS`, doivent être fournies. Cette étiquette peut être différente de celle définie pour les valises à bord et les valises d'importation.
** `pkcs11LabelPreProvisionedECDeviceCertificateForTLS` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 du certificat de l'appareil. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préapprovisionnement avec une clé EC, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedRSADeviceCertificateForTLS`, doivent être fournies. Cette étiquette peut être différente de celle définie pour les valises à bord et les valises d'importation.
** `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé privée. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préprovisionnement à l'aide d'une clé RSA, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS`, doivent être fournies.
** `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé publique. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préprovisionnement à l'aide d'une clé RSA, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedECDevicePublicKeyForTLS`, doivent être fournies.
** `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 du certificat de l'appareil. Pour les appareils dotés d'éléments sécurisés ou présentant des limitations matérielles, celui-ci portera une étiquette différente afin de préserver les AWS IoT informations d'identification. Si votre appareil prend en charge le préprovisionnement à l'aide d'une clé RSA, fournissez cette étiquette. Lorsque PreProvisioned est défini sur **Yes** in`device.json`, cette étiquette, ou les deux`pkcs11LabelPreProvisionedECDeviceCertificateForTLS`, doivent être fournies.
** `pkcs11LabelCodeVerifyKey` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 de la clé de vérification du code. Si votre appareil prend en charge le stockage PKCS \$111 du certificat JITP, de la clé de vérification du code et du certificat racine, fournissez cette étiquette. Lorsque `pkcs11JITPCodeVerifyRootCertSupport` la `device.json` valeur Oui est définie sur **Oui**, cette étiquette doit être fournie.
** `pkcs11LabelJITPCertificate` **
(Facultatif) Cette étiquette est utilisée pour l'étiquette PKCS \$111 du certificat JITP. Si votre appareil prend en charge le stockage PKCS \$111 du certificat JITP, de la clé de vérification du code et du certificat racine, fournissez cette étiquette. Lorsque `pkcs11JITPCodeVerifyRootCertSupport` la `device.json` valeur Oui est définie sur **Oui**, cette étiquette doit être fournie.
# IDT pour les variables FreeRTOS
Les commandes permettant de créer votre code et de flasher l'appareil peuvent nécessiter une connectivité ou d'autres informations sur vos appareils pour fonctionner correctement. AWS IoT Device Tester vous permet de référencer les informations du périphérique dans Flash et de créer des commandes à l'aide de [JsonPath](https://goessner.net/articles/JsonPath/). À l'aide d' JsonPathexpressions simples, vous pouvez récupérer les informations requises spécifiées dans votre `device.json` fichier.
## Variables de chemin
IDT pour FreeRTOS définit les variables de chemin suivantes qui peuvent être utilisées dans les lignes de commande et les fichiers de configuration :
** `{{testData.sourcePath}}` **
Développe le code source du chemin d'accès. Si vous utilisez cette variable, elle doit être utilisée dans les commandes flash et build.
** `{{device.connectivity.serialPort}}` **
Extension au port série.
** `{{device.identifiers[?(@.name == 'serialNo')].value[0]}}` **
Extension jusqu'au numéro de série de votre appareil.
** `{{config.idtRootPath}}` **
S'étend jusqu'au chemin AWS IoT Device Tester racine.
# Interface utilisateur pour IDT pour la suite de qualification FreeRTOS 2.0 (FRQ 2.0)
AWS IoT Device Tester for FreeRTOS (IDT for FreeRTOS) inclut une interface utilisateur (UI) Web dans laquelle vous pouvez interagir avec l'application de ligne de commande IDT et les fichiers de configuration associés. Vous utilisez l'interface utilisateur IDT pour FreeRTOS pour créer une nouvelle configuration ou modifier une configuration existante pour votre appareil. Vous pouvez également utiliser l'interface utilisateur pour appeler l'application IDT et exécuter les tests FreeRTOS sur votre appareil.
Pour plus d'informations sur l'utilisation de la ligne de commande pour exécuter des tests de qualification, consultez[Premier test de votre carte microcontrôleur](lts-qual-steps.md).
Cette section décrit les prérequis pour l'interface utilisateur IDT pour FreeRTOS et comment exécuter des tests de qualification à partir de l'interface utilisateur.
**Topics**
+ [Configurer les prérequis IDT](#lts-dev-tester-ui-prereqs)
+ [Configurer les AWS informations d'identification pour utiliser l'interface utilisateur IDT](lts-configure-aws-credentials.md)
+ [Ouvrez l'interface utilisateur IDT pour FreeRTOS](lts-open-idt-ui.md)
+ [Création d'une nouvelle configuration](lts-create-new-configuration.md)
+ [Modifier une configuration existante](lts-modify-existing-configuration.md)
+ [Exécuter des tests de qualification](lts-run-tests-from-ui.md)
## Configurer les prérequis IDT
Pour exécuter des tests via l'interface utilisateur AWS IoT Device Tester (IDT) pour FreeRTOS, vous devez remplir les conditions requises sur la [Configurez les prérequis de qualification LTS](lts-idt-dev-tester-prereqs.md) page de qualification IDT FreeRTOS (FRQ) 2.x.
# Configurer les AWS informations d'identification pour utiliser l'interface utilisateur IDT
Vous devez configurer vos informations d'identification utilisateur IAM pour l' AWS utilisateur que vous avez créé dans[Créez un AWS compte](lts-idt-dev-tester-prereqs.md#lts-config-aws-account). 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
## Configurer les AWS informations d'identification avec un fichier d'informations d'identification
IDT utilise le même fichier d'informations d'identification que l' AWS CLI. Pour de plus amples informations, veuillez consulter [Fichiers de configuration et d'informations d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html).
L'emplacement du fichier d'informations d'identification varie en fonction du système d'exploitation que vous utilisez :
+ **macOS et 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 = your_access_key_id
aws_secret_access_key = your_secret_access_key
```
**Note**
Si vous n'utilisez pas le `default` AWS profil, vous devez spécifier le nom du profil dans l'interface utilisateur IDT pour FreeRTOS. Pour plus d'informations sur les profils, consultez [Configuration et paramètres des fichiers d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.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. Ils ne sont pas enregistrés si vous fermez la session SSH. L'interface utilisateur IDT pour FreeRTOS utilise les variables d'environnement `AWS_SECRET_ACCESS_KEY` et pour `AWS_ACCESS_KEY_ID` stocker vos informations d'identification. AWS
Pour définir ces variables sous Linux, macOS ou Unix, utilisez **export**:
```
export AWS_ACCESS_KEY_ID=your_access_key_id
export AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
Pour définir ces variables sous Windows, utilisez **set** :
```
set AWS_ACCESS_KEY_ID=your_access_key_id
set AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
# Ouvrez l'interface utilisateur IDT pour FreeRTOS
Cette rubrique explique comment ouvrir l'interface utilisateur IDT pour FreeRTOS afin d'utiliser la suite de qualification FreeRTOS.
**Pour ouvrir l'interface utilisateur IDT pour FreeRTOS**
1. Téléchargez une version IDT compatible pour FreeRTOS. Extrayez ensuite l'archive téléchargée dans un répertoire pour lequel vous disposez d'autorisations de lecture et d'écriture.
1. Accédez au répertoire d'installation d'IDT pour FreeRTOS :
```
cd devicetester-extract-location/bin
```
1. Exécutez la commande suivante pour ouvrir l'interface utilisateur IDT pour FreeRTOS :
------
#### [ Linux ]
```
.devicetester_ui_linux_x86-64
```
------
#### [ Windows ]
```
./devicetester_ui_win_x64-64
```
------
#### [ macOS ]
```
./devicetester_ui_mac_x86-64
```
**Note**
Sous macOS, pour autoriser votre système à exécuter l'interface utilisateur, accédez à **Préférences système -> Sécurité et confidentialité**. Lorsque vous exécutez les tests, vous devrez peut-être le faire trois fois de plus.
------
L'interface utilisateur IDT pour FreeRTOS s'ouvre dans votre navigateur par défaut. Les trois dernières versions majeures des navigateurs suivants sont compatibles avec l'interface utilisateur :
+ Google Chrome
+ Mozilla Firefox
+ Microsoft Edge
+ Apple Safari pour macOS
**Note**
Pour une meilleure expérience, nous recommandons Google Chrome ou Mozilla Firefox pour accéder à l'interface utilisateur IDT pour FreeRTOS. Microsoft Internet Explorer n'est pas pris en charge par l'interface utilisateur.
**Important**
Vous devez configurer vos AWS informations d'identification avant d'ouvrir l'interface utilisateur. Si vous n'avez pas configuré vos informations d'identification, fermez la fenêtre du navigateur IDT pour FreeRTOS UI, suivez les étapes [Configurer les AWS informations d'identification pour utiliser l'interface utilisateur IDT](lts-configure-aws-credentials.md) indiquées, puis rouvrez l'interface utilisateur IDT pour FreeRTOS.
# Création d'une nouvelle configuration
Si vous utilisez IDT pour la première fois, vous devez créer une nouvelle configuration pour configurer les fichiers de configuration JSON dont IDT pour FreeRTOS a besoin pour exécuter des tests. Vous pouvez ensuite exécuter des tests ou modifier la configuration créée.
Pour des exemples de `userdata.json` fichiers, et`config.json`,,,`device.json`,,,,,,,,,,[Premier test de votre carte microcontrôleur](lts-qual-steps.md),,
**Pour créer une configuration**
1. **Dans l'interface utilisateur IDT pour FreeRTOS, ouvrez le menu de navigation et choisissez Create new configuration.**
![\[Interface Device Tester for FreeRTOS avec bouton « Créer une nouvelle configuration » et informations sur l'autotest automatique des microcontrôleurs.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-create-configuration.png)
1. Suivez l'assistant de configuration pour saisir les paramètres de configuration IDT utilisés pour exécuter les tests de qualification. L'assistant configure les paramètres suivants dans les fichiers de configuration JSON situés dans le `devicetester-extract-location/config` répertoire.
+ **Paramètres des appareils** : paramètres du pool de périphériques pour les appareils à tester. Ces paramètres sont configurés dans les `sku` champs `id` et, et les **appareils** sont bloqués pour le pool de périphériques dans le `config.json` fichier.
![\[Écran de configuration du Device Tester for FreeRTOS avec les champs Identifiant et SKU pour configurer un pool d'appareils, options de configuration des appareils telles que la méthode de connectivité, l'approvisionnement des clés, les paramètres PKCS #11, les champs de saisie des détails de l'appareil et les commandes pour ajouter des appareils ou des identifiants.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-device-settings.png)
+ **AWS paramètres du compte** — Les Compte AWS informations utilisées par IDT pour FreeRTOS pour AWS créer des ressources lors des tests. Ces paramètres sont configurés dans le `config.json` fichier.
![\[Compte AWS page de paramètres avec des champs pour la région du compte, l'emplacement des informations d'identification sous forme de fichier ou d'environnement et le nom du profil\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-account-settings.png)
+ **Implémentation de FreeRTOS** — Le chemin absolu vers le référentiel FreeRTOS et le code porté, ainsi que la version de FreeRTOS sur laquelle vous souhaitez exécuter IDT FRQ. Les chemins d'accès aux fichiers d'en-tête d'exécution et de configuration des paramètres depuis le `FreeRTOS-Libraries-Integration-Tests` GitHub référentiel. Les commandes de compilation et de flash pour votre matériel qui permettent à IDT de créer et de tester automatiquement votre carte mère. Ces paramètres sont configurés dans le `userdata.json` fichier.
![\[Section de configuration de l'implémentation de FreeRTOS avec les chemins du référentiel, les chemins d'exécution des tests, la version de FreeRTOS, les détails de l'outil de génération et les paramètres de l'outil Flash.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-implementation-settings.png)
+ **Étiquettes PKCS \$111 et serveur Echo** : les étiquettes [PKCS \$111](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html) qui correspondent aux clés fournies sur votre matériel en fonction de la fonctionnalité clé et de la méthode de fourniture des clés. Les paramètres de configuration du serveur Echo pour les tests de l'interface de transport. Ces paramètres sont configurés dans les `device.json` fichiers `userdata.json` et.
![\[Étiquettes PKCS #11 et configurations du serveur Echo avec champs de saisie pour les étiquettes clés, la méthode de génération des clés et le numéro de port du serveur\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-pkcs11-settings.png)
+ **Over-the-air Mises à jour (OTA)** : paramètres qui contrôlent les tests de fonctionnalité OTA. Ces paramètres sont configurés dans le `features` bloc des `userdata.json` fichiers `device.json` et.
![\[Options de configuration de mise à jour OTA : ignorer les tests, les protocoles de données, les chemins du microprogramme, le chemin du certificat PAL, la signature de code, les hash/sign algorithmes, les certificats de trusted/untrusted signataire, le fichier de certificat de signature, le certificat de signature de compilation, la plateforme de signature.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-ota-settings.png)
1. Sur la page **Révision**, vérifiez vos informations de configuration.
![\[La configuration a créé une boîte de dialogue pour Device Tester for FreeRTOS, montrant des détails sur la création d'une nouvelle configuration de test avec des options pour modifier ou exécuter des tests.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/gsg-configuration-created.png)
Après avoir passé en revue votre configuration, pour exécuter vos tests de qualification, choisissez **Run tests**.
# Modifier une configuration existante
Si vous avez déjà configuré des fichiers de configuration pour IDT pour FreeRTOS, vous pouvez utiliser l'interface utilisateur IDT pour FreeRTOS pour modifier votre configuration existante. Les fichiers de configuration existants doivent se trouver dans le `devicetester-extract-location/config` répertoire.
**Pour modifier une configuration**
1. **Dans l'interface utilisateur IDT pour FreeRTOS, ouvrez le menu de navigation et choisissez Modifier la configuration existante.**
Le tableau de bord de configuration affiche des informations sur vos paramètres de configuration existants. Si une configuration est incorrecte ou indisponible, le statut de cette configuration est`Error validating configuration`.
![\[Écran de configuration avec le périphérique Compte AWS, l'implémentation de FreeRTOS, les étiquettes PKCS et le serveur d'écho, les mises à jour et les over-the-air sections de paramètres de test indiquant un statut valide.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/modify-existing-configuration.png)
1. Pour modifier un paramètre de configuration existant, procédez comme suit :
1. Choisissez le nom d'un paramètre de configuration pour ouvrir sa page de paramètres.
1. Modifiez les paramètres, puis choisissez **Enregistrer** pour régénérer le fichier de configuration correspondant.
1. Pour modifier les paramètres d'exécution du test IDT pour FreeRTOS, **choisissez les paramètres du cycle de test IDT dans la vue d'**édition :
![\[Boîte de dialogue des paramètres d'exécution du test IDT avec des options pour sélectionner les tests, ignorer les groupes de tests, multiplier le délai d'attente et arrêter en cas de premier échec.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/idt-testrun-settings.png)
Une fois que vous avez terminé de modifier votre configuration, vérifiez que tous vos paramètres de configuration sont validés. Si le statut de chaque paramètre de configuration est`Valid`, vous pouvez exécuter vos tests de qualification avec cette configuration.
# Exécuter des tests de qualification
Après avoir créé une configuration pour l'interface utilisateur IDT pour FreeRTOS, vous pouvez exécuter vos tests de qualification.
**Pour exécuter des tests de qualification**
1. Dans le menu de navigation, choisissez **Exécuter des tests**.
1. Choisissez **Démarrer les tests** pour démarrer le test. Par défaut, tous les tests applicables sont exécutés pour la configuration de votre appareil. IDT pour FreeRTOS génère un rapport de qualification lorsque tous les tests sont terminés.
![\[L'interface Device Tester pour FreeRTOS indique qu'aucun test n'a encore été effectué, avec des options pour créer une nouvelle configuration, modifier la configuration existante et exécuter des tests.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/idt-run-tests.png)
IDT pour FreeRTOS exécute les tests de qualification. Il affiche ensuite le résumé du test et les éventuelles erreurs dans la console **Test Runner**. Une fois le test terminé, vous pouvez consulter les résultats du test et les journaux depuis les emplacements suivants :
+ Les résultats des tests se trouvent dans le `devicetester-extract-location/results/execution-id` répertoire.
+ Les journaux de test se trouvent dans le `devicetester-extract-location/results/execution-id/logs` répertoire.
Pour plus d'informations sur les résultats des tests et les journaux, consultez [Consultez l'IDT gratuitement RTOSresults](view-results-lts.md) et[Consultez l'IDT gratuitement RTOSlogs](view-logs-lts.md).
![\[Journal d'exécution de Device Tester for FreeRTOS indiquant les tests réussis, les groupes de tests et les chemins de fichiers pour les journaux et les rapports.\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/images/idt-results.png)
# Exécutez la suite de qualification FreeRTOS 2.0
Utilisez l'exécutable AWS IoT Device Tester for FreeRTOS pour interagir avec IDT pour FreeRTOS. Les exemples de ligne de commande ci-dessous vous montrent comment exécuter les tests de qualification d'un groupe d'appareils (ensemble d'appareils identiques).
------
#### [ IDT v4.5.2 and later ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--group-id group-id \
--pool-id your-device-pool \
--test-id test-id \
--userdata userdata.json
```
Exécute une suite de tests sur un groupe d'appareils. Le fichier `userdata.json` doit figurer dans le répertoire `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/`.
**Note**
Si vous utilisez IDT pour FreeRTOS sous Windows, utilisez des barres obliques (/) pour spécifier le chemin du fichier. `userdata.json`
Utilisez la commande suivante pour exécuter un groupe de tests spécifique :
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.99.0 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
Les paramètres `suite-id` et `pool-id` sont facultatifs si vous exécutez une seule suite de tests au niveau d'un seul groupe d'appareils (à savoir, si un seul groupe d'appareils est défini dans votre fichier `device.json`).
Utilisez la commande suivante pour exécuter un cas de test spécifique dans un groupe de tests :
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
Vous pouvez utiliser la commande `list-test-cases` pour répertorier les cas de test dans un groupe de tests.
**Options de ligne de commande IDT pour FreeRTOS**
**group-id**
(Facultatif) Groupes de tests à exécuter, sous la forme d'une 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.
**pool-id**
(Facultatif) Le groupe d'appareils à tester. Option requise si vous définissez plusieurs groupes d'appareils dans `device.json`. Si vous avez un seul groupe d'appareils, vous pouvez omettre cette option.
**suite-id**
(Facultatif) Version de la suite de tests à exécuter. Si cette option n'est pas spécifiée, IDT utilise la dernière version dans le répertoire tests de votre système.
**test-id**
(Facultatif) Tests à exécuter, sous la forme d'une liste séparée par des virgules. Si cette option est spécifiée, `group-id` doit spécifier un groupe unique.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
**h**
Utilisez l'option d'aide pour en savoir plus sur les options `run-suite`.
**Example**
**Exemple**
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
## IDT pour les commandes FreeRTOS
La commande IDT pour FreeRTOS prend en charge les opérations suivantes :
------
#### [ IDT v4.5.2 and later ]
** `help` **
Répertorie les informations sur la commande spécifiée.
** `list-groups` **
Répertorie les groupes dans une suite donnée.
** `list-suites` **
Répertorie les suites disponibles.
** `list-supported-products` **
Répertorie les produits et les versions de suite de tests pris en charge.
** `list-supported-versions` **
Répertorie les versions de FreeRTOS et de suites de tests prises en charge par la version actuelle d'IDT.
** `list-test-cases` **
Répertorie les cas de test dans un groupe spécifié.
** `run-suite` **
Exécute une suite de tests sur un groupe d'appareils.
Utilisez l'option `--suite-id` pour spécifier une version de suite de tests ou omettez-la pour utiliser la dernière version sur votre système.
Utilisez l'option `--test-id` pour exécuter un cas de test individuel.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
Depuis IDT v3.0.0, IDT recherche en ligne des suites de tests plus récentes. Pour de plus amples informations, veuillez consulter [Versions de la suite de tests](idt-test-suite-versions.md).
------
# Consultez l'IDT gratuitement RTOSresults
Lorsqu'il s'exécute, IDT écrit les erreurs sur la console, les fichiers journaux et les rapports de tests. Après avoir terminé la gamme de test de qualification, IDT écrit un résumé de la série de tests dans la console et génère deux rapports d'essais. Ces rapports se trouvent à l'emplacement `devicetester-extract-location/results/execution-id/`. 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 inscrire votre appareil dans le catalogue des appareils AWS partenaires. Ce rapport contient les éléments suivants :
+ La version IDT pour FreeRTOS.
+ La version de FreeRTOS qui a été testée.
+ Les fonctionnalités de FreeRTOS prises en charge par l'appareil sont basées sur les tests réussis.
+ La référente et le nom de l'appareil spécifiés dans le fichier `device.json`.
+ Les caractéristiques de l'appareil spécifiées dans le fichier `device.json`.
+ Un récapitulatif des résultats des scénarios de test.
+ Une répartition des résultats des cas d'utilisation par bibliothèques qui ont été testés en fonction des fonctionnalités de l'appareil.
`FRQ_Report.xml`Il s'agit d'un rapport au [format JUnit XML](https://llg.cubic.org/docs/junit/) standard. Vous pouvez l'intégrer à CI/CD des plateformes telles 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 scénarios de test.
+ Une répartition des résultats des cas d'utilisation par bibliothèques qui ont été testés en fonction des fonctionnalités de l'appareil.
# Interpréter l'IDT pour les résultats FreeRTOS
La section Rapport dans `awsiotdevicetester_report.xml` ou `FRQ_Report.xml` répertorie les résultats des tests exécutés.
La première balise XML `` contient le résumé global de l'exécution des tests. Par exemple :
``
**Attributs utilisés dans la `` balise**
** `name` **
Nom de la suite de tests.
** `time` **
Durée, en secondes, nécessaire pour exécuter la suite de qualification.
** `tests` **
Nombre de scénarios de test exécutés.
** `failures` **
Nombre de scénarios de tests qui ont été exécutés, mais dont le résultat n'est pas probant.
** `errors` **
Le nombre de cas de test que IDT pour FreeRTOS n'a pas pu exécuter.
** `disabled` **
Cet attribut n'est pas utilisé et peut être ignoré.
S'il n'y a aucun échec ou erreur dans le scénario de test, votre appareil répond aux exigences techniques pour exécuter FreeRTOS et peut interagir avec les services. AWS IoT Si vous choisissez de répertorier votre appareil dans le catalogue des appareils AWS partenaires, vous pouvez utiliser ce rapport comme preuve de qualification.
En cas d'erreurs ou d'échec de scénarios de test, vous pouvez identifier les scénarios concernés à l'aide des balises XML ``. Les balises XML `` au sein de la balise `` indiquent le récapitulatif des résultats d'un groupe de tests.
``
Le format est similaire à la balise ``, mais avec un attribut supplémentaire appelé `skipped` qui n'est pas utilisé et qui ne peut pas être ignoré. Chaque balise XML ``inclut des balises `` pour chaque scénario de test qui a été exécuté pour un groupe de tests. Par exemple :
``
**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 suivant montre comment cela apparaît dans le `awsiotdevicetester_report.xml` fichier.
```
```
Les fonctionnalités marquées comme `optional` ne sont pas requises pour l'éligibilité. Les extraits suivants illustrent des fonctions facultatives.
```
```
S'il n'y a aucun échec ou erreur de test pour les fonctionnalités requises, votre appareil répond aux exigences techniques pour exécuter FreeRTOS et peut interagir avec les services. AWS IoT Si vous souhaitez répertorier votre appareil dans le [catalogue des appareils AWS partenaires](https://partners.amazonaws.com/qualified-devices), 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 à celui de la `` balise, mais possède un `skipped` attribut qui n'est pas utilisé et qui peut ê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 scénario de test.
** `attempts` **
Le nombre de fois où IDT pour FreeRTOS 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 case failure
Reason for the test case execution error
```
Pour de plus amples informations, veuillez consulter [Résolution des erreurs](dt-afr-troubleshooting.md).
# Consultez l'IDT gratuitement RTOSlogs
Vous pouvez trouver les journaux générés par IDT pour FreeRTOS à partir de l'exécution des tests dans. `devicetester-extract-location/results/execution-id/logs` Deux ensembles de journaux sont générés :
+ `test_manager.log`
Contient les journaux générés par IDT pour FreeRTOS (par exemple, la configuration associée aux journaux et la génération de rapports).
+ `test_group_id/test_case_id/test_case_id.log`
Fichier journal d'un cas de test, y compris la sortie de l'appareil en cours de test. Le fichier journal est nommé en fonction du groupe de test et du cas de test qui a été exécuté.
# IDT avec suite de qualification FreeRTOS 1.0 (FRQ 1.0)
**Important**
Depuis octobre 2022, AWS IoT Device Tester AWS IoT FreeRTOS Qualification (FRQ) 1.0 ne génère pas de rapports de qualification signés. Vous ne pouvez pas qualifier les nouveaux appareils AWS IoT FreeRTOS à répertorier dans le catalogue des appareils [partenaires dans AWS le cadre du programme de qualification des appareils](https://partners.amazonaws.com/qualified-devices) [utilisant AWS les versions](https://aws.amazon.com/partners/programs/dqp/) IDT FRQ 1.0. Bien que vous ne puissiez pas qualifier les appareils FreeRTOS avec IDT FRQ 1.0, vous pouvez continuer à tester vos appareils FreeRTOS avec FRQ 1.0. [Nous vous recommandons d'utiliser [IDT FRQ 2.0 pour qualifier et répertorier](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) les appareils FreeRTOS dans le catalogue d'appareils partenaires.AWS](https://partners.amazonaws.com/qualified-devices)
Vous pouvez utiliser IDT pour la qualification FreeRTOS afin de vérifier que le système d'exploitation FreeRTOS fonctionne localement sur votre appareil et qu'il peut communiquer avec. AWS IoT Plus précisément, il vérifie que les interfaces de la couche de portage pour les bibliothèques FreeRTOS sont correctement implémentées. Il effectue également end-to-end des tests avec AWS IoT Core. Il vérifie par exemple que votre carte peut envoyer, recevoir et traiter correctement des messages MQTT. [Les tests exécutés par IDT pour FreeRTOS sont définis dans le référentiel FreeRTOS. GitHub ](https://github.com/aws/amazon-freertos)
Les tests comme les applications intégrées qui sont flashés sur votre carte. Les images binaires de l'application incluent FreeRTOS, les interfaces FreeRTOS portées par le fournisseur de semi-conducteurs, et les pilotes de périphériques de la carte. Le but des tests est de vérifier que les interfaces FreeRTOS portées fonctionnent correctement au-dessus des pilotes de périphériques.
IDT for FreeRTOS génère des rapports de test que vous pouvez soumettre AWS IoT pour ajouter votre matériel au catalogue d'appareils partenaires. AWS Pour de plus amples informations, veuillez consulter [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
IDT pour FreeRTOS s'exécute sur un ordinateur hôte (Windows, macOS ou Linux) connecté à la carte à tester. IDT exécute des scénarios de test et regroupe les résultats. Il fournit également une interface de ligne de commande pour gérer l'exécution des tests.
Outre les appareils de test, IDT for FreeRTOS crée des ressources (par exemple, des AWS IoT objets, des groupes FreeRTOS, des fonctions Lambda, etc.) pour faciliter le processus de qualification. Pour créer ces ressources, IDT pour FreeRTOS utilise les informations d'identification configurées dans AWS le pour effectuer des appels d'API en `config.json` votre nom. Ces ressources sont allouées à différents moments d'un test.
Lorsque vous exécutez IDT pour FreeRTOS sur votre ordinateur hôte, il 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.
**Topics**
+ [Configuration des prérequis de qualification 1.0](dev-tester-prereqs.md)
+ [Premier test de votre carte microcontrôleur](qual-steps.md)
+ [Utiliser l'interface utilisateur IDT pour exécuter la suite de qualification FreeRTOS](device-tester-ui.md)
+ [Exécuter des tests Bluetooth Low Energy](afr-bridgekeeper-dt-bt.md)
+ [Exécutez la suite de qualification FreeRTOS](run-tests.md)
+ [Afficher les résultats de l'IDT pour FreeRTOS](view-results-frq.md)
+ [Interpréter l'IDT pour les résultats FreeRTOS](interpreting-results-frq.md)
+ [Afficher les logs IDT pour FreeRTOS](view-logs-frq.md)
# Configuration des prérequis de qualification 1.0
Cette section décrit les prérequis pour tester les microcontrôleurs avec. AWS IoT Device Tester
## Télécharger FreeRTOS
Vous pouvez télécharger une version de FreeRTOS à l'aide [GitHub](https://github.com/aws/amazon-freertos)de la commande suivante :
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
où se trouve une version de FreeRTOS (par exemple, 202007.00) correspondant à une version IDT répertoriée dans. [Versions prises en charge de AWS IoT Device Tester](dev-test-versions-afr.md) Cela garantit que vous disposez du code source complet, y compris les sous-modules, et que vous utilisez la bonne version d'IDT pour votre version de FreeRTOS, et vice versa.
Pour Windows, la limitation de la longueur du chemin est de 260 caractères. La structure des chemins de FreeRTOS comporte plusieurs niveaux. Par conséquent, si vous utilisez Windows, maintenez les chemins de vos fichiers en dessous de la limite de 260 caractères. Par exemple, clonez FreeRTOS sur plutôt que sur`C:\FreeRTOS`. `C:\Users\username\programs\projects\myproj\FreeRTOS\`
### Qualification FreeRTOS avec les bibliothèques LTS
+ Pour que votre microcontrôleur soit désigné comme compatible avec les versions basées sur le support à long terme (LTS) de FreeRTOS dans AWS le catalogue des appareils partenaires, vous devez fournir un fichier manifeste. *Pour plus d'informations, consultez la liste de contrôle de qualification [FreeRTOS dans le guide de qualification](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html) FreeRTOS.*
+ Afin de valider que votre microcontrôleur prend en charge les versions LTS de FreeRTOS et de le soumettre au Partner Device Catalog, vous devez AWS IoT Device Tester utiliser (IDT) avec AWS la version v1.4.x de la suite de tests FreeRTOS Qualification (FRQ).
+ Support pour les versions LTS de FreeRTOS limité à la version 202012.xx de FreeRTOS.
## Télécharger IDT pour FreeRTOS
Chaque version de FreeRTOS possède une version correspondante d'IDT pour FreeRTOS afin d'effectuer des tests de qualification. Téléchargez la version appropriée d'IDT pour FreeRTOS à partir de. [Versions prises en charge de AWS IoT Device Tester](dev-test-versions-afr.md)
Extrayez IDT pour FreeRTOS vers un emplacement du système de fichiers où vous disposez d'autorisations de lecture et d'écriture. Microsoft Windows ayant une limite de caractères pour la longueur du chemin, extrayez IDT pour FreeRTOS dans un répertoire racine tel que ou. `C:\` `D:\`
**Note**
Nous ne recommandons pas l'exécution d'IDT par plusieurs utilisateurs à partir d'un emplacement partagé, tel qu'un répertoire NFS ou un dossier partagé réseau Windows. Cela peut entraîner des plantages ou une corruption des données. Nous vous recommandons d'extraire le package IDT sur un disque local.
## Création et configuration d'un AWS compte
### Inscrivez-vous pour un Compte AWS
Si vous n'en avez pas Compte AWS, procédez comme suit pour en créer un.
**Pour vous inscrire à un Compte AWS**
1. Ouvrez l'[https://portal.aws.amazon.com/billing/inscription.](https://portal.aws.amazon.com/billing/signup)
1. Suivez les instructions en ligne.
Dans le cadre de la procédure d’inscription, vous recevrez un appel téléphonique ou un SMS et vous saisirez un code de vérification en utilisant le clavier numérique du téléphone.
Lorsque vous vous inscrivez à un Compte AWS, un *Utilisateur racine d'un compte AWS*est créé. Par défaut, seul l’utilisateur racine a accès à l’ensemble des Services AWS et des ressources de ce compte. La meilleure pratique de sécurité consiste à attribuer un accès administratif à un utilisateur, et à utiliser uniquement l’utilisateur racine pour effectuer les [tâches nécessitant un accès utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS vous envoie un e-mail de confirmation une fois le processus d'inscription terminé. À tout moment, vous pouvez consulter l'activité actuelle de votre compte et gérer votre compte en accédant à [https://aws.amazon.com/](https://aws.amazon.com/)et en choisissant **Mon compte**.
### Création d’un utilisateur doté d’un accès administratif
Après vous être inscrit à un Compte AWS, sécurisez Utilisateur racine d'un compte AWS AWS IAM Identity Center, activez et créez un utilisateur administratif afin de ne pas utiliser l'utilisateur root pour les tâches quotidiennes.
**Sécurisez votre Utilisateur racine d'un compte AWS**
1. Connectez-vous en [AWS Management Console](https://console.aws.amazon.com/)tant que propriétaire du compte en choisissant **Utilisateur root** et en saisissant votre adresse Compte AWS e-mail. Sur la page suivante, saisissez votre mot de passe.
Pour obtenir de l’aide pour vous connecter en utilisant l’utilisateur racine, consultez [Connexion en tant qu’utilisateur racine](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) dans le *Guide de l’utilisateur Connexion à AWS *.
1. Activez l’authentification multifactorielle (MFA) pour votre utilisateur racine.
Pour obtenir des instructions, voir [Activer un périphérique MFA virtuel pour votre utilisateur Compte AWS root (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) dans le guide de l'utilisateur *IAM*.
**Création d’un utilisateur doté d’un accès administratif**
1. Activez IAM Identity Center.
Pour obtenir des instructions, consultez [Activation d’ AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
1. Dans IAM Identity Center, octroyez un accès administratif à un utilisateur.
Pour un didacticiel sur l'utilisation du Répertoire IAM Identity Center comme source d'identité, voir [Configurer l'accès utilisateur par défaut Répertoire IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) dans le *Guide de AWS IAM Identity Center l'utilisateur*.
**Connexion en tant qu’utilisateur doté d’un accès administratif**
+ Pour vous connecter avec votre utilisateur IAM Identity Center, utilisez l’URL de connexion qui a été envoyée à votre adresse e-mail lorsque vous avez créé l’utilisateur IAM Identity Center.
Pour obtenir de l'aide pour vous connecter en utilisant un utilisateur d'IAM Identity Center, consultez la section [Connexion au portail AWS d'accès](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) dans le *guide de l'Connexion à AWS utilisateur*.
**Attribution d’un accès à d’autres utilisateurs**
1. Dans IAM Identity Center, créez un ensemble d’autorisations qui respecte la bonne pratique consistant à appliquer les autorisations de moindre privilège.
Pour obtenir des instructions, consultez [Création d’un ensemble d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
1. Attribuez des utilisateurs à un groupe, puis attribuez un accès par authentification unique au groupe.
Pour obtenir des instructions, consultez [Ajout de groupes](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
## AWS IoT Device Tester politique gérée
La politique `AWSIoTDeviceTesterForFreeRTOSFullAccess` gérée contient les AWS IoT Device Tester autorisations suivantes pour la vérification des versions, les fonctionnalités de mise à jour automatique et la collecte de métriques.
+ `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 de la suite de tests.
+ `iot-device-tester:SendMetrics`
Accorde AWS l'autorisation de collecter des statistiques relatives à l'utilisation AWS IoT Device Tester interne.
## (Facultatif) Installez le AWS Command Line Interface
Vous préférerez peut-être utiliser le AWS CLI pour effectuer certaines opérations. Si vous ne l'avez pas AWS CLI installé, suivez les instructions de la section [Installer le AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html).
Configurez le AWS CLI pour la AWS région que vous souhaitez utiliser en l'exécutant à **aws configure** partir d'une ligne de commande. [Pour plus d'informations sur les AWS régions qui prennent en charge IDT pour FreeRTOS,AWS consultez Régions et points de terminaison.](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control) Pour plus d'informations sur la **aws configure** section [Configuration rapide avec **aws configure**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config).
# Premier test de votre carte microcontrôleur
Vous pouvez utiliser IDT pour FreeRTOS pour tester lors du portage des interfaces FreeRTOS. Après avoir porté les interfaces FreeRTOS pour les pilotes de périphériques de votre carte, vous pouvez exécuter les tests AWS IoT Device Tester de qualification sur votre carte microcontrôleur.
## Ajouter des couches de transfert pour les bibliothèques
Pour transférer FreeRTOS sur votre appareil, suivez les instructions du Guide de portage de [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/).
## Configurez vos AWS informations d'identification
Vous devez configurer vos AWS informations d'identification AWS IoT Device Tester pour pouvoir communiquer avec le AWS Cloud. Pour plus d'informations, voir [Configurer les AWS informations d'identification et la région pour le développement](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html). Des AWS informations d'identification valides doivent être spécifiées dans le fichier `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/config.json` de configuration.
**Topics**
+ [Ajouter des couches de transfert pour les bibliothèques](#add-port-layer)
+ [Configurez vos AWS informations d'identification](#cfg-aws-afr)
+ [Créer un pool d'appareils dans IDT pour FreeRTOS](cfg-dt-dp.md)
+ [Configurer les paramètres de création, de flash et de test](cfg-dt-ud.md)
# Créer un pool d'appareils dans IDT pour FreeRTOS
Les appareils à tester sont organisés dans des groupes. Chaque groupe d'appareils se compose d'un ou de plusieurs appareils identiques. Vous pouvez configurer IDT pour FreeRTOS afin de tester un seul appareil dans un pool ou plusieurs appareils dans un pool. Pour accélérer le processus de qualification, IDT for FreeRTOS peut tester des appareils avec les mêmes spécifications en parallèle. Il utilise une méthode séquentielle pour exécuter un groupe de tests différents pour chaque appareil d'un groupe.
Vous pouvez ajouter un ou plusieurs appareils à un groupe d'appareils en modifiant la section `devices` du modèle `device.json` dans le dossier `configs`.
**Note**
Tous les appareils du même groupe doivent avoir les mêmes spécifications techniques et la même référence.
Pour permettre des compilations parallèles du code source pour différents groupes de test, IDT pour FreeRTOS copie le code source dans un dossier de résultats à l'intérieur du dossier extrait d'IDT pour FreeRTOS. Le chemin du code source dans votre commande build ou flash doit être référencé à l'aide de la `sdkPath` variable `testdata.sourcePath` or. IDT pour FreeRTOS remplace cette variable par un chemin temporaire du code source copié. Pour plus d'informations, voir,[IDT pour les variables FreeRTOS](dt-vars.md).
Voici un exemple de fichier `device.json` utilisé pour créer un groupe comprenant plusieurs appareils :
```
[
{
"id": "pool-id",
"sku": "sku",
"features": [
{
"name": "WIFI",
"value": "Yes | No"
},
{
"name": "Cellular",
"value": "Yes | No"
},
{
"name": "OTA",
"value": "Yes | No",
"configs": [
{
"name": "OTADataPlaneProtocol",
"value": "HTTP | MQTT"
}
]
},
{
"name": "BLE",
"value": "Yes | No"
},
{
"name": "TCP/IP",
"value": "On-chip | Offloaded | No"
},
{
"name": "TLS",
"value": "Yes | No"
},
{
"name": "PKCS11",
"value": "RSA | ECC | Both | No"
},
{
"name": "KeyProvisioning",
"value": "Import | Onboard | No"
}
],
"devices": [
{
"id": "device-id",
"connectivity": {
"protocol": "uart",
"serialPort": "/dev/tty*"
},
***********Remove the section below if the device does not support onboard key generation***************
"secureElementConfig" : {
"publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key",
"secureElementSerialNumber": "secure-element-serialNo-value",
"preProvisioned" : "Yes | No"
},
**********************************************************************************************************
"identifiers": [
{
"name": "serialNo",
"value": "serialNo-value"
}
]
}
]
}
]
```
Les attributs suivants sont utilisés dans le fichier `device.json` :
**`id`**
Un ID alphanumérique défini par l'utilisateur qui identifie de façon unique un groupe d'appareils. Les appareils appartenant à un groupe doivent être du même type. Lorsque vous exécutez une suite de tests, les appareils du groupe sont utilisés pour paralléliser la charge de travail.
**`sku`**
Une valeur alphanumérique qui identifie de façon unique la carte que vous testez. La référence est utilisée pour effectuer le suivi des cartes qualifiées.
Si vous souhaitez mettre votre carte en vente dans le catalogue des appareils AWS partenaires, le SKU que vous spécifiez ici doit correspondre au SKU que vous avez utilisé lors du processus de mise en vente.
**`features`**
Tableau contenant les fonctionnalités prises en charge par l'appareil. AWS IoT Device Tester utilise ces informations pour sélectionner les tests de qualification à exécuter.
Les valeurs prises en charge sont :
**`TCP/IP`**
Indique si votre carte supporte une TCP/IP pile et si elle est supportée sur puce (MCU) ou déchargée vers un autre module. TCP/IP est requis pour la qualification.
**`WIFI`**
Indique si la carte contient des fonctionnalités Wi-Fi. Doit être défini sur `No` s'`Cellular`il est défini sur`Yes`.
**`Cellular`**
Indique si votre carte est dotée de fonctionnalités cellulaires. Doit être défini sur `No` s'`WIFI`il est défini sur`Yes`. Lorsque cette fonctionnalité est définie sur`Yes`, le FullSecureSockets test sera exécuté à l'aide d'instances EC2 AWS t2.micro, ce qui peut entraîner des coûts supplémentaires pour votre compte. Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/).
**`TLS`**
Indique si votre carte prend en charge TLS. Le protocole TLS est requis pour la qualification.
**`PKCS11`**
Indique l'algorithme de cryptographie à clé publique pris en charge par la carte. PKCS11 est requis pour la qualification. Les valeurs prises en charge sont `ECC`, `RSA`, `Both` et `No`. `Both` indique que la carte prend en charge les algorithmes `ECC` et `RSA` .
**`KeyProvisioning`**
Indique la méthode d'écriture d'un certificat client X.509 approuvé sur votre carte. Les valeurs valides sont `Import`, `Onboard` et `No`. La mise en service de clés est requise pour la qualification.
+ Utilisez `Import` si votre carte autorise l'importation de clés privées. IDT créera une clé privée et l'intégrera au code source de FreeRTOS.
+ Utilisez `Onboard` si votre carte prend en charge la génération d'une clé privée embarquée (par exemple, si votre appareil dispose d'un élément sécurisé ou si vous préférez générer vos propres certificat et paire de clés d'appareil). Veillez à ajouter un élément `secureElementConfig` dans chacune des sections de l'appareil et indiquez le chemin absolu vers le fichier de clé publique dans le champ `publicKeyAsciiHexFilePath`.
+ Utilisez `No` si votre carte ne prend pas en charge la mise en service de clés.
**`OTA`**
Indique si votre carte mère prend en charge la fonctionnalité de mise à jour over-the-air (OTA). L'attribut `OtaDataPlaneProtocol` indique le protocole de plan de données OTA pris en charge par le périphérique. L'attribut est ignoré si la fonctionnalité OTA n'est pas prise en charge par le périphérique. Lorsque `"Both"` est sélectionné, le temps d'exécution du test OTA est prolongé en raison de l'exécution de tests MQTT, HTTP et mixtes.
À partir de IDT v4.1.0, `OtaDataPlaneProtocol` accepte uniquement `HTTP` et en `MQTT` tant que valeurs prises en charge.
**`BLE`**
Indique si la carte prend en charge Bluetooth Low Energy (BLE).
**`devices.id`**
Un identificateur unique défini par l'utilisateur pour l'appareil testé.
**`devices.connectivity.protocol`**
Le protocole de communication utilisé pour communiquer avec cet appareil. Valeur prise en charge : `uart`.
**`devices.connectivity.serialPort`**
Le port série de l'ordinateur hôte utilisé pour se connecter aux appareils testés.
**`devices.secureElementConfig.PublicKeyAsciiHexFilePath`**
Chemin absolu vers le fichier contenant la clé publique d'octets hexadécimaux extraite de la clé privée embarquée.
Exemple de format :
```
3059 3013 0607 2a86 48ce 3d02 0106 082a
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c
```
Si votre clé publique est au format .der, vous pouvez l'encoder directement en hexadécimal pour générer le fichier hexadécimal.
Exemple de commande pour la clé publique .der pour générer un fichier hexadécimal :
```
xxd -p pubkey.der > outFile
```
Si votre clé publique est au format .pem, vous pouvez extraire la partie codée en base64, la décoder au format binaire, puis l'encoder en hexadécimal pour générer le fichier hexadécimal.
Par exemple, utilisez ces commandes pour générer un fichier hexadécimal pour une clé publique .pem :
1. Retirez la partie codée en base64 de la clé (supprimez l'en-tête et le pied de page) et stockez-la dans un fichier, par exemple nommez-la`base64key`, exécutez cette commande pour la convertir au format .der :
```
base64 —decode base64key > pubkey.der
```
1. Exécutez la `xxd` commande pour le convertir au format hexadécimal.
```
xxd -p pubkey.der > outFile
```
**`devices.secureElementConfig.SecureElementSerialNumber`**
(Facultatif) Numéro de série de l'élément sécurisé. Indiquez ce champ lorsque le numéro de série est imprimé avec la clé publique de l'appareil lorsque vous exécutez le projet FreeRTOS demo/test .
**`devices.secureElementConfig.preProvisioned`**
(Facultatif) Réglez sur « Oui » si l'appareil possède un élément sécurisé préconfiguré avec des informations d'identification verrouillées, qui ne peut pas importer, créer ou détruire des objets. Cette configuration ne prend effet que lorsqu'`features`elle est `KeyProvisioning` définie sur « Onboard » et sur « ECC ». `PKCS11`
**`identifiers`**
(Facultatif) Un tableau de paires nom-valeur arbitraires. Vous pouvez utiliser ces valeurs dans les commandes de création et flash décrites dans la section suivante.
# Configurer les paramètres de création, de flash et de test
Pour qu'IDT for FreeRTOS puisse être créé et testé automatiquement sur votre carte, vous devez configurer IDT pour exécuter les commandes de compilation et de flash pour votre matériel. Les paramètres de création et flash sont configurés dans le modèle de fichier `userdata.json` situé dans le dossier `config`.
# Configurer les paramètres pour tester un seul appareil
Les paramètres de création, de flash et de test sont définis dans le fichier `configs/userdata.json`. Nous prenons en charge la configuration du serveur Echo en chargeant les certificats et les clés du client et du serveur dans le`customPath`. Pour plus d'informations, consultez la section [Configuration d'un serveur Echo](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html) dans le Guide de *portage de FreeRTOS*. L'exemple JSON suivant montre comment configurer IDT pour FreeRTOS afin de tester plusieurs appareils :
```
{
"sourcePath": "/absolute-path-to/freertos",
"vendorPath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name",
// ***********The sdkConfiguration block below is needed if you are not using the default, unmodified FreeRTOS repo.
// In other words, if you are using the default, unmodified FreeRTOS repo then remove this block***************
"sdkConfiguration": {
"name": "sdk-name",
"version": "sdk-version",
"path": "/absolute-path-to/sdk"
},
"buildTool": {
"name": "your-build-tool-name",
"version": "your-build-tool-version",
"command": [
"{{config.idtRootPath}}/relative-path-to/build-parallel.sh {{testData.sourcePath}} {{enableTests}}"
]
},
"flashTool": {
"name": "your-flash-tool-name",
"version": "your-flash-tool-version",
"command": [
"/{{config.idtRootPath}}/relative-path-to/flash-parallel.sh {{testData.sourcePath}} {{device.connectivity.serialPort}} {{buildImageName}}"
],
"buildImageInfo" : {
"testsImageName": "tests-image-name",
"demosImageName": "demos-image-name"
}
},
"testStartDelayms": 0,
"clientWifiConfig": {
"wifiSSID": "ssid",
"wifiPassword": "password",
"wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
},
"testWifiConfig": {
"wifiSSID": "ssid",
"wifiPassword": "password",
"wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
},
//**********
//This section is used to start echo server based on server certificate generation method,
//When certificateGenerationMethod is set as Automatic specify the eccCurveFormat to generate certifcate and key based on curve format,
//When certificateGenerationMethod is set as Custom specify the certificatePath and PrivateKeyPath to be used to start echo server
//**********
"echoServerCertificateConfiguration": {
"certificateGenerationMethod": "Automatic | Custom",
"customPath": {
"clientCertificatePath":"/path/to/clientCertificate",
"clientPrivateKeyPath": "/path/to/clientPrivateKey",
"serverCertificatePath":"/path/to/serverCertificate",
"serverPrivateKeyPath": "/path/to/serverPrivateKey"
},
"eccCurveFormat": "P224 | P256 | P384 | P521"
},
"echoServerConfiguration": {
"securePortForSecureSocket": 33333, // Secure tcp port used by SecureSocket test. Default value is 33333. Ensure that the port configured isn't blocked by the firewall or your corporate network
"insecurePortForSecureSocket": 33334, // Insecure tcp port used by SecureSocket test. Default value is 33334. Ensure that the port configured isn't blocked by the firewall or your corporate network
"insecurePortForWiFi": 33335 // Insecure tcp port used by Wi-Fi test. Default value is 33335. Ensure that the port configured isn't blocked by the firewall or your corporate network
},
"otaConfiguration": {
"otaFirmwareFilePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process",
"deviceFirmwareFileName": "ota-image-name-on-device",
"otaDemoConfigFilePath": "{{testData.sourcePath}}/relative-path-to/ota-demo-config-header-file",
"codeSigningConfiguration": {
"signingMethod": "AWS | Custom",
"signerHashingAlgorithm": "SHA1 | SHA256",
"signerSigningAlgorithm": "RSA | ECDSA",
"signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file",
"signerCertificateFileName": "signerCertificate-file-name",
"compileSignerCertificate": boolean,
// ***********Use signerPlatform if you choose aws for signingMethod***************
"signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF",
"untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier",
// ***********Use signCommand if you choose custom for signingMethod***************
"signCommand": [
"/absolute-path-to/sign.sh {{inputImageFilePath}} {{outputSignatureFilePath}}"
]
}
},
// ***********Remove the section below if you're not configuring CMake***************
"cmakeConfiguration": {
"boardName": "board-name",
"vendorName": "vendor-name",
"compilerName": "compiler-name",
"frToolchainPath": "/path/to/freertos/toolchain",
"cmakeToolchainPath": "/path/to/cmake/toolchain"
},
"freertosFileConfiguration": {
"required": [
{
"configName": "pkcs11Config",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/core_pkcs11_config.h"
},
{
"configName": "pkcs11TestConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/iot_test_pkcs11_config.h"
}
],
"optional": [
{
"configName": "otaAgentTestsConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/ota_config.h"
},
{
"configName": "otaAgentDemosConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_config.h"
},
{
"configName": "otaDemosConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_demo_config.h"
}
]
}
}
```
Voici les attributs utilisés dans le fichier `userdata.json` :
**`sourcePath`**
Le chemin d'accès à la racine du code source FreeRTOS porté. Pour les tests parallèles avec un SDK, ils `sourcePath` peuvent être définis à l'aide du `{{userData.sdkConfiguration.path}}` support. Par exemple :
```
{ "sourcePath":"{{userData.sdkConfiguration.path}}/freertos" }
```
**`vendorPath`**
Le chemin d'accès au code FreeRTOS spécifique au fournisseur. Pour les tests série, `vendorPath` peut être défini comme un chemin absolu. Par exemple :
```
{ "vendorPath":"C:/path-to-freertos/vendors/espressif/boards/esp32" }
```
Pour les tests en parallèle, `vendorPath` peut être défini à l'aide de l'espace réservé `{{testData.sourcePath}}`. Par exemple :
```
{ "vendorPath":"{{testData.sourcePath}}/vendors/espressif/boards/esp32" }
```
La `vendorPath` variable n'est nécessaire que lorsqu'elle est exécutée sans SDK, sinon elle peut être supprimée.
Lorsque vous exécutez des tests en parallèle sans SDK, l'`{{testData.sourcePath}}`espace réservé doit être utilisé dans les champs `vendorPath``buildTool`,`flashTool`. Lors de l'exécution d'un test avec un seul appareil, les chemins absolus doivent être utilisés dans les champs `vendorPath`, `buildTool` et `flashTool`. Lors de l'exécution avec un SDK, l'`{{sdkPath}}`espace réservé doit être utilisé dans les commandes `sourcePath``buildTool`, et`flashTool`.
**`sdkConfiguration`**
Si vous qualifiez FreeRTOS en apportant des modifications aux fichiers et à la structure des dossiers au-delà de ce qui est requis pour le portage, vous devrez configurer les informations de votre SDK dans ce bloc. Si vous n'êtes pas éligible à un FreeRTOS porté dans un SDK, vous devez omettre complètement ce bloc.
**`sdkConfiguration.name`**
Le nom du SDK que vous utilisez avec FreeRTOS. Si vous n'utilisez pas de SDK, le `sdkConfiguration` bloc entier doit être omis.
**`sdkConfiguration.version`**
Version du SDK que vous utilisez avec FreeRTOS. Si vous n'utilisez pas de SDK, le `sdkConfiguration` bloc entier doit être omis.
**`sdkConfiguration.path`**
Le chemin absolu vers le répertoire du SDK qui contient votre code FreeRTOS. Si vous n'utilisez pas de SDK, le `sdkConfiguration` bloc entier doit être omis.
**`buildTool`**
Chemin d'accès complet au script de création (.bat ou .sh) qui contient les commandes pour générer le code source. Toutes les références au chemin du code source dans la commande de construction doivent être remplacées par la AWS IoT Device Tester variable `{{testdata.sourcePath}}` et les références au chemin du SDK doivent être remplacées par`{{sdkPath}}`. Utilisez l'`{{config.idtRootPath}}`espace réservé pour référencer le chemin IDT absolu ou relatif.
**`testStartDelayms`**
Spécifie le nombre de millisecondes que le lanceur de tests FreeRTOS attendra avant de commencer à exécuter les tests. Cela peut être utile si l'appareil testé commence à émettre des informations de test importantes avant qu'IDT n'ait la chance de se connecter et de commencer à se connecter en raison d'une latence réseau ou autre. La valeur maximale autorisée est de 30 000 ms (30 secondes). Cette valeur s'applique uniquement aux groupes de test FreeRTOS et ne s'applique pas aux autres groupes de test qui n'utilisent pas le lanceur de tests FreeRTOS, tels que les tests OTA.
**`flashTool`**
Chemin d'accès complet au script flash (.sh ou .bat) qui contient les commandes flash pour votre appareil. Toutes les références au chemin du code source dans la commande flash doivent être remplacées par la variable IDT pour FreeRTOS `{{testdata.sourcePath}}` et toutes les références au chemin de votre SDK doivent être remplacées par la variable IDT pour FreeRTOS. Utilisez l'espace réservé pour référencer le chemin IDT absolu ou relatif. `{{sdkPath}}` `{{config.idtRootPath}}`
**`buildImageInfo`**
**`testsImageName`**
Nom du fichier produit par la commande build lors de la création de tests à partir du `freertos-source/tests` dossier.
**`demosImageName`**
Nom du fichier produit par la commande build lors de la création de tests à partir du `freertos-source/demos` dossier.
**`clientWifiConfig`**
Configuration Wi-Fi du client. Les tests de bibliothèque Wi-Fi nécessitent la connexion d'une carte MCU à deux points d'accès. (Les deux points d'accès peuvent être les mêmes.) Cet attribut configure les paramètres Wi-Fi du premier point d'accès. Certains des scénarios de test Wi-Fi exigent que le point d'accès soit sécurisé et qu'il ne soit pas ouvert. Assurez-vous que les deux points d'accès se trouvent sur le même sous-réseau que l'ordinateur hôte exécutant IDT.
**`wifi_ssid`**
SSID Wi-Fi.
**`wifi_password`**
Mot de passe Wi-Fi.
**`wifiSecurityType`**
Type de sécurité Wi-Fi utilisé. Une des valeurs suivantes :
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Si votre carte ne prend pas en charge le Wi-Fi, vous devez tout de même inclure la section `clientWifiConfig` dans votre fichier `device.json`, mais vous pouvez omettre les valeurs de ces attributs.
**`testWifiConfig`**
Configuration Wi-Fi de test. Les tests de bibliothèque Wi-Fi nécessitent la connexion d'une carte MCU à deux points d'accès. (Les deux points d'accès peuvent être les mêmes.) Cet attribut configure le paramétrage Wi-Fi du second point d'accès. Certains des scénarios de test Wi-Fi exigent que le point d'accès soit sécurisé et qu'il ne soit pas ouvert. Assurez-vous que les deux points d'accès se trouvent sur le même sous-réseau que l'ordinateur hôte exécutant IDT.
**`wifiSSID`**
SSID Wi-Fi.
**`wifiPassword`**
Mot de passe Wi-Fi.
**`wifiSecurityType`**
Type de sécurité Wi-Fi utilisé. Une des valeurs suivantes :
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Si votre carte ne prend pas en charge le Wi-Fi, vous devez tout de même inclure la section `testWifiConfig` dans votre fichier `device.json`, mais vous pouvez omettre les valeurs de ces attributs.
**`echoServerCertificateConfiguration`**
L'espace réservé à la génération de certificats de serveur Echo configurable pour les tests de socket sécurisés. Ce champ est obligatoire.
**`certificateGenerationMethod`**
Spécifie si le certificat de serveur est généré automatiquement ou fourni manuellement.
**`customPath`**
`certificateGenerationMethod`Il s'agit de « Personnalisé » `certificatePath` et `privateKeyPath` obligatoire.
**`certificatePath`**
Spécifie le chemin du fichier pour le certificat de serveur.
**`privateKeyPath`**
Spécifie le chemin du fichier pour la clé privée.
**`eccCurveFormat`**
Spécifie le format de courbe pris en charge par la carte. Obligatoire lorsque `PKCS11` le paramètre est réglé sur « ecc » dans`device.json`. Les valeurs valides sont « P224 », « P256 », « P384 » ou « P521 ».
**`echoServerConfiguration`**
Les ports configurables du serveur Echo pour WiFi les tests de sockets sécurisés. Ce champ est facultatif.
**`securePortForSecureSocket`**
Port utilisé pour configurer un serveur echo avec TLS pour le test des sockets sécurisés. La valeur par défaut est 33333. Assurez-vous que le port configuré n'est pas bloqué par un pare-feu ou votre réseau d'entreprise.
**`insecurePortForSecureSocket`**
Port utilisé pour configurer le serveur echo sans TLS pour le test des sockets sécurisés. La valeur par défaut utilisée dans le test est 33334. Assurez-vous que le port configuré n'est pas bloqué par un pare-feu ou votre réseau d'entreprise.
**`insecurePortForWiFi`**
Le port utilisé pour configurer le serveur Echo sans TLS à des fins de WiFi test. La valeur par défaut utilisée dans le test est 33335. Assurez-vous que le port configuré n'est pas bloqué par un pare-feu ou votre réseau d'entreprise.
**`otaConfiguration`**
Configuration OTA. [Facultatif]
**`otaFirmwareFilePath`**
Chemin d'accès complet vers l'image OTA créée après la génération. Par exemple, `{{testData.sourcePath}}/relative-path/to/ota/image/from/source/root`.
**`deviceFirmwareFileName`**
Le chemin complet du fichier sur le périphérique MCU où se trouve le microprogramme OTA. Certains appareils n'utilisent pas ce champ, mais vous devez tout de même fournir une valeur.
**`otaDemoConfigFilePath`**
Chemin d'accès complet à `aws_demo_config.h`, disponible dans `afr-source/vendors/vendor/boards/board/aws_demos/config_files/`. Ces fichiers sont inclus dans le modèle de code de portage fourni par FreeRTOS.
**`codeSigningConfiguration`**
Configuration de signature de code.
**`signingMethod`**
Méthode de signature de code. Les valeurs possibles sont `AWS` ou `Custom`.
Pour les régions de Pékin et de Ningxia, utilisez`Custom`. `AWS`la signature de code n'est pas prise en charge dans ces régions.
**`signerHashingAlgorithm`**
Algorithme de hachage pris en charge sur le périphérique. Les valeurs possibles sont `SHA1` ou `SHA256`.
**`signerSigningAlgorithm`**
Algorithme de signature pris en charge sur le périphérique. Les valeurs possibles sont `RSA` ou `ECDSA`.
**`signerCertificate`**
Certificat de confiance utilisé pour l'OTA.
Pour la méthode de signature du AWS code, utilisez l'Amazon Resource Name (ARN) pour le certificat sécurisé chargé sur le AWS Certificate Manager.
Pour la méthode de signature de code personnalisée, utilisez le chemin d’accès absolu vers le fichier de certificat du signataire.
Pour plus d'informations sur la création d'un certificat approuvé, consultez [Créer un certificat de signature de code](ota-code-sign-cert.md).
**`signerCertificateFileName`**
Le nom de fichier du certificat de signature de code sur l'appareil. Cette valeur doit correspondre au nom de fichier que vous avez fourni lors de l'exécution de la `aws acm import-certificate` commande.
Pour de plus amples informations, veuillez consulter [Créer un certificat de signature de code](ota-code-sign-cert.md).
**`compileSignerCertificate`**
Défini `true` si le certificat de vérification de signature du signataire de code n'est pas fourni ou flashé, il doit donc être compilé dans le projet. AWS IoT Device Tester récupère le certificat sécurisé et le compile dans. `aws_codesigner_certifiate.h`
**`untrustedSignerCertificate`**
L'ARN ou le chemin de fichier d'un deuxième certificat utilisé dans certains tests OTA en tant que certificat non fiable. Pour plus d'informations sur la création d'un certificat, voir [Création d'un certificat de signature de code](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html).
**`signerPlatform`**
Algorithme de signature et de hachage utilisé par AWS Code Signer lors de la création de la tâche de mise à jour OTA. Actuellement, les valeurs possibles pour ce champ sont `AmazonFreeRTOS-TI-CC3220SF` et `AmazonFreeRTOS-Default`.
+ Choisissez `AmazonFreeRTOS-TI-CC3220SF`, si `SHA1` et `RSA`.
+ Choisissez `AmazonFreeRTOS-Default`, si `SHA256` et `ECDSA`.
Si vous avez besoin de `SHA256` \$1 `RSA` ou `SHA1` \$1 `ECDSA` pour votre configuration, contactez-nous pour obtenir une assistance complémentaire.
Configurez `signCommand` si vous avez choisi `Custom` pour `signingMethod`.
**`signCommand`**
Commande utilisée pour effectuer la signature de code personnalisée. Vous pouvez trouver le modèle dans le répertoire `/configs/script_templates`.
Deux espaces réservés `{{inputImageFilePath}}` et `{{outputSignatureFilePath}}` sont obligatoires dans la commande. `{{inputImageFilePath}}` est le chemin d'accès au fichier de l'image créée par IDT qu’il faut signer. `{{outputSignatureFilePath}}` est le chemin d’accès au fichier de la signature qui sera généré par le script.
**`cmakeConfiguration`**
CMake configuration [Facultatif]
Pour exécuter des scénarios de CMake test, vous devez fournir le nom du forum, le nom du fournisseur et le `frToolchainPath` ou`compilerName`. Vous pouvez également fournir le `cmakeToolchainPath` si vous avez un chemin personnalisé vers la CMake chaîne d'outils.
**`boardName`**
Nom de la carte testée. Le nom de la carte doit être le même que le nom du dossier sous `path/to/afr/source/code/vendors/vendor/boards/board`.
**`vendorName`**
Le nom du fournisseur pour le tableau testé. Le fournisseur doit être le même que le nom du dossier sous `path/to/afr/source/code/vendors/vendor`.
**`compilerName`**
Le nom du compilateur.
**`frToolchainPath`**
Le chemin d'accès complet au compilateur de la chaîne d'outils
**`cmakeToolchainPath` **
Le chemin complet vers la chaîne d' CMake outils. Ce champ est facultatif
**`freertosFileConfiguration`**
La configuration des fichiers FreeRTOS qu'IDT modifie avant d'exécuter les tests.
**`required`**
Cette section indique les tests requis dont vous avez déplacé les fichiers de configuration PKCS11, par exemple TLS, etc.
**`configName`**
Nom du test en cours de configuration.
**`filePath`**
Le chemin absolu vers les fichiers de configuration dans le `freertos` dépôt. Utilisez la `{{testData.sourcePath}}` variable pour définir le chemin.
**`optional`**
Cette section spécifie les tests facultatifs dont vous avez déplacé les fichiers de configuration WiFi, par exemple OTA, etc.
**`configName`**
Nom du test en cours de configuration.
**`filePath`**
Le chemin absolu vers les fichiers de configuration dans le `freertos` dépôt. Utilisez la `{{testData.sourcePath}}` variable pour définir le chemin.
**Note**
Pour exécuter des scénarios de CMake test, vous devez fournir le nom du forum, le nom du fournisseur et le `afrToolchainPath` ou`compilerName`. Vous pouvez également indiquer `cmakeToolchainPath` si vous avez un chemin personnalisé vers la CMake chaîne d'outils.
# IDT pour les variables FreeRTOS
Les commandes permettant de créer votre code et de flasher l'appareil peuvent nécessiter une connectivité ou d'autres informations sur vos appareils pour fonctionner correctement. AWS IoT Device Tester vous permet de référencer les informations du périphérique dans Flash et de créer des commandes à l'aide de [JsonPath](https://goessner.net/articles/JsonPath/). À l'aide d' JsonPathexpressions simples, vous pouvez récupérer les informations requises spécifiées dans votre `device.json` fichier.
## Variables de chemin
IDT pour FreeRTOS définit les variables de chemin suivantes qui peuvent être utilisées dans les lignes de commande et les fichiers de configuration :
**`{{testData.sourcePath}}`**
Développe le code source du chemin d'accès. Si vous utilisez cette variable, elle doit être utilisée dans les commandes flash et build.
**`{{sdkPath}}`**
S'étend jusqu'à la valeur de votre `userData.sdkConfiguration.path` lorsqu'elle est utilisée dans les commandes de compilation et de flash.
**`{{device.connectivity.serialPort}}`**
Extension au port série.
**`{{device.identifiers[?(@.name == 'serialNo')].value[0]}}`**
Extension jusqu'au numéro de série de votre appareil.
**`{{enableTests}}`**
Valeur entière indiquant si la génération est destinée à des tests (valeur 1) ou à des démonstrations (valeur 0).
**`{{buildImageName}}`**
Nom de fichier de l'image générée par la commande build.
**`{{otaCodeSignerPemFile}}`**
Fichier PEM pour le signataire du code OTA.
**`{{config.idtRootPath}}`**
S'étend jusqu'au chemin AWS IoT Device Tester racine. Cette variable remplace le chemin absolu pour IDT lorsqu'il est utilisé par les commandes build et flash.
# Utiliser l'interface utilisateur IDT pour exécuter la suite de qualification FreeRTOS
À partir de IDT v4.3.0, pour AWS IoT Device Tester FreeRTOS (IDT-FreeRTOS) inclut une interface utilisateur Web qui vous permet d'interagir avec le fichier exécutable en ligne de commande IDT et les fichiers de configuration associés. Vous pouvez utiliser l'interface utilisateur IDT-FreeRTOS pour créer une nouvelle configuration afin d'exécuter des tests IDT ou pour modifier une configuration existante. Vous pouvez également utiliser l'interface utilisateur pour appeler l'exécutable IDT et exécuter des tests.
L'interface utilisateur IDT-FreeRTOS fournit les fonctions suivantes :
+ Simplifiez la configuration des fichiers de configuration pour les tests IDT-FreeRTOS.
+ Simplifiez l'utilisation d'IDT-FreeRTOS pour exécuter des tests de qualification.
Pour plus d'informations sur l'utilisation de la ligne de commande pour exécuter des tests de qualification, consultez[Premier test de votre carte microcontrôleur](qual-steps.md).
Cette section décrit les conditions requises pour utiliser l'interface utilisateur IDT-FreeRTOS et vous montre comment commencer à exécuter des tests de qualification dans l'interface utilisateur.
**Topics**
+ [Configurez les prérequis pour exécuter la suite de qualification FreeRTOS](dev-tester-ui-prereqs.md)
+ [Commencez avec l'interface utilisateur IDT-Freertos](dev-tester-ui-getting-started.md)
# Configurez les prérequis pour exécuter la suite de qualification FreeRTOS
Cette section décrit les prérequis pour tester les microcontrôleurs avec. AWS IoT Device Tester
**Topics**
+ [Utiliser un navigateur Web compatible](#idt-ui-supported-web-browser)
+ [Télécharger FreeRTOS](#ui-download-afr)
+ [Télécharger IDT pour FreeRTOS](#ui-download-dev-tester-afr)
+ [Création et configuration d'un AWS compte](#ui-config-aws-account)
+ [AWS IoT Device Tester politique gérée](#ui-managed-policy)
## Utiliser un navigateur Web compatible
L'interface utilisateur d'IDT-Freertos prend en charge les navigateurs Web suivants.
| Navigateur | Version |
| --- | --- |
| Google Chrome | Les trois dernières versions majeures |
| Mozilla Firefox | Les trois dernières versions majeures |
| Microsoft Edge | Les trois dernières versions majeures |
| Apple Safari pour macOS | Les trois dernières versions majeures |
Nous vous recommandons d'utiliser Google Chrome ou Mozilla Firefox pour une meilleure expérience.
**Note**
L'interface utilisateur d'IDT-FreeRTOS ne prend pas en charge Microsoft Internet Explorer.
## Télécharger FreeRTOS
Vous pouvez télécharger une version de FreeRTOS à l'aide [GitHub](https://github.com/aws/amazon-freertos)de la commande suivante :
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
où se trouve une version de FreeRTOS (par exemple, 202007.00) correspondant à une version IDT répertoriée dans. [Versions prises en charge de AWS IoT Device Tester](dev-test-versions-afr.md) Cela garantit que vous disposez du code source complet, y compris les sous-modules, et que vous utilisez la bonne version d'IDT pour votre version de FreeRTOS, et vice versa.
Pour Windows, la limitation de la longueur du chemin est de 260 caractères. La structure des chemins de FreeRTOS comporte plusieurs niveaux. Par conséquent, si vous utilisez Windows, maintenez les chemins de vos fichiers en dessous de la limite de 260 caractères. Par exemple, clonez FreeRTOS sur plutôt que sur`C:\FreeRTOS`. `C:\Users\username\programs\projects\myproj\FreeRTOS\`
### Considérations relatives à la qualification LTS (qualification pour FreeRTOS utilisant des bibliothèques LTS)
+ Pour que votre microcontrôleur soit désigné comme compatible avec les versions basées sur le support à long terme (LTS) de FreeRTOS dans AWS le catalogue des appareils partenaires, vous devez fournir un fichier manifeste. *Pour plus d'informations, consultez la liste de contrôle de qualification [FreeRTOS dans le guide de qualification](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html) FreeRTOS.*
+ Afin de valider que votre microcontrôleur prend en charge les versions LTS de FreeRTOS et de le soumettre au Partner Device Catalog, vous devez AWS IoT Device Tester utiliser (IDT) avec AWS la version v1.4.x de la suite de tests FreeRTOS Qualification (FRQ).
+ Support pour les versions LTS de FreeRTOS limité à la version 202012.xx de FreeRTOS.
## Télécharger IDT pour FreeRTOS
Chaque version de FreeRTOS possède une version correspondante d'IDT pour FreeRTOS pour effectuer des tests de qualification. Téléchargez la version appropriée d'IDT pour FreeRTOS à partir de. [Versions prises en charge de AWS IoT Device Tester](dev-test-versions-afr.md)
Extrayez IDT pour FreeRTOS vers un emplacement du système de fichiers où vous disposez d'autorisations de lecture et d'écriture. Microsoft Windows ayant une limite de caractères pour la longueur du chemin, extrayez IDT pour FreeRTOS dans un répertoire racine tel que ou. `C:\` `D:\`
**Note**
Nous vous recommandons d'extraire le package IDT sur un lecteur local. Si vous autorisez plusieurs utilisateurs à exécuter IDT à partir d'un emplacement partagé, tel qu'un répertoire NFS ou un dossier partagé sur le réseau Windows, le système risque de ne pas répondre ou de corrompre les données.
## Création et configuration d'un AWS compte
### Inscrivez-vous pour un Compte AWS
Si vous n'en avez pas Compte AWS, procédez comme suit pour en créer un.
**Pour vous inscrire à un Compte AWS**
1. Ouvrez l'[https://portal.aws.amazon.com/billing/inscription.](https://portal.aws.amazon.com/billing/signup)
1. Suivez les instructions en ligne.
Dans le cadre de la procédure d’inscription, vous recevrez un appel téléphonique ou un SMS et vous saisirez un code de vérification en utilisant le clavier numérique du téléphone.
Lorsque vous vous inscrivez à un Compte AWS, un *Utilisateur racine d'un compte AWS*est créé. Par défaut, seul l’utilisateur racine a accès à l’ensemble des Services AWS et des ressources de ce compte. La meilleure pratique de sécurité consiste à attribuer un accès administratif à un utilisateur, et à utiliser uniquement l’utilisateur racine pour effectuer les [tâches nécessitant un accès utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS vous envoie un e-mail de confirmation une fois le processus d'inscription terminé. À tout moment, vous pouvez consulter l'activité actuelle de votre compte et gérer votre compte en accédant à [https://aws.amazon.com/](https://aws.amazon.com/)et en choisissant **Mon compte**.
### Création d’un utilisateur doté d’un accès administratif
Après vous être inscrit à un Compte AWS, sécurisez Utilisateur racine d'un compte AWS AWS IAM Identity Center, activez et créez un utilisateur administratif afin de ne pas utiliser l'utilisateur root pour les tâches quotidiennes.
**Sécurisez votre Utilisateur racine d'un compte AWS**
1. Connectez-vous en [AWS Management Console](https://console.aws.amazon.com/)tant que propriétaire du compte en choisissant **Utilisateur root** et en saisissant votre adresse Compte AWS e-mail. Sur la page suivante, saisissez votre mot de passe.
Pour obtenir de l’aide pour vous connecter en utilisant l’utilisateur racine, consultez [Connexion en tant qu’utilisateur racine](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) dans le *Guide de l’utilisateur Connexion à AWS *.
1. Activez l’authentification multifactorielle (MFA) pour votre utilisateur racine.
Pour obtenir des instructions, voir [Activer un périphérique MFA virtuel pour votre utilisateur Compte AWS root (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) dans le guide de l'utilisateur *IAM*.
**Création d’un utilisateur doté d’un accès administratif**
1. Activez IAM Identity Center.
Pour obtenir des instructions, consultez [Activation d’ AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
1. Dans IAM Identity Center, octroyez un accès administratif à un utilisateur.
Pour un didacticiel sur l'utilisation du Répertoire IAM Identity Center comme source d'identité, voir [Configurer l'accès utilisateur par défaut Répertoire IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) dans le *Guide de AWS IAM Identity Center l'utilisateur*.
**Connexion en tant qu’utilisateur doté d’un accès administratif**
+ Pour vous connecter avec votre utilisateur IAM Identity Center, utilisez l’URL de connexion qui a été envoyée à votre adresse e-mail lorsque vous avez créé l’utilisateur IAM Identity Center.
Pour obtenir de l'aide pour vous connecter en utilisant un utilisateur d'IAM Identity Center, consultez la section [Connexion au portail AWS d'accès](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) dans le *guide de l'Connexion à AWS utilisateur*.
**Attribution d’un accès à d’autres utilisateurs**
1. Dans IAM Identity Center, créez un ensemble d’autorisations qui respecte la bonne pratique consistant à appliquer les autorisations de moindre privilège.
Pour obtenir des instructions, consultez [Création d’un ensemble d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
1. Attribuez des utilisateurs à un groupe, puis attribuez un accès par authentification unique au groupe.
Pour obtenir des instructions, consultez [Ajout de groupes](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
## AWS IoT Device Tester politique gérée
Pour permettre au testeur d'appareils de s'exécuter et de collecter des métriques, la politique `AWSIoTDeviceTesterForFreeRTOSFullAccess` gérée contient les autorisations suivantes :
+ `iot-device-tester:SupportedVersion`
Accorde l'autorisation d'obtenir la liste des versions de FreeRTOS et des versions de suites de tests prises en charge par IDT, afin qu'elles soient disponibles auprès du. AWS CLI
+ `iot-device-tester:LatestIdt`
Accorde l'autorisation d'obtenir la dernière AWS IoT Device Tester version disponible au téléchargement.
+ `iot-device-tester:CheckVersion`
Accorde l'autorisation de vérifier la compatibilité d'une combinaison de produit, de suite de tests et de versions AWS IoT Device Tester .
+ `iot-device-tester:DownloadTestSuite`
Accorde l'autorisation AWS IoT Device Tester de télécharger des suites de tests.
+ `iot-device-tester:SendMetrics`
Accorde l'autorisation de publier des données de statistiques AWS IoT Device Tester d'utilisation.
# Commencez avec l'interface utilisateur IDT-Freertos
Cette section explique comment utiliser l'interface utilisateur d'IDT-FreeRTOS pour créer ou modifier votre configuration, puis comment exécuter des tests.
**Topics**
+ [Configurer les AWS informations d'identification](#configure-aws-credentials)
+ [Ouvrez l'interface utilisateur IDT-Freertos](#open-idt-ui)
+ [Création d'une nouvelle configuration](#create-new-configuration)
+ [Modifier une configuration existante](#modify-existing-configuration)
+ [Exécuter des tests de qualification](#run-tests-from-ui)
## Configurer les AWS informations d'identification
Vous devez configurer les informations d'identification de l' AWS utilisateur que vous avez créé dans[Création et configuration d'un AWS compte](dev-tester-ui-prereqs.md#ui-config-aws-account). 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 =
```
**Note**
Si vous n'utilisez pas le `default` AWS profil, veillez à spécifier le nom du profil dans l'interface utilisateur IDT-FreeRTOS. Pour plus d'informations sur les profils, consultez [Configuration et paramètres des fichiers d'identification](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. Ils ne sont pas enregistrés si vous fermez la session SSH. L'interface utilisateur IDT-FreeRTOS utilise les variables d'`AWS_SECRET_ACCESS_KEY`environnement `AWS_ACCESS_KEY_ID` et pour stocker vos 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=
```
## Ouvrez l'interface utilisateur IDT-Freertos
**Pour ouvrir l'interface utilisateur IDT-FreeRTOS**
1. Téléchargez une version IDT-FreeRTOS compatible et extrayez l'archive téléchargée dans un emplacement de votre système de fichiers où vous disposez d'autorisations de lecture et d'écriture.
1. Exécutez la commande suivante pour accéder au répertoire d'installation d'IDT-FreeRTOS :
```
cd devicetester-extract-location/bin
```
1. Exécutez la commande suivante pour ouvrir l'interface utilisateur IDT-FreeRTOS :
------
#### [ Linux ]
```
.devicetestergui_linux_x86-64.exe
```
------
#### [ Windows ]
```
./devicetestergui_win_x64-64
```
------
#### [ macOS ]
```
./devicetestergui_mac_x86-64
```
**Note**
Sur Mac, pour autoriser votre système à exécuter l'interface utilisateur, accédez à **Préférences système -> Sécurité et confidentialité**. Lorsque vous exécutez les tests, il se peut que vous deviez le faire trois fois de plus.
------
L'interface utilisateur d'IDT-Freertos s'ouvre dans votre navigateur par défaut. Pour plus d'informations sur les navigateurs pris en charge, consultez[Utiliser un navigateur Web compatible](dev-tester-ui-prereqs.md#idt-ui-supported-web-browser).
## Création d'une nouvelle configuration
Si vous utilisez IDT-FreeRTOS pour la première fois, vous devez créer une nouvelle configuration pour configurer les fichiers de configuration JSON dont IDT-FreeRTOS a besoin pour exécuter des tests. Vous pouvez ensuite exécuter des tests ou modifier la configuration créée.
Pour des exemples de `userdata.json` fichiers, et`config.json`,,,`device.json`,,,,,,,,,,[Premier test de votre carte microcontrôleur](qual-steps.md),, Pour un exemple de `resource.json` fichier utilisé uniquement pour exécuter des tests Bluetooth Low Energy (BLE), consultez[Exécuter des tests Bluetooth Low Energy](afr-bridgekeeper-dt-bt.md).
**Pour créer une nouvelle configuration**
1. **Dans l'interface utilisateur IDT-FreeRTOS, ouvrez le menu de navigation, puis choisissez Créer une nouvelle configuration.**
**Important**
Vous devez configurer vos AWS informations d'identification avant d'ouvrir l'interface utilisateur. Si vous n'avez pas configuré vos informations d'identification, fermez la fenêtre du navigateur de l'interface utilisateur IDT-FreeRTOS, suivez les étapes indiquées[Configurer les AWS informations d'identification](#configure-aws-credentials), puis rouvrez l'interface utilisateur d'IDT-FreeRTOS.
1. Suivez l'assistant de configuration pour saisir les paramètres de configuration IDT utilisés pour exécuter les tests de qualification. L'assistant configure les paramètres suivants dans les fichiers de configuration JSON situés dans le `devicetester-extract-location/config` répertoire.
+ **AWS paramètres** : Compte AWS informations utilisées par IDT-FreeRTOS pour créer des AWS ressources lors des tests. Ces paramètres sont configurés dans le `config.json` fichier.
+ Référentiel **FreeRTOS** : chemin absolu vers le référentiel FreeRTOS et le code porté, ainsi que le type de qualification que vous souhaitez effectuer. Ces paramètres sont configurés dans le `userdata.json` fichier.
Vous devez transférer FreeRTOS pour votre appareil avant de pouvoir exécuter des tests de qualification. Pour plus d'informations, consultez le guide de portage de [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/)
+ **Build and flash** : commandes build et flash pour votre matériel qui permettent à IDT de créer et de tester automatiquement votre carte mère. Ces paramètres sont configurés dans le `userdata.json` fichier.
+ **Appareils** : paramètres du pool de périphériques pour les appareils à tester. Ces paramètres sont configurés dans `sku` les champs `id` et dans le `devices` bloc du pool de périphériques du `device.json` fichier.
+ **Mise en réseau** : paramètres permettant de tester la prise en charge des communications réseau pour vos appareils. Ces paramètres sont configurés dans le `features` bloc du `device.json` fichier et dans les `testWifiConfig` blocs `clientWifiConfig` et du `userdata.json` fichier.
+ **Serveur Echo** : paramètres de configuration du serveur Echo pour les tests de socket sécurisés. Ces paramètres sont configurés dans le `userdata.json` fichier.
Pour plus d'informations sur la configuration du serveur Echo, consultez[https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html).
+ **CMake**— (Facultatif) Les paramètres pour exécuter CMake les tests de fonctionnalité de compilation. Cette configuration n'est requise que si vous l'utilisez CMake comme système de compilation. Ces paramètres sont configurés dans le `userdata.json` fichier.
+ **BLE** —Paramètres permettant d'exécuter des tests de fonctionnalité Bluetooth Low Energy. Ces paramètres sont configurés dans le `features` bloc du `device.json` fichier et dans le `resource.json` fichier.
+ **OTA** : paramètres permettant d'exécuter des tests de fonctionnalité OTA. Ces paramètres sont configurés dans le `features` bloc du `device.json` fichier et dans le `userdata.json` fichier.
1. Sur la page **Révision**, vérifiez vos informations de configuration.
Après avoir passé en revue votre configuration, pour exécuter vos tests de qualification, choisissez **Run tests**.
## Modifier une configuration existante
Si vous avez déjà configuré des fichiers de configuration pour IDT, vous pouvez utiliser l'interface utilisateur IDT-FreeRTOS pour modifier votre configuration existante. Assurez-vous que vos fichiers de configuration existants sont disponibles dans le `devicetester-extract-location/config` répertoire.
**Pour modifier une nouvelle configuration**
1. **Dans l'interface utilisateur IDT-FreeRTOS, ouvrez le menu de navigation, puis choisissez Modifier la configuration existante.**
Le tableau de bord de configuration affiche des informations sur vos paramètres de configuration existants. Si une configuration est incorrecte ou indisponible, le statut de cette configuration est`Error validating configuration`.
1. Pour modifier un paramètre de configuration existant, procédez comme suit :
1. Choisissez le nom d'un paramètre de configuration pour ouvrir sa page de paramètres.
1. Modifiez les paramètres, puis choisissez **Enregistrer** pour régénérer le fichier de configuration correspondant.
Une fois que vous avez terminé de modifier votre configuration, vérifiez que tous vos paramètres de configuration sont validés. Si le statut de chaque paramètre de configuration est`Valid`, vous pouvez exécuter vos tests de qualification à l'aide de cette configuration.
## Exécuter des tests de qualification
Après avoir créé une configuration pour IDT-Freertos, vous pouvez exécuter vos tests de qualification.
**Pour exécuter des tests de qualification**
1. Validez votre configuration.
1. Dans le menu de navigation, choisissez **Exécuter des tests**.
1. Pour démarrer le test, choisissez **Démarrer les tests**.
**IDT-FreeRTOS exécute les tests de qualification et affiche le résumé des tests ainsi que les éventuelles erreurs dans la console Test Runner.** Une fois le test terminé, vous pouvez consulter les résultats du test et les journaux depuis les emplacements suivants :
+ Les résultats des tests se trouvent dans le `devicetester-extract-location/results/execution-id` répertoire.
+ Les journaux de test se trouvent dans le `devicetester-extract-location/results/execution-id/logs` répertoire.
Pour plus d'informations sur les résultats des tests et les journaux, consultez [Afficher les résultats de l'IDT pour FreeRTOS](view-results-frq.md) et[Afficher les logs IDT pour FreeRTOS](view-logs-frq.md).
# Exécuter des tests Bluetooth Low Energy
Cette section décrit comment configurer et exécuter des tests Bluetooth Low Energy à l'aide AWS IoT Device Tester de FreeRTOS.
Les tests Bluetooth ne sont pas requis pour la qualification principale. Si vous ne souhaitez pas tester votre appareil avec le support Bluetooth FreeRTOS, vous pouvez ignorer cette configuration. Assurez-vous de laisser la fonctionnalité BLE dans device.json définie sur. `No`
## Conditions préalables
+ Suivez les instructions de la section [Premier test de votre carte microcontrôleur](qual-steps.md).
+ Un Raspberry Pi 4B ou 3B\$1. (Requis pour exécuter l'application complémentaire Raspberry Pi BLE)
+ Une carte micro SD et un adaptateur de carte SD pour le logiciel Raspberry Pi.
## Configuration de Raspberry Pi Setup
Pour tester les capacités BLE de l'appareil testé (DUT), vous devez disposer d'un Raspberry Pi modèle 4B ou 3B\$1.
**Pour configurer votre Raspberry Pi afin d'exécuter les tests BLE**
1. Téléchargez l'une des images Yocto personnalisées contenant le logiciel requis pour effectuer les tests.
+ [Image pour Raspberry Pi 4B](https://docs.aws.amazon.com/freertos/latest/userguide/freertos/IDTFR_BLE_RaspberryPi4B_1.0.0_2021-04-13.rpi-sd.img)
+ [Image pour Raspberry Pi 3B\$1](https://docs.aws.amazon.com/freertos/latest/userguide/freertos/IDTFR_BLE_RaspberryPi3Bplus_1.0.0_2021-04-13.rpi-sd.img)
**Note**
L'image Yocto ne doit être utilisée qu'à des fins de test avec AWS IoT Device Tester FreeRTOS et à aucune autre fin.
1. Flashez l'image yocto sur la carte SD pour Raspberry Pi.
1. En utilisant un outil d'écriture sur carte SD comme [Etcher](https://www.balena.io/etcher), flashez le fichier `image-name.rpi-sd.img` téléchargé sur la carte SD. Comme l'image du système d'exploitation est volumineuse, cette étape peut prendre un peu de temps. Éjectez ensuite votre carte SD de votre ordinateur et insérez la carte microSD dans votre Raspberry Pi.
1. Configurez votre Raspberry Pi.
1. Pour le premier démarrage, nous vous recommandons de connecter le Raspberry Pi à un moniteur, un clavier et une souris.
1. Connectez votre Raspberry Pi à une source d'alimentation micro USB.
1. Connectez-vous à l'aide des informations d'identification par défaut. Pour l’ID utilisateur, saisissez **root**. Pour le mot de passe, saisissez **idtafr**.
1. En utilisant une connexion Wi-Fi ou Ethernet, connectez le Raspberry Pi à votre réseau.
1. Pour connecter votre Raspberry Pi par Wi-Fi, ouvrez `/etc/wpa_supplicant.conf` sur le Raspberry Pi et ajoutez vos informations d'identification Wi-Fi à la configuration `Network`.
```
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
network={
scan_ssid=1
ssid="your-wifi-ssid"
psk="your-wifi-password"
}
```
1. Exécutez `ifup wlan0` pour démarrer la connexion Wi-Fi. La connexion à votre réseau Wi-Fi peut prendre une minute.
1. Pour une connexion Ethernet, exécutez `ifconfig eth0`. Pour une connexion Wi-Fi, exécutez `ifconfig wlan0`. Prenez note de l'adresse IP qui apparaît sous la forme `inet addr` dans la sortie de commande. Vous aurez besoin de l'adresse IP ultérieurement dans cette procédure.
1. (Facultatif) Les tests exécutent les commandes sur le Raspberry Pi via SSH à l'aide des informations d'identification par défaut pour l’image yocto. Pour plus de sécurité, nous vous recommandons de configurer l'authentification par clé publique pour SSH et de désactiver SSH basé sur un mot de passe.
1. Créez une clé SSH à l'aide de la commande OpenSSL`ssh-keygen`. Si vous avez déjà une paire de clés SSK sur votre ordinateur hôte, il est recommandé d'en créer une nouvelle AWS IoT Device Tester pour permettre à FreeRTOS de se connecter à votre Raspberry Pi.
**Note**
Windows n'est fourni avec une installation de client SSH. Pour plus d'informations sur la façon d'installer un client SSH sur Windows, consultez la section [Download SSH Software](https://www.ssh.com/ssh/#sec-Download-client-software).
1. 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\user-name`.
1. Lorsque vous êtes invité à saisir une expression clé, appuyez sur Entrée pour continuer.
1. Pour ajouter votre clé SSH sur votre Raspberry Pi afin que AWS IoT Device Tester FreeRTOS puisse se connecter à l'appareil, utilisez `ssh-copy-id` la commande de votre ordinateur hôte. Cette commande ajoute votre clé publique au fichier `~/.ssh/authorized_keys` sur votre Raspberry Pi.
`ssh-copy-id root@raspberry-pi-ip-address`
1. Lorsque vous êtes invité à saisir un mot de passe, saisissez **idtafr**. Il s'agit du mot de passe par défaut de l’image yocto.
**Note**
La commande `ssh-copy-id` suppose que la clé publique est nommée `id_rsa.pub`. Sur macOS et Linux, l'emplacement par défaut est ` ~/.ssh/`. Sur Windows, l'emplacement par défaut est `C:\Users\user-name\.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 ~/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).
1. Pour vérifier que l'authentification par clé publique fonctionne, exécutez `ssh -i /my/path/myKey root@raspberry-pi-device-ip`.
Si vous n'êtes pas invité à saisir un mot de passe, votre authentification par clé publique fonctionne.
1. Vérifiez que vous pouvez vous connecter à votre Raspberry Pi à l'aide d'une clé publique, puis désactivez SSH basé sur un mot de passe.
1. Sur le Raspberry Pi, modifiez le fichier `/etc/ssh/sshd_config`.
1. Définissez l'attribut `PasswordAuthentication` sur `no`.
1. Enregistrez et fermez le fichier `sshd_config`.
1. Rechargez le serveur SSH en exécutant `/etc/init.d/sshd reload`.
1. Créez un fichier `resource.json`.
1. Dans le répertoire dans lequel vous avez extrait AWS IoT Device Tester, créez un fichier nommé`resource.json`.
1. Ajoutez les informations suivantes concernant votre Raspberry Pi au fichier, en les *rasp-pi-ip-address* remplaçant par l'adresse IP de votre Raspberry Pi.
```
[
{
"id": "ble-test-raspberry-pi",
"features": [
{"name":"ble", "version":"4.2"}
],
"devices": [
{
"id": "ble-test-raspberry-pi-1",
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address"
}
}
]
}
]
```
1. Si vous n'avez pas choisi d'utiliser l'authentification par clé publique pour SSH, ajoutez ce qui suit à la `connectivity` section du `resource.json` fichier.
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "password",
"credentials": {
"user": "root",
"password": "idtafr"
}
}
}
```
1. (Facultatif) Si vous avez choisi d'utiliser l’authentification par clé publique pour SSH, ajoutez les éléments suivants à la section `connectivity` du fichier `resource.json`.
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "pki",
"credentials": {
"user": "root",
"privKeyPath": "location-of-private-key"
}
}
}
```
## Configuration de l'appareil FreeRTOS
Dans votre fichier `device.json`, définissez la fonctionnalité `BLE` sur `Yes`. Si vous commencez avec un fichier `device.json` qui existait avant que les tests Bluetooth ne soient disponibles, vous devez ajouter la fonctionnalité BLE au tableau `features` :
```
{
...
"features": [
{
"name": "BLE",
"value": "Yes"
},
...
}
```
## Exécutez les tests BLE
Une fois que vous avez activé la fonctionnalité BLE dans `device.json`, les tests BLE commencent lorsque vous exécutez `devicetester_[linux | mac | win_x86-64] run-suite` *sans spécifier d'ID de groupe*.
Si vous souhaitez exécuter les tests BLE séparément, vous pouvez spécifier l'ID de groupe pour BLE : `devicetester_[linux | mac | win_x86-64] run-suite --userdata path-to-userdata/userdata.json --group-id FullBLE`.
Pour des performances optimales, placez votre Raspberry Pi à proximité de l'appareil testé.
## Résoudre les problèmes liés aux tests BLE
Vérifiez que vous avez suivi les étapes décrites dans [Premier test de votre carte microcontrôleur](qual-steps.md). Si des tests autres que les tests BLE échouent, le problème n'est probablement pas dû à la configuration Bluetooth.
# Exécutez la suite de qualification FreeRTOS
Vous utilisez l'exécutable AWS IoT Device Tester for FreeRTOS pour interagir avec IDT pour FreeRTOS. Les exemples de ligne de commande ci-dessous vous montrent comment exécuter les tests de qualification d'un groupe d'appareils (ensemble d'appareils identiques).
------
#### [ IDT v3.0.0 and later ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--group-id group-id \
--pool-id your-device-pool \
--test-id test-id \
--upgrade-test-suite y|n \
--update-idt y|n \
--update-managed-policy y|n \
--userdata userdata.json
```
Exécute une suite de tests sur un groupe d'appareils. Le fichier `userdata.json` doit figurer dans le répertoire `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/`.
**Note**
Si vous utilisez IDT pour FreeRTOS sous Windows, utilisez des barres obliques (/) pour spécifier le chemin du fichier. `userdata.json`
Utilisez la commande suivante pour exécuter un groupe de tests spécifique :
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.0.1 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
Les paramètres `suite-id` et `pool-id` sont facultatifs si vous exécutez une seule suite de tests au niveau d'un seul groupe d'appareils (à savoir, si un seul groupe d'appareils est défini dans votre fichier `device.json`).
Utilisez la commande suivante pour exécuter un cas de test spécifique dans un groupe de tests :
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
Vous pouvez utiliser la commande `list-test-cases` pour répertorier les cas de test dans un groupe de tests. Options de ligne de commande IDT pour FreeRTOS
**group-id**
(Facultatif) Groupes de tests à exécuter, sous la forme d'une 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.
**pool-id**
(Facultatif) Le groupe d'appareils à tester. Option requise si vous définissez plusieurs groupes d'appareils dans `device.json`. Si vous avez un seul groupe d'appareils, vous pouvez omettre cette option.
**suite-id**
(Facultatif) Version de la suite de tests à exécuter. Si cette option n'est pas spécifiée, IDT utilise la dernière version dans le répertoire tests de votre système.
Depuis IDT v3.0.0, IDT recherche en ligne des suites de tests plus récentes. Pour de plus amples informations, veuillez consulter [Versions de la suite de tests](idt-test-suite-versions.md).
**test-id**
(Facultatif) Tests à exécuter, sous la forme d'une liste séparée par des virgules. Si cette option est spécifiée, `group-id` doit spécifier un groupe unique.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
**update-idt**
(Facultatif) Si ce paramètre n'est pas défini et qu'une version IDT plus récente est disponible, vous serez invité à mettre à jour IDT. Si ce paramètre est défini sur`Y`, IDT arrêtera l'exécution du test s'il détecte qu'une version plus récente est disponible. Si ce paramètre est défini sur`N`, IDT poursuivra l'exécution du test.
**update-managed-policy**
(Facultatif) Si ce paramètre n'est pas utilisé et qu'IDT détecte que votre politique gérée ne l'est pas up-to-date, vous serez invité à mettre à jour votre politique gérée. Si ce paramètre est défini sur`Y`, IDT arrêtera l'exécution du test s'il détecte que ce n'est pas up-to-date le cas de votre politique gérée. Si ce paramètre est défini sur`N`, IDT poursuivra l'exécution du test.
**upgrade-test-suite**
(Facultatif) Si cette option n'est pas utilisée et qu'une version de suite de tests plus récente est disponible, vous êtes invité à la télécharger. Pour masquer l'invite, spécifiez `y` pour toujours télécharger la suite de tests la plus récente ou spécifiez `n` pour utiliser la suite de tests spécifiée ou la dernière version sur votre système.
**Example**
**Exemple**
Pour toujours télécharger et utiliser la suite de tests la plus récente, utilisez la commande suivante.
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite y
```
Pour utiliser la dernière suite de tests sur votre système, utilisez la commande suivante.
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite n
```
**h**
Utilisez l'option d'aide pour en savoir plus sur les options `run-suite`.
**Example**
**Exemple**
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
#### [ IDT v1.7.0 and earlier ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--pool-id your-device-pool \
--userdata userdata.json
```
Le fichier `userdata.json` doit être situé dans le répertoire `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/`.
**Note**
Si vous utilisez IDT pour FreeRTOS sous Windows, utilisez des barres obliques (/) pour spécifier le chemin du fichier. `userdata.json`
Utilisez la commande suivante pour exécuter un groupe de tests spécifique.
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1 --group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
Les valeurs `suite-id` et `pool-id` sont facultatives si vous exécutez une seule suite de tests au niveau d'un seul groupe d'appareils (autrement, si un seul groupe d'appareils est défini dans le fichier `device.json`).Options de ligne de commande IDT pour FreeRTOS
**group-id**
(Facultatif) Spécifie le groupe de tests.
**pool-id**
Spécifie le groupe d'appareils à tester. Si vous avez un seul groupe d'appareils, vous pouvez omettre cette option.
**suite-id**
(Facultatif) Spécifie la suite de tests à exécuter.
------
## IDT pour les commandes FreeRTOS
La commande IDT pour FreeRTOS prend en charge les opérations suivantes :
------
#### [ IDT v3.0.0 and later ]
**`help`**
Répertorie les informations sur la commande spécifiée.
**`list-groups`**
Répertorie les groupes dans une suite donnée.
**`list-suites`**
Répertorie les suites disponibles.
**`list-supported-products`**
Répertorie les produits et les versions de suite de tests pris en charge.
**`list-supported-versions`**
Répertorie les versions de FreeRTOS et de suites de tests prises en charge par la version actuelle d'IDT.
**`list-test-cases`**
Répertorie les cas de test dans un groupe spécifié.
**`run-suite`**
Exécute une suite de tests sur un groupe d'appareils.
Utilisez l'option `--suite-id` pour spécifier une version de suite de tests ou omettez-la pour utiliser la dernière version sur votre système.
Utilisez l'option `--test-id` pour exécuter un cas de test individuel.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
Pour obtenir la liste complète des options, veuillez consulter [Exécutez la suite de qualification FreeRTOS](#run-tests).
Depuis IDT v3.0.0, IDT recherche en ligne des suites de tests plus récentes. Pour de plus amples informations, veuillez consulter [Versions de la suite de tests](idt-test-suite-versions.md).
------
#### [ IDT v1.7.0 and earlier ]
**`help`**
Répertorie les informations sur la commande spécifiée.
**`list-groups`**
Répertorie les groupes dans une suite donnée.
**`list-suites`**
Répertorie les suites disponibles.
**`run-suite`**
Exécute une suite de tests sur un groupe d'appareils.
------
## Test de requalification
À mesure que de nouvelles versions d'IDT pour les tests de qualification FreeRTOS sont publiées, ou que vous mettez à jour des packages ou des pilotes de périphériques spécifiques à vos cartes, vous pouvez utiliser IDT pour FreeRTOS pour tester vos cartes microcontrôleurs. Pour les qualifications ultérieures, assurez-vous de disposer des dernières versions de FreeRTOS et d'IDT pour FreeRTOS et recommencez les tests de qualification.
# Afficher les résultats de l'IDT pour FreeRTOS
Lorsqu'il s'exécute, IDT écrit les erreurs sur la console, les fichiers journaux et les rapports de tests. Après avoir terminé la gamme de test de qualification, IDT écrit un résumé de la série de tests dans la console et génère deux rapports d'essais. Ces rapports se trouvent à l'emplacement `devicetester-extract-location/results/execution-id/`. 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 inscrire votre appareil dans le catalogue des appareils AWS partenaires. Ce rapport contient les éléments suivants :
+ La version IDT pour FreeRTOS.
+ La version de FreeRTOS qui a été testée.
+ Les fonctionnalités de FreeRTOS prises en charge par l'appareil sont basées sur les tests réussis.
+ La référente et le nom de l'appareil spécifiés dans le fichier `device.json`.
+ Les caractéristiques de l'appareil spécifiées dans le fichier `device.json`.
+ Un récapitulatif des résultats des scénarios de test.
+ Répartition des résultats des scénarios de test par bibliothèques testées en fonction des fonctionnalités de l'appareil (par exemple FullWiFi, FullMQTT, etc.).
+ Si cette qualification de FreeRTOS concerne la version 202012.00 qui utilise les bibliothèques LTS.
`FRQ_Report.xml`Il s'agit d'un rapport au [format JUnit XML](https://llg.cubic.org/docs/junit/) standard. Vous pouvez l'intégrer à CI/CD des plateformes telles 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 scénarios de test.
+ Une répartition des résultats des cas d'utilisation par bibliothèques qui ont été testés en fonction des fonctionnalités de l'appareil.
# Interpréter l'IDT pour les résultats FreeRTOS
La section Rapport dans `awsiotdevicetester_report.xml` ou `FRQ_Report.xml` répertorie les résultats des tests exécutés.
La première balise XML `` contient le résumé global de l'exécution des tests. Par exemple :
``
**Attributs utilisés dans la `` balise**
**`name`**
Nom de la suite de tests.
**`time`**
Durée, en secondes, nécessaire pour exécuter la suite de qualification.
**`tests`**
Nombre de scénarios de test exécutés.
**`failures`**
Nombre de scénarios de tests qui ont été exécutés, mais dont le résultat n'est pas probant.
**`errors`**
Le nombre de cas de test que IDT pour FreeRTOS n'a pas pu exécuter.
**`disabled`**
Cet attribut n'est pas utilisé et peut être ignoré.
S'il n'y a aucun échec ou erreur dans le scénario de test, votre appareil répond aux exigences techniques pour exécuter FreeRTOS et peut interagir avec les services. AWS IoT Si vous choisissez de répertorier votre appareil dans le catalogue des appareils AWS partenaires, vous pouvez utiliser ce rapport comme preuve de qualification.
En cas d'erreurs ou d'échec de scénarios de test, vous pouvez identifier les scénarios concernés à l'aide des balises XML ``. Les balises XML `` au sein de la balise `` indiquent le récapitulatif des résultats d'un groupe de tests.
``
Le format est similaire à la balise ``, mais avec un attribut supplémentaire appelé `skipped` qui n'est pas utilisé et qui ne peut pas être ignoré. Chaque balise XML ``inclut des balises `` pour chaque scénario de test qui a été exécuté pour un groupe de tests. Par exemple :
``
**Attributs utilisés dans la `` balise**
**`name`**
Nom du produit testé.
**`version`**
Version du produit testé.
**`sdk`**
Si vous avez exécuté IDT avec un SDK, ce bloc contient le nom et la version de votre SDK. Si vous n'avez pas exécuté IDT avec un SDK, ce bloc contient :
```
N/A
N/A
```
**`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 suivant montre comment cela apparaît dans le `awsiotdevicetester_report.xml` fichier.
```
```
Les fonctionnalités marquées comme `optional` ne sont pas requises pour l'éligibilité. Les extraits suivants illustrent des fonctions facultatives.
```
```
S'il n'y a aucun échec ou erreur de test pour les fonctionnalités requises, votre appareil répond aux exigences techniques pour exécuter FreeRTOS et peut interagir avec les services. AWS IoT Si vous souhaitez répertorier votre appareil dans le [catalogue des appareils AWS partenaires](https://partners.amazonaws.com/qualified-devices), 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 à celui de la `` balise, mais possède un `skipped` attribut qui n'est pas utilisé et qui peut être ignoré. Chaque balise XML `` inclut des balises `` pour chaque test exécuté pour un groupe de tests. Par exemple :
```
```
**`lts`**
True si vous êtes éligible à une version de FreeRTOS qui utilise les bibliothèques LTS, false dans le cas contraire.
**Attributs utilisés dans la `` balise**
**`name`**
Nom du scénario de test.
**`attempts`**
Le nombre de fois où IDT pour FreeRTOS 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 case failure
Reason for the test case execution error
```
Pour de plus amples informations, veuillez consulter [Résolution des erreurs](dt-afr-troubleshooting.md).
# Afficher les logs IDT pour FreeRTOS
Vous pouvez trouver les journaux générés par IDT pour FreeRTOS à partir de l'exécution des tests dans. `devicetester-extract-location/results/execution-id/logs` Deux ensembles de journaux sont générés :
**`test_manager.log`**
Contient les journaux générés par IDT pour FreeRTOS (par exemple, la configuration associée aux journaux et la génération de rapports).
**`test_group_id__test_case_id.log` (par exemple, `FullMQTT__Full_MQTT.log`)**
Fichier journal d'un cas de test, y compris la sortie de l'appareil en cours de test. Le fichier journal est nommé en fonction du groupe de test et du cas de test qui a été exécuté.
# Développez et exécutez vos propres suites de tests IDT
À partir de IDT v4.0.0, IDT pour FreeRTOS 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 que vous souhaitez tester.
+ Fournissez à IDT vos suites de tests personnalisées aux testeurs. Incluez des informations sur les configurations de paramètres spécifiques de vos suites de tests.
****Pour exécuter des suites de tests personnalisées****
+ Configurez l'appareil que vous souhaitez tester.
+ Implémentez les configurations de paramètres requises par les suites de tests que vous souhaitez utiliser.
+ Utilisez IDT pour exécuter vos suites de tests personnalisées.
+ Consultez les résultats des tests et les journaux d'exécution des tests exécutés par IDT.
## Téléchargez la dernière version de AWS IoT Device Tester pour FreeRTOS
Téléchargez la [dernière version](dev-test-versions-afr.md#idt-latest-version-afr) d'IDT et extrayez le logiciel dans un emplacement de votre système de fichiers où vous disposez d'autorisations de lecture et d'écriture.
**Note**
IDT ne prend pas en charge son exécution par plusieurs utilisateurs à partir d'un emplacement partagé, tel qu'un répertoire NFS ou un dossier partagé réseau Windows. Nous vous recommandons d'extraire le package IDT sur une unité locale et d'exécuter le fichier binaire IDT sur votre station de travail locale.
Pour Windows, la limitation de la longueur du chemin est de 260 caractères. Si vous utilisez Windows, décompressez IDT dans un répertoire racine comme `C:\ ` ou `D:\` afin que la longueur de vos chemins respecte la limite de 260 caractères.
## Workflow de la suite de tests
Les suites de tests sont composées de trois types de fichiers :
+ Fichiers de configuration fournissant à IDT des informations sur la manière 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](test-executables.md) contenant la logique de test de votre suite de tests.
1. Vérifiez et documentez les [informations de configuration requises pour que les testeurs](set-config-custom.md) exécutent la suite de tests.
1. Vérifiez qu'IDT peut exécuter votre suite de tests et produire les [résultats des tests](run-tests-custom.md) comme prévu.
Pour créer rapidement un exemple de suite personnalisée et l'exécuter, suivez les instructions figurant dans[Tutoriel : création et exécution de l'exemple de suite de tests IDT](build-sample-suite.md).
Pour commencer à créer une suite de tests personnalisée en Python, consultez[Tutoriel : Développement d'une suite de tests IDT simple](create-custom-tests.md).
# Tutoriel : création et exécution de l'exemple de suite de tests IDT
Le 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 FreeRTOS AWS IoT Device Tester pour exécuter des suites de tests personnalisées. Bien que ce didacticiel utilise le protocole SSH, il est utile d'apprendre à l'utiliser AWS IoT Device Tester avec les appareils FreeRTOS.
Dans ce didacticiel, vous allez effectuer les étapes suivantes :
1. [Créez la suite d'exemples de tests](build-sample.md)
1. [Utiliser IDT pour exécuter l'exemple de suite de tests](run-sample.md)
**Topics**
+ [Configurer les prérequis pour l'exemple de suite de tests](prereqs-tutorial-sample.md)
+ [Configurer les informations de l'appareil pour IDT](configure-idt-sample.md)
+ [Créez la suite d'exemples de tests](build-sample.md)
+ [Utiliser IDT pour exécuter l'exemple de suite de tests](run-sample.md)
+ [Résolution des erreurs](tutorial-troubleshooting-custom.md)
# Configurer les prérequis pour l'exemple de suite de tests
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://docs.python.org/3/) 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/3/).
+ [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.com/documentation/computers/remote-access.html) 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 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.md) 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 AWS 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 erreurs
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.md) 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 à partir de votre ordinateur hôte.
# Tutoriel : Développement d'une suite de tests IDT simple
Une suite de tests combine les éléments suivants :
+ Exécutable de test contenant la logique de test
+ Fichiers de configuration décrivant la suite de tests
Ce didacticiel vous montre comment utiliser IDT pour FreeRTOS pour développer une suite de tests Python contenant un seul cas de test. Bien que ce didacticiel utilise le protocole SSH, il est utile d'apprendre à l'utiliser AWS IoT Device Tester avec les appareils FreeRTOS.
Dans ce didacticiel, vous allez effectuer les étapes suivantes :
1. [Création d'un répertoire de suites de tests](test-suite-dir.md)
1. [Création de fichiers de configuration](test-suite-json.md)
1. [Création de l'exécutable du scénario de test](test-suite-exe.md)
1. [Exécutez la suite de tests](run-test-suite.md)
Suivez les étapes ci-dessous pour suivre un didacticiel sur le développement d'une suite de tests IDT simple.
**Topics**
+ [Configurez les prérequis pour une suite de tests IDT simple](prereqs-tutorial-custom.md)
+ [Création d'un répertoire de suites de tests](test-suite-dir.md)
+ [Création de fichiers de configuration](test-suite-json.md)
+ [Obtenez le SDK du client IDT](add-idt-sdk.md)
+ [Création de l'exécutable du scénario de test](test-suite-exe.md)
+ [Configurer les informations de l'appareil pour IDT](configure-idt-sample2.md)
+ [Exécutez la suite de tests](run-test-suite.md)
+ [Résolution des erreurs](tutorial-troubleshooting.md)
+ [Création de fichiers de configuration de la suite de tests IDT](idt-json-config.md)
+ [Configuration de l'orchestrateur de test IDT](idt-test-orchestrator.md)
+ [Configuration de la machine d'état IDT](idt-state-machine.md)
+ [Créer un fichier exécutable pour le scénario de test IDT](test-executables.md)
+ [Utiliser le contexte IDT](idt-context.md)
+ [Configuration des paramètres pour les testeurs](set-config-custom.md)
+ [Déboguer et exécuter des suites de tests personnalisées](run-tests-custom.md)
+ [Consulter les résultats et les journaux des tests IDT](idt-review-results-logs.md)
+ [Soumettre les statistiques d'utilisation de l'IDT](idt-usage-metrics.md)
# Configurez les prérequis pour une suite de tests IDT simple
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/3/).
+ [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.com/documentation/computers/remote-access.html) 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 requis**
**`suite.json`**
Contient des informations sur la suite de tests. Consultez [Configurer suite.json](idt-json-config.md#suite-json).
**`group.json`**
Contient des informations sur un groupe de test. Vous devez créer un `group.json` fichier pour chaque groupe de test de votre suite de tests. Consultez [Configurer group.json](idt-json-config.md#group-json).
**`test.json`**
Contient des informations sur un scénario de test. Vous devez créer un `test.json` fichier pour chaque scénario de test de votre suite de tests. Consultez [Configurer test.json](idt-json-config.md#test-json).
1. Dans le `MyTestSuite_1.0.0/suite` dossier, créez un `suite.json` fichier avec la structure suivante :
```
{
"id": "MyTestSuite_1.0.0",
"title": "My Test Suite",
"details": "This is my test suite.",
"userDataRequired": false
}
```
1. Dans le `MyTestSuite_1.0.0/myTestGroup` dossier, créez un `group.json` fichier avec la structure suivante :
```
{
"id": "MyTestGroup",
"title": "My Test Group",
"details": "This is my test group.",
"optional": false
}
```
1. Dans le `MyTestSuite_1.0.0/myTestGroup/myTestCase` dossier, créez un `test.json` fichier avec la structure suivante :
```
{
"id": "MyTestCase",
"title": "My Test Case",
"details": "This is my test case.",
"execution": {
"timeout": 300000,
"linux": {
"cmd": "python3",
"args": [
"myTestCase.py"
]
},
"mac": {
"cmd": "python3",
"args": [
"myTestCase.py"
]
},
"win": {
"cmd": "python3",
"args": [
"myTestCase.py"
]
}
}
}
```
L'arborescence de votre `MyTestSuite_1.0.0` dossier doit désormais ressembler à ce qui suit :
```
MyTestSuite_1.0.0
└── suite
├── suite.json
└── myTestGroup
├── group.json
└── myTestCase
└── test.json
```
# Obtenez le SDK du client IDT
Vous utilisez le [SDK du client IDT](test-executables.md#idt-client-sdk) pour permettre à IDT d'interagir avec l'appareil testé et de communiquer les résultats des tests. Pour ce didacticiel, vous allez utiliser la version Python du SDK.
Depuis le `/sdks/python/` dossier, `idt_client` copiez-le dans votre `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` dossier.
Pour vérifier que le SDK a bien été copié, exécutez la commande suivante.
```
cd MyTestSuite_1.0.0/suite/myTestGroup/myTestCase
python3 -c 'import idt_client'
```
# Création de l'exécutable du scénario de test
Les exécutables du scénario de test contiennent la logique de test que vous souhaitez exécuter. Une suite de tests peut contenir plusieurs exécutables de scénarios de test. Pour ce didacticiel, vous ne créerez qu'un seul exécutable de scénario de test.
1. Créez le fichier de suite de tests.
Dans le `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` dossier, créez un `myTestCase.py` fichier avec le contenu suivant :
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
if __name__ == "__main__":
main()
```
1. Utilisez les fonctions du SDK client pour ajouter la logique de test suivante à votre `myTestCase.py` fichier :
1. Exécutez une commande SSH sur le périphérique testé.
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
# Create an execute on device request
exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'"))
# Run the command
exec_resp = client.execute_on_device(exec_req)
# Print the standard output
print(exec_resp.stdout)
if __name__ == "__main__":
main()
```
1. Envoyez le résultat du test à IDT.
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
# Create an execute on device request
exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'"))
# Run the command
exec_resp = client.execute_on_device(exec_req)
# Print the standard output
print(exec_resp.stdout)
# Create a send result request
sr_req = SendResultRequest(TestResult(passed=True))
# Send the result
client.send_result(sr_req)
if __name__ == "__main__":
main()
```
# Configurer les informations de l'appareil pour IDT
Configurez les informations de votre appareil pour qu'IDT exécute le test. Vous devez mettre à jour le `device.json` modèle situé dans le `/configs` dossier avec les informations suivantes.
```
[
{
"id": "pool",
"sku": "N/A",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
Dans l'`devices`objet, fournissez les informations suivantes :
**`id`**
Identifiant unique défini par l'utilisateur pour votre appareil.
**`connectivity.ip`**
L'adresse IP de votre appareil.
**`connectivity.port`**
Facultatif. Le numéro de port à utiliser pour les connexions SSH à votre appareil.
**`connectivity.auth`**
Informations d'authentification pour la connexion.
Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`.
**`connectivity.auth.method`**
Méthode d'authentification utilisée pour accéder à un appareil sur le protocole de connectivité donné.
Les valeurs prises en charge sont :
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Informations d'identification utilisées pour l'authentification.
**`connectivity.auth.credentials.user`**
Le nom d'utilisateur utilisé pour vous connecter à votre appareil.
**`connectivity.auth.credentials.privKeyPath`**
Le chemin complet vers la clé privée utilisée pour vous connecter à votre appareil.
Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `pki`.
**`devices.connectivity.auth.credentials.password`**
Le mot de passe utilisé pour vous connecter à votre appareil.
Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `password`.
**Note**
Spécifiez `privKeyPath` uniquement si `method` est défini sur `pki`.
Spécifiez `password` uniquement si `method` est défini sur `password`.
# Exécutez la suite de tests
Après avoir créé votre suite de tests, vous devez vous assurer qu'elle fonctionne comme prévu. Pour ce faire, procédez comme suit pour exécuter la suite de tests avec votre pool d'appareils existant.
1. Copiez votre `MyTestSuite_1.0.0` dossier dans`/tests`.
1. Exécutez les commandes suivantes :
```
cd /bin
./devicetester_[linux | mac | win_x86-64] run-suite --suite-id MyTestSuite
```
IDT exécute votre suite de tests et diffuse les résultats sur la console. Lorsque le test est terminé, les informations suivantes s'affichent :
```
time="2020-10-19T09:24:47-07:00" level=info msg=Using pool: pool
time="2020-10-19T09:24:47-07:00" level=info msg=Using test suite "MyTestSuite_1.0.0" for execution
time="2020-10-19T09:24:47-07:00" level=info msg=b'hello world\n' suiteId=MyTestSuite groupId=myTestGroup testCaseId=myTestCase deviceId=my-device executionId=9a52f362-1227-11eb-86c9-8c8590419f30
time="2020-10-19T09:24:47-07:00" level=info msg=All tests finished. executionId=9a52f362-1227-11eb-86c9-8c8590419f30
time="2020-10-19T09:24:48-07:00" level=info msg=
========== Test Summary ==========
Execution Time: 1s
Tests Completed: 1
Tests Passed: 1
Tests Failed: 0
Tests Skipped: 0
----------------------------------
Test Groups:
myTestGroup: PASSED
----------------------------------
Path to AWS 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 erreurs
Utilisez les informations suivantes pour résoudre les problèmes rencontrés lors de l'exécution du didacticiel.
**Le scénario de test ne s'exécute pas correctement**
Si le test échoue, IDT diffuse les journaux d'erreurs sur la console afin de vous aider à résoudre les problèmes liés à l'exécution du test. Avant de consulter les journaux d'erreurs, vérifiez les points suivants :
+ Le SDK du client IDT se trouve dans le bon dossier, comme décrit dans. [Obtenez le SDK du client IDT](add-idt-sdk.md)
+ Vous répondez à tous les prérequis pour ce didacticiel. Pour de plus amples informations, veuillez consulter [Configurez les prérequis pour une suite de tests IDT simple](prereqs-tutorial-custom.md).
**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 à partir de 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.2, 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-config-custom.md#userdata-config-custom) que les testeurs peuvent inclure dans leur configuration de configuration. Le `userdata.json` fichier est utilisé pour toute information de configuration supplémentaire requise pour exécuter le test mais absente du `device.json` fichier. Consultez [Configurer userdata\$1schema.json](#userdata-schema-json).
Les fichiers de configuration 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 doit pas comporter de trait 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éer un fichier exécutable pour le scénario de test IDT](test-executables.md)
Utilisez le modèle suivant pour configurer votre `/suite///test.json` fichier :
```
{
"id": "",
"title": "",
"details": "",
"requireDUT": true | false,
"requiredResources": [
{
"name": "",
"features": [
{
"name": "",
"version": "",
"jobSlots":
}
]
}
],
"execution": {
"timeout": ,
"mac": {
"cmd": "/path/to/executable",
"args": [
""
],
},
"linux": {
"cmd": "/path/to/executable",
"args": [
""
],
},
"win": {
"cmd": "/path/to/executable",
"args": [
""
]
}
},
"environmentVariables": [
{
"key": "",
"value": "",
}
]
}
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**`id`**
Un identifiant unique défini par l'utilisateur pour le scénario de test. La valeur de `id` doit correspondre au nom du dossier de scénario de test dans lequel se trouve le `test.json` fichier et ne doit pas comporter de trait de soulignement (`_`). L'ID est utilisé dans les rapports de test générés par IDT.
**`title`**
Nom descriptif du scénario de test. Le nom est affiché dans la CLI IDT pour les testeurs.
**`details`**
Brève description de l'objectif du scénario de test.
**`requireDUT`**
Facultatif. Réglez sur `true` si un appareil est requis pour exécuter ce test, sinon sur`false`. La valeur par défaut est `true`. Les testeurs configureront les appareils qu'ils utiliseront pour exécuter le test dans leur `device.json` fichier.
**`requiredResources`**
Facultatif. Un tableau qui fournit des informations sur les périphériques de ressources nécessaires pour exécuter ce test.
**`requiredResources.name`**
Le nom unique à attribuer au périphérique de ressource lors de l'exécution de ce test.
**`requiredResources.features`**
Un ensemble de fonctionnalités de périphérique de ressources définies par l'utilisateur.
**`requiredResources.features.name`**
Nom de la fonctionnalité. Fonctionnalité de l'appareil pour laquelle vous souhaitez utiliser cet appareil. Ce nom est comparé au nom de la fonctionnalité fourni par le testeur dans le `resource.json` fichier.
**`requiredResources.features.version`**
Facultatif. Version de la fonctionnalité. Cette valeur est comparée à la version de fonctionnalité fournie par le testeur dans le `resource.json` fichier. Si aucune version n'est fournie, la fonctionnalité n'est pas cochée. Si aucun numéro de version n'est requis pour la fonctionnalité, laissez ce champ vide.
**`requiredResources.features.jobSlots`**
Facultatif. Le nombre de tests simultanés que cette fonctionnalité peut prendre en charge. La valeur par défaut est `1`. Si vous souhaitez qu'IDT utilise des appareils distincts pour des fonctionnalités individuelles, nous vous recommandons de définir cette valeur sur`1`.
**`execution.timeout`**
Durée (en millisecondes) pendant laquelle IDT attend la fin du test. Pour plus d'informations sur la définition de cette valeur, consultez[Créer un fichier exécutable pour le scénario de test IDT](test-executables.md).
**`execution.os`**
Les exécutables du scénario de test à exécuter sont basés sur le système d'exploitation de l'ordinateur hôte qui exécute IDT. Les valeurs prises en charge sont `linux`, `mac` et `win`.
**`execution.os.cmd`**
Le chemin d'accès au fichier exécutable du scénario de test que vous souhaitez exécuter pour le système d'exploitation spécifié. Cet emplacement doit se trouver dans le chemin du système.
**`execution.os.args`**
Facultatif. Les arguments à fournir pour exécuter l'exécutable du scénario de test.
**`environmentVariables`**
Facultatif. Un tableau de variables d'environnement défini pour ce cas de test.
**`environmentVariables.key`**
Le nom de la variable d'environnement.
**`environmentVariables.value`**
Valeur de la variable d'environnement.
Si vous spécifiez la même variable d'environnement dans le `test.json` fichier et dans le `suite.json` fichier, la valeur du `test.json` fichier est prioritaire.
## Configurer 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 absentes du `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#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-test-orchestrator.md#idt-test-orchestrator-context).
# Configuration de l'orchestrateur de test IDT
*À partir de IDT v4.5.2, 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 la machine d'état IDT. Nous vous recommandons vivement d'utiliser l'orchestrateur de tests pour développer vos suites de tests plutôt que la machine à états 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 `custom-test-suite-folder/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. Liste des conditions et des scénarios de test correspondants 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**
**Exemple**
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`
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`.
## 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.2, 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, au lieu de recourir à la suite de tests complète.
+ Si aucun groupe de test spécifique n'est sélectionné, exécute chaque groupe de test de la suite de tests dans un ordre aléatoire.
+ Génère des rapports et imprime un résumé de console présentant les résultats des tests pour chaque groupe de test et chaque cas de test.
La machine d'état d'une suite de tests IDT doit répondre aux critères suivants :
+ Chaque état correspond à une action que doit effectuer IDT, par exemple exécuter un groupe de test ou produire un fichier de rapport.
+ Le passage à un état exécute l'action associée à cet état.
+ Chaque état définit la règle de transition pour l'état suivant.
+ L'état final doit être l'un `Succeed` ou l'autre`Fail`.
## Format de machine à états
Vous pouvez utiliser le modèle suivant pour configurer votre propre `/suite/state_machine.json` fichier :
```
{
"Comment": "",
"StartAt": "",
"States": {
"": {
"Type": "",
// Additional state configuration
}
// Required states
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**`Comment`**
Description de la machine à états.
**`StartAt`**
Nom de l'état dans lequel IDT commence à exécuter la suite de tests. La valeur de `StartAt` doit être définie sur l'un des états répertoriés dans l'`States`objet.
**`States`**
Objet qui fait correspondre les noms d'état définis par l'utilisateur à des états IDT valides. Chaque État. *state-name*l'objet contient la définition d'un état valide mappé à. *state-name*
L'`States`objet doit inclure les `Fail` états `Succeed` et. Pour plus d'informations sur les états valides, consultez[États valides et définitions d'états](#valid-states).
## États valides et définitions d'états
Cette section décrit les définitions d'état de tous les états valides qui peuvent être utilisés dans la machine d'état IDT. Certains des états suivants prennent en charge les configurations au niveau du scénario de test. Toutefois, nous vous recommandons de configurer les règles de transition d'état au niveau du groupe de test plutôt qu'au niveau du cas de test, sauf si cela est absolument nécessaire.
**Topics**
+ [RunTask](#state-runtask)
+ [Choice](#state-choice)
+ [Parallèle](#state-parallel)
+ [AddProductFeatures](#state-addproductfeatures)
+ [Rapport](#state-report)
+ [LogMessage](#state-logmessage)
+ [SelectGroup](#state-selectgroup)
+ [Fail](#state-fail)
+ [Succeed](#state-succeed)
### RunTask
L'`RunTask`État exécute des scénarios de test à partir d'un groupe de tests défini dans la suite de tests.
```
{
"Type": "RunTask",
"Next": "",
"TestGroup": "",
"TestCases": [
""
],
"ResultVar": ""
}
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**`Next`**
Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel.
**`TestGroup`**
Facultatif. ID du groupe de test à exécuter. Si cette valeur n'est pas spécifiée, IDT exécute le groupe de test sélectionné par le testeur.
**`TestCases`**
Facultatif. Un tableau de scénarios de test IDs provenant du groupe spécifié dans`TestGroup`. Sur la base des valeurs de `TestGroup` et`TestCases`, IDT détermine le comportement d'exécution du test comme suit :
+ Lorsque `TestGroup` les deux `TestCases` sont spécifiés, IDT exécute les cas de test spécifiés à partir du groupe de test.
+ Lorsqu'ils `TestCases` sont spécifiés mais `TestGroup` non spécifiés, IDT exécute les cas de test spécifiés.
+ Lorsqu'il `TestGroup` est spécifié, mais `TestCases` non spécifié, IDT exécute tous les cas de test au sein du groupe de test spécifié.
+ Lorsque ni l'`TestGroup`un ni l'autre n'`TestCases`est spécifié, IDT exécute tous les cas de test à partir du groupe de test sélectionné par le lanceur de tests dans la CLI IDT. Pour permettre la sélection de groupes pour les testeurs, vous devez inclure à la fois les `Choice` états `RunTask` et les états dans votre `statemachine.json` fichier. Pour un exemple de la façon dont cela fonctionne, voir [Exemple de machine à états : exécuter des groupes de test sélectionnés par l'utilisateur](#allow-specific-groups).
Pour plus d'informations sur l'activation des commandes IDT CLI pour les testeurs, consultez[Activer les commandes IDT CLI](test-executables.md#idt-cli-coop).
**`ResultVar`**
Nom de la variable de contexte à définir avec les résultats du test. Ne spécifiez pas cette valeur si vous n'avez pas indiqué de valeur pour`TestGroup`. IDT définit la valeur de la variable que vous définissez dans `true` ou `ResultVar` en `false` fonction des éléments suivants :
+ Si le nom de la variable est au format`text_text_passed`, la valeur est définie de manière à indiquer si tous les tests du premier groupe de tests ont été réussis ou ignorés.
+ Dans tous les autres cas, la valeur est définie selon que tous les tests de tous les groupes de tests ont été réussis ou ignorés.
Généralement, vous utiliserez `RunTask` state pour spécifier un identifiant de groupe de test sans spécifier de cas de test individuel IDs, de sorte qu'IDT exécute tous les cas de test dans le groupe de test spécifié. Tous les cas de test exécutés par cet état sont exécutés en parallèle, dans un ordre aléatoire. Toutefois, si tous les scénarios de test nécessitent l'exécution d'un périphérique et qu'un seul périphérique est disponible, les scénarios de test seront exécutés de manière séquentielle.
**Gestion des erreurs**
Si l'un des groupes de tests ou des scénarios de test IDs spécifiés n'est pas valide, cet état génère l'erreur d'`RunTaskError`exécution. Si l'état rencontre une erreur d'exécution, il définit également la `hasExecutionError` variable dans le contexte de la machine à états sur`true`.
### Choice
L'`Choice`état vous permet de définir dynamiquement l'état suivant vers lequel passer en fonction des conditions définies par l'utilisateur.
```
{
"Type": "Choice",
"Default": "",
"FallthroughOnError": true | false,
"Choices": [
{
"Expression": "",
"Next": ""
}
]
}
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**`Default`**
État par défaut vers lequel passer si aucune des expressions définies dans ne `Choices` peut être évaluée`true`.
**`FallthroughOnError`**
Facultatif. Spécifie le comportement lorsque l'état rencontre une erreur lors de l'évaluation des expressions. Définissez cette `true` valeur si vous souhaitez ignorer une expression si l'évaluation entraîne une erreur. Si aucune expression ne correspond, la machine à états passe à l'`Default`état. Si la `FallthroughOnError` valeur n'est pas spécifiée, elle est définie par défaut sur`false`.
**`Choices`**
Tableau d'expressions et d'états permettant de déterminer l'état vers lequel passer après avoir exécuté les actions dans l'état actuel.
**`Choices.Expression`**
Chaîne d'expression dont l'évaluation correspond à une valeur booléenne. Si l'expression est évaluée à`true`, la machine à états passe à l'état défini dans`Choices.Next`. Les chaînes d'expression récupèrent les valeurs du contexte de la machine à états, puis exécutent des opérations sur celles-ci pour obtenir une valeur booléenne. Pour plus d'informations sur l'accès au contexte de la machine à états, consultez[Contexte de la machine à états](#state-machine-context).
**`Choices.Next`**
Nom de l'état vers lequel passer si l'expression définie dans `Choices.Expression` correspond à`true`.
**Gestion des erreurs**
L'`Choice`état peut nécessiter la gestion des erreurs dans les cas suivants :
+ Certaines variables des expressions de choix n'existent pas dans le contexte de la machine à états.
+ Le résultat d'une expression n'est pas une valeur booléenne.
+ Le résultat d'une recherche JSON n'est pas une chaîne, un nombre ou un booléen.
Vous ne pouvez pas utiliser un `Catch` bloc pour gérer les erreurs dans cet état. Si vous souhaitez arrêter l'exécution de la machine d'état lorsqu'elle rencontre une erreur, vous devez `FallthroughOnError` définir sur`false`. Toutefois, nous vous recommandons de configurer l'une des `FallthroughOnError` options suivantes et`true`, en fonction de votre cas d'utilisation, d'effectuer l'une des opérations suivantes :
+ Si une variable à laquelle vous accédez ne devrait pas exister dans certains cas, utilisez la valeur de `Default` et des `Choices` blocs supplémentaires pour spécifier l'état suivant.
+ Si une variable à laquelle vous accédez doit toujours exister, définissez son `Default` état sur`Fail`.
### Parallèle
L'`Parallel`état vous permet de définir et d'exécuter de nouvelles machines à états en parallèle les unes avec les autres.
```
{
"Type": "Parallel",
"Next": "",
"Branches": [
]
}
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**`Next`**
Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel.
**`Branches`**
Un tableau de définitions de machines à états à exécuter. Chaque définition de machine à états doit contenir ses propres `Fail` états `StartAt``Succeed`, et. Les définitions de machines à états de ce tableau ne peuvent pas faire référence à des états en dehors de leur propre définition.
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 ne passe à l'état suivant qu'après avoir exécuté toutes les machines d'état de branche. Chaque état nécessitant un appareil attendra de fonctionner jusqu'à ce que l'appareil soit disponible. Si plusieurs appareils sont disponibles, cet état exécute des scénarios de test à partir de plusieurs groupes en parallèle. Si un nombre suffisant de périphériques ne sont pas disponibles, les scénarios de test s'exécuteront de manière séquentielle. Comme les scénarios de test sont exécutés dans un ordre aléatoire lorsqu'ils sont exécutés en parallèle, différents appareils peuvent être utilisés pour exécuter des tests à partir du même groupe de test.
**Gestion des erreurs**
Assurez-vous que la machine d'état de branche et la machine d'état parent passent à l'`Fail`état pour gérer les erreurs d'exécution.
Comme les machines d'état de branche ne transmettent pas d'erreurs d'exécution à la machine d'état parent, vous ne pouvez pas utiliser de `Catch` bloc pour gérer les erreurs d'exécution dans les machines d'état de branche. Utilisez plutôt la `hasExecutionErrors` valeur dans le contexte de la machine à états partagés. Pour un exemple de la façon dont cela fonctionne, voir[Exemple de machine à états : exécuter deux groupes de tests en parallèle](#run-in-parallel).
### AddProductFeatures
L'`AddProductFeatures`état vous permet d'ajouter des fonctionnalités du produit au `awsiotdevicetester_report.xml` fichier généré par IDT.
Les fonctionnalités d'un produit sont des informations définies par l'utilisateur concernant des critères spécifiques auxquels un appareil peut répondre. Par exemple, la fonctionnalité `MQTT` du produit peut indiquer que l'appareil publie correctement les messages MQTT. Dans le rapport, les fonctionnalités du produit sont définies sous `supported` la forme d'une valeur ou d'une valeur personnalisée, en fonction de la réussite des tests spécifiés. `not-supported`
**Note**
L'`AddProductFeatures`État ne produit pas de rapports par lui-même. Cet état doit passer à l'[`Report`état permettant](#state-report) de générer des rapports.
```
{
"Type": "Parallel",
"Next": "",
"Features": [
{
"Feature": "",
"Groups": [
""
],
"OneOfGroups": [
""
],
"TestCases": [
""
],
"IsRequired": true | false,
"ExecutionMethods": [
""
]
}
]
}
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**`Next`**
Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel.
**`Features`**
Un ensemble de fonctionnalités du produit à afficher dans le `awsiotdevicetester_report.xml` fichier.
**`Feature`**
Le nom de la fonctionnalité
**`FeatureValue`**
Facultatif. La valeur personnalisée à utiliser dans le rapport à la place de`supported`. Si cette valeur n'est pas spécifiée, la valeur de la fonction est définie sur `supported` ou en fonction des résultats des tests`not-supported`.
Si vous utilisez une valeur personnalisée pour`FeatureValue`, vous pouvez tester la même fonctionnalité dans des conditions différentes, et IDT concatène les valeurs des caractéristiques pour les conditions prises en charge. Par exemple, l'extrait suivant montre l'`MyFeature`entité avec deux valeurs de fonction distinctes :
```
...
{
"Feature": "MyFeature",
"FeatureValue": "first-feature-supported",
"Groups": ["first-feature-group"]
},
{
"Feature": "MyFeature",
"FeatureValue": "second-feature-supported",
"Groups": ["second-feature-group"]
},
...
```
Si les deux groupes de test réussissent, la valeur de la fonctionnalité est définie sur`first-feature-supported, second-feature-supported`.
**`Groups`**
Facultatif. Un ensemble de groupes de test IDs. Tous les tests au sein de chaque groupe de test spécifié doivent réussir pour que la fonctionnalité soit prise en charge.
**`OneOfGroups`**
Facultatif. Un ensemble de groupes de test IDs. Tous les tests au sein d'au moins un des groupes de tests spécifiés doivent réussir pour que la fonctionnalité soit prise en charge.
**`TestCases`**
Facultatif. Un ensemble de scénarios de test IDs. Si vous spécifiez cette valeur, les règles suivantes s'appliquent :
+ Tous les scénarios de test spécifiés doivent être réussis pour que la fonctionnalité soit prise en charge.
+ `Groups`ne doit contenir qu'un seul identifiant de groupe de test.
+ `OneOfGroups`ne doit pas être spécifiée.
**`IsRequired`**
Facultatif. Réglez `false` sur pour marquer cette fonctionnalité comme fonctionnalité facultative dans le rapport. La valeur par défaut est `true`.
**`ExecutionMethods`**
Facultatif. Tableau de méthodes d'exécution correspondant à la `protocol` valeur spécifiée dans le `device.json` fichier. Si cette valeur est spécifiée, les testeurs doivent spécifier une `protocol` valeur correspondant à l'une des valeurs de ce tableau pour inclure la fonctionnalité dans le rapport. Si cette valeur n'est pas spécifiée, la fonctionnalité sera toujours incluse dans le rapport.
Pour utiliser l'`AddProductFeatures`état, vous devez définir la valeur de `ResultVar` in the `RunTask` state sur l'une des valeurs suivantes :
+ Si vous avez spécifié un scénario de test individuel IDs, réglez `ResultVar` sur`group-id_test-id_passed`.
+ Si vous n'avez pas spécifié de scénario de test individuel IDs, réglez `ResultVar` sur`group-id_passed`.
L'`AddProductFeatures`État vérifie les résultats des tests de la manière suivante :
+ Si vous n'avez spécifié aucun scénario de test IDs, le résultat de chaque groupe de test est déterminé à partir de la valeur de la `group-id_passed` variable dans le contexte de la machine à états.
+ Si vous avez spécifié un scénario de test IDs, le résultat de chacun des tests est déterminé à partir de la valeur de la `group-id_test-id_passed` variable dans le contexte de la machine à états.
**Gestion des erreurs**
Si un identifiant de groupe fourni dans cet état n'est pas un identifiant de groupe valide, cet état entraîne une erreur d'`AddProductFeaturesError`exécution. Si l'état rencontre une erreur d'exécution, il définit également la `hasExecutionErrors` variable dans le contexte de la machine à états sur`true`.
### Rapport
L'`Report`état génère les `awsiotdevicetester_report.xml` fichiers `suite-name_Report.xml` et. Cet état diffuse également le rapport vers la console.
```
{
"Type": "Report",
"Next": ""
}
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**`Next`**
Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel.
Vous devez toujours passer à l'`Report`état vers la fin du flux d'exécution des tests afin que les testeurs puissent voir les résultats des tests. Généralement, l'état suivant après cet état est`Succeed`.
**Gestion des erreurs**
Si cet état rencontre des problèmes lors de la génération des rapports, il émet l'erreur d'`ReportError`exécution.
### LogMessage
L'`LogMessage`état génère le `test_manager.log` fichier et transmet le message du journal à la console.
```
{
"Type": "LogMessage",
"Next": ""
"Level": "info | warn | error"
"Message": ""
}
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**`Next`**
Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel.
**`Level`**
Le niveau d'erreur auquel le message de journal doit être créé. Si vous spécifiez un niveau non valide, cet état génère un message d'erreur et le supprime.
**`Message`**
Le message à enregistrer.
### SelectGroup
L'`SelectGroup`état met à jour le contexte de la machine à états pour indiquer quels groupes sont sélectionnés. Les valeurs définies par cet état sont utilisées par tous `Choice` les états suivants.
```
{
"Type": "SelectGroup",
"Next": ""
"TestGroups": [
"
]
}
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**`Next`**
Nom de l'état vers lequel passer après l'exécution des actions dans l'état actuel.
**`TestGroups`**
Un ensemble de groupes de test qui seront marqués comme sélectionnés. Pour chaque ID de groupe de test de ce tableau, la `group-id_selected` variable est définie sur `true` dans le contexte. Assurez-vous de fournir un groupe de test valide IDs car IDT ne valide pas l'existence des groupes spécifiés.
### Fail
L'`Fail`état indique que la machine à états ne s'est pas exécutée correctement. Il s'agit d'un état final pour la machine à états, et chaque définition de machine à états doit inclure cet état.
```
{
"Type": "Fail"
}
```
### Succeed
L'`Succeed`état indique que la machine à états s'est exécutée correctement. Il s'agit d'un état final pour la machine à états, et chaque définition de machine à états doit inclure cet état.
```
{
"Type": "Succeed"
}
```
## Contexte de la machine à états
Le contexte de la machine à états est un document JSON en lecture seule qui contient les données mises à la disposition de la machine à états pendant l'exécution. Le contexte de la machine à états n'est accessible qu'à partir de la machine à états et contient des informations qui déterminent le flux de test. Par exemple, vous pouvez utiliser les informations configurées par les testeurs dans le `userdata.json` fichier pour déterminer si un test spécifique est requis pour être exécuté.
Le contexte de la machine à états utilise le format suivant :
```
{
"pool": {
},
"userData": {
},
"config": {
},
"suiteFailed": true | false,
"specificTestGroups": [
""
],
"specificTestCases": [
""
],
"hasExecutionErrors": true
}
```
**`pool`**
Informations sur le pool de périphériques sélectionné pour le test. Pour un pool de périphériques sélectionné, ces informations sont extraites de l'élément de tableau de pool de périphériques de niveau supérieur correspondant défini dans le `device.json` fichier.
**`userData`**
Informations contenues dans le `userdata.json` fichier.
**`config`**
Informations épinglez le `config.json` fichier.
**`suiteFailed`**
La valeur est définie sur le `false` démarrage de la machine à états. Si un groupe de test échoue dans un `RunTask` état, cette valeur est définie sur la durée restante `true` de l'exécution de la machine à états.
**`specificTestGroups`**
Si le testeur sélectionne des groupes de tests spécifiques à exécuter au lieu de l'ensemble de la suite de tests, cette clé est créée et contient la liste des groupes de tests spécifiques IDs.
**`specificTestCases`**
Si le lanceur de tests sélectionne des cas de test spécifiques à exécuter au lieu de la suite de tests complète, cette clé est créée et contient la liste des cas de test spécifiques IDs.
**`hasExecutionErrors`**
Ne se ferme pas au démarrage de la machine à états. Si un état rencontre une erreur d'exécution, cette variable est créée et définie `true` pour la durée restante de l'exécution de la machine à états.
Vous pouvez interroger le contexte à l'aide de la JSONPath notation. La syntaxe des JSONPath requêtes dans les définitions d'état est`{{$.query}}`. Vous pouvez utiliser des JSONPath requêtes comme chaînes d'espace réservé dans certains États. IDT remplace les chaînes d'espace réservé par la valeur de la JSONPath requête évaluée à partir du contexte. Vous pouvez utiliser des espaces réservés pour les valeurs suivantes :
+ La `TestCases` valeur 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éer un fichier exécutable pour le scénario de test IDT
Vous pouvez créer et placer un exécutable de scénario 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 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 IDT
Les commandes suivantes permettent à vos suites de tests de communiquer avec IDT.
**`PollForNotifications`**
Permet aux suites de tests de vérifier les notifications provenant d'IDT.
**`GetContextValue ` et `GetContextString`**
Permet aux suites de tests de récupérer des valeurs à partir du contexte IDT. Pour de plus amples informations, veuillez consulter [Utiliser le contexte IDT](idt-context.md).
**`SendResult`**
Permet aux suites de tests de communiquer les résultats des scénarios de test à IDT. Cette commande doit être appelée à la fin de chaque scénario de test dans une suite de tests.
### Interaction avec l'hôte
La commande suivante permet à vos suites de tests de communiquer avec la machine hôte.
**`PollForNotifications`**
Permet aux suites de tests de vérifier les notifications provenant d'IDT.
**`GetContextValue` et `GetContextString`**
Permet aux suites de tests de récupérer des valeurs à partir du contexte IDT. Pour de plus amples informations, veuillez consulter [Utiliser le contexte IDT](idt-context.md).
**`ExecuteOnHost`**
Permet aux suites de tests d'exécuter des commandes sur la machine locale et permet à IDT de gérer le cycle de vie des exécutables des scénarios de test.
## Activer les commandes IDT CLI
La `run-suite` commande IDT CLI fournit plusieurs options qui permettent au lanceur de tests de personnaliser l'exécution des tests. Pour permettre aux testeurs d'utiliser ces options pour exécuter votre suite de tests personnalisée, vous implémentez le support de la CLI IDT. Si vous n'implémentez pas le support, les testeurs pourront toujours exécuter des tests, mais certaines options de la CLI ne fonctionneront pas correctement. Pour offrir une expérience client optimale, nous vous recommandons de mettre en œuvre la prise en charge des arguments suivants pour la `run-suite` commande dans la CLI IDT :
**`timeout-multiplier`**
Spécifie une valeur supérieure à 1,0 qui sera appliquée à tous les délais d'expiration lors de l'exécution des tests.
Les testeurs peuvent utiliser cet argument pour augmenter le délai d'expiration des scénarios de test qu'ils souhaitent exécuter. Lorsqu'un lanceur de tests spécifie cet argument dans sa `run-suite` commande, IDT l'utilise pour calculer la valeur de la variable d'environnement IDT\$1TEST\$1TIMEOUT et définit le champ dans le contexte IDT. `config.timeoutMultiplier` Pour étayer cet argument, vous devez procéder comme suit :
+ Au lieu d'utiliser directement la valeur de délai d'attente du `test.json` fichier, lisez la variable d'environnement IDT\$1TEST\$1TIMEOUT pour obtenir la valeur de délai d'expiration correctement calculée.
+ Récupérez la `config.timeoutMultiplier` valeur dans le contexte IDT et appliquez-la à des délais d'expiration prolongés.
Pour plus d'informations sur la fermeture anticipée en raison d'événements liés au délai imparti, consultez. [Spécifier le comportement de sortie](#test-exec-exiting)
**`stop-on-first-failure`**
Spécifie qu'IDT doit arrêter d'exécuter tous les tests en cas d'échec.
Lorsqu'un lanceur de tests spécifie cet argument dans sa `run-suite` commande, IDT arrête d'exécuter les tests dès qu'il rencontre un échec. Toutefois, si les scénarios de test sont exécutés en parallèle, cela peut entraîner des résultats inattendus. Pour mettre en œuvre le support, assurez-vous que si IDT rencontre cet événement, votre logique de test indique à tous les scénarios de test en cours d'exécution de s'arrêter, de nettoyer les ressources temporaires et de communiquer un résultat de test à IDT. Pour plus d'informations sur la gestion anticipée des défaillances, consultez[Spécifier le comportement de sortie](#test-exec-exiting).
**`group-id` et `test-id`**
Spécifie qu'IDT ne doit exécuter que les groupes de tests ou les cas de test sélectionnés.
Les testeurs peuvent utiliser ces arguments avec leur `run-suite` commande pour spécifier le comportement d'exécution du test suivant :
+ Exécutez tous les tests au sein des groupes de tests spécifiés.
+ Exécutez une sélection de tests au sein d'un groupe de tests spécifié.
Pour prendre en charge ces arguments, la machine à états de votre suite de tests doit inclure un ensemble spécifique d'`Choice`états `RunTask` et dans votre machine à états. Si vous n'utilisez pas de machine à états personnalisée, la machine à états IDT par défaut inclut les états requis pour vous et vous n'avez pas besoin de prendre d'autres mesures. Toutefois, si vous utilisez une machine à états personnalisée, utilisez-la [Exemple de machine à états : exécuter des groupes de test sélectionnés par l'utilisateur](idt-state-machine.md#allow-specific-groups) comme exemple pour ajouter les états requis dans votre machine à états.
Pour plus d'informations sur les commandes IDT CLI, consultez[Déboguer et exécuter des suites de tests personnalisées](run-tests-custom.md).
## Rédiger des journaux d'événements
Pendant le test, vous envoyez des données à la console `stdout` et vous `stderr` devez y écrire des journaux d'événements et des messages d'erreur. Pour plus d'informations sur le format des messages de console, consultez[Format des messages de console](idt-review-results-logs.md#idt-console-format).
Lorsque l'IDT a terminé d'exécuter la suite de tests, ces informations sont également disponibles dans le `test_manager.log` fichier situé dans le `/results//logs` dossier.
Vous pouvez configurer chaque scénario de test pour écrire les journaux de son exécution, y compris les journaux du périphérique testé, dans le `_` fichier situé dans le `/results/execution-id/logs` dossier. Pour ce faire, récupérez le chemin 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 s'arrête avant sa fin dans les événements suivants. Utilisez ces informations pour configurer le fichier exécutable de votre scénario de test afin de détecter chacun de ces événements dans le scénario de test :
****Expiration****
Se produit lorsqu'un scénario de test s'exécute pendant une durée supérieure à la valeur de délai spécifiée dans le `test.json` fichier. Si le lanceur de test a utilisé l'`timeout-multiplier`argument pour spécifier un multiplicateur de délai d'attente, IDT calcule la valeur du délai d'expiration avec le multiplicateur.
Pour détecter cet événement, utilisez la variable d'environnement IDT\$1TEST\$1TIMEOUT. Lorsqu'un lanceur de tests lance un test, IDT définit la valeur de la variable d'environnement IDT\$1TEST\$1TIMEOUT sur la valeur du délai d'attente calculée (en secondes) et transmet la variable à l'exécutable du scénario de test. Vous pouvez lire la valeur de la variable pour définir un temporisateur approprié.
****Interrompre****
Survient lorsque le lanceur de test interrompt l'IDT. Par exemple, en appuyant surCtrl\$1C.
É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,
"idtRootPath":
},
"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-config-custom.md#config-json-custom). Le `config` champ contient également les champs supplémentaires suivants :
**`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`.
**`config.idRootPath`**
Cette valeur est un espace réservé pour la valeur du chemin absolu d'IDT lors de la configuration du `userdata.json` fichier. Ceci est utilisé par les commandes build et flash.
**`device`**
Informations sur le périphérique sélectionné pour le test. Ces informations sont équivalentes à l'élément du `devices` tableau dans le [`device.json`fichier](set-config-custom.md#device-config-custom) du périphérique sélectionné.
**`devicePool`**
Informations sur le pool de périphériques sélectionné pour le test. Ces informations sont équivalentes à l'élément de tableau de pool de périphériques de niveau supérieur défini dans le `device.json` fichier pour le pool de périphériques sélectionné.
**`resource`**
Informations sur les périphériques de ressources contenues dans le `resource.json` fichier.
**`resource.devices`**
Ces informations sont équivalentes au `devices` tableau défini dans le `resource.json` fichier. Chaque `devices` élément inclut le champ supplémentaire suivant :
**`resource.device.name`**
Nom du périphérique ressource. Cette valeur est définie sur la `requiredResource.name` valeur du `test.json` fichier.
**`testData.awsCredentials`**
Les AWS informations d'identification utilisées par le test pour se connecter au AWS cloud. Ces informations sont extraites du `config.json` fichier.
**`testData.logFilePath`**
Le chemin d'accès au fichier journal dans lequel le scénario de test écrit les messages de journal. La suite de tests crée ce fichier s'il n'existe pas.
**`userData`**
Informations fournies par le testeur dans le [`userdata.json`fichier](set-config-custom.md#userdata-config-custom).
## Accédez aux données dans le contexte
Vous pouvez interroger le contexte en utilisant les JSONPath notations de vos fichiers de configuration et de votre exécutable texte avec le `GetContextValue` et `GetContextString` APIs. La syntaxe des JSONPath chaînes permettant d'accéder au contexte IDT varie comme suit :
+ Dans `suite.json` et`test.json`, tu utilises`{{query}}`. En d'autres termes, n'utilisez pas l'élément racine `$.` pour démarrer votre expression.
+ Dans`statemachine.json`, tu utilises`{{$.query}}`.
+ Dans les commandes d'API, vous utilisez `query` ou`{{$.query}}`, selon la commande. Pour plus d'informations, consultez la documentation intégrée dans le SDKs.
Le tableau suivant décrit les opérateurs d'une expression foobar JSONPath typique :
| Opérateur | Description |
| --- | --- |
| \$1 | L'élément racine. La valeur de contexte de haut niveau pour IDT étant un objet, vous l'utiliserez généralement \$1. pour démarrer vos requêtes. |
| .childName | Accède à l'élément enfant dont le nom childName provient d'un objet. S'il est appliqué à un tableau, il produit un nouveau tableau avec cet opérateur appliqué à chaque élément. Le nom de l'élément distingue les majuscules et minuscules. Par exemple, la requête pour accéder à la awsRegion valeur de l'configobjet est\$1.config.awsRegion. |
| [start:end] | Filtre les éléments d'un tableau, en récupérant les éléments en commençant par l'startindex et en remontant jusqu'à l'endindex, dans les deux cas inclus. |
| [index1, index2, ... , indexN] | Filtre les éléments d'un tableau, en récupérant les éléments uniquement à partir des indices spécifiés. |
| [?(expr)] | Filtre les éléments d'un tableau à l'aide de l'exprexpression. Cette expression doit être évaluée à une valeur booléenne. |
Pour créer des expressions de filtre, utilisez la syntaxe suivante :
```
| operator |
```
Dans cette syntaxe :
+ `jsonpath`est un JSONPath qui utilise la syntaxe JSON standard.
+ `value`est une valeur personnalisée qui utilise la syntaxe JSON standard.
+ `operator`est l'un des opérateurs suivants :
+ `<`(Inférieur à)
+ `<=`(Inférieur ou égal à)
+ `==`(Égal à)
Si la valeur JSONPath ou de votre expression est un tableau, une valeur booléenne ou une valeur d'objet, il s'agit du seul opérateur binaire pris en charge que vous pouvez utiliser.
+ `>=`(Supérieur ou égal à)
+ `>`(Supérieur à)
+ `=~`(Correspondance d'expressions régulières). Pour utiliser cet opérateur dans une expression de filtre, la valeur JSONPath ou sur le côté gauche de votre expression doit être une chaîne et le côté droit doit être une valeur de modèle conforme à la [RE2syntaxe](https://github.com/google/re2/wiki/Syntax).
Vous pouvez utiliser JSONPath des requêtes sous la forme \$1\$1*query*\$1\$1 comme chaînes d'espace réservé dans les `environmentVariables` champs `args` et `test.json` des fichiers et dans les `environmentVariables` champs des `suite.json` fichiers. IDT effectue une recherche contextuelle et remplit les champs avec la valeur évaluée de la requête. Par exemple, dans le `suite.json` fichier, vous pouvez utiliser des chaînes d'espace réservé pour spécifier des valeurs de variables d'environnement qui changent avec chaque scénario de test et IDT remplira les variables d'environnement avec la valeur correcte pour chaque cas de test. Toutefois, lorsque vous utilisez des chaînes d'espace réservé dans des `suite.json` fichiers `test.json` et, les considérations suivantes s'appliquent à vos requêtes :
+ Vous devez écrire toutes les occurrences de la `devicePool` clé dans votre requête en minuscules. C'est-à-dire, utilisez `devicepool` plutôt.
+ Pour les tableaux, vous ne pouvez utiliser que des tableaux de chaînes. De plus, les tableaux utilisent un format non standard. `item1, item2,...,itemN` Si le tableau ne contient qu'un seul élément, il est sérialisé en tant que tel`item`, ce qui le rend impossible à distinguer d'un champ de chaîne.
+ Vous ne pouvez pas utiliser d'espaces réservés pour récupérer des objets depuis le contexte.
En raison de ces considérations, nous vous recommandons, dans la mesure du possible, d'utiliser l'API pour accéder au contexte de votre logique de test au lieu d'utiliser des chaînes de caractères dans `suite.json` les fichiers `test.json` et. Toutefois, dans certains cas, il peut être plus pratique d'utiliser des JSONPath espaces réservés pour récupérer des chaînes uniques à définir comme variables d'environnement.
# Configuration des paramètres pour les testeurs
Pour exécuter des suites de tests personnalisées, les testeurs doivent configurer leurs paramètres en fonction de la suite de tests qu'ils souhaitent exécuter. Les paramètres sont spécifiés en fonction des modèles de fichiers de configuration situés dans le `/configs/` dossier. Si nécessaire, les testeurs doivent également configurer des AWS informations d'identification qu'IDT utilisera pour se connecter au AWS cloud.
En tant que rédacteur de tests, vous devrez configurer ces fichiers pour [déboguer votre suite de tests](run-tests-custom.md). Vous devez fournir des instructions aux testeurs afin qu'ils puissent configurer les paramètres suivants selon les besoins pour exécuter vos suites de tests.
## Configurer device.json
Le `device.json` fichier contient des informations sur les appareils sur lesquels les tests sont exécutés (par exemple, adresse IP, informations de connexion, système d'exploitation et architecture du processeur).
Les testeurs peuvent fournir ces informations à l'aide du `device.json` fichier modèle suivant situé dans le `/configs/` dossier.
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "",
"value": "",
"configs": [
{
"name": "",
"value": ""
}
],
}
],
"devices": [
{
"id": "",
"pairedResource": "", //used for no-op protocol
"connectivity": {
"protocol": "ssh | uart | docker | no-op",
// ssh
"ip": "",
"port": ,
"publicKeyPath": "",
"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 appareils AWS partenaires, le SKU que vous spécifiez ici doit correspondre au SKU que vous avez utilisé lors du processus de mise en vente.
**`features`**
Facultatif. Un tableau contenant les fonctions prises en charge de l'appareil. Les fonctionnalités de l'appareil sont des valeurs définies par l'utilisateur que vous configurez dans votre suite de tests. Vous devez fournir à vos testeurs des informations sur les noms et les valeurs des fonctionnalités à inclure dans le `device.json` fichier. Par exemple, si vous souhaitez tester un périphérique qui fonctionne comme un serveur MQTT pour d'autres appareils, vous pouvez configurer votre logique de test pour valider les niveaux pris en charge spécifiques pour une fonctionnalité nommée`MQTT_QoS`. Les testeurs fournissent le nom de cette fonctionnalité et définissent la valeur de la fonctionnalité en fonction des niveaux de QoS pris en charge par leur appareil. Vous pouvez récupérer les informations fournies depuis le [contexte IDT](idt-context.md) avec la `devicePool.features` requête ou depuis le [contexte de la machine à états](idt-state-machine.md#state-machine-context) avec la `pool.features` requête.
**`features.name`**
Nom de la fonctionnalité.
**`features.value`**
Les valeurs des fonctionnalités prises en charge.
**`features.configs`**
Paramètres de configuration, si nécessaire, pour la fonctionnalité.
**`features.config.name`**
Nom du paramètre de configuration.
**`features.config.value`**
Les valeurs de réglage prises en charge.
**`devices`**
Un ensemble d'appareils du pool à tester. Au moins un appareil est requis.
**`devices.id`**
Un identificateur unique défini par l'utilisateur pour l'appareil testé.
**`devices.pairedResource`**
Identifiant unique défini par l'utilisateur pour un périphérique ressource. Cette valeur est requise lorsque vous testez des appareils à l'aide du protocole de `no-op` connectivité.
**`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, `docker` pour les conteneurs Docker et `no-op` pour les appareils qui n'ont pas de connexion directe avec la machine hôte IDT mais qui ont besoin d'un périphérique ressource comme intergiciel physique pour communiquer avec la machine hôte.
Pour les appareils non opérationnels, vous configurez l'ID du périphérique ressource dans`devices.pairedResource`. Vous devez également spécifier cet ID dans le `resource.json` fichier. L'appareil jumelé doit être un appareil physiquement jumelé à l'appareil testé. Une fois qu'IDT a identifié le périphérique ressource jumelé et s'y est connecté, IDT ne se connecte pas aux autres périphériques ressources conformément aux fonctionnalités décrites dans le `test.json` fichier.
**`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. 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 au périphérique 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`.
**`connectivity.auth`**
Informations d'authentification pour la connexion.
Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`.
**`connectivity.auth.method`**
Méthode d'authentification utilisée pour accéder à un appareil sur le protocole de connectivité donné.
Les valeurs prises en charge sont :
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Informations d'identification utilisées pour l'authentification.
**`connectivity.auth.credentials.password`**
Mot de passe utilisé pour se connecter à l'appareil à tester.
Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `password`.
**`connectivity.auth.credentials.privKeyPath`**
Chemin complet de la clé privée utilisée pour se connecter à l'appareil testé.
Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `pki`.
**`connectivity.auth.credentials.user`**
Nom d'utilisateur pour la connexion à l'appareil testé.
**`connectivity.serialPort`**
Facultatif. Port série auquel le périphérique est connecté.
Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `uart`.
**`connectivity.containerId`**
ID de conteneur ou nom du conteneur Docker en cours de test.
Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `docker`.
**`connectivity.containerUser`**
Facultatif. Le nom de l'utilisateur à l'intérieur du conteneur. La valeur par défaut est l'utilisateur indiqué dans le Dockerfile.
La valeur par défaut est 22.
Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `docker`.
Pour vérifier si les testeurs configurent la mauvaise connexion au périphérique pour un test, vous pouvez la récupérer dans le contexte `pool.Devices[0].Connectivity.Protocol` de la machine à états et la comparer à la valeur attendue dans un `Choice` état. Si un protocole incorrect est utilisé, imprimez un message en utilisant l'`LogMessage`état et passez à l'`Fail`état.
Vous pouvez également utiliser un code de gestion des erreurs pour signaler un échec de test pour des types de périphériques incorrects.
## (Facultatif) Configurer userdata.json
Le `userdata.json` fichier contient toutes les informations supplémentaires requises par une suite de tests mais qui ne sont pas spécifiées dans le `device.json` fichier. Le format de ce fichier dépend du [`userdata_scheme.json`fichier](idt-json-config.md#userdata-schema-json) défini dans la suite de tests. Si vous êtes rédacteur de tests, assurez-vous de fournir ces informations aux utilisateurs qui exécuteront les suites de tests que vous écrivez.
## (Facultatif) Configurer resource.json
Le `resource.json` fichier contient des informations sur les périphériques qui seront utilisés comme périphériques de ressources. Les périphériques ressources sont des appareils nécessaires pour tester certaines fonctionnalités d'un périphérique testé. Par exemple, pour tester la capacité Bluetooth d'un appareil, vous pouvez utiliser un périphérique ressource pour vérifier si votre appareil peut s'y connecter correctement. Les périphériques de ressources sont facultatifs et vous pouvez avoir besoin d'autant de périphériques de ressources que nécessaire. En tant que rédacteur de test, vous utilisez le [fichier test.json](idt-json-config.md#test-json) pour définir les fonctionnalités du périphérique de ressources requises pour un test. Les testeurs utilisent ensuite le `resource.json` fichier pour fournir un pool de périphériques de ressources dotés des fonctionnalités requises. Assurez-vous de fournir ces informations aux utilisateurs qui exécuteront les suites de tests que vous écrivez.
Les testeurs peuvent fournir ces informations à l'aide du `resource.json` fichier modèle suivant situé dans le `/configs/` dossier.
```
[
{
"id": "",
"features": [
{
"name": "",
"version": "",
"jobSlots":
}
],
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh | uart | docker",
// ssh
"ip": "",
"port": ,
"publicKeyPath": "",
"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. 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 au périphérique 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`.
**`connectivity.auth`**
Informations d'authentification pour la connexion.
Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `ssh`.
**`connectivity.auth.method`**
Méthode d'authentification utilisée pour accéder à un appareil sur le protocole de connectivité donné.
Les valeurs prises en charge sont :
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Informations d'identification utilisées pour l'authentification.
**`connectivity.auth.credentials.password`**
Mot de passe utilisé pour se connecter à l'appareil à tester.
Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `password`.
**`connectivity.auth.credentials.privKeyPath`**
Chemin complet de la clé privée utilisée pour se connecter à l'appareil testé.
Cette valeur s'applique uniquement si `connectivity.auth.method` est défini sur `pki`.
**`connectivity.auth.credentials.user`**
Nom d'utilisateur pour la connexion à l'appareil testé.
**`connectivity.serialPort`**
Facultatif. Port série auquel le périphérique est connecté.
Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `uart`.
**`connectivity.containerId`**
ID de conteneur ou nom du conteneur Docker en cours de test.
Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `docker`.
**`connectivity.containerUser`**
Facultatif. Le nom de l'utilisateur à l'intérieur du conteneur. La valeur par défaut est l'utilisateur indiqué dans le Dockerfile.
La valeur par défaut est 22.
Cette propriété s'applique uniquement si `connectivity.protocol` est défini sur `docker`.
## (Facultatif) Configurer config.json
Le `config.json` fichier contient des informations de configuration pour IDT. 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 qui est utilisée pour améliorer la fonctionnalité IDT. Pour de plus amples informations, veuillez consulter [Soumettre les statistiques d'utilisation de l'IDT](idt-usage-metrics.md).
Les testeurs peuvent configurer leurs AWS informations d'identification de l'une des manières suivantes :
+ **Fichier d’informations d’identification**
IDT utilise le même fichier d'informations d'identification que l' AWS CLI. Pour de plus amples informations, veuillez consulter [Fichiers de configuration et d'informations d'identification](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html).
L'emplacement du fichier d'informations d'identification varie en fonction du système d'exploitation que vous utilisez :
+ macOS, Linux : `~/.aws/credentials`
+ Windows: `C:\Users\UserName\.aws\credentials`
+ **Variables d'environnement**
Les variables d'environnement sont des variables gérées par le système d'exploitation et utilisées par les commandes du système. Les variables définies au cours d'une session SSH ne sont pas disponibles après la fermeture de cette session. IDT peut utiliser les variables d'`AWS_SECRET_ACCESS_KEY`environnement `AWS_ACCESS_KEY_ID` et pour stocker les informations d'identification AWS
Pour définir ces variables sous Linux, macOS ou Unix, utilisez **export**:
```
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
```
Pour définir ces variables sous Windows, utilisez **set** :
```
set AWS_ACCESS_KEY_ID=
set AWS_SECRET_ACCESS_KEY=
```
Pour configurer les AWS informations d'identification pour IDT, les testeurs modifient la `auth` section du `config.json` fichier situé dans le `/configs/` dossier.
```
{
"log": {
"location": "logs"
},
"configFiles": {
"root": "configs",
"device": "configs/device.json"
},
"testPath": "tests",
"reportPath": "results",
"awsRegion": "",
"auth": {
"method": "file | environment",
"credentials": {
"profile": ""
}
}
}
]
```
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
**Note**
Tous les chemins de ce fichier sont définis par rapport à**.
**`log.location`**
Le chemin d'accès au dossier des journaux dans le**.
**`configFiles.root`**
Le chemin d'accès au dossier contenant les fichiers de configuration.
**`configFiles.device`**
Le chemin d'accès au `device.json` fichier.
**`testPath`**
Le chemin d'accès au dossier contenant les suites de tests.
**`reportPath`**
Le chemin d'accès au dossier qui contiendra les résultats des tests une fois qu'IDT aura exécuté une suite de tests.
**`awsRegion`**
Facultatif. La AWS région que les suites de tests utiliseront. Si ce paramètre n'est pas défini, les suites de tests utiliseront la région par défaut spécifiée dans chaque suite de tests.
**`auth.method`**
Méthode utilisée par IDT pour récupérer les AWS informations d'identification. Les valeurs prises en charge sont `file` la récupération des informations d'identification à partir d'un fichier d'informations d'identification et la récupération `environment` des informations d'identification à l'aide de variables d'environnement.
**`auth.credentials.profile`**
Le profil d'informations d'identification à utiliser à partir du fichier d'informations d'identification. Cette propriété s'applique uniquement si `auth.method` est défini sur `file`.
# Déboguer et exécuter des suites de tests personnalisées
Une fois la [configuration requise](set-config-custom.md) définie, IDT peut exécuter votre suite de tests. Le temps d'exécution de la suite de tests complète dépend du matériel et de la composition de la suite de tests. À titre de référence, il faut environ 30 minutes pour terminer la suite complète de tests de qualification FreeRTOS sur un Raspberry Pi 3B.
Lorsque vous écrivez votre suite de tests, vous pouvez utiliser IDT pour exécuter la suite de tests en mode débogage afin de vérifier votre code avant de l'exécuter ou de le fournir aux testeurs.
## Exécutez IDT en mode debug
Étant donné que les suites de tests dépendent de l'IDT pour interagir avec les appareils, fournir le contexte et recevoir les résultats, vous ne pouvez pas simplement déboguer vos suites de tests dans un IDE sans aucune interaction IDT. Pour ce faire, la CLI IDT fournit la `debug-test-suite` commande qui vous permet d'exécuter IDT en mode de débogage. Exécutez la commande suivante pour afficher les options disponibles pour `debug-test-suite` :
```
devicetester_[linux | mac | win_x86-64] debug-test-suite -h
```
Lorsque vous exécutez IDT en mode débogage, IDT ne lance pas réellement la suite de tests ni n'exécute 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 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 les versions FreeRTOS, et les versions de la suite de tests de qualification FreeRTOS 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. Voici quelques options couramment utilisées :
+ `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.
```
[INFO] [2000-01-02 03:04:05]: 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.
```
[INFO] [2000-01-02 03:04:05]: Hello world! suiteId=MyTestSuitegroupId=myTestGroup testCaseId=myTestCase deviceId=my-deviceexecutionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
La partie spécifique à la suite de tests du message de console contient les champs suivants :
**`suiteId`**
Nom de la suite de tests en cours d'exécution.
**`groupId`**
ID du groupe de test en cours d'exécution.
**`testCaseId`**
ID du scénario de test en cours d'exécution.
**`deviceId`**
Identifiant de l'appareil testé utilisé par le scénario de test en cours.
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 AWS 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 dans le `awsiotdevicetester_report.xml` ou `suite-name_report.xml` répertorie les tests effectués et les résultats.
La première balise XML `` contient le résumé de l'exécution des tests. Par exemple :
```
```
**Attributs utilisés dans la `` balise**
**`name`**
Nom de la suite de tests.
**`time`**
Le temps, en secondes, nécessaire pour exécuter la suite de tests.
**`tests`**
Nombre de tests exécutés.
**`failures`**
Nombre de tests exécutés mais dont le résultat n'est pas probant.
**`errors`**
Nombre de tests qu'IDT n'a pas pu exécuter.
**`disabled`**
Cet attribut n'est pas utilisé et peut être ignoré.
En cas d'erreurs ou d'échecs de tests, vous pouvez identifier les tests concernés à l'aide des balises XML ``. Les balises XML `` au sein de la balise `` montrent le récapitulatif des résultats d'un groupe de tests. Par exemple :
```
```
Le format est similaire à la balise ``, mais avec un attribut appelé `skipped` qui n'est pas utilisé et qui ne peut pas être ignoré. Chaque balise XML `` inclut des balises `` pour chaque test exécuté pour un groupe de tests. Par exemple :
```
```
**Attributs utilisés dans la `` balise**
**`name`**
Nom du test.
**`attempts`**
Nombre de fois où IDT a exécuté le test.
Lorsqu'un test échoue ou qu'une erreur se produit, les balises `` ou `` sont ajoutées à la balise `` avec des informations relatives au dépannage. Par exemple :
```
Reason for the test failure
Reason for the test execution error
```
# Soumettre les statistiques 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 qui est utilisée pour améliorer la fonctionnalité IDT. IDT collecte des informations telles que les suivantes :
+ L'ID de AWS compte utilisé pour exécuter IDT
+ Les commandes IDT CLI utilisées pour exécuter des tests
+ La suite de tests exécutée
+ Les suites de tests dans le ** dossier
+ Le nombre d'appareils configurés dans le pool de périphériques
+ Noms des scénarios de test et durées d'exécution
+ Informations sur les résultats des tests, par exemple si les tests ont été réussis, ont échoué, ont rencontré des erreurs ou ont été ignorés
+ Caractéristiques du produit testées
+ Comportement de sortie IDT, tel que les sorties inattendues ou anticipées
Toutes les informations envoyées par IDT sont également enregistrées dans un `metrics.log` fichier du `/results//` dossier. Vous pouvez consulter le fichier journal pour voir les informations collectées lors d'un test. Ce fichier est généré uniquement si vous choisissez de collecter des statistiques d'utilisation.
Pour désactiver la collecte des métriques, il n'est pas nécessaire de prendre d'autres mesures. Ne stockez simplement pas vos AWS informations d'identification et, si vous en avez, ne configurez pas le `config.json` fichier pour y accéder. AWS
## Inscrivez-vous pour un Compte AWS
Si vous n'en avez pas Compte AWS, procédez comme suit pour en créer un.
**Pour vous inscrire à un Compte AWS**
1. Ouvrez l'[https://portal.aws.amazon.com/billing/inscription.](https://portal.aws.amazon.com/billing/signup)
1. Suivez les instructions en ligne.
Dans le cadre de la procédure d’inscription, vous recevrez un appel téléphonique ou un SMS et vous saisirez un code de vérification en utilisant le clavier numérique du téléphone.
Lorsque vous vous inscrivez à un Compte AWS, un *Utilisateur racine d'un compte AWS*est créé. Par défaut, seul l’utilisateur racine a accès à l’ensemble des Services AWS et des ressources de ce compte. La meilleure pratique de sécurité consiste à attribuer un accès administratif à un utilisateur, et à utiliser uniquement l’utilisateur racine pour effectuer les [tâches nécessitant un accès utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS vous envoie un e-mail de confirmation une fois le processus d'inscription terminé. À tout moment, vous pouvez consulter l'activité actuelle de votre compte et gérer votre compte en accédant à [https://aws.amazon.com/](https://aws.amazon.com/)et en choisissant **Mon compte**.
## Création d’un utilisateur doté d’un accès administratif
Après vous être inscrit à un Compte AWS, sécurisez Utilisateur racine d'un compte AWS AWS IAM Identity Center, activez et créez un utilisateur administratif afin de ne pas utiliser l'utilisateur root pour les tâches quotidiennes.
**Sécurisez votre Utilisateur racine d'un compte AWS**
1. Connectez-vous en [AWS Management Console](https://console.aws.amazon.com/)tant que propriétaire du compte en choisissant **Utilisateur root** et en saisissant votre adresse Compte AWS e-mail. Sur la page suivante, saisissez votre mot de passe.
Pour obtenir de l’aide pour vous connecter en utilisant l’utilisateur racine, consultez [Connexion en tant qu’utilisateur racine](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) dans le *Guide de l’utilisateur Connexion à AWS *.
1. Activez l’authentification multifactorielle (MFA) pour votre utilisateur racine.
Pour obtenir des instructions, voir [Activer un périphérique MFA virtuel pour votre utilisateur Compte AWS root (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) dans le guide de l'utilisateur *IAM*.
**Création d’un utilisateur doté d’un accès administratif**
1. Activez IAM Identity Center.
Pour obtenir des instructions, consultez [Activation d’ AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
1. Dans IAM Identity Center, octroyez un accès administratif à un utilisateur.
Pour un didacticiel sur l'utilisation du Répertoire IAM Identity Center comme source d'identité, voir [Configurer l'accès utilisateur par défaut Répertoire IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) dans le *Guide de AWS IAM Identity Center l'utilisateur*.
**Connexion en tant qu’utilisateur doté d’un accès administratif**
+ Pour vous connecter avec votre utilisateur IAM Identity Center, utilisez l’URL de connexion qui a été envoyée à votre adresse e-mail lorsque vous avez créé l’utilisateur IAM Identity Center.
Pour obtenir de l'aide pour vous connecter en utilisant un utilisateur d'IAM Identity Center, consultez la section [Connexion au portail AWS d'accès](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) dans le *guide de l'Connexion à AWS utilisateur*.
**Attribution d’un accès à d’autres utilisateurs**
1. Dans IAM Identity Center, créez un ensemble d’autorisations qui respecte la bonne pratique consistant à appliquer les autorisations de moindre privilège.
Pour obtenir des instructions, consultez [Création d’un ensemble d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
1. Attribuez des utilisateurs à un groupe, puis attribuez un accès par authentification unique au groupe.
Pour obtenir des instructions, consultez [Ajout de groupes](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
Pour activer l’accès, ajoutez des autorisations à vos utilisateurs, groupes ou rôles :
+ Utilisateurs et groupes dans AWS IAM Identity Center :
Créez un jeu d’autorisations. Suivez les instructions de la rubrique [Création d’un jeu d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) du *Guide de l’utilisateur AWS IAM Identity Center *.
+ Utilisateurs gérés dans IAM par un fournisseur d’identité :
Créez un rôle pour la fédération d’identité. Suivez les instructions de la rubrique [Création d’un rôle pour un fournisseur d’identité tiers (fédération)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) dans le *Guide de l’utilisateur IAM*.
+ Utilisateurs IAM :
+ Créez un rôle que votre utilisateur peut assumer. Suivez les instructions de la rubrique [Création d’un rôle pour un utilisateur IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*.
+ (Non recommandé) Attachez une politique directement à un utilisateur ou ajoutez un utilisateur à un groupe d’utilisateurs. Suivez les instructions de la rubrique [Ajout d’autorisations à un utilisateur (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) du *Guide de l’utilisateur IAM*.
## Fournir des AWS informations d'identification à IDT
Pour autoriser IDT à accéder à vos AWS informations d'identification et à envoyer des statistiques AWS, procédez comme suit :
1. Stockez les AWS informations d'identification de votre utilisateur IAM sous forme de variables d'environnement ou dans un fichier d'informations d'identification :
1. Pour utiliser des variables d'environnement, exécutez la commande suivante :
```
AWS_ACCESS_KEY_ID=access-key
AWS_SECRET_ACCESS_KEY=secret-access-key
```
1. Pour utiliser le fichier d'informations d'identification, ajoutez les informations suivantes au `.aws/credentials file:`
```
[profile-name]
aws_access_key_id=access-key
aws_secret_access_key=secret-access-key
```
1. Configurez la `auth` section du `config.json` fichier. Pour de plus amples informations, veuillez consulter [(Facultatif) Configurer config.json](set-config-custom.md#config-json-custom).
# Maintenir les versions des suites de tests
IDT pour FreeRTOS organise les ressources de test en suites de tests et en groupes de tests :
+ Une suite de tests est un ensemble de groupes de tests utilisés pour vérifier qu'un appareil fonctionne avec des versions spécifiques de FreeRTOS.
+ Un groupe de tests est l'ensemble des tests individuels liés à une fonctionnalité particulière, telle que la messagerie BLE et MQTT.
Depuis IDT v3.0.0, les suites de tests sont versionnées à l'aide d'un format `major`.`minor`.`patch` commençant par 1.0.0. Lorsque vous téléchargez IDT, le package inclut la version de suite de tests la plus récente.
Lorsque vous démarrez IDT dans l'interface de ligne de commande, IDT vérifie si une version de suite de tests plus récente est disponible. Si tel est le cas, vous êtes invité à effectuer une mise à jour vers la nouvelle version. Vous pouvez choisir de mettre à jour ou de poursuivre avec vos tests actuels.
**Note**
IDT prend en charge les trois versions de suite de tests les plus récentes pour la qualification. Pour de plus amples informations, veuillez consulter [Comprendre la politique de support pour AWS IoT Device Tester](idt-support-policy.md).
Vous pouvez télécharger des suites de tests en utilisant la commande `upgrade-test-suite`. Vous pouvez également utiliser le paramètre optionnel `-upgrade-test-suite flag` lorsque vous démarrez IDT, qui *flag* peut être « `y` » pour toujours télécharger la dernière version, ou « `n` » pour utiliser la version existante.
Vous pouvez également exécuter la `list-supported-versions` commande pour répertorier les versions de FreeRTOS et de suites de tests prises en charge par la version actuelle d'IDT.
De nouveaux tests peuvent introduire de nouveaux paramètres de configuration IDT. Si les paramètres sont facultatifs, IDT vous en avertit et continue à exécuter les tests. Si les paramètres sont requis, IDT vous en avertit et arrête l'exécution. Après avoir configuré les paramètres, vous pouvez continuer à exécuter les tests.
# Résolution des erreurs
Chaque exécution de suite de tests a un ID d'exécution unique qui est utilisé pour créer un dossier nommé `results/execution-id` dans le répertoire `results`. Les journaux de groupes de tests individuels se trouvent dans le répertoire `results/execution-id/logs`. Utilisez la sortie de la console IDT pour FreeRTOS pour trouver l'identifiant d'exécution, l'identifiant du cas de test et l'identifiant du groupe de tests du scénario qui a échoué, puis ouvrez le fichier journal du scénario de test nommé. `results/execution-id/logs/test_group_id__test_case_id.log` Les informations dans ce fichier incluent, entre autres :
+ Sortie complète des commandes de création et flash.
+ Sortie de l'exécution des tests.
+ IDT plus détaillé pour les sorties de console FreeRTOS.
Nous vous recommandons le flux de dépannage suivant :
1. Si le message d'erreur « n'*user/role*est pas autorisé à accéder à cette ressource » s'affiche, assurez-vous de configurer les autorisations comme indiqué dans[Création et configuration d'un AWS compte](dev-tester-prereqs.md#config-aws-account).
1. Lisez la sortie de la console pour trouver des informations, telles que l'UUID d'exécution et les tâches en cours d'exécution.
1. Recherchez dans le fichier `FRQ_Report.xml` les déclarations d'erreurs de chaque test. Ce répertoire contient des fichiers journaux d'exécution de chaque groupe de tests.
1. Consultez les fichiers journaux ci-dessous`/results/execution-id/logs`.
1. Vérifiez que les éléments suivants ne présentant pas de problème :
+ La configuration des appareils, comme les fichiers de configuration JSON dans le dossier `/configs/`.
+ Interface de l'appareil Vérifiez dans les journaux afin de déterminer quelle interface échoue.
+ Outils de l'appareil. Assurez-vous que les chaînes d'outils de génération et de flashage de l'appareil sont installées et configurées correctement.
+ Pour FRQ 1.x.x, assurez-vous qu'une version propre et clonée du code source de FreeRTOS est disponible. Les versions de FreeRTOS sont étiquetées en fonction de la version de FreeRTOS. Pour cloner une version spécifique du code, utilisez les commandes suivantes :
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
## Résoudre les problèmes de configuration de l'appareil
Lorsque vous utilisez IDT pour FreeRTOS, vous devez mettre en place les bons fichiers de configuration avant d'exécuter le binaire. Si vous obtenez des erreurs d'analyse et de configuration, votre première étape devrait être de localiser et d'utiliser un modèle de configuration approprié pour votre environnement. Ces modèles sont situés dans le répertoire `IDT_ROOT/configs`.
Si le problème persiste, consultez les processus de débogage suivants.
### Quels fichiers examiner ?
Commencez par lire la sortie de la console pour trouver des informations, telles que l'UUID d'exécution, qui est référencé en tant que `execution-id` dans cette documentation.
Ensuite, examinez le fichier `FRQ_Report.xml` dans le répertoire `/results/execution-id`. Ce fichier contient tous les scénarios de tests qui ont été exécutés et des extraits d'erreur pour chaque échec. Pour obtenir tous les journaux d'exécution, recherchez le fichier `/results/execution-id/logs/test_group_id__test_case_id.log` pour chaque cas de test.
### Codes d'erreur IDT
Le tableau suivant explique les codes d'erreur générés par IDT pour FreeRTOS :
| Code d’erreur | Nom du code d'erreur | Cause première possible | Résolution des problèmes |
| --- | --- | --- | --- |
| 201 | InvalidInputError | Les champs dans `device.json`, `config.json` ou `userdata.json` sont manquants ou dans un format incorrect. | Assurez-vous que les champs obligatoires ne sont pas manquants et qu'ils sont au format requis dans les fichiers répertoriés. Pour de plus amples informations, veuillez consulter [Premier test de votre carte microcontrôleur](qual-steps.md). |
| 202 | ValidationError | Les champs de `device.json`, `config.json` ou `userdata.json` contiennent des valeurs non valides. | Vérifiez le message d'erreur situé à droite du code d'erreur dans le rapport : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 203 | CopySourceCodeError | Impossible de copier le code source de FreeRTOS dans le répertoire spécifié. | Vérifiez les éléments suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 204 | BuildSourceError | Impossible de compiler le code source de FreeRTOS. | Vérifiez les éléments suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 205 | FlashOrRunTestError | IDT FreeRTOS n'est pas en mesure de flasher ou d'exécuter FreeRTOS sur votre DUT. | Vérifiez que les informations sous `flashTool` dans votre fichier `userdata.json` sont correctes. Pour de plus amples informations, veuillez consulter [Configurer les paramètres de création, de flash et de test](cfg-dt-ud.md). |
| 206 | StartEchoServerError | IDT FreeRTOS n'est pas en mesure de démarrer le serveur Echo pour les tests ou les WiFi tests de sockets sécurisés. | Vérifiez que les ports configurés sous `echoServerConfiguration` dans votre fichier `userdata.json` ne sont pas utilisés ou bloqués par le pare-feu ou les paramètres réseau. |
### Erreurs d'analyse du fichier de configuration de débogage
Parfois, une faute de frappe dans une configuration JSON peut entraîner des erreurs d'analyse. La plupart du temps, le problème est le résultat d'une virgule, d'une apostrophe ou d'un crochet manquant dans le fichier JSON. IDT pour FreeRTOS effectue la validation JSON et imprime les informations de débogage. Il imprime la ligne dans laquelle l'erreur s'est produite, le numéro de ligne et le numéro de colonne de l'erreur de syntaxe. Ces informations devraient être suffisantes pour vous aider à corriger l'erreur, mais si vous ne parvenez toujours pas à la localiser, vous pouvez effectuer la validation manuellement dans votre IDE, un éditeur de texte tel qu'Atom ou Sublime, ou via un outil en ligne tel que JSONLint.
### Les résultats des tests de débogage et les erreurs d'analyse
Lors de l'exécution d'un groupe de test à partir de [ FreeRTOS-Libraries-Integration-TestsFullTransportInterface](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests)**TLS, Full PKCS11 \$1Core, Full PKCS11 \$1OnBoard\$1ECC, Full \$1OnBoard\$1RSA, Full \$1 PKCS11 \$1ECC, Full \$1 PKCS11 \$1RSA ou **OTACore**IDT pour PKCS11 FreeRTOS PreProvisioned analyse les résultats du test depuis le périphérique PreProvisioned** de test avec la connexion série. Parfois, des sorties série supplémentaires sur le périphérique peuvent interférer avec l'analyse des résultats des tests.
Dans le cas mentionné ci-dessus, d'étranges raisons d'échec du scénario de test, telles que des chaînes provenant de sorties de périphériques indépendantes, sont produites. Le fichier journal du cas de test IDT pour FreeRTOS (qui inclut toutes les sorties série reçues par IDT pour FreeRTOS pendant le test) peut afficher les informations suivantes :
```
TEST(Full_PKCS11_Capabilities, PKCS11_Capabilities)
PASS
```
**Dans l'exemple ci-dessus, la sortie du périphérique indépendante empêche IDT pour FreeRTOS de détecter le résultat du test qui est PASS.**
Vérifiez les points suivants pour garantir des tests optimaux.
+ Assurez-vous que les macros de journalisation utilisées sur l'appareil sont compatibles avec les threads. Voir [Implémentation des macros de journalisation de la bibliothèque](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html) pour plus d'informations.
+ Assurez-vous que les sorties de la connexion série sont minimales pendant les tests. Les sorties d'autres appareils peuvent poser problème même si vos macros de journalisation sont correctement sécurisées par thread, car les résultats des tests seront générés lors d'appels séparés pendant les tests.
Un journal des cas de test IDT pour FreeRTOS devrait idéalement afficher une sortie ininterrompue des résultats de test, comme ci-dessous :
```
---------STARTING TESTS---------
TEST(Full_OTA_PAL, otaPal_CloseFile_ValidSignature) PASS
TEST(Full_OTA_PAL, otaPal_CloseFile_InvalidSignatureBlockWritten) PASS
-----------------------
2 Tests 0 Failures 0 Ignored
```
### Défaillances du contrôle d'intégrité du débogage
Si vous utilisez la version FRQ 1.x.x de FreeRTOS, les contrôles d'intégrité suivants s'appliquent.
Lorsque vous exécutez le groupe de RTOSIntegrity test Free et que vous rencontrez des échecs, assurez-vous d'abord de n'avoir modifié aucun des fichiers du `freertos` répertoire. Si ce n'est pas le cas et que vous rencontrez toujours des problèmes, assurez-vous d'utiliser la bonne branche. Si vous exécutez la `list-supported-products` commande IDT, vous pouvez trouver la branche balisée du `freertos` dépôt que vous devez utiliser.
Si vous avez cloné la bonne branche balisée du `freertos` dépôt et que vous rencontrez toujours des problèmes, assurez-vous d'avoir également exécuté la `submodule update` commande. Le flux de travail de clonage pour le `freertos` dépôt est le suivant.
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout —init —recursive
```
La liste des fichiers recherchés par le vérificateur d'intégrité se trouve dans le `checksums.json` fichier de votre `freertos` répertoire. Pour qualifier un port FreeRTOS sans aucune modification des fichiers et de la structure des dossiers, assurez-vous qu'aucun des fichiers répertoriés dans les sections « » et `exhaustive` `minimal` « » `checksums.json` du fichier n'a été modifié. Pour exécuter avec un SDK configuré, vérifiez qu'aucun des fichiers de la section « `minimal` » n'a été modifié.
Si vous exécutez IDT avec un SDK et que vous avez modifié certains fichiers de votre `freertos` répertoire, assurez-vous de configurer correctement votre SDK dans votre fichier. `userdata` Dans le cas contraire, le vérificateur d'intégrité vérifiera tous les fichiers du `freertos` répertoire.
### Défaillances du groupe de FullWiFi test de débogage
Si vous utilisez FRQ 1.x.x et que vous rencontrez des échecs dans le groupe de FullWiFi test et que le test « `AFQP_WiFiConnectMultipleAP` » échoue, cela peut être dû au fait que les deux points d'accès ne se trouvent pas dans le même sous-réseau que l'ordinateur hôte exécutant IDT. Assurez-vous que les deux points d'accès se trouvent dans le même sous-réseau que l'ordinateur hôte exécutant IDT.
### Déboguer les erreurs « paramètre requis manquant »
Étant donné que de nouvelles fonctionnalités sont ajoutées à IDT pour FreeRTOS, des modifications peuvent être apportées aux fichiers de configuration. L'utilisation d'un ancien fichier de configuration peut corrompre votre configuration. Si tel est le cas, le fichier `test_group_id__test_case_id.log` sous le répertoire `results/execution-id/logs` répertorie explicitement tous les paramètres manquants. IDT pour FreeRTOS valide vos schémas de fichiers de configuration JSON pour s'assurer que la dernière version prise en charge a été utilisée.
### Déboguer les erreurs « le test n'a pas pu démarrer »
Vous pouvez voir des erreurs qui pointent sur des défaillances lors du démarrage du test. Comme il existe plusieurs causes possibles, vérifiez bien les points suivants :
+ Assurez-vous que le nom du groupe que vous avez inclus dans votre commande d'exécution existe réellement. Celui-ci est référencé directement à partir du fichier `device.json`.
+ Assurez-vous que le ou les appareils du groupe ont des paramètres de configuration corrects.
### Déboguer les erreurs « Impossible de trouver le début des résultats du test »
Des erreurs peuvent s'afficher lorsque IDT tente d'analyser les résultats produits par le périphérique testé. Il existe plusieurs causes possibles, alors vérifiez l'exactitude des points suivants :
+ Assurez-vous que le périphérique testé dispose d'une connexion stable avec votre machine hôte. Vous pouvez consulter le fichier journal pour un test qui indique ces erreurs afin de voir ce que reçoit IDT.
+ Si vous utilisez FRQ 1.x.x et que le périphérique testé est connecté via un réseau lent ou une autre interface, ou si vous ne voyez pas l'indicateur « ---------STARTING TESTS--------- » dans le journal d'un groupe de test FreeRTOS avec les autres sorties du groupe de test FreeRTOS, vous pouvez essayer d'augmenter la valeur de dans votre configuration de données utilisateur. `testStartDelayms` Pour de plus amples informations, veuillez consulter [Configurer les paramètres de création, de flash et de test](cfg-dt-ud.md).
### Déboguer une erreur « Échec du test : \$1\$1 résultats attendus mais \$1\$1\$1 »
Il est possible que vous rencontriez des erreurs indiquant un échec pendant le test. Le test attend un certain nombre de résultats et ne le voit pas pendant le test. Certains tests FreeRTOS sont exécutés avant qu'IDT ne voie le résultat de l'appareil. Si cette erreur s'affiche, vous pouvez essayer d'augmenter la valeur de `testStartDelayms` dans votre configuration de *données utilisateur*. Pour de plus amples informations, veuillez consulter [Configurer les paramètres de création, de flash et de test](lts-cfg-dt-ud.md).
### Déboguer une erreur « \$1\$1\$1\$1\$1\$1\$1\$1 n'a pas été sélectionné en raison de contraintes » ConditionalTests
Cela signifie que vous effectuez un test sur un pool de périphériques incompatible avec le test. Cela peut se produire avec les tests OTA E2E. Par exemple, lors de l'exécution du groupe de `OTADataplaneMQTT` test et dans votre fichier de `device.json` configuration, vous avez choisi OTA comme **Non** ou `OTADataPlaneProtocol` comme **HTTP**. Le groupe de test choisi pour exécuter doit correspondre à vos sélections `device.json` de capacités.
### Déboguer un délai IDT lors de la surveillance de la sortie de l'appareil
L'IDT peut expirer pour un certain nombre de raisons. Si un délai d'attente survient pendant la phase de surveillance des sorties de l'appareil d'un test et que vous pouvez voir les résultats dans le journal des cas de test IDT, cela signifie que les résultats ont été mal analysés par IDT. L'une des raisons pourrait être l'entrelacement des messages du journal au milieu des résultats des tests. Si tel est le cas, veuillez consulter le guide de [portage de FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-ota.html) pour plus de détails sur la manière dont les journaux UNITY doivent être configurés.
Un délai d'attente pendant la surveillance des sorties de l'appareil peut également être dû au redémarrage du périphérique après un seul échec du test TLS. L'appareil exécute ensuite l'image flashée et provoque une boucle infinie qui apparaît dans les journaux. Dans ce cas, assurez-vous que votre appareil ne redémarre pas après un échec du test.
### Déboguer une erreur « accès non autorisé à la ressource »
Le message d'erreur « n'*user/role*est pas autorisé à accéder à cette ressource » peut s'afficher dans la sortie du terminal ou dans le `test_manager.log` fichier ci-dessous`/results/execution-id/logs`. Pour résoudre ce problème, attachez la stratégie gérée `AWS IoTDeviceTesterForFreeRTOSFullAccess` à votre utilisateur de test. Pour de plus amples informations, veuillez consulter [Création et configuration d'un AWS compte](dev-tester-prereqs.md#config-aws-account).
### Déboguer les erreurs de test du réseau
Pour les tests basés sur réseau, IDT lance un serveur echo qui se lie à un port non réservé sur la machine hôte. Si vous rencontrez des erreurs dues à des délais d'attente ou à des connexions indisponibles lors des WiFi tests de sockets sécurisés, assurez-vous que votre réseau est configuré pour autoriser le trafic vers les ports configurés compris entre 1024 et 49151.
Le test des sockets sécurisées utilise les ports 33333 et 33334 par défaut. Les WiFi tests utilisent le port 33335 par défaut. Si ces trois ports sont utilisés ou bloqués par un pare-feu ou un réseau, vous pouvez choisir d'utiliser d'autres ports dans userdata.json pour les tests. Pour de plus amples informations, veuillez consulter [Configurer les paramètres de création, de flash et de test](cfg-dt-ud.md). Vous pouvez utiliser les commandes suivantes pour vérifier si un port spécifique est en cours d'utilisation :
+ Windows: `netsh advfirewall firewall show rule name=all | grep port`
+ Linux : `sudo netstat -pan | grep port`
+ macOS : `netstat -nat | grep port`
### Défaillances de mise à jour OTA dues à une charge utile de version identique
Si les scénarios de test OTA échouent parce que la même version se trouve sur l'appareil après l'exécution d'un OTA, cela peut être dû au fait que votre système de compilation (par exemple cmake) n'a pas remarqué les modifications apportées par IDT au code source de FreeRTOS et n'a pas créé de binaire mis à jour. L'opération OTA est alors effectuée avec le même binaire que celui qui est actuellement sur le périphérique, ce qui entraîne l'échec du test. Pour résoudre les défaillances de mise à jour OTA, commencez par vous assurer que vous utilisez la dernière version prise en charge de votre système de build.
### Échec du test OTA sur le cas de test `PresignedUrlExpired`
Pour que ce test aboutisse, le temps de mise à jour OTA doit être supérieur à 60 secondes. Dans le cas contraire, le message d'erreur suivant se trouve dans le journal : « Test takes less than 60 seconds (url expired time) to finish. Please reach out to us. » (Le test dure moins de 60 secondes (délai d'expiration de l'URL). Veuillez nous contacter).
### Erreurs de port et d'interface du périphérique de débogage
Cette section contient des informations sur les interfaces utilisées par IDT pour se connecter à vos appareils.
#### Plateformes prises en charge
IDT prend en charge Windows, macOS et Linux. Ces trois plateformes ont différents schémas de dénomination pour les appareils :
+ Linux : `/dev/tty*`
+ macOS : `/dev/tty.*` ou `/dev/cu.*`
+ Windows : COM\$1
Pour vérifier le port de votre appareil :
+ Pour Linux/macOS, ouvrez un terminal et exécutez `ls /dev/tty*`.
+ Pour macOS, ouvrez un terminal et exécutez `ls /dev/tty.*` ou `ls /dev/cu.*`.
+ Pour Windows, ouvrez le gestionnaire d'appareils et développez le groupe d'appareils en série.
Pour vérifier que l'appareil est connecté à un port :
+ Pour Linux, assurez-vous que le package `udev` est installé, puis exécutez `udevadm info –name=PORT`. Cet utilitaire imprime les informations de pilote de l'appareil qui vous permettent de vérifier que vous utilisez le bon port.
+ Pour macOS, ouvrez Launchpad et recherchez **System Information**.
+ Pour Windows, ouvrez le gestionnaire d'appareils et développez le groupe d'appareils en série.
#### Interfaces du périphérique
Chaque appareil intégré est différent, ce qui signifie qu'ils peuvent avoir un ou plusieurs ports série. Il est courant pour les appareils d'avoir deux connexions lorsqu'ils sont connectés à une machine :
+ Un port de données pour flasher l'appareil.
+ Un port de lecture pour lire la sortie.
Vous devez définir le bon port de lecture dans votre fichier `device.json`. Dans le cas contraire, la lecture de la sortie à partir de l'appareil peut échouer.
Lorsqu'il existe plusieurs ports, assurez-vous d'utiliser le port de lecture de l'appareil dans votre fichier `device.json`. Par exemple, si vous branchez un WRover appareil Espressif et que les deux ports qui lui sont `/dev/ttyUSB0` assignés `/dev/ttyUSB1` sont utilisés `/dev/ttyUSB1` dans votre `device.json` fichier.
Pour Windows, suivez la même logique.
#### Lecture des données du périphérique
IDT pour FreeRTOS utilise la création de périphériques individuels et des outils flash pour spécifier la configuration des ports. Si vous testez votre appareil et que vous n'obtenez pas de sortie, essayez les paramètres par défaut suivants :
+ Vitesse de transmission : 115200
+ Bits de données : 8
+ Parité : aucune
+ Bits d'arrêt : 1
+ Contrôle de flux : aucun
Ces paramètres sont gérés par IDT pour FreeRTOS. Vous n'avez pas à les définir. Cependant, vous pouvez utiliser la même méthode pour lire manuellement la sortie de l'appareil. Sur Linux ou macOS, vous pouvez le faire avec la commande `screen`. Sous Windows, vous pouvez utiliser un programme tel que TeraTerm.
`Screen: screen /dev/cu.usbserial 115200`
`TeraTerm: Use the above-provided settings to set the fields explicitly in the GUI.`
### Problèmes liés à la chaîne d'outils de développement
Cette section explique les problèmes qui peuvent survenir avec votre chaîne d'outils.
#### Code Composer Studio sur Ubuntu
Les dernières versions d'Ubuntu (17.10 et 18.04) incluent une version du package `glibc` qui n'est pas compatible avec Code Composer Studio 7.*x*. Nous vous recommandons d'installer Code Composer Studio 8.2 ou version ultérieure.
Voici les symptômes d'incompatibilité possibles :
+ FreeRTOS ne parvient pas à se créer ou à flasher sur votre appareil.
+ Le programme d'installation de Code Composer Studio peut rester bloqué.
+ Aucune sortie de journal ne s'affiche dans la console lors du processus de génération ou flash.
+ La commande de génération tente de se lancer en mode graphique même lorsqu'elle est appelée en mode sans tête.
### Logging
Les journaux IDT pour FreeRTOS sont placés en un seul endroit. À partir du répertoire IDT racine, ces fichiers sont disponibles sous `results/execution-id/` :
+ `FRQ_Report.xml`
+ `awsiotdevicetester_report.xml`
+ `logs/test_group_id__test_case_id.log`
`FRQ_Report.xml` et `logs/test_group_id__test_case_id.log` sont les journaux les plus importants à examiner. `FRQ_Report.xml` contient des informations sur les cas de test qui ont échoué avec un message d'erreur spécifique. Vous pouvez ensuite utiliser `logs/test_group_id__test_case_id.log` pour approfondir le problème afin d'obtenir plus de contexte.
#### Erreurs de la console
Lorsqu'il AWS IoT Device Tester est exécuté, les défaillances sont signalées à la console par de brefs messages. Recherchez dans `results/execution-id/logs/test_group_id__test_case_id.log` pour en savoir plus sur l'erreur.
#### Erreurs de journal
Chaque exécution de suite de tests a un ID d'exécution unique qui est utilisé pour créer un dossier nommé `results/execution-id`. Les journaux des cas de test individuels figurent dans le répertoire `results/execution-id/logs`. Utilisez la sortie de la console IDT pour FreeRTOS pour trouver l'identifiant d'exécution, l'identifiant du cas de test et l'identifiant du groupe de test du scénario de test qui a échoué. Utilisez ensuite ces informations pour rechercher et ouvrir le fichier journal correspondant à ce scénario de test nommé `results/execution-id/logs/test_group_id__test_case_id.log` Les informations contenues dans ce fichier incluent la sortie complète de la commande flash et de la compilation, la sortie de l'exécution du test et la sortie de AWS IoT Device Tester console plus détaillée.
#### Problèmes liés au compartiment S3
Si vous appuyez CTRL\$1C pendant l'exécution d'IDT, IDT lancera un processus de nettoyage. Une partie de ce nettoyage consiste à supprimer les ressources Amazon S3 créées dans le cadre des tests IDT. Si le nettoyage ne peut pas être terminé, il se peut que vous rencontriez un problème lié à la création d'un trop grand nombre de compartiments Amazon S3. Cela signifie que la prochaine fois que vous exécuterez IDT, les tests commenceront à échouer.
Si vous appuyez CTRL\$1C pour arrêter IDT, vous devez le laisser terminer le processus de nettoyage pour éviter ce problème. Vous pouvez également supprimer de votre compte les compartiments Amazon S3 créés manuellement.
## Résoudre les erreurs liées au délai d'expiration
Si vous constatez des erreurs de délai d'expiration lors de l'exécution d'une suite de tests, augmentez le délai d'expiration en spécifiant un facteur multiplicateur de délai d'expiration. Ce facteur est appliqué à la valeur de délai d'expiration par défaut. Toute valeur configurée pour cet indicateur doit être supérieure ou égale à 1.0. Pour utiliser le multiplicateur de délai d'expiration, employez l'indicateur `--timeout-multiplier` lors de l'exécution de la suite de tests.
**Example**
```
./devicetester_linux run-suite --suite-id FRQ_1.0.1 --pool-id DevicePool1 --timeout-multiplier 2.5
```
```
./devicetester_linux run-suite --suite-id FRQ_1 --pool-id DevicePool1 --timeout-multiplier 2.5
```
## Fonction cellulaire et AWS frais
Lorsque la `Cellular` fonctionnalité est configurée `Yes` dans votre `device.JSON` fichier, vous FullSecureSockets utiliserez les instances T.micro EC2 pour exécuter les tests, ce qui peut entraîner des frais supplémentaires pour votre compte. AWS Pour plus d’informations, consultez [Tarification Amazon EC2](https://aws.amazon.com/ec2/pricing/).
## Politique de génération de rapports de qualification
Les rapports de qualification ne sont générés que par les versions AWS IoT Device Tester (IDT) compatibles avec les versions de FreeRTOS publiées au cours des deux dernières années. Si vous avez des questions concernant la politique d'assistance, veuillez contacter [AWS Support](https://aws.amazon.com/contact-us/).
# Comprendre la politique AWS gérée pour AWS IoT Device Tester
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle politique Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.
Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.
**Topics**
+ [AWS politique gérée : AWS Io TDevice TesterForFree RTOSFull Access](#aws-managed-policies-AWSIoTDT)
+ [Mises à jour des politiques AWS gérées](#aws-managed-policy-updates)
## AWS politique gérée : AWS Io TDevice TesterForFree RTOSFull Access
La politique `AWSIoTDeviceTesterForFreeRTOSFullAccess` gérée contient les AWS IoT Device Tester autorisations suivantes pour la vérification des versions, les fonctionnalités de mise à jour automatique et la collecte de métriques.
**Détails de l'autorisation**
Cette politique inclut les autorisations suivantes :
+ `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 de la suite de tests.
+ `iot-device-tester:SendMetrics`
Accorde AWS l'autorisation de collecter des statistiques relatives à l'utilisation AWS IoT Device Tester interne.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/idt-*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "iot.amazonaws.com"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"iot:DeleteThing",
"iot:AttachThingPrincipal",
"iot:DeleteCertificate",
"iot:GetRegistrationCode",
"iot:CreatePolicy",
"iot:UpdateCACertificate",
"s3:ListBucket",
"iot:DescribeEndpoint",
"iot:CreateOTAUpdate",
"iot:CreateStream",
"signer:ListSigningJobs",
"acm:ListCertificates",
"iot:CreateKeysAndCertificate",
"iot:UpdateCertificate",
"iot:CreateCertificateFromCsr",
"iot:DetachThingPrincipal",
"iot:RegisterCACertificate",
"iot:CreateThing",
"iam:ListRoles",
"iot:RegisterCertificate",
"iot:DeleteCACertificate",
"signer:PutSigningProfile",
"s3:ListAllMyBuckets",
"signer:ListSigningPlatforms",
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource": "*"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"signer:StartSigningJob",
"acm:GetCertificate",
"signer:DescribeSigningJob",
"s3:CreateBucket",
"execute-api:Invoke",
"s3:DeleteBucket",
"s3:PutBucketVersioning",
"signer:CancelSigningProfile"
],
"Resource": [
"arn:aws:execute-api:us-east-1:098862408343:9xpmnvs5h4/prod/POST/metrics",
"arn:aws:signer:*:*:/signing-profiles/*",
"arn:aws:signer:*:*:/signing-jobs/*",
"arn:aws:iam::*:role/idt-*",
"arn:aws:acm:*:*:certificate/*",
"arn:aws:s3:::idt-*",
"arn:aws:s3:::afr-ota*"
]
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"iot:DeleteStream",
"iot:DeleteCertificate",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"s3:ListBucketVersions",
"iot:UpdateCertificate",
"iot:GetOTAUpdate",
"iot:DeleteOTAUpdate",
"iot:DescribeJobExecution"
],
"Resource": [
"arn:aws:s3:::afr-ota*",
"arn:aws:iot:*:*:thinggroup/idt*",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid": "VisualEditor4",
"Effect": "Allow",
"Action": [
"iot:DeleteCertificate",
"iot:AttachPolicy",
"iot:DetachPolicy",
"s3:DeleteObjectVersion",
"iot:DeleteOTAUpdate",
"s3:PutObject",
"s3:GetObject",
"iot:DeleteStream",
"iot:DeletePolicy",
"s3:DeleteObject",
"iot:UpdateCertificate",
"iot:GetOTAUpdate",
"s3:GetObjectVersion",
"iot:DescribeJobExecution"
],
"Resource": [
"arn:aws:s3:::afr-ota*/*",
"arn:aws:s3:::idt-*/*",
"arn:aws:iot:*:*:policy/idt*",
"arn:aws:iam::*:role/idt-*",
"arn:aws:iot:*:*:otaupdate/idt*",
"arn:aws:iot:*:*:thing/idt*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:job/*",
"arn:aws:iot:*:*:stream/*"
]
},
{
"Sid": "VisualEditor5",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::afr-ota*/*",
"arn:aws:s3:::idt-*/*"
]
},
{
"Sid": "VisualEditor6",
"Effect": "Allow",
"Action": [
"iot:CancelJobExecution"
],
"Resource": [
"arn:aws:iot:*:*:job/*",
"arn:aws:iot:*:*:thing/idt*"
]
},
{
"Sid": "VisualEditor7",
"Effect": "Allow",
"Action": [
"ec2:TerminateInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor8",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DeleteSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor9",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor10",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:image/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:placement-group/*",
"arn:aws:ec2:*:*:snapshot/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:subnet/*"
]
},
{
"Sid": "VisualEditor11",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor12",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroups",
"ssm:DescribeParameters",
"ssm:GetParameters"
],
"Resource": "*"
},
{
"Sid": "VisualEditor13",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"Owner"
]
},
"StringEquals": {
"ec2:CreateAction": [
"RunInstances",
"CreateSecurityGroup"
]
}
}
}
]
}
```
------
## Mises à jour des politiques AWS gérées
Vous pouvez consulter les informations relatives aux mises à jour des politiques AWS gérées à AWS IoT Device Tester partir du moment où ce service a commencé à suivre ces modifications.
| Version | Modifier | Description | Date |
| --- | --- | --- | --- |
| 7 (Dernier) | Restructuration des `ec2:CreateTags` conditions. | Suppression de l'utilisation de`ForAnyValues`. | 14/06/2023 |
| 6 | `freertos:ListHardwarePlatforms`Supprimé de la politique. | Suppression des autorisations car cette action est obsolète depuis le 1er mars 2023. | 02/06/2023 |
| 5 | Des autorisations ont été ajoutées pour exécuter des tests sur le serveur Echo à l'aide d'EC2. | Cela permet de démarrer et d'arrêter une instance EC2 dans les AWS comptes des clients. | 15 décembre 2020 |
| 4 | Ajouté `iot:CancelJobExecution`. | Cette autorisation annule les jobs OTA. | 17/07/2020 |
| 3 | Les autorisations suivantes ont été ajoutées : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/security-iam-aws-managed-policies.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/freertos/latest/userguide/security-iam-aws-managed-policies.html) | 23/03/2020 |
| 2 | `iot-device-tester:SendMetrics`Autorisations ajoutées. | Accorde AWS l'autorisation de collecter des statistiques relatives à l'utilisation AWS IoT Device Tester interne. | 18/02/2020 |
| 1 | Première version. | | 12/02/2020 |
# Comprendre la politique de support pour AWS IoT Device Tester
**Important**
Depuis octobre 2022, AWS IoT Device Tester AWS IoT FreeRTOS Qualification (FRQ) 1.0 ne génère pas de rapports de qualification signés. Vous ne pouvez pas qualifier les nouveaux appareils AWS IoT FreeRTOS à répertorier dans le catalogue des appareils [partenaires dans AWS le cadre du programme de qualification des appareils](https://partners.amazonaws.com/qualified-devices) [utilisant AWS les versions](https://aws.amazon.com/partners/programs/dqp/) IDT FRQ 1.0. Bien que vous ne puissiez pas qualifier les appareils FreeRTOS avec IDT FRQ 1.0, vous pouvez continuer à tester vos appareils FreeRTOS avec FRQ 1.0. [Nous vous recommandons d'utiliser [IDT FRQ 2.0 pour qualifier et répertorier](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) les appareils FreeRTOS dans le catalogue d'appareils partenaires.AWS](https://partners.amazonaws.com/qualified-devices)
AWS IoT Device Tester for FreeRTOS est un outil d'automatisation des tests permettant de valider le port FreeRTOS sur les appareils. En outre, vous pouvez [qualifier](https://aws.amazon.com/partners/programs/dqp/) vos appareils FreeRTOS et les répertorier dans [AWS le](https://partners.amazonaws.com/qualified-devices) catalogue des appareils partenaires. [Le AWS IoT Device Tester for FreeRTOS prend en charge la validation et la qualification des bibliothèques FreeRTOS supportées à long terme (LTS) disponibles sur FreeRTOS/FreeRTOS-LTS, et de la gamme principale de FreeRTOS disponible sur GitHub [FreeRTOS/FreeRTOS](https://github.com/FreeRTOS/FreeRTOS-LTS).](https://github.com/FreeRTOS/FreeRTOS) Nous vous recommandons d'utiliser les versions les plus récentes de FreeRTOS et de FreeRTOS AWS IoT Device Tester pour valider et qualifier vos appareils.
Pour FreeRTOS-LTS, IDT prend en charge la validation et la qualification de la version FreeRTOS 202210 LTS. Cliquez ici pour plus d'informations sur les versions de [FreeRTOS LTS](https://www.freertos.org/lts-libraries.html) et leur calendrier de maintenance. Une fois la période de support de ces versions LTS terminée, vous pouvez toujours poursuivre la validation, mais IDT ne générera pas de rapport vous permettant de soumettre votre appareil à des fins de qualification.
Pour les principaux FreeRTOS disponibles sur FreeRTOS/FreeRTOS, nous prenons en charge la validation et la qualification de toutes les versions publiées [au](https://github.com/FreeRTOS/FreeRTOS) cours des six derniers mois, ou des deux versions précédentes de FreeRTOS si elles sont publiées à plus de six mois d'intervalle. Consultez ici les [versions actuellement prises en charge]( https://docs.aws.amazon.com//freertos/latest/userguide/dev-test-versions-afr.html). Pour les versions non prises en charge de FreeRTOS, vous pouvez toujours poursuivre la validation, mais IDT ne générera pas de rapport qui vous permettra de soumettre votre appareil à des fins de qualification.
Consultez [Versions prises en charge de AWS IoT Device Tester](dev-test-versions-afr.md) les dernières versions IDT et FreeRTOS prises en charge. Vous pouvez utiliser n'importe laquelle des versions prises en charge AWS IoT Device Tester de la version correspondante de FreeRTOS pour tester ou qualifier votre appareil. Si vous continuez à utiliser le[Versions IDT non prises en charge pour FreeRTOS](idt-unsupported-versions-afr.md), vous ne recevrez pas les dernières corrections de bogues ou mises à jour.
Pour toute question concernant la politique d'assistance, contactez [AWS le support client](https://aws.amazon.com/contact-us/).