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 IDT v4.5.1 ist diese Zustandsmaschine veraltet. Wir empfehlen dringend, den neuen Test-Orchestrator zu verwenden. Weitere Informationen finden Sie unter [Konfigurieren Sie den IDT-Testorchestrator](idt-test-orchestrator.md). 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, generiert IDT 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 IDT ausführen 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 sein`Fail`. ## Format der Zustandsmaschine Sie können die folgende Vorlage verwenden, um Ihre eigene `/suite/state_machine.json` Datei zu konfigurieren: ``` { "Comment": "", "StartAt": "", "States": { "": { "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 IDT mit der Ausführung der Testsuite beginnt. Der Wert von `StartAt` muss auf einen der im `States` 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 dem zugeordnet ist*state-name*. Das `States` Objekt muss die `Fail` Zustände `Succeed` und enthalten. Hinweise zu gültigen Bundesstaaten finden Sie unter[Gültige Staaten und Bundesstaatendefinitionen](#valid-states). ## 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 Staaten 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. **Topics** + [RunTask](#state-runtask) + [Choice](#state-choice) + [Parallel](#state-parallel) + [AddProductFeatures](#state-addproductfeatures) + [Bericht](#state-report) + [LogMessage](#state-logmessage) + [SelectGroup](#state-selectgroup) + [Fehler](#state-fail) + [Succeed](#state-succeed) ### RunTask Der `RunTask` Staat führt Testfälle aus einer in der Testsuite definierten Testgruppe aus. ``` { "Type": "RunTask", "Next": "", "TestGroup": "", "TestCases": [ "" ], "ResultVar": "" } ``` 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, führt IDT die Testgruppe aus, die der Testläufer auswählt. `TestCases` Optional. Ein Array von Testfällen IDs aus der in `TestGroup` angegebenen Gruppe. Basierend auf den Werten von `TestGroup` und `TestCases` bestimmt IDT das Verhalten der Testausführung wie folgt: + Wenn `TestGroup` sowohl als auch angegeben `TestCases` sind, führt IDT die angegebenen Testfälle aus der Testgruppe aus. + Wenn `TestCases` angegeben, aber nicht angegeben `TestGroup` ist, führt IDT die angegebenen Testfälle aus. + Wenn `TestGroup` angegeben, aber nicht angegeben `TestCases` ist, führt IDT alle Testfälle innerhalb der angegebenen Testgruppe aus. + Wenn weder `TestGroup` oder angegeben `TestCases` 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 `RunTask` sowohl Status als auch `Choice` Status in Ihre `state_machine.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](#allow-specific-groups). Weitere Informationen zur Aktivierung von IDT-CLI-Befehlen für Testläufer finden Sie unter[IDT-CLI-Befehle aktivieren](create-test-executables.md#idt-cli-coop). `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`. IDT legt den Wert der Variablen, die Sie definieren, auf `true` oder `ResultVar` auf der `false` Grundlage der folgenden Werte fest: + Wenn der Variablenname die Form hat`text_text_passed`, wird der Wert darauf gesetzt, ob alle Tests in der ersten Testgruppe bestanden oder übersprungen wurden. + 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 anzugeben IDs, sodass IDT alle Testfälle in der angegebenen Testgruppe ausführt. 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 gesetzt`true`. ### 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": "", "FallthroughOnError": true | false, "Choices": [ { "Expression": "", "Next": "" } ] } ``` 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 den `Default` Status. Wenn der `FallthroughOnError` 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](#state-machine-context) `Choices.Next` Der Name des Zustands, zu dem der Übergang erfolgen soll, wenn der in definierte Ausdruck zu `Choices.Expression` ausgewertet wird. `true` **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 einstellen`false`. 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ätzliche `Choices` Blöcke, um den nächsten Status anzugeben. + Wenn eine Variable, auf die Sie zugreifen, immer existieren sollte, setzen Sie den `Default` Status auf`Fail`. ### Parallel Mit dem `Parallel` Status können Sie neue Zustandsmaschinen definieren und parallel zueinander ausführen. ``` { "Type": "Parallel", "Next": "", "Branches": [ ] } ``` 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`, und `Fail` -Zustände enthalten. Die Zustandsmaschinendefinitionen in diesem Array können nicht auf Zustände verweisen, die außerhalb ihrer eigenen Definition liegen. 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, um Ausführungsfehler zu beheben. 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 unter[Beispiel State Machine: Zwei Testgruppen parallel ausführen](#run-in-parallel). ### AddProductFeatures Mit `AddProductFeatures` diesem Status können Sie der von IDT generierten `awsiotdevicetester_report.xml` Datei Produktmerkmale hinzufügen. Bei einer Produktfunktion handelt es sich um benutzerdefinierte Informationen über bestimmte Kriterien, die ein Gerät möglicherweise erfüllt. Beispielsweise kann die `MQTT` Produktfunktion angeben, dass das Gerät MQTT-Nachrichten ordnungsgemäß veröffentlicht. Im Bericht werden Produktfunktionen als, oder als benutzerdefinierter Wert festgelegt `supported``not-supported`, je nachdem, ob die angegebenen Tests bestanden wurden. **Anmerkung** Der `AddProductFeatures` Staat generiert selbst keine Berichte. Dieser Status muss in den [`Report`Status](#state-report) übergehen, in dem Berichte generiert werden können. ``` { "Type": "Parallel", "Next": "", "Features": [ { "Feature": "", "Groups": [ "" ], "OneOfGroups": [ "" ], "TestCases": [ "" ], "IsRequired": true | false, "ExecutionMethods": [ "" ] } ] } ``` 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 auf `supported` oder gesetzt`not-supported`. Wenn Sie einen benutzerdefinierten Wert für verwenden`FeatureValue`, können Sie dasselbe Feature mit unterschiedlichen Bedingungen testen, und IDT verkettet die Feature-Werte für die unterstützten Bedingungen. Der folgende Auszug zeigt beispielsweise das `MyFeature` 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 Testgruppen IDs. Alle Tests innerhalb jeder angegebenen Testgruppe müssen bestanden werden, damit die Funktion unterstützt wird. `OneOfGroups` Optional. Ein Array von Testgruppen IDs. Alle Tests innerhalb mindestens einer der angegebenen Testgruppen müssen bestanden werden, damit die Funktion unterstützt wird. `TestCases` Optional. Eine Reihe von Testfällen IDs. 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 ist `true`. `ExecutionMethods` Optional. Eine Reihe von Ausführungsmethoden, die dem in der `device.json` Datei angegebenen `protocol` Wert entsprechen. Wenn dieser Wert angegeben ist, müssen Testläufer einen `protocol` 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 verwenden zu können, müssen Sie den Wert von `ResultVar` in the `RunTask` state auf einen der folgenden Werte festlegen: + Wenn Sie einen einzelnen Testfall angegeben haben IDs, legen Sie `ResultVar` den Wert auf fest`group-id_test-id_passed`. + Wenn Sie keinen individuellen Testfall angegeben haben IDs, legen Sie `ResultVar` den Wert auf fest`group-id_passed`. Der `AddProductFeatures` Staat sucht auf folgende Weise nach Testergebnissen: + Wenn Sie keinen Testfall angegeben haben IDs, wird das Ergebnis für jede Testgruppe anhand des Werts der `group-id_passed` Variablen im State-Machine-Kontext bestimmt. + Wenn Sie einen Testfall angegeben haben IDs, wird das Ergebnis für jeden der Tests anhand des Werts der `group-id_test-id_passed` Variablen im Zustandsmaschinen-Kontext bestimmt. **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 gesetzt`true`. ### Bericht Der `Report` Status generiert die `awsiotdevicetester_report.xml` Dateien `suite-name_Report.xml` und. In diesem Status wird der Bericht auch an die Konsole gestreamt. ``` { "Type": "Report", "Next": "" } ``` 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 Status`Succeed`. **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": "" "Level": "info | warn | error" "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": "" "TestGroups": [ " ] } ``` 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 `group-id_selected` Variable `true` im Kontext auf gesetzt. Stellen Sie sicher, dass Sie eine gültige Testgruppe angeben IDs , da IDT nicht überprüft, ob die angegebenen Gruppen existieren. ### Fehler Der `Fail` Status weist darauf hin, 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": { }, "userData": { }, "config": { }, "suiteFailed": true | false, "specificTestGroups": [ "" ], "specificTestCases": [ "" ], "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 einem `RunTask` Status ausfällt, wird dieser Wert `true` 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 Testgruppen IDs. `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älle IDs. `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`{{$.query}}`. In einigen Bundesstaaten können Sie JSONPath Abfragen als Platzhalterzeichenfolgen verwenden. IDT ersetzt die Platzhalterzeichenfolgen durch den Wert der ausgewerteten JSONPath Abfrage aus dem Kontext. Sie können Platzhalter für die folgenden Werte verwenden: + Der `TestCases` Wert in `RunTask` 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. [Verwenden Sie den IDT-Kontext](idt-context.md) ## Ausführungsfehler Ausführungsfehler sind Fehler in der Zustandsmaschinen-Definition, auf die der Zustandsmaschine bei der Ausführung eines Zustands stößt. IDT protokolliert 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 [`Catch`Block](#catch) hinzu. + Überprüfen Sie den [`hasExecutionErrors`Wert des Werts](#context) im Kontext der Zustandsmaschine. ### Fangen Um es zu verwenden`Catch`, fügen Sie Ihrer Bundesstaatendefinition Folgendes hinzu: ``` "Catch": [ { "ErrorEquals": [ "" ] "Next": "" } ] ``` 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 Status `false` für die `Choice` Staaten, die `FallthroughOnError` 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 wird`true`, und für alle nachfolgenden Zustände bietet er keinen aussagekräftigen Wert. + Der `hasExecutionError` Wert wird von allen Zweigstatusmaschinen im `Parallel` 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. **Topics** + [Beispiel für eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe aus](#single-test-group) + [Beispiel für eine Zustandsmaschine: Führen Sie vom Benutzer ausgewählte Testgruppen aus](#allow-specific-groups) + [Beispiel für eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe mit Produktfunktionen aus](#run-with-product-features) + [Beispiel State Machine: Zwei Testgruppen parallel ausführen](#run-in-parallel) ### 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 einer `group.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, und `Fail` 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 das `FeatureThatDependsOnGroupA` Feature hinzu: + Wenn der `GroupA` Wert erfolgreich ist, wird das Feature auf gesetzt`supported`. + Die Funktion ist im Bericht nicht als optional gekennzeichnet. + Generiert einen Bericht und wechselt zu, `Succeed` wenn keine Fehler vorliegen, und `Fail` 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 die `GroupB` Testgruppen parallel aus. Die `ResultVar` Variablen, die im Kontext der `RunTask` Bundesstaaten gespeichert sind, stehen dem `AddProductFeatures` Staat zur Verfügung. + Prüft auf Ausführungsfehler und wechselt, `Fail` falls welche gefunden wurden. Diese Zustandsmaschine verwendet keinen `Catch` 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 gesetzt`supported`. + Die Funktion ist im Bericht nicht als optional gekennzeichnet. + Generiert einen Bericht und wechselt zu, `Succeed` wenn keine Fehler vorliegen, und `Fail` 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" } } } ```