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à.
# Configurare la macchina a stati IDT
**Importante**
A partire da IDT v4.5.1, questa macchina a stati è obsoleta. Ti consigliamo vivamente di utilizzare il nuovo orchestrator di test. Per ulteriori informazioni, consulta [Configurare l'orchestrator di test IDT](idt-test-orchestrator.md).
Una macchina a stati è 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 la transizione attraverso tali stati fino a raggiungere lo stato finale.
Se la vostra suite di test non include una macchina a stati definita dall'utente, IDT genererà una macchina a stati per voi. La macchina a stati predefinita 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 ogni gruppo di test nella suite di test in ordine casuale.
+ Genera report e stampa un riepilogo della console che mostra i risultati dei test per ogni gruppo di test e test case.
La macchina a stati per una suite di test IDT deve soddisfare i seguenti criteri:
+ Ogni stato corrisponde a un'azione che IDT deve intraprendere, ad esempio eseguire un gruppo di test o produrre un file di report.
+ La transizione a uno stato esegue l'azione associata allo stato.
+ Ogni stato definisce la regola di transizione per lo stato successivo.
+ Lo stato finale deve essere `Succeed` o`Fail`.
## Formato macchina a stati
È possibile utilizzare il seguente modello per configurare il proprio `/suite/state_machine.json` file:
```
{
"Comment": "",
"StartAt": "",
"States": {
"": {
"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 nell'`States`oggetto.
`States`
Un oggetto che associa i nomi di stato definiti dall'utente a stati IDT validi. Ogni stato. *state-name*l'oggetto contiene la definizione di uno stato valido mappato su. *state-name*
L'`States`oggetto deve includere gli `Fail` stati `Succeed` e. Per informazioni sugli stati validi, vedere[Stati e definizioni di stato validi](#valid-states).
## 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 stati IDT. Alcuni dei seguenti stati supportano configurazioni a livello di test case. Tuttavia, si consiglia di configurare le regole di transizione degli stati a livello di gruppo di test anziché a livello di test case, a meno che non sia assolutamente necessario.
**Topics**
+ [RunTask](#state-runtask)
+ [Choice](#state-choice)
+ [Parallel](#state-parallel)
+ [AddProductFeatures](#state-addproductfeatures)
+ [Report](#state-report)
+ [LogMessage](#state-logmessage)
+ [SelectGroup](#state-selectgroup)
+ [Fail](#state-fail)
+ [Succeed](#state-succeed)
### RunTask
Lo `RunTask` stato esegue casi di test da un gruppo di test definito nella suite di test.
```
{
"Type": "RunTask",
"Next": "",
"TestGroup": "",
"TestCases": [
""
],
"ResultVar": ""
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
`Next`
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
`TestGroup`
Opzionale. L'ID del gruppo di test da eseguire. Se questo valore non è specificato, IDT esegue il gruppo di test selezionato dal test runner.
`TestCases`
Opzionale. Una serie di test case del gruppo IDs specificato in. `TestGroup` In base ai valori di `TestGroup` and`TestCases`, IDT determina il comportamento di esecuzione del test nel modo seguente:
+ Quando `TestCases` vengono specificati entrambi gli `TestGroup` E, IDT esegue i casi di test specificati dal gruppo di test.
+ Quando `TestCases` sono specificati ma non `TestGroup` sono specificati, IDT esegue i casi di test specificati.
+ Quando `TestGroup` è specificato, ma non `TestCases` è specificato, IDT esegue tutti i casi di test all'interno del gruppo di test specificato.
+ Quando nessuno dei due `TestGroup` `TestCases` è specificato, IDT esegue tutti i casi di test dal gruppo di test selezionato dal test runner dalla CLI IDT. Per abilitare la selezione di gruppo per i test runner, è necessario includere entrambi `RunTask` gli stati nel file. `Choice` `state_machine.json` Per un esempio di come funziona, vedi [Example state machine: Esegui gruppi di test selezionati dall'utente](#allow-specific-groups).
Per ulteriori informazioni sull'abilitazione dei comandi CLI IDT per i test runner, vedere. [Abilita i comandi CLI IDT](create-test-executables.md#idt-cli-coop)
`ResultVar`
Il nome della variabile di contesto da impostare con i risultati dell'esecuzione del test. Non specificate questo valore se non avete specificato un valore per`TestGroup`. IDT imposta il valore della variabile definita in `true` o in `false` base `ResultVar` a quanto segue:
+ Se il nome della variabile è nel formato`text_text_passed`, il valore viene impostato in base al fatto che tutti i test del primo gruppo di test siano stati superati o ignorati.
+ In tutti gli altri casi, il valore è impostato in base al fatto che tutti i test di tutti i gruppi di test siano stati superati o saltati.
In genere, si utilizza `RunTask` lo stato per specificare un ID del gruppo di test senza specificare il singolo test case IDs, in modo che IDT esegua tutti i casi di test nel gruppo di test specificato. Tutti i casi di test eseguiti da questo stato vengono eseguiti in parallelo, in ordine casuale. Tuttavia, se tutti i casi di test richiedono l'esecuzione di un dispositivo ed è disponibile un solo dispositivo, i test case verranno invece eseguiti in sequenza.
**Gestione errori**
Se uno dei gruppi di test o dei test case IDs specificati non è valido, questo stato genera l'errore di `RunTaskError` esecuzione. Se lo stato rileva un errore di esecuzione, imposta anche la `hasExecutionError` variabile nel contesto della macchina a stati su. `true`
### Choice
Lo `Choice` stato consente di impostare dinamicamente lo stato successivo a cui passare in base a condizioni definite dall'utente.
```
{
"Type": "Choice",
"Default": "",
"FallthroughOnError": true | false,
"Choices": [
{
"Expression": "",
"Next": ""
}
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
`Default`
Lo stato predefinito a cui passare se nessuna delle espressioni definite in `Choices` può essere valutata. `true`
`FallthroughOnError`
Opzionale. Speciifica il comportamento quando lo stato rileva un errore nella valutazione delle espressioni. Imposta su `true` se desideri saltare un'espressione se la valutazione genera un errore. Se nessuna espressione corrisponde, la macchina a stati passa allo `Default` stato. Se il `FallthroughOnError` valore non è specificato, il valore predefinito è. `false`
`Choices`
Un array di espressioni e stati per determinare a quale stato passare dopo aver eseguito le azioni nello stato corrente.
`Choices.Expression`
Una stringa di espressione che restituisce un valore booleano. Se l'espressione restituisce a`true`, la macchina a stati passa allo stato definito in. `Choices.Next` Le stringhe di espressione recuperano i valori dal contesto della macchina a stati e quindi eseguono operazioni su di essi per ottenere un valore booleano. Per informazioni sull'accesso al contesto della macchina a stati, vedere. [Contesto della macchina a stati](#state-machine-context)
`Choices.Next`
Il nome dello stato a cui passare se l'espressione definita in `Choices.Expression` restituisce. `true`
**Gestione errori**
Lo `Choice` stato può richiedere la gestione degli errori nei seguenti casi:
+ Alcune variabili nelle espressioni di scelta non esistono nel contesto della macchina a stati.
+ 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 un `Catch` blocco per gestire gli errori in questo stato. Se si desidera interrompere l'esecuzione della macchina a stati quando rileva un errore, è necessario impostare su`FallthroughOnError`. `false` Tuttavia, ti consigliamo di impostare e`true`, `FallthroughOnError` a seconda del caso d'uso, di eseguire una delle seguenti operazioni:
+ Se in alcuni casi si prevede che una variabile a cui stai accedendo non esista, utilizza il valore `Default` e i `Choices` blocchi aggiuntivi per specificare lo stato successivo.
+ Se una variabile a cui stai accedendo deve sempre esistere, imposta lo `Default` stato su`Fail`.
### Parallel
Lo `Parallel` stato consente di definire ed eseguire nuove macchine a stati in parallelo tra loro.
```
{
"Type": "Parallel",
"Next": "",
"Branches": [
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
`Next`
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
`Branches`
Una serie di definizioni di macchine a stati da eseguire. Ogni definizione di macchina a stati deve contenere `StartAt` `Succeed` i propri `Fail` stati. Le definizioni delle macchine a stati in questo array non possono fare riferimento a stati al di fuori della propria definizione.
Poiché ogni macchina a stati della filiale condivide lo stesso contesto della macchina a stati, l'impostazione delle variabili in un ramo e la successiva lettura di tali variabili da un altro ramo potrebbe causare un comportamento imprevisto.
Lo `Parallel` stato passa allo stato successivo solo dopo aver eseguito tutte le macchine a stati della filiale. Ogni stato che richiede un dispositivo aspetterà di funzionare finché il dispositivo non sarà disponibile. Se sono disponibili più dispositivi, questo stato esegue casi di test da più gruppi in parallelo. Se non sono disponibili dispositivi sufficienti, i test case verranno eseguiti in sequenza. Poiché i casi di test vengono eseguiti in ordine casuale quando vengono eseguiti in parallelo, è possibile utilizzare dispositivi diversi per eseguire i test dello stesso gruppo di test.
**Gestione errori**
Assicurati che sia la macchina a stati della filiale che la macchina a stati principale passino allo `Fail` stato per gestire gli errori di esecuzione.
Poiché le macchine a stato della filiale non trasmettono errori di esecuzione alla macchina a stato principale, non è possibile utilizzare un `Catch` blocco per gestire gli errori di esecuzione nelle macchine a stato filiale. Utilizzate invece il `hasExecutionErrors` valore nel contesto della macchina a stati condivisa. Per un esempio di come funziona, vedi[Esempio di macchina a stati: esecuzione di due gruppi di test in parallelo](#run-in-parallel).
### AddProductFeatures
Lo `AddProductFeatures` stato consente di aggiungere funzionalità del prodotto al `awsiotdevicetester_report.xml` file generato da IDT.
Una funzionalità del prodotto è costituita da informazioni definite dall'utente su criteri specifici che un dispositivo potrebbe soddisfare. Ad esempio, la funzionalità del `MQTT` prodotto può indicare che il dispositivo pubblica correttamente i messaggi MQTT. Nel rapporto, le caratteristiche del prodotto sono impostate come o come valore personalizzato `supported``not-supported`, in base al superamento dei test specificati.
**Nota**
Lo `AddProductFeatures` stato non genera report da solo. Questo stato deve passare allo [`Report`stato](#state-report) per generare report.
```
{
"Type": "Parallel",
"Next": "",
"Features": [
{
"Feature": "",
"Groups": [
""
],
"OneOfGroups": [
""
],
"TestCases": [
""
],
"IsRequired": true | false,
"ExecutionMethods": [
""
]
}
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
`Next`
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
`Features`
Una serie di caratteristiche del prodotto da mostrare nel `awsiotdevicetester_report.xml` file.
`Feature`
Il nome della funzionalità
`FeatureValue`
Opzionale. Il valore personalizzato da utilizzare nel rapporto anziché`supported`. Se questo valore non è specificato, in base ai risultati del test, il valore della funzionalità viene impostato su `supported` o`not-supported`.
Se utilizzate un valore personalizzato per`FeatureValue`, potete testare la stessa funzionalità con condizioni diverse e IDT concatena i valori delle caratteristiche per le condizioni supportate. Ad esempio, il seguente estratto mostra la funzionalità con due valori di `MyFeature` funzionalità 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 superano il test, il valore della funzionalità viene impostato su. `first-feature-supported, second-feature-supported`
`Groups`
Opzionale. Una serie di gruppi di test IDs. Tutti i test all'interno di ogni gruppo di test specificato devono essere superati affinché la funzionalità sia supportata.
`OneOfGroups`
Opzionale. Una serie di gruppi di test IDs. Tutti i test all'interno di almeno uno dei gruppi di test specificati devono essere superati affinché la funzionalità sia supportata.
`TestCases`
Opzionale. Una serie di test case IDs. Se si specifica questo valore, si applica quanto segue:
+ Tutti i casi di test specificati devono essere superati affinché la funzionalità sia supportata.
+ `Groups`deve contenere un solo ID del gruppo di test.
+ `OneOfGroups`non deve essere specificato.
`IsRequired`
Opzionale. Imposta `false` su per contrassegnare questa funzionalità come opzionale nel rapporto. Il valore predefinito è `true`.
`ExecutionMethods`
Opzionale. Una serie di metodi di esecuzione che corrispondono al `protocol` valore specificato nel `device.json` file. Se viene specificato questo valore, i test runner devono specificare un `protocol` valore che corrisponda a uno dei valori di questo array per includere la funzionalità nel report. Se questo valore non è specificato, la funzionalità verrà sempre inclusa nel rapporto.
Per utilizzare lo `AddProductFeatures` stato, è necessario impostare il valore di `ResultVar` in the `RunTask` state su uno dei seguenti valori:
+ Se hai specificato un singolo test case IDs, imposta `ResultVar` su`group-id_test-id_passed`.
+ Se non hai specificato un singolo test case IDs, imposta `ResultVar` su`group-id_passed`.
Lo `AddProductFeatures` stato verifica i risultati dei test nel modo seguente:
+ Se non è stato specificato alcun test case IDs, il risultato per ogni gruppo di test viene determinato dal valore della `group-id_passed` variabile nel contesto della macchina a stati.
+ Se hai specificato il test case IDs, il risultato di ciascuno dei test viene determinato dal valore della `group-id_test-id_passed` variabile nel contesto della macchina a stati.
**Gestione errori**
Se un ID di gruppo fornito in questo stato non è un ID di gruppo valido, questo stato genera l'errore di `AddProductFeaturesError` esecuzione. Se lo stato rileva un errore di esecuzione, imposta anche la `hasExecutionErrors` variabile nel contesto della macchina a stati su. `true`
### Report
Lo `Report` stato genera i file `suite-name_Report.xml` and`awsiotdevicetester_report.xml`. Questo stato trasmette inoltre il report alla console.
```
{
"Type": "Report",
"Next": ""
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
`Next`
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
Dovresti sempre passare `Report` allo 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 a questo è`Succeed`.
**Gestione errori**
Se questo stato riscontra problemi con la generazione dei report, genera l'errore di `ReportError` esecuzione.
### LogMessage
Lo `LogMessage` stato genera il `test_manager.log` file e trasmette il messaggio di registro alla console.
```
{
"Type": "LogMessage",
"Next": ""
"Level": "info | warn | error"
"Message": ""
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
`Next`
Il nome dello stato a cui 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 elimina.
`Message`
Il messaggio da registrare.
### SelectGroup
Lo `SelectGroup` stato aggiorna il contesto della macchina a stati per indicare quali gruppi sono selezionati. I valori impostati da questo stato vengono utilizzati da tutti `Choice` gli stati successivi.
```
{
"Type": "SelectGroup",
"Next": ""
"TestGroups": [
"
]
}
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
`Next`
Il nome dello stato a cui passare dopo l'esecuzione delle azioni nello stato corrente.
`TestGroups`
Una serie di gruppi di test che verranno contrassegnati come selezionati. Per ogni ID del gruppo di test in questo array, la `group-id_selected` variabile è impostata su `true` nel contesto. Assicuratevi di fornire un gruppo di test valido IDs perché IDT non verifica l'esistenza dei gruppi specificati.
### Fail
Lo `Fail` stato indica che la macchina a stati non è stata eseguita correttamente. Si tratta di uno stato finale per la macchina a stati e ogni definizione di macchina a stati deve includere questo stato.
```
{
"Type": "Fail"
}
```
### Succeed
Lo `Succeed` stato indica che la macchina a stati è stata eseguita correttamente. Si tratta di uno stato finale per la macchina a stati e ogni definizione di macchina a stati deve includere questo stato.
```
{
"Type": "Succeed"
}
```
## Contesto della macchina a stati
Il contesto della macchina a stati è un documento JSON di sola lettura che contiene dati disponibili per la macchina a stati durante l'esecuzione. Il contesto della macchina a stati è accessibile solo dalla macchina a stati e contiene informazioni che determinano il flusso di test. Ad esempio, è possibile utilizzare le informazioni configurate dai test runner nel `userdata.json` file per determinare se è necessario eseguire un test specifico.
Il contesto della macchina a stati utilizza il seguente formato:
```
{
"pool": {
},
"userData": {
},
"config": {
},
"suiteFailed": true | false,
"specificTestGroups": [
""
],
"specificTestCases": [
""
],
"hasExecutionErrors": true
}
```
`pool`
Informazioni sul pool di dispositivi selezionato per l'esecuzione del test. Per un pool di dispositivi selezionato, queste informazioni vengono recuperate dal corrispondente elemento dell'array del pool di dispositivi di primo livello definito nel `device.json` file.
`userData`
Informazioni contenute nel file. `userdata.json`
`config`
Le informazioni bloccano il `config.json` file.
`suiteFailed`
Il valore è impostato su `false` quando viene avviata la macchina a stati. Se un gruppo di test fallisce in uno `RunTask` stato, questo valore viene impostato `true` per la durata residua dell'esecuzione della macchina a stati.
`specificTestGroups`
Se il test runner seleziona gruppi di test specifici da eseguire anziché l'intera suite di test, questa chiave viene creata e contiene l'elenco dei gruppi di test specifici. IDs
`specificTestCases`
Se il test runner seleziona casi di test specifici da eseguire anziché l'intera suite di test, questa chiave viene creata e contiene l'elenco di casi di test specifici. IDs
`hasExecutionErrors`
Non esce all'avvio della macchina a stati. Se uno stato rileva errori di esecuzione, questa variabile viene creata e impostata `true` per la durata residua dell'esecuzione della macchina a stati.
È possibile interrogare il contesto utilizzando JSONPath la notazione. La sintassi per le JSONPath interrogazioni nelle definizioni di stato è. `{{$.query}}` È possibile utilizzare JSONPath le query come stringhe segnaposto in alcuni stati. IDT sostituisce le stringhe segnaposto con il valore della query valutata dal contesto. JSONPath È possibile utilizzare i segnaposto per i seguenti valori:
+ Il `TestCases` valore in `RunTask` stati.
+ Lo `Choice` stato `Expression` del valore.
Quando accedete ai dati dal contesto della macchina a stati, assicuratevi che siano soddisfatte le seguenti condizioni:
+ I percorsi JSON devono iniziare con `$.`
+ Ogni valore deve restituire una stringa, un numero o un valore booleano.
Per ulteriori informazioni sull'utilizzo della JSONPath notazione per accedere ai dati dal contesto, vedere. [Usa il contesto IDT](idt-context.md)
## Errori di esecuzione
Gli errori di esecuzione sono errori nella definizione della macchina a stati che la macchina a stati incontra durante l'esecuzione di uno stato. IDT registra le informazioni su ogni errore nel `test_manager.log` file e trasmette il messaggio di registro alla console.
È possibile utilizzare i seguenti metodi per gestire gli errori di esecuzione:
+ Aggiungere un [`Catch`blocco](#catch) nella definizione dello stato.
+ Controlla il valore del [`hasExecutionErrors`valore](#context) nel contesto della macchina a stati.
### Cattura
Per utilizzarlo`Catch`, aggiungi quanto segue alla definizione dello stato:
```
"Catch": [
{
"ErrorEquals": [
""
]
"Next": ""
}
]
```
Tutti i campi che includono valori sono obbligatori, come descritto di seguito:
`Catch.ErrorEquals`
Una serie di tipi di errore da catturare. Se un errore di esecuzione corrisponde a uno dei valori specificati, la macchina a stati passa allo stato specificato in`Catch.Next`. Consultate la definizione di ogni 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 che corrisponde a uno dei valori specificati in. `Catch.ErrorEquals`
I blocchi Catch vengono gestiti in sequenza fino a quando non ne corrisponde uno. Se gli errori no corrispondono a quelli elencati nei blocchi Catch, le macchine a stati continuano a 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 rileva un errore di esecuzione.
### hasExecutionError
Quando alcuni stati riscontrano errori di esecuzione, oltre a emettere l'errore, impostano anche il `hasExecutionError` valore su `true` nel contesto della macchina a stati. È possibile utilizzare questo valore per rilevare quando si verifica un errore e quindi utilizzare uno `Choice` stato per trasferire la macchina a stati allo `Fail` stato.
Questo metodo presenta le seguenti caratteristiche.
+ La macchina a stati non si avvia con alcun valore assegnato a `hasExecutionError` e questo valore non è disponibile finché non viene impostato da uno stato particolare. Ciò significa che è necessario impostare in modo esplicito il `FallthroughOnError` to `false` per gli `Choice` stati che accedono a questo valore per evitare che la macchina a stati si fermi se non si verificano errori di esecuzione.
+ Una volta impostato su`true`, non `hasExecutionError` viene mai impostato su false o rimosso dal contesto. Ciò significa che questo valore è utile solo la prima volta che viene impostato su e per tutti gli stati successivi non fornisce un valore significativo. `true`
+ Il `hasExecutionError` valore è condiviso con tutte le macchine a stati delle filiali presenti `Parallel` nello stato, il che può generare risultati imprevisti a seconda dell'ordine in cui viene effettuato l'accesso.
A causa di queste caratteristiche, non è consigliabile utilizzare questo metodo se è possibile utilizzare invece un blocco Catch.
## Esempi di macchine a stati
Questa sezione fornisce alcuni esempi di configurazioni di macchine a stati.
**Topics**
+ [Esempio di macchina a stati: Esegui un singolo gruppo di test](#single-test-group)
+ [Esempio di macchina a stati: esegue gruppi di test selezionati dall'utente](#allow-specific-groups)
+ [Esempio di macchina a stati: esegui un singolo gruppo di test con le caratteristiche del prodotto](#run-with-product-features)
+ [Esempio di macchina a stati: esecuzione di due gruppi di test in parallelo](#run-in-parallel)
### Esempio di 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 un `group.json` file.
+ Verifica la presenza di errori di esecuzione e le `Fail` eventuali transizioni rilevate.
+ Genera un rapporto e passa a `Succeed` se non ci sono errori e `Fail` altro.
```
{
"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 di macchina a stati: esegue gruppi di test selezionati dall'utente
Questa macchina a stati:
+ Verifica se il test runner ha selezionato gruppi di test specifici. La macchina a stati non verifica la presenza di casi di test specifici perché i test runner non possono selezionare casi di test senza selezionare anche un gruppo di test.
+ Se sono selezionati gruppi di test:
+ Esegue i casi di test all'interno dei gruppi di test selezionati. A tale scopo, la macchina a stati non specifica esplicitamente alcun gruppo di test o caso di test nello `RunTask` stato.
+ Genera un rapporto dopo aver eseguito tutti i test e le uscite.
+ Se i gruppi di test non sono selezionati:
+ Esegue i 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 di macchina a stati: esegui un singolo gruppo di test con le caratteristiche del prodotto
Questa macchina a stati:
+ Esegue il gruppo di test`GroupA`.
+ Verifica la presenza di errori di esecuzione e le `Fail` eventuali transizioni rilevate.
+ Aggiunge la `FeatureThatDependsOnGroupA` funzionalità al `awsiotdevicetester_report.xml` file:
+ Se ha `GroupA` esito positivo, la funzionalità è impostata su`supported`.
+ La funzionalità non è contrassegnata come opzionale nel rapporto.
+ Genera un rapporto e passa a `Succeed` se non ci sono errori e altro `Fail`
```
{
"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 di macchina a stati: esecuzione di due gruppi di test in parallelo
Questa macchina a stati:
+ Esegue i gruppi `GroupA` e `GroupB` test in parallelo. Le `ResultVar` variabili memorizzate nel contesto dagli `RunTask` stati nelle macchine a stati della filiale di sono disponibili per lo `AddProductFeatures` stato.
+ Verifica la presenza di errori di esecuzione e le `Fail` eventuali transizioni rilevate. Questa macchina a stati non utilizza un `Catch` blocco perché tale metodo non rileva errori di esecuzione nelle macchine a stati delle filiali.
+ Aggiunge funzionalità al `awsiotdevicetester_report.xml` file in base ai gruppi che passano
+ Se ha `GroupA` esito positivo, la funzionalità è impostata su`supported`.
+ La funzionalità non è contrassegnata come opzionale nel rapporto.
+ Genera un rapporto e passa a `Succeed` se non ci sono errori e altro `Fail`
Se due dispositivi sono configurati nel pool di dispositivi, entrambi `GroupA` `GroupB` possono funzionare contemporaneamente. Tuttavia, se uno `GroupA` o `GroupB` più test sono inclusi, 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"
}
}
}
```