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 des IDT-Testorchestrators
Ab IDT v4.5.2 enthält IDT eine neue Testorchestratorkomponente. Der Testorchestrator ist eine IDT-Komponente, die den Ausführungsablauf der Testsuite steuert und den Testbericht generiert, nachdem IDT die Ausführung aller Tests abgeschlossen hat. Der Testorchestrator bestimmt die Testauswahl und die Reihenfolge, in der Tests ausgeführt werden, basierend auf benutzerdefinierten Regeln.
Wenn Ihre Testsuite keinen benutzerdefinierten Testorchestrator enthält, generiert IDT einen Testorchestrator für Sie.
Der Standard-Testorchestrator führt die folgenden Funktionen aus:
-
Bietet Test Runnern die Möglichkeit, bestimmte Testgruppen anstelle der gesamten Testsuite auszuwählen und auszuführen.
-
Wenn bestimmte Testgruppen nicht ausgewählt sind, führt jede Testgruppe in der Testsuite in zufälliger Reihenfolge aus.
-
Generiert Berichte und druckt eine Konsolenübersicht, die die Testergebnisse für jede Testgruppe und jeden Testfall anzeigt.
Der Testorchestrator ersetzt den IDT-Zustandsautomaten. Wir empfehlen dringend, dass Sie den Testorchestrator verwenden, um Ihre Testsuiten anstelle des IDT-Zustandsautomaten zu entwickeln. Der Testorchestrator bietet die folgenden verbesserten Funktionen:
-
Verwendet ein deklaratives Format im Vergleich zu dem exakten Format, das der IDT-Zustandsautomat verwendet. Auf diese Weise können Sie angeben, welche Tests Sie ausführen möchten und wann Sie sie ausführen möchten.
-
Verwaltet die Verarbeitung bestimmter Gruppen, die Erstellung von Berichten, die Fehlerbehandlung und die Ergebnisverfolgung, sodass Sie diese Aktionen nicht manuell verwalten müssen.
-
Verwendet das YAML-Format, das standardmäßig Kommentare unterstützt.
-
Benötigt 80 Prozent weniger Festplattenspeicher als der Testorchestrator, um denselben Workflow zu definieren.
-
Fügt eine Vortestvalidierung hinzu, um zu überprüfen, ob Ihre Workflow-Definition keine falschen Test-IDs oder Zirkelbezüge enthält.
Testen des Orchestratorformats
Sie können die folgende Vorlage verwenden, um Ihre eigene
Datei zu konfigurieren: custom-test-suite-folder
/suite/test_orchestrator.yaml
Aliases:
string
:context-expression
ConditionalTests: - Condition:context-expression
Tests: -test-descriptor
Order: - -group-descriptor
-group-descriptor
Features: - Name:feature-name
Value:support-description
Condition:context-expression
Tests: -test-descriptor
OneOfTests: -test-descriptor
IsRequired:boolean
Nachfolgend sind alle Pflichtfelder beschrieben:
Aliases
-
Optional. Benutzerdefinierte Zeichenfolgen, die Kontextausdrücken zugeordnet werden. Mit Aliassen können Sie Anzeigenamen generieren, um Kontextausdrücke in Ihrer Testorchestrator-Konfiguration zu identifizieren. Dies ist besonders nützlich, wenn Sie komplexe Kontextausdrücke oder Ausdrücke erstellen, die Sie an mehreren Stellen verwenden.
Sie können Kontextausdrücke verwenden, um Kontextabfragen zu speichern, mit denen Sie auf Daten aus anderen IDT-Konfigurationen zugreifen können. Weitere Informationen finden Sie unter Zugriff auf Daten im Kontext.
Beispiel
Aliases: FizzChosen: "'{{$pool.features[?(@.name == 'Fizz')].value[0]}}' == 'yes'" BuzzChosen: "'{{$pool.features[?(@.name == 'Buzz')].value[0]}}' == 'yes'" FizzBuzzChosen: "'{{$aliases.FizzChosen}}' && '{{$aliases.BuzzChosen}}'"
ConditionalTests
-
Optional. Eine Liste von Bedingungen und die entsprechenden Testfälle, die ausgeführt werden, wenn jede Bedingung erfüllt ist. Jede Bedingung kann mehrere Testfälle haben. Sie können jedoch nur einer Bedingung einen bestimmten Testfall zuweisen.
Standardmäßig führt IDT jeden Testfall aus, der keiner Bedingung in dieser Liste zugewiesen ist. Wenn Sie diesen Abschnitt nicht angeben, führt IDT alle Testgruppen in der Testsuite aus.
Jedes Element in der
ConditionalTests
Liste enthält die folgenden Parameter:Condition
-
Ein Kontextausdruck, der zu einem booleschen Wert ausgewertet wird. Wenn der ausgewertete Wert „true“ ist, führt IDT die Testfälle aus, die im
Tests
Parameter angegeben sind. Tests
-
Die Liste der Testdeskriptoren.
Jeder Testdeskriptor verwendet die Testgruppen-ID und eine oder mehrere Testfall-IDs, um die einzelnen Tests zu identifizieren, die von einer bestimmten Testgruppe ausgeführt werden sollen. Der Testdeskriptor verwendet das folgende Format:
GroupId:
group-id
CaseIds: [test-id
,test-id
] # optional
Beispiel
Im folgenden Beispiel werden generische Kontextausdrücke verwendet, die Sie als definieren können
Aliases
.ConditionalTests: - Condition: "{{$aliases.Condition1}}" Tests: - GroupId: A - GroupId: B - Condition: "{{$aliases.Condition2}}" Tests: - GroupId: D - Condition: "{{$aliases.Condition1}} || {{$aliases.Condition2}}" Tests: - GroupId: C
Basierend auf den definierten Bedingungen wählt IDT Testgruppen wie folgt aus:
-
Wenn „true“
Condition1
ist, führt IDT die Tests in den Testgruppen A, B und C aus. -
Wenn „true“
Condition2
ist, führt IDT die Tests in den Testgruppen C und D aus.
Order
-
Optional. Die Reihenfolge, in der Tests ausgeführt werden sollen. Sie geben die Testreihenfolge auf Testgruppenebene an. Wenn Sie diesen Abschnitt nicht angeben, führt IDT alle entsprechenden Testgruppen in zufälliger Reihenfolge aus. Der Wert von
Order
ist eine Liste von Gruppendeskriptorlisten. Jede Testgruppe, die Sie nicht in auflistenOrder
, kann parallel zu jeder anderen aufgelisteten Testgruppe ausgeführt werden.Jede Gruppendeskriptorliste enthält einen oder mehrere Gruppendeskriptoren und gibt die Reihenfolge an, in der die in jedem Deskriptor angegebenen Gruppen ausgeführt werden sollen. Sie können die folgenden Formate verwenden, um einzelne Gruppendeskriptoren zu definieren:
-
– Die Gruppen-ID einer vorhandenen Testgruppe.group-id
-
[
– Liste der Testgruppen, die in beliebiger Reihenfolge relativ zueinander ausgeführt werden können.group-id
,group-id
] -
"*"
– Platzhalter. Dies entspricht der Liste aller Testgruppen, die noch nicht in der aktuellen Gruppendeskriptorliste angegeben sind.
Der Wert für
Order
muss auch die folgenden Anforderungen erfüllen:-
Testgruppen-IDs, die Sie in einem Gruppendeskriptor angeben, müssen in Ihrer Testsuite vorhanden sein.
-
Jede Gruppenbeschreibungsliste muss mindestens eine Testgruppe enthalten.
-
Jede Gruppenbeschreibungsliste muss eindeutige Gruppen-IDs enthalten. Sie können eine Testgruppen-ID nicht innerhalb einzelner Gruppendeskriptoren wiederholen.
-
Eine Gruppendeskriptorliste kann höchstens einen Platzhaltergruppendeskriptor haben. Der Platzhaltergruppendeskriptor muss das erste oder letzte Element in der Liste sein.
Beispiel
Für eine Testsuite, die Testgruppen A, B, C, D und E enthält, zeigt die folgende Liste von Beispielen verschiedene Möglichkeiten, anzugeben, dass IDT zuerst Testgruppe A, dann Testgruppe B und dann Testgruppen C, D und E in beliebiger Reihenfolge ausführen soll.
-
Order: - - A - B - [C, D, E]
-
Order: - - A - B - "*"
-
Order: - - A - B - - B - C - - B - D - - B - E
-
Features
-
Optional. Die Liste der Produktfunktionen, die IDT der
awsiotdevicetester_report.xml
Datei hinzufügen soll. Wenn Sie diesen Abschnitt nicht angeben, fügt IDT dem Bericht keine Produktfunktionen hinzu.Ein Produktfeature sind benutzerdefinierte Informationen zu bestimmten Kriterien, die ein Gerät möglicherweise erfüllt. Das MQTT-Produktfeature kann beispielsweise festlegen, dass das Gerät MQTT-Nachrichten ordnungsgemäß veröffentlicht. In werden
awsiotdevicetester_report.xml
Produktfunktionen alssupported
, oder ein benutzerdefinierter benutzerdefinierter Wert festgelegt, je nachdemnot-supported
, ob die angegebenen Tests bestanden wurden.Jedes Element in der
Features
Liste besteht aus den folgenden Parametern:Name
-
Der Name des Features.
Value
-
Optional. Der benutzerdefinierte Wert, den Sie im Bericht anstelle von verwenden möchten
supported
. Wenn dieser Wert nicht angegeben wird, legt basierend auf IDT den Feature-Wert aufsupported
odernot-supported
basierend auf den Testergebnissen fest. Wenn Sie dasselbe Feature mit unterschiedlichen Bedingungen testen, können Sie für jede Instance dieses Features in derFeatures
Liste einen benutzerdefinierten Wert verwenden, und IDT verkettet die Feature-Werte für unterstützte Bedingungen. Weitere Informationen finden Sie unter Condition
-
Ein Kontextausdruck, der zu einem booleschen Wert ausgewertet wird. Wenn der ausgewertete Wert wahr ist, fügt IDT das Feature dem Testbericht hinzu, nachdem es die Ausführung der Testsuite abgeschlossen hat. Wenn der ausgewertete Wert „false“ ist, ist der Test nicht im Bericht enthalten.
Tests
-
Optional. Die Liste der Testdeskriptoren. Alle in dieser Liste angegebenen Tests müssen bestanden werden, damit das Feature unterstützt wird.
Jeder Testdeskriptor in dieser Liste verwendet die Testgruppen-ID und eine oder mehrere Testfall-IDs, um die einzelnen Tests zu identifizieren, die aus einer bestimmten Testgruppe ausgeführt werden sollen. Der Testdeskriptor verwendet das folgende Format:
GroupId:
group-id
CaseIds: [test-id
,test-id
] # optionalSie müssen entweder
Tests
oderOneOfTests
für jedes Feature in derFeatures
Liste angeben. OneOfTests
-
Optional. Die Liste der Testdeskriptoren. Mindestens einer der in dieser Liste angegebenen Tests muss bestanden werden, damit das Feature unterstützt wird.
Jeder Testdeskriptor in dieser Liste verwendet die Testgruppen-ID und eine oder mehrere Testfall-IDs, um die einzelnen Tests zu identifizieren, die aus einer bestimmten Testgruppe ausgeführt werden sollen. Der Testdeskriptor verwendet das folgende Format:
GroupId:
group-id
CaseIds: [test-id
,test-id
] # optionalSie müssen entweder
Tests
oderOneOfTests
für jedes Feature in derFeatures
Liste angeben. IsRequired
-
Der boolesche Wert, der definiert, ob das Feature im Testbericht erforderlich ist. Der Standardwert ist
false
.
Orchestratorkontext testen
Der Testorchestrator-Kontext ist ein schreibgeschütztes JSON-Dokument, das Daten enthält, die dem Testor während der Ausführung zur Verfügung stehen. Der Testorchestrator-Kontext ist nur vom Testorchestrator aus zugänglich und enthält Informationen, die den Testfluss bestimmen. Sie können beispielsweise Informationen verwenden, die von Test Runnern in der Datei konfiguriert wurdenuserdata.json
, um festzustellen, ob ein bestimmter Test ausgeführt werden muss.
Der Testorchestrator-Kontext verwendet das folgende Format:
{ "pool": {
<device-json-pool-element>
}, "userData": {<userdata-json-content>
}, "config": {<config-json-content>
} }
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 in der -
config.json
Datei.
Sie können den Kontext mit der JSONPath-Notation abfragen. Die Syntax für JSONPath-Abfragen in Statusdefinitionen ist {{
. Wenn Sie auf Daten aus dem Kontext des Testorchestrators zugreifen, stellen Sie sicher, dass jeder Wert zu einer Zeichenfolge, einer Zahl oder einem booleschen Wert ausgewertet wird.query
}}
Weitere Informationen zur Verwendung der JSONPath-Notation für den Zugriff auf Daten aus dem Kontext finden Sie unter Verwenden des IDT-Kontexts.