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.
# Verwenden Sie IDT, um Ihre eigenen Testsuiten zu entwickeln und auszuführen
Ab IDT v4.0.1 kombiniert IDT for AWS IoT Greengrass V2 ein standardisiertes Konfigurations-Setup und ein standardisiertes Ergebnisformat mit einer Testsuite-Umgebung, mit der Sie benutzerdefinierte Testsuiten für Ihre Geräte und Gerätesoftware entwickeln können. Sie können benutzerdefinierte Tests für Ihre eigene interne Validierung hinzufügen oder sie Ihren Kunden zur Geräteverifizierung zur Verfügung stellen.
Verwenden Sie IDT, um benutzerdefinierte Testsuiten wie folgt zu entwickeln und auszuführen:
**Um benutzerdefinierte Testsuiten zu entwickeln**
+ Erstellen Sie Testsuiten mit benutzerdefinierter Testlogik für das Greengrass-Gerät, das Sie testen möchten.
+ Stellen Sie IDT Ihre benutzerdefinierten Testsuiten für Testläufer zur Verfügung. Fügen Sie Informationen zu bestimmten Einstellungskonfigurationen für Ihre Testsuiten hinzu.
**Um benutzerdefinierte Testsuiten auszuführen**
+ Richten Sie das Gerät ein, das Sie testen möchten.
+ Implementieren Sie die Einstellungskonfigurationen entsprechend den Anforderungen der Testsuiten, die Sie verwenden möchten.
+ Verwenden Sie IDT, um Ihre benutzerdefinierten Testsuiten auszuführen.
+ Sehen Sie sich die Testergebnisse und Ausführungsprotokolle für die von IDT ausgeführten Tests an.
## Laden Sie die neueste Version von für AWS IoT Device Tester herunter AWS IoT Greengrass
Laden Sie die [neueste Version](idt-programmatic-download.md) von IDT herunter und extrahieren Sie die Software an einen Speicherort (**) auf Ihrem Dateisystem, für den Sie Lese-/Schreibberechtigungen haben.
**Anmerkung**
IDT unterstützt nicht die Ausführung durch mehrere Benutzer von einem gemeinsam genutzten Speicherort aus, z. B. einem NFS-Verzeichnis oder einem freigegebenen Windows-Netzwerkordner. Es wird empfohlen, das IDT-Paket auf ein lokales Laufwerk zu extrahieren und die IDT-Binärdatei auf Ihrer lokalen Workstation auszuführen.
Windows hat eine Pfadlängenbegrenzung von 260 Zeichen. Wenn Sie Windows verwenden, extrahieren Sie IDT in ein Stammverzeichnis wie `C:\ ` oder `D:\`, um Ihre Pfade unter der Grenze von 260 Zeichen zu halten.
## Arbeitsablauf bei der Erstellung einer Testsuite
Testsuiten bestehen aus drei Arten von Dateien:
+ Konfigurationsdateien, die IDT Informationen zur Ausführung der Testsuite liefern.
+ Testen Sie ausführbare Dateien, die IDT zum Ausführen von Testfällen verwendet.
+ Zusätzliche Dateien, die zum Ausführen von Tests erforderlich sind.
Führen Sie die folgenden grundlegenden Schritte aus, um benutzerdefinierte IDT-Tests zu erstellen:
1. [Erstellen Sie Konfigurationsdateien](idt-json-config.md) für Ihre Testsuite.
1. [Erstellen Sie ausführbare Testfalldateien](create-test-executables.md), die die Testlogik für Ihre Testsuite enthalten.
1. Überprüfen und dokumentieren Sie die [Konfigurationsinformationen, die Testläufer benötigen](set-custom-idt-config.md), um die Testsuite auszuführen.
1. Stellen Sie sicher, dass IDT Ihre Testsuite ausführen und die [Testergebnisse](run-debug-custom-tests.md) erwartungsgemäß liefern kann.
Folgen Sie den Anweisungen unter, um schnell eine benutzerdefinierte Beispielsuite zu erstellen und auszuführen. [Tutorial: IDT-Beispiel-Testsuite erstellen und ausführen](build-sample-suite.md)
Erste Schritte zum Erstellen einer benutzerdefinierten Testsuite in Python finden Sie unter[Tutorial: Entwickeln Sie eine einfache IDT-Testsuite](create-custom-tests.md).
# Tutorial: IDT-Beispiel-Testsuite erstellen und ausführen
Der AWS IoT Device Tester Download enthält den Quellcode für eine Beispiel-Testsuite. Sie können dieses Tutorial abschließen, um die Beispieltestsuite zu erstellen und auszuführen, um zu verstehen, wie Sie IDT für AWS IoT Greengrass die Ausführung benutzerdefinierter Testsuiten verwenden können.
In diesem Tutorial werden Sie die folgenden Schritte ausführen:
1. [Erstellen Sie die Beispiel-Testsuite](#build-sample)
1. [Verwenden Sie IDT, um die Beispieltestsuite auszuführen](#run-sample)
## Voraussetzungen
Zum Durcharbeiten dieses Tutorials ist Folgendes erforderlich:
+
**Anforderungen an den Host-Computer**
+ Aktuelle Version von AWS IoT Device Tester
+ [Python](https://www.python.org/downloads/) 3.7 oder höher
Führen Sie den folgenden Befehl aus, um die auf Ihrem Computer installierte Version von Python zu überprüfen:
```
python3 --version
```
Wenn die Verwendung dieses Befehls unter Windows einen Fehler zurückgibt, verwenden Sie `python --version` stattdessen. Wenn die zurückgegebene Versionsnummer 3.7 oder höher ist, führen Sie den folgenden Befehl in einem Powershell-Terminal aus, um ihn `python3` als Alias für Ihren `python` Befehl festzulegen.
```
Set-Alias -Name "python3" -Value "python"
```
Wenn keine Versionsinformationen zurückgegeben werden oder wenn die Versionsnummer kleiner als 3.7 ist, folgen Sie den Anweisungen unter [Python herunterladen, um Python](https://wiki.python.org/moin/BeginnersGuide/Download) 3.7\$1 zu installieren. Weitere Informationen finden Sie in der [Python-Dokumentation](https://docs.python.org).
+ [urllib3](https://urllib3.readthedocs.io/en/latest/)
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Installation korrekt `urllib3` ist:
```
python3 -c 'import urllib3'
```
Wenn `urllib3` es nicht installiert ist, führen Sie den folgenden Befehl aus, um es zu installieren:
```
python3 -m pip install urllib3
```
+
**Anforderungen an Speichergeräte**
+ Ein Gerät mit einem Linux-Betriebssystem und einer Netzwerkverbindung zu demselben Netzwerk wie Ihr Host-Computer.
Wir empfehlen Ihnen, einen [Raspberry Pi mit Raspberry](https://www.raspberrypi.org/) Pi OS zu verwenden. Stellen Sie sicher, dass Sie [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) auf Ihrem Raspberry Pi eingerichtet haben, um eine Remoteverbindung herzustellen.
## Geräteinformationen für IDT konfigurieren
Konfigurieren Sie Ihre Geräteinformationen für IDT, um den Test auszuführen. Sie müssen die `device.json` Vorlage im `/configs` Ordner mit den folgenden Informationen aktualisieren.
```
[
{
"id": "pool",
"sku": "N/A",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
Geben Sie im `devices` Objekt die folgenden Informationen ein:
`id`
Eine benutzerdefinierte eindeutige Kennung für Ihr Gerät.
`connectivity.ip`
Die IP-Adresse Ihres Geräts.
`connectivity.port`
Optional. Die Portnummer, die für SSH-Verbindungen zu Ihrem Gerät verwendet werden soll.
`connectivity.auth`
Authentifizierungsinformationen für die Verbindung.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.auth.method`
Die Authentifizierungsmethode, die für den Zugriff über ein bestimmtes Verbindungsprotokoll auf ein Gerät verwendet wird.
Unterstützte Werte sind:
+ `pki`
+ `password`
`connectivity.auth.credentials`
Die für die Authentifizierung verwendeten Anmeldeinformationen.
`connectivity.auth.credentials.user`
Der Benutzername, mit dem Sie sich auf Ihrem Gerät angemeldet haben.
`connectivity.auth.credentials.privKeyPath`
Der vollständige Pfad zu dem privaten Schlüssel, mit dem Sie sich auf Ihrem Gerät angemeldet haben.
Dieser Wert gilt nur, wenn `connectivity.auth.method` auf `pki` festgelegt ist.
`devices.connectivity.auth.credentials.password`
Das Passwort, mit dem Sie sich auf Ihrem Gerät angemeldet haben.
Dieser Wert gilt nur, wenn `connectivity.auth.method` auf `password` festgelegt ist.
**Anmerkung**
Geben Sie `privKeyPath` nur an, wenn `method` auf `pki` gesetzt ist.
Geben Sie `password` nur an, wenn `method` auf `password` gesetzt ist.
## Erstellen Sie die Beispiel-Testsuite
Der `/samples/python` Ordner enthält Beispielkonfigurationsdateien, Quellcode und das IDT Client SDK, die Sie mithilfe der bereitgestellten Build-Skripten zu einer Testsuite kombinieren können. Die folgende Verzeichnisstruktur zeigt den Speicherort dieser Beispieldateien:
```
├── ...
├── tests
├── samples
│ ├── ...
│ └── python
│ ├── configuration
│ ├── src
│ └── build-scripts
│ ├── build.sh
│ └── build.ps1
└── sdks
├── ...
└── python
└── idt_client
```
Um die Testsuite zu erstellen, führen Sie die folgenden Befehle auf Ihrem Host-Computer aus:
------
#### [ Windows ]
```
cd /samples/python/build-scripts
./build.ps1
```
------
#### [ Linux, macOS, or UNIX ]
```
cd /samples/python/build-scripts
./build.sh
```
------
Dadurch wird die Beispiel-Testsuite in dem `IDTSampleSuitePython_1.0.0` Ordner innerhalb des `/tests` Ordners erstellt. Sehen Sie sich die Dateien im `IDTSampleSuitePython_1.0.0` Ordner an, um zu verstehen, wie die Beispieltestsuite strukturiert ist, und um verschiedene Beispiele für ausführbare Testfälle und JSON-Dateien für Testkonfigurationen zu sehen.
**Anmerkung**
Die Beispieltestsuite enthält Python-Quellcode. Nehmen Sie keine vertraulichen Informationen in Ihren Testsuite-Code auf.
Nächster Schritt: Verwenden Sie IDT, um [die von Ihnen erstellte Beispiel-Testsuite auszuführen](#run-sample).
## Verwenden Sie IDT, um die Beispieltestsuite auszuführen
Führen Sie die folgenden Befehle auf Ihrem Host-Computer aus, um die Beispiel-Testsuite auszuführen:
```
cd /bin
./devicetester_[linux | mac | win_x86-64] run-suite --suite-id IDTSampleSuitePython
```
IDT führt die Beispieltestsuite aus und streamt die Ergebnisse an die Konsole. Wenn der Test abgeschlossen ist, sehen Sie die folgenden Informationen:
```
========== Test Summary ==========
Execution Time: 5s
Tests Completed: 4
Tests Passed: 4
Tests Failed: 0
Tests Skipped: 0
----------------------------------
Test Groups:
sample_group: PASSED
----------------------------------
Path to IoT Device Tester Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/awsiotdevicetester_report.xml
Path to Test Execution Logs: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/logs
Path to Aggregated JUnit Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/IDTSampleSuitePython_Report.xml
```
## Fehlerbehebung
Verwenden Sie die folgenden Informationen, um Probleme beim Abschließen des Tutorials zu lösen.
**Der Testfall wird nicht erfolgreich ausgeführt**
Wenn der Test nicht erfolgreich ausgeführt wird, streamt IDT die Fehlerprotokolle an die Konsole, die Ihnen bei der Problembehandlung des Testlaufs helfen kann. Stellen Sie sicher, dass Sie alle [Voraussetzungen](#prereqs-tutorial-sample) für dieses Tutorial erfüllen.
**Es kann keine Verbindung zu dem zu testenden Gerät hergestellt werden**
Überprüfen Sie Folgendes:
+ Ihre `device.json` Datei enthält die richtige IP-Adresse, den richtigen Port und die richtigen Authentifizierungsinformationen.
+ Sie können von Ihrem Host-Computer aus eine Verbindung zu Ihrem Gerät über SSH herstellen.
# Tutorial: Entwickeln Sie eine einfache IDT-Testsuite
Eine Testsuite kombiniert Folgendes:
+ Testdateien, die die Testlogik enthalten
+ Konfigurationsdateien, die die Testsuite beschreiben
Dieses Tutorial zeigt Ihnen, wie Sie IDT for verwenden AWS IoT Greengrass , um eine Python-Testsuite zu entwickeln, die einen einzigen Testfall enthält. In diesem Tutorial werden Sie die folgenden Schritte ausführen:
1. [Erstellen Sie ein Testsuite-Verzeichnis](#test-suite-dir)
1. [Erstellen Sie Konfigurationsdateien](#test-suite-json)
1. [Erstellen Sie die ausführbare Testfalldatei](#test-suite-exe)
1. [Führen Sie die Testsuite aus](#run-test-suite)
## Voraussetzungen
Zum Durcharbeiten dieses Tutorials ist Folgendes erforderlich:
+
**Anforderungen an den Host-Computer**
+ Aktuelle Version von AWS IoT Device Tester
+ [Python](https://www.python.org/downloads/) 3.7 oder höher
Führen Sie den folgenden Befehl aus, um die auf Ihrem Computer installierte Version von Python zu überprüfen:
```
python3 --version
```
Wenn die Verwendung dieses Befehls unter Windows einen Fehler zurückgibt, verwenden Sie `python --version` stattdessen. Wenn die zurückgegebene Versionsnummer 3.7 oder höher ist, führen Sie den folgenden Befehl in einem Powershell-Terminal aus, um ihn `python3` als Alias für Ihren `python` Befehl festzulegen.
```
Set-Alias -Name "python3" -Value "python"
```
Wenn keine Versionsinformationen zurückgegeben werden oder wenn die Versionsnummer kleiner als 3.7 ist, folgen Sie den Anweisungen unter [Python herunterladen, um Python](https://wiki.python.org/moin/BeginnersGuide/Download) 3.7\$1 zu installieren. Weitere Informationen finden Sie in der [Python-Dokumentation](https://docs.python.org).
+ [urllib3](https://urllib3.readthedocs.io/en/latest/)
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Installation korrekt `urllib3` ist:
```
python3 -c 'import urllib3'
```
Wenn `urllib3` es nicht installiert ist, führen Sie den folgenden Befehl aus, um es zu installieren:
```
python3 -m pip install urllib3
```
+
**Anforderungen an Speichergeräte**
+ Ein Gerät mit einem Linux-Betriebssystem und einer Netzwerkverbindung zu demselben Netzwerk wie Ihr Host-Computer.
Wir empfehlen Ihnen, einen [Raspberry Pi mit Raspberry](https://www.raspberrypi.org/) Pi OS zu verwenden. Stellen Sie sicher, dass Sie [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) auf Ihrem Raspberry Pi eingerichtet haben, um eine Remoteverbindung herzustellen.
## Erstellen Sie ein Testsuite-Verzeichnis
IDT unterteilt Testfälle innerhalb jeder Testsuite logisch in Testgruppen. Jeder Testfall muss sich innerhalb einer Testgruppe befinden. Erstellen Sie für dieses Tutorial einen Ordner mit dem Namen `MyTestSuite_1.0.0` und erstellen Sie in diesem Ordner den folgenden Verzeichnisbaum:
```
MyTestSuite_1.0.0
└── suite
└── myTestGroup
└── myTestCase
```
## Erstellen Sie Konfigurationsdateien
Ihre Testsuite muss die folgenden erforderlichen [Konfigurationsdateien](idt-json-config.md) enthalten:Erforderliche Konfigurationsdateien
`suite.json`
Enthält Informationen über die Testsuite. Siehe [Konfigurieren Sie suite.json](idt-json-config.md#suite-json).
`group.json`
Enthält Informationen über eine Testgruppe. Sie müssen für jede Testgruppe in Ihrer Testsuite eine `group.json` Datei erstellen. Siehe [Konfigurieren Sie group.json](idt-json-config.md#group-json).
`test.json`
Enthält Informationen zu einem Testfall. Sie müssen für jeden Testfall in Ihrer Testsuite eine `test.json` Datei erstellen. Siehe [Konfigurieren Sie test.json](idt-json-config.md#test-json).
1. Erstellen Sie in dem `MyTestSuite_1.0.0/suite` Ordner eine `suite.json` Datei mit der folgenden Struktur:
```
{
"id": "MyTestSuite_1.0.0",
"title": "My Test Suite",
"details": "This is my test suite.",
"userDataRequired": false
}
```
1. Erstellen Sie in dem `MyTestSuite_1.0.0/myTestGroup` Ordner eine `group.json` Datei mit der folgenden Struktur:
```
{
"id": "MyTestGroup",
"title": "My Test Group",
"details": "This is my test group.",
"optional": false
}
```
1. Erstellen Sie in dem `MyTestSuite_1.0.0/myTestGroup/myTestCase` Ordner eine `test.json` Datei mit der folgenden Struktur:
```
{
"id": "MyTestCase",
"title": "My Test Case",
"details": "This is my test case.",
"execution": {
"timeout": 300000,
"linux": {
"cmd": "python3",
"args": [
"myTestCase.py"
]
},
"mac": {
"cmd": "python3",
"args": [
"myTestCase.py"
]
},
"win": {
"cmd": "python3",
"args": [
"myTestCase.py"
]
}
}
}
```
Der Verzeichnisbaum für Ihren `MyTestSuite_1.0.0` Ordner sollte jetzt wie folgt aussehen:
```
MyTestSuite_1.0.0
└── suite
├── suite.json
└── myTestGroup
├── group.json
└── myTestCase
└── test.json
```
## Holen Sie sich das IDT-Client-SDK
Sie verwenden das [IDT-Client-SDK](create-test-executables.md#idt-client-sdk), damit IDT mit dem zu testenden Gerät interagieren und Testergebnisse melden kann. Für dieses Tutorial verwenden Sie die Python-Version des SDK.
Kopieren Sie den `/sdks/python/` Ordner aus dem `idt_client` Ordner in Ihren `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` Ordner.
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob das SDK erfolgreich kopiert wurde.
```
cd MyTestSuite_1.0.0/suite/myTestGroup/myTestCase
python3 -c 'import idt_client'
```
## Erstellen Sie die ausführbare Testfalldatei
Die ausführbaren Testfalldateien enthalten die Testlogik, die Sie ausführen möchten. Eine Testsuite kann mehrere ausführbare Testfalldateien enthalten. Für dieses Tutorial erstellen Sie nur eine ausführbare Testfalldatei.
1. Erstellen Sie die Testsuite-Datei.
Erstellen Sie in dem `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` Ordner eine `myTestCase.py` Datei mit dem folgenden Inhalt:
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
if __name__ == "__main__":
main()
```
1. Verwenden Sie die Funktionen des Client-SDK, um Ihrer `myTestCase.py` Datei die folgende Testlogik hinzuzufügen:
1. Führen Sie auf dem zu testenden Gerät einen SSH-Befehl aus.
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
# Create an execute on device request
exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'"))
# Run the command
exec_resp = client.execute_on_device(exec_req)
# Print the standard output
print(exec_resp.stdout)
if __name__ == "__main__":
main()
```
1. Senden Sie das Testergebnis an IDT.
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
# Create an execute on device request
exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'"))
# Run the command
exec_resp = client.execute_on_device(exec_req)
# Print the standard output
print(exec_resp.stdout)
# Create a send result request
sr_req = SendResultRequest(TestResult(passed=True))
# Send the result
client.send_result(sr_req)
if __name__ == "__main__":
main()
```
## Geräteinformationen für IDT konfigurieren
Konfigurieren Sie Ihre Geräteinformationen für IDT, um den Test auszuführen. Sie müssen die `device.json` Vorlage im `/configs` Ordner mit den folgenden Informationen aktualisieren.
```
[
{
"id": "pool",
"sku": "N/A",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
Geben Sie im `devices` Objekt die folgenden Informationen ein:
`id`
Eine benutzerdefinierte eindeutige Kennung für Ihr Gerät.
`connectivity.ip`
Die IP-Adresse Ihres Geräts.
`connectivity.port`
Optional. Die Portnummer, die für SSH-Verbindungen zu Ihrem Gerät verwendet werden soll.
`connectivity.auth`
Authentifizierungsinformationen für die Verbindung.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.auth.method`
Die Authentifizierungsmethode, die für den Zugriff über ein bestimmtes Verbindungsprotokoll auf ein Gerät verwendet wird.
Unterstützte Werte sind:
+ `pki`
+ `password`
`connectivity.auth.credentials`
Die für die Authentifizierung verwendeten Anmeldeinformationen.
`connectivity.auth.credentials.user`
Der Benutzername, mit dem Sie sich auf Ihrem Gerät angemeldet haben.
`connectivity.auth.credentials.privKeyPath`
Der vollständige Pfad zu dem privaten Schlüssel, mit dem Sie sich auf Ihrem Gerät angemeldet haben.
Dieser Wert gilt nur, wenn `connectivity.auth.method` auf `pki` festgelegt ist.
`devices.connectivity.auth.credentials.password`
Das Passwort, mit dem Sie sich auf Ihrem Gerät angemeldet haben.
Dieser Wert gilt nur, wenn `connectivity.auth.method` auf `password` festgelegt ist.
**Anmerkung**
Geben Sie `privKeyPath` nur an, wenn `method` auf `pki` gesetzt ist.
Geben Sie `password` nur an, wenn `method` auf `password` gesetzt ist.
## Führen Sie die Testsuite aus
Nachdem Sie Ihre Testsuite erstellt haben, möchten Sie sicherstellen, dass sie wie erwartet funktioniert. Führen Sie dazu die folgenden Schritte aus, um die Testsuite mit Ihrem vorhandenen Gerätepool auszuführen.
1. Kopieren Sie Ihren `MyTestSuite_1.0.0` Ordner in`/tests`.
1. Führen Sie die folgenden Befehle aus:
```
cd /bin
./devicetester_[linux | mac | win_x86-64] run-suite --suite-id MyTestSuite
```
IDT führt Ihre Testsuite aus und streamt die Ergebnisse an die Konsole. Wenn der Test abgeschlossen ist, sehen Sie die folgenden Informationen:
```
time="2020-10-19T09:24:47-07:00" level=info msg=Using pool: pool
time="2020-10-19T09:24:47-07:00" level=info msg=Using test suite "MyTestSuite_1.0.0" for execution
time="2020-10-19T09:24:47-07:00" level=info msg=b'hello world\n' suiteId=MyTestSuite groupId=myTestGroup testCaseId=myTestCase deviceId=my-device executionId=9a52f362-1227-11eb-86c9-8c8590419f30
time="2020-10-19T09:24:47-07:00" level=info msg=All tests finished. executionId=9a52f362-1227-11eb-86c9-8c8590419f30
time="2020-10-19T09:24:48-07:00" level=info msg=
========== Test Summary ==========
Execution Time: 1s
Tests Completed: 1
Tests Passed: 1
Tests Failed: 0
Tests Skipped: 0
----------------------------------
Test Groups:
myTestGroup: PASSED
----------------------------------
Path to IoT Device Tester Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/awsiotdevicetester_report.xml
Path to Test Execution Logs: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/logs
Path to Aggregated JUnit Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/MyTestSuite_Report.xml
```
## Fehlerbehebung
Verwenden Sie die folgenden Informationen, um Probleme beim Abschließen des Tutorials zu lösen.
**Der Testfall wird nicht erfolgreich ausgeführt**
Wenn der Test nicht erfolgreich ausgeführt wird, streamt IDT die Fehlerprotokolle an die Konsole, die Ihnen bei der Problembehandlung des Testlaufs helfen kann. Bevor Sie die Fehlerprotokolle überprüfen, überprüfen Sie Folgendes:
+ Das IDT-Client-SDK befindet sich im richtigen Ordner, wie in [diesem Schritt](#add-idt-sdk) beschrieben.
+ Sie erfüllen alle [Voraussetzungen](#prereqs-tutorial-custom) für dieses Tutorial.
**Es kann keine Verbindung zu dem zu testenden Gerät hergestellt werden**
Überprüfen Sie Folgendes:
+ Ihre `device.json` Datei enthält die richtige IP-Adresse, den richtigen Port und die richtigen Authentifizierungsinformationen.
+ Sie können von Ihrem Host-Computer aus eine Verbindung zu Ihrem Gerät über SSH herstellen.
# Erstellen Sie Konfigurationsdateien für die IDT-Testsuite
In diesem Abschnitt werden die Formate beschrieben, in denen Sie Konfigurationsdateien erstellen, die Sie beim Schreiben einer benutzerdefinierten Testsuite einbeziehen.Erforderliche Konfigurationsdateien
`suite.json`
Enthält Informationen über die Testsuite. Siehe [Konfigurieren Sie suite.json](#suite-json).
`group.json`
Enthält Informationen über eine Testgruppe. Sie müssen für jede Testgruppe in Ihrer Testsuite eine `group.json` Datei erstellen. Siehe [Konfigurieren Sie group.json](#group-json).
`test.json`
Enthält Informationen zu einem Testfall. Sie müssen für jeden Testfall in Ihrer Testsuite eine `test.json` Datei erstellen. Siehe [Konfigurieren Sie test.json](#test-json).Optionale Konfigurationsdateien
`test_orchestrator.yaml` oder `state_machine.json`
Definiert, wie Tests ausgeführt werden, wenn IDT die Testsuite ausführt. SSe [Konfigurieren Sie test\$1orchestrator.yaml](#test-orchestrator-config).
Ab IDT v4.5.1 verwenden Sie die `test_orchestrator.yaml` Datei, um den Test-Workflow zu definieren. In früheren Versionen von IDT verwenden Sie die Datei. `state_machine.json` Informationen zur Zustandsmaschine finden Sie unter[Konfigurieren Sie die IDT-Zustandsmaschine](idt-state-machine.md).
`userdata_schema.json`
Definiert das Schema für die [`userdata.json`Datei](set-custom-idt-config.md#userdata-config-custom), die Testläufer in ihre Einstellungskonfiguration aufnehmen können. Die `userdata.json` Datei wird für alle zusätzlichen Konfigurationsinformationen verwendet, die für die Ausführung des Tests erforderlich sind, aber nicht in der `device.json` Datei enthalten sind. Siehe [Konfigurieren Sie userdata\$1schema.json](#userdata-schema-json).
Die Konfigurationsdateien werden `` wie hier gezeigt in Ihrem abgelegt.
```
└── suite
├── suite.json
├── test_orchestrator.yaml
├── userdata_schema.json
├──
├── group.json
├──
└── test.json
```
## Konfigurieren Sie suite.json
Die `suite.json` Datei legt Umgebungsvariablen fest und bestimmt, ob Benutzerdaten für die Ausführung der Testsuite erforderlich sind. Verwenden Sie die folgende Vorlage, um Ihre `/suite/suite.json` Datei zu konfigurieren:
```
{
"id": "_",
"title": "",
"details": "",
"userDataRequired": true | false,
"environmentVariables": [
{
"key": "",
"value": "",
},
...
{
"key": "",
"value": "",
}
]
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`id`
Eine eindeutige benutzerdefinierte ID für die Testsuite. Der Wert von `id` muss mit dem Namen des Testsuite-Ordners übereinstimmen, in dem sich die `suite.json` Datei befindet. Der Name der Suite und die Suite-Version müssen außerdem die folgenden Anforderungen erfüllen:
+ ``darf keine Unterstriche enthalten.
+ ``wird bezeichnet als`x.x.x`, wo `x` ist eine Zahl.
Die ID wird in IDT-generierten Testberichten angezeigt.
`title`
Ein benutzerdefinierter Name für das Produkt oder die Funktion, das von dieser Testsuite getestet wird. Der Name wird in der IDT-CLI für Testläufer angezeigt.
`details`
Eine kurze Beschreibung des Zwecks der Testsuite.
`userDataRequired`
Definiert, ob Testläufer benutzerdefinierte Informationen in eine `userdata.json` Datei aufnehmen müssen. Wenn Sie diesen Wert auf setzen`true`, müssen Sie die [`userdata_schema.json`Datei](#userdata-schema-json) auch in Ihren Testsuite-Ordner aufnehmen.
`environmentVariables`
Optional. Ein Array von Umgebungsvariablen, die für diese Testsuite festgelegt werden sollen.
`environmentVariables.key`
Der Name der Umgebungsvariable.
`environmentVariables.value`
Der Wert der Umgebungsvariable.
## Konfigurieren Sie group.json
Die `group.json` Datei definiert, ob eine Testgruppe erforderlich oder optional ist. Verwenden Sie die folgende Vorlage, um Ihre `/suite//group.json` Datei zu konfigurieren:
```
{
"id": "",
"title": "",
"details": "",
"optional": true | false,
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`id`
Eine eindeutige benutzerdefinierte ID für die Testgruppe. Der Wert von `id` muss mit dem Namen des Testgruppenordners übereinstimmen, in dem sich die `group.json` Datei befindet, und darf keine Unterstriche () `_` enthalten. Die ID wird in IDT-generierten Testberichten verwendet.
`title`
Ein beschreibender Name für die Testgruppe. Der Name wird in der IDT-CLI für Testläufer angezeigt.
`details`
Eine kurze Beschreibung des Zwecks der Testgruppe.
`optional`
Optional. Stellen Sie diese Option ein`true`, um diese Testgruppe als optionale Gruppe anzuzeigen, nachdem IDT die Ausführung der erforderlichen Tests abgeschlossen hat. Der Standardwert ist `false`.
## Konfigurieren Sie test.json
Die `test.json` Datei bestimmt die ausführbaren Testfalldateien und die Umgebungsvariablen, die von einem Testfall verwendet werden. Weitere Hinweise zum Erstellen von ausführbaren Testfalldateien finden Sie unter. [Ausführbare IDT-Testfalldateien erstellen](create-test-executables.md)
Verwenden Sie die folgende Vorlage, um Ihre `/suite///test.json` Datei zu konfigurieren:
```
{
"id": "",
"title": "",
"details": "",
"requireDUT": true | false,
"requiredResources": [
{
"name": "",
"features": [
{
"name": "",
"version": "",
"jobSlots":
}
]
}
],
"execution": {
"timeout": ,
"mac": {
"cmd": "/path/to/executable",
"args": [
""
],
},
"linux": {
"cmd": "/path/to/executable",
"args": [
""
],
},
"win": {
"cmd": "/path/to/executable",
"args": [
""
]
}
},
"environmentVariables": [
{
"key": "",
"value": "",
}
]
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`id`
Eine eindeutige benutzerdefinierte ID für den Testfall. Der Wert von `id` muss mit dem Namen des Testfallordners übereinstimmen, in dem sich die `test.json` Datei befindet, und darf keine Unterstriche () `_` enthalten. Die ID wird in IDT-generierten Testberichten verwendet.
`title`
Ein beschreibender Name für den Testfall. Der Name wird in der IDT-CLI für Testläufer angezeigt.
`details`
Eine kurze Beschreibung des Zwecks des Testfalls.
`requireDUT`
Optional. `true`Ist auf eingestellt, wenn ein Gerät für die Ausführung dieses Tests erforderlich ist, andernfalls auf`false`. Der Standardwert ist `true`. Testläufer konfigurieren die Geräte, mit denen sie den Test ausführen, in ihrer `device.json` Datei.
`requiredResources`
Optional. Ein Array, das Informationen über Ressourcengeräte bereitstellt, die für die Ausführung dieses Tests benötigt werden.
`requiredResources.name`
Der eindeutige Name, der dem Ressourcengerät gegeben werden soll, wenn dieser Test ausgeführt wird.
`requiredResources.features`
Eine Reihe von benutzerdefinierten Funktionen für Ressourcengeräte.
`requiredResources.features.name`
Der Name der Funktion. Die Gerätefunktion, für die Sie dieses Gerät verwenden möchten. Dieser Name wird mit dem Funktionsnamen abgeglichen, den der Testrunner in der `resource.json` Datei angegeben hat.
`requiredResources.features.version`
Optional. Die Version der Funktion. Dieser Wert wird mit der vom Test-Runner in der `resource.json` Datei bereitgestellten Feature-Version abgeglichen. Wenn keine Version bereitgestellt wird, wird die Funktion nicht überprüft. Wenn für die Funktion keine Versionsnummer erforderlich ist, lassen Sie dieses Feld leer.
`requiredResources.features.jobSlots`
Optional. Die Anzahl der gleichzeitigen Tests, die diese Funktion unterstützen kann. Der Standardwert ist `1`. Wenn Sie möchten, dass IDT unterschiedliche Geräte für einzelne Funktionen verwendet, empfehlen wir Ihnen, diesen Wert auf `1` festzulegen.
`execution.timeout`
Die Zeit (in Millisekunden), die IDT wartet, bis der Test abgeschlossen ist. Weitere Informationen zum Einstellen dieses Werts finden Sie unter. [Ausführbare IDT-Testfalldateien erstellen](create-test-executables.md)
`execution.os`
Die ausführbaren Testfalldateien, die auf dem Betriebssystem des Host-Computers ausgeführt werden sollen, basieren auf dem Betriebssystem, auf dem IDT ausgeführt wird. Unterstützte Werte sind `linux`, `mac` und `win`.
`execution.os.cmd`
Der Pfad zu der ausführbaren Testfalldatei, die Sie für das angegebene Betriebssystem ausführen möchten. Dieser Speicherort muss sich im Systempfad befinden.
`execution.os.args`
Optional. Die Argumente, die zur Ausführung der ausführbaren Testfalldatei angegeben werden müssen.
`environmentVariables`
Optional. Ein Array von Umgebungsvariablen, die für diesen Testfall festgelegt wurden.
`environmentVariables.key`
Der Name der Umgebungsvariable.
`environmentVariables.value`
Der Wert der Umgebungsvariable.
Wenn Sie dieselbe Umgebungsvariable in der `test.json` Datei und in der `suite.json` Datei angeben, hat der Wert in der `test.json` Datei Vorrang.
## Konfigurieren Sie test\$1orchestrator.yaml
Ein Testorchestrator ist ein Konstrukt, das den Ausführungsablauf der Testsuite steuert. Er bestimmt den Startstatus einer Testsuite, verwaltet Zustandsübergänge auf der Grundlage benutzerdefinierter Regeln und setzt den Übergang durch diese Zustände fort, bis der Endstatus erreicht ist.
Wenn Ihre Testsuite keinen benutzerdefinierten Test-Orchestrator enthält, generiert IDT einen Test-Orchestrator für Sie.
Der Standard-Test-Orchestrator führt die folgenden Funktionen aus:
+ Bietet Testläufern die Möglichkeit, anstelle der gesamten Testsuite bestimmte Testgruppen auszuwählen und auszuführen.
+ Wenn keine bestimmten Testgruppen ausgewählt sind, wird jede Testgruppe in der Testsuite in zufälliger Reihenfolge ausgeführt.
+ Generiert Berichte und druckt eine Konsolenübersicht aus, in der die Testergebnisse für jede Testgruppe und jeden Testfall angezeigt werden.
Weitere Informationen zur Funktionsweise des IDT Test Orchestrator finden Sie unter. [Konfigurieren Sie den IDT-Testorchestrator](idt-test-orchestrator.md)
## Konfigurieren Sie userdata\$1schema.json
Die `userdata_schema.json` Datei bestimmt das Schema, in dem Testläufer Benutzerdaten bereitstellen. Benutzerdaten sind erforderlich, wenn Ihre Testsuite Informationen benötigt, die nicht in der `device.json` Datei enthalten sind. Beispielsweise benötigen Ihre Tests möglicherweise Anmeldeinformationen für Wi-Fi-Netzwerke, bestimmte offene Ports oder Zertifikate, die ein Benutzer bereitstellen muss. Diese Informationen können IDT als Eingabeparameter zur Verfügung gestellt werden`userdata`, dessen Wert eine `userdata.json` Datei ist, die Benutzer in ihrem `/config` Ordner erstellen. Das Format der `userdata.json` Datei basiert auf der `userdata_schema.json` Datei, die Sie in die Testsuite aufnehmen.
Um anzugeben, dass Testläufer eine `userdata.json` Datei bereitstellen müssen:
1. Stellen Sie in der `suite.json` Datei `userDataRequired` auf ein`true`.
1. Erstellen Sie in Ihrem `` eine `userdata_schema.json` Datei.
1. Bearbeiten Sie die `userdata_schema.json` Datei, um ein gültiges [IETF-Draft v4-JSON-Schema](https://json-schema.org/specification-links.html#draft-4) zu erstellen.
Wenn IDT Ihre Testsuite ausführt, liest es automatisch das Schema und verwendet es, um die vom Testläufer bereitgestellte `userdata.json` Datei zu validieren. Falls gültig, ist der Inhalt der `userdata.json` Datei sowohl im [IDT-Kontext als auch im [Test-Orchestrator-Kontext](idt-state-machine.md#state-machine-context)](idt-context.md) verfügbar.
# Konfigurieren Sie den IDT-Testorchestrator
*Ab IDT v4.5.1 enthält IDT eine neue Test Orchestrator-Komponente.* Der Testorchestrator ist eine IDT-Komponente, die den Ausführungsablauf der Testsuite steuert und den Testbericht generiert, nachdem IDT alle Tests ausgeführt hat. Der Testorchestrator bestimmt die Testauswahl und die Reihenfolge, in der Tests ausgeführt werden, auf der Grundlage benutzerdefinierter Regeln.
Wenn Ihre Testsuite keinen benutzerdefinierten Test-Orchestrator enthält, generiert IDT einen Test-Orchestrator für Sie.
Der Standard-Test-Orchestrator führt die folgenden Funktionen aus:
+ Bietet Testläufern die Möglichkeit, anstelle der gesamten Testsuite bestimmte Testgruppen auszuwählen und auszuführen.
+ Wenn keine bestimmten Testgruppen ausgewählt sind, wird jede Testgruppe in der Testsuite in zufälliger Reihenfolge ausgeführt.
+ Generiert Berichte und druckt eine Konsolenübersicht aus, in der die Testergebnisse für jede Testgruppe und jeden Testfall angezeigt werden.
Der Test-Orchestrator ersetzt den IDT-Test-Orchestrator. Wir empfehlen dringend, anstelle des IDT-Testorchestrators den Testorchestrator für die Entwicklung Ihrer Testsuiten zu verwenden. Der Test-Orchestrator bietet die folgenden verbesserten Funktionen:
+ Verwendet ein deklaratives Format im Vergleich zum imperativen Format, das die IDT-Zustandsmaschine 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 Bearbeitung bestimmter Gruppen, die Generierung von Berichten, die Fehlerbehandlung und die Ergebnisverfolgung, sodass Sie diese Aktionen nicht manuell verwalten müssen.
+ Verwendet das YAML-Format, das Kommentare standardmäßig unterstützt.
+ Benötigt 80 Prozent weniger Festplattenspeicher als der Test-Orchestrator, um denselben Workflow zu definieren.
+ Fügt eine Validierung vor dem Test hinzu, um sicherzustellen, dass Ihre Workflow-Definition keine falschen Test IDs - oder zirkulären Abhängigkeiten enthält.
## Testen Sie das Orchestrator-Format
Sie können die folgende Vorlage verwenden, um Ihre eigene `/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 Zeichenketten, die Kontextausdrücken zugeordnet sind. Aliase ermöglichen es Ihnen, benutzerfreundliche Namen zu generieren, um Kontextausdrücke in Ihrer Test-Orchestrator-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 [Greifen Sie auf Daten im Kontext zu](idt-context.md#accessing-context-data).
**Example 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 der Bedingungen und der entsprechenden Testfälle, die ausgeführt werden, wenn jede Bedingung erfüllt ist. Jede Bedingung kann mehrere Testfälle haben. Sie können einen bestimmten Testfall jedoch nur einer Bedingung 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 einen booleschen Wert ergibt. Wenn der ausgewertete Wert wahr ist, führt IDT die im Parameter angegebenen Testfälle aus. `Tests`
`Tests`
Die Liste der Testdeskriptoren.
Jeder Testdeskriptor verwendet die Testgruppen-ID und einen oder mehrere Testfälle, um die einzelnen Tests IDs zu identifizieren, die von einer bestimmten Testgruppe aus ausgeführt werden sollen. Der Testdeskriptor verwendet das folgende Format:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
**Example Beispiel**
Im folgenden Beispiel werden generische Kontextausdrücke verwendet, die Sie als `Aliases` definieren können.
```
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 `Condition1` dies zutrifft, führt IDT die Tests in den Testgruppen A, B und C durch.
+ Wenn `Condition2` dies zutrifft, führt IDT die Tests in den Testgruppen C und D durch.
`Order`
Optional. Die Reihenfolge, in der die Tests ausgeführt werden. Sie geben die Testreihenfolge auf der Ebene der Testgruppen an. Wenn Sie diesen Abschnitt nicht angeben, führt IDT alle zutreffenden Testgruppen in zufälliger Reihenfolge aus. Der Wert von `Order` ist eine Liste von Gruppendeskriptorlisten. Jede Testgruppe, in der Sie nicht aufgeführt sind`Order`, 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 Gruppen ausgeführt werden sollen, die in den einzelnen Deskriptoren angegeben sind. 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 außerdem die folgenden Anforderungen erfüllen:
+ Die Testgruppe IDs , die Sie in einem Gruppendeskriptor angeben, muss in Ihrer Testsuite vorhanden sein.
+ Jede Gruppendeskriptorliste muss mindestens eine Testgruppe enthalten.
+ Jede Gruppendeskriptorliste muss eine eindeutige Gruppe enthalten. IDs Sie können eine Testgruppen-ID nicht innerhalb einzelner Gruppendeskriptoren wiederholen.
+ Eine Gruppendeskriptorliste kann höchstens einen Platzhalter-Gruppendeskriptor enthalten. Der Platzhalter-Gruppendeskriptor muss das erste oder das letzte Element in der Liste sein.
**Example Beispiele**
Für eine Testsuite, die die Testgruppen A, B, C, D und E enthält, zeigt die folgende Beispielliste verschiedene Möglichkeiten, um anzugeben, dass IDT zuerst die Testgruppe A, dann die Testgruppe B und dann die 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.
Bei einer Produktfunktion handelt es sich um benutzerdefinierte Informationen über bestimmte Kriterien, die ein Gerät möglicherweise erfüllt. Beispielsweise kann die MQTT-Produktfunktion angeben, dass das Gerät MQTT-Nachrichten ordnungsgemäß veröffentlicht. In werden Produktfunktionen als`awsiotdevicetester_report.xml`, oder als benutzerdefinierter benutzerdefinierter Wert festgelegt `supported``not-supported`, je nachdem, ob die angegebenen Tests bestanden wurden.
Jedes Element in der `Features` Liste besteht aus den folgenden Parametern:
`Name`
Der Name der Funktion.
`Value`
Optional. Der benutzerdefinierte Wert, den Sie anstelle von im Bericht verwenden möchten`supported`. Wenn dieser Wert nicht angegeben ist, legt Based IDT den Feature-Wert auf `supported` oder `not-supported` basierend auf Testergebnissen fest. Wenn Sie dasselbe Feature mit unterschiedlichen Bedingungen testen, können Sie für jede Instanz 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 die Funktion dem Testbericht hinzu, nachdem die Ausführung der Testsuite abgeschlossen ist. Wenn der ausgewertete Wert falsch ist, ist der Test nicht im Bericht enthalten.
`Tests`
Optional. Die Liste der Testdeskriptoren. Alle Tests, die in dieser Liste aufgeführt sind, müssen bestanden werden, damit die Funktion unterstützt wird.
Jeder Testdeskriptor in dieser Liste verwendet die Testgruppen-ID und einen oder mehrere Testfälle, um die einzelnen Tests IDs zu identifizieren, die von einer bestimmten Testgruppe aus ausgeführt werden sollen. Der Testdeskriptor verwendet das folgende Format:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
Sie müssen `OneOfTests` für jedes Feature in der `Features` Liste entweder `Tests` oder angeben.
`OneOfTests`
Optional. Die Liste der Testdeskriptoren. Mindestens einer der in dieser Liste aufgeführten Tests muss bestanden werden, damit die Funktion unterstützt wird.
Jeder Testdeskriptor in dieser Liste verwendet die Testgruppen-ID und einen oder mehrere Testfälle, um die einzelnen Tests IDs zu identifizieren, die von einer bestimmten Testgruppe aus ausgeführt werden sollen. Der Testdeskriptor verwendet das folgende Format:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
Sie müssen `OneOfTests` für jedes Feature in der `Features` Liste entweder `Tests` oder angeben.
`IsRequired`
Der boolesche Wert, der definiert, ob die Funktion im Testbericht erforderlich ist. Der Standardwert ist `false`.
**Example**
## Testen Sie den Orchestrator-Kontext
Der Test-Orchestrator-Kontext ist ein schreibgeschütztes JSON-Dokument, das Daten enthält, die dem Test-Orchestrator während der Ausführung zur Verfügung stehen. Der Test-Orchestrator-Kontext ist nur vom Test-Orchestrator aus zugänglich und enthält Informationen, die den Testablauf bestimmen. Sie können beispielsweise Informationen verwenden, die von Testläufern in der `userdata.json` Datei konfiguriert wurden, um festzustellen, ob ein bestimmter Test ausgeführt werden muss.
Der Test-Orchestrator-Kontext verwendet das folgende Format:
```
{
"pool": {
},
"userData": {
},
"config": {
}
}
```
`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.json` Datei.
`config`
Informationen in der `config.json` Datei.
Sie können den Kontext mithilfe der JSONPath Notation abfragen. Die Syntax für JSONPath Abfragen in Statusdefinitionen lautet`{{query}}`. Wenn Sie auf Daten aus dem Test Orchestrator-Kontext zugreifen, stellen Sie sicher, dass jeder Wert eine Zeichenfolge, eine Zahl oder einen booleschen Wert ergibt.
Weitere Hinweise zur Verwendung der JSONPath Notation für den Zugriff auf Daten aus dem Kontext finden Sie unter. [Verwenden Sie den IDT-Kontext](idt-context.md)
# Konfigurieren Sie die IDT-Zustandsmaschine
**Wichtig**
Ab IDT v4.5.1 ist diese Zustandsmaschine veraltet. Wir empfehlen dringend, den neuen Test-Orchestrator zu verwenden. Weitere Informationen finden Sie unter [Konfigurieren Sie den IDT-Testorchestrator](idt-test-orchestrator.md).
Eine Zustandsmaschine ist ein Konstrukt, das den Ausführungsablauf der Testsuite steuert. Sie bestimmt den Startstatus einer Testsuite, verwaltet Zustandsübergänge auf der Grundlage benutzerdefinierter Regeln und setzt den Übergang durch diese Zustände fort, bis der Endstatus erreicht ist.
Wenn Ihre Testsuite keine benutzerdefinierte Zustandsmaschine enthält, generiert IDT eine Zustandsmaschine für Sie. Die Standard-Zustandsmaschine erfüllt die folgenden Funktionen:
+ Bietet Testläufern die Möglichkeit, anstelle der gesamten Testsuite bestimmte Testgruppen auszuwählen und auszuführen.
+ Wenn keine bestimmten Testgruppen ausgewählt sind, wird jede Testgruppe in der Testsuite in zufälliger Reihenfolge ausgeführt.
+ Generiert Berichte und druckt eine Konsolenübersicht aus, in der die Testergebnisse für jede Testgruppe und jeden Testfall angezeigt werden.
Die Zustandsmaschine für eine IDT-Testsuite muss die folgenden Kriterien erfüllen:
+ Jeder Status entspricht einer Aktion, die IDT ausführen muss, z. B. dem Ausführen einer Testgruppe oder eines Produkts oder einer Berichtsdatei.
+ Beim Übergang zu einem Status wird die mit dem Status verknüpfte Aktion ausgeführt.
+ Jeder Status definiert die Übergangsregel für den nächsten Status.
+ Der Endstatus muss entweder `Succeed` oder sein`Fail`.
## Format der Zustandsmaschine
Sie können die folgende Vorlage verwenden, um Ihre eigene `/suite/state_machine.json` Datei zu konfigurieren:
```
{
"Comment": "",
"StartAt": "",
"States": {
"": {
"Type": "",
// Additional state configuration
}
// Required states
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`Comment`
Eine Beschreibung der Zustandsmaschine.
`StartAt`
Der Name des Status, in dem IDT mit der Ausführung der Testsuite beginnt. Der Wert von `StartAt` muss auf einen der im `States` Objekt aufgelisteten Zustände gesetzt werden.
`States`
Ein Objekt, das benutzerdefinierte Statusnamen gültigen IDT-Staaten zuordnet. Jeder Bundesstaat. *state-name*Objekt enthält die Definition eines gültigen Zustands, der dem zugeordnet ist*state-name*.
Das `States` Objekt muss die `Fail` Zustände `Succeed` und enthalten. Hinweise zu gültigen Bundesstaaten finden Sie unter[Gültige Staaten und Bundesstaatendefinitionen](#valid-states).
## Gültige Staaten und Bundesstaatendefinitionen
In diesem Abschnitt werden die Zustandsdefinitionen aller gültigen Staaten beschrieben, die in der IDT-Zustandsmaschine verwendet werden können. Einige der folgenden Staaten unterstützen Konfigurationen auf Testfallebene. Wir empfehlen jedoch, Regeln für den Statusübergang auf Testgruppenebene statt auf Testfallebene zu konfigurieren, sofern dies nicht unbedingt erforderlich ist.
**Topics**
+ [RunTask](#state-runtask)
+ [Choice](#state-choice)
+ [Parallel](#state-parallel)
+ [AddProductFeatures](#state-addproductfeatures)
+ [Bericht](#state-report)
+ [LogMessage](#state-logmessage)
+ [SelectGroup](#state-selectgroup)
+ [Fehler](#state-fail)
+ [Succeed](#state-succeed)
### RunTask
Der `RunTask` Staat führt Testfälle aus einer in der Testsuite definierten Testgruppe aus.
```
{
"Type": "RunTask",
"Next": "",
"TestGroup": "",
"TestCases": [
""
],
"ResultVar": ""
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`Next`
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
`TestGroup`
Optional. Die ID der Testgruppe, die ausgeführt werden soll. Wenn dieser Wert nicht angegeben ist, führt IDT die Testgruppe aus, die der Testläufer auswählt.
`TestCases`
Optional. Ein Array von Testfällen IDs aus der in `TestGroup` angegebenen Gruppe. Basierend auf den Werten von `TestGroup` und `TestCases` bestimmt IDT das Verhalten der Testausführung wie folgt:
+ Wenn `TestGroup` sowohl als auch angegeben `TestCases` sind, führt IDT die angegebenen Testfälle aus der Testgruppe aus.
+ Wenn `TestCases` angegeben, aber nicht angegeben `TestGroup` ist, führt IDT die angegebenen Testfälle aus.
+ Wenn `TestGroup` angegeben, aber nicht angegeben `TestCases` ist, führt IDT alle Testfälle innerhalb der angegebenen Testgruppe aus.
+ Wenn weder `TestGroup` oder angegeben `TestCases` ist, führt IDT alle Testfälle aus der Testgruppe aus, die der Testläufer aus der IDT-CLI auswählt. Um die Gruppenauswahl für Testläufer zu aktivieren, müssen Sie `RunTask` sowohl Status als auch `Choice` Status in Ihre `state_machine.json` Datei aufnehmen. Ein Beispiel dafür, wie das funktioniert, finden Sie unter [Beispiel für eine Zustandsmaschine: Vom Benutzer ausgewählte Testgruppen ausführen](#allow-specific-groups).
Weitere Informationen zur Aktivierung von IDT-CLI-Befehlen für Testläufer finden Sie unter[IDT-CLI-Befehle aktivieren](create-test-executables.md#idt-cli-coop).
`ResultVar`
Der Name der Kontextvariablen, die mit den Ergebnissen des Testlaufs festgelegt werden soll. Geben Sie diesen Wert nicht an, wenn Sie keinen Wert für angegeben haben`TestGroup`. IDT legt den Wert der Variablen, die Sie definieren, auf `true` oder `ResultVar` auf der `false` Grundlage der folgenden Werte fest:
+ Wenn der Variablenname die Form hat`text_text_passed`, wird der Wert darauf gesetzt, ob alle Tests in der ersten Testgruppe bestanden oder übersprungen wurden.
+ In allen anderen Fällen wird der Wert darauf gesetzt, ob alle Tests in allen Testgruppen bestanden wurden oder ob sie übersprungen wurden.
In der Regel verwenden Sie `RunTask` state, um eine Testgruppen-ID ohne Angabe eines einzelnen Testfalls anzugeben IDs, sodass IDT alle Testfälle in der angegebenen Testgruppe ausführt. Alle Testfälle, die von diesem Status ausgeführt werden, werden parallel in zufälliger Reihenfolge ausgeführt. Wenn jedoch für alle Testfälle ein Gerät ausgeführt werden muss und nur ein einziges Gerät verfügbar ist, werden die Testfälle stattdessen sequentiell ausgeführt.
**Fehlerbehandlung**
Wenn eine der angegebenen Testgruppen oder Testfälle nicht gültig ist, IDs gibt dieser Status den `RunTaskError` Ausführungsfehler aus. Wenn im Status ein Ausführungsfehler auftritt, wird auch die `hasExecutionError` Variable im Zustandsmaschinenkontext auf gesetzt`true`.
### Choice
Mit `Choice` diesem Status können Sie basierend auf benutzerdefinierten Bedingungen dynamisch den nächsten Status festlegen, zu dem der Übergang erfolgen soll.
```
{
"Type": "Choice",
"Default": "",
"FallthroughOnError": true | false,
"Choices": [
{
"Expression": "",
"Next": ""
}
]
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`Default`
Der Standardstatus, in den der Übergang erfolgen soll, wenn keiner der in definierten Ausdrücke ausgewertet werden `Choices` kann. `true`
`FallthroughOnError`
Optional. Gibt das Verhalten an, wenn der Status bei der Auswertung von Ausdrücken auf einen Fehler stößt. Legt fest, `true` ob Sie einen Ausdruck überspringen möchten, wenn die Auswertung zu einem Fehler führt. Wenn keine Ausdrücke übereinstimmen, wechselt die Zustandsmaschine in den `Default` Status. Wenn der `FallthroughOnError` Wert nicht angegeben ist, wird standardmäßig der Wert verwendet. `false`
`Choices`
Eine Reihe von Ausdrücken und Zuständen, um zu bestimmen, in welchen Status nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
`Choices.Expression`
Eine Ausdruckszeichenfolge, die einen booleschen Wert ergibt. Wenn der Ausdruck zu ausgewertet wird`true`, geht die Zustandsmaschine in den Zustand über, der in definiert ist. `Choices.Next` Ausdruckszeichenfolgen rufen Werte aus dem Zustandsmaschinen-Kontext ab und führen dann Operationen an ihnen durch, um einen booleschen Wert zu erhalten. Hinweise zum Zugriff auf den Zustandsmaschinenkontext finden Sie unter. [Kontext der Zustandsmaschine](#state-machine-context)
`Choices.Next`
Der Name des Zustands, zu dem der Übergang erfolgen soll, wenn der in definierte Ausdruck zu `Choices.Expression` ausgewertet wird. `true`
**Fehlerbehandlung**
In den folgenden Fällen kann für den `Choice` Status eine Fehlerbehandlung erforderlich sein:
+ Einige Variablen in den Auswahlausdrücken sind im Zustandsmaschinen-Kontext nicht vorhanden.
+ Das Ergebnis eines Ausdrucks ist kein boolescher Wert.
+ Das Ergebnis einer JSON-Suche ist keine Zeichenfolge, Zahl oder boolescher Wert.
In diesem Status können Sie keinen `Catch` Block verwenden, um Fehler zu behandeln. Wenn Sie die Ausführung der Zustandsmaschine beenden möchten, wenn sie auf einen Fehler stößt, müssen Sie `FallthroughOnError` auf einstellen`false`. Wir empfehlen jedoch, dass Sie die Einstellung `FallthroughOnError` auf `true` festlegen und je nach Anwendungsfall eine der folgenden Aktionen ausführen:
+ Wenn davon ausgegangen wird, dass eine Variable, auf die Sie zugreifen, in einigen Fällen nicht existiert, verwenden Sie den Wert von `Default` und zusätzliche `Choices` Blöcke, um den nächsten Status anzugeben.
+ Wenn eine Variable, auf die Sie zugreifen, immer existieren sollte, setzen Sie den `Default` Status auf`Fail`.
### Parallel
Mit dem `Parallel` Status können Sie neue Zustandsmaschinen definieren und parallel zueinander ausführen.
```
{
"Type": "Parallel",
"Next": "",
"Branches": [
]
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`Next`
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
`Branches`
Eine Reihe von Zustandsmaschinendefinitionen, die ausgeführt werden sollen. Jede Zustandsmaschinen-Definition muss ihre eigenen `StartAt``Succeed`, und `Fail` -Zustände enthalten. Die Zustandsmaschinendefinitionen in diesem Array können nicht auf Zustände verweisen, die außerhalb ihrer eigenen Definition liegen.
Da jeder Zustandsmaschine denselben Zustandsmaschinenkontext verwendet, kann das Setzen von Variablen in einem Zweig und das anschließende Lesen dieser Variablen aus einem anderen Zweig zu unerwartetem Verhalten führen.
Der `Parallel` Status wechselt erst in den nächsten Status, nachdem er alle Branch-State-Machines ausgeführt hat. Jeder Status, für den ein Gerät erforderlich ist, wartet mit der Ausführung, bis das Gerät verfügbar ist. Wenn mehrere Geräte verfügbar sind, führt dieser Status Testfälle aus mehreren Gruppen parallel aus. Wenn nicht genügend Geräte verfügbar sind, werden die Testfälle nacheinander ausgeführt. Da Testfälle in zufälliger Reihenfolge ausgeführt werden, wenn sie parallel ausgeführt werden, können verschiedene Geräte verwendet werden, um Tests derselben Testgruppe auszuführen.
**Fehlerbehandlung**
Stellen Sie sicher, dass sowohl die Zweigzustandsmaschine als auch die übergeordnete Zustandsmaschine in den `Fail` Status wechseln, um Ausführungsfehler zu beheben.
Da Branch-State-Maschinen keine Ausführungsfehler an den übergeordneten Zustandsmaschinen übertragen, können Sie einen `Catch` Block nicht verwenden, um Ausführungsfehler in Branch-State-Machines zu behandeln. Verwenden Sie den `hasExecutionErrors` Wert stattdessen im Kontext des Shared State Machines. Ein Beispiel dafür, wie das funktioniert, finden Sie unter[Beispiel State Machine: Zwei Testgruppen parallel ausführen](#run-in-parallel).
### AddProductFeatures
Mit `AddProductFeatures` diesem Status können Sie der von IDT generierten `awsiotdevicetester_report.xml` Datei Produktmerkmale hinzufügen.
Bei einer Produktfunktion handelt es sich um benutzerdefinierte Informationen über bestimmte Kriterien, die ein Gerät möglicherweise erfüllt. Beispielsweise kann die `MQTT` Produktfunktion angeben, dass das Gerät MQTT-Nachrichten ordnungsgemäß veröffentlicht. Im Bericht werden Produktfunktionen als, oder als benutzerdefinierter Wert festgelegt `supported``not-supported`, je nachdem, ob die angegebenen Tests bestanden wurden.
**Anmerkung**
Der `AddProductFeatures` Staat generiert selbst keine Berichte. Dieser Status muss in den [`Report`Status](#state-report) übergehen, in dem Berichte generiert werden können.
```
{
"Type": "Parallel",
"Next": "",
"Features": [
{
"Feature": "",
"Groups": [
""
],
"OneOfGroups": [
""
],
"TestCases": [
""
],
"IsRequired": true | false,
"ExecutionMethods": [
""
]
}
]
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`Next`
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
`Features`
Eine Reihe von Produktfunktionen, die in der `awsiotdevicetester_report.xml` Datei angezeigt werden sollen.
`Feature`
Der Name der Funktion
`FeatureValue`
Optional. Der benutzerdefinierte Wert, der anstelle von im Bericht verwendet werden soll`supported`. Wenn dieser Wert nicht angegeben ist, wird der Feature-Wert basierend auf den Testergebnissen auf `supported` oder gesetzt`not-supported`.
Wenn Sie einen benutzerdefinierten Wert für verwenden`FeatureValue`, können Sie dasselbe Feature mit unterschiedlichen Bedingungen testen, und IDT verkettet die Feature-Werte für die unterstützten Bedingungen. Der folgende Auszug zeigt beispielsweise das `MyFeature` Feature mit zwei separaten Feature-Werten:
```
...
{
"Feature": "MyFeature",
"FeatureValue": "first-feature-supported",
"Groups": ["first-feature-group"]
},
{
"Feature": "MyFeature",
"FeatureValue": "second-feature-supported",
"Groups": ["second-feature-group"]
},
...
```
Wenn beide Testgruppen erfolgreich sind, wird der Feature-Wert auf `first-feature-supported, second-feature-supported` gesetzt.
`Groups`
Optional. Ein Array von Testgruppen IDs. Alle Tests innerhalb jeder angegebenen Testgruppe müssen bestanden werden, damit die Funktion unterstützt wird.
`OneOfGroups`
Optional. Ein Array von Testgruppen IDs. Alle Tests innerhalb mindestens einer der angegebenen Testgruppen müssen bestanden werden, damit die Funktion unterstützt wird.
`TestCases`
Optional. Eine Reihe von Testfällen IDs. Wenn Sie diesen Wert angeben, gilt Folgendes:
+ Alle angegebenen Testfälle müssen bestanden werden, damit die Funktion unterstützt wird.
+ `Groups`darf nur eine Testgruppen-ID enthalten.
+ `OneOfGroups`darf nicht angegeben werden.
`IsRequired`
Optional. Stellen Sie auf ein`false`, um diese Funktion im Bericht als optionale Funktion zu kennzeichnen. Der Standardwert ist `true`.
`ExecutionMethods`
Optional. Eine Reihe von Ausführungsmethoden, die dem in der `device.json` Datei angegebenen `protocol` Wert entsprechen. Wenn dieser Wert angegeben ist, müssen Testläufer einen `protocol` Wert angeben, der einem der Werte in diesem Array entspricht, um das Feature in den Bericht aufzunehmen. Wenn dieser Wert nicht angegeben wird, wird das Feature immer in den Bericht aufgenommen.
Um den `AddProductFeatures` Status verwenden zu können, müssen Sie den Wert von `ResultVar` in the `RunTask` state auf einen der folgenden Werte festlegen:
+ Wenn Sie einen einzelnen Testfall angegeben haben IDs, legen Sie `ResultVar` den Wert auf fest`group-id_test-id_passed`.
+ Wenn Sie keinen individuellen Testfall angegeben haben IDs, legen Sie `ResultVar` den Wert auf fest`group-id_passed`.
Der `AddProductFeatures` Staat sucht auf folgende Weise nach Testergebnissen:
+ Wenn Sie keinen Testfall angegeben haben IDs, wird das Ergebnis für jede Testgruppe anhand des Werts der `group-id_passed` Variablen im State-Machine-Kontext bestimmt.
+ Wenn Sie einen Testfall angegeben haben IDs, wird das Ergebnis für jeden der Tests anhand des Werts der `group-id_test-id_passed` Variablen im Zustandsmaschinen-Kontext bestimmt.
**Fehlerbehandlung**
Wenn eine in diesem Status angegebene Gruppen-ID keine gültige Gruppen-ID ist, führt dieser Status zu einem `AddProductFeaturesError` Ausführungsfehler. Wenn im Status ein Ausführungsfehler auftritt, wird auch die `hasExecutionErrors` Variable im Zustandsmaschinenkontext auf gesetzt`true`.
### Bericht
Der `Report` Status generiert die `awsiotdevicetester_report.xml` Dateien `suite-name_Report.xml` und. In diesem Status wird der Bericht auch an die Konsole gestreamt.
```
{
"Type": "Report",
"Next": ""
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`Next`
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
Sie sollten immer gegen Ende der Testausführung in den `Report` Status wechseln, damit Testläufer die Testergebnisse einsehen können. In der Regel ist der nächste Status nach diesem Status`Succeed`.
**Fehlerbehandlung**
Wenn in diesem Status Probleme beim Generieren der Berichte auftreten, wird der `ReportError` Ausführungsfehler ausgegeben.
### LogMessage
Der `LogMessage` Status generiert die `test_manager.log` Datei und streamt die Protokollnachricht an die Konsole.
```
{
"Type": "LogMessage",
"Next": ""
"Level": "info | warn | error"
"Message": ""
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`Next`
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
`Level`
Die Fehlerstufe, auf der die Protokollnachricht erstellt werden soll. Wenn Sie eine ungültige Stufe angeben, generiert dieser Status eine Fehlermeldung und verwirft sie.
`Message`
Die zu protokollierende Nachricht.
### SelectGroup
Der `SelectGroup` Status aktualisiert den Kontext der Zustandsmaschine, um anzugeben, welche Gruppen ausgewählt wurden. Die in diesem Status festgelegten Werte werden von allen nachfolgenden `Choice` Staaten verwendet.
```
{
"Type": "SelectGroup",
"Next": ""
"TestGroups": [
"
]
}
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`Next`
Der Name des Status, zu dem nach der Ausführung der Aktionen im aktuellen Status übergegangen werden soll.
`TestGroups`
Eine Reihe von Testgruppen, die als ausgewählt markiert werden. Für jede Testgruppen-ID in diesem Array wird die `group-id_selected` Variable `true` im Kontext auf gesetzt. Stellen Sie sicher, dass Sie eine gültige Testgruppe angeben IDs , da IDT nicht überprüft, ob die angegebenen Gruppen existieren.
### Fehler
Der `Fail` Status weist darauf hin, dass die Zustandsmaschine nicht korrekt ausgeführt wurde. Dies ist ein Endzustand für die Zustandsmaschine, und jede Zustandsmaschine muss diesen Zustand enthalten.
```
{
"Type": "Fail"
}
```
### Succeed
Der `Succeed` Status gibt an, dass die Zustandsmaschine korrekt ausgeführt wurde. Dies ist ein Endzustand für die Zustandsmaschine, und jede Zustandsmaschine muss diesen Zustand enthalten.
```
{
"Type": "Succeed"
}
```
## Kontext der Zustandsmaschine
Der Zustandsmaschinenkontext ist ein schreibgeschütztes JSON-Dokument, das Daten enthält, die der Zustandsmaschine während der Ausführung zur Verfügung stehen. Der Zustandsmaschinen-Kontext ist nur von der Zustandsmaschine aus zugänglich und enthält Informationen, die den Testablauf bestimmen. Sie können beispielsweise Informationen verwenden, die von Testläufern in der `userdata.json` Datei konfiguriert wurden, um festzustellen, ob ein bestimmter Test ausgeführt werden muss.
Der State-Machine-Kontext verwendet das folgende Format:
```
{
"pool": {
},
"userData": {
},
"config": {
},
"suiteFailed": true | false,
"specificTestGroups": [
""
],
"specificTestCases": [
""
],
"hasExecutionErrors": true
}
```
`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.json` Datei.
`config`
Informationen an die `config.json` Datei anheften.
`suiteFailed`
Der Wert wird auf den `false` Zeitpunkt gesetzt, zu dem die Zustandsmaschine gestartet wird. Wenn eine Testgruppe in einem `RunTask` Status ausfällt, wird dieser Wert `true` für die verbleibende Dauer der State-Machine-Ausführung auf gesetzt.
`specificTestGroups`
Wenn der Testläufer anstelle der gesamten Testsuite bestimmte Testgruppen zur Ausführung auswählt, wird dieser Schlüssel erstellt und enthält die Liste der spezifischen Testgruppen IDs.
`specificTestCases`
Wenn der Testläufer anstelle der gesamten Testsuite bestimmte Testfälle zur Ausführung auswählt, wird dieser Schlüssel erstellt und enthält die Liste der spezifischen Testfälle IDs.
`hasExecutionErrors`
Wird nicht beendet, wenn die Zustandsmaschine gestartet wird. Wenn in einem Status ein Ausführungsfehler auftritt, wird diese Variable erstellt und `true` für die verbleibende Dauer der State-Machine-Ausführung auf „gesetzt“.
Sie können den Kontext mithilfe der JSONPath Notation abfragen. Die Syntax für JSONPath Abfragen in Statusdefinitionen lautet`{{$.query}}`. In einigen Bundesstaaten können Sie JSONPath Abfragen als Platzhalterzeichenfolgen verwenden. IDT ersetzt die Platzhalterzeichenfolgen durch den Wert der ausgewerteten JSONPath Abfrage aus dem Kontext. Sie können Platzhalter für die folgenden Werte verwenden:
+ Der `TestCases` Wert in `RunTask` Bundesstaaten.
+ Der `Expression` `Choice` Wertstatus.
Wenn Sie auf Daten aus dem State Machine-Kontext zugreifen, stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:
+ Ihre JSON-Pfade müssen beginnen mit `$.`
+ Jeder Wert muss eine Zeichenfolge, eine Zahl oder einen booleschen Wert ergeben.
Weitere Hinweise zur Verwendung der JSONPath Notation für den Zugriff auf Daten aus dem Kontext finden Sie unter. [Verwenden Sie den IDT-Kontext](idt-context.md)
## Ausführungsfehler
Ausführungsfehler sind Fehler in der Zustandsmaschinen-Definition, auf die der Zustandsmaschine bei der Ausführung eines Zustands stößt. IDT protokolliert Informationen zu jedem Fehler in der `test_manager.log` Datei und streamt die Protokollnachricht an die Konsole.
Sie können die folgenden Methoden verwenden, um Ausführungsfehler zu behandeln:
+ Fügen Sie der Statusdefinition einen [`Catch`Block](#catch) hinzu.
+ Überprüfen Sie den [`hasExecutionErrors`Wert des Werts](#context) im Kontext der Zustandsmaschine.
### Fangen
Um es zu verwenden`Catch`, fügen Sie Ihrer Bundesstaatendefinition Folgendes hinzu:
```
"Catch": [
{
"ErrorEquals": [
""
]
"Next": ""
}
]
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`Catch.ErrorEquals`
Eine Reihe von Fehlertypen, die abgefangen werden sollen. Wenn ein Ausführungsfehler mit einem der angegebenen Werte übereinstimmt, wechselt die Zustandsmaschine in den unter angegebenen Status`Catch.Next`. In den einzelnen Statusdefinitionen finden Sie Informationen zur Art des Fehlers, den sie erzeugt.
`Catch.Next`
Der nächste Status, in den übergegangen werden soll, wenn im aktuellen Status ein Ausführungsfehler auftritt, der einem der in angegebenen Werte entspricht`Catch.ErrorEquals`.
Catch-Blöcke werden sequentiell behandelt, bis einer übereinstimmt. Wenn der Wert „Keine Fehler“ mit den in den Catch-Blöcken aufgelisteten Fehlern übereinstimmt, wird die Ausführung der Zustandsmaschinen fortgesetzt. Da Ausführungsfehler auf falsche Statusdefinitionen zurückzuführen sind, empfehlen wir, dass Sie in den Status Fail wechseln, wenn in einem Status ein Ausführungsfehler auftritt.
### hasExecutionError
Wenn in einigen Staaten Ausführungsfehler auftreten, geben sie nicht nur den Fehler aus, sondern setzen den `hasExecutionError` Wert auch `true` im Kontext der Zustandsmaschine auf. Sie können diesen Wert verwenden, um zu erkennen, wann ein Fehler auftritt, und dann einen `Choice` Status verwenden, um die Zustandsmaschine in den `Fail` Status zu versetzen.
Diese Methode hat die folgenden Eigenschaften.
+ Die Zustandsmaschine beginnt mit keinem Wert, der zugewiesen wurde`hasExecutionError`, und dieser Wert ist erst verfügbar, wenn ein bestimmter Status ihn festlegt. Das bedeutet, dass Sie den Status `false` für die `Choice` Staaten, die `FallthroughOnError` auf diesen Wert zugreifen, explizit auf setzen müssen, um zu verhindern, dass der Zustandsmaschine angehalten wird, wenn keine Ausführungsfehler auftreten.
+ Sobald der Wert auf gesetzt ist`true`, `hasExecutionError` wird er niemals auf False gesetzt oder aus dem Kontext entfernt. Das bedeutet, dass dieser Wert nur nützlich ist, wenn er zum ersten Mal auf gesetzt wird`true`, und für alle nachfolgenden Zustände bietet er keinen aussagekräftigen Wert.
+ Der `hasExecutionError` Wert wird von allen Zweigstatusmaschinen im `Parallel` Bundesstaat gemeinsam genutzt, was je nach Reihenfolge, in der auf ihn zugegriffen wird, zu unerwarteten Ergebnissen führen kann.
Aufgrund dieser Eigenschaften empfehlen wir nicht, diese Methode zu verwenden, wenn Sie stattdessen einen Catch-Block verwenden können.
## Beispiel für Zustandsmaschinen
Dieser Abschnitt enthält einige Beispielkonfigurationen von Zustandsmaschinen.
**Topics**
+ [Beispiel für eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe aus](#single-test-group)
+ [Beispiel für eine Zustandsmaschine: Führen Sie vom Benutzer ausgewählte Testgruppen aus](#allow-specific-groups)
+ [Beispiel für eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe mit Produktfunktionen aus](#run-with-product-features)
+ [Beispiel State Machine: Zwei Testgruppen parallel ausführen](#run-in-parallel)
### Beispiel für eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe aus
Dieser Zustandsmaschine:
+ Führt die Testgruppe mit der ID aus`GroupA`, die in der Suite in einer `group.json` Datei vorhanden sein muss.
+ Prüft auf Ausführungsfehler und wechselt zu, `Fail` ob welche gefunden wurden.
+ Generiert einen Bericht und wechselt zu, `Succeed` ob keine Fehler vorliegen, und `Fail` andernfalls.
```
{
"Comment": "Runs a single group and then generates a report.",
"StartAt": "RunGroupA",
"States": {
"RunGroupA": {
"Type": "RunTask",
"Next": "Report",
"TestGroup": "GroupA",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"Report": {
"Type": "Report",
"Next": "Succeed",
"Catch": [
{
"ErrorEquals": [
"ReportError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
### Beispiel für eine Zustandsmaschine: Führen Sie vom Benutzer ausgewählte Testgruppen aus
Dieser Zustandsmaschine:
+ Prüft, ob der Testläufer bestimmte Testgruppen ausgewählt hat. Die Zustandsmaschine sucht nicht nach bestimmten Testfällen, da Testläufer keine Testfälle auswählen können, ohne auch eine Testgruppe auszuwählen.
+ Wenn Testgruppen ausgewählt sind:
+ Führt die Testfälle innerhalb der ausgewählten Testgruppen aus. Zu diesem Zweck spezifiziert die Zustandsmaschine nicht explizit Testgruppen oder Testfälle im `RunTask` Status.
+ Generiert einen Bericht, nachdem alle Tests ausgeführt und beendet wurden.
+ Wenn keine Testgruppen ausgewählt sind:
+ Führt Tests in einer Testgruppe aus`GroupA`.
+ Generiert Berichte und beendet das Programm.
```
{
"Comment": "Runs specific groups if the test runner chose to do that, otherwise runs GroupA.",
"StartAt": "SpecificGroupsCheck",
"States": {
"SpecificGroupsCheck": {
"Type": "Choice",
"Default": "RunGroupA",
"FallthroughOnError": true,
"Choices": [
{
"Expression": "{{$.specificTestGroups[0]}} != ''",
"Next": "RunSpecificGroups"
}
]
},
"RunSpecificGroups": {
"Type": "RunTask",
"Next": "Report",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"RunGroupA": {
"Type": "RunTask",
"Next": "Report",
"TestGroup": "GroupA",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"Report": {
"Type": "Report",
"Next": "Succeed",
"Catch": [
{
"ErrorEquals": [
"ReportError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
### Beispiel für eine Zustandsmaschine: Führen Sie eine einzelne Testgruppe mit Produktfunktionen aus
Dieser Zustandsmaschine:
+ Führt die Testgruppe aus`GroupA`.
+ Prüft auf Ausführungsfehler und wechselt, `Fail` ob welche gefunden wurden.
+ Fügt der `awsiotdevicetester_report.xml` Datei das `FeatureThatDependsOnGroupA` Feature hinzu:
+ Wenn der `GroupA` Wert erfolgreich ist, wird das Feature auf gesetzt`supported`.
+ Die Funktion ist im Bericht nicht als optional gekennzeichnet.
+ Generiert einen Bericht und wechselt zu, `Succeed` wenn keine Fehler vorliegen, und `Fail` andernfalls
```
{
"Comment": "Runs GroupA and adds product features based on GroupA",
"StartAt": "RunGroupA",
"States": {
"RunGroupA": {
"Type": "RunTask",
"Next": "AddProductFeatures",
"TestGroup": "GroupA",
"ResultVar": "GroupA_passed",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"AddProductFeatures": {
"Type": "AddProductFeatures",
"Next": "Report",
"Features": [
{
"Feature": "FeatureThatDependsOnGroupA",
"Groups": [
"GroupA"
],
"IsRequired": true
}
]
},
"Report": {
"Type": "Report",
"Next": "Succeed",
"Catch": [
{
"ErrorEquals": [
"ReportError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
### Beispiel State Machine: Zwei Testgruppen parallel ausführen
Diese Zustandsmaschine:
+ Führt die Gruppen `GroupA` und die `GroupB` Testgruppen parallel aus. Die `ResultVar` Variablen, die im Kontext der `RunTask` Bundesstaaten gespeichert sind, stehen dem `AddProductFeatures` Staat zur Verfügung.
+ Prüft auf Ausführungsfehler und wechselt, `Fail` falls welche gefunden wurden. Diese Zustandsmaschine verwendet keinen `Catch` Block, da diese Methode keine Ausführungsfehler in Zweigzustandsmaschinen erkennt.
+ Fügt der `awsiotdevicetester_report.xml` Datei Funktionen hinzu, die auf den Gruppen basieren, die erfolgreich sind
+ Bei `GroupA` erfolgreicher Prüfung wird das Feature auf gesetzt`supported`.
+ Die Funktion ist im Bericht nicht als optional gekennzeichnet.
+ Generiert einen Bericht und wechselt zu, `Succeed` wenn keine Fehler vorliegen, und `Fail` andernfalls
Wenn zwei Geräte im Gerätepool konfiguriert sind, `GroupB` können beide `GroupA` Geräte gleichzeitig ausgeführt werden. Wenn jedoch einer `GroupA` oder `GroupB` mehrere Tests enthalten sind, können beide Geräte diesen Tests zugewiesen werden. Wenn nur ein Gerät konfiguriert ist, werden die Testgruppen nacheinander ausgeführt.
```
{
"Comment": "Runs GroupA and GroupB in parallel",
"StartAt": "RunGroupAAndB",
"States": {
"RunGroupAAndB": {
"Type": "Parallel",
"Next": "CheckForErrors",
"Branches": [
{
"Comment": "Run GroupA state machine",
"StartAt": "RunGroupA",
"States": {
"RunGroupA": {
"Type": "RunTask",
"Next": "Succeed",
"TestGroup": "GroupA",
"ResultVar": "GroupA_passed",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
},
{
"Comment": "Run GroupB state machine",
"StartAt": "RunGroupB",
"States": {
"RunGroupA": {
"Type": "RunTask",
"Next": "Succeed",
"TestGroup": "GroupB",
"ResultVar": "GroupB_passed",
"Catch": [
{
"ErrorEquals": [
"RunTaskError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
]
},
"CheckForErrors": {
"Type": "Choice",
"Default": "AddProductFeatures",
"FallthroughOnError": true,
"Choices": [
{
"Expression": "{{$.hasExecutionErrors}} == true",
"Next": "Fail"
}
]
},
"AddProductFeatures": {
"Type": "AddProductFeatures",
"Next": "Report",
"Features": [
{
"Feature": "FeatureThatDependsOnGroupA",
"Groups": [
"GroupA"
],
"IsRequired": true
},
{
"Feature": "FeatureThatDependsOnGroupB",
"Groups": [
"GroupB"
],
"IsRequired": true
}
]
},
"Report": {
"Type": "Report",
"Next": "Succeed",
"Catch": [
{
"ErrorEquals": [
"ReportError"
],
"Next": "Fail"
}
]
},
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
# Ausführbare IDT-Testfalldateien erstellen
Sie können ausführbare Testfalldateien 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, 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 dem 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 Folgendes: SDKs
+ IDT-Client-SDK für Python
+ IDT Client SDK for Go
+ IDT Client SDK for Java
Diese SDKs befinden sich im `/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.
**Topics**
+ [Geräteinteraktion](#api-device-interaction)
+ [IDT-Interaktion](#api-idt-interaction)
+ [Interaktion mit dem Host](#api-host-interaction)
### 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 unter[Verwenden Sie den IDT-Kontext](idt-context.md).
### 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](idt-context.md).
`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](idt-context.md).
`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. Um es Testläufern zu ermöglichen, diese Optionen zum Ausführen Ihrer benutzerdefinierten Testsuite zu verwenden, 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\$1TEST\$1TIMEOUT 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\$1TEST\$1TIMEOUT, 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](#test-exec-exiting)
`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](#test-exec-exiting)
`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 der Test-Orchestrator für Ihre Testsuite einen bestimmten Satz von `RunTask` `Choice` Endstatus in Ihrem Test-Orchestrator enthalten. Wenn Sie keine benutzerdefinierte Zustandsmaschine verwenden, enthält der standardmäßige IDT-Testorchestrator die erforderlichen Status für Sie, und Sie müssen keine zusätzlichen Maßnahmen ergreifen. Wenn Sie jedoch einen benutzerdefinierten Test-Orchestrator verwenden, verwenden Sie ihn [Beispiel für eine Zustandsmaschine: Führen Sie vom Benutzer ausgewählte Testgruppen aus](idt-state-machine.md#allow-specific-groups) als Beispiel, um die erforderlichen Status in Ihrem Test-Orchestrator hinzuzufügen.
Weitere Informationen zu IDT-CLI-Befehlen finden Sie unter[Debuggen und Ausführen benutzerdefinierter Testsuiten](run-debug-custom-tests.md).
## 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 unter[Nachrichtenformat der Konsole](idt-review-results-logs.md#idt-console-format).
Wenn das IDT die Ausführung der Testsuite beendet hat, sind diese Informationen auch in der `test_manager.log` Datei im `/results//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 `_` Datei im `/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 `/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`/results//`. 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](idt-review-results-logs.md)
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 liefert, 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\$1TEST\$1TIMEOUT, um dieses Ereignis zu erkennen. Wenn ein Testläufer einen Test startet, setzt IDT den Wert der Umgebungsvariablen IDT\$1TEST\$1TIMEOUT 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\$1C
Da Terminals Signale an alle untergeordneten Prozesse weiterleiten, können Sie in Ihren Testfällen einfach einen Signal-Handler konfigurieren, um Interrupt-Signale zu erkennen.
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.
1. Bereinigen Sie alle temporären Ressourcen, z. B. Testartefakte, auf dem zu testenden Gerät.
1. Melden Sie IDT ein Testergebnis, z. B. einen Testfehler oder einen Fehler.
1. Beenden.
# Verwenden Sie den IDT-Kontext
Wenn IDT eine Testsuite ausführt, kann die Testsuite auf einen Datensatz zugreifen, anhand dessen bestimmt werden kann, wie die einzelnen Tests ausgeführt werden. Diese Daten werden als IDT-Kontext bezeichnet. Beispielsweise wird die Benutzerdatenkonfiguration, die von Testläufern in einer `userdata.json` Datei bereitgestellt wird, Testsuiten im IDT-Kontext zur Verfügung gestellt.
Der IDT-Kontext kann als schreibgeschütztes JSON-Dokument betrachtet werden. Testsuiten können mithilfe von Standard-JSON-Datentypen wie Objekten, Arrays, Zahlen usw. Daten aus dem Kontext abrufen und Daten in den Kontext schreiben.
## Kontextschema
Der IDT-Kontext verwendet das folgende Format:
```
{
"config": {
"timeoutMultiplier": timeout-multiplier
},
"device": {
},
"devicePool": {
},
"resource": {
"devices": [
{
"name": ""
}
]
},
"testData": {
"awsCredentials": {
"awsAccessKeyId": "",
"awsSecretAccessKey": "",
"awsSessionToken": ""
},
"logFilePath": "/path/to/log/file"
},
"userData": {
}
}
```
`config`
Informationen aus der [`config.json`Datei](set-custom-idt-config.md#config-json-custom). Das `config` Feld enthält außerdem das folgende zusätzliche Feld:
`config.timeoutMultiplier`
Der Multiplikator für jeden Timeout-Wert, der von der Testsuite verwendet wird. Dieser Wert wird vom Test-Runner über die IDT-CLI angegeben. Der Standardwert ist `1`.
`device`
Informationen über das Gerät, das für den Testlauf ausgewählt wurde. Diese Information entspricht dem `devices` Array-Element in der [`device.json`Datei](set-custom-idt-config.md#device-config-custom) für das ausgewählte Gerät.
`devicePool`
Informationen über den Gerätepool, der für den Testlauf ausgewählt wurde. Diese Informationen entsprechen dem Element des Gerätepool-Arrays der obersten Ebene, das in der `device.json` Datei für den ausgewählten Gerätepool definiert ist.
`resource`
Informationen zu Ressourcengeräten aus der `resource.json` Datei.
`resource.devices`
Diese Informationen entsprechen dem in der `resource.json` Datei definierten `devices` Array. Jedes `devices` Element enthält das folgende zusätzliche Feld:
`resource.device.name`
Der Name des Ressourcengeräts. Dieser Wert ist auf den `requiredResource.name` Wert in der `test.json` Datei festgelegt.
`testData.awsCredentials`
Die AWS Anmeldeinformationen, die vom Test für die Verbindung mit der AWS Cloud verwendet wurden. Diese Informationen werden aus der `config.json` Datei abgerufen.
`testData.logFilePath`
Der Pfad zur Protokolldatei, in die der Testfall Protokollnachrichten schreibt. Die Testsuite erstellt diese Datei, falls sie nicht existiert.
`userData`
Informationen, die vom Testrunner in der [`userdata.json`Datei](set-custom-idt-config.md#userdata-config-custom) bereitgestellt wurden.
## Greifen Sie auf Daten im Kontext zu
Sie können den Kontext mithilfe der JSONPath Notation aus Ihren JSON-Dateien und aus Ihrer ausführbaren Textdatei mit dem `GetContextValue` und abfragen `GetContextString` APIs. Die Syntax für JSONPath Zeichenketten für den Zugriff auf den IDT-Kontext variiert wie folgt:
+ In `suite.json` und `test.json` verwenden `{{query}}` Sie. Das heißt, verwenden Sie nicht das Stammelement`$.`, um Ihren Ausdruck zu starten.
+ In`test_orchestrator.yaml`, du benutzt`{{query}}`.
Wenn Sie die veraltete Zustandsmaschine verwenden, dann verwenden Sie. `state_machine.json` `{{$.query}}`
+ In API-Befehlen verwenden Sie je nach Befehl `query` oder`{{$.query}}`. Weitere Informationen finden Sie in der Inline-Dokumentation im SDKs.
In der folgenden Tabelle werden die Operatoren in einem typischen JSONPath Ausdruck beschrieben:
| Operator | Beschreibung |
| --- |--- |
| \$1 | Das Stammelement. Da es sich bei dem Kontextwert der obersten Ebene für IDT um ein Objekt handelt, verwenden Sie ihn in der Regel, um Ihre \$1. Abfragen zu starten. |
| .childName | Greift auf das untergeordnete Element mit dem Namen eines Objekts childName zu. Wenn es auf ein Array angewendet wird, ergibt dies ein neues Array, bei dem dieser Operator auf jedes Element angewendet wird. Beim Elementnamen wird zwischen Groß- und Kleinschreibung unterschieden. Die Abfrage für den Zugriff auf den awsRegion Wert im config Objekt lautet beispielsweise\$1.config.awsRegion. |
| [start:end] | Filtert Elemente aus einem Array und ruft Elemente ab, die mit dem start Index beginnen und bis zum end Index aufsteigen, jeweils inklusive. |
| [index1, index2, ... , indexN] | Filtert Elemente aus einem Array und ruft nur Elemente aus den angegebenen Indizes ab. |
| [?(expr)] | Filtert Elemente aus einem Array mithilfe des expr Ausdrucks. Dieser Ausdruck muss einen booleschen Wert ergeben. |
Verwenden Sie die folgende Syntax, um Filterausdrücke zu erstellen:
```
| operator |
```
In dieser Syntax gilt:
+ `jsonpath`ist ein JSONPath , das die Standard-JSON-Syntax verwendet.
+ `value`ist ein beliebiger benutzerdefinierter Wert, der die Standard-JSON-Syntax verwendet.
+ `operator`ist einer der folgenden Operatoren:
+ `<`(Weniger als)
+ `<=`(Weniger als oder gleich)
+ `==`(Gleich)
Wenn der Wert JSONPath oder in Ihrem Ausdruck ein Array, ein boolescher Wert oder ein Objektwert ist, dann ist dies der einzige unterstützte binäre Operator, den Sie verwenden können.
+ `>=`(Größer als oder gleich)
+ `>`(Größer als)
+ `=~`(Übereinstimmung mit regulären Ausdrücken). Um diesen Operator in einem Filterausdruck zu verwenden, muss der Wert JSONPath oder auf der linken Seite des Ausdrucks eine Zeichenfolge ergeben, und auf der rechten Seite muss es sich um einen Musterwert handeln, der der [RE2Syntax](https://github.com/google/re2/wiki/Syntax) folgt.
Sie können JSONPath Abfragen in der Form \$1\$1*query*\$1\$1 als Platzhalterzeichenfolgen innerhalb der `environmentVariables` Felder `args` und in `test.json` Dateien und innerhalb der `environmentVariables` Felder in `suite.json` Dateien verwenden. IDT führt eine Kontextsuche durch und füllt die Felder mit dem ausgewerteten Wert der Abfrage auf. In der `suite.json` Datei können Sie beispielsweise Platzhalterzeichenfolgen verwenden, um Umgebungsvariablenwerte anzugeben, die sich mit jedem Testfall ändern, und IDT füllt die Umgebungsvariablen mit dem richtigen Wert für jeden Testfall. Wenn Sie jedoch Platzhalterzeichenfolgen in `test.json` und `suite.json` -Dateien verwenden, gelten für Ihre Abfragen die folgenden Überlegungen:
+ Sie müssen jedes Vorkommen des `devicePool` Schlüssels in Ihrer Abfrage in Kleinbuchstaben angeben. Das heißt, verwenden Sie `devicepool` stattdessen.
+ Für Arrays können Sie nur Zeichenketten-Arrays verwenden. Darüber hinaus verwenden Arrays ein nicht standardmäßiges Format. `item1, item2,...,itemN` Wenn das Array nur ein Element enthält, wird es als serialisiert`item`, sodass es nicht von einem Zeichenkettenfeld zu unterscheiden ist.
+ Sie können keine Platzhalter verwenden, um Objekte aus dem Kontext abzurufen.
Aus diesen Gründen empfehlen wir, wann immer möglich, die API für den Zugriff auf den Kontext in Ihrer Testlogik anstelle von Platzhalterzeichenfolgen in `test.json` und `suite.json` -Dateien zu verwenden. In einigen Fällen kann es jedoch praktischer sein, JSONPath Platzhalter zu verwenden, um einzelne Zeichenketten abzurufen, die als Umgebungsvariablen festgelegt werden sollen.
# Einstellungen für Testläufer konfigurieren
Um benutzerdefinierte Testsuiten auszuführen, müssen Testläufer ihre Einstellungen auf der Grundlage der Testsuite konfigurieren, die sie ausführen möchten. Die Einstellungen werden auf der Grundlage von Vorlagen für Konfigurationsdateien angegeben, die sich im `/configs/` Ordner befinden. Falls erforderlich, müssen Testläufer auch AWS Anmeldeinformationen einrichten, die IDT für die Verbindung mit der AWS Cloud verwendet.
Als Testautor müssen Sie diese Dateien konfigurieren, um [Ihre Testsuite zu debuggen](run-debug-custom-tests.md). Sie müssen den Testläufern Anweisungen geben, damit sie die folgenden Einstellungen nach Bedarf für die Ausführung Ihrer Testsuiten konfigurieren können.
## Konfigurieren von device.json
Die `device.json` Datei enthält Informationen über die Geräte, auf denen die Tests ausgeführt werden (z. B. IP-Adresse, Anmeldeinformationen, Betriebssystem und CPU-Architektur).
Testläufer können diese Informationen mithilfe der folgenden `device.json` Vorlagendatei bereitstellen, die sich im `/configs/` Ordner befindet.
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "",
"value": "",
"configs": [
{
"name": "",
"value": ""
}
],
}
],
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh | uart | docker",
// ssh
"ip": "",
"port": ,
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
// pki
"privKeyPath": "/path/to/private/key",
// password
"password": "",
}
},
// uart
"serialPort": "",
// docker
"containerId": "",
"containerUser": "",
}
}
]
}
]
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`id`
Eine benutzerdefinierte alphanumerische ID, die eine Sammlung von Geräten, den sogenannten *Gerätepool*, eindeutig identifiziert. Geräte, die zu einem Pool gehören, müssen über identische Hardware verfügen. Bei der Ausführung einer Reihe von Tests werden Geräte im Pool verwendet, um die Workload zu parallelisieren. Mehrere Geräte werden verwendet, um verschiedene Tests auszuführen.
`sku`
Ein alphanumerischer Wert, durch den das zu testende Gerät eindeutig identifiziert wird. Die SKU wird verwendet, um qualifizierte Geräte nachzuverfolgen.
Wenn du dein Motherboard im AWS Partner Gerätekatalog auflisten möchtest, muss die hier angegebene SKU mit der SKU übereinstimmen, die du bei der Angebotserstellung verwendest.
`features`
Optional. Ein Array, das die Funktionen enthält, die das Gerät unterstützt. Gerätefunktionen sind benutzerdefinierte Werte, die Sie in Ihrer Testsuite konfigurieren. Sie müssen Ihren Testläufern Informationen über die Namen und Werte der Funktionen zur Verfügung stellen, die in die `device.json` Datei aufgenommen werden sollen. Wenn Sie beispielsweise ein Gerät testen möchten, das als MQTT-Server für andere Geräte fungiert, können Sie Ihre Testlogik so konfigurieren, dass bestimmte unterstützte Stufen für ein Feature mit dem Namen `MQTT_QOS` validiert werden. Testläufer geben diesen Feature-Namen an und setzen den Feature-Wert auf die QOS-Stufen, die von ihrem Gerät unterstützt werden. Sie können die bereitgestellten Informationen aus dem [IDT-Kontext](idt-context.md) mit der `devicePool.features` Abfrage oder aus dem [Test-Orchestrator-Kontext](idt-state-machine.md#state-machine-context) mit der Abfrage abrufen. `pool.features`
`features.name`
Der Name der Funktion.
`features.value`
Die unterstützten Feature-Werte.
`features.configs`
Konfigurationseinstellungen für die Funktion, falls erforderlich.
`features.config.name`
Der Name der Konfigurationseinstellung.
`features.config.value`
Die unterstützten Einstellungswerte.
`devices`
Eine Reihe von Geräten im Pool, die getestet werden sollen. Es ist mindestens ein Gerät erforderlich.
`devices.id`
Eine benutzerdefinierte eindeutige Kennung für das zu testende Gerät.
`connectivity.protocol`
Das Kommunikationsprotokoll, das für die Kommunikation mit diesem Gerät verwendet wird. Jedes Gerät in einem Pool muss dasselbe Protokoll verwenden.
Derzeit werden nur Werte `uart` für physische Geräte `ssh` und `docker` für Docker-Container unterstützt.
`connectivity.ip`
Die IP-Adresse des zu testenden Geräts.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.port`
Optional. Die Portnummer, die für SSH-Verbindungen verwendet werden soll.
Der Standardwert ist 22.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.auth`
Authentifizierungsinformationen für die Verbindung.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.auth.method`
Die Authentifizierungsmethode, die für den Zugriff über ein bestimmtes Verbindungsprotokoll auf ein Gerät verwendet wird.
Unterstützte Werte sind:
+ `pki`
+ `password`
`connectivity.auth.credentials`
Die für die Authentifizierung verwendeten Anmeldeinformationen.
`connectivity.auth.credentials.password`
Das Passwort für die Anmeldung am Gerät wird überprüft.
Dieser Wert gilt nur, wenn `connectivity.auth.method` auf `password` festgelegt ist.
`connectivity.auth.credentials.privKeyPath`
Der vollständige Pfad zum privaten Schlüssel, der für die Anmeldung bei dem zu testenden Gerät verwendet wird.
Dieser Wert gilt nur, wenn `connectivity.auth.method` auf `pki` festgelegt ist.
`connectivity.auth.credentials.user`
Der Benutzername für die Anmeldung bei dem zu testenden Gerät.
`connectivity.serialPort`
Optional. Die serielle Schnittstelle, an die das Gerät angeschlossen ist.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `uart` festgelegt ist.
`connectivity.containerId`
Die Container-ID oder der Name des getesteten Docker-Containers.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.containerUser`
Optional. Der Name des Benutzers gegenüber dem Benutzer innerhalb des Containers. Der Standardwert ist der im Dockerfile angegebene Benutzer.
Der Standardwert ist 22.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
Um zu überprüfen, ob Testläufer die falsche Geräteverbindung für einen Test konfigurieren, können Sie den Test `pool.Devices[0].Connectivity.Protocol` aus dem Orchestrator-Kontext abrufen und ihn mit dem erwarteten Wert in einem `Choice` Status vergleichen. Wenn ein falsches Protokoll verwendet wird, drucken Sie eine Nachricht mit dem `LogMessage` Status und wechseln Sie zum `Fail` Status.
Alternativ können Sie den Fehlerbehandlungscode verwenden, um einen Testfehler für falsche Gerätetypen zu melden.
## (Optional) Konfigurieren Sie userdata.json
Die `userdata.json` Datei enthält alle zusätzlichen Informationen, die für eine Testsuite erforderlich sind, aber nicht in der Datei angegeben sind. `device.json` Das Format dieser Datei hängt von der [`userdata_scheme.json`Datei](idt-json-config.md#userdata-schema-json) ab, die in der Testsuite definiert ist. Wenn Sie ein Testautor sind, stellen Sie sicher, dass Sie diese Informationen Benutzern zur Verfügung stellen, die die von Ihnen geschriebenen Testsuiten ausführen.
## (Optional) Konfigurieren Sie resource.json
Die `resource.json` Datei enthält Informationen zu allen Geräten, die als Ressourcengeräte verwendet werden. Ressourcengeräte sind Geräte, die zum Testen bestimmter Funktionen eines zu testenden Geräts erforderlich sind. Um beispielsweise die Bluetooth-Fähigkeit eines Geräts zu testen, können Sie ein Ressourcengerät verwenden, um zu testen, ob Ihr Gerät erfolgreich eine Verbindung zu dem Gerät herstellen kann. Ressourcengeräte sind optional, und Sie können so viele Ressourcengeräte benötigen, wie Sie benötigen. Als Testautor verwenden Sie die [Datei test.json](idt-json-config.md#test-json), um die Funktionen der Ressourcengeräte zu definieren, die für einen Test erforderlich sind. Testläufer verwenden dann die `resource.json` Datei, um einen Pool von Ressourcengeräten bereitzustellen, die über die erforderlichen Funktionen verfügen. Stellen Sie sicher, dass Sie diese Informationen Benutzern zur Verfügung stellen, die die von Ihnen geschriebenen Testsuiten ausführen werden.
Testläufer können diese Informationen mithilfe der folgenden `resource.json` Vorlagendatei bereitstellen, die sich im `/configs/` Ordner befindet.
```
[
{
"id": "",
"features": [
{
"name": "",
"version": "",
"jobSlots":
}
],
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh | uart | docker",
// ssh
"ip": "",
"port": ,
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
// pki
"privKeyPath": "/path/to/private/key",
// password
"password": "",
}
},
// uart
"serialPort": "",
// docker
"containerId": "",
"containerUser": "",
}
}
]
}
]
```
Nachfolgend sind alle Pflichtfelder beschrieben:
`id`
Eine benutzerdefinierte alphanumerische ID, die eine Sammlung von Geräten, den sogenannten *Gerätepool*, eindeutig identifiziert. Geräte, die zu einem Pool gehören, müssen über identische Hardware verfügen. Bei der Ausführung einer Reihe von Tests werden Geräte im Pool verwendet, um die Workload zu parallelisieren. Mehrere Geräte werden verwendet, um verschiedene Tests auszuführen.
`features`
Optional. Ein Array, das die Funktionen enthält, die das Gerät unterstützt. Die in diesem Feld erforderlichen Informationen sind in den [test.json-Dateien](idt-json-config.md#test-json) in der Testsuite definiert und bestimmen, welche Tests ausgeführt werden und wie diese Tests ausgeführt werden. Wenn die Testsuite keine Funktionen benötigt, ist dieses Feld nicht erforderlich.
`features.name`
Der Name der Funktion.
`features.version`
Die Feature-Version.
`features.jobSlots`
Einstellung, die angibt, wie viele Tests das Gerät gleichzeitig verwenden können. Der Standardwert ist `1`.
`devices`
Eine Reihe von Geräten im Pool, die getestet werden sollen. Es ist mindestens ein Gerät erforderlich.
`devices.id`
Eine benutzerdefinierte eindeutige Kennung für das zu testende Gerät.
`connectivity.protocol`
Das Kommunikationsprotokoll, das für die Kommunikation mit diesem Gerät verwendet wird. Jedes Gerät in einem Pool muss dasselbe Protokoll verwenden.
Derzeit werden nur Werte `uart` für physische Geräte `ssh` und `docker` für Docker-Container unterstützt.
`connectivity.ip`
Die IP-Adresse des zu testenden Geräts.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.port`
Optional. Die Portnummer, die für SSH-Verbindungen verwendet werden soll.
Der Standardwert ist 22.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.auth`
Authentifizierungsinformationen für die Verbindung.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.auth.method`
Die Authentifizierungsmethode, die für den Zugriff über ein bestimmtes Verbindungsprotokoll auf ein Gerät verwendet wird.
Unterstützte Werte sind:
+ `pki`
+ `password`
`connectivity.auth.credentials`
Die für die Authentifizierung verwendeten Anmeldeinformationen.
`connectivity.auth.credentials.password`
Das Passwort für die Anmeldung am Gerät wird überprüft.
Dieser Wert gilt nur, wenn `connectivity.auth.method` auf `password` festgelegt ist.
`connectivity.auth.credentials.privKeyPath`
Der vollständige Pfad zum privaten Schlüssel, der für die Anmeldung bei dem zu testenden Gerät verwendet wird.
Dieser Wert gilt nur, wenn `connectivity.auth.method` auf `pki` festgelegt ist.
`connectivity.auth.credentials.user`
Der Benutzername für die Anmeldung bei dem zu testenden Gerät.
`connectivity.serialPort`
Optional. Die serielle Schnittstelle, an die das Gerät angeschlossen ist.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `uart` festgelegt ist.
`connectivity.containerId`
Die Container-ID oder der Name des getesteten Docker-Containers.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
`connectivity.containerUser`
Optional. Der Name des Benutzers gegenüber dem Benutzer innerhalb des Containers. Der Standardwert ist der im Dockerfile angegebene Benutzer.
Der Standardwert ist 22.
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
## (Optional) Konfigurieren Sie config.json
Die `config.json` Datei enthält Konfigurationsinformationen für IDT. In der Regel müssen Testläufer diese Datei nicht ändern, es sei denn, sie müssen ihre AWS Benutzeranmeldeinformationen für IDT und optional eine AWS Region angeben. Wenn AWS Anmeldeinformationen mit den erforderlichen Berechtigungen bereitgestellt werden, werden Nutzungsmetriken AWS IoT Device Tester erfasst und an diese gesendet. AWS Dies ist eine Opt-in-Funktion, die zur Verbesserung der IDT-Funktionalität verwendet wird. Weitere Informationen finden Sie unter [IDT-Nutzungsmetriken](idt-usage-metrics.md).
Testläufer können ihre AWS Anmeldeinformationen auf eine der folgenden Arten konfigurieren:
+ **Anmeldeinformationsdatei**
IDT verwendet die gleiche Anmeldeinformationsdatei wie das AWS CLI. Weitere Informationen finden Sie unter [Konfigurations- und Anmeldeinformationsdateien](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html).
Der Speicherort der Datei mit den Anmeldeinformationen variiert je nach verwendetem Betriebssystem:
+ macOS Linux: `~/.aws/credentials`
+ Windows: `C:\Users\UserName\.aws\credentials`
+ **Umgebungsvariablen**
Umgebungsvariablen sind Variablen, die vom Betriebssystem gepflegt und von Systembefehlen verwendet werden. Variablen, die während einer SSH-Sitzung definiert wurden, sind nach dem Schließen dieser Sitzung nicht verfügbar. IDT kann die `AWS_SECRET_ACCESS_KEY` Umgebungsvariablen `AWS_ACCESS_KEY_ID` und zum Speichern von Anmeldeinformationen verwenden AWS
Um diese Variablen auf Linux, macOS oder Unix festzulegen, verwenden Sie **export**:
```
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
```
In Windows können Sie die Variablen mit **set** festlegen:
```
set AWS_ACCESS_KEY_ID=
set AWS_SECRET_ACCESS_KEY=
```
Um AWS Anmeldeinformationen für IDT zu konfigurieren, bearbeiten Testläufer den `auth` Abschnitt in der `config.json` Datei, die sich im `/configs/` Ordner befindet.
```
{
"log": {
"location": "logs"
},
"configFiles": {
"root": "configs",
"device": "configs/device.json"
},
"testPath": "tests",
"reportPath": "results",
"awsRegion": "",
"auth": {
"method": "file | environment",
"credentials": {
"profile": ""
}
}
}
]
```
Nachfolgend sind alle Pflichtfelder beschrieben:
**Anmerkung**
Alle Pfade in dieser Datei sind relativ zu definiert. **
`log.location`
Der Pfad zum Protokollordner in der**.
`configFiles.root`
Der Pfad zu dem Ordner, der die Konfigurationsdateien enthält.
`configFiles.device`
Der Pfad zur `device.json` Datei.
`testPath`
Der Pfad zu dem Ordner, der Testsuiten enthält.
`reportPath`
Der Pfad zu dem Ordner, der Testergebnisse enthält, nachdem IDT eine Testsuite ausgeführt hat.
`awsRegion`
Optional. Die AWS Region, die die Testsuiten verwenden werden. Wenn nicht festgelegt, verwenden Testsuiten die in jeder Testsuite angegebene Standardregion.
`auth.method`
Die Methode, die IDT zum Abrufen von AWS Anmeldeinformationen verwendet. Unterstützte Werte sind `file` das Abrufen von Anmeldeinformationen aus einer Anmeldeinformationsdatei und `environment` das Abrufen von Anmeldeinformationen mithilfe von Umgebungsvariablen.
`auth.credentials.profile`
Das zu verwendende Anmeldeinformationsprofil aus der Anmeldeinformationsdatei. Diese Eigenschaft gilt nur, wenn `auth.method` auf `file` festgelegt ist.
# Debuggen und Ausführen benutzerdefinierter Testsuiten
Nachdem die [erforderliche Konfiguration](set-custom-idt-config.md) festgelegt wurde, kann IDT Ihre Testsuite ausführen. Die Laufzeit der vollständigen Testsuite hängt von der Hardware und der Zusammensetzung der Testsuite ab. Als Referenz: Es dauert ungefähr 30 Minuten, bis die vollständige AWS IoT Greengrass Qualifizierungstestsuite auf einem Raspberry Pi 3B abgeschlossen ist.
Während Sie Ihre Testsuite schreiben, können Sie IDT verwenden, um die Testsuite im Debug-Modus auszuführen, um Ihren Code vor der Ausführung zu überprüfen oder ihn Testläufern zur Verfügung zu stellen.
## Führen Sie IDT im Debug-Modus aus
Da Testsuiten auf IDT angewiesen sind, um mit Geräten zu interagieren, den Kontext bereitzustellen und Ergebnisse zu erhalten, können Sie Ihre Testsuiten nicht einfach ohne IDT-Interaktion in einer IDE debuggen. Zu diesem Zweck stellt die IDT-CLI den `debug-test-suite` Befehl bereit, mit dem Sie IDT im Debug-Modus ausführen können. Führen Sie den folgenden Befehl aus, um die verfügbaren Optionen für anzuzeigen: `debug-test-suite`
```
devicetester_[linux | mac | win_x86-64] debug-test-suite -h
```
Wenn Sie IDT im Debug-Modus ausführen, startet IDT weder die Testsuite noch den Test-Orchestrator. Stattdessen interagiert IDT mit Ihrer IDE, um auf Anfragen von der in der IDE ausgeführten Testsuite zu antworten und die Protokolle auf der Konsole auszudrucken. IDT hat kein Timeout und wartet mit dem Beenden, bis es manuell unterbrochen wird. Im Debug-Modus führt IDT auch den Test-Orchestrator nicht aus und generiert keine Berichtsdateien. Um Ihre Testsuite zu debuggen, müssen Sie Ihre IDE verwenden, um einige Informationen bereitzustellen, die IDT normalerweise aus den JSON-Konfigurationsdateien bezieht. Stellen Sie sicher, dass Sie die folgenden Informationen angeben:
+ Umgebungsvariablen und Argumente für jeden Test. IDT liest diese Informationen nicht von `test.json` oder`suite.json`.
+ Argumente zur Auswahl von Ressourcengeräten. IDT liest diese Informationen nicht aus`test.json`.
Gehen Sie wie folgt vor, um Ihre Testsuiten zu debuggen:
1. Erstellen Sie die Einstellungskonfigurationsdateien, die für die Ausführung der Testsuite erforderlich sind. Wenn Ihre Testsuite beispielsweise die`device.json`, und erfordert`resource.json`, stellen Sie sicher`user data.json`, dass Sie sie alle nach Bedarf konfigurieren.
1. Führen Sie den folgenden Befehl aus, um IDT in den Debug-Modus zu versetzen und alle Geräte auszuwählen, die für die Ausführung des Tests erforderlich sind.
```
devicetester_[linux | mac | win_x86-64] debug-test-suite [options]
```
Nachdem Sie diesen Befehl ausgeführt haben, wartet IDT auf Anfragen von der Testsuite und beantwortet sie dann. IDT generiert auch die Umgebungsvariablen, die für den Fallprozess für das IDT Client SDK erforderlich sind.
1. Verwenden Sie in Ihrer IDE die `debug` Konfiguration `run` oder, um Folgendes zu tun:
1. Legen Sie die Werte der von IDT generierten Umgebungsvariablen fest.
1. Legen Sie den Wert aller Umgebungsvariablen oder Argumente fest, die Sie in Ihrer `test.json` AND-Datei angegeben haben. `suite.json`
1. Legen Sie nach Bedarf Haltepunkte fest.
1. Führen Sie die Testsuite in Ihrer IDE aus.
Sie können die Testsuite so oft wie nötig debuggen und erneut ausführen. IDT tritt im Debug-Modus nicht auf.
1. Nachdem Sie das Debuggen abgeschlossen haben, unterbrechen Sie IDT, um den Debug-Modus zu verlassen.
## IDT-CLI-Befehle zum Ausführen von Tests
Im folgenden Abschnitt werden die IDT-CLI-Befehle beschrieben:
------
#### [ IDT v4.0.0 ]
`help`
Listet Informationen über den angegebenen Befehl auf.
`list-groups`
Listet die Gruppen in der jeweiligen Testsuite auf.
`list-suites`
Listet die verfügbaren Testsuites auf.
`list-supported-products`
Listet die unterstützten Produkte für Ihre Version von IDT auf, in diesem Fall AWS IoT Greengrass Versionen, und die Versionen der AWS IoT Greengrass Qualifizierungstestsuite, die für die aktuelle IDT-Version verfügbar sind.
`list-test-cases`
Listet die Testfälle in einer bestimmten Testgruppe auf. Die folgende Option wird unterstützt:
+ `group-id`. Die Testgruppe, nach der gesucht werden soll. Diese Option ist erforderlich und muss eine einzelne Gruppe angeben.
`run-suite`
Führt eine Reihe von Tests in einem Pool von Geräten aus. Im Folgenden sind einige häufig verwendete Optionen aufgeführt:
+ `suite-id`. Die auszuführende Version der Testsuite. Wenn nicht angegeben, verwendet IDT die neueste Version im `tests`-Ordner.
+ `group-id`. Die auszuführenden Testgruppen als kommagetrennte Liste. Bei fehlender Angabe führt IDT alle Testgruppen in der Testsuite aus.
+ `test-id`. Die auszuführenden Testfälle als kommagetrennte Liste. Wenn angegeben, muss `group-id` eine einzelne Gruppe angeben.
+ `pool-id`. Der zu testende Gerätepool. Testläufer müssen einen Pool angeben, wenn in Ihrer `device.json` Datei mehrere Gerätepools definiert sind.
+ `timeout-multiplier`. Konfiguriert IDT so, dass das in der `test.json` Datei angegebene Timeout für die Testausführung für einen Test mit einem benutzerdefinierten Multiplikator geändert wird.
+ `stop-on-first-failure`. Konfiguriert IDT so, dass die Ausführung beim ersten Fehler gestoppt wird. Diese Option sollte mit `group-id` verwendet werden, um die angegebenen Testgruppen zu debuggen.
+ `userdata`. Legt die Datei fest, die Benutzerdateninformationen enthält, die zum Ausführen der Testsuite erforderlich sind. Dies ist nur erforderlich, wenn `userdataRequired` es in der `suite.json` Datei für die Testsuite auf true gesetzt ist.
Weitere Informationen zu `run-suite`-Optionen erhalten Sie mit der `help`-Option:
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
`debug-test-suite`
Führen Sie die Testsuite im Debug-Modus aus. Weitere Informationen finden Sie unter [Führen Sie IDT im Debug-Modus aus](#idt-debug-mode).
------
# Überprüfen Sie die IDT-Testergebnisse und -protokolle
In diesem Abschnitt wird das Format beschrieben, in dem IDT Konsolenprotokolle und Testberichte generiert.
## Nachrichtenformat der Konsole
AWS IoT Device Tester verwendet ein Standardformat für das Drucken von Nachrichten auf der Konsole, wenn eine Testsuite gestartet wird. Der folgende Auszug zeigt ein Beispiel für eine von IDT generierte Konsolennachricht.
```
time="2000-01-02T03:04:05-07:00" level=info msg=Using suite: MyTestSuite_1.0.0
executionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
Die meisten Konsolennachrichten bestehen aus den folgenden Feldern:
`time`
Ein vollständiger ISO 8601-Zeitstempel für das protokollierte Ereignis.
`level`
Die Nachrichtenebene für das protokollierte Ereignis. In der Regel ist die Ebene der protokollierten Nachricht eine von `info``warn`, oder`error`. IDT gibt eine `fatal` `panic` OR-Nachricht aus, wenn es auf ein erwartetes Ereignis trifft, das dazu führt, dass es vorzeitig beendet wird.
`msg`
Die protokollierte Nachricht.
`executionId`
Eine eindeutige ID-Zeichenfolge für den aktuellen IDT-Prozess. Diese ID wird verwendet, um zwischen einzelnen IDT-Läufen zu unterscheiden.
Von einer Testsuite generierte Konsolennachrichten enthalten zusätzliche Informationen über das zu testende Gerät und die Testsuite, Testgruppe und Testfälle, die IDT ausführt. Der folgende Auszug zeigt ein Beispiel für eine Konsolennachricht, die aus einer Testsuite generiert wurde.
```
time="2000-01-02T03:04:05-07:00" level=info msg=Hello world! suiteId=MyTestSuite
groupId=myTestGroup testCaseId=myTestCase deviceId=my-device
executionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
Der für die Testsuite spezifische Teil der Konsolennachricht enthält die folgenden Felder:
`suiteId`
Der Name der Testsuite, die gerade läuft.
`groupId`
Die ID der Testgruppe, die gerade läuft.
`testCaseId`
Die ID des aktuell laufenden Testfalls.
`deviceId`
Eine ID des zu testenden Geräts, das der aktuelle Testfall verwendet.
Um eine Testzusammenfassung auf der Konsole zu drucken, wenn ein IDT die Ausführung eines Tests abgeschlossen hat, müssen Sie in Ihrem Test-Orchestrator einen [`Report`Status angeben](idt-state-machine.md#state-report). Die Testzusammenfassung enthält Informationen über die Testsuite, die Testergebnisse für jede Gruppe, die ausgeführt wurde, und die Speicherorte der generierten Protokolle und Berichtsdateien. Das folgende Beispiel zeigt eine Meldung mit einer Testzusammenfassung.
```
========== Test Summary ==========
Execution Time: 5m00s
Tests Completed: 4
Tests Passed: 3
Tests Failed: 1
Tests Skipped: 0
----------------------------------
Test Groups:
GroupA: PASSED
GroupB: FAILED
----------------------------------
Failed Tests:
Group Name: GroupB
Test Name: TestB1
Reason: Something bad happened
----------------------------------
Path to IoT Device Tester Report: /path/to/awsiotdevicetester_report.xml
Path to Test Execution Logs: /path/to/logs
Path to Aggregated JUnit Report: /path/to/MyTestSuite_Report.xml
```
## AWS IoT Device Tester Berichtsschema
`awsiotdevicetester_report.xml`ist ein signierter Bericht, der die folgenden Informationen enthält:
+ Die IDT-Version.
+ Die Version der Testsuite.
+ Die Berichtssignatur und der Schlüssel, die zum Signieren des Berichts verwendet wurden.
+ Die Geräte-SKU und der Name des Gerätepools, die in der `device.json` Datei angegeben sind.
+ Die Produktversion und die getesteten Gerätefunktionen.
+ Die aggregierte Zusammenfassung der Testergebnisse. Diese Informationen entsprechen denen, die in der `suite-name_report.xml` Datei enthalten sind.
```
idt-version
test-suite-version
signature
keyname
execution-id
start-time
end-time
product-name
product-version
device-sku
device-name
ssh | uart | docker
```
Die Datei `awsiotdevicetester_report.xml` enthält ein ``-Tag mit Informationen zum getesteten Produkt und den Produktfunktionen, die nach einer Reihe von Tests validiert wurden.Im ``-Tag verwendete Attribute
`name`
Der Name des getesteten Produkts.
`version`
Die Version des getesteten Produkts.
`features`
Die validierten Funktionen Als markierte Funktionen `required` sind erforderlich, damit die Testsuite das Gerät validieren kann. Der folgende Ausschnitt zeigt, wie diese Informationen in der Datei `awsiotdevicetester_report.xml` angezeigt werden.
```
```
Als markierte Funktionen `optional` sind für die Validierung nicht erforderlich. Die folgenden Codeausschnitte zeigen optionale Funktionen.
```
```
## Berichtsschema der Testsuite
Der `suite-name_Result.xml` Bericht ist im [JUnit XML-Format](https://llg.cubic.org/docs/junit/). Sie können ihn in Continuous Integration and Deployment-Plattformen wie [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo) usw. integrieren. Der Bericht enthält eine Zusammenfassung der Testergebnisse.
```
reason
reason
reason
```
Im Berichtsabschnitt sowohl im `awsiotdevicetester_report.xml` als auch im Abschnitt `suite-name_report.xml` werden die durchgeführten Tests und die Ergebnisse aufgeführt.
Im ersten XML-Tag `` ist die Zusammenfassung der Testausführung enthalten. Zum Beispiel:
```
```Im ``-Tag verwendete Attribute
`name`
Name der Testsuite
`time`
Die Zeit in Sekunden, die zum Ausführen der Testsuite benötigt wurde.
`tests`
Die Anzahl der ausgeführten Tests.
`failures`
Die Anzahl der ausgeführten Tests, die den Test nicht bestanden haben
`errors`
Die Anzahl der Tests, die IDT nicht ausführen konnte.
`disabled`
Dieses Attribut wird nicht verwendet und kann ignoriert werden.
Falls bei Tests Fehler auftreten, können Sie den fehlgeschlagenen Test identifizieren, indem Sie die XML-Tags von `` überprüfen. Die XML-Tags von `` im ``-Tag zeigen die Ergebniszusammenfassung eines Tests für eine Testgruppe. Zum Beispiel:
```
```
Das Format ähnelt dem ``-Tag, weist aber das Attribut `skipped` auf, das nicht verwendet wird und ignoriert werden kann. Innerhalb der einzelnen ``-XML-Tags befinden sich ``-Tags für alle ausgeführten Tests einer Testgruppe. Zum Beispiel:
```
>
```Im ``-Tag verwendete Attribute
`name`
Der Name des Tests
`attempts`
Gibt an, wie oft IDT den Testfall ausgeführt hat.
Wenn ein Testfall fehlschlägt oder ein Fehler auftritt, werden ``- oder ``-Tags hinzugefügt, um das ``-Tag mit Informationen für die Fehlerbehebung zu versehen. Zum Beispiel:
```
Reason for the test failure
Reason for the test execution error
```
# IDT-Nutzungsmetriken
Wenn Sie AWS Anmeldeinformationen mit den erforderlichen Berechtigungen angeben, AWS IoT Device Tester sammelt und sendet Nutzungsmetriken an. AWS Dies ist eine Opt-in-Funktion, die zur Verbesserung der IDT-Funktionalität verwendet wird. IDT sammelt Informationen wie die folgenden:
+ Die AWS-Konto ID, die zur Ausführung von IDT verwendet wurde
+ Die AWS CLI IDT-Befehle, die zum Ausführen von Tests verwendet werden
+ Die Testsuiten, die ausgeführt werden
+ Die Testsuiten im ** Ordner
+ Die Anzahl der im Gerätepool konfigurierten Geräte
+ Testfallnamen und Laufzeiten
+ Informationen zu den Testergebnissen, z. B. ob Tests bestanden oder fehlgeschlagen sind, ob Fehler aufgetreten sind oder ob sie übersprungen wurden
+ Getestete Produktmerkmale
+ Verhalten beim Beenden von IDT, z. B. unerwartetes oder vorzeitiges Beenden
Alle Informationen, die IDT sendet, werden auch in einer `metrics.log` Datei im Ordner protokolliert. `/results//` In der Protokolldatei können Sie die Informationen einsehen, die während eines Testlaufs gesammelt wurden. Diese Datei wird nur generiert, wenn Sie sich für die Erfassung von Nutzungsmetriken entscheiden.
Um die Erfassung von Messwerten zu deaktivieren, müssen Sie keine zusätzlichen Maßnahmen ergreifen. Speichern Sie Ihre AWS Anmeldeinformationen einfach nicht, und wenn Sie AWS Anmeldeinformationen gespeichert haben, konfigurieren Sie die `config.json` Datei nicht für den Zugriff darauf.
## Konfigurieren Sie Ihre AWS Anmeldedaten
Wenn Sie noch keine haben AWS-Konto, müssen Sie [eine erstellen](#idt-metrics-aws-account). Wenn Sie bereits über eine verfügen AWS-Konto, müssen Sie lediglich [die erforderlichen Berechtigungen für Ihr Konto konfigurieren](#idt-metrics-permissions), damit IDT in Ihrem Namen Nutzungsdaten AWS an diese senden kann.
### Schritt 1: Erstellen Sie ein AWS-Konto
In diesem Schritt erstellen und konfigurieren Sie eine AWS-Konto. Wenn Sie bereits über ein AWS-Konto verfügen, fahren Sie direkt mit [Schritt 2: Konfigurieren von Berechtigungen für IDT](#idt-metrics-permissions) fort.
Wenn Sie noch keine haben AWS-Konto, führen Sie die folgenden Schritte aus, um eine zu erstellen.
**Um sich für eine anzumelden AWS-Konto**
1. Öffnen Sie [https://portal.aws.amazon.com/billing/die Anmeldung.](https://portal.aws.amazon.com/billing/signup)
1. Folgen Sie den Online-Anweisungen.
Während der Anmeldung erhalten Sie einen Telefonanruf oder eine Textnachricht und müssen einen Verifizierungscode über die Telefontasten eingeben.
Wenn Sie sich für eine anmelden AWS-Konto, *Root-Benutzer des AWS-Kontos*wird eine erstellt. Der Root-Benutzer hat Zugriff auf alle AWS-Services und Ressourcen des Kontos. Als bewährte Sicherheitsmethode weisen Sie einem Benutzer Administratorzugriff zu und verwenden Sie nur den Root-Benutzer, um [Aufgaben auszuführen, die Root-Benutzerzugriff erfordern](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
Wählen Sie zum Erstellen eines Administratorbenutzers eine der folgenden Optionen aus.
****
| Wählen Sie eine Möglichkeit zur Verwaltung Ihres Administrators aus. | Bis | Von | Sie können auch |
| --- | --- | --- | --- |
| Im IAM Identity Center (Empfohlen) | Verwendung von kurzfristigen Anmeldeinformationen für den Zugriff auf AWS.Dies steht im Einklang mit den bewährten Methoden für die Sicherheit. Weitere Informationen zu bewährten Methoden finden Sie unter [Bewährte Methoden für die Sicherheit in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) im *IAM-Benutzerhandbuch*. | Beachtung der Anweisungen unter [Erste Schritte](https://docs.aws.amazon.com//singlesignon/latest/userguide/getting-started.html) im AWS IAM Identity Center -Benutzerhandbuch. | Konfigurieren Sie den programmatischen Zugriff, indem [Sie AWS CLI die Konfiguration für die Verwendung AWS IAM Identity Center](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-sso.html) im AWS Command Line Interface Benutzerhandbuch vornehmen. |
| In IAM (Nicht empfohlen) | Verwendung von langfristigen Anmeldeinformationen für den Zugriff auf AWS. | Folgen Sie den Anleitungen unter [IAM-Benutzer für den Notfallzugriff erstellen](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started-emergency-iam-user.html) im IAM-Benutzerhandbuch. | Sie konfigurieren den programmgesteuerten Zugriff unter Verwendung der Informationen unter [Verwalten der Zugriffsschlüssel für IAM-Benutzer](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html) im IAM-Benutzerhandbuch. |
### Schritt 2: Konfigurieren von Berechtigungen für IDT
In diesem Schritt konfigurieren Sie die Berechtigungen, die IDT zum Ausführen von Tests und zum Sammeln von IDT-Nutzungsdaten verwendet. Sie können das AWS-Managementkonsole oder AWS Command Line Interface (AWS CLI) verwenden, um eine IAM-Richtlinie und einen Benutzer für IDT zu erstellen und dann Richtlinien an den Benutzer anzuhängen.
+ [So konfigurieren Sie Berechtigungen für IDT (Konsole)](#idt-metrics-permissions-console):
+ [So konfigurieren Sie Berechtigungen für IDT (AWS CLI)](#idt-metrics-permissions-cli):
**So konfigurieren Sie Berechtigungen für IDT (Konsole)**
Gehen Sie folgendermaßen vor, um mithilfe der Konsole Berechtigungen für IDT für AWS IoT Greengrass zu konfigurieren.
1. Melden Sie sich bei der [IAM-Konsole](https://console.aws.amazon.com/iam) an.
1. Erstellen Sie eine vom Kunden verwaltete Richtlinie, die Berechtigungen zum Erstellen von Rollen mit bestimmten Berechtigungen erteilt.
1. Wählen Sie im Navigationsbereich **Richtlinien** und dann **Richtlinie erstellen**.
1. Ersetzen Sie auf der Registerkarte **JSON** den Platzhalterinhalt durch die folgende Richtlinie.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot-device-tester:SendMetrics"
],
"Resource": "*"
}
]
}
```
------
1. Wählen Sie **Richtlinie prüfen**.
1. Geben Sie unter **Name** **IDTUsageMetricsIAMPermissions** ein. Überprüfen Sie unter **Summary (Zusammenfassung)** die von Ihrer Richtlinie gewährten Berechtigungen.
1. Wählen Sie **Richtlinie erstellen** aus.
1. Erstellen Sie einen IAM-Benutzer und weisen Sie dem Benutzer Berechtigungen zu.
1. Erstellen Sie einen IAM-Benutzer. Folgen Sie den Schritten 1 bis 5 unter [Erstellen von IAM-Benutzern (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) im *IAM-Benutzerhandbuch*. Wenn Sie bereits einen IAM-Benutzer erstellt haben, fahren Sie mit dem nächsten Schritt fort.
1. Hängen Sie die Berechtigungen an Ihren IAM-Benutzer an:
1. Wählen Sie auf der Seite **Set permissions (Berechtigungen einrichten)** die Option **Attach existing policies to user directly (Vorhandene Richtlinien dem Benutzer direkt anfügen)** aus.
1. Suchen Sie nach der **IDTUsageIAMPermissionsMetrics-Richtlinie**, die Sie im vorherigen Schritt erstellt haben. Markieren Sie das Kontrollkästchen.
1. Wählen Sie **Weiter: Tags** aus.
1. Wählen Sie **Next: Review (Weiter: Überprüfen)**, um eine Zusammenfassung Ihrer Auswahlmöglichkeiten anzuzeigen.
1. Wählen Sie **Create user** (Benutzer erstellen) aus.
1. Um die Zugriffsschlüssel des Benutzers (Zugriffsschlüssel IDs und geheime Zugriffsschlüssel) **anzuzeigen**, wählen Sie neben dem Passwort und dem Zugriffsschlüssel die Option Anzeigen aus. Zum Speichern der Zugriffsschlüssel wählen Sie **Download .csv (CSV-Datei herunterladen)** aus und speichern die Datei an einem sicheren Speicherort. Sie verwenden diese Informationen später, um Ihre AWS Anmeldeinformationsdatei zu konfigurieren.
**So konfigurieren Sie Berechtigungen für IDT (AWS CLI)**
Gehen Sie wie folgt vor, AWS CLI um Berechtigungen für IDT für AWS IoT Greengrass zu konfigurieren.
1. Installieren und konfigurieren Sie das auf Ihrem Computer, AWS CLI falls es noch nicht installiert ist. Folgen Sie den Schritten [unter Installation von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) im *AWS Command Line Interface Benutzerhandbuch*.
**Anmerkung**
Das AWS CLI ist ein Open-Source-Tool, mit dem Sie über Ihre AWS Befehlszeilen-Shell mit Diensten interagieren können.
1. Erstellen Sie die folgende vom Kunden verwaltete Richtlinie, die Berechtigungen zur Verwaltung von IDT und Rollen gewährt. AWS IoT Greengrass
------
#### [ Linux or Unix ]
```
aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot-device-tester:SendMetrics"
],
"Resource": "*"
}
]
}'
```
------
#### [ Windows command prompt ]
```
aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document
'{\"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": [\"iot-device-tester:SendMetrics\"], \"Resource": \"*\"}]}'
```
**Anmerkung**
Dieser Schritt beinhaltet ein Beispiel für eine Windows-Eingabeaufforderung, da er eine andere JSON-Syntax als Linux-, macOS- oder Unix-Terminalbefehle verwendet.
------
#### [ PowerShell ]
```
aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot-device-tester:SendMetrics"
],
"Resource": "*"
}
]
}'
```
------
1. Erstellen Sie einen IAM-Benutzer und fügen Sie die von IDT erforderlichen Berechtigungen für hinzu. AWS IoT Greengrass
1. Erstellen Sie einen IAM-Benutzer.
```
aws iam create-user --user-name user-name
```
1. Hängen Sie die von Ihnen erstellte `IDTUsageMetricsIAMPermissions` Richtlinie an Ihren IAM-Benutzer an. *user-name*Ersetzen Sie es durch Ihren IAM-Benutzernamen und ** im Befehl durch die ID Ihres. AWS-Konto
```
aws iam attach-user-policy --user-name user-name --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions
```
1. Erstellen Sie einen geheimen Zugriffsschlüssel für den Benutzer.
```
aws iam create-access-key --user-name user-name
```
Speichern Sie die Ausgabe an einem sicheren Ort. Sie verwenden diese Informationen später, um Ihre AWS Anmeldeinformationsdatei zu konfigurieren.
## Geben Sie die AWS Anmeldeinformationen für IDT ein
Gehen Sie wie folgt vor, damit IDT auf Ihre AWS Anmeldeinformationen zugreifen und Messwerte an AWS senden kann:
1. Speichern Sie die AWS Anmeldeinformationen für Ihren IAM-Benutzer als Umgebungsvariablen oder in einer Anmeldeinformationsdatei:
1. Führen Sie die folgenden Befehle aus, um Umgebungsvariablen zu verwenden.
------
#### [ Linux or Unix ]
```
export AWS_ACCESS_KEY_ID=access-key
export AWS_SECRET_ACCESS_KEY=secret-access-key
```
------
#### [ Windows Command Prompt (CMD) ]
```
set AWS_ACCESS_KEY_ID=access-key
set AWS_SECRET_ACCESS_KEY=secret-access-key
```
------
#### [ PowerShell ]
```
$env:AWS_ACCESS_KEY_ID="access-key"
$env:AWS_SECRET_ACCESS_KEY="secret-access-key"
```
------
1. Um die Datei mit den Anmeldeinformationen zu verwenden, fügen Sie der `~/.aws/credentials` Datei die folgenden Informationen hinzu.
```
[profile-name]
aws_access_key_id=access-key
aws_secret_access_key=secret-access-key
```
1. Konfigurieren Sie den `auth` Abschnitt der `config.json` Datei. Weitere Informationen finden Sie unter [(Optional) Konfigurieren Sie config.json](set-custom-idt-config.md#config-json-custom).