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 essere
Succeed
oFail
.
Formato macchina a stati
Puoi utilizzare il seguente modello per configurarne uno
file: <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" } } }
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 di
StartAt
deve essere impostato su uno degli stati elencati nellaStates
oggetto. States
-
Oggetto che mappa i nomi di stato definiti dall'utente a stati IDT validi. Ciascuno stato.
nome stato
object contiene la definizione di uno stato valido mappato alnome stato
.La
States
l'oggetto deve includere ilSucceed
eFail
stati. 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.
Definizioni di stato
RunTask
LaRunTask
Lo 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 in
TestGroup
. In base ai valori diTestGroup
eTestCases
, IDT determina il comportamento di esecuzione del test come segue:-
Quando entrambi
TestGroup
eTestCases
sono specificati, IDT esegue i test case specificati dal gruppo di test. -
Quando
TestCases
sono specificati maTestGroup
non è specificato, IDT esegue i test case specificati. -
Quando
TestGroup
è specificato, maTestCases
Non è specificato, IDT esegue tutti i test case all'interno del gruppo di test specificato. -
Quando nessuno dei due
TestGroup
oTestCases
è 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 entrambiRunTask
eChoice
stati nel tuostatemachine.json
file. 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 per
TestGroup
. IDT imposta il valore della variabile definita inResultVar
atrue
ofalse
in base a quanto segue:-
Se il nome della variabile è del modulo
, quindi il valore viene impostato su se tutti i test del primo gruppo di test sono passati o sono stati saltati.text
_text
_passed -
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 utilizzaRunTask
stato 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 ilRunTaskError
Errore di esecuzione. Se lo stato rileva un errore di esecuzione, imposta anche ilhasExecutionError
variabile nel contesto della macchina a statotrue
.
Choice
LaChoice
state 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 in
Choices
può essere valutato pertrue
. FallthroughOnError
-
Facoltativo. Specifica il comportamento quando lo stato rileva un errore nella valutazione delle espressioni. Impostare su
true
se si desidera saltare un'espressione se la valutazione genera un errore. Se nessuna espressione corrisponde, la macchina a stati passa allaDefault
Stato. Se il fileFallthroughOnError
Il 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 valutata
true
, 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 in
Choices.Expression
valuta atrue
.
Gestione errori
LaChoice
stato 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 unCatch
Blocca per gestire gli errori in questo stato. Se si desidera interrompere l'esecuzione della macchina a stato quando viene rilevato un errore, è necessario impostareFallthroughOnError
afalse
. Consigliamo, tuttavia, di impostareFallthroughOnError
atrue
e 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 di
Default
e addizionaleChoices
Blocca per specificare lo stato successivo. -
Se una variabile a cui si accede deve sempre esistere, impostare il
Default
a statiFail
.
Parallel
LaParallel
state 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 propria
StartAt
,Succeed
, eFail
stati. 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.
LaParallel
stato 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 alFail
stato 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 unCatch
blocco per gestire gli errori di esecuzione nelle macchine a stato di filiale. Utilizza invecehasExecutionErrors
valore 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
LaAddProductFeatures
stato consente di aggiungere funzionalità del prodotto alawsiotdevicetester_report.xml
file generato da IDT.
Una funzione di prodotto è costituita da informazioni definite dall'utente su criteri specifici che un dispositivo potrebbe soddisfare. Ad esempio, le ricetteMQTT
la funzionalità del prodotto può indicare che il dispositivo pubblica correttamente i messaggi MQTT. Nel report, le funzionalità del prodotto sono impostate comesupported
,not-supported
o un valore personalizzato, in base al superamento dei test specificati.
Nota
LaAddProductFeatures
stato 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 nella
awsiotdevicetester_report.xml
file.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 susupported
onot-supported
.Se si utilizza un valore personalizzato per
FeatureValue
, è 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 ilMyFeature
feature 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 su
first-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à.
-
Groups
deve contenere un solo ID del gruppo di test. -
OneOfGroups
non deve essere specificato.
-
IsRequired
-
Facoltativo. Impostare su
false
per contrassegnare questa funzione come funzione facoltativa nel report. Il valore di default ètrue
. ExecutionMethods
-
Facoltativo. Un array di metodi di esecuzione che corrispondono al
protocol
valore specificato neldevice.json
file. Se questo valore è specificato, i test runner devono specificare unprotocol
valore 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 pluginAddProductFeatures
stato, è necessario impostare il valore diResultVar
nellaRunTask
State su uno dei seguenti valori:
-
Se sono stati specificati i singoli ID del test case, impostare
ResultVar
a
.group-id_test-id
_passed -
Se non sono stati specificati singoli ID test case, impostare
ResultVar
a
.group-id
_passed
LaAddProductFeatures
Verifica 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 del
variabile nel contesto della macchina a stato.group-id
_passed -
Se hai specificato gli ID del test case, il risultato per ciascuno dei test viene determinato dal valore del
variabile nel contesto della macchina a stato.group-id_test-id
_passed
Gestione errori
Se un ID di gruppo fornito in questo stato non è un ID di gruppo valido, questo stato si traduce nellaAddProductFeaturesError
Errore di esecuzione. Se lo stato rileva un errore di esecuzione, imposta anche ilhasExecutionErrors
variabile nel contesto della macchina a statotrue
.
Report
LaReport
lo stato genera il
esuite-name
_Report.xmlawsiotdevicetester_report.xml
file. 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 alReport
stato 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 ilReportError
Errore di esecuzione.
Messaggio di log
LaLogMessage
lo stato genera iltest_manager.log
File 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
LaSelectGroup
state aggiorna il contesto della macchina statale per indicare quali gruppi sono selezionati. I valori impostati da questo stato vengono utilizzati da qualsiasi successivoChoice
stati.
{ "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, il
variabile è impostata sugroup-id
_selectedtrue
nel contesto. Assicurati di fornire ID del gruppo di test validi perché IDT non convalida se esistono i gruppi specificati.
Fail
LaFail
stato 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
LaSucceed
stato 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.json
file 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 nel
device.json
file. userData
-
Informazioni nel
userdata.json
file. config
-
Informazioni di pin
config.json
file. suiteFailed
-
Il valore è impostato su
false
Quando si avvia la macchina a stati. Se un gruppo di test fallisce in unRunTask
stato, quindi questo valore è impostato sutrue
per 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 su
true
per 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 è{{$.
. È 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:query
}}
-
La
TestCases
valore inRunTask
stati. -
La
Expression
valoreChoice
Stato.
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.log
File e trasmette il messaggio di log alla console.
È possibile utilizzare i seguenti metodi per gestire gli errori di esecuzione:
-
Aggiungi unCatchbloccarenella definizione dello stato.
-
Verificare il valore dihasExecutionErrorsvalorenel contesto della macchina a stati.
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 in
Catch.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 in
Catch.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 ilhasExecutionError
valore atrue
nel contesto della macchina a stati. È possibile utilizzare questo valore per rilevare quando si verifica un errore e quindi utilizzare unChoice
stato per la transizione della macchina statale alFail
Stato.
Questo metodo presenta le seguenti caratteristiche.
-
La macchina a stato non inizia con alcun valore assegnato a
hasExecutionError
e questo valore non è disponibile fino a quando uno stato particolare non lo imposta. Ciò significa che è necessario impostare esplicitamente ilFallthroughOnError
afalse
perChoice
afferma che accede a questo valore per impedire l'arresto della macchina a stato se non si verificano errori di esecuzione. -
Una volta impostato su
true
,hasExecutionError
non è mai impostato su false o rimosso dal contesto. Ciò significa che questo valore è utile solo la prima volta che viene impostato sutrue
e per tutti gli stati successivi, non fornisce un valore significativo. -
La
hasExecutionError
il valore è condiviso con tutte le macchine a stato di diramazione nellaParallel
stato, 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.
Esempi
- Esempio della macchina a stati: Esegui un singolo gruppo di test
- Esempio della macchina a stati: Esegui gruppi di test selezionati dall'utente
- Esempio della macchina a stati: Esegui un singolo gruppo di test con caratteristiche del prodotto
- Esempio della macchina a stati: Esegui due gruppi di test in parallel
Esempio della macchina a stati: Esegui un singolo gruppo di test
Questa macchina a stati:
-
Esegue il gruppo di test con id
GroupA
, che deve essere presente nella suite in ungroup.json
file. -
Verifica la presenza di errori di esecuzione e transizioni a
Fail
se ne vengono trovati. -
Genera un report e transizioni a
Succeed
se non ci sono errori eFail
In 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 nel
RunTask
Stato. -
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 test
GroupA
. -
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 test
GroupA
. -
Verifica la presenza di errori di esecuzione e transizioni a
Fail
se ne vengono trovati. -
Aggiunge il
FeatureThatDependsOnGroupA
funzionalità per ilawsiotdevicetester_report.xml
file:-
Se
GroupA
passa, la funzione è impostata susupported
. -
La funzione non è contrassegnata come facoltativa nel report.
-
-
Genera un report e transizioni a
Succeed
se non ci sono errori eFail
altrimenti
{ "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:
-
Esegue
GroupA
eGroupB
gruppi di test in parallel. LaResultVar
variabili memorizzate nel contesto dalRunTask
gli stati nelle macchine dello stato di filiale sono disponibili per ilAddProductFeatures
Stato. -
Verifica la presenza di errori di esecuzione e transizioni a
Fail
se ne vengono trovati. Questa macchina a stato non utilizza unCatch
blocco perché tale metodo non rileva errori di esecuzione nelle macchine a stato di diramazione. -
Aggiunge funzionalità al
awsiotdevicetester_report.xml
file basato sui gruppi che passano-
Se
GroupA
passa, la caratteristica è impostata susupported
. -
La funzione non è contrassegnata come facoltativa nel report.
-
-
Genera un report e transizioni a
Succeed
se non ci sono errori eFail
altrimenti
Se nel pool di dispositivi sono configurati due dispositivi, entrambiGroupA
eGroupB
può funzionare nello stesso momento. Tuttavia, se uno dei dueGroupA
oGroupB
contiene 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" } } }