Créer des exécutables de cas de test IDT - AWS IoT Greengrass
Utiliser le SDK Client IDTActiver les commandes IDT CLIrédigent des journaux d'événementsSignaler les résultats à IDTSpécifier le comportement de sortie

AWS IoT Greengrass Version 1 est entré dans la phase de durée de vie prolongée le 30 juin 2023. Pour plus d'informations, consultez la politique de AWS IoT Greengrass V1 maintenance. Après cette date, AWS IoT Greengrass V1 ne publiera pas de mises à jour fournissant des fonctionnalités, des améliorations, des corrections de bogues ou des correctifs de sécurité. Les appareils qui fonctionnent AWS IoT Greengrass V1 sous tension ne seront pas perturbés et continueront à fonctionner et à se connecter au cloud. Nous vous recommandons vivement de migrer vers AWS IoT Greengrass Version 2, qui ajoute de nouvelles fonctionnalités importantes et prend en charge des plateformes supplémentaires.

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éer des exécutables de cas de test IDT

Vous pouvez créer et placer des exécutables de cas 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 de latest.jsonpour déterminer les tests à exécuter, vous pouvez créer un exécutable de cas de test unique 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 basés sur des commandes spécifiées, vous créez un exécutable de cas de test 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 cas de test en conséquence. Assurez-vous que vous fournissez le chemin exécutable de cas de test correct dans chaque castest.jsonet 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.jsonpour le cas de test sélectionné, détermine les processus à démarrer et les variables d'environnement à définir.

  • Lesuite.jsonpour la suite de tests détermine les variables d'environnement à définir.

IDT lance le processus exexutable de test requis en fonction des commandes et des arguments spécifiés dans letest.jsonet transmet les variables d'environnement requises au processus.

Utiliser le SDK Client IDT

Les kits SDK Client IDT vous permettent de simplifier la façon dont vous écrivez une logique de test dans votre exécutable de test avec des commandes API que vous pouvez utiliser Interact avec IDT et vos appareils testés. IDT fournit actuellement les kits de développement logiciel suivants :

  • Kit SDK client IDT pour Python

  • Kit SDK client IDT pour Go

Ces kits SDK sont situés dans le<device-tester-extract-location>/sdksfolder. Lorsque vous créez un nouvel exécutable de cas de test, vous devez copier le kit SDK que vous souhaitez utiliser dans le dossier contenant l'exécutable de votre cas 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 vos exécutables de scénario de test.

Interaction entre appareils

Les commandes suivantes vous permettent de communiquer avec l'appareil testé sans avoir à implémenter d'autres fonctions d'interaction et de gestion de la connectivité des appareils.

ExecuteOnDevice

Permet aux suites de tests d'exécuter des commandes shell sur un périphérique 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 périphérique 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

Étant donné que IDT ne gère pas les connexions directes aux appareils créés à l'aide des informations d'accès aux appareils à partir du contexte, nous vous recommandons d'utiliser ces commandes API d'interaction avec les appareils dans vos exécutables de cas 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 à l'appareil à partir de la suite de tests.

Pour établir une connexion directe, récupérez les informations dans ledevice.connectivityet l'resource.devices.connectivitypour votre appareil en cours de test et pour les périphériques de ressources, respectivement. Pour plus d'informations sur l'utilisation du contexte IDT, consultezUtiliser 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 la présence de 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, consultez Utiliser le contexte IDT.

SendResult

Permet aux suites de tests de signaler les résultats des scénarios de test à IDT. Cette commande doit être appelée à la fin de chaque cas de test dans une suite de tests.

Interaction avec l'

La commande suivante permet à vos suites de tests de communiquer avec la machine hôte.

PollForNotifications

Permet aux suites de tests de vérifier la présence de 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, consultez 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 de l'exécutable du cas de test.

Activer les commandes IDT CLI

Lerun-suitecommande IDT CLI propose plusieurs options qui permettent au lanceur de test de personnaliser l'exécution des tests. Pour permettre aux exécuteurs de tests d'utiliser ces options pour exécuter votre suite de tests personnalisée, vous implémentez la prise en charge de l'interface de ligne de commande IDT. Si vous n'implémentez pas la prise en charge, les exécuteurs de tests pourront toujours exécuter des tests, mais certaines options CLI ne fonctionneront pas correctement. Pour offrir une expérience client idéale, nous vous recommandons de mettre en œuvre la prise en charge des arguments suivants pour lerun-suitedans 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 exécuteurs de test peuvent utiliser cet argument pour augmenter le délai d'attente des cas de test qu'ils souhaitent exécuter. Lorsqu'un lanceur de test spécifie cet argument dans sonrun-suite, IDT l'utilise pour calculer la valeur de la variable d'environnement IDT_TEST_TIMEOUT et définit la valeurconfig.timeoutMultiplierdans le contexte IDT. Pour soutenir cet argument, vous devez procéder comme suit :

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

  • Récupérer leconfig.timeoutMultiplierà partir du contexte IDT et l'appliquer à des délais d'attente longs.

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

stop-on-first-failure

Spécifie qu'IDT doit cesser d'exécuter tous les tests s'il rencontre un échec.

Lorsqu'un lanceur de test spécifie cet argument dans sonrun-suite, IDT cessera d'exécuter les tests dès qu'il rencontre un échec. Toutefois, si les cas 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 cas de test en cours d'arrêt, de nettoyage des ressources temporaires et de signaler un résultat de test à IDT. Pour plus d'informations sur la sortie anticipée des échecs, consultezSpé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 coureurs de test peuvent utiliser ces arguments avec leurrun-suitepour spécifier le comportement d'exécution de test suivant :

  • Exécutez tous les tests au sein des groupes de tests spécifiés.

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

Pour prendre en charge ces arguments, la machine d'état de votre suite de tests doit inclure un ensemble spécifique deRunTasketChoicedans votre machine d'état. Si vous n'utilisez pas de machine à états personnalisée, la machine d'état 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, utilisezExemple de machine d'état : Exécuter des groupes de test sélectionnés par l'utilisateurcomme exemple pour ajouter les états requis dans votre machine d'état.

Pour plus d'informations sur les commandes IDT CLI, consultezDéboguer et exécuter des suites de tests personnalisées.

rédigent des journaux d'événements

Pendant que le test est en cours, vous envoyez des données àstdoutetstderrpour écrire des journaux d'événements et des messages d'erreur sur la console. Pour plus d'informations sur le format des messages de console, consultezFormat des messages de la console.

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

Vous pouvez configurer chaque cas de test pour écrire les journaux de son exécution de test, y compris les journaux de l'appareil testé, dans le<group-id>_<test-id>situé dans le fichier<device-tester-extract-location>/results/execution-id/logsfolder. Pour ce faire, récupérez le chemin d'accès au fichier journal à partir du contexte IDT avec letestData.logFilePath, créez un fichier à ce chemin d'accès et écrivez le contenu que vous souhaitez y accéder. 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 cas de test, aucun fichier n'est généré pour ce cas de test.

Vous pouvez également configurer votre exécutable de texte pour créer des fichiers journaux supplémentaires au besoin dans le<device-tester-extract-location>/logsfolder. Nous vous recommandons de spécifier des préfixes uniques pour les noms de fichiers journaux afin que vos fichiers ne soient pas écrasés.

Signaler les résultats à IDT

IDT écrit les résultats des tests sur leawsiotdevicetester_report.xmlet l'suite-name_report.xmlfichiers suivants. 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, consultezExaminer les résultats des tests IDT et les journaux

Pour renseigner le contenu de l'suite-name_report.xml, vous devez utiliser leSendResultpour signaler les résultats des tests à IDT avant la fin de l'exécution du test. Si IDT ne peut pas localiser les résultats d'un test, il génère une erreur pour le cas 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é dans letestData.testArtifactsPathclassé 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 pour fournir directement les résultats à IDT au lieu d'analyser les résultats, puis d'utiliser l'API pour les soumettre à IDT.

Si vous utilisez cette méthode, assurez-vous que votre logique de test résume avec précision les résultats du test et formate votre fichier de résultats dans le même format que lesuite-name_report.xmldans le fichier. IDT n'effectue aucune validation des données que vous fournissez, à l'exception des exceptions suivantes :

  • IDT ignore toutes les propriétés dutestsuitesétiquette. Au lieu de cela, il calcule les propriétés des balises à partir d'autres résultats de groupes de tests signalés.

  • Au moins unetestsuitela balise doit exister danstestsuites.

Étant donné que IDT utilise le même dossier d'artefacts pour tous les cas de test et ne supprime pas les fichiers de résultats entre les essais, 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 cas de test afin d'écraser les résultats de chaque cas de test et de vous assurer que les résultats corrects sont disponibles pour IDT. Bien que vous puissiez utiliser une approche mixte pour générer 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 quitte toujours avec un code de sortie 0, même si un cas de test signale une défaillance ou un résultat d'erreur. Utilisez des codes de sortie non nuls uniquement pour indiquer qu'un cas de test n'a pas été exécuté ou si l'exécutable du cas de test n'a pas pu communiquer de résultats à IDT. Lorsque IDT reçoit un code de sortie différent de zéro, il marque que le cas de test a rencontré une erreur qui l'a empêché de s'exécuter.

IDT peut demander ou s'attendre à ce qu'un cas 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 cas 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 plus longtemps que la valeur du délai d'attente spécifiée dans le champtest.jsondans le fichier. Si le coureur de test a utilisé letimeout-multiplierpour spécifier un multiplicateur de délai d'attente, puis IDT calcule la valeur du délai d'attente avec le multiplicateur.

Pour détecter cet événement, utilisez la variable d'environnement IDT_TEST_TIMEOUT. Lorsqu'un lanceur de tests 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é.

Interrupte

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

Étant donné que les terminaux propagent des signaux à tous les processus enfants, vous pouvez simplement configurer un gestionnaire de signaux dans vos cas de test pour détecter les signaux d'interruption.

Vous pouvez également interroger périodiquement l'API pour vérifier la valeur de l'APICancellationRequestedbooléen dans lePollForNotificationsRéponse de l'API. Lorsque IDT reçoit un signal d'interruption, il définit la valeur du paramètreCancellationRequestedbooléentrue.

Arrêtez lors du premier échec

Se produit lorsqu'un cas de test exécuté en parallel avec le cas de test actuel échoue et que le lanceur de test a utilisé le paramètrestop-on-first-failurepour spécifier qu'IDT doit s'arrêter lorsqu'il rencontre une défaillance.

Pour détecter cet événement, vous pouvez interroger périodiquement l'API afin de vérifier la valeur de l'APICancellationRequestedbooléen dans lePollForNotificationsRéponse de l'API. Lorsque IDT rencontre une défaillance et est configuré pour s'arrêter lors de la première défaillance, il définit la valeur de laCancellationRequestedbooléentrue.

Lorsque l'un de ces événements se produit, IDT attend pendant 5 minutes que tous les cas de test en cours d'exécution soient terminés. Si tous les cas 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é. En tant que meilleure pratique, vous devez vous assurer que vos cas de test effectuent les actions suivantes lorsqu'ils rencontrent l'un des événements :

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

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

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

  4. Quitter.