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 die IDT Zustandsmaschine
Wichtig
Ab Version IDT 4.5.2 ist diese Zustandsmaschine veraltet. Wir empfehlen dringend, den neuen Test-Orchestrator zu verwenden. Weitere Informationen finden Sie unter Konfigurieren Sie den IDT Test-Orchestrator.
Eine Zustandsmaschine ist ein Konstrukt, das den Ausführungsablauf der Testsuite steuert. Sie bestimmt den Startstatus einer Testsuite, verwaltet Zustandsübergänge auf der Grundlage benutzerdefinierter Regeln und setzt den Übergang durch diese Zustände fort, bis der Endstatus erreicht ist.
Wenn Ihre Testsuite keine benutzerdefinierte Zustandsmaschine enthält, IDT generiert sie eine Zustandsmaschine für Sie. Die Standard-Zustandsmaschine erfüllt die folgenden Funktionen:
-
Bietet Testläufern die Möglichkeit, anstelle der gesamten Testsuite bestimmte Testgruppen auszuwählen und auszuführen.
-
Wenn keine bestimmten Testgruppen ausgewählt sind, wird jede Testgruppe in der Testsuite in zufälliger Reihenfolge ausgeführt.
-
Generiert Berichte und druckt eine Konsolenübersicht aus, in der die Testergebnisse für jede Testgruppe und jeden Testfall angezeigt werden.
Die Zustandsmaschine für eine IDT Testsuite muss die folgenden Kriterien erfüllen:
-
Jeder Status entspricht einer Aktion, die ausgeführt werden IDT muss, z. B. dem Ausführen einer Testgruppe oder eines Produkts oder einer Berichtsdatei.
-
Beim Übergang zu einem Status wird die mit dem Status verknüpfte Aktion ausgeführt.
-
Jeder Status definiert die Übergangsregel für den nächsten Status.
-
Der Endstatus muss entweder
Succeed
oder seinFail
.
Format der Zustandsmaschine
Sie können die folgende Vorlage verwenden, um Ihre eigene
Datei zu konfigurieren: <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 der Zustandsmaschine.
StartAt
-
Der Name des Status, in dem die Ausführung der Testsuite IDT beginnt. Der Wert von
StartAt
muss auf einen der imStates
Objekt aufgelisteten Zustände gesetzt werden. States
-
Ein Objekt, das benutzerdefinierte Statusnamen gültigen IDT Staaten zuordnet. Jeder Bundesstaat.
state-name
Objekt enthält die Definition eines gültigen Zustands, der zugeordnet iststate-name
.Das
States
Objekt muss dieFail
ZuständeSucceed
und enthalten. Hinweise zu gültigen Bundesstaaten finden Sie unterGültige Staaten und Bundesstaatendefinitionen.
Gültige Staaten und Bundesstaatendefinitionen
In diesem Abschnitt werden die Zustandsdefinitionen aller gültigen Staaten beschrieben, die in der IDT Zustandsmaschine verwendet werden können. Einige der folgenden Zustände unterstützen Konfigurationen auf Testfallebene. Wir empfehlen jedoch, Regeln für den Statusübergang auf Testgruppenebene statt auf Testfallebene zu konfigurieren, sofern dies nicht unbedingt erforderlich ist.
Definitionen von Bundesstaaten
RunTask
Der RunTask
Staat führt Testfälle aus 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 Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
TestGroup
-
Optional. Die ID der Testgruppe, die ausgeführt werden soll. Wenn dieser Wert nicht angegeben ist, wird die Testgruppe IDT ausgeführt, die der Testläufer auswählt.
TestCases
-
Optional. Ein Array von Testfällen IDs aus der in angegebenen Gruppe
TestGroup
. Basierend auf den Werten vonTestGroup
undTestCases
IDT bestimmt das Verhalten der Testausführung wie folgt:-
Wenn
TestGroup
sowohl als auch angegebenTestCases
sind, werden die angegebenen Testfälle aus der Testgruppe IDT ausgeführt. -
Wenn angegeben, aber nicht angegeben
TestGroup
ist,TestCases
werden die angegebenen Testfälle IDT ausgeführt. -
Wenn
TestGroup
angegeben, aber nicht angegebenTestCases
ist, werden alle Testfälle innerhalb der angegebenen Testgruppe IDT ausgeführt. -
Wenn weder
TestGroup
oder angegebenTestCases
ist, werden alle Testfälle aus der Testgruppe IDT ausgeführt, die der Testläufer aus der auswählt IDTCLI. Um die Gruppenauswahl für Testläufer zu aktivieren, müssen SieRunTask
sowohl als auchChoice
Status in Ihrestatemachine.json
Datei aufnehmen. Ein Beispiel dafür, wie das funktioniert, finden Sie unter Beispiel für eine Zustandsmaschine: Vom Benutzer ausgewählte Testgruppen ausführen.Weitere Informationen zum Aktivieren von IDT CLI Befehlen für Testläufer finden Sie unterIDTCLIBefehle aktivieren.
-
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
. IDTlegt den Wert der Variablen, die Sie definieren, auftrue
oderResultVar
auf derfalse
Grundlage der folgenden Werte fest:-
Wenn der Variablenname die folgende Form hat
, wird der Wert darauf gesetzt, ob alle Tests in der ersten Testgruppe bestanden oder übersprungen wurden.text
_text
_passed -
In allen anderen Fällen wird der Wert darauf gesetzt, ob alle Tests in allen Testgruppen bestanden wurden oder ob sie übersprungen wurden.
-
In der Regel verwenden Sie RunTask
state, um eine Testgruppen-ID ohne Angabe eines einzelnen Testfalls anzugebenIDs, sodass alle Testfälle in der angegebenen Testgruppe ausgeführt IDT werden. Alle Testfälle, die von diesem Status ausgeführt werden, werden parallel in zufälliger Reihenfolge ausgeführt. 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 sequentiell ausgeführt.
Fehlerbehandlung
Wenn eine der angegebenen Testgruppen oder Testfälle nicht gültig ist, IDs gibt dieser Status den RunTaskError
Ausführungsfehler aus. Wenn im Status ein Ausführungsfehler auftritt, wird auch die hasExecutionError
Variable im Zustandsmaschinenkontext auf gesetzttrue
.
Choice
Mit Choice
diesem Status können Sie basierend auf benutzerdefinierten Bedingungen dynamisch den nächsten Status festlegen, zu dem der Übergang erfolgen soll.
{
"Type": "Choice",
"Default": "<state-name>
",
"FallthroughOnError": true | false,
"Choices": [
{
"Expression": "<expression>
",
"Next": "<state-name>
"
}
]
}
Nachfolgend sind alle Pflichtfelder beschrieben:
Default
-
Der Standardstatus, in den der Übergang erfolgen soll, wenn keiner der in definierten Ausdrücke ausgewertet werden
Choices
kann.true
FallthroughOnError
-
Optional. Gibt das Verhalten an, wenn der Status bei der Auswertung von Ausdrücken auf einen Fehler stößt. Legt fest,
true
ob Sie einen Ausdruck überspringen möchten, wenn die Auswertung zu einem Fehler führt. Wenn keine Ausdrücke übereinstimmen, wechselt die Zustandsmaschine in denDefault
Status. Wenn derFallthroughOnError
Wert nicht angegeben ist, wird standardmäßig der Wert verwendet.false
Choices
-
Eine Reihe von Ausdrücken und Zuständen, um zu bestimmen, in welchen Status nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
Choices.Expression
-
Eine Ausdruckszeichenfolge, die einen booleschen Wert ergibt. Wenn der Ausdruck zu ausgewertet wird
true
, geht die Zustandsmaschine in den Zustand über, der in definiert ist.Choices.Next
Ausdruckszeichenfolgen rufen Werte aus dem Zustandsmaschinen-Kontext ab und führen dann Operationen an ihnen durch, um einen booleschen Wert zu erhalten. Hinweise zum Zugriff auf den Zustandsmaschinenkontext finden Sie unter. Kontext der Zustandsmaschine Choices.Next
-
Der Name des Zustands, zu dem der Übergang erfolgen soll, wenn der in definierte Ausdruck zu
Choices.Expression
true
ausgewertet wird.
Fehlerbehandlung
In den folgenden Fällen kann für den Choice
Status eine Fehlerbehandlung erforderlich sein:
-
Einige Variablen in den Auswahlausdrücken sind im Zustandsmaschinen-Kontext nicht vorhanden.
-
Das Ergebnis eines Ausdrucks ist kein boolescher Wert.
-
Das Ergebnis einer JSON Suche ist keine Zeichenfolge, Zahl oder boolescher Wert.
In diesem Status können Sie keinen Catch
Block verwenden, um Fehler zu behandeln. Wenn Sie die Ausführung der Zustandsmaschine beenden möchten, wenn sie auf einen Fehler stößt, müssen Sie FallthroughOnError
auf einstellenfalse
. Wir empfehlen jedoch, dass Sie die Einstellung FallthroughOnError
auf true
festlegen und je nach Anwendungsfall eine der folgenden Aktionen ausführen:
-
Wenn davon ausgegangen wird, dass eine Variable, auf die Sie zugreifen, in einigen Fällen nicht existiert, verwenden Sie den Wert von
Default
und zusätzlicheChoices
Blöcke, um den nächsten Status anzugeben. -
Wenn eine Variable, auf die Sie zugreifen, immer existieren sollte, setzen Sie den
Default
Status aufFail
.
Parallel
Mit dem Parallel
Status können Sie neue Zustandsmaschinen definieren und parallel zueinander ausführen.
{
"Type": "Parallel",
"Next": "<state-name>
",
"Branches": [
<state-machine-definition>
]
}
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
Branches
-
Eine Reihe von Zustandsmaschinendefinitionen, die ausgeführt werden sollen. Jede Zustandsmaschinen-Definition muss ihre eigenen
StartAt
Succeed
, undFail
-Zustände enthalten. Die Zustandsmaschinendefinitionen in diesem Array können nicht auf Zustände verweisen, die außerhalb ihrer eigenen Definition liegen.Anmerkung
Da jeder Zustandsmaschine denselben Zustandsmaschinenkontext verwendet, kann das Setzen von Variablen in einem Zweig und das anschließende Lesen dieser Variablen aus einem anderen Zweig zu unerwartetem Verhalten führen.
Der Parallel
Status wechselt erst in den nächsten Status, nachdem er alle Branch-State-Machines ausgeführt hat. Jeder Status, für den ein Gerät erforderlich ist, wartet mit der 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 die Testfälle nacheinander ausgeführt. Da Testfälle in zufälliger Reihenfolge ausgeführt werden, wenn sie parallel ausgeführt werden, können verschiedene Geräte verwendet werden, um Tests derselben Testgruppe auszuführen.
Fehlerbehandlung
Stellen Sie sicher, dass sowohl die Zweigzustandsmaschine als auch die übergeordnete Zustandsmaschine in den Fail
Status wechseln, in dem Ausführungsfehler behoben werden.
Da Branch-State-Maschinen keine Ausführungsfehler an den übergeordneten Zustandsmaschinen übertragen, können Sie einen Catch
Block nicht verwenden, um Ausführungsfehler in Branch-State-Machines zu behandeln. Verwenden Sie den hasExecutionErrors
Wert stattdessen im Kontext des Shared State Machines. Ein Beispiel dafür, wie das funktioniert, finden Sie unterBeispiel State Machine: Zwei Testgruppen parallel ausführen.
AddProductFeatures
Mit AddProductFeatures
diesem Status können Sie der awsiotdevicetester_report.xml
Datei, die von generiert wurde, Produktmerkmale hinzufügenIDT.
Bei einer Produktfunktion handelt es sich um benutzerdefinierte Informationen über bestimmte Kriterien, die ein Gerät erfüllen könnte. Beispielsweise kann die MQTT
Produktfunktion angeben, dass das Gerät MQTT Nachrichten ordnungsgemäß veröffentlicht. Im Bericht werden die Produktmerkmale alssupported
, oder als benutzerdefinierter Wert festgelegtnot-supported
, je nachdem, ob die angegebenen Tests bestanden wurden.
Anmerkung
Der AddProductFeatures
Staat generiert selbst keine Berichte. Dieser Status muss in den ReportStatus übergehen, in dem Berichte generiert werden können.
{
"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 Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
Features
-
Eine Reihe von Produktfunktionen, die in der
awsiotdevicetester_report.xml
Datei angezeigt werden sollen.Feature
-
Der Name der Funktion
FeatureValue
-
Optional. Der benutzerdefinierte Wert, der anstelle von im Bericht verwendet werden soll
supported
. Wenn dieser Wert nicht angegeben ist, wird der Feature-Wert basierend auf den Testergebnissen aufsupported
oder gesetztnot-supported
.Wenn Sie einen benutzerdefinierten Wert für verwenden
FeatureValue
, können Sie dasselbe Feature mit unterschiedlichen Bedingungen testen und die Feature-Werte für die unterstützten Bedingungen IDT verketten. Der folgende Auszug zeigt beispielsweise dasMyFeature
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 erfolgreich sind, wird der Feature-Wert auf
first-feature-supported, second-feature-supported
gesetzt. Groups
-
Optional. Ein Array von TestgruppenIDs. Alle Tests innerhalb jeder angegebenen Testgruppe müssen bestanden werden, damit die Funktion unterstützt wird.
OneOfGroups
-
Optional. Ein Array von TestgruppenIDs. Alle Tests innerhalb mindestens einer der angegebenen Testgruppen müssen bestanden werden, damit die Funktion unterstützt wird.
TestCases
-
Optional. Eine Reihe von TestfällenIDs. Wenn Sie diesen Wert angeben, gilt Folgendes:
-
Alle angegebenen Testfälle müssen bestanden werden, damit die Funktion unterstützt wird.
-
Groups
darf nur eine Testgruppen-ID enthalten. -
OneOfGroups
darf nicht angegeben werden.
-
IsRequired
-
Optional. Stellen Sie auf ein
false
, um diese Funktion im Bericht als optionale Funktion zu kennzeichnen. Der Standardwert isttrue
. ExecutionMethods
-
Optional. Eine Reihe von Ausführungsmethoden, die dem in der
device.json
Datei angegebenenprotocol
Wert entsprechen. Wenn dieser Wert angegeben ist, müssen Testläufer einenprotocol
Wert angeben, der einem der Werte in diesem Array entspricht, um das Feature in den Bericht aufzunehmen. Wenn dieser Wert nicht angegeben wird, wird das Feature immer in den Bericht aufgenommen.
Um den AddProductFeatures
Status zu verwenden, müssen Sie den Wert von ResultVar
in the RunTask
state auf einen der folgenden Werte festlegen:
-
Wenn Sie einen einzelnen Testfall angegeben habenIDs, setzen Sie ihn
ResultVar
auf
.group-id_test-id
_passed -
Wenn Sie keinen individuellen Testfall angegeben habenIDs, setzen Sie
ResultVar
den Wert auf
.group-id
_passed
Der AddProductFeatures
Staat sucht auf folgende Weise nach Testergebnissen:
-
Wenn Sie keinen Testfall angegeben habenIDs, wird das Ergebnis für jede Testgruppe anhand des Werts der
Variablen im State-Machine-Kontext bestimmt.group-id
_passed -
Wenn Sie einen Testfall angegeben habenIDs, wird das Ergebnis für jeden der Tests anhand des Werts der
Variablen im Zustandsmaschinen-Kontext bestimmt.group-id_test-id
_passed
Fehlerbehandlung
Wenn eine in diesem Status angegebene Gruppen-ID keine gültige Gruppen-ID ist, führt dieser Status zu einem AddProductFeaturesError
Ausführungsfehler. Wenn im Status ein Ausführungsfehler auftritt, wird auch die hasExecutionErrors
Variable im Zustandsmaschinenkontext auf gesetzttrue
.
Bericht
Der Report
Status generiert die awsiotdevicetester_report.xml
Dateien
und. In diesem Status wird der Bericht auch an die Konsole gestreamt.suite-name
_Report.xml
{
"Type": "Report",
"Next": "<state-name>
"
}
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
Sie sollten immer gegen Ende der Testausführung in den Report
Status wechseln, damit Testläufer die Testergebnisse einsehen können. In der Regel ist der nächste Status nach diesem StatusSucceed
.
Fehlerbehandlung
Wenn in diesem Status Probleme beim Generieren der Berichte auftreten, wird der ReportError
Ausführungsfehler ausgegeben.
LogMessage
Der LogMessage
Status generiert die test_manager.log
Datei und streamt die Protokollnachricht an die Konsole.
{
"Type": "LogMessage",
"Next": "<state-name>
"
"Level": "info | warn | error"
"Message": "<message>
"
}
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
Level
-
Die Fehlerstufe, auf der die Protokollnachricht erstellt werden soll. Wenn Sie eine ungültige Stufe angeben, generiert dieser Status eine Fehlermeldung und verwirft sie.
Message
-
Die zu protokollierende Nachricht.
SelectGroup
Der SelectGroup
Status aktualisiert den Kontext der Zustandsmaschine, um anzugeben, welche Gruppen ausgewählt wurden. Die in diesem Status festgelegten Werte werden von allen nachfolgenden Choice
Staaten verwendet.
{
"Type": "SelectGroup",
"Next": "<state-name>
"
"TestGroups": [
<group-id>
"
]
}
Nachfolgend sind alle Pflichtfelder beschrieben:
Next
-
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
TestGroups
-
Eine Reihe von Testgruppen, die als ausgewählt markiert werden. Für jede Testgruppen-ID in diesem Array wird die
Variablegroup-id
_selectedtrue
im Kontext auf gesetzt. Stellen Sie sicher, dass Sie eine gültige Testgruppe angebenIDs, da IDT nicht überprüft wird, ob die angegebenen Gruppen existieren.
Fehler
Der Fail
Status gibt an, dass die Zustandsmaschine nicht korrekt ausgeführt wurde. Dies ist ein Endzustand für die Zustandsmaschine, und jede Zustandsmaschine muss diesen Zustand enthalten.
{
"Type": "Fail"
}
Succeed
Der Succeed
Status gibt an, dass die Zustandsmaschine korrekt ausgeführt wurde. Dies ist ein Endzustand für die Zustandsmaschine, und jede Zustandsmaschine muss diesen Zustand enthalten.
{
"Type": "Succeed"
}
Kontext der Zustandsmaschine
Der Zustandsmaschinenkontext ist ein schreibgeschütztes JSON Dokument, das Daten enthält, die der Zustandsmaschine während der Ausführung zur Verfügung stehen. Der Zustandsmaschinen-Kontext ist nur von der Zustandsmaschine aus zugänglich und enthält Informationen, die den Testablauf bestimmen. Sie können beispielsweise Informationen verwenden, die von Testläufern in der userdata.json
Datei konfiguriert wurden, um festzustellen, ob ein bestimmter Test ausgeführt werden muss.
Der State-Machine-Kontext 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
Datei definiert ist. userData
-
Informationen in der
userdata.json
Datei. config
-
Informationen an die
config.json
Datei anheften. suiteFailed
-
Der Wert wird auf den
false
Zeitpunkt gesetzt, zu dem die Zustandsmaschine gestartet wird. Wenn eine Testgruppe in einemRunTask
Status ausfällt, wird dieser Werttrue
für die verbleibende Dauer der State-Machine-Ausführung auf gesetzt. specificTestGroups
-
Wenn der Testläufer anstelle der gesamten Testsuite bestimmte Testgruppen zur Ausführung auswählt, wird dieser Schlüssel erstellt und enthält die Liste der spezifischen TestgruppenIDs.
specificTestCases
-
Wenn der Testläufer anstelle der gesamten Testsuite bestimmte Testfälle zur Ausführung auswählt, wird dieser Schlüssel erstellt und enthält die Liste der spezifischen TestfälleIDs.
hasExecutionErrors
-
Wird nicht beendet, wenn die Zustandsmaschine gestartet wird. Wenn in einem Status ein Ausführungsfehler auftritt, wird diese Variable erstellt und
true
für die verbleibende Dauer der State-Machine-Ausführung auf „gesetzt“.
Sie können den Kontext mithilfe der JSONPath Notation abfragen. Die Syntax für JSONPath Abfragen in Statusdefinitionen lautet{{$.
. In einigen Bundesstaaten können Sie JSONPath Abfragen als Platzhalterzeichenfolgen verwenden. IDTersetzt die Platzhalterzeichenfolgen durch den Wert der ausgewerteten JSONPath Abfrage aus dem Kontext. Sie können Platzhalter für die folgenden Werte verwenden:query
}}
-
Der
TestCases
Wert inRunTask
Bundesstaaten. -
Der
Expression
Choice
Wertstatus.
Wenn Sie auf Daten aus dem State Machine-Kontext zugreifen, stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:
-
Ihre JSON Pfade müssen beginnen mit
$.
-
Jeder Wert muss eine Zeichenfolge, eine Zahl oder einen booleschen Wert ergeben.
Weitere Hinweise zur Verwendung der JSONPath Notation für den Zugriff auf Daten aus dem Kontext finden Sie unter. Benutze den IDT Kontext
Ausführungsfehler
Ausführungsfehler sind Fehler in der Zustandsmaschinen-Definition, auf die der Zustandsmaschine bei der Ausführung eines Zustands stößt. IDTprotokolliert Informationen zu jedem Fehler in der test_manager.log
Datei und streamt die Protokollnachricht an die Konsole.
Sie können die folgenden Methoden verwenden, um Ausführungsfehler zu behandeln:
-
Fügen Sie der Statusdefinition einen CatchBlock hinzu.
-
Überprüfen Sie den hasExecutionErrorsWert des Werts im Kontext der Zustandsmaschine.
Fangen
Um es zu verwendenCatch
, fügen Sie Ihrer Bundesstaatendefinition Folgendes hinzu:
"Catch": [
{
"ErrorEquals": [
"<error-type>
"
]
"Next": "<state-name>
"
}
]
Nachfolgend sind alle Pflichtfelder beschrieben:
Catch.ErrorEquals
-
Eine Reihe von Fehlertypen, die abgefangen werden sollen. Wenn ein Ausführungsfehler mit einem der angegebenen Werte übereinstimmt, wechselt die Zustandsmaschine in den unter angegebenen Status
Catch.Next
. In den einzelnen Statusdefinitionen finden Sie Informationen zur Art des Fehlers, den sie erzeugt. Catch.Next
-
Der nächste Status, in den übergegangen werden soll, wenn im aktuellen Status ein Ausführungsfehler auftritt, der einem der in angegebenen Werte entspricht
Catch.ErrorEquals
.
Catch-Blöcke werden sequentiell behandelt, bis einer übereinstimmt. Wenn der Wert „Keine Fehler“ mit den in den Catch-Blöcken aufgelisteten Fehlern übereinstimmt, wird die Ausführung der Zustandsmaschinen fortgesetzt. Da Ausführungsfehler auf falsche Statusdefinitionen zurückzuführen sind, empfehlen wir, dass Sie in den Status Fail wechseln, wenn in einem Status ein Ausführungsfehler auftritt.
hasExecutionError
Wenn in einigen Staaten Ausführungsfehler auftreten, geben sie nicht nur den Fehler aus, sondern setzen den hasExecutionError
Wert auch true
im Kontext der Zustandsmaschine auf. Sie können diesen Wert verwenden, um zu erkennen, wann ein Fehler auftritt, und dann einen Choice
Status verwenden, um die Zustandsmaschine in den Fail
Status zu versetzen.
Diese Methode hat die folgenden Eigenschaften.
-
Die Zustandsmaschine beginnt mit keinem Wert, der zugewiesen wurde
hasExecutionError
, und dieser Wert ist erst verfügbar, wenn ein bestimmter Status ihn festlegt. Das bedeutet, dass Sie den Statusfalse
für dieChoice
Staaten, dieFallthroughOnError
auf diesen Wert zugreifen, explizit auf setzen müssen, um zu verhindern, dass der Zustandsmaschine angehalten wird, wenn keine Ausführungsfehler auftreten. -
Sobald der Wert auf gesetzt ist
true
,hasExecutionError
wird er niemals auf False gesetzt oder aus dem Kontext entfernt. Das bedeutet, dass dieser Wert nur nützlich ist, wenn er zum ersten Mal auf gesetzt wirdtrue
, und für alle nachfolgenden Zustände bietet er keinen aussagekräftigen Wert. -
Der
hasExecutionError
Wert wird von allen Zweigzustandsmaschinen imParallel
Bundesstaat gemeinsam genutzt, was je nach Reihenfolge, in der auf ihn zugegriffen wird, zu unerwarteten Ergebnissen führen kann.
Aufgrund dieser Eigenschaften empfehlen wir nicht, diese Methode zu verwenden, wenn Sie stattdessen einen Catch-Block verwenden können.
Beispiel für Zustandsmaschinen
Dieser Abschnitt enthält einige Beispielkonfigurationen von Zustandsmaschinen.
Beispiele
- Beispiel für eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe aus
- Beispiel für eine Zustandsmaschine: Führen Sie vom Benutzer ausgewählte Testgruppen aus
- Beispiel für eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe mit Produktfunktionen aus
- Beispiel State Machine: Zwei Testgruppen parallel ausführen
Beispiel für eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe aus
Dieser Zustandsmaschine:
-
Führt die Testgruppe mit der ID aus
GroupA
, die in der Suite in einergroup.json
Datei vorhanden sein muss. -
Prüft auf Ausführungsfehler und wechselt zu,
Fail
ob welche gefunden wurden. -
Generiert einen Bericht und wechselt zu,
Succeed
ob keine Fehler vorliegen, undFail
andernfalls.
{
"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 eine Zustandsmaschine: Führen Sie vom Benutzer ausgewählte Testgruppen aus
Dieser Zustandsmaschine:
-
Prüft, ob der Testläufer bestimmte Testgruppen ausgewählt hat. Die Zustandsmaschine sucht nicht nach bestimmten Testfällen, da Testläufer keine Testfälle 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 spezifiziert die Zustandsmaschine nicht explizit Testgruppen oder Testfälle im
RunTask
Status. -
Generiert einen Bericht, nachdem alle Tests ausgeführt und beendet wurden.
-
-
Wenn keine Testgruppen ausgewählt sind:
-
Führt Tests in einer Testgruppe aus
GroupA
. -
Generiert Berichte und beendet das Programm.
-
{
"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 eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe mit Produktfunktionen aus
Dieser Zustandsmaschine:
-
Führt die Testgruppe aus
GroupA
. -
Prüft auf Ausführungsfehler und wechselt,
Fail
ob welche gefunden wurden. -
Fügt der
awsiotdevicetester_report.xml
Datei dasFeatureThatDependsOnGroupA
Feature hinzu:-
Wenn der
GroupA
Wert erfolgreich ist, wird das Feature auf gesetztsupported
. -
Die Funktion ist im Bericht nicht als optional gekennzeichnet.
-
-
Generiert einen Bericht und wechselt zu,
Succeed
wenn keine Fehler vorliegen, undFail
andernfalls
{
"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 State Machine: Zwei Testgruppen parallel ausführen
Diese Zustandsmaschine:
-
Führt die Gruppen
GroupA
und dieGroupB
Testgruppen parallel aus. DieResultVar
Variablen, die im Kontext derRunTask
Bundesstaaten gespeichert sind, stehen demAddProductFeatures
Staat zur Verfügung. -
Prüft auf Ausführungsfehler und wechselt,
Fail
falls welche gefunden wurden. Diese Zustandsmaschine verwendet keinenCatch
Block, da diese Methode keine Ausführungsfehler in Zweigzustandsmaschinen erkennt. -
Fügt der
awsiotdevicetester_report.xml
Datei Funktionen hinzu, die auf den Gruppen basieren, die erfolgreich sind-
Bei
GroupA
erfolgreicher Prüfung wird das Feature auf gesetztsupported
. -
Die Funktion ist im Bericht nicht als optional gekennzeichnet.
-
-
Generiert einen Bericht und wechselt zu,
Succeed
wenn keine Fehler vorliegen, undFail
andernfalls
Wenn zwei Geräte im Gerätepool konfiguriert sind, GroupB
können beide GroupA
Geräte gleichzeitig ausgeführt werden. Wenn jedoch einer GroupA
oder GroupB
mehrere Tests enthalten sind, können beide Geräte diesen Tests zugewiesen 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"
}
}
}