View a markdown version of this page

Configurare la macchina a stati IDT - FreeRTOS
Formato macchina a statiStati validi e definizioni di statoContesto 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.2, questa macchina a stati è obsoleta. Ti consigliamo vivamente di utilizzare il nuovo orchestrator di test. Per ulteriori informazioni, consulta Configura 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 a passare attraverso tali stati fino a raggiungere lo stato finale.

Se la tua suite di test non include una macchina a stati definita dall'utente, IDT genererà una macchina a stati per te. La macchina a stati predefinita esegue 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 della suite di test in ordine casuale.

  • Genera report e stampa un riepilogo sulla 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 creare 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 uno 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. Ciascuno Stato. state-namel'oggetto contiene la definizione di uno stato valido mappato a. state-name

L'Statesoggetto deve includere gli Fail stati Succeed and. Per informazioni sugli stati validi, vedereStati validi e definizioni di stato.

Stati validi e definizioni di stato

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 le configurazioni a livello di test case. Tuttavia, si consiglia di configurare le regole di transizione di stato a livello di gruppo di test anziché a livello di test case, a meno che non sia assolutamente necessario.

RunTask

Lo RunTask stato esegue i 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 aver eseguito le 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 ID dei test case del gruppo specificato in. TestGroup In base ai valori di TestGroup eTestCases, IDT determina il comportamento di esecuzione del test come segue:

  • Quando TestCases vengono specificati entrambi 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 TestCases è specificato TestGroup o è specificato, IDT esegue tutti i test case dal gruppo di test selezionato dal test runner dall'IDT CLI. Per abilitare la selezione di gruppo per i test runner, è necessario includere entrambi RunTask gli stati nel file. Choice statemachine.json Per un esempio di come funziona, vedi Esempio di macchina a stati: esecuzione di gruppi di test selezionati dall'utente.

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

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

  • In tutti gli altri casi, il valore è impostato sul fatto che tutti i test di tutti i gruppi di test siano stati superati o saltati.

In genere, si utilizza RunTask state per specificare l'ID di un gruppo di test senza specificare gli ID dei singoli test case, in modo che IDT esegua tutti i test case nel gruppo di test specificato. Tutti i test case eseguiti da questo stato vengono eseguiti in parallelo, in ordine casuale. Tuttavia, se tutti i test case 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 degli ID dei test case 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

Opzionale. Specifica il comportamento quando lo stato rileva un errore nella valutazione delle espressioni. Impostato su true se si desidera 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

Una serie 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 un risultatotrue, 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 arrivare a 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 si verifica un errore, è necessario impostare suFallthroughOnError. false Tuttavia, ti consigliamo di impostare etrue, FallthroughOnError a seconda del caso d'uso, di effettuare una delle seguenti operazioni:

  • Se in alcuni casi si prevede che una variabile a cui stai accedendo non esista, utilizza il valore Default e Choices i 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 aver eseguito le azioni nello stato corrente.

Branches

Una serie di definizioni di macchine a stati da eseguire. Ogni definizione di macchina a stati deve contenere StartAt i propri e 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 di filiale condivide lo stesso contesto di 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 delle filiali. Ogni stato che richiede un dispositivo attenderà l'esecuzione finché il dispositivo non sarà disponibile. Se sono disponibili più dispositivi, questo stato esegue casi di test di più gruppi in parallelo. Se non è disponibile un numero sufficiente di dispositivi, i test case verranno eseguiti in sequenza. Poiché i test case 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 stato del ramo che la macchina a stato principale passino allo Fail stato per gestire gli errori di esecuzione.

Poiché le macchine a stato secondario 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 secondario. Utilizzate invece il hasExecutionErrors valore nel contesto della macchina a stati condivisi. Per un esempio di come funziona, vediEsempio di macchina a stati: esegue due gruppi di test in parallelo.

AddProductFeatures

Lo AddProductFeatures stato consente di aggiungere funzionalità di prodotto al awsiotdevicetester_report.xml file generato da IDT.

Una funzionalità di 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 report, le caratteristiche del prodotto sono impostate come, o come valore personalizzato supportednot-supported, in base al superamento o meno dei test specificati.

Nota

Lo AddProductFeatures stato non genera report da solo. Questo stato deve passare allo Report stato 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 aver eseguito le 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 report anzichésupported. Se questo valore non è specificato, in base ai risultati del test, il valore della feature viene impostato su supported onot-supported.

Se si utilizza un valore personalizzato perFeatureValue, è possibile testare la stessa funzionalità con condizioni diverse e IDT concatena i valori della funzionalità 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 vengono superati, il valore della funzionalità viene impostato su. first-feature-supported, second-feature-supported

Groups

Opzionale. Una serie di ID dei gruppi di test. Tutti i test all'interno di ciascun gruppo di test specificato devono essere superati affinché la funzionalità sia supportata.

OneOfGroups

Opzionale. Una serie di ID dei gruppi di test. 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 ID dei test case. 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

Opzionale. falseImpostare su per contrassegnare questa funzionalità come funzionalità 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 gli ID dei singoli test case, imposta ResultVar sugroup-id_test-id_passed.

  • Se non hai specificato gli ID dei singoli test case, imposta ResultVar sugroup-id_passed.

Lo AddProductFeatures stato verifica i risultati dei test nel modo seguente:

  • Se non hai specificato alcun ID del test case, 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 gli ID dei test case, 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 rapporto 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 aver eseguito le 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 stato è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 aver eseguito le 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 qualsiasi stato Choice successivo.

{
    "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 aver eseguito le 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. Assicurati di fornire ID validi per i gruppi di test perché IDT non convalida l'esistenza dei gruppi specificati.

Fail

Lo Fail stato indica che la macchina a stati non è stata eseguita correttamente. Questo è 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. Questo è 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 nel file. userdata.json

config

Informazioni: aggiungi il config.json file.

suiteFailed

Il valore è impostato all'falseavvio della macchina a stati. Se un gruppo di test fallisce in uno RunTask stato, questo valore viene impostato true per la durata rimanente 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 degli ID specifici dei gruppi di test.

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 degli ID specifici dei test case.

hasExecutionErrors

Non esce all'avvio della macchina a stati. Se uno stato rileva un errore di esecuzione, questa variabile viene creata e impostata su true per la durata rimanente dell'esecuzione della macchina a stati.

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

  • Il TestCases valore in stati. RunTask

  • Lo Choice stato Expression del valore.

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

  • I tuoi percorsi JSON devono iniziare con $.

  • Ogni valore deve restituire una stringa, un numero o un booleano.

Per ulteriori informazioni sull'utilizzo della notazione JSONPath 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, aggiungete 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 dei tipi di errore da rilevare. Se un errore di esecuzione corrisponde a uno dei valori specificati, la macchina a stati passa allo stato specificato inCatch.Next. Vedi ogni 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 che corrisponde a uno dei valori specificati in. Catch.ErrorEquals

I blocchi catch vengono gestiti in sequenza finché uno non corrisponde. Se l'assenza di errori corrisponde a quelli elencati nei blocchi Catch, l'esecuzione delle macchine a stati continua. 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.

ha ExecutionError

Quando alcuni stati riscontrano errori di esecuzione, oltre a generare 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 hasExecutionError e questo valore non è disponibile finché non viene impostato da uno stato particolare. Ciò significa che è necessario impostare esplicitamente su false per gli Choice stati che accedono FallthroughOnError a questo valore per evitare che la macchina a stati si arresti 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 e per tutti gli stati successivi non fornisce un valore significativo. true

  • Il hasExecutionError valore è condiviso con tutte le macchine a stati di filiale presenti Parallel nello stato, il che può portare a risultati imprevisti a seconda dell'ordine di accesso.

A causa di queste caratteristiche, non è consigliabile utilizzare questo metodo se invece è possibile utilizzare 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 passa a Fail se ne vengono trovati.

  • Genera un report e passa a Succeed se non ci sono errori e Fail viceversa.

{
    "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 casi di test 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 stati non specifica esplicitamente alcun gruppo di test o test case nello RunTask stato.

    • Genera un report 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 esce.

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

  • Aggiunge la FeatureThatDependsOnGroupA funzionalità al awsiotdevicetester_report.xml file:

    • Se viene GroupA superata, la feature è impostata susupported.

    • La funzionalità non è contrassegnata come opzionale nel rapporto.

  • Genera un report e passa a Succeed se non ci sono errori e viceversa 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: esegue due gruppi di test in parallelo

Questa macchina a stati:

  • Esegue i gruppi di GroupB test GroupA e li esegue in parallelo. Le ResultVar variabili memorizzate nel contesto dagli RunTask stati nel branch State Machines by sono disponibili per lo AddProductFeatures stato.

  • Verifica la presenza di errori di esecuzione e le Fail eventuali transizioni. Questa macchina a stati non utilizza un Catch blocco perché tale metodo non rileva errori di esecuzione nelle macchine a stati secondari.

  • Aggiunge funzionalità al awsiotdevicetester_report.xml file in base ai gruppi che lo superano

    • Se GroupA viene superato, la funzionalità è impostata susupported.

    • La funzionalità non è contrassegnata come opzionale nel rapporto.

  • Genera un report e passa a Succeed se non ci sono errori e viceversa Fail

Se nel pool di dispositivi sono configurati due dispositivi, entrambi GroupA GroupB possono funzionare contemporaneamente. Tuttavia, se uno GroupA o GroupB più test sono presenti, 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"
        }
    }
}