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 la machine d'état IDT **Important** À partir de IDT v4.5.1, 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, plutôt que 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 la 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 associe 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 `RunTask` les deux `Choice` états dans votre `state_machine.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](create-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 passe à l'état suivant uniquement 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 seront exécutés 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" } } } ```