Création d'exécutables de cas de test IDT - AWS IoT Greengrass
Utiliser le SDK du client IDTActiver les commandes CLI IDTRédiger des journaux d'événementsSignaler les résultats à IDTSpécifier le comportement de sortie

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.

Création d'exécutables de cas de test IDT

Vous pouvez créer et placer des exécutables de scénarios de test dans un dossier de suite de tests de la manière suivante :

  • Pour les suites de tests qui utilisent des arguments ou des variables d'environnement provenant destest.json fichiers pour déterminer les tests à exécuter, vous pouvez créer un seul script 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 créez un scénario de test exécutable pour chaque scénario de test de la suite de tests.

En tant que rédacteur de test, 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 que vous indiquez le chemin d'exécution du scénario de test correct dans chaquetest.json fichier et que l'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 :

  • Letest.json pour le scénario de test sélectionné détermine les processus à démarrer et les variables d'environnement à définir.

  • Lesuite.json pour la suite de tests 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 letest.json fichier, et transmet les variables d'environnement requises au processus.

Utiliser le SDK du client IDT

Les SDK du client IDT vous permettent 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 en cours de test. IDT fournit actuellement les SDK suivants :

  • SDK du client IDT pour Python

  • SDK du client IDT pour Go

  • SDK du client IDT pour Java

Ces SDK se trouvent dans le<device-tester-extract-location>/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 qui contient l'exécutable de votre 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.

Interaction avec l'appareil

Les commandes suivantes vous permettent de communiquer avec l'appareil en cours de test sans avoir à implémenter de fonctions supplémentaires d'interaction 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 shell SSH ou Docker.

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 périphérique prenant en charge les connexions shell SSH ou Docker.

ReadFromDevice

Permet aux suites de tests de lire à partir du port série des appareils prenant en charge les connexions UART.

Note

Comme IDT ne gère pas les connexions directes aux appareils qui sont établies à l'aide des informations d'accès aux appareils issues du contexte, nous vous recommandons d'utiliser ces commandes d'API d'interaction entre 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 au périphérique depuis la suite de tests.

Pour établir une connexion directe, récupérez les informations dans les champsdevice.connectivity et dans lesresource.devices.connectivity champs correspondant à votre appareil en cours de test et aux périphériques de ressources, respectivement. Pour de plus amples informations sur l'utilisation du contexte IDT, veuillez consulterUtiliser le contexte IDT.

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 plus d'informations, veuillez consulter Utiliser le contexte IDT.

SendResult

Permet aux suites de tests de communiquer les résultats des cas 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 plus d'informations, veuillez consulter Utiliser le contexte IDT.

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 CLI IDT

Larun-suite commande IDT CLI fournit plusieurs options qui permettent au testeur de personnaliser l'exécution du test. Pour permettre aux exécuteurs de tests d'utiliser ces options pour exécuter votre suite de tests personnalisée, vous devez implémenter la prise en charge de l'IDT CLI. Si vous n'implémentez pas le support, les exécuteurs de tests 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 d'implémenter la prise en charge des arguments suivants pour larun-suite commande dans l'IDT CLI :

timeout-multiplier

Spécifie une valeur supérieure à 1,0 qui sera appliquée à tous les délais d'attente lors de l'exécution des tests.

Les testeurs peuvent utiliser cet argument pour augmenter le délai d'attente des scénarios de test qu'ils souhaitent exécuter. Lorsqu'un lanceur de test spécifie cet argument dans sarun-suite commande, IDT l'utilise pour calculer la valeur de la variable d'environnement IDT_TEST_TIMEOUT et définit leconfig.timeoutMultiplier champ dans le contexte IDT. Pour étayer cet argument, procédez comme suit :

  • Au lieu d'utiliser directement la valeur de délai d'expiration dutest.json fichier, lisez la variable d'environnement IDT_TEST_TIMEOUT pour obtenir la valeur de délai d'expiration correctement calculée.

  • Récupérez laconfig.timeoutMultiplier valeur dans le contexte IDT et appliquez-la aux délais d'attente prolongés.

Pour plus d'informations sur la fermeture anticipée en raison d'événements de dépassement de délai, consultezSpécifier le comportement de sortie.

stop-on-first-failure

Spécifie qu'IDT doit arrêter d'exécuter tous les tests en cas de défaillance.

Lorsqu'un lanceur de test spécifie cet argument dans sarun-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 parallel, cela peut entraîner des résultats inattendus. Pour implémenter le support, assurez-vous que si IDT rencontre cet événement, votre logique de test demande à 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 de plus amples informations sur la résolution précoce des échecs, veuillez consulterSpécifier le comportement de sortie.

group-id et test-id

Spécifie qu'IDT doit exécuter uniquement les groupes de test ou les cas de test sélectionnés.

Les exécuteurs de tests peuvent utiliser ces arguments avec leurrun-suite commande pour spécifier le comportement d'exécution des tests suivant :

  • Exécutez tous les tests dans les groupes de tests spécifiés.

  • Exécutez une sélection de tests à partir d'un groupe de tests spécifié.

Pour étayer ces arguments, l'orchestrateur de tests de votre suite de tests doit inclure un ensemble spécifique d'ChoiceétatsRunTask et d'états dans votre orchestrateur de tests. Si vous n'utilisez pas de machine à états personnalisée, l'orchestrateur de test IDT par défaut inclut les états requis et vous n'avez aucune action supplémentaire à effectuer. Toutefois, si vous utilisez un orchestrateur de test personnalisé, utilisez-leExemple de machine d'état : Exécuter des groupes de test sélectionnés par l'utilisateur comme exemple pour ajouter les états requis dans votre orchestrateur de test.

Pour de plus amples informations sur les commandes CLI IDT, veuillez consulterDéboguer et exécuter des suites de tests personnalisées.

Rédiger des journaux d'événements

Pendant l'exécution du test, vous envoyez des données à la consolestdout etstderr vous y inscrivez des journaux d'événements et des messages d'erreur. Pour de plus amples informations sur le format des messages de la console, veuillez consulterFormat des messages de la console.

Lorsque l'IDT a fini d'exécuter la suite de tests, ces informations sont également disponibles dans letest_manager.log fichier situé dans le<devicetester-extract-location>/results/<execution-id>/logs dossier.

Vous pouvez configurer chaque scénario de test pour écrire les journaux de son exécution de test, y compris les journaux du périphérique testé, dans le<group-id>_<test-id> fichier situé dans le<device-tester-extract-location>/results/execution-id/logs dossier. Pour ce faire, récupérez le chemin d'accès au fichier journal à partir du contexte IDT à l'aide de latestData.logFilePath requête, créez un fichier à partir de ce chemin et écrivez-y le contenu de votre choix. 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 d'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<device-tester-extract-location>/logs dossier. Nous vous recommandons de spécifier des préfixes uniques pour les noms des fichiers journaux afin que vos fichiers ne soient pas remplacés.

Signaler les résultats à IDT

IDT écrit les résultats des tests dans lessuite-name_report.xml fichiersawsiotdevicetester_report.xml et. Ces fichiers de rapport se trouvent dans<device-tester-extract-location>/results/<execution-id>/. 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, voirExaminer les résultats des tests IDT et les journaux

Pour renseigner le contenu dusuite-name_report.xml fichier, vous devez utiliser laSendResult 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 génère 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 signalez pas de 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é danstestData.testArtifactsPath le 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 XML JUnit, vous pouvez écrire les résultats du test dans un fichier XML dans le dossier des artefacts afin de fournir directement les résultats à IDT au lieu de les analyser puis d'utiliser l'API pour les soumettre à 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 lesuite-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 latestsuites balise. Au lieu de cela, il calcule les propriétés des balises à partir des résultats d'autres groupes de test signalés.

  • Au moins unetestsuite étiquette doit exister danstestsuites.

Comme 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 fichier incorrect. 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 des résultats via l'API pour d'autres, nous ne recommandons pas cette approche.

Spécifier le comportement de sortie

Configurez votre exécutable de texte pour qu'il se termine toujours avec un code de sortie égal à 0, même si un scénario de test indique un échec ou un résultat d'erreur. Utilisez des codes de sortie différents de zéro uniquement pour indiquer qu'un scénario de test n'a pas été exécuté ou si l'exécutable du scénario de test n'a pas pu communiquer de résultats à IDT. Lorsque IDT reçoit un code de sortie différent de zéro, cela indique que le scénario de test a rencontré une erreur qui l'a empêché de s'exécuter.

IDT peut demander ou s'attendre à ce qu'un scénario de test cesse de s'exécuter avant qu'il ne soit terminé dans les événements suivants. Utilisez ces informations pour configurer l'exécutable de votre scénario de test afin de détecter chacun de ces événements à partir du 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 letest.json fichier. Si le testeur a utilisé l'timeout-multiplierargument pour spécifier un multiplicateur de délai d'expiration, IDT calcule la valeur du délai d'expiration à l'aide du multiplicateur.

Pour détecter cet événement, utilisez la variable d'environnement IDT_TEST_TIMEOUT. Lorsqu'un lanceur de test lance un test, IDT définit la valeur de la variable d'environnement IDT_TEST_TIMEOUT sur la valeur de délai d'expiration 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 minuteur approprié.

Interrompre

Se produit lorsque le lanceur de test interrompt l'IDT. Par exemple, en appuyant surCtrl+C.

Comme les terminaux transmettent des 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 duCancellationRequested booléen dans la réponse de l'PollForNotificationsAPI. Lorsque IDT reçoit un signal d'interruption, il définit la valeur duCancellationRequested booléen àtrue.

Arrêter dès le premier échec

Se produit lorsqu'un scénario de test exécuté en parallel au scénario de test actuel échoue et que le lanceur de test a utilisé l'stop-on-first-failureargument 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 pour vérifier la valeur duCancellationRequested booléen dans la réponse de l'PollForNotificationsAPI. Lorsque IDT rencontre une défaillance et est configuré pour s'arrêter dès la première défaillance, il définit la valeurCancellationRequested booléenne surtrue.

Lorsque l'un de ces événements se produit, IDT attend 5 minutes pour que tous les cas de test en cours se terminent. Si tous les scénarios de test en cours ne se terminent pas dans les 5 minutes, IDT force chacun de ses processus à s'arrêter. Si IDT n'a pas reçu de résultats de test avant la fin des processus, il marquera les cas de test comme ayant expiré. À titre de bonne pratique, vous devez vous assurer que vos scénarios de test exécutent les actions suivantes lorsqu'ils rencontrent l'un des événements suivants :

  1. Arrêtez d'exécuter la logique de test normale.

  2. Nettoyez toutes les ressources temporaires, telles que les artefacts de test sur l'appareil en cours de test.

  3. Signalez un résultat de test à IDT, tel qu'un échec de test ou une erreur.

  4. Sortir.