Configurare la macchina a stati IDT - AWS IoT Greengrass
Formato macchina a statiStati e definizioni di stato validiContesto della macchina a statiErrori di esecuzioneEsempi di macchine a stati

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.

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 oFail.

Formato macchina a stati

È possibile utilizzare il seguente modello per configurare il proprio <custom-test-suite-folder>/suite/state_machine.json file: 

{
  "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 nell'Statesoggetto.

States

Un oggetto che associa i nomi di stato definiti dall'utente a stati IDT validi. Ogni stato. state-namel'oggetto contiene la definizione di uno stato valido mappato su. state-name

L'Statesoggetto deve includere gli Fail stati Succeed e. Per informazioni sugli stati validi, vedereStati 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 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.

RunTask

Lo RunTask stato esegue casi di test 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 a cui 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 test runner.

TestCases

Facoltativo. Una serie di test case del gruppo IDs specificato in. TestGroup In base ai valori di TestGroup andTestCases, 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.

    Per ulteriori informazioni sull'abilitazione dei comandi CLI IDT per i test runner, vedere. Abilita i comandi CLI IDT

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 perTestGroup. IDT imposta il valore della variabile definita in true o in false base ResultVar a quanto segue:

  • Se il nome della variabile è nel formatotext_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": "<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 a cui passare se nessuna delle espressioni definite in Choices può essere valutata. true

FallthroughOnError

Facoltativo. 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 atrue, 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

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 suFallthroughOnError. false Tuttavia, ti consigliamo di impostare etrue, 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 suFail.

Parallel

Lo Parallel stato consente di definire ed eseguire nuove macchine a stati in parallelo tra loro.

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

Nota

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, vediEsempio di macchina a stati: esecuzione di due gruppi di test in parallelo.

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 supportednot-supported, in base al superamento dei test specificati.

Nota

Lo AddProductFeatures stato non genera report da solo. Questo stato deve passare allo Reportstato per 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 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

Facoltativo. 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 onot-supported.

Se utilizzate un valore personalizzato perFeatureValue, 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

Facoltativo. 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

Facoltativo. 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

Facoltativo. 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.

  • Groupsdeve contenere un solo ID del gruppo di test.

  • OneOfGroupsnon deve essere specificato.

IsRequired

Facoltativo. Imposta false su per contrassegnare questa funzionalità come opzionale nel rapporto. Il valore predefinito è true.

ExecutionMethods

Facoltativo. 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 sugroup-id_test-id_passed.

  • Se non hai specificato un singolo test case IDs, imposta ResultVar sugroup-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 andawsiotdevicetester_report.xml. Questo stato trasmette inoltre il report alla console.

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

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": "<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 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": "<state-name>"
    "TestGroups": [
        <group-id>"
    ]
}

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

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:

Cattura

Per utilizzarloCatch, aggiungi quanto segue alla definizione dello stato:

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

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 inCatch.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 sutrue, 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.

Esempio di 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 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 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 di macchina a stati: esegui un singolo gruppo di test con le caratteristiche del prodotto

Questa macchina a stati:

  • Esegue il gruppo di testGroupA.

  • 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 susupported.

    • 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 susupported.

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