Erstellen Sie eine ausführbare IDT-Testfalldatei - Kostenlos RTOS
Verwenden Sie das IDT Client SDKIDT-CLI-Befehle aktivierenSchreiben Sie EreignisprotokolleErgebnisse an IDT meldenGeben Sie das Exit-Verhalten 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 ablegen:

  • 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 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 jeder test.json Datei den richtigen Pfad für die ausführbare 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 festgelegte Prozess bestimmt, welche Prozesse gestartet und welche Umgebungsvariablen gesetzt werden sollen.

  • 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 Testdatei mithilfe von API-Befehlen vereinfachen, die Sie verwenden können, um mit IDT und Ihren zu testenden Geräten zu interagieren. IDT bietet derzeit die folgenden SDKs:

  • IDT-Client-SDK für Python

  • IDT Client SDK for Go

  • IDT Client SDK for 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 Ihre 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.

Geräteinteraktion

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 es 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 es 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 Geräteinteraktionen 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 sie verwenden, um über die Testsuite eine direkte Verbindung zum Gerät herzustellen.

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

SendResult

Ermöglicht es 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 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 Testfälle.

IDT-CLI-Befehle aktivieren

Der run-suite Befehl IDT CLI bietet mehrere Optionen, mit denen Test Runner die Testausführung anpassen kann. Damit Testläufer diese Optionen zum Ausführen Ihrer benutzerdefinierten Testsuite verwenden können, implementieren Sie 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, 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 größer als 1,0 an, der auf alle Timeouts beim Ausführen von Tests 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, verwendet IDT es, um den Wert der Umgebungsvariablen IDT_TEST_TIMEOUT zu berechnen, und legt das Feld im IDT-Kontext fest. config.timeoutMultiplier Um dieses Argument zu unterstützen, müssen Sie wie folgt vorgehen:

  • Anstatt den Timeout-Wert direkt aus der test.json Datei zu verwenden, lesen Sie die Umgebungsvariable IDT_TEST_TIMEOUT, 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 Exit-Verhalten 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, beendet 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 Support zu implementieren, stellen Sie sicher, dass Ihre Testlogik alle laufenden Testfälle anweist, anzuhalten, temporäre Ressourcen zu bereinigen und ein Testergebnis an IDT zu melden, wenn IDT auf dieses Ereignis trifft. Weitere Informationen zum vorzeitigen Beenden von Fehlern finden Sie unter. Geben Sie das Exit-Verhalten 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 mit ihrem run-suite Befehl verwenden, um das folgende Verhalten bei der Testausführung anzugeben:

  • Führt alle Tests innerhalb der angegebenen Testgruppen aus.

  • Führt eine Auswahl von Tests innerhalb einer angegebenen Testgruppe aus.

Um diese Argumente zu unterstützen, muss die Zustandsmaschine für Ihre Testsuite einen bestimmten Satz von RunTask Choice 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, und Sie müssen keine zusätzlichen Maßnahmen ergreifen. Wenn Sie jedoch eine benutzerdefinierte Zustandsmaschine verwenden, verwenden Sie sie Beispiel für eine Zustandsmaschine: Führen Sie vom Benutzer ausgewählte Testgruppen aus als Beispiel, um die erforderlichen Zustände zu Ihrer Zustandsmaschine 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 beendet 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 des 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 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 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 so einrichten, dass sie bei Bedarf zusätzliche Protokolldateien im <device-tester-extract-location>/logs Ordner erstellt. Wir empfehlen Ihnen, 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 aufzufü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 Ergebnisse nicht über die API melden, sucht IDT im Ordner mit den Testartefakten nach Testergebnissen. Der Pfad zu diesem Ordner wird in der Datei im testData.testArtifactsPath IDT-Kontext gespeichert. In diesem Ordner verwendet IDT die erste alphabetisch sortierte XML-Datei, die es findet, als Testergebnis.

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 weiterzugeben, 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 Überprüfung der von Ihnen bereitgestellten Daten durch, mit den folgenden Ausnahmen:

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

  • Darin testsuites muss mindestens ein testsuite Tag vorhanden sein.

Da IDT für alle Testfälle denselben Ordner mit Artefakten verwendet und Ergebnisdateien nicht zwischen Testläufen löscht, kann diese Methode auch zu fehlerhaften Berichten führen, wenn IDT die falsche Datei liest. Es wird empfohlen, 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 hat. Sie können in Ihrer Testsuite zwar einen gemischten Ansatz für die Berichterstattung verwenden, d. h. für einige Testfälle eine XML-Ergebnisdatei verwenden und für andere die Ergebnisse über die API einreichen, wir empfehlen diesen Ansatz jedoch nicht.

Geben Sie das Exit-Verhalten an

Konfigurieren Sie Ihre ausführbare 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 dass die ausführbare Testfalldatei keine Ergebnisse an IDT übermitteln konnte. Wenn IDT einen Exit-Code ungleich Null empfängt, bedeutet dies, dass der Testfall auf einen Fehler gestoßen ist, der seine Ausführung verhindert hat.

IDT kann in den folgenden Fällen 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 anhand des Testfalls 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 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 festzulegen.

Unterbrechen

Tritt auf, wenn der Test-Runner IDT unterbricht. Zum Beispiel durch Drücken von. Ctrl+C

Da Terminals Signale an alle untergeordneten Prozesse weiterleiten, können Sie in Ihren Testfällen einfach einen Signal-Handler konfigurieren, der Interrupt-Signale 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 Fehler

Tritt auf, wenn ein Testfall, der parallel zum aktuellen Testfall ausgeführt wird, fehlschlägt und der Testläufer 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, wird der Wert des booleschen Werts CancellationRequested auf gesetzt. true

Wenn eines dieser Ereignisse eintritt, wartet IDT 5 Minuten, bis alle derzeit laufenden Testfälle abgeschlossen sind. Wenn nicht alle laufenden Testfälle innerhalb von 5 Minuten beendet werden, erzwingt IDT, jeden ihrer Prozesse zu 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, z. B. Testartefakte, auf dem zu testenden Gerät.

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

  4. Beenden.