Ausführbare IDT-Testfalldateien erstellen - AWS IoT Greengrass
Verwenden Sie das IDT Client SDKDie IDB CLI-BefehleSchreiben Sie EreignisprotokolleErgebnisse an IDT meldenGeben Sie das Ausgangsverhalten 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.

Ausführbare IDT-Testfalldateien erstellen

Sie können auf folgende Weise ausführbare Testfalldateien erstellen und in einem Testsuite-Ordner ablegen:

  • Für Testsuiten, die Argumente oder Umgebungsvariablen aus dentest.json Dateien verwenden, um zu bestimmen, welche Tests ausgeführt werden sollen, können Sie eine einzelne ausführbare Testfalldatei für die gesamte Testsuite oder eine ausführbare 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 eine ausführbare Testfalldatei.

Als Testautor können Sie bestimmen, welcher Ansatz für Ihren Anwendungsfall geeignet ist, und Ihre ausführbare Testfalldatei entsprechend strukturieren. Stellen Sie sicher, dass Sie in jedertest.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:

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

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

IDT startet den erforderlichen ausführbaren Testprozess auf der Grundlage der in dertest.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 Testdatei mit API-Befehlen vereinfachen, die Sie verwenden können, um mit IDT und Ihren zu testenden Geräten zu interagieren. IDT stellt derzeit die folgenden SDKs bereit:

  • IDT

  • SDK for Go

  • SDK for Java

Diese SDKs befinden sich in dem<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 das SDK in Ihrem Code referenzieren. 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 für die Geräteinteraktion und das Konnektivitätsmanagement implementieren zu müssen.

ExecuteOnDevice

Ermöglicht Testsuiten das Ausführen von Shell-Befehlen auf einem Gerät, 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 Ort auf einem Gerät zu kopieren, das SSH- oder Docker-Shell-Verbindungen unterstützt.

ReadFromDevice

Ermöglicht Testsuiten das Lesen von der seriellen Schnittstelle von Geräten, 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 Geräteinteraktionen in Ihren ausführbaren Testfalldateien zu verwenden. Wenn diese Befehle jedoch nicht Ihren Testfallanforderungen entsprechen, können Sie die 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 Felderndevice.connectivity und in denresource.devices.connectivity Feldern für Ihr zu testendes Gerät bzw. für Ressourcengeräte ab. Weitere Informationen zur Verwendung des IDTVerwenden 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 das Abrufen von Werten aus dem IDT-Kontext. 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 Gastgeber

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 das Abrufen von Werten aus dem IDT-Kontext. Weitere Informationen finden Sie unter Verwenden Sie den IDT-Kontext.

ExecuteOnHost

Ermöglicht Testsuiten die Ausführung von Befehlen auf dem lokalen Computer und ermöglicht IDT die Verwaltung des Lebenszyklus der ausführbaren Testfalldatei.

Die IDB CLI-Befehle

Derrun-suite Befehl IDT CLI bietet verschiedene Optionen, mit denen Test Runner 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 die Unterstützung nicht implementieren, können Testläufer weiterhin Tests ausführen, aber einige CLI-Optionen funktionieren nicht richtig. Um ein optimales Kundenerlebnis zu bieten, empfehlen wir, die Unterstützung für die folgenden Argumente für denrun-suite Befehl in der IDT-CLI zu implementieren:

timeout-multiplier

Gibt einen Wert größer als 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 Testrunner dieses Argument in seinemrun-suite Befehl angibt, berechnet IDT damit den Wert der Umgebungsvariablen IDT_TEST_TIMEOUT und legt dasconfig.timeoutMultiplier Feld im IDT-Kontext fest. Um dieses Argument zu untermauern, müssen Sie die folgenen Schritte ausführen:

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

  • Rufen Sie denconfig.timeoutMultiplier Wert aus dem IDT-Kontext ab und wenden Sie ihn auf lange laufende Timeouts an.

Weitere Hinweise zum vorzeitigen Beenden aufgrund von Timeout-Ereignissen finden Sie unterGeben Sie das Ausgangsverhalten an.

stop-on-first-failure

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

Wenn ein Testrunner dieses Argument in seinemrun-suite Befehl angibt, stoppt IDT die Ausführung von Tests, sobald ein Fehler auftritt. Wenn Testfälle jedoch parallel laufen, kann dies zu unerwarteten Ergebnissen führen. Um die Unterstützung zu implementieren, stellen Sie sicher, dass Ihre Testlogik alle laufenden Testfälle anweist, anzuhalten, temporäre Ressourcen zu bereinigen und IDT ein Testergebnis zu melden, wenn IDT auf dieses Ereignis stößt. Weitere Informationen zum vorzeitigen Beenden finden Sie unterGeben Sie das Ausgangsverhalten an.

group-id und test-id

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

Testläufer können diese Argumente zusammen mit ihremrun-suite Befehl verwenden, um das folgende Testausführungsverhalten 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 der Testorchestrator für Ihre Testsuite einen bestimmten Satz vonRunTaskChoice AND-Zuständen in Ihrem Testorchestrator enthalten. Wenn Sie keine benutzerdefinierte State-Machine verwenden, enthält der standardmäßige IDT-Testorchestrator die erforderlichen Zustände für Sie, und Sie müssen keine zusätzlichen Maßnahmen ergreifen. Wenn Sie jedoch einen benutzerdefinierten Testorchestrator verwenden, verwenden Sie ihnBeispiel für einen Zustandsautomaten: Ausführen von vom Benutzer ausgewählten Testgruppen als Beispiel, um die erforderlichen Zustände in Ihrem Testorchestrator hinzuzufügen.

Weitere Informationen zu EB CLI-Befehlen finden Sie unterDebuggen und Ausführen benutzerdefinierter Testsuiten.

Schreiben Sie Ereignisprotokolle

Während der Test läuft, senden Sie Daten anstdout undstderr um Ereignisprotokolle und Fehlermeldungen an die Konsole zu schreiben. Weitere Informationen zum Format von Konsolennachrichten finden Sie unterNachrichtenformat.

Wenn das IDT die Ausführung der Testsuite abgeschlossen hat, sind diese Informationen auch in dertest_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 zu testenden 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 mit dertestData.logFilePath Abfrage aus dem IDT-Kontext ab, erstellen Sie eine Datei in diesem Pfad und schreiben Sie den gewünschten Inhalt hinein. IDT aktualisiert den Pfad automatisch auf der Grundlage des laufenden Testfalls. Wenn Sie sich dafür entscheiden, die Protokolldatei für einen Testfall nicht zu erstellen, wird keine Datei für diesen Testfall generiert.

Sie können Ihre ausführbare Textdatei auch einrichten, um nach Bedarf zusätzliche Protokolldateien im<device-tester-extract-location>/logs Ordner zu erstellen. Wir empfehlen, dass Sie eindeutige Präfixe für Protokolldateinamen angeben, damit Ihre Dateien nicht überschrieben werden.

Ergebnisse an IDT melden

IDT schreibt Testergebnisse in dieawsiotdevicetester_report.xml und diesuite-name_report.xml Dateien. Diese Berichtsdateien befinden sich unter<device-tester-extract-location>/results/<execution-id>/. In beiden Berichten werden die Ergebnisse der Ausführung der Testsuite erfasst. Weitere Informationen zu den Schemas, die IDT für diese Berichte verwendet, finden Sie unterÜberprüfen Sie IDT-Testergebnisse und -protokolle

Um den Inhalt dersuite-name_report.xml Datei aufzufüllen, müssen Sie denSendResult 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 „Testartefacts“ nach Testergebnissen. Der Pfad zu diesem Ordner wird in dertestData.testArtifactsPath Datei 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 artefacts 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 diesuite-name_report.xml Datei. IDT führt keine Validierung der von Ihnen bereitgestellten Daten durch, mit den folgenden Ausnahmen:

  • IDT ignoriert alle Eigenschaften destestsuites Tags. Stattdessen werden die Tag-Eigenschaften anhand anderer gemeldeter Testgruppenergebnisse berechnet.

  • Darin muss mindestens eintestsuite Tag vorhanden seintestsuites.

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

Geben Sie das Ausgangsverhalten an

Konfigurieren Sie Ihre ausführbare Textdatei so, dass sie immer mit einem Exit-Code von 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 ob die ausführbare Testfalldatei keine Ergebnisse an IDT übermitteln konnte. Wenn IDT einen Exit-Code ungleich Null empfängt, markiert dies, dass im Testfall ein Fehler aufgetreten ist, der die Ausführung verhindert hat.

IDT kann in den folgenden Ereignissen anfordern oder erwarten, dass die Ausführung eines Testfalls beendet wird, bevor er abgeschlossen ist. Verwenden Sie diese Informationen, um Ihre ausführbare Testfalldatei so zu konfigurieren, dass jedes dieser Ereignisse im Testfall erkannt wird:

Timeout (Zeitüberschreitung)

Tritt auf, wenn ein Testfall länger als der in dertest.json Datei angegebene Timeout-Wert ausgeführt wird. Wenn der Testrunner dastimeout-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 Test-Runner einen Test startet, setzt IDT den Wert der Umgebungsvariablen IDT_TEST_TIMEOUT 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 Testrunner IDT unterbricht. Zum Beispiel durch DrückenCtrl+C.

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

Alternativ können Sie die API regelmäßig abfragen, um den Wert desCancellationRequested booleschen Werts in derPollForNotifications API-Antwort zu überprüfen. Wenn IDT ein Interruptsignal empfängt, setzt es den Wert desCancellationRequested booleschen Werts auftrue.

Stoppen Sie beim ersten Ausfall

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

Um dieses Ereignis zu erkennen, können Sie die API regelmäßig abfragen, um den Wert desCancellationRequested booleschen Werts in derPollForNotifications 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 desCancellationRequested booleschen Werts auftrue.

Wenn eines dieser Ereignisse eintritt, wartet IDT 5 Minuten, bis die Ausführung aller aktuell laufenden Testfälle abgeschlossen ist. Wenn nicht alle laufenden Testfälle innerhalb von 5 Minuten abgeschlossen sind, zwingt IDT jeden seiner Prozesse zum Stoppen. Wenn IDT vor dem Ende der Prozesse keine Testergebnisse erhalten hat, markiert es die Testfälle als abgelaufen. 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. Aussteigen.