Créer un fichier exécutable pour un scénario de IDT test - Gratuit RTOS
Utiliser le IDT client SDKActiver IDT CLI les commandesRé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éer un fichier exécutable pour un scénario de IDT test

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.

IDTlance 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 IDT client SDK

Le IDT client vous SDKs permet de simplifier la façon dont vous écrivez la logique de test dans votre exécutable de test à l'aide de API commandes que vous pouvez utiliser pour interagir avec vos appareils IDT et avec lesquels vous testez. IDTfournit actuellement les éléments suivants SDKs :

  • IDTClient SDK pour Python

  • IDTClient SDK pour Go

  • IDTClient SDK pour Java

Ils se SDKs 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 fichier SDK que vous souhaitez utiliser dans le dossier contenant votre exécutable de scénario de test et le référencer SDK dans votre code. Cette section fournit une brève description des API commandes disponibles que vous pouvez utiliser dans les exécutables de vos scénarios de test.

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 qui prend en charge SSH les connexions au shell Docker.

CopyToDevice

Permet aux suites de tests de copier un fichier local depuis la machine hôte qui s'exécute IDT vers un emplacement spécifié sur un appareil qui prend en charge les SSH connexions Docker shell.

ReadFromDevice

Permet aux suites de tests de lire à partir du port série des appareils compatibles UART avec les connexions.

Note

Comme il IDT ne gère pas les connexions directes aux appareils établies à l'aide des informations d'accès aux appareils provenant du contexte, nous vous recommandons d'utiliser ces API commandes 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 IDT contexte 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 IDT contexte, consultezUtiliser le IDT contexte.

IDTinteraction

Les commandes suivantes permettent à vos suites de tests de communiquer avecIDT.

PollForNotifications

Permet aux suites de tests de vérifier les notifications provenant deIDT.

GetContextValue et GetContextString

Permet aux suites de tests de récupérer des valeurs à partir du IDT contexte. Pour de plus amples informations, veuillez consulter Utiliser le IDT contexte.

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 deIDT.

GetContextValue et GetContextString

Permet aux suites de tests de récupérer des valeurs à partir du IDT contexte. Pour de plus amples informations, veuillez consulter Utiliser le IDT contexte.

ExecuteOnHost

Permet aux suites de tests d'exécuter des commandes sur la machine locale et de IDT gérer le cycle de vie des exécutables des scénarios de test.

Activer IDT CLI les commandes

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 la prise en charge du IDTCLI. Si vous n'implémentez pas le support, les testeurs pourront toujours exécuter les tests, mais certaines CLI options 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 la run-suite commande dans le IDT CLI :

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, l'IDTutilise pour calculer la valeur de la variable d'TIMEOUTenvironnement IDT TEST _ _ et définit le config.timeoutMultiplier champ dans le IDT contexte. 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'TIMEOUTenvironnement IDT TEST _ _ pour obtenir la valeur de délai d'expiration correctement calculée.

  • Récupérez la config.timeoutMultiplier valeur IDT dans le contexte et appliquez-la aux longs délais d'expiration.

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

stop-on-first-failure

Spécifie que l'exécution de tous les tests IDT doit être interrompue en cas d'échec.

Lorsqu'un lanceur de tests spécifie cet argument dans sa run-suite commande, il 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 cet IDT événement se produit, votre logique de test indique à tous les cas 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, consultezSpécifier le comportement de sortie.

group-id et test-id

Spécifie que seuls les groupes de tests ou les scénarios de test sélectionnés IDT doivent être exécuté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 à IDT états par défaut inclut les états requis pour vous et vous n'avez aucune autre action à effectuer. 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 comme exemple pour ajouter les états requis dans votre machine à états.

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

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, consultezFormat des messages de console.

Lorsque la suite de tests est IDT terminée, ces informations sont également disponibles dans le test_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, 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 du fichier journal IDT dans le contexte de la testData.logFilePath requête, créez un fichier sur ce chemin et inscrivez le contenu souhaité. IDTmet 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 <device-tester-extract-location>/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 suite-name_report.xml fichiers awsiotdevicetester_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 IDT utilisés pour ces rapports, voir Examiner IDT les résultats des tests et les journaux

Pour renseigner le contenu du suite-name_report.xml fichier, vous devez utiliser la SendResult commande pour signaler les résultats des tests IDT avant la fin de l'exécution du test. Si les résultats d'un test IDT ne sont pas localisés, une erreur est générée pour le scénario de test. L'extrait Python suivant montre les commandes auxquelles envoyer un résultat de test IDT :

request-variable = SendResultRequest(TestResult(result))
client.send_result(request-variable)

Si vous ne publiez pas les résultats via leAPI, IDT recherche les résultats des tests dans le dossier des artefacts de test. Le chemin d'accès à ce dossier est enregistré dans testData.testArtifactsPath le fichier du IDT contexte. Dans ce dossier, IDT utilise le premier XML fichier trié par ordre alphabétique qu'il trouve comme résultat du test.

Si votre logique de test produit des JUnit XML résultats, vous pouvez écrire les résultats du test dans un XML fichier du dossier des artefacts pour y fournir directement les résultats IDT au lieu de les analyser puis d'utiliser le API pour les envoyerIDT.

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. IDTn'effectue aucune validation des données que vous fournissez, sauf dans les cas suivants :

  • IDTignore 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érieurtestsuites.

Comme elle 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 générer des rapports erronés en cas de IDT lecture du fichier incorrect. Nous vous recommandons d'utiliser le même nom pour le fichier de XML résultats généré dans tous les scénarios de test afin de remplacer les résultats de chaque cas de test et de vous assurer que les résultats corrects sont disponibles IDT pour utilisation. Bien que vous puissiez utiliser une approche mixte pour créer des rapports dans votre suite de tests, c'est-à-dire utiliser un XML fichier de résultats pour certains cas de test et soumettre les résultats via le fichier 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 Lorsqu'il IDT reçoit un code de sortie différent de zéro, il indique que le scénario de test a rencontré une erreur qui l'a empêché de s'exécuter.

IDTpeut demander ou s'attendre à ce qu'un scénario de test cesse de s'exécuter avant qu'il ne soit terminé dans les événements suivants. Utilisez ces informations pour configurer le fichier exécutable de votre scénario de test afin de détecter chacun de ces événements dans le scénario de test :

Expiration

Se produit lorsqu'un scénario de test s'exécute pendant une durée supérieure à la valeur de délai spécifiée dans le test.json fichier. Si le lanceur de test a utilisé l'timeout-multiplierargument pour spécifier un multiplicateur de délai d'attente, il IDT calcule la valeur du délai d'expiration avec le multiplicateur.

Pour détecter cet événement, utilisez la variable d'TIMEOUTenvironnement IDT TEST _ _. Lorsqu'un lanceur de tests lance un test, IDT définit la valeur de la variable d'TIMEOUTenvironnement IDT TEST _ _ 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 s'interrompt. IDT Par exemple, en appuyant surCtrl+C.

É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 le API pour vérifier la valeur du CancellationRequested booléen dans la PollForNotifications API réponse. Lorsqu'il 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-failureargument pour spécifier qu'il IDT doit s'arrêter en cas d'échec.

Pour détecter cet événement, vous pouvez régulièrement interroger le API afin de vérifier la valeur du CancellationRequested booléen dans la PollForNotifications API réponse. Lorsqu'il IDT rencontre une défaillance et qu'il 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 produitIDT, attendez 5 minutes pour que tous 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 chacun de leurs processus à s'arrêter. S'il n'IDTa pas reçu de résultats de test 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.

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

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

  4. Sortir.