Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Konfigurieren Sie den IDT-Statuscomputer
Wichtig
Ab IDT v4.5.1 ist dieser Zustandscomputer veraltet. Es wird dringend empfohlen, den neuen Test-Orchestrator zu verwenden. Weitere Informationen finden Sie unter Konfigurieren Sie den IDT-Test-Orchestrator.
Ein State-Computer ist ein Konstrukt, das den Ausführungsablauf der Testsuite steuert. Es bestimmt den Startstatus einer Testsuite, verwaltet Zustandsübergänge basierend auf benutzerdefinierten Regeln und wechselt weiter durch diese Zustände, bis sie den Endzustand erreicht.
Wenn Ihre Testsuite keinen benutzerdefinierten Zustandscomputer enthält, generiert IDT einen Zustandscomputer für Sie. Der Standardstatus-Computer führt die folgenden Funktionen aus:
-
Bietet Testläufern die Möglichkeit, bestimmte Testgruppen anstelle der gesamten Testsuite auszuwählen und auszuführen.
-
Wenn keine bestimmten Testgruppen ausgewählt sind, führt jede Testgruppe in der Testsuite in einer zufälligen Reihenfolge aus.
-
Generiert Berichte und druckt eine Konsolenzusammenfassung, die die Testergebnisse für jede Testgruppe und jeden Testfall anzeigt.
Der Zustandsautomat für eine IDT-Testsuite muss die folgenden Kriterien erfüllen:
-
Jeder Status entspricht einer Aktion, die IDT ausführen muss, z. B. um eine Testgruppe oder ein Produkt einer Berichtsdatei auszuführen.
-
Durch den Übergang zu einem Status wird die mit dem Status verbundene Aktion ausgeführt.
-
Jeder Status definiert die Übergangsregel für den nächsten Status.
-
Der Endstatus muss entweder
Succeed
oderFail
aus.
Format des Zustandsautomaten
Sie können die folgende Vorlage verwenden, um Ihre eigene zu konfigurieren
file: <custom-test-suite-folder>
/suite/state_machine.json
{ "Comment": "
<description>
", "StartAt": "<state-name>
", "States": { "<state-name>
": { "Type": "<state-type>
", // Additional state configuration } // Required states "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } }
Nachfolgend sind alle Pflichtfelder beschrieben:
Comment
-
Eine Beschreibung des Zustandsautomaten.
StartAt
-
Der Name des nächsten Zustands, in dem IDT mit der Ausführung der Testsuite beginnt. Der Wert von
StartAt
muss auf einen der in derStates
-Objekt. States
-
Ein Objekt, das benutzerdefinierte Statusnamen gültigen IDT-Status zuordnet. Jeder Bundesstaat.
Name des Zustandsautomaten
object enthält die Definition eines gültigen Status, der demName des Zustandsautomaten
aus.Die
States
Objekt muss dasSucceed
undFail
-Staaten. Weitere Information zu gültigen Zuständen finden Sie unterGültige Status und Statusdefinitionenaus.
Gültige Status und Statusdefinitionen
In diesem Abschnitt werden die Statusdefinitionen aller gültigen Zustände beschrieben, die im IDT-Statuscomputer verwendet werden können. Einige der folgenden Zustände unterstützen Konfigurationen auf Testfallebene. Wir empfehlen jedoch, Statusübergangsregeln auf Testgruppenebene anstelle der Testfallebene zu konfigurieren, sofern dies nicht unbedingt erforderlich ist.
RunTask
DieRunTask
state führt Testfälle von einer in der Testsuite definierten Testgruppe aus.
{ "Type": "RunTask", "Next": "
<state-name>
", "TestGroup": "<group-id>
", "TestCases": [ "<test-id>
" ], "ResultVar": "<result-name>
" }
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des nächsten Zustands, nachdem die Aktionen im aktuellen Zustand ausgeführt werden sollen.
TestGroup
-
Optional. Die ID der auszuführenden Testgruppe. Wenn dieser Wert nicht angegeben wird, führt IDT die Testgruppe aus, die der Testläufer auswählt.
TestCases
-
Optional. Ein Array von Testfall-IDs aus der in
TestGroup
aus. Basierend auf den Werten vonTestGroup
undTestCases
bestimmt IDT das Verhalten der Testausführung wie folgt:-
Wenn beide
TestGroup
undTestCases
angegeben sind, führt IDT die angegebenen Testfälle aus der Testgruppe aus. -
Wann
TestCases
sind angegeben aberTestGroup
ist nicht angegeben, IDT führt die angegebenen Testfälle aus. -
Wann
TestGroup
ist angegeben, aberTestCases
Ist nicht angegeben, führt IDT alle Testfälle innerhalb der angegebenen Testgruppe aus. -
Wenn keines
TestGroup
oderTestCases
angegeben ist, führt IDT alle Testfälle aus der Testgruppe aus, die der Testläufer aus der IDT CLI auswählt. Um die Gruppenauswahl für Testläufer zu aktivieren, müssen Sie beide einschließenRunTask
undChoice
Bundesstaaten in deinemstate_machine.json
file. Ein Beispiel dafür, wie dies funktioniert, finden Sie unterBeispiel für einen Zustandsautomaten: Ausführen von vom Benutzer ausgewählten Testgruppenaus.Weitere Informationen zur Aktivierung von IDT CLI-Befehlen für Testläufer finden Sie unterDie IDB CLI-Befehleaus.
-
ResultVar
-
Der Name der Kontextvariablen, die mit den Ergebnissen des Testlaufs festgelegt werden soll. Geben Sie diesen Wert nicht an, wenn Sie keinen Wert für angegeben haben
TestGroup
aus. IDT legt den Wert der Variablen fest, in der Sie definierenResultVar
zutrue
oderfalse
basierend auf den folgenden Kriterien:-
Wenn der Variablenname vom Formular stammt
, dann wird der Wert darauf eingestellt, ob alle Tests in der ersten Testgruppe bestanden oder übersprungen wurden.text
_text
_passed -
In allen anderen Fällen wird der Wert darauf festgelegt, ob alle Tests in allen Testgruppen bestanden oder übersprungen wurden.
-
In Regel wird verwendetRunTask
status, um eine Testgruppen-ID anzugeben, ohne einzelne Testfall-IDs anzugeben, damit IDT alle Testfälle in der angegebenen Testgruppe ausführt. Alle Testfälle, die von diesem Status ausgeführt werden, laufen parallel in einer zufälligen Reihenfolge. Wenn jedoch für alle Testfälle ein Gerät ausgeführt werden muss und nur ein einziges Gerät verfügbar ist, werden die Testfälle stattdessen nacheinander ausgeführt.
Fehlerbehandlung
Wenn eine der angegebenen Testgruppen oder Testfall-IDs nicht gültig ist, gibt dieser Status dieRunTaskError
Fehler bei der-Ausführung. Wenn der Status auf einen Ausführungsfehler stößt, wird auch diehasExecutionError
Variable im Zustandsmaschine-Kontext zutrue
aus.
Choice
DieChoice
state ermöglicht es Ihnen, den nächsten Status dynamisch festzulegen, auf den Sie basierend auf benutzerdefinierten Bedingungen wechseln möchten.
{ "Type": "Choice", "Default": "
<state-name>
", "FallthroughOnError": true | false, "Choices": [ { "Expression": "<expression>
", "Next": "<state-name>
" } ] }
Nachfolgend sind alle Pflichtfelder beschrieben:
Default
-
Der Standardzustand, wenn keiner der in definierten Ausdrücke
Choices
kann ausgewertet werdentrue
aus. FallthroughOnError
-
Optional. Gibt das Verhalten an, wenn der Status bei der Auswertung von Ausdrücken auf einen Fehler stößt. Stellen Sie auf
true
wenn Sie einen Ausdruck überspringen möchten, wenn die Auswertung zu einem Fehler führt. Wenn keine Ausdrücke übereinstimmen, wechselt der Zustandsautomat in denDefault
Status. Wenn das SymbolFallthroughOnError
Wert ist nicht angegeben, er ist standardmäßigfalse
aus. Choices
-
Ein Array von Ausdrücken und Zuständen, in den festgelegt werden soll, in welchen Status nach Ausführung der Aktionen im aktuellen Status umgestellt werden soll.
Choices.Expression
-
Eine Ausdruckszeichenfolge, die zu einem booleschen Wert ausgewertet wird. Wenn der Ausdruck ausgewertet wird
true
, wechselt der Zustandsautomat inChoices.Next
aus. Ausdruckszeichenfolgen rufen Werte aus dem Zustandsmaschinenkontext ab und führen dann Operationen an ihnen aus, um zu einem booleschen Wert zu gelangen. Informationen über den Zugriff auf den Zustandsmaschinen-Kontext finden Sie unterKontext des Zustandsautomatenaus. Choices.Next
-
Der Name des nächsten Zustands, wenn der in definierte Ausdruck
Choices.Expression
wertet nachtrue
aus.
Fehlerbehandlung
DieChoice
state kann in folgenden Fällen eine Fehlerbehandlung erfordern:
-
Einige Variablen in den Auswahlausdrücken existieren im Zustandsmaschinenkontext nicht.
-
Das Ergebnis eines Ausdrucks ist kein boolescher Wert.
-
Das Ergebnis eines JSON-Lookups ist kein String, keine Zahl oder ein boolescher Wert.
Sie können keinCatch
blockieren, um Fehler in diesem Zustand zu behandeln. Wenn Sie die Ausführung des Statusrechners beenden möchten, wenn ein Fehler auftritt, müssen SieFallthroughOnError
zufalse
aus. Wir empfehlen jedoch, dass Sie festlegenFallthroughOnError
zutrue
, und abhängig von Ihrem Anwendungsfall führen Sie eine der folgenden Maßnahmen durch:
-
Wenn erwartet wird, dass eine Variable, auf die Sie zugreifen, in einigen Fällen nicht existiert, verwenden Sie den Wert von
Default
und zusätzlichChoices
Blöcke, um den nächsten Zustand anzugeben. -
Wenn eine Variable, auf die Sie zugreifen, immer vorhanden sein sollte, setzen Sie die
Default
Status zuFail
aus.
Parallel
DieParallel
state ermöglicht es Ihnen, neue Zustandsmaschinen parallel zueinander zu definieren und auszuführen.
{ "Type": "Parallel", "Next": "
<state-name>
", "Branches": [<state-machine-definition>
] }
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des nächsten Zustands, nachdem die Aktionen im aktuellen Zustand ausgeführt werden sollen.
Branches
-
Ein Array von auszuführenden Statusmaschinendefinitionen. Jede Definition des Zustandsautomaten muss ihre eigene enthalten
StartAt
,Succeed
, undFail
-Staaten. Die Statusmaschinendefinitionen in diesem Array können keine Zustände außerhalb ihrer eigenen Definition referenzieren.Anmerkung
Da jeder Zweigstatus-Computer denselben Zustands-Maschinen-Kontext hat, kann das Festlegen von Variablen in einem Zweig und das anschließende Lesen dieser Variablen aus einem anderen Zweig zu unerwartetem Verhalten führen.
DieParallel
state wechselt erst in den nächsten Status, nachdem alle Zweigzustandsmaschinen ausgeführt wurden. Jeder Status, der ein Gerät benötigt, wartet auf die Ausführung, bis das Gerät verfügbar ist. Wenn mehrere Geräte verfügbar sind, führt dieser Status Testfälle aus mehreren Gruppen parallel aus. Wenn nicht genügend Geräte verfügbar sind, werden Testfälle nacheinander ausgeführt. Da Testfälle in einer zufälligen Reihenfolge ausgeführt werden, wenn sie parallel ausgeführt werden, können verschiedene Geräte verwendet werden, um Tests aus derselben Testgruppe auszuführen.
Fehlerbehandlung
Stellen Sie sicher, dass sowohl der Zweigzustandsmaschine als auch der übergeordnete Zustandsmaschine in dieFail
status, um Ausführungsfehler zu behandeln.
Da Zweigzustandsmaschinen keine Ausführungsfehler an den übergeordneten Zustandscomputer übermitteln, können Sie keineCatch
blockieren, um Ausführungsfehler in Zweigzustandsmaschinen zu behandeln. Verwenden Sie stattdessen denhasExecutionErrors
Wert im Kontext des freigegebenen Zustands-Rechners. Ein Beispiel dafür, wie dies funktioniert, finden Sie unterBeispiel für einen Zustandsautomaten: Führen Sie zwei Testgruppen parallel ausaus.
addProductFeatures
DieAddProductFeatures
state ermöglicht es Ihnen, Produktfunktionen zumawsiotdevicetester_report.xml
von IDT generierte Datei.
Ein Produktmerkmal sind benutzerdefinierte Informationen zu bestimmten Kriterien, die ein Gerät möglicherweise erfüllen kann. Zum Beispiel, dasMQTT
Die Produktfunktion kann angeben, dass das Gerät MQTT-Nachrichten ordnungsgemäß veröffentlicht. Im Bericht werden Produkteigenschaften als festgelegtsupported
,not-supported
oder ein benutzerdefinierter Wert, basierend darauf, ob bestimmte Tests bestanden wurden.
Anmerkung
DieAddProductFeatures
state generiert keine Berichte von selbst. Dieser Staat muss auf dieReportBundesstaatum Berichte zu generieren.
{ "Type": "Parallel", "Next": "
<state-name>
", "Features": [ { "Feature": "<feature-name>
", "Groups": [ "<group-id>
" ], "OneOfGroups": [ "<group-id>
" ], "TestCases": [ "<test-id>
" ], "IsRequired": true | false, "ExecutionMethods": [ "<execution-method>
" ] } ] }
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des nächsten Zustands, nachdem die Aktionen im aktuellen Zustand ausgeführt werden sollen.
Features
-
Eine Reihe von Produkteigenschaften, die in der
awsiotdevicetester_report.xml
file.Feature
-
Der Name des Features
FeatureValue
-
Optional. Der benutzerdefinierte Wert, der im Bericht anstelle von verwendet werden soll
supported
aus. Wenn dieser Wert nicht angegeben wird, wird der Feature-Wert basierend auf Testergebnissen aufsupported
odernot-supported
aus.Wenn Sie einen benutzerdefinierten Wert für verwenden
FeatureValue
können Sie dasselbe Feature mit verschiedenen Bedingungen testen, und IDT verkettet die Feature-Werte für die unterstützten Bedingungen. Der folgende Auszug zeigt denMyFeature
Feature mit zwei separaten Feature-Werten:... { "Feature": "MyFeature", "FeatureValue": "first-feature-supported", "Groups": ["first-feature-group"] }, { "Feature": "MyFeature", "FeatureValue": "second-feature-supported", "Groups": ["second-feature-group"] }, ...
Wenn beide Testgruppen bestehen, wird der Feature-Wert auf
first-feature-supported, second-feature-supported
aus. Groups
-
Optional. Ein Array von Testgruppen-IDs. Alle Tests innerhalb jeder angegebenen Testgruppe müssen bestehen, damit das Feature unterstützt wird.
OneOfGroups
-
Optional. Ein Array von Testgruppen-IDs. Alle Tests innerhalb mindestens einer der angegebenen Testgruppen müssen bestehen, damit das Feature unterstützt wird.
TestCases
-
Optional. Ein Array von Testfall-IDs. Wenn Sie diesen Wert angeben, gilt Folgendes:
-
Alle angegebenen Testfälle müssen bestehen, damit das Feature unterstützt wird.
-
Groups
darf nur eine Testgruppen-ID enthalten. -
OneOfGroups
darf nicht angegeben werden.
-
IsRequired
-
Optional. Stellen Sie auf
false
um diese Funktion als optionales Feature im Bericht zu markieren. Der Standardwert isttrue
. ExecutionMethods
-
Optional. Ein Array von Ausführungsmethoden, die mit der
protocol
Der in derdevice.json
file. Wenn dieser Wert angegeben wird, müssen Testläufer eine angebenprotocol
Wert, der mit einem der Werte in diesem Array übereinstimmt, um das Feature in den Bericht aufzunehmen. Wenn dieser Wert nicht angegeben wird, wird das Feature immer in den Bericht aufgenommen.
So verwenden Sie denAddProductFeatures
state, müssen Sie den Wert vonResultVar
imRunTask
Geben Sie einen der folgenden Werte an:
-
Wenn Sie einzelne Testfall-IDs angegeben haben, setzen Sie
ResultVar
zu
aus.group-id_test-id
_passed -
Wenn Sie keine einzelnen Testfall-IDs angegeben haben, setzen Sie
ResultVar
zu
aus.group-id
_passed
DieAddProductFeatures
Statusprüfungen für Testergebnisse in der folgenden Weise:
-
Wenn Sie keine Testfall-IDs angegeben haben, wird das Ergebnis für jede Testgruppe aus dem Wert des
variabel im Zustandsmaschinen-Kontext.group-id
_passed -
Wenn Sie Testfall-IDs angegeben haben, wird das Ergebnis für jeden der Tests aus dem Wert des
variabel im Zustandsmaschinen-Kontext.group-id_test-id
_passed
Fehlerbehandlung
Wenn eine in diesem Status angegebene Gruppen-ID keine gültige Gruppen-ID ist, führt dieser Status zuAddProductFeaturesError
Fehler bei der-Ausführung. Wenn der Status auf einen Ausführungsfehler stößt, wird auch diehasExecutionErrors
Variable im Zustandsmaschine-Kontext zutrue
aus.
Bericht
DieReport
Der Zustand generiert den
undsuite-name
_Report.xmlawsiotdevicetester_report.xml
Dateien. Dieser Status streamt den Bericht auch an die Konsole.
{ "Type": "Report", "Next": "
<state-name>
" }
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des nächsten Zustands, nachdem die Aktionen im aktuellen Zustand ausgeführt werden sollen.
Du solltest immer auf dieReport
gegen Ende des Testausführungsflusses angeben, damit Testläufer Testergebnisse anzeigen können. In der Regel ist der nächste Status nach diesem StatusSucceed
aus.
Fehlerbehandlung
Wenn dieser Status Probleme beim Erstellen der Berichte aufweist, gibt er dieReportError
Fehler bei der-Ausführung.
LogMessage
DieLogMessage
Der Zustand generiert dentest_manager.log
-Datei und streamt die Protokollnachricht in die Konsole.
{ "Type": "LogMessage", "Next": "
<state-name>
" "Level": "info | warn | error" "Message": "<message>
" }
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des nächsten Zustands, nachdem die Aktionen im aktuellen Zustand ausgeführt werden sollen.
Level
-
Die Fehlerstufe, auf der die Protokollmeldung erstellt werden soll. Wenn Sie eine Ebene angeben, die nicht gültig ist, generiert dieser Status eine Fehlermeldung und verwirft diese.
Message
-
Die zu protokolligende Nachricht.
SelectGroup
DieSelectGroup
status aktualisiert den Zustandsmaschinenkontext, um anzugeben, welche Gruppen ausgewählt sind. Die von diesem Status festgelegten Werte werden von allen nachfolgenden verwendetChoice
-Staaten.
{ "Type": "SelectGroup", "Next": "
<state-name>
" "TestGroups": [<group-id>
" ] }
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des nächsten Zustands, nachdem die Aktionen im aktuellen Zustand ausgeführt werden sollen.
TestGroups
-
Ein Array von Testgruppen, die als ausgewählt gekennzeichnet werden. Für jede Testgruppen-ID in diesem Array wird die
Variable ist aufgroup-id
_selectedtrue
im Kontext. Stellen Sie sicher, dass Sie gültige Testgruppen-IDs angeben, da IDT nicht überprüft, ob die angegebenen Gruppen vorhanden sind.
Fehler
DieFail
status gibt an, dass der Zustandsmaschine nicht korrekt ausgeführt wurde. Dies ist ein Endstatus für den Statuscomputer, und jede Statusmaschinendefinition muss diesen Status enthalten.
{ "Type": "Fail" }
Succeed
DieSucceed
status gibt an, dass der Zustandsmaschine korrekt ausgeführt wurde. Dies ist ein Endstatus für den Statuscomputer, und jede Statusmaschinendefinition muss diesen Status enthalten.
{ "Type": "Succeed" }
Kontext des Zustandsautomaten
Der Zustandsmaschinenkontext ist ein schreibgeschütztes JSON-Dokument, das Daten enthält, die dem Statuscomputer während der Ausführung zur Verfügung stehen. Der Zustandsmaschinenkontext ist nur vom Zustandsmaschine aus zugänglich und enthält Informationen, die den Testfluss bestimmen. Beispielsweise können Sie Informationen verwenden, die von Testläufern konfiguriert wurden, imuserdata.json
-Datei, um festzustellen, ob ein bestimmter Test ausgeführt werden muss.
Der Kontext des Zustandsautomaten verwendet das folgende Format:
{ "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
-
Informationen über den Gerätepool, der für den Testlauf ausgewählt wurde. Für einen ausgewählten Gerätepool werden diese Informationen aus dem entsprechenden Gerätepool-Array-Element der obersten Ebene abgerufen, das in der
device.json
file. userData
-
Informationen im
userdata.json
file. config
-
Informationen pinnen Sie den
config.json
file. suiteFailed
-
Der Wert ist auf
false
wenn der Zustandsautomat gestartet wird. Wenn eine Testgruppe in einerRunTask
state, dann ist dieser Wert auftrue
Für die verbleibende Dauer der Ausführung des Zustandsautomaten. specificTestGroups
-
Wenn der Testrunner bestimmte Testgruppen auswählt, die anstelle der gesamten Testsuite ausgeführt werden sollen, wird dieser Schlüssel erstellt und enthält die Liste der spezifischen Testgruppen-IDs.
specificTestCases
-
Wenn der Testläufer bestimmte Testfälle auswählt, die anstelle der gesamten Testsuite ausgeführt werden sollen, wird dieser Schlüssel erstellt und enthält die Liste der spezifischen Testfall-IDs.
hasExecutionErrors
-
Wird nicht beendet, wenn der Zustandsmaschine gestartet wird. Wenn ein Status auf Ausführungsfehler stößt, wird diese Variable erstellt und auf
true
Für die verbleibende Dauer der Ausführung des Zustandsautomaten.
Sie können den Kontext mit JsonPath-Notation abfragen. Die Syntax für JsonPath-Abfragen in Statusdefinitionen lautet{{$.
aus. Sie können JsonPath-Abfragen als Platzhalterzeichenfolgen in einigen Zuständen verwenden. IDT ersetzt die Platzhalterzeichenfolgen durch den Wert der ausgewerteten JsonPath-Abfrage aus dem Kontext. Sie können Platzhalter für folgende Werte verwenden:query
}}
-
Die
TestCases
Wert inRunTask
-Staaten. -
Die
Expression
WertChoice
Status.
Wenn Sie auf Daten aus dem Zustandsautomatenkontext zugreifen, stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:
-
Ihre JSON-Pfade müssen mit beginnen
$.
-
Jeder Wert muss zu einer Zeichenfolge, einer Zahl oder einem booleschen Wert ausgewertet werden.
Weitere Informationen zur Verwendung von JSONPath-Notation für den Zugriff auf Daten aus dem Kontext finden Sie unterVerwenden Sie den IDT-Kontextaus.
Ausführungsfehler
Ausführungsfehler sind Fehler in der Statusmaschinendefinition, auf die der Statuscomputer beim Ausführen eines Status stößt. IDT protokolliert Informationen zu jedem Fehler imtest_manager.log
-Datei und streamt die Protokollnachricht in die Konsole.
Sie können die folgenden Methoden verwenden, um Ausführungsfehler zu behandeln:
-
Hinzufügen einerCatchBlockin der Statusdefinition.
-
Überprüfen Sie den Wert deshasExecutionErrorsWertIm Kontext des Zustandsautomaten.
Fangen
Um zu verwendenCatch
, fügen Sie Ihrer Statusdefinition Folgendes hinzu:
"Catch": [ { "ErrorEquals": [ "
<error-type>
" ] "Next": "<state-name>
" } ]
Nachfolgend sind alle Pflichtfelder beschrieben:
Catch.ErrorEquals
-
Ein Array der abzusehenden Fehlertypen. Wenn ein Ausführungsfehler mit einem der angegebenen Werte übereinstimmt, wechselt der Zustandsautomat in
Catch.Next
aus. Informationen über die Art des Fehlers, den es erzeugt, finden Sie in jeder Statusdefinition. Catch.Next
-
Der nächste Status, zu dem umgestellt werden soll, wenn der aktuelle Status auf einen Ausführungsfehler stößt, der mit einem der in angegebenen Werte übereinstimmt
Catch.ErrorEquals
aus.
Catch-Blöcke werden nacheinander gehandhabt, bis einer übereinstimmt. Wenn die Keine Fehler mit den in den Catch-Blöcken aufgeführten übereinstimmen, werden die Zustandsmaschinen weiterhin ausgeführt. Da Ausführungsfehler auf falsche Zustandsdefinitionen zurückzuführen sind, empfehlen wir Ihnen, in den Status „Fail“ zu wechseln, wenn ein Status auf einen Ausführungsfehler stößt.
hasExecutionError
Wenn einige Zustände auf Ausführungsfehler stoßen, legen sie zusätzlich zur Fehlerausgabe auch diehasExecutionError
Wert zutrue
im Zustandsautomatenkontext. Sie können diesen Wert verwenden, um zu erkennen, wann ein Fehler auftritt, und dann eineChoice
status, um die Zustandsmaschine auf denFail
Status.
Diese Methode hat folgende Merkmale:
-
Der Zustandsmaschine beginnt nicht mit einem Wert, der dem zugewiesen wurde
hasExecutionError
, und dieser Wert ist erst verfügbar, wenn ein bestimmter Status ihn festgelegt hat. Dies bedeutet, dass Sie explizit denFallthroughOnError
zufalse
fürChoice
gibt an, dass auf diesen Wert zugegriffen wird, um zu verhindern, dass der Statuscomputer beendet wird, wenn keine Ausführungsfehler auftreten -
Sobald es auf eingestellt ist
true
,hasExecutionError
wird niemals auf false festgelegt oder aus dem Kontext entfernt. Dies bedeutet, dass dieser Wert nur nützlich ist, wenn er zum ersten Mal auftrue
und für alle nachfolgenden Staaten bietet es keinen aussagekräftigen Wert. -
Die
hasExecutionError
Wert wird mit allen Zweigzustandsmaschinen imParallel
status, was abhängig von der Reihenfolge, in der darauf zugegriffen wird, zu unerwarteten Ergebnissen führen kann.
Aufgrund dieser Eigenschaften empfehlen wir, diese Methode nicht zu verwenden, wenn Sie stattdessen einen Catch-Block verwenden können.
Beispiel für einen Zustandsautomaten
In diesem Abschnitt finden Sie einige Beispielkonfigurationen für Zustandsautomaten.
Beispiele
- Beispiel für einen Zustandsautomaten: Führen Sie eine einzelne Testgruppe aus
- Beispiel für einen Zustandsautomaten: Ausführen von vom Benutzer ausgewählten Testgruppen
- Beispiel für einen Zustandsautomaten: Führen Sie eine einzelne Testgruppe mit Produktfunktionen aus
- Beispiel für einen Zustandsautomaten: Führen Sie zwei Testgruppen parallel aus
Beispiel für einen Zustandsautomaten: Führen Sie eine einzelne Testgruppe aus
Dieser Zustandsautomat:
-
Führt die Testgruppe mit ID aus
GroupA
, die in der Suite in einem vorhanden sein mussgroup.json
file. -
Prüft auf Ausführungsfehler und Übergänge zu
Fail
falls welche gefunden werden. -
Generiert einen Bericht und wechselt zu
Succeed
wenn es keine Fehler gibt, undFail
Ansonsten .
{ "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" } } }
Beispiel für einen Zustandsautomaten: Ausführen von vom Benutzer ausgewählten Testgruppen
Dieser Zustandsautomat:
-
Prüft, ob der Testläufer bestimmte Testgruppen ausgewählt hat. Der Zustandsmaschine prüft nicht nach bestimmten Testfällen, da Testläufer Testfälle nicht auswählen können, ohne auch eine Testgruppe auszuwählen.
-
Wenn Testgruppen ausgewählt sind:
-
Führt die Testfälle innerhalb der ausgewählten Testgruppen aus. Zu diesem Zweck gibt der Zustandsmaschine keine Testgruppen oder Testfälle in der
RunTask
Status. -
Generiert einen Bericht, nachdem alle Tests und Exits ausgeführt wurden.
-
-
Wenn Testgruppen nicht ausgewählt sind:
-
Führt Tests in Testgruppe aus
GroupA
aus. -
Generiert Berichte und Exits.
-
{ "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" } } }
Beispiel für einen Zustandsautomaten: Führen Sie eine einzelne Testgruppe mit Produktfunktionen aus
Dieser Zustandsautomat:
-
Führt die Testgruppe aus
GroupA
aus. -
Prüft auf Ausführungsfehler und Übergänge zu
Fail
falls welche gefunden werden. -
Fügt den
FeatureThatDependsOnGroupA
Funktion zumawsiotdevicetester_report.xml
file:-
Wenn
GroupA
Pässe, die Funktion ist aufsupported
aus. -
Die Funktion ist im Bericht nicht als optional gekennzeichnet.
-
-
Generiert einen Bericht und wechselt zu
Succeed
wenn es keine Fehler gibt, undFail
ansonsten
{ "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" } } }
Beispiel für einen Zustandsautomaten: Führen Sie zwei Testgruppen parallel aus
Dieser Zustandsautomat:
-
Führt den
GroupA
undGroupB
Testgruppen parallel. DieResultVar
Variablen, die im Kontext von derRunTask
Zustände in den Zweigzustandsmaschinen von sind für dieAddProductFeatures
Status. -
Prüft auf Ausführungsfehler und Übergänge zu
Fail
falls welche gefunden werden. Dieser Zustandsmaschine verwendet keinCatch
blockieren, weil diese Methode keine Ausführungsfehler in Zweigzustandsmaschinen erkennt. -
Fügt Funktionen zum
awsiotdevicetester_report.xml
Datei basierend auf den Gruppen, die bestehen-
Wenn
GroupA
Pässe, die Funktion ist aufsupported
aus. -
Die Funktion ist im Bericht nicht als optional gekennzeichnet.
-
-
Generiert einen Bericht und wechselt zu
Succeed
wenn es keine Fehler gibt, undFail
ansonsten
Wenn zwei Geräte im Gerätepool konfiguriert sind, sind beideGroupA
undGroupB
kann gleichzeitig ausgeführt werden. Wenn jedoch entwederGroupA
oderGroupB
hat mehrere Tests, dann können beide Geräte diesen Tests zugeordnet werden. Wenn nur ein Gerät konfiguriert ist, werden die Testgruppen nacheinander ausgeführt.
{ "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" } } }