Konfigurieren des IDT-Testorchestrators - FreeRTOS

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 custom-test-suite-folder/suite/test_orchestrator.yaml Datei zu konfigurieren:

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önnenAliases.

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:

  • group-id– Die Gruppen-ID einer vorhandenen Testgruppe.

  • [group-id, group-id]– Liste der Testgruppen, die in beliebiger Reihenfolge relativ zueinander ausgeführt werden können.

  • "*"– 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.xmlProduktfunktionen als supported, 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öchtensupported. Wenn dieser Wert nicht angegeben wird, legt basierend auf IDT den Feature-Wert auf supported oder not-supported basierend auf den Testergebnissen fest. Wenn Sie dasselbe Feature mit unterschiedlichen Bedingungen testen, können Sie für jede Instance dieses Features in der Features 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] # optional

Sie müssen entweder Tests oder OneOfTests für jedes Feature in der Features 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] # optional

Sie müssen entweder Tests oder OneOfTests für jedes Feature in der Features 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.jsonDatei.

config

Informationen in der -config.jsonDatei.

Sie können den Kontext mit der JSONPath-Notation abfragen. Die Syntax für JSONPath-Abfragen in Statusdefinitionen ist {{query}}. 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.

Weitere Informationen zur Verwendung der JSONPath-Notation für den Zugriff auf Daten aus dem Kontext finden Sie unter Verwenden des IDT-Kontexts.