View a markdown version of this page

Erstellen Sie eine ausführbare IDT-Testfalldatei - FreeRTOS
Verwenden Sie das IDT Client SDKAktivieren Sie IDT-CLI-BefehleSchreiben Sie EreignisprotokolleErgebnisse an IDT meldenGeben Sie das Verhalten beim Verlassen an

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.

Erstellen Sie eine ausführbare IDT-Testfalldatei

Sie können die ausführbare Testfalldatei auf folgende Weise erstellen und in einem Testsuite-Ordner platzieren:

  • Für Testsuiten, die Argumente oder Umgebungsvariablen aus den test.json Dateien verwenden, um zu bestimmen, welche Tests ausgeführt werden sollen, können Sie einen einzelnen ausführbaren Testfall für die gesamte Testsuite oder eine Testdatei für jede Testgruppe in der Testsuite erstellen.

  • Für eine Testsuite, in der Sie bestimmte Tests auf der Grundlage bestimmter Befehle ausführen möchten, erstellen Sie für jeden Testfall in der Testsuite einen ausführbaren Testfall.

Als Testautor können Sie bestimmen, welcher Ansatz für Ihren Anwendungsfall geeignet ist, und Ihre Testfall-Programmdatei entsprechend strukturieren. Stellen Sie sicher, dass Sie in jeder test.json Datei den richtigen Pfad zur ausführbaren Testfalldatei angeben und dass die angegebene ausführbare Datei korrekt ausgeführt wird.

Wenn alle Geräte für die Ausführung eines Testfalls bereit sind, liest IDT die folgenden Dateien:

  • Der test.json für den ausgewählten Testfall bestimmt die zu startenden Prozesse und die zu setzenden Umgebungsvariablen.

  • Die suite.json für die Testsuite bestimmt die zu setzenden Umgebungsvariablen.

IDT startet den erforderlichen ausführbaren Testprozess auf der Grundlage der in der test.json Datei angegebenen Befehle und Argumente und übergibt die erforderlichen Umgebungsvariablen an den Prozess.

Verwenden Sie das IDT Client SDK

Mit den IDT-Client-SDKs können Sie das Schreiben von Testlogik in Ihre ausführbare Testdatei mit API-Befehlen vereinfachen, die Sie für die Interaktion mit IDT und Ihren zu testenden Geräten verwenden können. IDT bietet derzeit die folgenden SDKs:

  • IDT-Client-SDK für Python

  • IDT-Client-SDK für Go

  • IDT-Client-SDK für Java

Diese SDKs befinden sich im <device-tester-extract-location>/sdks Ordner. Wenn Sie eine neue ausführbare Testfalldatei erstellen, müssen Sie das SDK, das Sie verwenden möchten, in den Ordner kopieren, der die ausführbare Testfalldatei enthält, und in Ihrem Code auf das SDK verweisen. Dieser Abschnitt enthält eine kurze Beschreibung der verfügbaren API-Befehle, die Sie in Ihren ausführbaren Testfalldateien verwenden können.

Interaktion mit dem Gerät

Mit den folgenden Befehlen können Sie mit dem zu testenden Gerät kommunizieren, ohne zusätzliche Funktionen zur Geräteinteraktions- und Konnektivitätsverwaltung implementieren zu müssen.

ExecuteOnDevice

Ermöglicht Testsuiten, Shell-Befehle auf einem Gerät auszuführen, das SSH- oder Docker-Shell-Verbindungen unterstützt.

CopyToDevice

Ermöglicht Testsuiten, eine lokale Datei vom Host-Computer, auf dem IDT ausgeführt wird, an einen bestimmten Speicherort auf einem Gerät zu kopieren, das SSH- oder Docker-Shell-Verbindungen unterstützt.

ReadFromDevice

Ermöglicht Testsuiten, von der seriellen Schnittstelle von Geräten zu lesen, die UART-Verbindungen unterstützen.

Anmerkung

Da IDT keine direkten Verbindungen zu Geräten verwaltet, die mithilfe von Gerätezugriffsinformationen aus dem Kontext hergestellt werden, empfehlen wir, diese API-Befehle für die Geräteinteraktion in Ihren ausführbaren Testfalldateien zu verwenden. Wenn diese Befehle jedoch nicht Ihren Testfallanforderungen entsprechen, können Sie Gerätezugriffsinformationen aus dem IDT-Kontext abrufen und damit eine direkte Verbindung zum Gerät aus der Testsuite herstellen.

Um eine direkte Verbindung herzustellen, rufen Sie die Informationen in den device.connectivity resource.devices.connectivity Feldern für Ihr zu testendes Gerät bzw. für Ressourcengeräte ab. Weitere Informationen zur Verwendung des IDT-Kontexts finden Sie unterVerwenden Sie den IDT-Kontext.

IDT-Interaktion

Die folgenden Befehle ermöglichen es Ihren Testsuiten, mit IDT zu kommunizieren.

PollForNotifications

Ermöglicht Testsuiten, nach Benachrichtigungen von IDT zu suchen.

GetContextValue und GetContextString

Ermöglicht Testsuiten, Werte aus dem IDT-Kontext abzurufen. Weitere Informationen finden Sie unter Verwenden Sie den IDT-Kontext.

SendResult

Ermöglicht Testsuiten, Testfallergebnisse an IDT zu melden. Dieser Befehl muss am Ende jedes Testfalls in einer Testsuite aufgerufen werden.

Interaktion mit dem Host

Mit dem folgenden Befehl können Ihre Testsuiten mit dem Host-Computer kommunizieren.

PollForNotifications

Ermöglicht Testsuiten, nach Benachrichtigungen von IDT zu suchen.

GetContextValue und GetContextString

Ermöglicht Testsuiten, Werte aus dem IDT-Kontext abzurufen. Weitere Informationen finden Sie unter Verwenden Sie den IDT-Kontext.

ExecuteOnHost

Ermöglicht Testsuiten das Ausführen von Befehlen auf dem lokalen Computer und ermöglicht IDT die Verwaltung des Lebenszyklus der ausführbaren Testfälle.

Aktivieren Sie IDT-CLI-Befehle

Der run-suite Befehl IDT CLI bietet mehrere Optionen, mit denen der Testläufer die Testausführung anpassen kann. Damit Testläufer diese Optionen verwenden können, um Ihre benutzerdefinierte Testsuite auszuführen, implementieren Sie die Unterstützung für die IDT-CLI. Wenn Sie keine Unterstützung implementieren, können Testläufer weiterhin Tests ausführen, aber einige CLI-Optionen funktionieren nicht richtig. Um ein optimales Kundenerlebnis zu bieten, empfehlen wir Ihnen, die Unterstützung für die folgenden Argumente für den run-suite Befehl in der IDT-CLI zu implementieren:

timeout-multiplier

Gibt einen Wert über 1,0 an, der bei der Ausführung von Tests auf alle Timeouts angewendet wird.

Testläufer können dieses Argument verwenden, um das Timeout für die Testfälle zu erhöhen, die sie ausführen möchten. Wenn ein Testläufer dieses Argument in seinem run-suite Befehl angibt, berechnet IDT damit den Wert der IDT_TEST_TIMEOUT-Umgebungsvariablen und setzt das Feld in den IDT-Kontext. config.timeoutMultiplier Um dieses Argument zu unterstützen, müssen Sie Folgendes tun:

  • Anstatt direkt den Timeout-Wert aus der test.json Datei zu verwenden, lesen Sie die IDT_TEST_TIMEOUT-Umgebungsvariable, um den korrekt berechneten Timeout-Wert zu erhalten.

  • Rufen Sie den config.timeoutMultiplier Wert aus dem IDT-Kontext ab und wenden Sie ihn auf Timeouts mit langer Laufzeit an.

Weitere Hinweise zum vorzeitigen Beenden aufgrund von Timeout-Ereignissen finden Sie unter. Geben Sie das Verhalten beim Verlassen an

stop-on-first-failure

Gibt an, dass IDT die Ausführung aller Tests beenden soll, wenn ein Fehler auftritt.

Wenn ein Testläufer dieses Argument in seinem run-suite Befehl angibt, stoppt IDT die Ausführung von Tests, sobald ein Fehler auftritt. Wenn Testfälle jedoch parallel ausgeführt werden, kann dies zu unerwarteten Ergebnissen führen. Um den Support zu implementieren, stellen Sie sicher, dass Ihre Testlogik alle laufenden Testfälle anweist, zu stoppen, temporäre Ressourcen zu bereinigen und ein Testergebnis an IDT zu melden, wenn IDT auf dieses Ereignis stößt. Weitere Informationen zum vorzeitigen Beenden bei Fehlern finden Sie unter. Geben Sie das Verhalten beim Verlassen an

group-id und test-id

Gibt an, dass IDT nur die ausgewählten Testgruppen oder Testfälle ausführen soll.

Testläufer können diese Argumente zusammen mit ihrem run-suite Befehl verwenden, um das folgende Verhalten bei der Testausführung anzugeben:

  • Führen Sie alle Tests innerhalb der angegebenen Testgruppen aus.

  • Führen Sie eine Auswahl von Tests innerhalb einer bestimmten Testgruppe aus.

Um diese Argumente zu unterstützen, muss die Zustandsmaschine für Ihre Testsuite einen bestimmten Satz von RunTask Choice UND-Zuständen in Ihrer Zustandsmaschine enthalten. Wenn Sie keine benutzerdefinierte Zustandsmaschine verwenden, enthält die standardmäßige IDT-Zustandsmaschine die erforderlichen Zustände für Sie, sodass Sie keine weiteren Maßnahmen ergreifen müssen. Wenn Sie jedoch einen benutzerdefinierten Zustandsautomaten verwenden, verwenden Sie ihn Beispiel für eine Zustandsmaschine: Führen Sie vom Benutzer ausgewählte Testgruppen aus als Beispiel, um Ihrem Zustandsmaschinen die erforderlichen Zustände hinzuzufügen.

Weitere Informationen zu IDT-CLI-Befehlen finden Sie unterDebuggen Sie benutzerdefinierte Testsuiten und führen Sie sie aus.

Schreiben Sie Ereignisprotokolle

Während der Test läuft, senden Sie Daten an stdout stderr die Konsole und schreiben dort Ereignisprotokolle und Fehlermeldungen. Hinweise zum Format von Konsolenmeldungen finden Sie unterNachrichtenformat der Konsole.

Wenn das IDT die Ausführung der Testsuite abgeschlossen hat, sind diese Informationen auch in der test_manager.log Datei im <devicetester-extract-location>/results/<execution-id>/logs Ordner verfügbar.

Sie können jeden Testfall so konfigurieren, dass die Protokolle seines Testlaufs, einschließlich der Protokolle des getesteten Geräts, in die <group-id>_<test-id> Datei im <device-tester-extract-location>/results/execution-id/logs Ordner geschrieben werden. Rufen Sie dazu den Pfad zur Protokolldatei aus dem IDT-Kontext mit der testData.logFilePath Abfrage ab, erstellen Sie eine Datei unter diesem Pfad und schreiben Sie den gewünschten Inhalt hinein. IDT aktualisiert den Pfad automatisch auf der Grundlage des gerade ausgeführten Testfalls. Wenn Sie sich dafür entscheiden, die Protokolldatei für einen Testfall nicht zu erstellen, wird für diesen Testfall keine Datei generiert.

Sie können Ihre Textdatei auch so einrichten, dass bei Bedarf zusätzliche Protokolldateien im <device-tester-extract-location>/logs Ordner erstellt werden. Wir empfehlen, eindeutige Präfixe für Protokolldateinamen anzugeben, damit Ihre Dateien nicht überschrieben werden.

Ergebnisse an IDT melden

IDT schreibt Testergebnisse in die awsiotdevicetester_report.xml und die suite-name_report.xml Dateien. Diese Berichtsdateien befinden sich in<device-tester-extract-location>/results/<execution-id>/. Beide Berichte erfassen die Ergebnisse der Ausführung der Testsuite. Weitere Informationen zu den Schemas, die IDT für diese Berichte verwendet, finden Sie unter Überprüfen Sie die IDT-Testergebnisse und -Protokolle

Um den Inhalt der suite-name_report.xml Datei auszufüllen, müssen Sie den SendResult Befehl verwenden, um die Testergebnisse an IDT zu melden, bevor die Testausführung abgeschlossen ist. Wenn IDT die Ergebnisse eines Tests nicht finden kann, gibt es einen Fehler für den Testfall aus. Der folgende Python-Auszug zeigt die Befehle zum Senden eines Testergebnisses an IDT:

request-variable = SendResultRequest(TestResult(result))
client.send_result(request-variable)

Wenn Sie keine Ergebnisse über die API melden, sucht IDT im Ordner „Testartefakte“ nach Testergebnissen. Der Pfad zu diesem Ordner wird in der Datei testData.testArtifactsPath im IDT-Kontext gespeichert. In diesem Ordner verwendet IDT die erste alphabetisch sortierte XML-Datei, die es als Testergebnis findet.

Wenn Ihre Testlogik JUnit-XML-Ergebnisse erzeugt, können Sie die Testergebnisse in eine XML-Datei im Ordner Artifacts schreiben, um die Ergebnisse direkt an IDT weiterzuleiten, anstatt die Ergebnisse zu analysieren und sie dann über die API an IDT zu senden.

Wenn Sie diese Methode verwenden, stellen Sie sicher, dass Ihre Testlogik die Testergebnisse korrekt zusammenfasst, und formatieren Sie Ihre Ergebnisdatei im gleichen Format wie die Datei. suite-name_report.xml IDT führt keine Validierung der von Ihnen bereitgestellten Daten durch, mit den folgenden Ausnahmen:

  • IDT ignoriert alle Eigenschaften des Tags. testsuites Stattdessen berechnet es die Tag-Eigenschaften anhand anderer gemeldeter Testgruppenergebnisse.

  • Mindestens ein testsuite Tag muss darin testsuites existieren.

Da IDT für alle Testfälle denselben Ordner für Artefakte verwendet und zwischen den Testläufen keine Ergebnisdateien löscht, kann diese Methode auch zu fehlerhaften Berichten führen, wenn IDT die falsche Datei liest. Wir empfehlen, für alle Testfälle denselben Namen für die generierte XML-Ergebnisdatei zu verwenden, um die Ergebnisse für jeden Testfall zu überschreiben und sicherzustellen, dass IDT die richtigen Ergebnisse zur Verfügung stehen. Obwohl Sie für die Berichterstattung in Ihrer Testsuite einen gemischten Ansatz verwenden können, d. h. für einige Testfälle eine XML-Ergebnisdatei verwenden und für andere die Ergebnisse über die API einreichen, empfehlen wir diesen Ansatz nicht.

Geben Sie das Verhalten beim Verlassen an

Konfigurieren Sie Ihre Textdatei so, dass sie immer mit dem Exit-Code 0 beendet wird, auch wenn ein Testfall einen Fehler oder ein Fehlerergebnis meldet. Verwenden Sie Exit-Codes ungleich Null nur, um anzuzeigen, dass ein Testfall nicht ausgeführt wurde oder wenn die ausführbare Testfalldatei IDT keine Ergebnisse übermitteln konnte. Wenn IDT einen Exit-Code ungleich Null empfängt, bedeutet dies, dass im Testfall ein Fehler aufgetreten ist, der die Ausführung des Testfalls verhindert hat.

In den folgenden Fällen kann IDT anfordern oder erwarten, dass ein Testfall nicht mehr ausgeführt wird, bevor er abgeschlossen ist. Verwenden Sie diese Informationen, um die ausführbare Datei Ihres Testfalls so zu konfigurieren, dass jedes dieser Ereignisse im Testfall erkannt wird:

Timeout (Zeitüberschreitung)

Tritt auf, wenn ein Testfall länger als der in der test.json Datei angegebene Timeout-Wert ausgeführt wird. Wenn der Testläufer das timeout-multiplier Argument verwendet hat, um einen Timeout-Multiplikator anzugeben, berechnet IDT den Timeout-Wert mit dem Multiplikator.

Verwenden Sie die Umgebungsvariable IDT_TEST_TIMEOUT, um dieses Ereignis zu erkennen. Wenn ein Testläufer einen Test startet, setzt IDT den Wert der IDT_TEST_TIMEOUT-Umgebungsvariablen auf den berechneten Timeout-Wert (in Sekunden) und übergibt die Variable an die ausführbare Testfalldatei. Sie können den Variablenwert lesen, um einen geeigneten Timer einzustellen.

Unterbrechen

Tritt auf, wenn der Testläufer IDT unterbricht. Zum Beispiel durch Drücken von. Ctrl+C

Da Terminals Signale an alle untergeordneten Prozesse weitergeben, können Sie in Ihren Testfällen einfach einen Signalhandler konfigurieren, der Interruptsignale erkennt.

Alternativ können Sie die API regelmäßig abfragen, um den Wert des CancellationRequested booleschen Werts in der API-Antwort zu überprüfen. PollForNotifications Wenn IDT ein Interruptsignal empfängt, setzt es den Wert des booleschen Werts auf. CancellationRequested true

Stoppt beim ersten Ausfall

Tritt auf, wenn ein Testfall, der parallel zum aktuellen Testfall ausgeführt wird, fehlschlägt und der Testrunner das stop-on-first-failure Argument verwendet hat, um anzugeben, dass IDT beendet werden soll, wenn ein Fehler auftritt.

Um dieses Ereignis zu erkennen, können Sie die API regelmäßig abfragen, um den Wert des CancellationRequested booleschen Werts in der PollForNotifications API-Antwort zu überprüfen. Wenn IDT auf einen Fehler stößt und so konfiguriert ist, dass es beim ersten Fehler stoppt, setzt es den Wert des booleschen Werts CancellationRequested auf. true

Wenn eines dieser Ereignisse eintritt, wartet IDT 5 Minuten, bis die Ausführung aller aktuell ausgeführten Testfälle abgeschlossen ist. Wenn nicht alle laufenden Testfälle innerhalb von 5 Minuten beendet werden, zwingt IDT jeden ihrer Prozesse zum Beenden. Wenn IDT vor dem Ende der Prozesse keine Testergebnisse erhalten hat, werden die Testfälle als Timeout markiert. Als bewährte Methode sollten Sie sicherstellen, dass Ihre Testfälle die folgenden Aktionen ausführen, wenn sie auf eines der Ereignisse stoßen:

  1. Beenden Sie die Ausführung der normalen Testlogik.

  2. Bereinigen Sie alle temporären Ressourcen, wie z. B. Testartefakte, auf dem zu testenden Gerät.

  3. Melden Sie IDT ein Testergebnis, z. B. einen Testfehler oder einen Fehler.

  4. Beenden.