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.
Configurer la machine d'état IDT
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 d'état pour vous. La machine d'état par défaut remplit les fonctions suivantes :
-
Offre aux coureurs de tests la possibilité de sélectionner et d'exécuter des groupes de tests spécifiques, au lieu de toute la suite de tests.
-
Si des groupes de tests spécifiques ne sont pas sélectionnés, exécute tous les groupes de tests de la suite de tests dans un ordre aléatoire.
-
Génère des rapports et imprime un résumé de la console qui affiche 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 IDT doit entreprendre, par exemple pour exécuter un groupe de test ou un produit un fichier de rapport.
-
La transition vers 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 soit
Succeed
ouFail
.
Format de la machine d'état
Vous pouvez utiliser le modèle suivant pour configurer le vôtre
dans le fichier: <custom-test-suite-folder>
/suite/state_machine.json
{ "Comment": "
<description>
", "StartAt": "<state-name>
", "States": { "<state-name>
": { "Type": "<state-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 d'état.
StartAt
-
Nom de l'état auquel IDT commence à exécuter la suite de tests. Pour
StartAt
doit être défini sur l'un des états répertoriés dans laStates
objet. States
-
Objet qui mappe les noms d'états définis par l'utilisateur à des états IDT valides. Chaque État.
nom-état
contient la définition d'un état valide mappé à lanom-état
.Le
States
l'objet doit inclure leSucceed
etFail
états. Pour plus d'informations sur les états valides, consultezDéfinitions d'états et d'états valides.
Définitions d'états et d'états valides
Cette section décrit les définitions d'état de tous les états valides pouvant être utilisés dans la machine d'état IDT. Certains des états suivants prennent en charge les configurations au niveau du cas de test. Toutefois, nous vous recommandons de configurer des règles de transition d'état au niveau du groupe de test plutôt qu'au niveau du scénario de test, sauf si cela est absolument nécessaire.
Définitions des états
RunTask
LeRunTask
state exécute les cas de tests d'un groupe de tests défini dans la suite de tests.
{ "Type": "RunTask", "Next": "
<state-name>
", "TestGroup": "<group-id>
", "TestCases": [ "<test-id>
" ], "ResultVar": "<result-name>
" }
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
Next
-
Nom de l'état auquel passer après avoir exécuté les actions de 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 lanceur de test.
TestCases
-
Facultatif. Tableau d'ID de cas de test du groupe spécifié dans
TestGroup
. Basé sur les valeurs deTestGroup
etTestCases
, IDT détermine le comportement d'exécution du test comme suit :-
Quand les deux
TestGroup
etTestCases
sont spécifiés, IDT exécute les cas de test spécifiés à partir du groupe de tests. -
Quand
TestCases
sont spécifiés maisTestGroup
n'est pas spécifié, IDT exécute les cas de test spécifiés. -
Quand
TestGroup
est spécifié, maisTestCases
n'est pas spécifié, IDT exécute tous les cas de tests du groupe de tests spécifié. -
Quand aucun des deux
TestGroup
ouTestCases
est spécifié, IDT exécute tous les cas de test du groupe de test sélectionné par le lanceur de test dans l'interface de ligne de commande IDT. Pour activer la sélection de groupes pour les coureurs d'essais, vous devez inclure les deuxRunTask
etChoice
états dans votrestatemachine.json
dans le fichier. Pour obtenir un exemple montrant la façon dont cela fonctionne, consultezExemple de machine d'état : Exécuter des groupes de test sélectionnés par l'utilisateur.Pour plus d'informations sur l'activation des commandes IDT CLI pour les exécuteurs de tests, consultezActiver les commandes IDT CLI.
-
ResultVar
-
Nom de la variable de contexte à définir avec les résultats de l'exécution du test. Ne spécifiez pas cette valeur si vous n'avez pas spécifié de valeur pour
TestGroup
. IDT définit la valeur de la variable que vous définissez dansResultVar
pourtrue
oufalse
basé sur les éléments suivants :-
Si le nom de la variable est du formulaire
, la valeur est alors définie sur si tous les tests du premier groupe de test ont réussi ou ont été ignorés.text
_text
_passed -
Dans tous les autres cas, la valeur est définie sur si tous les tests de tous les groupes de tests ont réussi ou ont été ignorés.
-
En général, vous utiliserezRunTask
pour spécifier un ID de groupe de test sans spécifier d'ID de cas de test individuels, 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 parallel, dans un ordre aléatoire. Toutefois, si tous les cas de test nécessitent l'exécution d'un périphérique et qu'un seul appareil est disponible, les cas de test seront exécutés de manière séquentielle.
Gestion des erreurs
Si l'un des groupes de test ou des identifiants de cas de test spécifiés n'est pas valide, cet état émet la valeurRunTaskError
erreur d'exécution. Si l'état rencontre une erreur d'exécution, il définit également le paramètrehasExecutionError
variable dans le contexte de la machine à étatstrue
.
Choice
LeChoice
vous permet de définir dynamiquement l'état suivant vers lequel passer la transition en fonction des conditions définies par l'utilisateur.
{ "Type": "Choice", "Default": "
<state-name>
", "FallthroughOnError": true | false, "Choices": [ { "Expression": "<expression>
", "Next": "<state-name>
" } ] }
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
Default
-
État auquel passer si aucune des expressions définies dans
Choices
peuvent être évalués pourtrue
. FallthroughOnError
-
Facultatif. Spécifie le comportement lorsque l'état rencontre une erreur lors de l'évaluation des expressions. Définit sur
true
si vous souhaitez ignorer une expression si l'évaluation entraîne une erreur. Si aucune expression ne correspond, la machine d'état passe à laDefault
État. Si l'icôneFallthroughOnError
La valeur n'est pas spécifiée, elle est par défautfalse
. Choices
-
Tableau d'expressions et d'états permettant de déterminer l'état vers lequel effectuer la transition après avoir exécuté les actions dans l'état actuel.
Choices.Expression
-
Chaîne d'expression qui correspond à une valeur booléenne. Si l'expression est évaluée à
true
, puis la machine d'état passe à l'état défini dansChoices.Next
. Les chaînes d'expression récupèrent les valeurs du contexte de la machine d'état, puis effectuent des opérations sur elles pour obtenir une valeur booléenne. Pour plus d'informations sur l'accès au contexte de la machine d'état, voirContexte des machines d'état. Choices.Next
-
Nom de l'état auquel passer si l'expression définie dans
Choices.Expression
évalue àtrue
.
Gestion des erreurs
LeChoice
l'é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 d'état.
-
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 unCatch
pour gérer les erreurs de cet état. Si vous souhaitez arrêter l'exécution de la machine d'état en cas d'erreur, vous devez définirFallthroughOnError
pourfalse
. Toutefois, nous vous recommandons de définirFallthroughOnError
pourtrue
, et selon votre cas d'utilisation, effectuez l'une des actions suivantes :
-
Si une variable à laquelle vous accédez ne devrait pas exister dans certains cas, utilisez la valeur de
Default
et supplémentairesChoices
blocs permettant de spécifier l'état suivant. -
Si une variable à laquelle vous accédez doit toujours exister, définissez la valeur
Default
État àFail
.
Parallèle
LeParallel
vous permet de définir et d'exécuter de nouvelles machines à états parallel les unes aux autres.
{ "Type": "Parallel", "Next": "
<state-name>
", "Branches": [<state-machine-definition>
] }
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
Next
-
Nom de l'état auquel passer après avoir exécuté les actions de l'état actuel.
Branches
-
Tableau de définitions de machines à états à exécuter. Chaque définition de machine d'état doit contenir la sienne
StartAt
,Succeed
, etFail
états. Les définitions de machines d'état de cette baie ne peuvent pas faire référence à des états en dehors de leur propre définition.Note
Étant donné que chaque machine d'état de branche partage le même contexte de machine d'état, la définition de variables dans une branche, puis la lecture de ces variables à partir d'une autre branche peut entraîner un comportement inattendu.
LeParallel
state passe à l'état suivant uniquement après avoir exécuté toutes les machines d'état de branche. Chaque état nécessitant un appareil attend d'être exécuté 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 parallel. Si suffisamment de périphériques ne sont pas disponibles, les cas de test seront exécutés de manière séquentielle. Étant donné que les cas de test sont exécutés dans un ordre aléatoire lorsqu'ils sont exécutés en parallel, différents périphériques peuvent être utilisés pour exécuter des tests à partir du même groupe de tests.
Gestion des erreurs
Assurez-vous que la machine d'état de branche et la machine d'état parent transitent vers leFail
pour gérer les erreurs d'exécution.
Étant donné que les machines d'état de branche ne transmettent pas d'erreurs d'exécution à la machine d'état parente, vous ne pouvez pas utiliser unCatch
pour gérer les erreurs d'exécution dans les machines d'état de branche. Utilisez plutôt lehasExecutionErrors
valeur dans le contexte de la machine à états partagés. Pour obtenir un exemple montrant la façon dont cela fonctionne, consultezExemple de machine d'état : Exécutez deux groupes de tests en parallel.
Ajouter des fonctionnalités du produit
LeAddProductFeatures
vous permet d'ajouter des fonctionnalités du produit à laawsiotdevicetester_report.xml
fichier généré par IDT.
Une fonctionnalité produit est constituée d'informations définies par l'utilisateur sur des critères spécifiques auxquels un appareil peut répondre. Par exemple, les recettesMQTT
peut indiquer que l'appareil publie correctement les messages MQTT. Dans le rapport, les fonctionnalités du produit sont définies comme suit :supported
,not-supported
, ou une valeur personnalisée, selon que les tests spécifiés ont réussi ou non.
Note
LeAddProductFeatures
state ne génère pas de rapports par lui-même. Cet état doit passer à laReportétatpour générer des rapports.
{ "Type": "Parallel", "Next": "
<state-name>
", "Features": [ { "Feature": "<feature-name>
", "Groups": [ "<group-id>
" ], "OneOfGroups": [ "<group-id>
" ], "TestCases": [ "<test-id>
" ], "IsRequired": true | false, "ExecutionMethods": [ "<execution-method>
" ] } ] }
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
Next
-
Nom de l'état auquel passer après avoir exécuté les actions de l'état actuel.
Features
-
Un éventail de fonctionnalités du produit à afficher dans le
awsiotdevicetester_report.xml
dans le fichier.Feature
-
Nom de la fonction
FeatureValue
-
Facultatif. La valeur personnalisée à utiliser dans le rapport au lieu de
supported
. Si cette valeur n'est pas spécifiée, en fonction des résultats des tests, la valeur de l'entité est définie sursupported
ounot-supported
.Si vous utilisez une valeur personnalisée pour
FeatureValue
, vous pouvez tester la même fonction avec des conditions différentes, et IDT concaténe les valeurs des entités pour les conditions prises en charge. Par exemple, l'extrait suivant montre laMyFeature
avec deux valeurs d'entités 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 l'entité est définie sur
first-feature-supported, second-feature-supported
. Groups
-
Facultatif. Tableau des ID de groupe de test. 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. Tableau des ID de groupe de test. 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. Tableau des ID de cas de test. Si vous spécifiez cette valeur, les éléments suivants s'appliquent :
-
Tous les cas de test spécifiés doivent réussir pour que la fonctionnalité soit prise en charge.
-
Groups
doit contenir un seul ID de groupe de tests. -
OneOfGroups
ne doit pas être spécifié.
-
IsRequired
-
Facultatif. Définit sur
false
pour marquer cette fonctionnalité comme une fonctionnalité facultative dans le rapport. La valeur par défaut esttrue
. ExecutionMethods
-
Facultatif. Un tableau de méthodes d'exécution qui correspondent à la
protocol
valeur spécifiée dans ledevice.json
dans le fichier. Si cette valeur est spécifiée, les exécuteurs de test doivent spécifier unprotocol
valeur qui correspond à l'une des valeurs de ce tableau pour inclure l'entité dans le rapport. Si cette valeur n'est pas spécifiée, l'entité sera toujours incluse dans le rapport.
Pour utiliser le pluginAddProductFeatures
, vous devez définir la valeur deResultVar
dans leRunTask
indique l'une des valeurs suivantes :
-
Si vous avez spécifié des ID de cas de test individuels, définissez
ResultVar
pour
.group-id_test-id
_passed -
Si vous n'avez pas spécifié d'ID de cas de test individuels, définissez
ResultVar
pour
.group-id
_passed
LeAddProductFeatures
vérifiez l'état des résultats des tests de la façon suivante :
-
Si vous n'avez pas spécifié d'ID de cas de test, le résultat de chaque groupe de test est déterminé à partir de la valeur de la
variable dans le contexte de la machine d'état.group-id
_passed -
Si vous avez spécifié des identifiants de cas de test, le résultat de chacun des tests est déterminé à partir de la valeur de la
variable dans le contexte de la machine d'état.group-id_test-id
_passed
Gestion des erreurs
Si un ID de groupe fourni dans cet état n'est pas un ID de groupe valide, cet état génère leAddProductFeaturesError
erreur d'exécution. Si l'état rencontre une erreur d'exécution, il définit également le paramètrehasExecutionErrors
variable dans le contexte de la machine à étatstrue
.
Rapport
LeReport
génère le
etsuite-name
_Report.xmlawsiotdevicetester_report.xml
fichiers suivants. Cet état diffuse également le rapport vers la console.
{ "Type": "Report", "Next": "
<state-name>
" }
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
Next
-
Nom de l'état auquel passer après avoir exécuté les actions de l'état actuel.
Vous devez toujours passer auReport
état vers la fin du flux d'exécution du test afin que les coureurs de test puissent afficher les résultats des tests. Généralement, l'état suivant après cet état estSucceed
.
Gestion des erreurs
Si cet état rencontre des problèmes lors de la génération des rapports, il émet alors leReportError
erreur d'exécution.
Message de journal
LeLogMessage
génère letest_manager.log
et diffuse le message de journal dans la console.
{ "Type": "LogMessage", "Next": "
<state-name>
" "Level": "info | warn | error" "Message": "<message>
" }
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
Next
-
Nom de l'état auquel passer après avoir exécuté les actions de l'état actuel.
Level
-
Niveau d'erreur auquel créer le message de journal. Si vous spécifiez un niveau non valide, cet état génère un message d'erreur et le rejette.
Message
-
Message à enregistrer.
Sélectionner un groupe
LeSelectGroup
state met à jour le contexte de la machine d'état pour indiquer quels groupes sont sélectionnés. Les valeurs définies par cet état sont utilisées par les autresChoice
états.
{ "Type": "SelectGroup", "Next": "
<state-name>
" "TestGroups": [<group-id>
" ] }
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
Next
-
Nom de l'état auquel passer après avoir exécuté les actions de l'état actuel.
TestGroups
-
Tableau de groupes de tests qui seront marqués comme sélectionnés. Pour chaque ID de groupe de test de cette baie, le
est définie surgroup-id
_selectedtrue
dans le contexte. Assurez-vous de fournir des ID de groupe de test valides, car IDT ne vérifie pas si les groupes spécifiés existent.
Fail
LeFail
indique que la machine d'état 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 d'état doit inclure cet état.
{ "Type": "Fail" }
Succeed
LeSucceed
indique que la machine d'état a été correctement exécutée. Il s'agit d'un état final pour la machine à états, et chaque définition de machine d'état doit inclure cet état.
{ "Type": "Succeed" }
Contexte des machines d'état
Le contexte de la machine d'état est un document JSON en lecture seule qui contient des données disponibles pour la machine à états pendant l'exécution. Le contexte de la machine d'état est accessible uniquement à 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 exécuteurs de tests dans leuserdata.json
pour déterminer si un test spécifique est nécessaire à l'exécution.
Le contexte de la machine d'état utilise le format suivant :
{ "pool": {
<device-json-pool-element>
}, "userData": {<userdata-json-content>
}, "config": {<config-json-content>
}, "suiteFailed": true | false, "specificTestGroups": [ "<group-id>" ], "specificTestCases": [ "<test-id>" ], "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
dans le fichier. userData
-
Informations dans le
userdata.json
dans le fichier. config
-
Informations épinglez le
config.json
dans le fichier. suiteFailed
-
La valeur est définie sur
false
lorsque la machine d'état démarre. Si un groupe de test échoue dans unRunTask
, cette valeur est alors définie surtrue
pendant la durée restante de l'exécution de la machine d'état. specificTestGroups
-
Si le lanceur de tests sélectionne des groupes de tests spécifiques à exécuter au lieu de toute la suite de tests, cette clé est créée et contient la liste des ID de groupes de tests spécifiques.
specificTestCases
-
Si le lanceur de tests sélectionne des cas de test spécifiques à exécuter au lieu de toute la suite de tests, cette clé est créée et contient la liste des ID de cas de test spécifiques.
hasExecutionErrors
-
Ne se ferme pas lorsque la machine d'état démarre. Si un état rencontre des erreurs d'exécution, cette variable est créée et définie sur
true
pendant la durée restante de l'exécution de la machine d'état.
Vous pouvez interroger le contexte à l'aide de la notation JSONPath. La syntaxe des requêtes JSONPath dans les définitions d'état est{{$.
. Vous pouvez utiliser des requêtes JSONPath comme chaînes d'espace réservé dans certains états. IDT remplace les chaînes d'espace réservé par la valeur de la requête JSONPath évaluée à partir du contexte. Vous pouvez utiliser des espaces réservés pour les valeurs suivantes :query
}}
-
Le
TestCases
valeur dansRunTask
états. -
Le
Expression
valeurChoice
État.
Lorsque vous accédez à des données du contexte de la machine d'état, vérifiez que les conditions suivantes sont remplies :
-
Vos chemins JSON doivent commencer par
$.
-
Chaque valeur doit être évaluée en chaîne, en nombre ou en booléen.
Pour plus d'informations sur l'utilisation de la notation JSONPath pour accéder aux données du contexte, consultezUtiliser le contexte IDT.
Erreurs d'exécution
Les erreurs d'exécution sont des erreurs dans la définition de la machine d'état rencontrées par la machine d'état lors de l'exécution d'un état. IDT enregistre les informations relatives à chaque erreur dans letest_manager.log
et diffuse le message de journal dans la console.
Vous pouvez utiliser les méthodes suivantes pour gérer les erreurs d'exécution :
-
Ajout d'unCatchblocdans la définition de l'état.
-
Vérifiez la valeur duhasExecutionErrorsvaleurdans le contexte de la machine d'état.
Capture
Pour utiliserCatch
, ajoutez ce qui suit à votre définition d'état :
"Catch": [ { "ErrorEquals": [ "
<error-type>
" ] "Next": "<state-name>
" } ]
Tous les champs qui contiennent des valeurs sont requis, comme indiqué ici :
Catch.ErrorEquals
-
Tableau des types d'erreurs à catch. Si une erreur d'exécution correspond à l'une des valeurs spécifiées, la machine d'état passe à l'état spécifié dans
Catch.Next
. Consultez chaque définition d'état pour plus d'informations sur le type d'erreur qu'elle produit. Catch.Next
-
État suivant à 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 bloc corresponde Si les erreurs sans erreur correspondent à celles répertoriées dans les blocs Catch, les machines d'état continuent de s'exécuter. Étant donné que les erreurs d'exécution sont le résultat de définitions d'état incorrectes, nous vous recommandons de passer à l'état Échec lorsqu'un état rencontre une erreur d'exécution.
Erreur d'exécution
Lorsque certains états rencontrent des erreurs d'exécution, en plus d'émettre l'erreur, ils définissent également le paramètrehasExecutionError
valeur pourtrue
dans le contexte de la machine d'état. Vous pouvez utiliser cette valeur pour détecter quand une erreur se produit, puis utiliser unChoice
pour faire passer la machine à états vers leFail
État.
Cette méthode possède les caractéristiques suivantes.
-
La machine d'état ne démarre avec aucune valeur attribuée à
hasExecutionError
, et cette valeur n'est pas disponible tant qu'un état particulier ne l'a pas définie. Cela signifie que vous devez définir explicitement laFallthroughOnError
pourfalse
pour laChoice
les états qui accèdent à cette valeur pour empêcher l'arrêt de la machine d'état si aucune erreur d'exécution ne se produit. -
Une fois qu'il est réglé sur
true
,hasExecutionError
n'est jamais défini sur false ou supprimé du contexte. Cela signifie que cette valeur n'est utile que la première fois qu'elle est définie surtrue
, et pour tous les États subséquents, il ne fournit pas de valeur significative. -
Le
hasExecutionError
est partagée avec toutes les machines d'état de branche dans leParallel
, ce qui peut entraîner des résultats inattendus en fonction de l'ordre dans lequel il est accédé.
En raison de ces caractéristiques, nous ne recommandons pas d'utiliser cette méthode si vous pouvez utiliser un bloc Catch à la place.
Exemple de machines d'état
Cette section fournit quelques exemples de configurations de machines d'état.
Exemples
- Exemple de machine d'état : Exécutez un groupe de test unique
- Exemple de machine d'état : Exécuter des groupes de test sélectionnés par l'utilisateur
- Exemple de machine d'état : Exécutez un groupe de test unique avec des fonctionnalités du produit
- Exemple de machine d'état : Exécutez deux groupes de tests en parallel
Exemple de machine d'état : Exécutez un groupe de test unique
Cette machine d'état :
-
Exécutez le groupe de test avec l'identifiant
GroupA
, qui doit être présente dans la suite d'ungroup.json
dans le fichier. -
Vérifie les erreurs d'exécution et les transitions vers
Fail
s'il y en a. -
Génère un rapport et effectue des transitions vers
Succeed
s'il n'y a pas d'erreurs, etFail
autrement.
{ "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 d'état : Exécuter des groupes de test sélectionnés par l'utilisateur
Cette machine d'état :
-
Vérifie si le coureur de test a sélectionné des groupes de test spécifiques. La machine d'état ne vérifie pas les cas de test spécifiques car les exécuteurs de tests ne peuvent pas sélectionner de cas de test sans avoir également sélectionné un groupe de test.
-
Si les groupes de test sont sélectionnés :
-
Exécute les cas de test au sein des groupes de test sélectionnés. Pour ce faire, la machine d'état ne spécifie explicitement aucun groupe de test ni aucun cas de test dans le
RunTask
État. -
Génère un rapport après avoir exécuté tous les tests et les sorties.
-
-
Si les groupes de test ne sont pas sélectionnés :
-
Exécute des tests dans un 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 d'état : Exécutez un groupe de test unique avec des fonctionnalités du produit
Cette machine d'état :
-
Exécutez le groupe de test
GroupA
. -
Vérifie les erreurs d'exécution et les transitions vers
Fail
s'il y en a. -
Ajoute le
FeatureThatDependsOnGroupA
fonction de la fonctionawsiotdevicetester_report.xml
dans le fichier:-
Si
GroupA
passe, la fonction est définie sursupported
. -
La fonctionnalité n'est pas marquée comme facultative dans le rapport.
-
-
Génère un rapport et effectue des transitions vers
Succeed
s'il n'y a pas d'erreurs, etFail
autrement
{ "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 d'état : Exécutez deux groupes de tests en parallel
Cette machine d'état :
-
Exécutez le
GroupA
etGroupB
groupes de test en parallel. LeResultVar
variables stockées dans le contexte par leRunTask
les états dans les machines d'état de branche sont disponibles pour leAddProductFeatures
État. -
Vérifie les erreurs d'exécution et les transitions vers
Fail
s'il y en a. Cette machine d'état n'utilise pas deCatch
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 basé sur les groupes qui passent-
Si
GroupA
passe, la fonction est définie sursupported
. -
La fonctionnalité n'est pas marquée comme facultative dans le rapport.
-
-
Génère un rapport et effectue des transitions vers
Succeed
s'il n'y a pas d'erreurs, etFail
autrement
Si deux appareils sont configurés dans le pool de périphériques, les deuxGroupA
etGroupB
peut fonctionner en même temps. Toutefois, si l'un ou l'autreGroupA
ouGroupB
contient plusieurs tests, puis les deux appareils peuvent être alloués à ces tests. Si un seul appareil est configuré, les groupes de test seront exécutés 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" } } }