Configuration de l'orchestrateur de test IDT - Gratuit RTOS

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.

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 d'identifiants de test incorrects ou de dépendances circulaires.

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 plus d’informations, consultez Accédez aux données dans le contexte.

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. Une liste de conditions et les cas de test correspondants qui sont 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 identifiants de cas de test 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

Exemple

L'exemple suivant utilise des expressions contextuelles génériques que vous pouvez définir en tant que tellesAliases.

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 :

  • Les identifiants de groupes de test que vous spécifiez dans un descripteur de groupe doivent 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 des identifiants de groupe uniques. Vous ne pouvez pas répéter un identifiant de groupe de test dans des descripteurs de groupe individuels.

  • Une liste de descripteurs de groupe 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.

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. Dansawsiotdevicetester_report.xml, les fonctionnalités du produit sont définies sous la forme de supportednot-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

Le nom de la fonctionnalité.

Value

Facultatif. La valeur personnalisée que vous souhaitez utiliser dans le rapport à la place desupported. 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'identifiant du groupe de test et un ou plusieurs identifiants de cas de test 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'identifiant du groupe de test et un ou plusieurs identifiants de cas de test 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": { <device-json-pool-element> }, "userData": { <userdata-json-content> }, "config": { <config-json-content> } }
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 notation JSONPath. La syntaxe des requêtes JSONPath 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 notation JSONPath pour accéder aux données depuis le contexte, consultez. Utiliser le contexte IDT