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 IDT ausführbare Testfalldatei
Sie können eine 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 die 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, IDT liest die folgenden Dateien:
-
Das
test.json
für den ausgewählten Testfall bestimmt, welche Prozesse gestartet und welche Umgebungsvariablen gesetzt werden sollen. -
Die
suite.json
für die Testsuite bestimmt die zu setzenden Umgebungsvariablen.
IDTstartet 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 den IDT Client SDK
Mit dem IDT Client SDKs können Sie das Schreiben von Testlogik in Ihre ausführbare Testdatei mithilfe von API Befehlen vereinfachen, mit denen Sie interagieren IDT und die zu testenden Geräte verwenden können. IDTbietet derzeit FolgendesSDKs:
-
IDTClient SDK für Python
-
IDTKunde SDK für Go
-
IDTClient SDK für Java
Diese SDKs befinden sich im
Ordner. Wenn Sie eine neue ausführbare Testfalldatei erstellen, müssen Sie die Datei, SDK die Sie verwenden möchten, in den Ordner kopieren, der Ihre ausführbare Testfalldatei enthält, und SDK in Ihrem Code darauf verweisen. Dieser Abschnitt enthält eine kurze Beschreibung der verfügbaren API Befehle, die Sie in Ihren ausführbaren Testfalldateien verwenden können. <device-tester-extract-location>
/sdks
In diesem Abschnitt
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 es Testsuiten, eine lokale Datei vom Host-Computer, der ausgeführt wird, IDT 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 direkte Verbindungen zu Geräten, die mithilfe von Gerätezugriffsinformationen aus dem Kontext hergestellt werden, IDT nicht verwaltet werden, empfehlen wir, diese API Befehle zur 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 sie verwenden, um von der Testsuite aus 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 unterBenutze den IDT Kontext.
IDTInteraktion
Mit den folgenden Befehlen können Ihre Testsuiten mit kommunizierenIDT.
PollForNotifications
-
Ermöglicht Testsuiten, nach Benachrichtigungen von zu suchenIDT.
GetContextValue
undGetContextString
-
Ermöglicht es Testsuiten, Werte aus dem IDT Kontext abzurufen. Weitere Informationen finden Sie unter Benutze den IDT Kontext.
SendResult
-
Ermöglicht es Testsuiten, Testfallergebnisse an zu meldenIDT. 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 zu suchenIDT.
GetContextValue
undGetContextString
-
Ermöglicht es Testsuiten, Werte aus dem IDT Kontext abzurufen. Weitere Informationen finden Sie unter Benutze den IDT Kontext.
ExecuteOnHost
-
Ermöglicht es Testsuiten, Befehle auf dem lokalen Computer auszuführen, und ermöglicht die IDT Verwaltung des Lebenszyklus der ausführbaren Testfälle.
IDTCLIBefehle aktivieren
Der run-suite
Befehl IDT CLI bietet mehrere 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 Unterstützung für IDTCLI. Wenn Sie keine Unterstützung implementieren, können Testläufer weiterhin Tests ausführen, aber einige CLI Optionen werden nicht richtig funktionieren. Um ein optimales Kundenerlebnis zu bieten, empfehlen wir Ihnen, Unterstützung für die folgenden Argumente für den run-suite
Befehl in der zu implementieren IDTCLI:
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 Testläufer dieses Argument in seinem
run-suite
Befehl angibt, IDT berechnet er damit den Wert der TIMEOUT Umgebungsvariablen IDT TEST _ _ und legt dasconfig.timeoutMultiplier
Feld im IDT Kontext fest. 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 TIMEOUT Umgebungsvariable IDT _ TEST _, um den korrekt berechneten Timeout-Wert zu erhalten. -
Ruft den
config.timeoutMultiplier
Wert aus dem IDT Kontext ab und wendet 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 die Ausführung aller Tests beendet werden IDT soll, wenn ein Fehler auftritt.
Wenn ein Testläufer dieses Argument in seinem
run-suite
Befehl angibt, beendet er 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, bei Auftreten dieses Ereignisses alle laufenden Testfälle anzuhalten, temporäre Ressourcen zu bereinigen und ein Testergebnis an zu IDT melden. IDT Weitere Informationen zum vorzeitigen Beenden von Fehlern finden Sie unter. Geben Sie das Exit-Verhalten an group-id
undtest-id
-
Gibt an, dass nur die ausgewählten Testgruppen oder Testfälle ausgeführt werden IDT sollen.
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 IDT Standard-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 die Ausführung der Testsuite IDT abgeschlossen ist, sind diese Informationen auch in der test_manager.log
Datei im
Ordner verfügbar.<devicetester-extract-location>
/results/<execution-id>
/logs
Sie können jeden Testfall so konfigurieren, dass die Protokolle des Testlaufs, einschließlich der Protokolle des zu testenden Geräts, in die
Datei im <group-id>
_<test-id>
Ordner geschrieben werden. Rufen Sie dazu den Pfad zur Protokolldatei aus dem IDT Kontext mit der <device-tester-extract-location>
/results/execution-id
/logstestData.logFilePath
Abfrage ab, erstellen Sie eine Datei unter diesem Pfad und schreiben Sie den gewünschten Inhalt hinein. IDTaktualisiert 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
Ordner erstellt. Wir empfehlen Ihnen, eindeutige Präfixe für Protokolldateinamen anzugeben, damit Ihre Dateien nicht überschrieben werden.<device-tester-extract-location>
/logs
Ergebnisse melden an IDT
IDTschreibt Testergebnisse in die awsiotdevicetester_report.xml
und die
Dateien. Diese Berichtsdateien befinden sich insuite-name
_report.xml
. Beide Berichte erfassen die Ergebnisse der Ausführung der Testsuite. Weitere Informationen zu den Schemas, die für diese Berichte IDT verwendet werden, finden Sie unter Überprüfen Sie die IDT Testergebnisse und Protokolle<device-tester-extract-location>
/results/<execution-id>
/
Um den Inhalt der
Datei aufzufüllen, müssen Sie den suite-name
_report.xmlSendResult
Befehl zum Melden von Testergebnissen verwenden, IDT bevor die Testausführung abgeschlossen ist. Wenn die Ergebnisse eines Tests IDT nicht gefunden werden können, wird ein Fehler für den Testfall ausgegeben. Der folgende Python-Auszug zeigt die Befehle, an die ein Testergebnis gesendet IDT werden kann:
request-variable
= SendResultRequest(TestResult(result
)) client.send_result(request-variable
)
Wenn Sie keine Ergebnisse über den meldenAPI, IDT sucht im Ordner mit den Testartefakten nach Testergebnissen. Der Pfad zu diesem Ordner wird in der testData.testArtifactsPath
Datei im IDT Kontext gespeichert. IDTVerwendet in diesem Ordner die erste alphabetisch sortierte XML Datei, die gefunden wird, als Testergebnis.
Wenn Ihre Testlogik JUnit XML Ergebnisse liefert, können Sie die Testergebnisse in eine XML Datei im Ordner artefacts schreiben, um die Ergebnisse direkt bereitzustellen, IDT anstatt die Ergebnisse zu analysieren und sie dann zu verwenden, um sie API zu senden. IDT
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. IDTführt keine Überprüfung der von Ihnen bereitgestellten Daten durch, mit den folgenden Ausnahmen:suite-name
_report.xml
-
IDTignoriert alle Eigenschaften des
testsuites
Tags. Stattdessen werden die Tag-Eigenschaften anhand anderer gemeldeter Testgruppenergebnisse berechnet. -
Darin
testsuites
muss mindestens eintestsuite
Tag vorhanden sein.
Da für alle Testfälle derselbe Ordner mit Artefakten IDT verwendet wird und Ergebnisdateien zwischen Testläufen nicht gelöscht werden, kann diese Methode auch zu fehlerhaften Berichten führen, wenn die falsche Datei IDT gelesen wird. 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 die richtigen Ergebnisse zur Verwendung zur IDT Verfügung stehen. 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 API für andere die Ergebnisse über die 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 sie IDT übermitteln konnte. Wenn ein Exit-Code ungleich Null IDT empfangen wird, bedeutet das, dass der Testfall auf einen Fehler gestoßen ist, der seine Ausführung verhindert hat.
IDTkönnte bei den folgenden Ereignissen verlangen 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 dastimeout-multiplier
Argument verwendet hat, um einen Timeout-Multiplikator anzugeben, IDT berechnet er den Timeout-Wert mit dem Multiplikator.Verwenden Sie die Umgebungsvariable _ _, um dieses Ereignis zu erkennen. IDT TEST TIMEOUT Wenn ein Testläufer einen Test startet, IDT setzt er den Wert der TIMEOUT Umgebungsvariablen IDT _ TEST _ 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 Test-Runner unterbrichtIDT. Zum Beispiel durch Drücken Ctrl+C von.
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 den in regelmäßigen Abständen abfragen, API um den Wert des
CancellationRequested
booleschen Werts in der Antwort zu überprüfen.PollForNotifications
API Wenn ein Interrupt-Signal IDT empfangen wird, wird der Wert des booleschen Werts aufCancellationRequested
gesetzt.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 er beendet werden IDT soll, wenn er auf einen Fehler stößt.Um dieses Ereignis zu erkennen, können Sie in regelmäßigen Abständen API den Wert des
CancellationRequested
booleschen Werts in derPollForNotifications
API Antwort abfragen. Wenn ein IDT Fehler auftritt und die Konfiguration so konfiguriert ist, dass der Vorgang beim ersten Fehler beendet wird, wird der Wert desCancellationRequested
booleschen Werts auf gesetzt.true
Wenn eines dieser Ereignisse eintritt, IDT wird 5 Minuten gewartet, bis alle derzeit laufenden Testfälle abgeschlossen sind. Wenn nicht alle laufenden Testfälle innerhalb von 5 Minuten beendet werden, wird jeder ihrer Prozesse zum Beenden IDT gezwungen. Wenn IDT vor dem Ende der Prozesse keine Testergebnisse erhalten wurden, wird das Timeout für die Testfälle als abgelaufen 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:
-
Beenden Sie die Ausführung der normalen Testlogik.
-
Bereinigen Sie alle temporären Ressourcen, z. B. Testartefakte, auf dem zu testenden Gerät.
-
Melden Sie ein Testergebnis anIDT, z. B. einen Testfehler oder einen Fehler.
-
Beenden.