Configurazione della macchina a stato IDT - AWS IoT Greengrass

AWS IoT Greengrass Version 1 è entrato nella fase di estensione della vita utile il 30 giugno 2023. Per ulteriori informazioni, consulta la politica AWS IoT Greengrass V1 di manutenzione. Dopo questa data, AWS IoT Greengrass V1 non rilascerà aggiornamenti che forniscano funzionalità, miglioramenti, correzioni di bug o patch di sicurezza. I dispositivi che funzionano AWS IoT Greengrass V1 non subiranno interruzioni e continueranno a funzionare e a connettersi al cloud. Ti consigliamo vivamente di eseguire la migrazione a AWS IoT Greengrass Version 2, che aggiunge nuove importanti funzionalità e supporto per piattaforme aggiuntive.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Configurazione della macchina a stato IDT

Una macchina a stato è un costrutto che controlla il flusso di esecuzione della suite di test. Determina lo stato iniziale di una suite di test, gestisce le transizioni di stato in base a regole definite dall'utente e continua a passare attraverso tali stati fino a raggiungere lo stato finale.

Se la suite di test non include una macchina a stato definita dall'utente, IDT genererà una macchina a stato per te. Il computer a stato predefinito svolge le seguenti funzioni:

  • Fornisce ai test runner la possibilità di selezionare ed eseguire gruppi di test specifici, anziché l'intera suite di test.

  • Se non sono selezionati gruppi di test specifici, esegue tutti i gruppi di test nella suite di test in un ordine casuale.

  • Genera report e stampa un riepilogo della console che mostra i risultati del test per ciascun gruppo di test e test case.

La macchina a stati di una suite di test IDT deve soddisfare i seguenti criteri:

  • Ciascuno stato corrisponde a un'azione che IDT deve intraprendere, ad esempio per eseguire un gruppo di test o produrre un file di report.

  • La transizione a uno stato esegue l'azione associata allo stato.

  • Ciascuno stato definisce la regola di transizione per lo stato successivo.

  • Lo stato finale deve essereSucceedoFail.

Formato macchina a stati

Puoi utilizzare il seguente modello per configurarne uno<custom-test-suite-folder>/suite/state_machine.jsonfile:

{ "Comment": "<description>", "StartAt": "<state-name>", "States": { "<state-name>": { "Type": "<state-type>", // Additional state configuration } // Required states "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } }

Tutti i campi che includono valori sono obbligatori, come descritto di seguito:

Comment

Una descrizione della macchina a stati.

StartAt

Il nome dello stato in cui IDT inizia a eseguire la suite di test. Il valore diStartAtdeve essere impostato su uno degli stati elencati nellaStatesoggetto.

States

Oggetto che mappa i nomi di stato definiti dall'utente a stati IDT validi. Ciascuno stato.nome statoobject contiene la definizione di uno stato valido mappato alnome stato.

LaStatesl'oggetto deve includere ilSucceedeFailstati. Per informazioni sugli stati validi, consultaStati e definizioni di stato validi.

Stati e definizioni di stato validi

Questa sezione descrive le definizioni di stato di tutti gli stati validi che possono essere utilizzati nella macchina a stato IDT. Alcuni dei seguenti stati supportano le configurazioni a livello di test case. Tuttavia, si consiglia di configurare le regole di transizione dello stato a livello di gruppo di test anziché a livello di test case, a meno che non sia assolutamente necessario.

RunTask

LaRunTaskLo stato esegue test cases da un gruppo di test definito nella suite di test.

{ "Type": "RunTask", "Next": "<state-name>", "TestGroup": "<group-id>", "TestCases": [ "<test-id>" ], "ResultVar": "<result-name>" }

Tutti i campi che includono valori sono obbligatori, come descritto di seguito:

Next

Il nome dello stato al quale passare dopo l'esecuzione delle azioni nello stato corrente.

TestGroup

Facoltativo. L'ID del gruppo di test da eseguire. Se questo valore non è specificato, IDT esegue il gruppo di test selezionato dal corridore di test.

TestCases

Facoltativo. Un array di ID del test case del gruppo specificato inTestGroup. In base ai valori diTestGroupeTestCases, IDT determina il comportamento di esecuzione del test come segue:

  • Quando entrambiTestGroupeTestCasessono specificati, IDT esegue i test case specificati dal gruppo di test.

  • QuandoTestCasessono specificati maTestGroupnon è specificato, IDT esegue i test case specificati.

  • QuandoTestGroupè specificato, maTestCasesNon è specificato, IDT esegue tutti i test case all'interno del gruppo di test specificato.

  • Quando nessuno dei dueTestGroupoTestCasesè specificato, IDT esegue tutti i test case del gruppo di test selezionato dal corridore di prova dalla CLI IDT. Per abilitare la selezione del gruppo per i test runner, è necessario includere entrambiRunTaskeChoicestati nel tuostatemachine.jsonfile. Per un esempio su come eseguire tale operazione, consultaEsempio della macchina a stati: Esegui gruppi di test selezionati dall'utente.

    Per ulteriori informazioni sull'abilitazione di comandi della CLI IDT per i test runner, consultaAbilitare i comandi CLI IDT.

ResultVar

Il nome della variabile di contesto da impostare con i risultati dell'esecuzione del test. Non specificare questo valore se non hai specificato un valore perTestGroup. IDT imposta il valore della variabile definita inResultVaratrueofalsein base a quanto segue:

  • Se il nome della variabile è del modulotext_text_passed, quindi il valore viene impostato su se tutti i test del primo gruppo di test sono passati o sono stati saltati.

  • In tutti gli altri casi, il valore è impostato su se tutti i test in tutti i gruppi di test sono stati superati o sono stati saltati.

In genere si utilizzaRunTaskstato per specificare un ID gruppo di test senza specificare gli ID del caso di test individuali, in modo che IDT esegua tutti i test case nel gruppo di test specificato. Tutti i test case gestiti da questo stato vengono eseguiti in parallel, in ordine casuale. Tuttavia, se tutti i test case richiedono l'esecuzione di un dispositivo ed è disponibile solo un singolo dispositivo, i test case verranno eseguiti in modo sequenziale.

Gestione errori

Se uno qualsiasi dei gruppi di test o ID del test case specificati non è valido, questo stato emette ilRunTaskErrorErrore di esecuzione. Se lo stato rileva un errore di esecuzione, imposta anche ilhasExecutionErrorvariabile nel contesto della macchina a statotrue.

Choice

LaChoicestate consente di impostare dinamicamente lo stato successivo in cui passare in base alle condizioni definite dall'utente.

{ "Type": "Choice", "Default": "<state-name>", "FallthroughOnError": true | false, "Choices": [ { "Expression": "<expression>", "Next": "<state-name>" } ] }

Tutti i campi che includono valori sono obbligatori, come descritto di seguito:

Default

Lo stato predefinito al quale passare se nessuna delle espressioni definite inChoicespuò essere valutato pertrue.

FallthroughOnError

Facoltativo. Specifica il comportamento quando lo stato rileva un errore nella valutazione delle espressioni. Impostare sutruese si desidera saltare un'espressione se la valutazione genera un errore. Se nessuna espressione corrisponde, la macchina a stati passa allaDefaultStato. Se il fileFallthroughOnErrorIl valore non è specificato, il valore predefinito èfalse.

Choices

Una matrice di espressioni e stati per determinare a quale stato passare dopo aver eseguito le azioni nello stato corrente.

Choices.Expression

Una stringa di espressioni che restituisce un valore booleano. Se l'espressione viene valutatatrue, quindi la macchina a stati passa allo stato definito inChoices.Next. Le stringhe di espressione recuperano i valori dal contesto della macchina statale e quindi eseguono operazioni su di esse per arrivare a un valore booleano. Per informazioni sull'accesso al contesto della macchina a stato, vedereContesto della macchina a stati.

Choices.Next

Il nome dello stato al quale passare se l'espressione definita inChoices.Expressionvaluta atrue.

Gestione errori

LaChoicestato può richiedere la gestione degli errori nei seguenti casi:

  • Alcune variabili nelle espressioni di scelta non esistono nel contesto della macchina a stato.

  • Il risultato di un'espressione non è un valore booleano.

  • Il risultato di una ricerca JSON non è una stringa, un numero o un valore booleano.

Non è possibile utilizzare unCatchBlocca per gestire gli errori in questo stato. Se si desidera interrompere l'esecuzione della macchina a stato quando viene rilevato un errore, è necessario impostareFallthroughOnErrorafalse. Consigliamo, tuttavia, di impostareFallthroughOnErroratruee in base al caso d'uso, esegui una delle seguenti operazioni:

  • Se in alcuni casi una variabile a cui si sta accedendo non esiste, utilizzare il valore diDefaulte addizionaleChoicesBlocca per specificare lo stato successivo.

  • Se una variabile a cui si accede deve sempre esistere, impostare ilDefaulta statiFail.

Parallel

LaParallelstate consente di definire ed eseguire nuove macchine a stato parallel l'una con l'altra.

{ "Type": "Parallel", "Next": "<state-name>", "Branches": [ <state-machine-definition> ] }

Tutti i campi che includono valori sono obbligatori, come descritto di seguito:

Next

Il nome dello stato al quale passare dopo l'esecuzione delle azioni nello stato corrente.

Branches

Un array di definizioni delle macchine statali da eseguire. Ogni definizione della macchina a stati deve contenere una propriaStartAt,Succeed, eFailstati. Le definizioni della macchina di stato in questo array non possono fare riferimento a stati al di fuori della propria definizione.

Nota

Poiché ogni macchina a stato di ramo condivide lo stesso contesto macchina a stato, l'impostazione di variabili in un ramo e quindi la lettura di tali variabili da un altro ramo potrebbe comportare un comportamento imprevisto.

LaParallelstato si sposta allo stato successivo solo dopo aver eseguito tutte le macchine dello stato del ramo. Ogni stato che richiede un dispositivo aspetterà l'esecuzione fino a quando il dispositivo non sarà disponibile. Se sono disponibili più dispositivi, questo stato esegue i test case di più gruppi in parallel. Se non sono disponibili dispositivi sufficienti, i test case verranno eseguiti in sequenza. Poiché i test case vengono eseguiti in ordine casuale quando vengono eseguiti in parallel, è possibile utilizzare dispositivi diversi per eseguire test dello stesso gruppo di test.

Gestione errori

Assicurarsi che sia la macchina a stato di diramazione che la macchina a stato padre passino alFailstato per gestire gli errori di esecuzione.

Poiché le macchine a stato di diramazione non trasmettono errori di esecuzione alla macchina a stato padre, non è possibile utilizzare unCatchblocco per gestire gli errori di esecuzione nelle macchine a stato di filiale. Utilizza invecehasExecutionErrorsvalore nel contesto della macchina a stato condiviso. Per un esempio su come eseguire tale operazione, consultaEsempio della macchina a stati: Esegui due gruppi di test in parallel.

Aggiungi caratteristiche del prodotto

LaAddProductFeaturesstato consente di aggiungere funzionalità del prodotto alawsiotdevicetester_report.xmlfile generato da IDT.

Una funzione di prodotto è costituita da informazioni definite dall'utente su criteri specifici che un dispositivo potrebbe soddisfare. Ad esempio, le ricetteMQTTla funzionalità del prodotto può indicare che il dispositivo pubblica correttamente i messaggi MQTT. Nel report, le funzionalità del prodotto sono impostate comesupported,not-supportedo un valore personalizzato, in base al superamento dei test specificati.

Nota

LaAddProductFeaturesstato non genera rapporti da solo. Questo stato deve passare alReportstateper generare report.

{ "Type": "Parallel", "Next": "<state-name>", "Features": [ { "Feature": "<feature-name>", "Groups": [ "<group-id>" ], "OneOfGroups": [ "<group-id>" ], "TestCases": [ "<test-id>" ], "IsRequired": true | false, "ExecutionMethods": [ "<execution-method>" ] } ] }

Tutti i campi che includono valori sono obbligatori, come descritto di seguito:

Next

Il nome dello stato al quale passare dopo l'esecuzione delle azioni nello stato corrente.

Features

Una serie di funzionalità del prodotto da mostrare nellaawsiotdevicetester_report.xmlfile.

Feature

Il nome della caratteristica

FeatureValue

Facoltativo. Il valore personalizzato da utilizzare nel report anzichésupported. Se questo valore non è specificato, in base ai risultati del test, il valore della feature viene impostato susupportedonot-supported.

Se si utilizza un valore personalizzato perFeatureValue, è possibile testare la stessa funzionalità con condizioni diverse e IDT concatena i valori delle feature per le condizioni supportate. Ad esempio, il seguente estratto mostra ilMyFeaturefeature con due valori di feature separati:

... { "Feature": "MyFeature", "FeatureValue": "first-feature-supported", "Groups": ["first-feature-group"] }, { "Feature": "MyFeature", "FeatureValue": "second-feature-supported", "Groups": ["second-feature-group"] }, ...

Se entrambi i gruppi di test passano, il valore della feature è impostato sufirst-feature-supported, second-feature-supported.

Groups

Facoltativo. Un array di ID del gruppo di test. Tutti i test all'interno di ciascun gruppo di test specificato devono essere superati per supportare la funzionalità.

OneOfGroups

Facoltativo. Un array di ID del gruppo di test. Tutti i test all'interno di almeno uno dei gruppi di test specificati devono essere superati affinché la funzionalità sia supportata.

TestCases

Facoltativo. Un array di ID del test case. Se si specifica questo valore, si applica quanto segue:

  • Tutti i test case specificati devono essere passati per supportare la funzionalità.

  • Groupsdeve contenere un solo ID del gruppo di test.

  • OneOfGroupsnon deve essere specificato.

IsRequired

Facoltativo. Impostare sufalseper contrassegnare questa funzione come funzione facoltativa nel report. Il valore di default è true.

ExecutionMethods

Facoltativo. Un array di metodi di esecuzione che corrispondono alprotocolvalore specificato neldevice.jsonfile. Se questo valore è specificato, i test runner devono specificare unprotocolvalore che corrisponde a uno dei valori di questa matrice per includere la feature nel report. Se questo valore non viene specificato, la funzione verrà sempre inclusa nel report.

Per utilizzare il pluginAddProductFeaturesstato, è necessario impostare il valore diResultVarnellaRunTaskState su uno dei seguenti valori:

  • Se sono stati specificati i singoli ID del test case, impostareResultVaragroup-id_test-id_passed.

  • Se non sono stati specificati singoli ID test case, impostareResultVaragroup-id_passed.

LaAddProductFeaturesVerifica dello stato dei risultati dei test nel modo seguente:

  • Se non è stato specificato alcun ID del test case, il risultato per ciascun gruppo di test viene determinato dal valore delgroup-id_passedvariabile nel contesto della macchina a stato.

  • Se hai specificato gli ID del test case, il risultato per ciascuno dei test viene determinato dal valore delgroup-id_test-id_passedvariabile nel contesto della macchina a stato.

Gestione errori

Se un ID di gruppo fornito in questo stato non è un ID di gruppo valido, questo stato si traduce nellaAddProductFeaturesErrorErrore di esecuzione. Se lo stato rileva un errore di esecuzione, imposta anche ilhasExecutionErrorsvariabile nel contesto della macchina a statotrue.

Report

LaReportlo stato genera ilsuite-name_Report.xmleawsiotdevicetester_report.xmlfile. Questo stato trasmette anche il report sulla console.

{ "Type": "Report", "Next": "<state-name>" }

Tutti i campi che includono valori sono obbligatori, come descritto di seguito:

Next

Il nome dello stato al quale passare dopo l'esecuzione delle azioni nello stato corrente.

Dovresti sempre passare alReportstato verso la fine del flusso di esecuzione del test in modo che i test runner possano visualizzare i risultati del test. In genere, lo stato successivo dopo questo stato èSucceed.

Gestione errori

Se questo stato incontra problemi con la generazione dei report, emette ilReportErrorErrore di esecuzione.

Messaggio di log

LaLogMessagelo stato genera iltest_manager.logFile e trasmette il messaggio di log alla console.

{ "Type": "LogMessage", "Next": "<state-name>" "Level": "info | warn | error" "Message": "<message>" }

Tutti i campi che includono valori sono obbligatori, come descritto di seguito:

Next

Il nome dello stato al quale passare dopo l'esecuzione delle azioni nello stato corrente.

Level

Il livello di errore al quale creare il messaggio di registro. Se si specifica un livello non valido, questo stato genera un messaggio di errore e lo scarta.

Message

Il messaggio da registrare.

Seleziona gruppo

LaSelectGroupstate aggiorna il contesto della macchina statale per indicare quali gruppi sono selezionati. I valori impostati da questo stato vengono utilizzati da qualsiasi successivoChoicestati.

{ "Type": "SelectGroup", "Next": "<state-name>" "TestGroups": [ <group-id>" ] }

Tutti i campi che includono valori sono obbligatori, come descritto di seguito:

Next

Il nome dello stato al quale passare dopo l'esecuzione delle azioni nello stato corrente.

TestGroups

Una serie di gruppi di test che verranno contrassegnati come selezionati. Per ogni ID gruppo di test in questo array, ilgroup-id_selectedvariabile è impostata sutruenel contesto. Assicurati di fornire ID del gruppo di test validi perché IDT non convalida se esistono i gruppi specificati.

Fail

LaFailstato indica che la macchina a stato non è stata eseguita correttamente. Si tratta di uno stato finale per la macchina a stato e ogni definizione della macchina a stato deve includere questo stato.

{ "Type": "Fail" }

Succeed

LaSucceedstato indica che la macchina a stato è stata eseguita correttamente. Si tratta di uno stato finale per la macchina a stato e ogni definizione della macchina a stato deve includere questo stato.

{ "Type": "Succeed" }

Contesto della macchina a stati

Il contesto macchina a stato è un documento JSON di sola lettura che contiene dati disponibili per la macchina a stato durante l'esecuzione. Il contesto della macchina a stato è accessibile solo dalla macchina a stato e contiene informazioni che determinano il flusso di test. Ad esempio, è possibile utilizzare le informazioni configurate dai test runner neluserdata.jsonfile per determinare se è necessario eseguire un test specifico.

Il contesto della macchina a stati utilizza il seguente formato:

{ "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

Informazioni sul pool di dispositivi selezionato per l'esecuzione del test. Per un pool di dispositivi selezionato, queste informazioni vengono recuperate dall'elemento dell'array del pool di dispositivi di livello superiore corrispondente definito neldevice.jsonfile.

userData

Informazioni neluserdata.jsonfile.

config

Informazioni di pinconfig.jsonfile.

suiteFailed

Il valore è impostato sufalseQuando si avvia la macchina a stati. Se un gruppo di test fallisce in unRunTaskstato, quindi questo valore è impostato sutrueper la durata rimanente dell'esecuzione della macchina a stati.

specificTestGroups

Se il test runner seleziona gruppi di test specifici da eseguire al posto dell'intera suite di test, questa chiave viene creata e contiene l'elenco di ID specifici del gruppo di test.

specificTestCases

Se il test runner seleziona casi di test specifici da eseguire al posto dell'intera suite di test, questa chiave viene creata e contiene l'elenco degli ID del test case specifici.

hasExecutionErrors

Non esce all'avvio della macchina a stato. Se uno stato incontra errori di esecuzione, questa variabile viene creata e impostata sutrueper la durata rimanente dell'esecuzione della macchina a stati.

È possibile eseguire una query sul contesto utilizzando la notazione JsonPath. La sintassi per le query JsonPath nelle definizioni di stato è{{$.query}}. È possibile utilizzare le query JsonPath come stringhe segnaposto all'interno di alcuni stati. IDT sostituisce le stringhe segnaposto con il valore della query JsonPath valutata dal contesto. È possibile utilizzare segnaposto per i seguenti valori:

  • LaTestCasesvalore inRunTaskstati.

  • LaExpressionvaloreChoiceStato.

Quando accedi ai dati dal contesto della macchina a stati, verifica che siano soddisfatte le seguenti condizioni:

  • I percorsi JSON devono iniziare con$.

  • Ogni valore deve essere valutato in una stringa, un numero o un valore booleano.

Per ulteriori informazioni sull'utilizzo della notazione JsonPath per l'accesso ai dati dal contesto, consultaUsa il contesto IDT.

Errori di esecuzione

Gli errori di esecuzione sono errori nella definizione della macchina a stato rilevata dalla macchina a stato durante l'esecuzione di uno stato. IDT registra le informazioni su ogni errore neltest_manager.logFile e trasmette il messaggio di log alla console.

È possibile utilizzare i seguenti metodi per gestire gli errori di esecuzione:

Cattura

Per utilizzareCatch, aggiungi quanto segue alla tua definizione di stato:

"Catch": [ { "ErrorEquals": [ "<error-type>" ] "Next": "<state-name>" } ]

Tutti i campi che includono valori sono obbligatori, come descritto di seguito:

Catch.ErrorEquals

Un array di tipi di errore da catch. Se un errore di esecuzione corrisponde a uno dei valori specificati, la macchina a stati passa allo stato specificato inCatch.Next. Vedere ciascuna definizione di stato per informazioni sul tipo di errore che produce.

Catch.Next

Lo stato successivo a cui passare se lo stato corrente rileva un errore di esecuzione corrispondente a uno dei valori specificati inCatch.ErrorEquals.

I blocchi di cattura vengono gestiti in sequenza fino a quando uno corrisponde. Se gli errori non corrispondono a quelli elencati nei blocchi Catch, le macchine a stato continuano ad essere eseguite. Poiché gli errori di esecuzione sono il risultato di definizioni di stato errate, si consiglia di passare allo stato Fail quando uno stato incontra un errore di esecuzione.

Errore di esecuzione

Quando alcuni stati incontrano errori di esecuzione, oltre a emettere l'errore, impostano anche ilhasExecutionErrorvalore atruenel contesto della macchina a stati. È possibile utilizzare questo valore per rilevare quando si verifica un errore e quindi utilizzare unChoicestato per la transizione della macchina statale alFailStato.

Questo metodo presenta le seguenti caratteristiche.

  • La macchina a stato non inizia con alcun valore assegnato ahasExecutionErrore questo valore non è disponibile fino a quando uno stato particolare non lo imposta. Ciò significa che è necessario impostare esplicitamente ilFallthroughOnErrorafalseperChoiceafferma che accede a questo valore per impedire l'arresto della macchina a stato se non si verificano errori di esecuzione.

  • Una volta impostato sutrue,hasExecutionErrornon è mai impostato su false o rimosso dal contesto. Ciò significa che questo valore è utile solo la prima volta che viene impostato sutruee per tutti gli stati successivi, non fornisce un valore significativo.

  • LahasExecutionErroril valore è condiviso con tutte le macchine a stato di diramazione nellaParallelstato, che può portare a risultati imprevisti a seconda dell'ordine in cui si accede.

A causa di queste caratteristiche, non è consigliabile utilizzare questo metodo se è possibile utilizzare invece un blocco Catch.

Esempio delle macchine a stati

Questa sezione fornisce alcuni esempi di configurazioni della macchina a stati.

Esempio della macchina a stati: Esegui un singolo gruppo di test

Questa macchina a stati:

  • Esegue il gruppo di test con idGroupA, che deve essere presente nella suite in ungroup.jsonfile.

  • Verifica la presenza di errori di esecuzione e transizioni aFailse ne vengono trovati.

  • Genera un report e transizioni aSucceedse non ci sono errori eFailIn caso contrario, .

{ "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" } } }

Esempio della macchina a stati: Esegui gruppi di test selezionati dall'utente

Questa macchina a stati:

  • Verifica se il corridore di prova ha selezionato gruppi di test specifici. La macchina a stato non verifica la presenza di casi di prova specifici perché i test runner non possono selezionare i test case senza selezionare anche un gruppo di test.

  • Se sono selezionati gruppi di test:

    • Esegue i test case all'interno dei gruppi di test selezionati. A tale scopo, la macchina a stato non specifica esplicitamente alcun gruppo di test o test case nelRunTaskStato.

    • Genera un report dopo aver eseguito tutti i test e le uscite.

  • Se i gruppi di test non sono selezionati:

    • Esegue test nel gruppo di testGroupA.

    • Genera report ed uscite.

{ "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" } } }

Esempio della macchina a stati: Esegui un singolo gruppo di test con caratteristiche del prodotto

Questa macchina a stati:

  • Esegue il gruppo di testGroupA.

  • Verifica la presenza di errori di esecuzione e transizioni aFailse ne vengono trovati.

  • Aggiunge ilFeatureThatDependsOnGroupAfunzionalità per ilawsiotdevicetester_report.xmlfile:

    • SeGroupApassa, la funzione è impostata susupported.

    • La funzione non è contrassegnata come facoltativa nel report.

  • Genera un report e transizioni aSucceedse non ci sono errori eFailaltrimenti

{ "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" } } }

Esempio della macchina a stati: Esegui due gruppi di test in parallel

Questa macchina a stati:

  • EsegueGroupAeGroupBgruppi di test in parallel. LaResultVarvariabili memorizzate nel contesto dalRunTaskgli stati nelle macchine dello stato di filiale sono disponibili per ilAddProductFeaturesStato.

  • Verifica la presenza di errori di esecuzione e transizioni aFailse ne vengono trovati. Questa macchina a stato non utilizza unCatchblocco perché tale metodo non rileva errori di esecuzione nelle macchine a stato di diramazione.

  • Aggiunge funzionalità alawsiotdevicetester_report.xmlfile basato sui gruppi che passano

    • SeGroupApassa, la caratteristica è impostata susupported.

    • La funzione non è contrassegnata come facoltativa nel report.

  • Genera un report e transizioni aSucceedse non ci sono errori eFailaltrimenti

Se nel pool di dispositivi sono configurati due dispositivi, entrambiGroupAeGroupBpuò funzionare nello stesso momento. Tuttavia, se uno dei dueGroupAoGroupBcontiene più test, quindi entrambi i dispositivi possono essere assegnati a tali test. Se è configurato un solo dispositivo, i gruppi di test verranno eseguiti in sequenza.

{ "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" } } }