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.
# AWS IoT Device Tester Für AWS IoT Greengrass V2 verwenden
AWS IoT Device Tester (IDT) ist ein herunterladbares Test-Framework, mit dem Sie IoT-Geräte validieren können. Sie können IDT verwenden, AWS IoT Greengrass um die AWS IoT Greengrass Qualifizierungssuite auszuführen und benutzerdefinierte Testsuiten für Ihre Geräte zu erstellen und auszuführen.
IDT for AWS IoT Greengrass läuft auf Ihrem Host-Computer (Windows, macOS oder Linux), der mit dem zu testenden Gerät verbunden ist. Er führt Tests durch und fasst die Ergebnisse zusammen. Er bietet auch eine Befehlszeilenschnittstelle zur Verwaltung der Testprozesse.
## AWS IoT Greengrass Qualifizierungssuite
Verwenden Sie AWS IoT Device Tester für AWS IoT Greengrass V2, um zu überprüfen, ob die AWS IoT Greengrass Core-Software auf Ihrer Hardware läuft und mit der kommunizieren kann AWS Cloud. Es führt auch end-to-end Tests mit durch AWS IoT Core. Es überprüft beispielsweise, ob Ihr Gerät Komponenten bereitstellen und aktualisieren kann.
Wenn Sie Ihre Hardware zum AWS Partner Gerätekatalog hinzufügen möchten, führen Sie die AWS IoT Greengrass Qualification Suite aus, um Testberichte zu erstellen, an die Sie sie einreichen können. AWS IoT Weitere Informationen finden Sie unter [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
![\[Ein Überblick darüber, wie AWS IoT Device Tester für AWS IoT Greengrass V2 überprüft wird, ob die AWS IoT Greengrass Core-Software auf Ihrer Hardware läuft und mit der AWS Cloud kommunizieren kann.\]](http://docs.aws.amazon.com/de_de/greengrass/v2/developerguide/images/devicetester_gg.png)
*IDT for AWS IoT Greengrass V2 organisiert Tests unter Verwendung der Konzepte von *Testsuiten und Testgruppen*.*
+ Eine Testsuite ist der Satz von Testgruppen, die verwendet werden, um zu überprüfen, ob ein Gerät mit bestimmten Versionen von AWS IoT Greengrass funktioniert.
+ Eine Testgruppe besteht aus einzelnen Tests, die sich auf eine bestimmte Funktion beziehen, z. B. auf die Bereitstellung von Komponenten.
Weitere Informationen finden Sie unter [Verwenden Sie IDT, um die AWS IoT Greengrass Qualification Suite auszuführen](idt-greengrass-qualification.md).
## Benutzerdefinierte Testsuiten
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.
Wie ein Testautor eine benutzerdefinierte Testsuite konfiguriert, bestimmt die Einstellungskonfigurationen, die für die Ausführung benutzerdefinierter Testsuiten erforderlich sind. Weitere Informationen finden Sie unter [Verwenden Sie IDT, um Ihre eigenen Testsuiten zu entwickeln und auszuführen](idt-custom-tests.md).
# Unterstützte Versionen von AWS IoT Device Tester für AWS IoT Greengrass V2
In diesem Thema werden die unterstützten Versionen von IDT für AWS IoT Greengrass V2 aufgeführt. Als bewährte Methode empfehlen wir, dass Sie die neueste Version von IDT für AWS IoT Greengrass V2 verwenden, die Ihre Zielversion von AWS IoT Greengrass V2 unterstützt. Bei neuen Versionen von müssen Sie AWS IoT Greengrass möglicherweise eine neue Version von IDT für AWS IoT Greengrass V2 herunterladen. Sie erhalten eine Benachrichtigung, wenn Sie einen Testlauf starten, wenn IDT für AWS IoT Greengrass V2 nicht mit der von AWS IoT Greengrass Ihnen verwendeten Version kompatibel ist.
Durch das Herunterladen der Software stimmen Sie der [AWS IoT Device Tester Lizenzvereinbarung](https://docs.aws.amazon.com/greengrass/v2/developerguide/idt-license.html) zu.
**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.
## Aktuelle IDT-Version für V2 AWS IoT Greengrass
Sie können diese Version von IDT für AWS IoT Greengrass V2 mit der hier aufgeführten AWS IoT Greengrass Version verwenden.
**IDT v4.9.4 für AWS IoT Greengrass**
Unterstützte Versionen: AWS IoT Greengrass
+ [Greengrass Nucleus](greengrass-nucleus-component.md) v2.12.0, v2.11.0, v2.10.0 und v2.9.5
IDT-Softwaredownloads:
+ [IDT v4.9.4 mit Testsuite Q\$12.5.4 für Linux GGV2](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_linux.zip)
+ [IDT v4.9.4 mit Testsuite GGV2 Q\$12.5.4 für macOS](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_mac.zip)
+ [IDT v4.9.4 mit Testsuite Q\$12.5.4 für Windows GGV2](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_win.zip)
Versionshinweise:
+ Ermöglicht die Gerätevalidierung und Qualifizierung für Geräte, auf denen die AWS IoT Greengrass Core-Softwareversionen 2.12.0, 2.11.0, 2.10.0 und 2.9.5 ausgeführt werden.
+ Entfernt Stream Manager- und Machine-Learning-Testgruppen.
Weitere Hinweise:
+ Wenn Ihr Gerät ein HSM verwendet und Sie Nucleus 2.10.x verwenden, migrieren Sie zu Greengrass Nucleus Version 2.11.0 oder höher.
Testsuite-Version:
`GGV2Q_2.5.4`
+ Veröffentlicht am 2024.05.03
## Frühere IDT-Versionen für AWS IoT Greengrass
Die folgenden früheren Versionen von IDT für AWS IoT Greengrass V2 werden ebenfalls unterstützt.
**IDT v4.9.3 für AWS IoT Greengrass**
Unterstützte Versionen: AWS IoT Greengrass
+ [Greengrass Nucleus](greengrass-nucleus-component.md) v2.12.0, v2.11.0, v2.10.0 und v2.9.5
IDT-Softwaredownloads:
+ [IDT v4.9.3 mit Testsuite Q\$12.5.3 für Linux GGV2](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.3_testsuite_2.5.3_linux.zip)
+ [IDT v4.9.3 mit Testsuite GGV2 Q\$12.5.3 für macOS](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.3_testsuite_2.5.3_mac.zip)
+ [IDT v4.9.3 mit Testsuite Q\$12.5.3 für Windows GGV2](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.3_testsuite_2.5.3_win.zip)
Versionshinweise:
+ Behebt ein Problem bei den Komponententests beim Testen eines Linux-Geräts von einem Windows-Host aus oder umgekehrt.
+ Entfernt den `localcomponent` Testfall aus der `component` Testgruppe. Dieser Testfall ist für die Qualifizierung nicht mehr erforderlich.
Weitere Hinweise:
+ Wenn Ihr Gerät ein HSM verwendet und Sie Nucleus 2.10.x verwenden, migrieren Sie zu Greengrass Nucleus Version 2.11.0 oder höher.
Testsuite-Version:
`GGV2Q_2.5.3`
+ Veröffentlicht 2024.04.05
## Nicht unterstützte Versionen von für V2 AWS IoT Device Tester AWS IoT Greengrass
In diesem Thema werden nicht unterstützte Versionen von IDT für V2 aufgeführt. AWS IoT Greengrass Nicht unterstützte Versionen erhalten keine Fehlerbehebungen oder Updates. Weitere Informationen finden Sie unter [Unterstützungsrichtlinie AWS IoT Device Tester für AWS IoT Greengrass](idt-support-policy.md).
**IDT v4.9.2 für AWS IoT Greengrass**
Versionshinweise:
+ Behebt ein Problem, bei dem die Lambda-Testsuite fehlschlägt, weil Java 8 veraltet ist.
Testsuite-Version:
`GGV2Q_2.5.2`
+ Veröffentlicht am 2024.03.18
**IDT v4.9.1 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Softwareversionen 2.12.0, 2.11.0, 2.10.0 und 2.9.5 ausgeführt werden.
+ Kleinere Fehlerbehebungen.
Testsuite-Version:
`GGV2Q_2.5.1`
+ Veröffentlicht 2023.10.05
**IDT v4.7.0 für AWS IoT Greengrass**
Unterstützte Versionen: AWS IoT Greengrass
+ [Greengrass Nucleus](greengrass-nucleus-component.md) v2.11.0, v2.10.0 und v2.9.5
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Softwareversionen 2.11.0, 2.10.0 und 2.9.5 ausgeführt werden.
+ Fügt Unterstützung hinzu, um IDT-Benutzerdatenwerte im AWS Systems Manager Parameter Store zu speichern und sie mithilfe der Platzhaltersyntax in die Konfiguration abzurufen.
+ Kleinere Fehlerbehebungen.
Testsuite-Version:
`GGV2Q_2.5.0`
+ Veröffentlicht 2022.12.13
**IDT v4.5.11 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Softwareversionen 2.9.1, 2.9.0, 2.8.1, 2.8.0, 2.7.0 und 2.6.0 ausgeführt werden.
+ Fügt Unterstützung hinzu, um PreInstalled Greengrass auf einem Kerngerät zu testen.
+ Kleinere Fehlerbehebungen.
Testsuite-Version:
`GGV2Q_2.4.1`
+ Veröffentlicht am 13.10.2022
**IDT v4.5.8 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Softwareversionen 2.7.0, 2.6.0 und 2.5.6 ausgeführt werden.
+ Ermöglicht das Testen mit PreInstalled Greengrass auf einem Core-Gerät.
+ Kleinere Fehlerbehebungen.
Testsuite-Version:
`GGV2Q_2.4.0`
+ Veröffentlicht am 12.08.2022
**IDT v4.5.3 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Softwareversionen 2.7.0, 2.6.0, 2.5.6, 2.5.5, 2.5.4 und 2.5.3 ausgeführt werden.
+ Aktualisiert den DockerApplicationManager Test, um ein ECR-basiertes Docker-Image zu verwenden.
+ Kleinere Fehlerbehebungen.
Testsuite-Version:
`GGV2Q_2.3.1`
+ Veröffentlicht am 15.04.2022
**IDT v4.5.1 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Software v2.5.3 ausgeführt wird.
+ Integriert die Unterstützung für die Validierung und Qualifizierung von Linux-basierten Geräten, die ein Hardware-Sicherheitsmodul (HSM) zum Speichern des privaten Schlüssels und Zertifikats verwenden, die von der Core-Software verwendet werden. AWS IoT Greengrass
+ Implementiert den neuen IDT-Testorchestrator für die Konfiguration benutzerdefinierter Testsuiten. Weitere Informationen finden Sie unter [Konfigurieren Sie den IDT-Testorchestrator](idt-test-orchestrator.md).
+ Zusätzliche kleinere Bugfixes.
Testsuite-Version:
`GGV2Q_2.3.0`
+ Veröffentlicht am 11.01.2022
**IDT v4.4.1 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Software v2.5.2 ausgeführt wird.
+ Integriert die Unterstützung für die Verwendung einer benutzerdefinierten IAM-Rolle als Token-Austauschrolle, die das getestete Gerät für die Interaktion mit Ressourcen annimmt. AWS
[Sie können die IAM-Rolle in der Datei angeben. `userdata.json`](set-config.md#userdata-config) Wenn Sie eine benutzerdefinierte Rolle angeben, verwendet IDT diese Rolle, anstatt während des Testlaufs die Standard-Token-Exchange-Rolle zu erstellen.
+ Zusätzliche kleinere Bugfixes.
Testsuite-Version:
`GGV2Q_2.2.1`
+ Veröffentlicht 2021.12.12
**IDT v4.4.0 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Software v2.5.0 ausgeführt wird.
+ Integriert die Unterstützung für die Validierung und Qualifizierung von Geräten, auf denen AWS IoT Greengrass Core-Software unter Windows ausgeführt wird.
+ Unterstützt die Verwendung der Validierung öffentlicher Schlüssel für Secure Shell (SSH) -Geräteverbindungen.
+ Verbessert die IAM-Richtlinie für IDT-Berechtigungen mit bewährten Sicherheitsmethoden.
+ Zusätzliche kleinere Fehlerkorrekturen.
Testsuite-Version:
`GGV2Q_2.1.0`
+ Veröffentlicht 2021.11.19
**IDT v4.2.0 für AWS IoT Greengrass**
Versionshinweise:
+ Beinhaltet Unterstützung für die Qualifizierung der folgenden Funktionen auf Geräten, auf denen die AWS IoT Greengrass Core-Software v2.2.0 und spätere Versionen ausgeführt wird:
+ Docker — Überprüft, ob Geräte ein Docker-Container-Image von Amazon Elastic Container Registry (Amazon ECR) herunterladen können.
+ [https://github.com/neo-ai/neo-ai-dlr](https://github.com/neo-ai/neo-ai-dlr)
+ Stream Manager — Überprüft, ob Geräte den Stream Manager herunterladen, installieren und ausführen können. AWS IoT Greengrass
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Software v2.4.0, v2.3.0, v2.2.0 und v2.1.0 ausgeführt wird.
+ Gruppiert die Testprotokolle für jeden Testfall in einem separaten Ordner innerhalb des Verzeichnisses. ** `/results//logs/`
+ Zusätzliche kleinere Bugfixes.
Testsuite-Version:
`GGV2Q_2.0.1`
+ Veröffentlicht 2021.08.31
**IDT v4.1.0 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Software v2.3.0, v2.2.0, v2.1.0 und v2.0.5 ausgeführt wird.
+ Verbessert die `userdata.json` Konfiguration, da die Angabe der Eigenschaften und nicht mehr erforderlich ist. `GreengrassNucleusVersion` `GreengrassCLIVersion`
+ Beinhaltet Unterstützung für Lambda und MQTT-Funktionsqualifizierung für AWS IoT Greengrass Core-Software v2.1.0 und spätere Versionen. Sie können jetzt IDT for AWS IoT Greengrass V2 verwenden, um zu überprüfen, ob Ihr Kerngerät Lambda-Funktionen ausführen kann und ob das Gerät AWS IoT Core MQTT-Themen veröffentlichen und abonnieren kann.
+ Verbessert die Protokollierungsfunktionen.
+ Zusätzliche kleinere Fehlerkorrekturen.
Testsuite-Version:
`GGV2Q_1.1.1`
+ Veröffentlicht 2021.06.18
**IDT v4.0.2 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen die AWS IoT Greengrass Core-Software v2.1.0 ausgeführt wird.
+ Integriert die Unterstützung für Lambda- und MQTT-Funktionsqualifizierung für AWS IoT Greengrass Core-Software v2.1.0 und spätere Versionen. Sie können jetzt IDT for AWS IoT Greengrass V2 verwenden, um zu überprüfen, ob Ihr Kerngerät Lambda-Funktionen ausführen kann und ob das Gerät AWS IoT Core MQTT-Themen veröffentlichen und abonnieren kann.
+ Verbessert die Protokollierungsfunktionen.
+ Zusätzliche kleinere Fehlerkorrekturen.
Testsuite-Version:
`GGV2Q_1.1.1`
+ Veröffentlicht 2021.05.05
**IDT v4.0.1 für AWS IoT Greengrass**
Versionshinweise:
+ Ermöglicht die Validierung und Qualifizierung von Geräten, auf denen Software der AWS IoT Greengrass Version 2 ausgeführt wird.
+ Ermöglicht es Ihnen, Ihre benutzerdefinierten Testsuiten mit AWS IoT Device Tester for zu entwickeln und auszuführen AWS IoT Greengrass. Weitere Informationen finden Sie unter [Verwenden Sie IDT, um Ihre eigenen Testsuiten zu entwickeln und auszuführen](idt-custom-tests.md).
+ Stellt codesignierte IDT-Anwendungen für macOS und Windows bereit. Unter macOS müssen Sie möglicherweise eine Sicherheitsausnahme für IDT gewähren. Weitere Informationen finden Sie unter [Sicherheitsausnahme auf macOS](idt-troubleshooting.md#security-exception-macos).
Testsuite-Version:
`GGV2Q_1.0.0`
+ Veröffentlicht am 22.12.2020
+ Die Testsuite führt nur die für die Qualifizierung erforderlichen Tests aus, es sei denn, Sie setzen die entsprechenden Tests `value` im `features` Array auf. `yes`
# Laden Sie IDT für AWS IoT Greengrass V2 herunter
In diesem Thema werden die Optionen zum Herunterladen AWS IoT Device Tester für AWS IoT Greengrass V2 beschrieben. Sie können entweder einen der folgenden Links zum Herunterladen von Software verwenden oder den Anweisungen folgen, um IDT programmgesteuert herunterzuladen.
**Topics**
+ [Laden Sie IDT manuell herunter](#idt-download-options)
+ [Laden Sie IDT programmgesteuert herunter](#idt-programmatic-download-process)
[Durch das Herunterladen der Software stimmen Sie der AWS IoT Device Tester Lizenzvereinbarung zu.](https://docs.aws.amazon.com/greengrass/v2/developerguide/idt-license.html)
**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.
## Laden Sie IDT manuell herunter
In diesem Thema werden die unterstützten Versionen von IDT für AWS IoT Greengrass V2 aufgeführt. Als bewährte Methode empfehlen wir, dass Sie die neueste Version von IDT für AWS IoT Greengrass V2 verwenden, die Ihre Zielversion von AWS IoT Greengrass V2 unterstützt. Bei neuen Versionen von müssen Sie AWS IoT Greengrass möglicherweise eine neue Version von IDT für AWS IoT Greengrass V2 herunterladen. Sie erhalten eine Benachrichtigung, wenn Sie einen Testlauf starten, wenn IDT für AWS IoT Greengrass V2 nicht mit der von AWS IoT Greengrass Ihnen verwendeten Version kompatibel ist.
**IDT v4.9.4 für AWS IoT Greengrass**
Unterstützte Versionen: AWS IoT Greengrass
+ [Greengrass Nucleus](greengrass-nucleus-component.md) v2.12.0, v2.11.0, v2.10.0 und v2.9.5
IDT-Softwaredownloads:
+ [IDT v4.9.4 mit Testsuite Q\$12.5.4 für Linux GGV2](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_linux.zip)
+ [IDT v4.9.4 mit Testsuite GGV2 Q\$12.5.4 für macOS](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_mac.zip)
+ [IDT v4.9.4 mit Testsuite Q\$12.5.4 für Windows GGV2](https://docs.aws.amazon.com/greengrass/v2/developerguide/devicetester_greengrass_v2_4.9.4_testsuite_2.5.4_win.zip)
Versionshinweise:
+ Ermöglicht die Gerätevalidierung und Qualifizierung für Geräte, auf denen die AWS IoT Greengrass Core-Softwareversionen 2.12.0, 2.11.0, 2.10.0 und 2.9.5 ausgeführt werden.
+ Entfernt Stream Manager- und Machine-Learning-Testgruppen.
Weitere Hinweise:
+ Wenn Ihr Gerät ein HSM verwendet und Sie Nucleus 2.10.x verwenden, migrieren Sie zu Greengrass Nucleus Version 2.11.0 oder höher.
Testsuite-Version:
`GGV2Q_2.5.4`
+ Veröffentlicht am 2024.05.03
## Laden Sie IDT programmgesteuert herunter
IDT bietet eine API-Operation, mit der Sie eine URL abrufen können, über die Sie IDT programmgesteuert herunterladen können. Sie können diesen API-Vorgang auch verwenden, um zu überprüfen, ob Sie über die neueste Version von IDT verfügen. Dieser API-Vorgang hat den folgenden Endpunkt.
```
https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt
```
Um diesen API-Vorgang aufrufen zu können, müssen Sie über die Berechtigung zum Ausführen der **iot-device-tester:LatestIdt** Aktion verfügen. Fügen Sie Ihre AWS Signatur hinzu und verwenden Sie `iot-device-tester` sie als Dienstnamen.
### API-Anfrage
HostOs — Das Betriebssystem des Host-Computers. Wählen Sie aus den folgenden Optionen aus:
+ `mac`
+ `linux`
+ `windows`
TestSuiteType — Der Typ der Testsuite. Wählen Sie die folgende Option:
`GGV2`— IDT für V2 AWS IoT Greengrass
ProductVersion
(Optional) Die Version des Greengrass-Kerns. Der Dienst gibt die neueste kompatible Version von IDT für diese Version von Greengrass Nucleus zurück. Wenn Sie diese Option nicht angeben, gibt der Dienst die neueste Version von IDT zurück.
### API-Antwort
Die API-Antwort hat das folgende Format. Das `DownloadURL` beinhaltet eine Zip-Datei.
```
{
"Success": True or False,
"Message": Message,
"LatestBk": {
"Version": The version of the IDT binary,
"TestSuiteVersion": The version of the test suite,
"DownloadURL": The URL to download the IDT Bundle, valid for one hour
}
}
```
### Beispiele
Sie können sich auf die folgenden Beispiele beziehen, um IDT programmgesteuert herunterzuladen. In diesen Beispielen werden Anmeldeinformationen verwendet, die Sie in den Umgebungsvariablen `AWS_ACCESS_KEY_ID` und `AWS_SECRET_ACCESS_KEY` speichern. Speichern Sie Ihre Anmeldeinformationen nicht in Ihrem Code, um die besten Sicherheitsvorkehrungen zu befolgen.
**Example Beispiel: Herunterladen mit cURL Version 7.75.0 oder höher (Mac und Linux)**
Wenn Sie die cURL-Version 7.75.0 oder höher haben, können Sie das `aws-sigv4` Flag verwenden, um die API-Anfrage zu signieren. In diesem Beispiel wird [jq](https://stedolan.github.io/jq/) verwendet, um die Download-URL aus der Antwort zu analysieren.
Das `aws-sigv4` Flag erfordert, dass die Abfrageparameter der curl-GET-Anfrage in der Reihenfolge oder angegeben werden. **HostOs/ProductVersion/TestSuiteType** **HostOs/TestSuiteType** Bestellungen, die nicht konform sind, führen zu einem Fehler beim Abrufen nicht übereinstimmender Signaturen für den Canonical String vom API Gateway.
Wenn der optionale Parameter enthalten **ProductVersion** ist, müssen Sie eine unterstützte Produktversion verwenden, wie unter Unterstützte [Versionen von](dev-test-versions.md) für V2 dokumentiert. AWS IoT Device Tester AWS IoT Greengrass
+ Ersetze es *us-west-2* durch dein AWS-Region. Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ *linux*Ersetzen Sie es durch das Betriebssystem Ihres Host-Computers.
+ *2.5.3*Ersetzen Sie es durch Ihre Version von AWS IoT Greengrass Nucleus.
```
url=$(curl --request GET "https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&ProductVersion=2.5.3&TestSuiteType=GGV2" \
--user $AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY \
--aws-sigv4 "aws:amz:us-west-2:iot-device-tester" \
| jq -r '.LatestBk["DownloadURL"]')
curl $url --output devicetester.zip
```
**Example Beispiel: Herunterladen mit einer früheren Version von cURL (Mac und Linux)**
Sie können den folgenden cURL-Befehl mit einer AWS Signatur verwenden, die Sie signieren und berechnen. Weitere Informationen zum Signieren und Berechnen einer AWS Signatur finden Sie unter [AWS API-Anfragen signieren](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html).
+ *linux*Ersetzen Sie es durch das Betriebssystem Ihres Host-Computers.
+ *Timestamp*Ersetzen Sie durch Datum und Uhrzeit, z. **20220210T004606Z** B.
+ *Date*Ersetzen Sie es durch das Datum, z. **20220210** B.
+ Ersetze *AWSRegion* durch dein AWS-Region. Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ *AWSSignature*Ersetzen Sie es durch die [AWS Signatur](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html), die Sie generieren.
```
curl --location --request GET 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&TestSuiteType=GGV2' \
--header 'X-Amz-Date: Timestamp \
--header 'Authorization: AWS4-HMAC-SHA256 Credential=$AWS_ACCESS_KEY_ID/Date/AWSRegion/iot-device-tester/aws4_request, SignedHeaders=host;x-amz-date, Signature=AWSSignature'
```
**Example Beispiel: Herunterladen mit einem Python-Skript**
In diesem Beispiel wird die [Python-Anforderungsbibliothek](https://pypi.org/project/requests/) verwendet. Dieses Beispiel ist an das Python-Beispiel angepasst, um [eine AWS API-Anfrage zu signieren](https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html) in der *AWS Allgemeinen Referenz*.
+ Ersetzen Sie *us-west-2* durch Ihre Region. Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html).
+ *linux*Ersetzen Sie es durch das Betriebssystem Ihres Host-Computers.
```
# Copyright 2010-2022 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# This file is licensed under the Apache License, Version 2.0 (the "License").
# You may not use this file except in compliance with the License. A copy of the
#License is located at
#
# http://aws.amazon.com/apache2.0/
#
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
# OF ANY KIND, either express or implied. See the License for the specific
# language governing permissions and limitations under the License.
# See: http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html
# This version makes a GET request and passes the signature
# in the Authorization header.
import sys, os, base64, datetime, hashlib, hmac
import requests # pip install requests
# ************* REQUEST VALUES *************
method = 'GET'
service = 'iot-device-tester'
host = 'download.devicetester.iotdevicesecosystem.amazonaws.com'
region = 'us-west-2'
endpoint = 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt'
request_parameters = 'HostOs=linux&TestSuiteType=GGV2'
# Key derivation functions. See:
# http://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html#signature-v4-examples-python
def sign(key, msg):
return hmac.new(key, msg.encode('utf-8'), hashlib.sha256).digest()
def getSignatureKey(key, dateStamp, regionName, serviceName):
kDate = sign(('AWS4' + key).encode('utf-8'), dateStamp)
kRegion = sign(kDate, regionName)
kService = sign(kRegion, serviceName)
kSigning = sign(kService, 'aws4_request')
return kSigning
# Read AWS access key from env. variables or configuration file. Best practice is NOT
# to embed credentials in code.
access_key = os.environ.get('AWS_ACCESS_KEY_ID')
secret_key = os.environ.get('AWS_SECRET_ACCESS_KEY')
if access_key is None or secret_key is None:
print('No access key is available.')
sys.exit()
# Create a date for headers and the credential string
t = datetime.datetime.utcnow()
amzdate = t.strftime('%Y%m%dT%H%M%SZ')
datestamp = t.strftime('%Y%m%d') # Date w/o time, used in credential scope
# ************* TASK 1: CREATE A CANONICAL REQUEST *************
# http://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
# Step 1 is to define the verb (GET, POST, etc.)--already done.
# Step 2: Create canonical URI--the part of the URI from domain to query
# string (use '/' if no path)
canonical_uri = '/latestidt'
# Step 3: Create the canonical query string. In this example (a GET request),
# request parameters are in the query string. Query string values must
# be URL-encoded (space=%20). The parameters must be sorted by name.
# For this example, the query string is pre-formatted in the request_parameters variable.
canonical_querystring = request_parameters
# Step 4: Create the canonical headers and signed headers. Header names
# must be trimmed and lowercase, and sorted in code point order from
# low to high. Note that there is a trailing \n.
canonical_headers = 'host:' + host + '\n' + 'x-amz-date:' + amzdate + '\n'
# Step 5: Create the list of signed headers. This lists the headers
# in the canonical_headers list, delimited with ";" and in alpha order.
# Note: The request can include any headers; canonical_headers and
# signed_headers lists those that you want to be included in the
# hash of the request. "Host" and "x-amz-date" are always required.
signed_headers = 'host;x-amz-date'
# Step 6: Create payload hash (hash of the request body content). For GET
# requests, the payload is an empty string ("").
payload_hash = hashlib.sha256(('').encode('utf-8')).hexdigest()
# Step 7: Combine elements to create canonical request
canonical_request = method + '\n' + canonical_uri + '\n' + canonical_querystring + '\n' + canonical_headers + '\n' + signed_headers + '\n' + payload_hash
# ************* TASK 2: CREATE THE STRING TO SIGN*************
# Match the algorithm to the hashing algorithm you use, either SHA-1 or
# SHA-256 (recommended)
algorithm = 'AWS4-HMAC-SHA256'
credential_scope = datestamp + '/' + region + '/' + service + '/' + 'aws4_request'
string_to_sign = algorithm + '\n' + amzdate + '\n' + credential_scope + '\n' + hashlib.sha256(canonical_request.encode('utf-8')).hexdigest()
# ************* TASK 3: CALCULATE THE SIGNATURE *************
# Create the signing key using the function defined above.
signing_key = getSignatureKey(secret_key, datestamp, region, service)
# Sign the string_to_sign using the signing_key
signature = hmac.new(signing_key, (string_to_sign).encode('utf-8'), hashlib.sha256).hexdigest()
# ************* TASK 4: ADD SIGNING INFORMATION TO THE REQUEST *************
# The signing information can be either in a query string value or in
# a header named Authorization. This code shows how to use a header.
# Create authorization header and add to request headers
authorization_header = algorithm + ' ' + 'Credential=' + access_key + '/' + credential_scope + ', ' + 'SignedHeaders=' + signed_headers + ', ' + 'Signature=' + signature
# The request can include any headers, but MUST include "host", "x-amz-date",
# and (for this scenario) "Authorization". "host" and "x-amz-date" must
# be included in the canonical_headers and signed_headers, as noted
# earlier. Order here is not significant.
# Python note: The 'host' header is added automatically by the Python 'requests' library.
headers = {'x-amz-date':amzdate, 'Authorization':authorization_header}
# ************* SEND THE REQUEST *************
request_url = endpoint + '?' + canonical_querystring
print('\nBEGIN REQUEST++++++++++++++++++++++++++++++++++++')
print('Request URL = ' + request_url)
response = requests.get(request_url, headers=headers)
print('\nRESPONSE++++++++++++++++++++++++++++++++++++')
print('Response code: %d\n' % response.status_code)
print(response.text)
download_url = response.json()["LatestBk"]["DownloadURL"]
r = requests.get(download_url)
open('devicetester.zip', 'wb').write(r.content)
```
# Verwenden Sie IDT, um die AWS IoT Greengrass Qualification Suite auszuführen
Sie können AWS IoT Device Tester für AWS IoT Greengrass V2 verwenden, um zu überprüfen, ob die AWS IoT Greengrass Core-Software auf Ihrer Hardware läuft und mit der AWS Cloud kommunizieren kann. Es führt auch end-to-end Tests mit durch AWS IoT Core. Es überprüft beispielsweise, ob Ihr Gerät Komponenten bereitstellen und aktualisieren kann.
IDT for AWS IoT Greengrass V2 testet nicht nur Geräte, sondern erstellt auch Ressourcen (z. B. AWS IoT Dinge, Gruppen usw.) in Ihrem System, um den AWS-Konto Qualifizierungsprozess zu erleichtern.
Um diese Ressourcen zu erstellen, verwendet IDT for AWS IoT Greengrass V2 die in der `config.json` Datei konfigurierten AWS Anmeldeinformationen, um API-Aufrufe in Ihrem Namen durchzuführen. Diese Ressourcen werden zu verschiedenen Zeiten während eines Tests bereitgestellt.
Wenn Sie IDT for AWS IoT Greengrass V2 verwenden, um die AWS IoT Greengrass Qualification Suite auszuführen, führt sie die folgenden Schritte aus:
1. Laden und überprüfen Sie die Konfiguration Ihres Geräts und Ihrer Anmeldeinformationen.
1. Führen Sie ausgewählte Tests mit den erforderlichen lokalen und Cloud-Ressourcen durch.
1. Bereinigen Sie lokale und Cloud-Ressourcen.
1. Erstellen Sie Testberichte, die anzeigen, ob Ihr Board die für die Qualifikation erforderlichen Tests bestanden hat.
## Test-Suite-Versionen
IDT for AWS IoT Greengrass V2 organisiert Tests in Testsuiten und Testgruppen.
+ Eine Testsuite ist der Satz von Testgruppen, die verwendet werden, um zu überprüfen, ob ein Gerät mit bestimmten Versionen von AWS IoT Greengrass funktioniert.
+ Eine Testgruppe besteht aus einzelnen Tests, die sich auf eine bestimmte Funktion beziehen, z. B. auf die Bereitstellung von Komponenten.
Testsuiten werden beispielsweise anhand eines `major.minor.patch` Formats versioniert. `GGV2Q_1.0.0` Wenn Sie IDT herunterladen, enthält das Paket die neueste Version der Greengrass Qualification Suite.
**Wichtig**
Tests von nicht unterstützten Testsuite-Versionen sind für die Gerätequalifizierung nicht gültig. IDT druckt keine Qualifizierungsberichte für nicht unterstützte Versionen. Weitere Informationen finden Sie unter [Unterstützungsrichtlinie AWS IoT Device Tester für AWS IoT Greengrass](idt-support-policy.md).
Sie können ausführen`list-supported-products`, um die Versionen von AWS IoT Greengrass und die Testsuiten aufzulisten, die von Ihrer aktuellen Version von IDT unterstützt werden.
## Beschreibung der Testgruppen
**Erforderliche Testgruppen für die Core-Qualifizierung**
Diese Testgruppen sind erforderlich, um Ihr AWS IoT Greengrass V2-Gerät für den AWS Partner Gerätekatalog zu qualifizieren.
Kernabhängigkeiten
Überprüft, ob das Gerät alle Software- und Hardwareanforderungen für die AWS IoT Greengrass Core-Software erfüllt. Diese Testgruppe umfasst den folgenden Testfall:
Java-Version
Überprüft, ob die erforderliche Java-Version auf dem zu testenden Gerät installiert ist. AWS IoT Greengrass benötigt Java 8 oder höher.
PreTest Validierung
Überprüft, ob das Gerät die Softwareanforderungen für die Durchführung von Tests erfüllt.
+ Bei Linux-basierten Geräten überprüft dieser Test, ob das Gerät die folgenden Linux-Befehle ausführen kann:
`chmod`, `cp`, `echo`, `grep`, `kill`, `ln`, `mkinfo`, `ps`, `rm`, `sh`, `uname`
+ Bei Windows-basierten Geräten überprüft dieser Test, ob auf dem Gerät die folgende Microsoft-Software installiert ist:
[Powershell](https://learn.microsoft.com/en-us/powershell/?view=powershell-7.1) [v5.1 oder höher, [.NET](https://learn.microsoft.com/en-us/dotnet/) v4.6.1 oder höher, [Visual C\$1\$1 2017 oder höher, Hilfsprogramm](https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170) PsExec](https://learn.microsoft.com/en-us/sysinternals/downloads/psexec)
Versionsprüfung
Überprüft, ob die AWS IoT Greengrass bereitgestellte Version mit der von Ihnen verwendeten AWS IoT Device Tester-Version kompatibel ist.
Komponente
Überprüft, ob das Gerät Komponenten bereitstellen und aktualisieren kann. Diese Testgruppe umfasst die folgenden Tests:
Cloud-Komponente
Überprüft die Gerätefähigkeit für Cloud-Komponenten.
Lokale Komponente
Überprüft die Gerätefähigkeit für lokale Komponenten.
Lambda
Dieser Test gilt nicht für Windows-basierte Geräte.
Überprüft, ob das Gerät Lambda-Funktionskomponenten bereitstellen kann, die die Java-Laufzeit verwenden, und ob die Lambda-Funktionen AWS IoT Core MQTT-Themen als Ereignisquellen für geschäftliche Nachrichten verwenden können.
MQTT
Überprüft, ob das Gerät MQTT-Themen abonnieren und veröffentlichen kann. AWS IoT Core
**Optionale Testgruppen**
Diese Testgruppen sind optional und werden nur für die Qualifizierung von Linux-basierten Greengrass-Core-Geräten verwendet. Wenn Sie sich für optionale Tests qualifizieren, wird Ihr Gerät mit zusätzlichen Funktionen im AWS Partner Gerätekatalog aufgeführt.
Docker-Abhängigkeiten
Überprüft, ob das Gerät alle erforderlichen technischen Abhängigkeiten erfüllt, um die von AWS-bereitgestellte Komponente Docker Application Manager () zu verwenden. `aws.greengrass.DockerApplicationManager`
Qualifikation für den Docker-Anwendungsmanager
Überprüft, ob das Gerät ein Docker-Container-Image von Amazon ECR herunterladen kann.
Abhängigkeiten Machine Learning
Die optionale Testgruppe für maschinelles Lernen wird nur in IDT v4.9.3 unterstützt.
Überprüft, ob das Gerät alle erforderlichen technischen Abhängigkeiten erfüllt, um die AWS bereitgestellten Komponenten für maschinelles Lernen (ML) verwenden zu können.
Inferenztests für Machine Learning
Die optionale Testgruppe für maschinelles Lernen wird nur in IDT v4.9.3 unterstützt.
[Überprüft, ob das Gerät mithilfe der [Deep Learning Runtime](https://github.com/neo-ai/neo-ai-dlr) - und Lite ML-Frameworks ML-Inferenz durchführen kann. TensorFlow ](https://www.tensorflow.org/lite/guide/python)
Stream Manager-Abhängigkeiten
Die optionale Testgruppe des Stream-Managers wird nur in IDT v4.9.3 unterstützt.
[Überprüft, ob das Gerät den Stream-Manager herunterladen, installieren und ausführen kann.AWS IoT Greengrass](manage-data-streams.md)
Integration von Hardware-Sicherheit (Hardware Security Integration, HSI)
Dieser Test ist in IDT v4.9.3 und höher nur für Linux-basierte Geräte verfügbar. AWS IoT Greengrass unterstützt derzeit keine Hardwaresicherheitsintegration für Windows-Geräte.
Überprüft, ob das Gerät Verbindungen zu den AWS IoT und AWS IoT Greengrass Diensten mithilfe eines privaten Schlüssels und Zertifikats authentifizieren kann, die in einem Hardware-Sicherheitsmodul (HSM) gespeichert sind. Mit diesem Test wird auch überprüft, ob die vom Hersteller AWS bereitgestellte [PKCS \$111 -Anbieterkomponente](pkcs11-provider-component.md) über eine vom Hersteller bereitgestellte PKCS \$111 -Bibliothek eine Schnittstelle zum HSM herstellen kann. Weitere Informationen finden Sie unter [Integration von Hardware-Sicherheit](hardware-security.md).
# Voraussetzungen für den Betrieb der AWS IoT Greengrass Qualification Suite
In diesem Abschnitt werden die Voraussetzungen für die Verwendung von AWS IoT Device Tester (IDT) für AWS IoT Greengrass beschrieben.
## 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.
## Laden Sie die Software herunter AWS IoT Greengrass
IDT for AWS IoT Greengrass V2 testet Ihr Gerät auf Kompatibilität mit einer bestimmten Version von AWS IoT Greengrass. Führen Sie den folgenden Befehl aus, um die AWS IoT Greengrass Core-Software in eine Datei mit dem Namen `aws.greengrass.nucleus.zip` herunterzuladen. *version*Ersetzen Sie Ihre [IDT-Version durch eine unterstützte Nucleus-Komponentenversion](dev-test-versions.md).
------
#### [ Linux or Unix ]
```
curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-version.zip > aws.greengrass.nucleus.zip
```
------
#### [ Windows Command Prompt (CMD) ]
```
curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-version.zip > aws.greengrass.nucleus.zip
```
------
#### [ PowerShell ]
```
iwr -Uri https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-version.zip -OutFile aws.greengrass.nucleus.zip
```
------
Platzieren Sie die heruntergeladene `aws.greengrass.nucleus.zip` Datei in dem `/products/` Ordner.
**Anmerkung**
Legen Sie nicht mehrere Dateien in diesem Verzeichnis für das gleiche Betriebssystem und die gleiche Architektur ab.
## Erstellen und konfigurieren Sie ein AWS-Konto
Bevor Sie AWS IoT Device Tester For AWS IoT Greengrass V2 verwenden können, müssen Sie die folgenden Schritte ausführen:
1. [Richten Sie eine ein AWS-Konto.](#create-aws-account-for-idt) Wenn Sie bereits eine haben AWS-Konto, fahren Sie mit Schritt 2 fort.
1. [Konfigurieren Sie die Berechtigungen für IDT.](#configure-idt-permissions)
Diese Kontoberechtigungen ermöglichen es IDT, in Ihrem Namen auf AWS Dienste zuzugreifen und AWS Ressourcen wie AWS IoT Dinge und AWS IoT Greengrass Komponenten zu erstellen.
Um diese Ressourcen zu erstellen, verwendet IDT for AWS IoT Greengrass V2 die in der `config.json` Datei konfigurierten AWS Anmeldeinformationen, um API-Aufrufe in Ihrem Namen durchzuführen. Diese Ressourcen werden zu verschiedenen Zeiten während eines Tests bereitgestellt.
**Anmerkung**
Obwohl die meisten Tests für das [AWS kostenlose Kontingent](https://aws.amazon.com/free) in Frage kommen, müssen Sie eine Kreditkarte angeben, wenn Sie sich für ein AWS-Konto kostenloses Kontingent anmelden. Weitere Informationen finden Sie unter [ Warum benötige ich eine Zahlungsmethode, wenn mein Konto vom kostenlosen Kontingent abgedeckt ist?](https://aws.amazon.com/premiumsupport/knowledge-center/free-tier-payment-method/).
### Schritt 1: Richten 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](#configure-idt-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 für AWS IoT Greengrass V2 verwendet, um Tests durchzuführen und IDT-Nutzungsdaten zu sammeln. Sie können das [AWS-Managementkonsole](#configure-idt-permissions-console)oder [AWS Command Line Interface (AWS CLI)](#configure-idt-permissions-cli) verwenden, um eine IAM-Richtlinie und einen Testbenutzer für IDT zu erstellen und dann Richtlinien an den Benutzer anzuhängen. Wenn Sie bereits einen Testbenutzer für IDT erstellt haben, fahren Sie mit fort. [Konfigurieren Sie Ihr Gerät für die Ausführung von IDT-Tests](device-config-setup.md)
#### So konfigurieren Sie Berechtigungen für IDT (Konsole)
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. Wenn Sie den Platzhalterinhalt nicht verwenden PreInstalled, ersetzen Sie auf der Registerkarte **JSON** den Platzhalterinhalt durch die folgende Richtlinie. Wenn Sie verwenden PreInstalled, fahren Sie mit dem folgenden Schritt fort.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/idt-*",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
},
{
"Sid":"lambdaResources",
"Effect":"Allow",
"Action":[
"lambda:CreateFunction",
"lambda:PublishVersion",
"lambda:DeleteFunction",
"lambda:GetFunction"
],
"Resource":[
"arn:aws:lambda:*:*:function:idt-*"
]
},
{
"Sid":"iotResources",
"Effect":"Allow",
"Action":[
"iot:CreateThing",
"iot:DeleteThing",
"iot:DescribeThing",
"iot:CreateThingGroup",
"iot:DeleteThingGroup",
"iot:DescribeThingGroup",
"iot:AddThingToThingGroup",
"iot:RemoveThingFromThingGroup",
"iot:AttachThingPrincipal",
"iot:DetachThingPrincipal",
"iot:UpdateCertificate",
"iot:DeleteCertificate",
"iot:CreatePolicy",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"iot:GetPolicy",
"iot:Publish",
"iot:TagResource",
"iot:ListThingPrincipals",
"iot:ListAttachedPolicies",
"iot:ListTargetsForPolicy",
"iot:ListThingGroupsForThing",
"iot:ListThingsInThingGroup",
"iot:CreateJob",
"iot:DescribeJob",
"iot:DescribeJobExecution",
"iot:CancelJob"
],
"Resource":[
"arn:aws:iot:*:*:thing/idt-*",
"arn:aws:iot:*:*:thinggroup/idt-*",
"arn:aws:iot:*:*:policy/idt-*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:topic/idt-*",
"arn:aws:iot:*:*:job/*"
]
},
{
"Sid":"s3Resources",
"Effect":"Allow",
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:CreateBucket",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:DeleteBucket",
"s3:PutObjectTagging",
"s3:PutBucketTagging"
],
"Resource":"arn:aws:s3::*:idt-*"
},
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/idt-*",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid":"idtExecuteAndCollectMetrics",
"Effect":"Allow",
"Action":[
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource":"*"
},
{
"Sid":"genericResources",
"Effect":"Allow",
"Action":[
"greengrass:*",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"iot:ListThings",
"iot:DescribeEndpoint",
"iot:CreateKeysAndCertificate"
],
"Resource":"*"
},
{
"Sid":"iamResourcesUpdate",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:DeleteRole",
"iam:CreatePolicy",
"iam:DeletePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:TagRole",
"iam:TagPolicy",
"iam:GetPolicy",
"iam:ListAttachedRolePolicies",
"iam:ListEntitiesForPolicy"
],
"Resource":[
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:policy/idt-*"
]
}
]
}
```
1. Wenn Sie verwenden PreInstalled, ersetzen Sie auf der Registerkarte **JSON** den Platzhalterinhalt durch die folgende Richtlinie. Stellen Sie sicher, dass Sie:
+ Ersetzen Sie *thingName* und *thingGroup* in der `iotResources` Anweisung durch den Dingnamen und die Dinggruppe, die während der Greengrass-Installation auf Ihrem zu testenden Gerät (DUT) erstellt wurden, um Berechtigungen hinzuzufügen.
+ Ersetzen Sie das *passRole* und *roleAlias* in der `roleAliasResources` Anweisung und der `passRoleForResources` Anweisung durch die Rollen, die während der Greengrass-Installation auf Ihrem DUT erstellt wurden.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/passRole",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
},
{
"Sid":"lambdaResources",
"Effect":"Allow",
"Action":[
"lambda:CreateFunction",
"lambda:PublishVersion",
"lambda:DeleteFunction",
"lambda:GetFunction"
],
"Resource":[
"arn:aws:lambda:*:*:function:idt-*"
]
},
{
"Sid":"iotResources",
"Effect":"Allow",
"Action":[
"iot:CreateThing",
"iot:DeleteThing",
"iot:DescribeThing",
"iot:CreateThingGroup",
"iot:DeleteThingGroup",
"iot:DescribeThingGroup",
"iot:AddThingToThingGroup",
"iot:RemoveThingFromThingGroup",
"iot:AttachThingPrincipal",
"iot:DetachThingPrincipal",
"iot:UpdateCertificate",
"iot:DeleteCertificate",
"iot:CreatePolicy",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"iot:GetPolicy",
"iot:Publish",
"iot:TagResource",
"iot:ListThingPrincipals",
"iot:ListAttachedPolicies",
"iot:ListTargetsForPolicy",
"iot:ListThingGroupsForThing",
"iot:ListThingsInThingGroup",
"iot:CreateJob",
"iot:DescribeJob",
"iot:DescribeJobExecution",
"iot:CancelJob"
],
"Resource":[
"arn:aws:iot:*:*:thing/thingName",
"arn:aws:iot:*:*:thinggroup/thingGroup",
"arn:aws:iot:*:*:policy/idt-*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:topic/idt-*",
"arn:aws:iot:*:*:job/*"
]
},
{
"Sid":"s3Resources",
"Effect":"Allow",
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:CreateBucket",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:DeleteBucket",
"s3:PutObjectTagging",
"s3:PutBucketTagging"
],
"Resource":"arn:aws:s3::*:idt-*"
},
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/roleAlias",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid":"idtExecuteAndCollectMetrics",
"Effect":"Allow",
"Action":[
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource":"*"
},
{
"Sid":"genericResources",
"Effect":"Allow",
"Action":[
"greengrass:*",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"iot:ListThings",
"iot:DescribeEndpoint",
"iot:CreateKeysAndCertificate"
],
"Resource":"*"
},
{
"Sid":"iamResourcesUpdate",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:DeleteRole",
"iam:CreatePolicy",
"iam:DeletePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:TagRole",
"iam:TagPolicy",
"iam:GetPolicy",
"iam:ListAttachedRolePolicies",
"iam:ListEntitiesForPolicy"
],
"Resource":[
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:policy/idt-*"
]
}
]
}
```
**Anmerkung**
Wenn Sie eine [benutzerdefinierte IAM-Rolle als Token-Austauschrolle](set-config.md#custom-token-exchange-role-idt) für Ihr zu testendes Gerät verwenden möchten, stellen Sie sicher, dass Sie die `roleAliasResources` Erklärung und die `passRoleForResources` Anweisung in Ihrer Richtlinie aktualisieren, um Ihre benutzerdefinierte IAM-Rollenressource zuzulassen.
1. Wählen Sie **Richtlinie prüfen**.
1. Geben Sie unter **Name** **IDTGreengrassIAMPermissions** 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 fügen Sie die von IDT erforderlichen Berechtigungen für hinzu. AWS IoT Greengrass
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*.
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 **IDTGreengrassIAMPermissions**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.
1. Nächster Schritt: Konfigurieren Sie Ihr [physisches Gerät](device-config-setup.md).
#### So konfigurieren Sie Berechtigungen für IDT (AWS CLI)
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 eine vom Kunden verwaltete Richtlinie, die Berechtigungen zum Verwalten von IDT- und AWS IoT Greengrass -Rollen erteilt.
1. Wenn Sie es nicht verwenden PreInstalled, öffnen Sie einen Texteditor und speichern Sie den folgenden Richtlinieninhalt in einer JSON-Datei. Wenn Sie dies verwenden PreInstalled, fahren Sie mit dem folgenden Schritt fort.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/idt-*",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
},
{
"Sid":"lambdaResources",
"Effect":"Allow",
"Action":[
"lambda:CreateFunction",
"lambda:PublishVersion",
"lambda:DeleteFunction",
"lambda:GetFunction"
],
"Resource":[
"arn:aws:lambda:*:*:function:idt-*"
]
},
{
"Sid":"iotResources",
"Effect":"Allow",
"Action":[
"iot:CreateThing",
"iot:DeleteThing",
"iot:DescribeThing",
"iot:CreateThingGroup",
"iot:DeleteThingGroup",
"iot:DescribeThingGroup",
"iot:AddThingToThingGroup",
"iot:RemoveThingFromThingGroup",
"iot:AttachThingPrincipal",
"iot:DetachThingPrincipal",
"iot:UpdateCertificate",
"iot:DeleteCertificate",
"iot:CreatePolicy",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"iot:GetPolicy",
"iot:Publish",
"iot:TagResource",
"iot:ListThingPrincipals",
"iot:ListAttachedPolicies",
"iot:ListTargetsForPolicy",
"iot:ListThingGroupsForThing",
"iot:ListThingsInThingGroup",
"iot:CreateJob",
"iot:DescribeJob",
"iot:DescribeJobExecution",
"iot:CancelJob"
],
"Resource":[
"arn:aws:iot:*:*:thing/idt-*",
"arn:aws:iot:*:*:thinggroup/idt-*",
"arn:aws:iot:*:*:policy/idt-*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:topic/idt-*",
"arn:aws:iot:*:*:job/*"
]
},
{
"Sid":"s3Resources",
"Effect":"Allow",
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:CreateBucket",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:DeleteBucket",
"s3:PutObjectTagging",
"s3:PutBucketTagging"
],
"Resource":"arn:aws:s3::*:idt-*"
},
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/idt-*",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid":"idtExecuteAndCollectMetrics",
"Effect":"Allow",
"Action":[
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource":"*"
},
{
"Sid":"genericResources",
"Effect":"Allow",
"Action":[
"greengrass:*",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"iot:ListThings",
"iot:DescribeEndpoint",
"iot:CreateKeysAndCertificate"
],
"Resource":"*"
},
{
"Sid":"iamResourcesUpdate",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:DeleteRole",
"iam:CreatePolicy",
"iam:DeletePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:TagRole",
"iam:TagPolicy",
"iam:GetPolicy",
"iam:ListAttachedRolePolicies",
"iam:ListEntitiesForPolicy"
],
"Resource":[
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:policy/idt-*"
]
}
]
}
```
1. Wenn Sie verwenden PreInstalled, öffnen Sie einen Texteditor und speichern Sie den folgenden Richtlinieninhalt in einer JSON-Datei. Stellen Sie sicher, dass Sie:
+ Ersetzen Sie *thingName* und *thingGroup* in der `iotResources` Anweisung, die während der Greengrass-Installation auf Ihrem zu testenden Gerät (DUT) erstellt wurden, um Berechtigungen hinzuzufügen.
+ Ersetzen Sie das *passRole* und *roleAlias* in der `roleAliasResources` Anweisung und der `passRoleForResources` Anweisung durch die Rollen, die während der Greengrass-Installation auf Ihrem DUT erstellt wurden.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/passRole",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
},
{
"Sid":"lambdaResources",
"Effect":"Allow",
"Action":[
"lambda:CreateFunction",
"lambda:PublishVersion",
"lambda:DeleteFunction",
"lambda:GetFunction"
],
"Resource":[
"arn:aws:lambda:*:*:function:idt-*"
]
},
{
"Sid":"iotResources",
"Effect":"Allow",
"Action":[
"iot:CreateThing",
"iot:DeleteThing",
"iot:DescribeThing",
"iot:CreateThingGroup",
"iot:DeleteThingGroup",
"iot:DescribeThingGroup",
"iot:AddThingToThingGroup",
"iot:RemoveThingFromThingGroup",
"iot:AttachThingPrincipal",
"iot:DetachThingPrincipal",
"iot:UpdateCertificate",
"iot:DeleteCertificate",
"iot:CreatePolicy",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"iot:GetPolicy",
"iot:Publish",
"iot:TagResource",
"iot:ListThingPrincipals",
"iot:ListAttachedPolicies",
"iot:ListTargetsForPolicy",
"iot:ListThingGroupsForThing",
"iot:ListThingsInThingGroup",
"iot:CreateJob",
"iot:DescribeJob",
"iot:DescribeJobExecution",
"iot:CancelJob"
],
"Resource":[
"arn:aws:iot:*:*:thing/thingName",
"arn:aws:iot:*:*:thinggroup/thingGroup",
"arn:aws:iot:*:*:policy/idt-*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:topic/idt-*",
"arn:aws:iot:*:*:job/*"
]
},
{
"Sid":"s3Resources",
"Effect":"Allow",
"Action":[
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:CreateBucket",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:DeleteBucket",
"s3:PutObjectTagging",
"s3:PutBucketTagging"
],
"Resource":"arn:aws:s3::*:idt-*"
},
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/roleAlias",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid":"idtExecuteAndCollectMetrics",
"Effect":"Allow",
"Action":[
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource":"*"
},
{
"Sid":"genericResources",
"Effect":"Allow",
"Action":[
"greengrass:*",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"iot:ListThings",
"iot:DescribeEndpoint",
"iot:CreateKeysAndCertificate"
],
"Resource":"*"
},
{
"Sid":"iamResourcesUpdate",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:DeleteRole",
"iam:CreatePolicy",
"iam:DeletePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:TagRole",
"iam:TagPolicy",
"iam:GetPolicy",
"iam:ListAttachedRolePolicies",
"iam:ListEntitiesForPolicy"
],
"Resource":[
"arn:aws:iam::*:role/idt-*",
"arn:aws:iam::*:policy/idt-*"
]
}
]
}
```
**Anmerkung**
Wenn Sie eine [benutzerdefinierte IAM-Rolle als Token-Austauschrolle](set-config.md#custom-token-exchange-role-idt) für Ihr zu testendes Gerät verwenden möchten, stellen Sie sicher, dass Sie die `roleAliasResources` Erklärung und die `passRoleForResources` Anweisung in Ihrer Richtlinie aktualisieren, um Ihre benutzerdefinierte IAM-Rollenressource zuzulassen.
1. Führen Sie den folgenden Befehl aus, um eine vom Kunden verwaltete Richtlinie mit dem Namen zu erstellen. `IDTGreengrassIAMPermissions` `policy.json`Ersetzen Sie durch den vollständigen Pfad zur JSON-Datei, die Sie im vorherigen Schritt erstellt haben.
```
aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document file://policy.json
```
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. In diesem Beispiel wird der Benutzer als `IDTGreengrassUser` bezeichnet.
```
aws iam create-user --user-name IDTGreengrassUser
```
1. Hängen Sie die in Schritt 2 erstellte `IDTGreengrassIAMPermissions` Richtlinie an Ihren IAM-Benutzer an. Ersetzen Sie ** den Befehl durch die ID Ihres AWS-Konto.
```
aws iam attach-user-policy --user-name IDTGreengrassUser --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 IDTGreengrassUser
```
Speichern Sie die Ausgabe an einem sicheren Ort. Sie verwenden diese Informationen später, um Ihre AWS Anmeldeinformationsdatei zu konfigurieren.
1. Nächster Schritt: Konfigurieren Sie Ihr [physisches Gerät](device-config-setup.md).
### AWS IoT Device Tester Berechtigungen
In den folgenden Richtlinien werden AWS IoT Device Tester Berechtigungen beschrieben.
AWS IoT Device Tester benötigt diese Berechtigungen für Funktionen zur Versionsprüfung und automatischen Aktualisierung.
+ `iot-device-tester:SupportedVersion`
Erteilt die AWS IoT Device Tester Erlaubnis, die Liste der unterstützten Produkte, Testsuiten und IDT-Versionen abzurufen.
+ `iot-device-tester:LatestIdt`
AWS IoT Device Tester Erteilt die Erlaubnis, die neueste IDT-Version abzurufen, die zum Herunterladen verfügbar ist.
+ `iot-device-tester:CheckVersion`
AWS IoT Device Tester Erteilt die Erlaubnis, die Versionskompatibilität für IDT, Testsuiten und Produkte zu überprüfen.
+ `iot-device-tester:DownloadTestSuite`
AWS IoT Device Tester Erteilt die Erlaubnis zum Herunterladen von Updates für Testsuiten.
AWS IoT Device Tester verwendet außerdem die folgende Berechtigung für optionale Metrikberichte:
+ `iot-device-tester:SendMetrics`
Erteilt die Erlaubnis AWS , Metriken zur AWS IoT Device Tester internen Nutzung zu sammeln. Wenn diese Erlaubnis nicht erteilt wird, werden diese Messwerte nicht erfasst.
# Konfigurieren Sie Ihr Gerät für die Ausführung von IDT-Tests
Damit IDT Tests zur Gerätequalifizierung durchführen kann, müssen Sie Ihren Host-Computer für den Zugriff auf Ihr Gerät konfigurieren und Benutzerberechtigungen auf Ihrem Gerät konfigurieren.
## Installieren Sie Java auf dem Host-Computer
Ab IDT v4.2.0 AWS IoT Greengrass erfordern die optionalen Qualifikationstests für die Ausführung von Java.
Sie können Java Version 8 oder höher verwenden. Wir empfehlen, dass Sie die [Langzeit-Support-Versionen von Amazon Corretto](https://aws.amazon.com/corretto/) oder [OpenJDK](https://openjdk.java.net/) verwenden. Version 8 oder höher ist erforderlich..
## Konfigurieren des Host-Computers für den Zugriff auf das zu testende Gerät
IDT wird auf Ihrem Host-Computer ausgeführt und muss über SSH eine Verbindung mit Ihrem Gerät herstellen können. Es gibt zwei Möglichkeiten, IDT SSH-Zugriff auf Ihre zu testenden Geräte zu gewähren:
1. Befolgen Sie die Anweisungen hier, um ein SSH-Schlüsselpaar zu erstellen und Ihren Schlüssel zur Anmeldung bei Ihrem zu testenden Gerät ohne Angabe eines Passworts zu berechtigen.
1. Geben Sie einen Benutzernamen und ein Passwort für jedes Gerät in der Datei `device.json` an. Weitere Informationen finden Sie unter [Konfigurieren von device.json](set-config.md#device-config).
Sie können eine beliebige SSL-Implementierung verwenden, um einen SSH-Schlüssel zu erstellen. Die folgenden Anweisungen zeigen Ihnen, wie Sie [SSH-KEYGEN](https://www.ssh.com/ssh/keygen/) oder [Pu TTYgen](https://www.ssh.com/ssh/putty/windows/puttygen) (für Windows) verwenden. Wenn Sie eine andere SSL-Implementierung verwenden, lesen Sie die Dokumentation zu dieser Implementierung.
IDT verwendet SSH-Schlüssel, um sich bei Ihrem zu testenden Gerät zu authentifizieren.
**So erstellen Sie einen SSH-Schlüssel mit SSH-KEYGEN**
1. Erstellen Sie einen SSH-Schlüssel.
Sie können mit dem Open SSH-Befehl **ssh-keygen** ein SSH-Schlüsselpaar erstellen. Wenn Sie bereits ein SSH-Schlüsselpaar auf Ihrem Host-Computer haben, ist es eine bewährte Methode, ein SSH-Schlüsselpaar speziell für IDT zu erstellen. Auf diese Weise kann Ihr Host-Computer nach Abschluss des Tests keine Verbindung mehr zu Ihrem Gerät herstellen, ohne ein Passwort einzugeben. Außerdem können Sie den Zugriff auf das Remote-Gerät auf die Personen beschränken, die tatsächlich Zugriff benötigen.
**Anmerkung**
Windows verfügt nicht über einen installierten SSH-Client. Weitere Informationen zur Installation eines SSH-Clients unter Windows finden Sie unter [Herunterladen der SSH-Client-Software](https://www.ssh.com/ssh/#sec-Download-client-software).
Der Befehl **ssh-keygen** fordert Sie auf, einen Namen und Pfad zum Speichern des Schlüsselpaars einzugeben. Standardmäßig werden die Schlüsselpaardateien `id_rsa` (privater Schlüssel) und `id_rsa.pub` (öffentlicher Schlüssel) genannt. Unter macOS und Linux ist der Standard-Speicherort dieser Dateien `~/.ssh/`. Unter Windows ist der Standard-Speicherort `C:\Users\\.ssh`.
Wenn Sie dazu aufgefordert werden, geben Sie eine Schlüsselphrase zum Schutz Ihres SSH-Schlüssels ein. Weitere Informationen finden Sie unter [Generieren eines neuen SSH-Schlüssels](https://www.ssh.com/ssh/keygen/).
1. Fügen Sie autorisierte SSH-Schlüssel zu Ihrem zu testenden Gerät hinzu.
IDT muss Ihren privaten SSH-Schlüssel für die Anmeldung bei Ihrem zu testenden Gerät verwenden. Um Ihren privaten SSH-Schlüssel für die Anmeldung bei Ihrem zu testenden Gerät zu autorisieren, verwenden Sie den Befehl **ssh-copy-id** von Ihrem Host-Computer. Dieser Befehl fügt Ihren öffentlichen Schlüssel zur Datei `~/.ssh/authorized_keys` auf dem zu testenden Gerät hinzu. Beispiel:
**\$1 ssh-copy-id **@****
Wo *remote-ssh-user* wird der Benutzername verwendet, um sich auf Ihrem zu testenden Gerät anzumelden, und *remote-device-ip* ist die IP-Adresse des zu testenden Geräts, mit dem Tests durchgeführt werden sollen. Beispiel:
**ssh-copy-id pi@192.168.1.5**
Wenn Sie dazu aufgefordert werden, geben Sie das Passwort für den im Befehl **ssh-copy-id** angegebenen Benutzernamen ein.
**ssh-copy-id** geht davon aus, dass der öffentliche Schlüssel `id_rsa.pub` heißt und am Standard-Speicherort gespeichert ist (`~/.ssh/` in macOS und Linux und `C:\Users\\.ssh` in Windows). Wenn Sie dem öffentlichen Schlüssel einen anderen Namen gegeben oder ihn an einem anderen Ort gespeichert haben, müssen Sie den vollqualifizierten Pfad zu Ihrem öffentlichen SSH-Schlüssel mit der Option **-i** zu **ssh-copy-id** (z. B. **ssh-copy-id -i \$1/my/path/myKey.pub**) angeben. Weitere Informationen zum Erstellen von SSH-Schlüsseln und Kopieren von öffentlichen Schlüsseln finden Sie unter [SSH-COPY-ID](https://www.ssh.com/ssh/copy-id).
**Um einen SSH-Schlüssel mit Pu zu erstellen TTYgen (nur Windows)**
1. Stellen Sie sicher, dass der OpenSSH-Server und -Client auf Ihrem zu testenden Gerät installiert sind. Weitere Informationen finden Sie unter [OpenSSH](https://www.openssh.com/).
1. Installieren Sie [Pu TTYgen](https://www.puttygen.com/) auf Ihrem zu testenden Gerät.
1. Öffnen Sie PuTTYgen.
1. Wählen Sie **Generate (Generieren)** aus und bewegen Sie den Mauszeiger in das Feld, um einen privaten Schlüssel zu generieren.
1. Wählen Sie im Menü **Conversions (Konvertierungen)** die Option **Export OpenSSH key (OpenSSH-Schlüssel exportieren)** aus und speichern Sie den privaten Schlüssel mit der Dateierweiterung `.pem`.
1. Fügen Sie den öffentlichen Schlüssel der Datei `/home//.ssh/authorized_keys` auf dem zu testenden Gerät hinzu.
1. Kopieren Sie den Text des öffentlichen Schlüssels aus dem TTYgen Pu-Fenster.
1. Verwenden Sie PuTTY, um eine Sitzung auf Ihrem zu testenden Gerät zu erstellen.
1. Führen Sie in einer Eingabeaufforderung oder einem Windows Powershell-Fenster den folgenden Befehl aus:
**C:/**/putty.exe -ssh **@** **
1. Wenn Sie dazu aufgefordert werden, geben Sie das Passwort Ihres Geräts ein.
1. Verwenden Sie vi oder einen anderen Texteditor, um den öffentlichen Schlüssel an die Datei `/home//.ssh/authorized_keys` auf Ihrem zu testenden Gerät anzuhängen.
1. Aktualisieren Sie die Datei `device.json` mit Ihrem Benutzernamen, der IP-Adresse und dem Pfad zur Datei mit dem privaten Schlüssel, die Sie gerade auf Ihrem Host-Computer für jedes zu testende Gerät gespeichert haben. Weitere Informationen finden Sie unter [Konfigurieren von device.json](set-config.md#device-config). Stellen Sie sicher, dass Sie den vollständigen Pfad und Dateinamen für den privaten Schlüssel angeben und Schrägstriche ('/') verwenden. Verwenden Sie beispielsweise für den Windows-Pfad `C:\DT\privatekey.pem` die Angabe `C:/DT/privatekey.pem` in der Datei `device.json`.
## Konfigurieren Sie Benutzeranmeldeinformationen für Windows-Geräte
Um ein Windows-basiertes Gerät zu qualifizieren, müssen Sie Benutzeranmeldeinformationen im LocalSystem Konto auf dem zu testenden Gerät für die folgenden Benutzer konfigurieren:
+ Der Standard-Greengrass-Benutzer (`ggc_user`).
+ Der Benutzer, mit dem Sie eine Verbindung zu dem zu testenden Gerät herstellen. Sie konfigurieren diesen Benutzer in der [`device.json`Datei](set-config.md#device-config).
Sie müssen jeden Benutzer im LocalSystem Konto auf dem zu testenden Gerät erstellen und dann den Benutzernamen und das Passwort für den Benutzer in der Credential Manager-Instanz für das LocalSystem Konto speichern.
**Um Benutzer auf Windows-Geräten zu konfigurieren**
1. Öffnen Sie die Windows-Eingabeaufforderung (`cmd.exe`) als Administrator.
1. Erstellen Sie die Benutzer im LocalSystem Konto auf dem Windows-Gerät. Führen Sie den folgenden Befehl für jeden Benutzer aus, den Sie erstellen möchten. Ersetzen Sie für den Standardbenutzer von Greengrass *user-name* durch`ggc_user`. *password*Durch ein sicheres Passwort ersetzen.
```
net user /add user-name password
```
1. Laden Sie das [PsExecProgramm](https://docs.microsoft.com/en-us/sysinternals/downloads/psexec) von Microsoft herunter und installieren Sie es auf dem Gerät.
1. Verwenden Sie das PsExec Hilfsprogramm, um den Benutzernamen und das Passwort für den Standardbenutzer in der Credential Manager-Instanz für das LocalSystem Konto zu speichern.
Führen Sie den folgenden Befehl für jeden Benutzer aus, den Sie in Credential Manager konfigurieren möchten. Ersetzen Sie für den Standardbenutzer von Greengrass *user-name* durch`ggc_user`. *password*Ersetzen Sie es durch das Passwort des Benutzers, das Sie zuvor festgelegt haben.
```
psexec -s cmd /c cmdkey /generic:user-name /user:user-name /pass:password
```
Wenn das **PsExec License Agreement**geöffnet wird, stimmen Sie **Accept**der Lizenz zu und führen Sie den Befehl aus.
**Anmerkung**
Auf Windows-Geräten wird auf dem LocalSystem Konto der Greengrass-Nucleus ausgeführt, und Sie müssen das PsExec Hilfsprogramm verwenden, um Benutzerinformationen im LocalSystem Konto zu speichern. Wenn Sie die Credential Manager-Anwendung verwenden, werden diese Informationen nicht im Konto, sondern im Windows-Konto des aktuell angemeldeten Benutzers gespeichert. LocalSystem
## Konfigurieren von Benutzerberechtigungen auf Ihrem Gerät
IDT führt Operationen für verschiedene Verzeichnisse und Dateien auf einem zu testenden Gerät aus. Einige dieser Operationen erfordern höhere Berechtigungen (mit **sudo**). Um diese Vorgänge zu automatisieren, muss IDT für AWS IoT Greengrass V2 in der Lage sein, Befehle mit sudo auszuführen, ohne nach einem Passwort gefragt zu werden.
Führen Sie die folgenden Schritte auf dem zu testenden Gerät aus, um sudo den Zugriff ohne Aufforderung zur Eingabe eines Passworts zu erlauben.
**Anmerkung**
`username` bezieht sich auf den SSH-Benutzer, der von IDT für den Zugriff auf das zu testende Gerät verwendet wird.
**So fügen Sie den Benutzer der sudo-Gruppe hinzu**
1. Führen Sie auf dem zu testenden Gerät `sudo usermod -aG sudo ` aus.
1. Melden Sie sich ab und melden Sie sich dann wieder an, damit die Änderungen wirksam werden.
1. Führen Sie **sudo echo test** aus, um zu überprüfen, ob der Benutzername erfolgreich hinzugefügt wurde. Wenn Sie nicht zur Eingabe eines Passworts aufgefordert werden, ist Ihr Benutzer korrekt konfiguriert.
1. Öffnen Sie die Datei `/etc/sudoers` und fügen Sie am Ende der Datei die folgende Zeile hinzu:
` ALL=(ALL) NOPASSWD: ALL`
## Konfigurieren Sie eine benutzerdefinierte Token-Austauschrolle
Sie können eine benutzerdefinierte IAM-Rolle als Token-Austauschrolle verwenden, die das getestete Gerät für die Interaktion mit AWS Ressourcen annimmt. Informationen zum Erstellen einer IAM-Rolle finden Sie unter [Erstellen von IAM-Rollen im *IAM-Benutzerhandbuch*](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html).
Sie müssen die folgenden Anforderungen erfüllen, damit IDT Ihre benutzerdefinierte IAM-Rolle verwenden kann. Wir empfehlen dringend, dieser Rolle nur die minimal erforderlichen Richtlinienaktionen hinzuzufügen.
+ Die Konfigurationsdatei [userdata.json](set-config.md#custom-token-exchange-role-idt) muss aktualisiert werden, um den `GreengrassV2TokenExchangeRole` Parameter auf zu setzen. `true`
+ Die benutzerdefinierte IAM-Rolle muss mit der folgenden Mindestvertrauensrichtlinie konfiguriert werden:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":[
"credentials.iot.amazonaws.com",
"lambda.amazonaws.com",
"sagemaker.amazonaws.com"
]
},
"Action":"sts:AssumeRole"
}
]
}
```
------
+ Die benutzerdefinierte IAM-Rolle muss mit der folgenden Mindestberechtigungsrichtlinie konfiguriert werden:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"iot:DescribeCertificate",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams",
"iot:Connect",
"iot:Publish",
"iot:Subscribe",
"iot:Receive",
"iot:ListThingPrincipals",
"iot:GetThingShadow",
"iot:UpdateThingShadow",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Resource":"*"
}
]
}
```
------
+ Der Name der benutzerdefinierten IAM-Rolle muss mit der IAM-Rollenressource übereinstimmen, die Sie in den IAM-Berechtigungen für den Testbenutzer angeben. Standardmäßig ermöglicht die [Testbenutzerrichtlinie](dev-tst-prereqs.md#configure-idt-permissions) den Zugriff auf IAM-Rollen, deren Rollennamen das `idt-` Präfix enthalten. Wenn Ihr IAM-Rollenname dieses Präfix nicht verwendet, fügen Sie die `arn:aws:iam::*:role/custom-iam-role-name` Ressource der `roleAliasResources` Anweisung und der `passRoleForResources` Anweisung in Ihrer Testbenutzerrichtlinie hinzu, wie in den folgenden Beispielen gezeigt:
**Example `passRoleForResources`-Anweisung**
```
{
"Sid":"passRoleForResources",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::*:role/custom-iam-role-name",
"Condition":{
"StringEquals":{
"iam:PassedToService":[
"iot.amazonaws.com",
"lambda.amazonaws.com",
"greengrass.amazonaws.com"
]
}
}
}
```
**Example `roleAliasResources`-Anweisung**
```
{
"Sid":"roleAliasResources",
"Effect":"Allow",
"Action":[
"iot:CreateRoleAlias",
"iot:DescribeRoleAlias",
"iot:DeleteRoleAlias",
"iot:TagResource",
"iam:GetRole"
],
"Resource":[
"arn:aws:iot:*:*:rolealias/idt-*",
"arn:aws:iam::*:role/custom-iam-role-name"
]
}
```
## Konfigurieren Ihres Geräts zum Testen optionaler Funktionen
In diesem Abschnitt werden die Geräteanforderungen für die Ausführung von IDT-Tests für optionale Docker- und ML-Funktionen (Machine Learning) beschrieben. Die ML-Funktionen werden nur in IDT v4.9.3 unterstützt. Sie müssen sicherstellen, dass Ihr Gerät diese Anforderungen nur erfüllt, wenn Sie diese Funktionen testen möchten. Fahren Sie andernfalls mit dem Schritt [Konfigurieren Sie die IDT-Einstellungen, um die AWS IoT Greengrass Qualification Suite auszuführen](set-config.md) fort.
**Topics**
+ [Anforderungen an die Docker-Qualifikation](#idt-config-docker-components)
+ [Anforderungen an die ML-Qualifikation](#idt-config-ml-components)
+ [HSM-Qualifikationsanforderungen](#idt-config-hsm-components)
### Anforderungen an die Docker-Qualifikation
IDT für AWS IoT Greengrass V2 bietet Docker-Qualifizierungstests, um zu überprüfen, ob Ihre Geräte die von Ihnen AWS bereitgestellte [Docker-Anwendungsmanager-Komponente zum Herunterladen von Docker-Container-Images](docker-application-manager-component.md) verwenden können, die Sie mit benutzerdefinierten Docker-Container-Komponenten ausführen können. Informationen zum Erstellen benutzerdefinierter Docker-Komponenten finden Sie unter. [Führen Sie einen Docker-Container aus](run-docker-container.md)
Um Docker-Qualifizierungstests ausführen zu können, müssen Ihre getesteten Geräte die folgenden Anforderungen erfüllen, um die Docker Application Manager-Komponente bereitstellen zu können.
+ [Docker Engine](https://docs.docker.com/engine/) 1.9.1 oder höher ist auf dem Greengrass-Core-Gerät installiert. Version 20.10 ist die neueste Version, für die verifiziert wurde, dass sie mit der Core-Software funktioniert. AWS IoT Greengrass Sie müssen Docker direkt auf dem Kerngerät installieren, bevor Sie Komponenten bereitstellen, auf denen Docker-Container ausgeführt werden.
+ Der Docker-Daemon wurde auf dem Kerngerät gestartet und ausgeführt, bevor Sie diese Komponente bereitstellen.
+ Der Systembenutzer, der eine Docker-Container-Komponente ausführt, muss über Root- oder Administratorrechte verfügen, oder Sie müssen Docker so konfigurieren, dass es als Benutzer ohne Root- oder Administratorrechte ausgeführt wird.
+ Auf Linux-Geräten können Sie der Gruppe einen Benutzer hinzufügen, um Befehle ohne Befehle `docker` aufzurufen. `docker` `sudo`
+ Auf Windows-Geräten können Sie der `docker-users` Gruppe einen Benutzer hinzufügen, um `docker` Befehle ohne Administratorrechte aufzurufen.
------
#### [ Linux or Unix ]
Führen Sie den folgenden Befehl aus`ggc_user`, um der `docker` Gruppe einen Nicht-Root-Benutzer, den Sie zum Ausführen von Docker-Container-Komponenten verwenden, hinzuzufügen.
```
sudo usermod -aG docker ggc_user
```
Weitere Informationen finden Sie unter [Docker als Nicht-Root-Benutzer verwalten](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user).
------
#### [ Windows Command Prompt (CMD) ]
Um der `docker-users` Gruppe den Benutzer`ggc_user`, den Sie zum Ausführen von Docker-Container-Komponenten verwenden, hinzuzufügen, führen Sie den folgenden Befehl als Administrator aus.
```
net localgroup docker-users ggc_user /add
```
------
#### [ Windows PowerShell ]
Um der `docker-users` Gruppe den Benutzer`ggc_user`, den Sie zum Ausführen von Docker-Container-Komponenten verwenden, hinzuzufügen, führen Sie den folgenden Befehl als Administrator aus.
```
Add-LocalGroupMember -Group docker-users -Member ggc_user
```
------
### Anforderungen an die ML-Qualifikation
**Anmerkung**
Die Funktion für maschinelles Lernen wird nur in IDT v4.9.3 unterstützt.
[IDT for AWS IoT Greengrass V2 bietet ML-Qualifizierungstests, um zu überprüfen, ob Ihre Geräte die AWS bereitgestellten [maschinellen Lernkomponenten verwenden können, um ML-Inferenzen lokal mithilfe der [Deep Learning](https://github.com/neo-ai/neo-ai-dlr)](machine-learning-components.md) Runtime- oder Lite ML-Frameworks durchzuführen. TensorFlow ](https://www.tensorflow.org/lite/guide/python) Weitere Informationen zur Ausführung von ML-Inferenz auf Greengrass-Geräten finden Sie unter. [Durchführen von Machine Learning-Inferenzen](perform-machine-learning-inference.md)
Um ML-Qualifizierungstests durchführen zu können, müssen Ihre getesteten Geräte die folgenden Anforderungen erfüllen, um die Komponenten für maschinelles Lernen bereitstellen zu können.
+ Auf Greengrass-Core-Geräten, auf denen Amazon Linux 2 oder Ubuntu 18.04 ausgeführt wird, ist die [GNU C Library](https://www.gnu.org/software/libc/) (Glibc) Version 2.27 oder höher auf dem Gerät installiert.
+ Auf ARMv7L-Geräten wie Raspberry Pi sind Abhängigkeiten für OpenCV-Python auf dem Gerät installiert. Führen Sie den folgenden Befehl aus, um die Abhängigkeiten zu installieren.
```
sudo apt-get install libopenjp2-7 libilmbase23 libopenexr-dev libavcodec-dev libavformat-dev libswscale-dev libv4l-dev libgtk-3-0 libwebp-dev
```
+ Raspberry Pi-Geräte, auf denen Raspberry Pi OS Bullseye ausgeführt wird, müssen die folgenden Anforderungen erfüllen:
+ NumPy 1.22.4 oder höher auf dem Gerät installiert. Raspberry Pi OS Bullseye enthält eine frühere Version von NumPy, sodass Sie den folgenden Befehl ausführen können, um das Gerät zu aktualisieren NumPy .
```
pip3 install --upgrade numpy
```
+ Der ältere Kamerastack ist auf dem Gerät aktiviert. Raspberry Pi OS Bullseye enthält einen neuen Kamerastack, der standardmäßig aktiviert und nicht kompatibel ist. Sie müssen also den älteren Kamerastack aktivieren.
**Um den Legacy-Kamerastack zu aktivieren**
1. Führen Sie den folgenden Befehl aus, um das Raspberry Pi-Konfigurationstool zu öffnen.
```
sudo raspi-config
```
1. Wählen Sie **Schnittstellenoptionen**.
1. Wählen Sie **Legacy-Kamera** aus, um den Legacy-Kamerastack zu aktivieren.
1. Starten Sie den Raspberry Pi neu.
### HSM-Qualifikationsanforderungen
AWS IoT Greengrass stellt die [PKCS \$111 -Anbieterkomponente](pkcs11-provider-component.md) zur Integration in das PKCS Hardware Security Module (HSM) auf dem Gerät bereit. Das HSM-Setup hängt von Ihrem Gerät und dem HSM-Modul ab, das Sie ausgewählt haben. Solange die erwartete HSM-Konfiguration, wie in den [IDT-Konfigurationseinstellungen dokumentiert, bereitgestellt wird, verfügt IDT](set-config.md) über die Informationen, die für die Durchführung dieses optionalen Feature-Qualifizierungstests erforderlich sind.
# Konfigurieren Sie die IDT-Einstellungen, um die AWS IoT Greengrass Qualification Suite auszuführen
Bevor Sie Tests ausführen, müssen Sie Einstellungen für AWS Anmeldeinformationen und Geräte auf Ihrem Hostcomputer konfigurieren.
## Konfigurieren Sie die AWS Anmeldeinformationen in config.json
Sie müssen Ihre IAM-Benutzeranmeldedaten in der `/configs/config.json` Datei konfigurieren. Verwenden Sie die Anmeldeinformationen für den IDT for AWS IoT Greengrass V2-Benutzer, der in erstellt wurde. [Erstellen und konfigurieren Sie ein AWS-Konto](dev-tst-prereqs.md#config-aws-account-for-idt) Sie können Ihre Anmeldeinformationen auf zwei Arten angeben:
+ In einer Anmeldeinformationsdatei
+ Als Umgebungsvariablen
### Konfigurieren Sie AWS Anmeldeinformationen mit einer 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`
Fügen Sie der `credentials` Datei Ihre AWS Anmeldeinformationen im folgenden Format hinzu:
```
[default]
aws_access_key_id =
aws_secret_access_key =
```
Um IDT für AWS IoT Greengrass V2 so zu konfigurieren, dass AWS Anmeldeinformationen aus Ihrer `credentials` Datei verwendet werden, bearbeiten Sie Ihre `config.json` Datei wie folgt:
```
{
"awsRegion": "region",
"auth": {
"method": "file",
"credentials": {
"profile": "default"
}
}
}
```
**Anmerkung**
Wenn Sie das `default` AWS Profil nicht verwenden, ändern Sie unbedingt den Profilnamen in Ihrer `config.json` Datei. Weitere Informationen hierzu finden Sie unter [Benannte Profile](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html).
### Konfigurieren Sie AWS Anmeldeinformationen mit Umgebungsvariablen
Umgebungsvariablen sind Variablen, die vom Betriebssystem gepflegt und von Systembefehlen verwendet werden. Sie werden nicht gespeichert, wenn Sie die SSH-Sitzung schließen. IDT für AWS IoT Greengrass V2 kann die `AWS_SECRET_ACCESS_KEY` Umgebungsvariablen `AWS_ACCESS_KEY_ID` und zum Speichern Ihrer AWS Anmeldeinformationen verwenden.
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 den IDT so zu konfigurieren, dass er die Umgebungsvariablen verwendet, bearbeiten Sie den Abschnitt `auth` in Ihrer Datei `config.json`. Ein Beispiel:
```
{
"awsRegion": "region",
"auth": {
"method": "environment"
}
}
```
## Konfigurieren von device.json
**Anmerkung**
IDT v4.9.3 unterstützt das Testen der Funktionen`ml`, und`docker`. `streamManagement` IDT v4.9.4 und spätere Versionen unterstützen Tests. `docker` Wenn Sie diese Funktionen nicht testen möchten, setzen Sie den entsprechenden Wert auf. `no`
Zusätzlich zu den AWS Anmeldeinformationen benötigt IDT für AWS IoT Greengrass V2 Informationen über die Geräte, auf denen die Tests ausgeführt werden. Beispielinformationen wären IP-Adresse, Anmeldeinformationen, Betriebssystem und CPU-Architektur.
Sie müssen diese Informationen mittels der Vorlage `device.json` in ` /configs/device.json` angeben:
------
#### [ IDT v4.9.3 ]
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "arch",
"value": "x86_64 | armv6l | armv7l | aarch64"
},
{
"name": "ml",
"value": "dlr | tensorflowlite | dlr,tensorflowlite | no"
},
{
"name": "docker",
"value": "yes | no"
},
{
"name": "streamManagement",
"value": "yes | no"
},
{
"name": "hsi",
"value": "hsm | no"
}
],
"devices": [
{
"id": "",
"operatingSystem": "Linux | Windows",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": 22,
"publicKeyPath": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
**Anmerkung**
Geben Sie `privKeyPath` nur an, wenn `method` auf `pki` gesetzt ist.
Geben Sie `password` nur an, wenn `method` auf `password` gesetzt ist.
Alle Eigenschaften, die Werte enthalten, sind erforderlich, wie hier 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 Boards nachzuverfolgen.
Wenn Sie Ihr Gerät im AWS Partner Gerätekatalog anbieten möchten, muss die hier angegebene SKU mit der SKU übereinstimmen, die Sie bei der Angebotserstellung verwenden.
`features`
Ein Array, das die Funktionen enthält, die das Gerät unterstützt. Alle Funktionen sind erforderlich.
`arch`
Die unterstützten Betriebssystemarchitekturen, die durch den Testlauf validiert werden. Folgende sind gültige Werte:
+ `x86_64`
+ `armv6l`
+ `armv7l`
+ `aarch64`
`ml`
Überprüft, ob das Gerät alle erforderlichen technischen Abhängigkeiten erfüllt, um die AWS bereitgestellten Komponenten für maschinelles Lernen (ML) verwenden zu können.
Durch die Aktivierung dieser Funktion wird auch überprüft, ob das Gerät ML-Inferenz mithilfe der Frameworks [Deep Learning Runtime](https://github.com/neo-ai/neo-ai-dlr) und [TensorFlow Lite](https://www.tensorflow.org/lite/guide/python) ML durchführen kann.
Gültige Werte sind eine beliebige Kombination aus `dlr` und `tensorflowlite` oder. `no`
`docker`
Überprüft, ob das Gerät alle erforderlichen technischen Abhängigkeiten erfüllt, um die von AWS-bereitgestellte Docker-Anwendungsmanager () `aws.greengrass.DockerApplicationManager` -Komponente verwenden zu können.
Durch die Aktivierung dieser Funktion wird auch bestätigt, dass das Gerät ein Docker-Container-Image von Amazon ECR herunterladen kann.
Gültige Werte sind eine beliebige Kombination von oder. `yes` `no`
`streamManagement`
Überprüft, ob das Gerät den [AWS IoT Greengrass Stream-Manager](manage-data-streams.md) herunterladen, installieren und ausführen kann.
Gültige Werte sind eine beliebige Kombination von `yes` oder`no`.
`hsi`
Überprüft, ob das Gerät Verbindungen zu den AWS IoT und AWS IoT Greengrass Diensten mithilfe eines privaten Schlüssels und Zertifikats authentifizieren kann, die in einem Hardware-Sicherheitsmodul (HSM) gespeichert sind. Mit diesem Test wird auch überprüft, ob die vom Hersteller AWS bereitgestellte [PKCS \$111 -Anbieterkomponente](pkcs11-provider-component.md) über eine vom Hersteller bereitgestellte PKCS \$111 -Bibliothek eine Schnittstelle zum HSM herstellen kann. Weitere Informationen finden Sie unter [Integration von Hardware-Sicherheit](hardware-security.md).
Gültige Werte sind `hsm` oder `no`.
Das Testen von `hsi` ist nur mit IDT v4.9.3 und späteren Versionen verfügbar.
`devices.id`
Eine benutzerdefinierte eindeutige Kennung für das zu testende Gerät.
`devices.operatingSystem`
Das Betriebssystem des Geräts. Unterstützte Werte sind `Linux` und `Windows`.
`connectivity.protocol`
Das Kommunikationsprotokoll, das für die Kommunikation mit diesem Gerät verwendet wird. Derzeit gilt der einzige unterstützte Wert `ssh` für physische Geräte.
`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.publicKeyPath`
Optional. Der vollständige Pfad zum öffentlichen Schlüssel, der zur Authentifizierung von Verbindungen mit dem zu testenden Gerät verwendet wird.
Wenn Sie das angeben`publicKeyPath`, validiert IDT den öffentlichen Schlüssel des Geräts, wenn es eine SSH-Verbindung zu dem zu testenden Gerät herstellt. Wenn dieser Wert nicht angegeben ist, stellt IDT eine SSH-Verbindung her, validiert aber nicht den öffentlichen Schlüssel des Geräts.
Wir empfehlen dringend, dass Sie den Pfad zum öffentlichen Schlüssel angeben und eine sichere Methode verwenden, um diesen öffentlichen Schlüssel abzurufen. Für standardmäßige SSH-Clients, die auf der Befehlszeile basieren, wird der öffentliche Schlüssel in der Datei bereitgestellt. `known_hosts` Wenn Sie eine separate öffentliche Schlüsseldatei angeben, muss diese Datei dasselbe Format wie die `known_hosts` Datei verwenden, d. h.. ` ip-address key-type public-key` Wenn es mehrere Einträge mit derselben IP-Adresse gibt, muss der Eintrag für den von IDT verwendeten Schlüsseltyp vor den anderen Einträgen in der Datei stehen.
`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.
------
#### [ IDT v4.9.4 ]
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "arch",
"value": "x86_64 | armv6l | armv7l | aarch64"
},
{
"name": "docker",
"value": "yes | no"
},
{
"name": "hsi",
"value": "hsm | no"
}
],
"devices": [
{
"id": "",
"operatingSystem": "Linux | Windows",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": 22,
"publicKeyPath": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
**Anmerkung**
Geben Sie `privKeyPath` nur an, wenn `method` auf `pki` gesetzt ist.
Geben Sie `password` nur an, wenn `method` auf `password` gesetzt ist.
Alle Eigenschaften, die Werte enthalten, sind erforderlich, wie hier 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 Boards nachzuverfolgen.
Wenn Sie Ihr Gerät im AWS Partner Gerätekatalog anbieten möchten, muss die hier angegebene SKU mit der SKU übereinstimmen, die Sie bei der Angebotserstellung verwenden.
`features`
Ein Array, das die Funktionen enthält, die das Gerät unterstützt. Alle Funktionen sind erforderlich.
`arch`
Die unterstützten Betriebssystemarchitekturen, die durch den Testlauf validiert werden. Folgende sind gültige Werte:
+ `x86_64`
+ `armv6l`
+ `armv7l`
+ `aarch64`
`docker`
Überprüft, ob das Gerät alle erforderlichen technischen Abhängigkeiten erfüllt, um die von ihm AWS bereitgestellte Komponente Docker Application Manager () zu verwenden. `aws.greengrass.DockerApplicationManager`
Durch die Aktivierung dieser Funktion wird auch bestätigt, dass das Gerät ein Docker-Container-Image von Amazon ECR herunterladen kann.
Gültige Werte sind eine beliebige Kombination von oder. `yes` `no`
`hsi`
Überprüft, ob das Gerät Verbindungen zu den AWS IoT und AWS IoT Greengrass Diensten mithilfe eines privaten Schlüssels und Zertifikats authentifizieren kann, die in einem Hardware-Sicherheitsmodul (HSM) gespeichert sind. Mit diesem Test wird auch überprüft, ob die vom Hersteller AWS bereitgestellte [PKCS \$111 -Anbieterkomponente](pkcs11-provider-component.md) über eine vom Hersteller bereitgestellte PKCS \$111 -Bibliothek eine Schnittstelle zum HSM herstellen kann. Weitere Informationen finden Sie unter [Integration von Hardware-Sicherheit](hardware-security.md).
Gültige Werte sind `hsm` oder `no`.
Das Testen von `hsi` ist nur mit IDT v4.9.3 und späteren Versionen verfügbar.
`devices.id`
Eine benutzerdefinierte eindeutige Kennung für das zu testende Gerät.
`devices.operatingSystem`
Das Betriebssystem des Geräts. Unterstützte Werte sind `Linux` und `Windows`.
`connectivity.protocol`
Das Kommunikationsprotokoll, das für die Kommunikation mit diesem Gerät verwendet wird. Derzeit gilt der einzige unterstützte Wert `ssh` für physische Geräte.
`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.publicKeyPath`
Optional. Der vollständige Pfad zum öffentlichen Schlüssel, der zur Authentifizierung von Verbindungen mit dem zu testenden Gerät verwendet wird.
Wenn Sie das angeben`publicKeyPath`, validiert IDT den öffentlichen Schlüssel des Geräts, wenn es eine SSH-Verbindung zu dem zu testenden Gerät herstellt. Wenn dieser Wert nicht angegeben ist, stellt IDT eine SSH-Verbindung her, validiert aber nicht den öffentlichen Schlüssel des Geräts.
Wir empfehlen dringend, dass Sie den Pfad zum öffentlichen Schlüssel angeben und eine sichere Methode verwenden, um diesen öffentlichen Schlüssel abzurufen. Für standardmäßige SSH-Clients, die auf der Befehlszeile basieren, wird der öffentliche Schlüssel in der Datei bereitgestellt. `known_hosts` Wenn Sie eine separate öffentliche Schlüsseldatei angeben, muss diese Datei dasselbe Format wie die `known_hosts` Datei verwenden, d. h.. ` ip-address key-type public-key` Wenn es mehrere Einträge mit derselben IP-Adresse gibt, muss der Eintrag für den von IDT verwendeten Schlüsseltyp vor den anderen Einträgen in der Datei stehen.
`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.
------
## Konfigurieren Sie userdata.json
IDT für AWS IoT Greengrass V2 benötigt außerdem zusätzliche Informationen zum Speicherort von Testartefakten und Software. AWS IoT Greengrass
Sie müssen diese Informationen mittels der Vorlage `userdata.json` in ` /configs/userdata.json` angeben:
```
{
"TempResourcesDirOnDevice": "/path/to/temp/folder",
"InstallationDirRootOnDevice": "/path/to/installation/folder",
"GreengrassNucleusZip": "/path/to/aws.greengrass.nucleus.zip",
"PreInstalled": "yes/no",
"GreengrassV2TokenExchangeRole": "custom-iam-role-name",
"hsm": {
"greengrassPkcsPluginJar": "/path/to/aws.greengrass.crypto.Pkcs11Provider-latest.jar",
"pkcs11ProviderLibrary": "/path/to/pkcs11-vendor-library",
"slotId": "slot-id",
"slotLabel": "slot-label",
"slotUserPin": "slot-pin",
"keyLabel": "key-label",
"preloadedCertificateArn": "certificate-arn"
"rootCA": "path/to/root-ca"
}
}
```
Alle Eigenschaften, die Werte enthalten, sind wie hier beschrieben erforderlich:
`TempResourcesDirOnDevice`
Der vollständige Pfad zu einem temporären Ordner auf dem zu testenden Gerät, in dem Testartefakte gespeichert werden sollen. Stellen Sie sicher, dass keine Sudo-Berechtigungen erforderlich sind, um in dieses Verzeichnis zu schreiben.
IDT löscht den Inhalt dieses Ordners, wenn die Ausführung eines Tests abgeschlossen ist.
`InstallationDirRootOnDevice`
Der vollständige Pfad zu einem Ordner auf dem Gerät, in dem die Installation durchgeführt werden soll. AWS IoT Greengrass Für PreInstalled Greengrass ist dies der Pfad zum Greengrass-Installationsverzeichnis.
Sie müssen die erforderlichen Dateiberechtigungen für diesen Ordner festlegen. Führen Sie den folgenden Befehl für jeden Ordner im Installationspfad aus.
```
sudo chmod 755 folder-name
```
`GreengrassNucleusZip`
Der vollständige Pfad zur Greengrass Nucleus-ZIP-Datei (`greengrass-nucleus-latest.zip`) auf Ihrem Host-Computer. Dieses Feld ist für Tests mit PreInstalled Greengrass nicht erforderlich.
Informationen zu den unterstützten Versionen von Greengrass Nucleus for IDT für AWS IoT Greengrass finden Sie unter. [Aktuelle IDT-Version für V2 AWS IoT Greengrass](dev-test-versions.md#idt-latest-version) Informationen zum Herunterladen der neuesten Greengrass-Software finden [Sie unter AWS IoT Greengrass Software herunterladen](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-tst-prereqs.html#config-gg).
`PreInstalled`
Diese Funktion ist nur für IDT v4.5.8 und spätere Versionen auf Linux-Geräten verfügbar.
(Optional) Wenn der Wert ist*yes*, geht IDT davon aus, dass der angegebene Pfad das Verzeichnis ist`InstallationDirRootOnDevice`, in dem Greengrass installiert ist.
Weitere Informationen zur Installation von Greengrass auf Ihrem Gerät finden Sie unter[Installieren Sie die AWS IoT Greengrass Core-Software mit automatischer Ressourcenbereitstellung](quick-installation.md). Wenn Sie die [Installation mit manueller Bereitstellung durchführen](https://docs.aws.amazon.com/greengrass/v2/developerguide/manual-installation.html), schließen Sie den Schritt „Das AWS IoT Ding zu einer neuen oder vorhandenen Dinggruppe hinzufügen“ ein, wenn Sie ein [AWS IoT Ding](https://docs.aws.amazon.com/greengrass/v2/developerguide/manual-installation.html#create-iot-thing) manuell erstellen. IDT geht davon aus, dass das Ding und die Dinggruppe während der Installation erstellt wurden. Stellen Sie sicher, dass diese Werte in der `effectiveConfig.yaml` Datei wiedergegeben werden. IDT sucht nach der Datei `effectiveConfig.yaml` unter`/config/effectiveConfig.yaml`.
Stellen Sie beim Ausführen von Tests mit HSM sicher, dass das `aws.greengrass.crypto.Pkcs11Provider` Feld in aktualisiert ist. `effectiveConfig.yaml`
`GreengrassV2TokenExchangeRole`
(Optional) Die benutzerdefinierte IAM-Rolle, die Sie als Token-Austauschrolle verwenden möchten, von der das zu testende Gerät annimmt, um mit AWS Ressourcen zu interagieren.
IDT verwendet diese benutzerdefinierte IAM-Rolle, anstatt während des Testlaufs die standardmäßige Token-Austauschrolle zu erstellen. Wenn Sie eine benutzerdefinierte Rolle verwenden, können Sie die [IAM-Berechtigungen für den Testbenutzer aktualisieren, um die `iamResourcesUpdate` Anweisung auszuschließen, die es dem Benutzer](dev-tst-prereqs.md#configure-idt-permissions) ermöglicht, IAM-Rollen und -Richtlinien zu erstellen und zu löschen.
Weitere Informationen zum Erstellen einer benutzerdefinierten IAM-Rolle als Token-Exchange-Rolle finden Sie unter. [Konfigurieren Sie eine benutzerdefinierte Token-Austauschrolle](device-config-setup.md#configure-custom-tes-role-for-idt)
`hsm`
Diese Funktion ist für IDT v4.5.1 und höher verfügbar.
(Optional) Die Konfigurationsinformationen für Tests mit einem AWS IoT Greengrass Hardware Security Module (HSM). Andernfalls sollte die `hsm`-Eigenschaft weggelassen werden. Weitere Informationen finden Sie unter [Integration von Hardware-Sicherheit](hardware-security.md).
Diese Eigenschaft gilt nur, wenn `connectivity.protocol` auf `ssh` festgelegt ist.
Die HSM-Konfiguration kann als sensible Daten betrachtet werden, wenn das Hardware-Sicherheitsmodul von IDT und einem anderen System gemeinsam genutzt wird. In diesem Fall können Sie die Sicherung dieser Konfigurationswerte im Klartext vermeiden, indem Sie sie in einem AWS Parameter SecureString Store-Parameter speichern und IDT so konfigurieren, dass sie während der Testausführung abgerufen werden. Weitere Informationen finden Sie unter [Rufen Sie die Konfiguration aus dem Parameter Store ab AWS](#fetch-config).
`hsm.greengrassPkcsPluginJar`
Der vollständige Pfad zur [PKCS \$111 -Anbieterkomponente](pkcs11-provider-component.md), die Sie auf den IDT-Hostcomputer herunterladen. AWS IoT Greengrass stellt diese Komponente als JAR-Datei bereit, die Sie herunterladen können, um sie während der Installation als Provisioning-Plugin anzugeben. Sie können die neueste Version der JAR-Datei der Komponente unter der folgenden URL herunterladen: [https://d2s8p88vqu9w66.cloudfront. net/releases/Pkcs11Provider/aws.greengrass.crypto.pkcs11Provider-latest.jar](https://d2s8p88vqu9w66.cloudfront.net/releases/Pkcs11Provider/aws.greengrass.crypto.Pkcs11Provider-latest.jar).
`hsm.pkcs11ProviderLibrary`
Der vollständige Pfad zur PKCS \$111 -Bibliothek, die vom Hersteller des Hardware-Sicherheitsmoduls (HSM) für die Interaktion mit dem HSM bereitgestellt wird.
`hsm.slotId`
Die Steckplatz-ID, anhand derer der HSM-Steckplatz identifiziert wird, in den Sie den Schlüssel und das Zertifikat laden.
`hsm.slotLabel`
Die Steckplatzbezeichnung, anhand derer der HSM-Steckplatz identifiziert wird, in den Sie den Schlüssel und das Zertifikat laden.
`hsm.slotUserPin`
Die Benutzer-PIN, mit der IDT die AWS IoT Greengrass Core-Software beim HSM authentifiziert.
Verwenden Sie aus Sicherheitsgründen nicht dieselbe Benutzer-PIN auf Produktionsgeräten.
`hsm.keyLabel`
Das Label zur Identifizierung des Schlüssels im Hardwaremodul. Sowohl der Schlüssel als auch das Zertifikat müssen dieselbe Schlüsselbezeichnung verwenden.
`hsm.preloadedCertificateArn`
Der Amazon-Ressourcenname (ARN) des hochgeladenen Gerätezertifikats in der AWS IoT Cloud.
Sie müssen dieses Zertifikat zuvor mit dem Schlüssel im HSM generiert, in Ihr HSM importiert und in die AWS IoT Cloud hochgeladen haben. Informationen zum Generieren und Importieren des Zertifikats finden Sie in der Dokumentation zu Ihrem HSM.
Sie müssen das Zertifikat in dasselbe Konto und dieselbe Region hochladen, die Sie in [config.json](#cfg-aws-gg) angeben. . Weitere Informationen zum Hochladen Ihres Zertifikats auf AWS IoT finden Sie unter [Manuelles Registrieren eines Client-Zertifikats](https://docs.aws.amazon.com/iot/latest/developerguide/manual-cert-registration.html) im *AWS IoT Entwicklerhandbuch*.
`hsm.rootCAPath`
(Optional) Der vollständige Pfad auf dem IDT-Hostcomputer zur Stammzertifizierungsstelle (CA), die Ihr Zertifikat signiert hat. Dies ist erforderlich, wenn das Zertifikat in Ihrem erstellten HSM nicht von der Amazon-Stammzertifizierungsstelle signiert ist.
## Rufen Sie die Konfiguration aus dem Parameter Store ab AWS
AWS IoT Device Tester (IDT) enthält eine optionale Funktion zum Abrufen von Konfigurationswerten aus dem [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). AWS Der Parameter Store ermöglicht die sichere und verschlüsselte Speicherung von Konfigurationen. Nach der Konfiguration kann IDT Parameter aus dem AWS Parameterspeicher abrufen, anstatt Parameter im Klartext in der Datei zu speichern. `userdata.json` Dies ist nützlich für alle sensiblen Daten, die verschlüsselt gespeichert werden sollten, z. B.: Passwörter, Pins und andere geheime Daten.
1. Um diese Funktion nutzen zu können, müssen Sie die bei der Erstellung Ihres [IDT-Benutzers](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-tst-prereqs.html) verwendeten Berechtigungen aktualisieren, um die GetParameter Aktion mit den Parametern zu ermöglichen, für deren Verwendung IDT konfiguriert ist. Im Folgenden finden Sie ein Beispiel für eine Berechtigungserklärung, die dem IDT-Benutzer hinzugefügt werden kann. Weitere Informationen finden Sie im [AWS Systems Manager Benutzerhandbuch](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-access.html).
```
{
"Sid":"parameterStoreResources",
"Effect": "Allow",
"Action": [
"ssm:GetParameter"
],
"Resource": "arn:aws:ssm:*:*:parameter/IDT*"
}
```
Die obige Berechtigung ist so konfiguriert, dass alle Parameter abgerufen werden können, deren Name mit, beginnt`IDT`, unter Verwendung des Platzhalterzeichens. `*` Sie sollten dies an Ihre Bedürfnisse anpassen, damit IDT Zugriff darauf hat, alle konfigurierten Parameter auf der Grundlage der Benennung der von Ihnen verwendeten Parameter abzurufen.
1. Sie müssen Ihre Konfigurationswerte im AWS Paramater Store speichern. Dies kann über die AWS Konsole oder über die AWS CLI erfolgen. AWS Mit Parameter Store können Sie zwischen verschlüsseltem und unverschlüsseltem Speicher wählen. Für die Speicherung sensibler Werte wie Geheimnisse, Passwörter und Pins sollten Sie die verschlüsselte Option verwenden, bei der es sich um einen Parametertyp von SecureString handelt. Um einen Parameter mit der AWS CLI hochzuladen, können Sie den folgenden Befehl verwenden:
```
aws ssm put-parameter --name IDT-example-name --value IDT-example-value --type SecureString
```
Mit dem folgenden Befehl können Sie überprüfen, ob ein Parameter gespeichert ist. (Optional) Verwenden Sie das `--with-decryption` Flag, um einen entschlüsselten SecureString Parameter abzurufen.
```
aws ssm get-parameter --name IDT-example-name
```
Bei Verwendung der AWS CLI wird der Parameter in die AWS Region des aktuellen CLI-Benutzers hochgeladen, und IDT ruft Parameter aus der Region ab, in der konfiguriert ist. `config.json` Verwenden Sie Folgendes, um Ihre Region von der AWS CLI aus zu überprüfen:
```
aws configure get region
```
1. Sobald Sie einen Konfigurationswert in der AWS Cloud haben, können Sie jeden Wert in der IDT-Konfiguration aktualisieren, um ihn aus der AWS Cloud abzurufen. Dazu verwenden Sie einen Platzhalter in Ihrer IDT-Konfiguration des Formulars, `{{AWS.Parameter.parameter_name}}` um den Parameter mit diesem Namen aus dem Parameterspeicher abzurufen. AWS
Nehmen wir beispielsweise an, Sie möchten den `IDT-example-name` Parameter aus Schritt 2 als HSM-KeyLabel in Ihrer HSM-Konfiguration verwenden. Zu diesem Zweck können Sie Ihre `userdata.json` wie folgt aktualisieren:
```
"hsm": {
"keyLabel": "{{AWS.Parameter.IDT-example-name}}",
[...]
}
```
IDT ruft zur Laufzeit den Wert dieses Parameters ab, auf den `IDT-example-value` in Schritt 2 gesetzt wurde. Diese Konfiguration ähnelt der Einstellung, `"keyLabel": "IDT-example-value"` aber stattdessen wird dieser Wert verschlüsselt in der AWS Cloud gespeichert.
# Führen Sie die AWS IoT Greengrass Qualifizierungssuite aus
Nachdem Sie [die gewünschte Konfiguration festgelegt haben](set-config.md), können Sie die Tests starten. Die Laufzeit der vollständigen Testsuite hängt von Ihrer Hardware ab. Zur Referenz: Es dauert etwa 30 Minuten, die vollständige Testsuite auf einem Raspberry Pi 3B auszuführen.
Verwenden Sie den folgenden `run-suite` Befehl, um eine Reihe von Tests auszuführen.
```
devicetester_[linux | mac | win]_x86-64 run-suite \\
--suite-id suite-id \\
--group-id group-id \\
--pool-id your-device-pool \\
--test-id test-id \\
--update-idt y|n \\
--userdata userdata.json
```
Alle Optionen sind optional. Sie können beispielsweise weglassen, `pool-id` wenn Sie nur einen Gerätepool haben, bei dem es sich um eine Gruppe identischer Geräte handelt, die in Ihrer `device.json` Datei definiert sind. Sie können auch `suite-id` weglassen, wenn Sie die neueste Testsuite-Version im `tests`-Ordner ausführen möchten.
**Anmerkung**
IDT informiert Sie, wenn eine neuere Testsuite-Version online verfügbar ist. Weitere Informationen finden Sie unter [Test-Suite-Versionen](idt-greengrass-qualification.md#idt-test-suite-versions).
## Beispielbefehle zum Ausführen der Qualification Suite
Die folgenden Befehlszeilenbeispiele zeigen Ihnen, wie Sie die Qualifikationstests für einen Gerätepool ausführen. Weitere Informationen zu `run-suite` und anderen IDT-Befehlen finden Sie unter [IDT für V2-Befehle AWS IoT Greengrass](#bk-cli).
Verwenden Sie den folgenden Befehl, um alle Testgruppen in einer angegebenen Testsuite auszuführen. Der `list-suites` Befehl listet die Testsuiten auf, die sich im `tests` Ordner befinden.
```
devicetester_[linux | mac | win]_x86-64 run-suite \
--suite-id GGV2Q_1.0.0 \
--pool-id \
--userdata userdata.json
```
Verwenden Sie den folgenden Befehl, um eine bestimmte Testgruppe in einer Testsuite auszuführen. Der `list-groups` Befehl listet die Testgruppen in einer Testsuite auf.
```
devicetester_[linux | mac | win]_x86-64 run-suite \
--suite-id GGV2Q_1.0.0 \
--group-id \
--pool-id \
--userdata userdata.json
```
Verwenden Sie den folgenden Befehl, um einen bestimmten Testfall in einer Testgruppe auszuführen.
```
devicetester_[linux | mac | win]_x86-64 run-suite \
--group-id \
--test-id \
--userdata userdata.json
```
Verwenden Sie den folgenden Befehl, um mehrere Testfälle in einer Testgruppe auszuführen.
```
devicetester_[linux | mac | win]_x86-64 run-suite \
--group-id \
--test-id ,
--userdata userdata.json
```
Verwenden Sie den folgenden Befehl, um alle Testfälle in einer Testgruppe aufzulisten.
```
devicetester_[linux | mac | win]_x86-64 list-test-cases --group-id
```
Wir empfehlen, dass Sie die vollständige Qualifizierungstestsuite ausführen, die Testgruppenabhängigkeiten in der richtigen Reihenfolge ausführt. Wenn Sie sich dafür entscheiden, bestimmte Testgruppen auszuführen, empfehlen wir, zuerst die Testgruppe für die Abhängigkeitsprüfung auszuführen, um sicherzustellen, dass alle Greengrass-Abhängigkeiten installiert sind, bevor Sie verwandte Testgruppen ausführen. Beispiel:
+ Führen Sie vor Ausführung von Testgruppen für die Core-Qualifizierung `coredependencies` aus.
## IDT für V2-Befehle AWS IoT Greengrass
Die IDT-Befehle befinden sich im `/bin`-Verzeichnis. Um eine Testsuite auszuführen, geben Sie den Befehl im folgenden Format an:
`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, in diesem Fall AWS IoT Greengrass Versionen, und Testsuite-Versionen für die aktuelle IDT-Version auf.
`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 finden Sie einige unterstützte Optionen:
+ `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. Wenn nicht angegeben, führt IDT alle entsprechenden Testgruppen in der Testsuite aus, abhängig von den konfigurierten Einstellungen in. `device.json` IDT führt aufgrund Ihrer konfigurierten Einstellungen keine Testgruppen aus, die das Gerät nicht unterstützt, auch wenn diese Testgruppen in der `group-id` Liste angegeben sind.
+ `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. Sie müssen einen Pool angeben, wenn mehrere Gerätepools in der `device.json`-Datei definiert sind.
+ `stop-on-first-failure`. Konfiguriert IDT so, dass es beim ersten Fehler nicht mehr läuft. Verwenden Sie diese Option zusammen`group-id`, wenn Sie die angegebenen Testgruppen debuggen möchten. Verwenden Sie diese Option nicht, wenn Sie eine vollständige Testsuite ausführen, um einen Qualifizierungsbericht zu generieren.
+ `update-idt`. Legt die Antwort auf die Aufforderung zur Aktualisierung von IDT fest. Die `Y` Antwort stoppt die Testausführung, wenn IDT feststellt, dass es eine neuere Version gibt. Die `N` Antwort setzt die Testausführung fort.
+ `userdata`. Der vollständige Pfad zu der `userdata.json` Datei, die Informationen über Testartefaktpfade enthält. Diese Option ist für den `run-suite` Befehl erforderlich. Die `userdata.json` Datei muss sich im Verzeichnis *devicetester\$1extract\$1location* /devicetester\$1ggv2\$1 /configs/ *[win\$1mac\$1linux]* befinden.
Weitere Informationen zu `run-suite`-Optionen erhalten Sie mit der `help`-Option:
```
devicetester_[linux | mac | win]_x86-64 run-suite -h
```
# Verstehen von Ergebnissen und Protokollen
In diesem Abschnitt wird beschrieben, wie Sie IDT-Ergebnisberichte und -Protokolle anzeigen und interpretieren können.
Informationen zur Behebung von Fehlern finden Sie unter[Problembehandlung IDT für V2 AWS IoT Greengrass](idt-troubleshooting.md).
## Anzeigen der Ergebnisse
Während der Ausführung schreibt IDT Fehler in die Konsole, Protokolldateien und Testberichte. Nachdem IDT die Qualifikations-Testsuite abgeschlossen hat, erstellt er zwei Testberichte. Diese Berichte befinden sich in`/results//`. Beide Berichte enthalten die Ergebnisse der Ausführung der Qualifizierungstestsuite.
Dies `awsiotdevicetester_report.xml` ist der Qualifizierungstestbericht, den Sie einreichen AWS , um Ihr Gerät im AWS Partner Gerätekatalog aufzulisten. Die Bericht enthält die folgenden Elemente:
+ Die IDT-Version.
+ Die AWS IoT Greengrass Version, die getestet wurde.
+ Die SKU- und der Gerätename, die in der `device.json`-Datei angegeben wurden.
+ Die Funktionen des Gerätepools, der in der `device.json`-Datei angegeben wurde.
+ Die aggregierte Zusammenfassung der Testergebnisse.
+ Eine Aufschlüsselung der Testergebnisse nach Bibliotheken, die auf der Grundlage der Gerätefunktionen wie lokaler Ressourcenzugriff, Shadow und MQTT getestet wurden.
Der `GGV2Q_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. Die Bericht enthält die folgenden Elemente:
+ Eine aggregierte Zusammenfassung der Testergebnisse.
+ Aufschlüsselung der Testergebnisse nach den getesteten AWS IoT Greengrass Funktionen.
## Interpretation der AWS IoT Device Tester Ergebnisse
Der Bericht im Abschnitt `awsiotdevicetester_report.xml` oder `awsiotdevicetester_report.xml` listet die Tests und die Ergebnisse auf, die ausgeführt wurden.
Das erste XML-Tag `` enthält die Zusammenfassung des Testlaufs. Zum Beispiel:
```
```Im ``-Tag verwendete Attribute
`name`
Name der Testsuite
`time`
Die Zeit in Sekunden, die für die Ausführung der Qualification Suite benötigt wurde.
`tests`
Die Anzahl der Tests, die ausgeführt wurden.
`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`
Ignoriere dieses Attribut. Sie wird nicht verwendet.
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 `required` gekennzeichnete Funktionen sind für die Einreichung Ihres Boards für die Qualifizierung erforderlich. Der folgende Ausschnitt zeigt, wie diese Informationen in der Datei `awsiotdevicetester_report.xml` angezeigt werden.
```
```
Wenn keine Testfehler oder Fehler bei den erforderlichen Funktionen vorliegen, erfüllt Ihr Gerät die technischen Voraussetzungen für den Betrieb AWS IoT Greengrass und kann mit AWS IoT Diensten zusammenarbeiten. Wenn Sie Ihr Gerät im AWS Partner Gerätekatalog auflisten möchten, können Sie diesen Bericht als Qualifikationsnachweis verwenden.
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. In jedem `` XML-Tag befinden sich `` Tags für jeden Test, der für eine Testgruppe ausgeführt wurde. 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
```
## Anzeigen von -Protokollen
IDT generiert Protokolle von Testläufen in. `/results//logs` Es werden zwei Protokollgruppen generiert:
`test_manager.log`
Von der Test Manager-Komponente von generierte Protokolle AWS IoT Device Tester (z. B. Protokolle zur Konfiguration, Testsequenzierung und Berichtserstellung).
`.log (for example, lambdaDeploymentTest.log)`
Protokolle des Testfalls innerhalb der Testgruppe, einschließlich der Protokolle des zu testenden Geräts. Ab IDT v4.2.0 gruppiert IDT die Testprotokolle für jeden Testfall in einem separaten ** Ordner innerhalb des Verzeichnisses. `/results//logs//`
# 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/