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.
# 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).