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 FreeRTOS
Das IDT für FreeRTOS ist ein Tool zur Qualifizierung der Datendurchsatzrate mit dem FreeRTOS-Betriebssystem. Der Gerätetester (IDT) öffnet zunächst eine USB- oder UART-Verbindung zu einem Gerät. Anschließend blinkt ein Bild von FreeRTOS, das konfiguriert ist, um die Gerätefunktionalität unter verschiedenen Bedingungen zu testen. AWS IoT Device Tester Suiten sind erweiterbar und IDT wird für die Orchestrierung von Kundentests verwendet. AWS IoT
IDT for FreeRTOS läuft auf einem Host-Computer (Windows, macOS oder Linux), der mit dem getesteten Gerät verbunden ist. IDT konfiguriert und orchestriert Testfälle und aggregiert die Ergebnisse. Er stellt ebenfalls eine Befehlszeilenschnittstelle zur Verwaltung der Testausführung bereit.
## FreeRTOS-Qualifizierungssuite
IDT for FreeRTOS überprüft den Port von FreeRTOS auf Ihrem Mikrocontroller und ob er effektiv und zuverlässig und sicher kommunizieren kann. AWS IoT Insbesondere wird überprüft, ob die Portierungslayer-Schnittstellen für FreeRTOS-Bibliotheken korrekt implementiert sind. Es führt end-to-end auch Tests mit durch. AWS IoT Core Es überprüft beispielsweise, ob Ihr Board MQTT-Nachrichten senden und empfangen und korrekt verarbeiten kann.
Die FreeRTOS Qualification (FRQ) 2.0 Suite verwendet Testfälle von FreeRTOS-Libraries-Integration-Tests und Device Advisor, die im [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html#qualifying-your-device-idt) Qualification Guide definiert sind.
IDT for FreeRTOS generiert Testberichte, die Sie an das AWS Partner Network (APN) senden können, um Ihre FreeRTOS-Geräte in den Partnergerätekatalog aufzunehmen. AWS Weitere Informationen finden Sie unter [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
Das folgende Diagramm zeigt die Einrichtung der Testinfrastruktur für die FreeRTOS-Qualifizierung.
![\[Flussdiagramm, das zeigt, wie die AWS IoT Core Interaktion mit Ihrem Computer und dem Mikrocontroller abläuft.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/devicetester_afr.png)
IDT for FreeRTOS organisiert Testressourcen in Testsuiten und Testgruppen:
+ Eine Testsuite besteht aus einer Reihe von Testgruppen, die verwendet werden, um zu überprüfen, ob ein Gerät mit bestimmten Versionen von FreeRTOS funktioniert.
+ Eine Testgruppe besteht aus einzelnen Testfällen, die sich auf eine bestimmte Funktion beziehen, z. B. BLE- und MQTT-Messaging.
Weitere Informationen finden Sie unter [Test-Suite-Versionen](idt-test-suite-versions.md).
## Verstehen Sie benutzerdefinierte Testsuiten
IDT for FreeRTOS kombiniert ein standardisiertes Konfigurations-Setup und ein standardisiertes Ergebnisformat mit einer Testsuite-Umgebung. In dieser Umgebung können Sie benutzerdefinierte Testsuiten für Ihre Geräte und Gerätesoftware entwickeln. 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 Sie benutzerdefinierte Testsuiten konfigurieren, bestimmt die Einstellungskonfigurationen, die Sie Ihren Benutzern zur Ausführung Ihrer benutzerdefinierten Testsuiten zur Verfügung stellen müssen. Weitere Informationen finden Sie unter [Entwickeln und betreiben Sie Ihre eigenen IDT-Testsuiten](idt-custom-tests.md).
# Unterstützte Versionen von AWS IoT Device Tester
Dieses Thema listet die unterstützten Versionen von AWS IoT Device Tester für FreeRTOS auf. Als bewährte Methode empfehlen wir, dass Sie die neueste Version von IDT for FreeRTOS verwenden, die Ihre Zielversion von FreeRTOS unterstützt. Jede Version von IDT for FreeRTOS hat eine oder mehrere entsprechende Versionen von FreeRTOS, die sie unterstützt. Wir empfehlen Ihnen, eine neue Version von IDT für FreeRTOS herunterzuladen, wenn eine neue Version von FreeRTOS veröffentlicht wird.
Durch das Herunterladen der Software stimmen Sie der im Download-Archiv enthaltenen AWS IoT Device Tester Lizenzvereinbarung zu.
**Anmerkung**
Wenn Sie AWS IoT Device Tester für FreeRTOS verwenden, empfehlen wir Ihnen, auf die neueste Patch-Version der neuesten FreeRTOS-LTS-Version zu aktualisieren.
**Wichtig**
Ab Oktober 2022 generiert AWS IoT FreeRTOS Qualification (FRQ) 1.0 keine signierten Qualifikationsberichte. AWS IoT Device Tester Sie können neue AWS IoT FreeRTOS-Geräte nicht für die Aufnahme in den [AWS Partnergerätekatalog über das Gerätequalifizierungsprogramm](https://partners.amazonaws.com/qualified-devices) [qualifizieren](https://aws.amazon.com/partners/programs/dqp/), wenn Sie IDT FRQ 1.0-Versionen verwenden.AWS Sie können FreeRTOS-Geräte zwar nicht mit IDT FRQ 1.0 qualifizieren, aber Sie können Ihre FreeRTOS-Geräte weiterhin mit FRQ 1.0 testen. [Wir empfehlen Ihnen, [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) zu verwenden, um FreeRTOS-Geräte zu qualifizieren und im Partnergerätekatalog aufzulisten.AWS](https://partners.amazonaws.com/qualified-devices)
## Aktuelle Version von AWS IoT Device Tester for freeRTOS
Verwenden Sie die folgenden Links, um die neuesten Versionen von IDT für FreeRTOS herunterzuladen.
**Aktuelle Version von AWS IoT Device Tester for freeRTOS**
| **AWS IoT Device Tester Version** | **Testsuite-Versionen** | **Unterstützte FreeRTOS-Versionen** | **Links herunterladen** | **Datum der Veröffentlichung** | **Versionshinweise** |
| --- | --- | --- | --- | --- | --- |
| IDT v4.9.0 | FRQ\$12.5.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) | 2023.04.04 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) |
**Anmerkung**
Es wird nicht empfohlen, dass mehrere Benutzer IDT aus einem freigegebenen Speicherort ausführen, z. B. einem NFS-Verzeichnis oder einem freigegebenen Windows-Netzwerkordner. Diese Vorgehensweise kann zu Abstürzen oder Datenbeschädigungen führen. Es wird empfohlen, das IDT-Paket auf ein lokales Laufwerk zu extrahieren und die IDT-Binärdatei auf Ihrer lokalen Workstation auszuführen.
## Frühere IDT-Versionen für FreeRTOS
Die folgenden früheren Versionen von IDT für FreeRTOS werden ebenfalls unterstützt.
**Frühere Versionen von AWS IoT Device Tester for freeRTOS**
| **AWS IoT Device Tester Version** | **Versionen der Testsuite** | **Unterstützte FreeRTOS-Versionen** | **Links herunterladen** | **Datum der Veröffentlichung** | **Versionshinweise** |
| --- | --- | --- | --- | --- | --- |
| IDT v4.8.1 | FRQ\$12.4.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) | 2023.01.23 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) |
| IDT v4.6.0 | FRQ\$12.3.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) | 2022.11.16 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) |
| IDT v4.5.11 | FRQ\$12.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) | 2022.10.14 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dev-test-versions-afr.html) |
Weitere Informationen finden Sie unter [Machen Sie sich mit den Support-Richtlinien vertraut für AWS IoT Device Tester](idt-support-policy.md).
# Nicht unterstützte IDT-Versionen für FreeRTOS
In diesem Abschnitt werden nicht unterstützte Versionen von IDT für FreeRTOS aufgeführt. Nicht unterstützte Versionen erhalten keine Fehlerbehebungen oder Updates. Weitere Informationen finden Sie unter [Machen Sie sich mit den Support-Richtlinien vertraut für AWS IoT Device Tester](idt-support-policy.md).
Die folgenden Versionen von IDT-FreeRTOS werden nicht mehr unterstützt.
**Nicht unterstützte Versionen von AWS IoT Device Tester for FreeRTOS**
| **AWS IoT Device Tester Version** | **Versionen der Testsuite** | **Unterstützte FreeRTOS-Versionen** | **Datum der Veröffentlichung** | **Versionshinweise** |
| --- | --- | --- | --- | --- |
| IDT v4.5.10 | FRQ\$12.1.4 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.09.02 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.9 | FRQ\$12.1.3 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.08.17 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.6 | FRQ\$12.1.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.06.29 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.5 | FRQ\$12.1.1 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.06.06 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.5 | FRQ\$12.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.05.31 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.4 | FRQ\$12.0.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) | 2022.05.09 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.5.2 | FRQ\$11.6.2 | 202107,00 | 2022.01.25 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.3 | FRQ\$11.5.1 | 202012,00 | 2021,07,30 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.3.0 | FRQ\$11.6.1 | 202107,00 | 2021.07.26 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.1.0 | FRQ\$11.6.0 | 202107,00 | 2021.07.21 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v4.0.1 | FRQ\$11.4.1 | 202012,00 | 2021.01.19 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.4.0 | FRQ\$11.3.0 | 202011,01 | 2020.11.05 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.3.0 | FRQ\$11.2.0 | 202007,00 | 17.09.2020 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v3.0.2 | FRQ\$11.0.1 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.7.1 | FRQ\$11.0.0 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.6.2 | FRQ\$11.0.0 | 202002.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.5.2 | FRQ\$11.0.0 | 201910.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.4.1 | FRQ\$11.0.0 | 201908.00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT v1.3.2 | FRQ\$11.0.0 | 201906,00 | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) |
| IDT-FreeRTOS v1.2 | FRQ\$11.0.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/idt-unsupported-versions-afr.html) | | Unterstützung für das Testen von FreeRTOS-Geräten mit dem CMAKE-Build-System hinzugefügt. |
| IDT-FreeRTOS v1.1 | FRQ\$11.0.0 | | | |
| IDT-FreeRTOS v1.0 | FRQ\$11.0.0 | | | |
# Laden Sie IDT für FreeRTOS herunter
In diesem Thema werden die Optionen zum Herunterladen von IDT für FreeRTOS beschrieben. Sie können entweder einen der folgenden Links zum Herunterladen von Software verwenden oder den Anweisungen folgen, um IDT programmgesteuert herunterzuladen.
**Wichtig**
Stand Oktober 2022 generiert AWS IoT FreeRTOS Qualification (FRQ) 1.0 keine signierten Qualifikationsberichte. AWS IoT Device Tester Sie können neue AWS IoT FreeRTOS-Geräte nicht für die Aufnahme in den [AWS Partnergerätekatalog über das AWS Gerätequalifizierungsprogramm](https://partners.amazonaws.com/qualified-devices) [qualifizieren](https://aws.amazon.com/partners/programs/dqp/), wenn Sie IDT FRQ 1.0-Versionen verwenden. Sie können FreeRTOS-Geräte zwar nicht mit IDT FRQ 1.0 qualifizieren, aber Sie können Ihre FreeRTOS-Geräte weiterhin mit FRQ 1.0 testen. [Wir empfehlen Ihnen, [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) zu verwenden, um FreeRTOS-Geräte zu qualifizieren und im Partnergerätekatalog aufzulisten.AWS](https://partners.amazonaws.com/qualified-devices)
**Topics**
+ [Laden Sie IDT manuell herunter](#idt-download-options)
+ [Laden Sie IDT programmgesteuert herunter](idt-programmatic-download-process.md)
Durch das Herunterladen der Software stimmen Sie der im Download-Archiv enthaltenen AWS IoT Device Tester Lizenzvereinbarung 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.
## Laden Sie IDT manuell herunter
In diesem Thema werden die unterstützten Versionen von IDT für FreeRTOS aufgeführt. Als bewährte Methode empfehlen wir, dass Sie die neueste Version verwenden AWS IoT Device Tester , die Ihre Zielversion von FreeRTOS unterstützt. Bei neuen Versionen von FreeRTOS müssen Sie möglicherweise eine neue Version von herunterladen. AWS IoT Device Tester Sie erhalten eine Benachrichtigung, wenn Sie einen Testlauf starten, falls dieser nicht mit der von Ihnen verwendeten Version von FreeRTOS kompatibel AWS IoT Device Tester ist.
Siehe [Unterstützte Versionen von AWS IoT Device Tester](dev-test-versions-afr.md)
# 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 aufzurufen, benötigen Sie die Berechtigung, die **iot-device-tester:LatestIdt** Aktion auszuführen. Fügen Sie Ihre AWS Signatur mit `iot-device-tester` als Dienstnamen hinzu
## 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:
`FR`— IDT für FreeRTOS
ProductVersion
(Optional) Die Version von FreeRTOS. Der Dienst gibt die neueste kompatible Version von IDT für diese Version von FreeRTOS 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 die folgenden Beispiele verwenden, 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 von **HostOs/ProductVersion/TestSuiteType**oder/angegeben werden. 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 AWS IoT Device Tester für FreeRTOS](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) dokumentiert.
+ Ersetze es durch *us-west-2* dein. AWS-Region Eine Liste der Regionscodes finden Sie unter [Regionale Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints).
+ *linux*Ersetzen Sie es durch das Betriebssystem Ihres Host-Computers.
+ Ersetze es *202107.00* durch deine Version von FreeRTOS.
```
url=$(curl --request GET "https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&ProductVersion=202107.00&TestSuiteType=FR" \
--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/IAM/latest/UserGuide/reference_sigv.html).
+ *linux*Ersetzen Sie es durch das Betriebssystem Ihres Host-Computers.
+ *Timestamp*Ersetzen Sie durch Datum und Uhrzeit, z. **20220210T004606Z** B.
+ *Date*Durch das Datum ersetzen, 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/IAM/latest/UserGuide/reference_sigv-create-signed-request.html), die Sie generieren.
```
curl --location --request GET 'https://download.devicetester.iotdevicesecosystem.amazonaws.com/latestidt?HostOs=linux&TestSuiteType=FR' \
--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/IAM/latest/UserGuide/reference_sigv.html) in der *AWS Allgemeinen Referenz*.
+ Ersetze es *us-west-2* durch deine Region. Eine Liste der Regionalcodes 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=FR'
# 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)
```
# IDT mit FreeRTOS Qualification Suite 2.0 (FRQ 2.0)
Die FreeRTOS Qualification Suite 2.0 ist eine aktualisierte Version der FreeRTOS Qualification Suite. Wir empfehlen Entwicklern, FRQ 2.0 zu verwenden, da es aus relevanten Testfällen besteht, um Geräte zu qualifizieren, auf denen FreeRTOS Long Term Support (LTS) -Bibliotheken ausgeführt werden.
IDT for FreeRTOS überprüft den Port von FreeRTOS auf Ihrem Mikrocontroller und ob er effektiv mit ihm kommuniziert. AWS IoT Insbesondere überprüft es die Schnittstellen der Portierungsschicht zu den FreeRTOS-Bibliotheken und ob die FreeRTOS-Testrepositorien korrekt implementiert sind. Es führt auch Tests mit durch. end-to-end AWS IoT Core[Die von IDT für FreeRTOS ausgeführten Tests sind im FreeRTOS-Repository definiert. GitHub](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests)
IDT for FreeRTOS führt Tests als eingebettete Anwendungen aus, die auf dem zu testenden Mikrocontroller-Gerät blinken. Die Binär-Images der Anwendung enthalten FreeRTOS, die portierten FreeRTOS-Schnittstellen und Platinengerätetreiber. Der Zweck der Tests besteht darin, zu überprüfen, ob die portierten FreeRTOS-Schnittstellen auf Ihren Gerätetreibern korrekt funktionieren.
IDT for FreeRTOS generiert Testberichte, die Sie einreichen können, AWS IoT damit Ihre Hardware im AWS Partnergerätekatalog aufgeführt wird. Weitere Informationen finden Sie unter [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
IDT for FreeRTOS läuft auf einem Host-Computer (Windows, macOS oder Linux), der mit dem zu testenden Gerät verbunden ist. IDT konfiguriert und orchestriert Testfälle und aggregiert die Ergebnisse. Es bietet auch eine Befehlszeilenschnittstelle zur Verwaltung der Ausführung der Tests.
Um Ihr Gerät zu testen, erstellt IDT for FreeRTOS Ressourcen wie AWS IoT Dinge, FreeRTOS-Gruppen und Lambda-Funktionen. Um diese Ressourcen zu erstellen, verwendet IDT for FreeRTOS die in der konfigurierten AWS Anmeldeinformationen, `config.json` um API-Aufrufe in Ihrem Namen durchzuführen. Diese Ressourcen werden zu verschiedenen Zeiten während eines Tests bereitgestellt.
Wenn Sie IDT for FreeRTOS auf Ihrem Host-Computer ausführen, werden die folgenden Schritte ausgeführt:
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.
# Richten Sie die Voraussetzungen für die LTS-Qualifikation ein
In diesem Abschnitt werden die Voraussetzungen für das Testen von Mikrocontrollern mit AWS IoT Device Tester beschrieben.
## Bereiten Sie sich auf die FreeRTOS-Qualifikation vor
**Anmerkung**
AWS IoT Device Tester for FreeRTOS empfiehlt dringend, die neueste Patch-Version der neuesten FreeRTOS-LTS-Version zu verwenden.
IDT für FRQ 2.0 ist eine Qualifikation für FreeRTOS. Bevor Sie IDT FRQ 2.0 zur Qualifizierung ausführen, müssen Sie die Qualifizierung [Ihres Boards im *FreeRTOS* Qualification](https://docs.aws.amazon.com/freertos/latest/qualificationguide/freertos-qualification.html) Guide abschließen. Informationen zum Portieren, Testen und Einrichten von Bibliotheken finden Sie unter [Portieren der `manifest.yml` FreeRTOS-Bibliotheken im *FreeRTOS*](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting.html) Porting Guide. FRQ 2.0 beinhaltet ein anderes Qualifizierungsverfahren. Einzelheiten finden Sie [im *FreeRTOS-Qualifikationsleitfaden unter Letzte Qualifikationsänderungen*](https://docs.aws.amazon.com/freertos/latest/qualificationguide/latest-changes.html).
Das [FreeRTOS-Libraries-Integration-Tests-Repository muss vorhanden](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests) sein, damit IDT ausgeführt werden kann. Informationen zum Klonen und [Portieren dieses Repositorys in Ihr Quellprojekt finden Sie in der README.md.](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/README.md) FreeRTOS-Libraries-Integration-Testsmuss die Datei enthalten, die `manifest.yml` sich im Stammverzeichnis Ihres Projekts befindet, damit IDT ausgeführt werden kann.
**Anmerkung**
IDT hängt von der Implementierung von im Test-Repository ab. `UNITY_OUTPUT_CHAR` Die Testausgabeprotokolle und die Geräteprotokolle dürfen nicht miteinander verschachtelt werden. Weitere Informationen finden Sie im Abschnitt [Implementierung der Bibliotheksprotokollierungsmakros](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html) im *FreeRTOS Porting Guide*.
## Laden Sie IDT für FreeRTOS herunter
Jede Version von FreeRTOS hat eine entsprechende Version von IDT für FreeRTOS zur Durchführung von Qualifizierungstests. Laden Sie die entsprechende Version von IDT für FreeRTOS von [Unterstützte Versionen von AWS IoT Device Tester](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) für FreeRTOS herunter.
Extrahieren Sie IDT for FreeRTOS an einen Speicherort im Dateisystem, für den Sie Lese- und Schreibberechtigungen haben. Da Microsoft Windows eine Zeichenbeschränkung für die Pfadlänge hat, extrahieren Sie IDT für FreeRTOS in ein Stammverzeichnis wie oder. `C:\` `D:\`
**Anmerkung**
IDT darf nicht von mehreren Benutzern von einem gemeinsam genutzten Speicherort aus ausgeführt werden, z. B. von einem NFS-Verzeichnis oder einem gemeinsam genutzten Windows-Netzwerkordner. Dies führt zu Abstürzen oder Datenbeschädigungen. Es wird empfohlen, das IDT-Paket in einem lokalen Laufwerk zu extrahieren.
## Laden Sie Git herunter
IDT muss Git als Voraussetzung installiert haben, um die Integrität des Quellcodes sicherzustellen.
Folgen Sie den Anweisungen in der [GitHub](https://github.com/git-guides/install-git)Anleitung, um Git zu installieren. Um die aktuell installierte Version von Git zu überprüfen, geben Sie den Befehl `git --version` am Terminal ein.
**Warnung**
IDT verwendet Git, um sich an den Status eines Verzeichnisses „sauber“ oder „Dirty“ anzupassen. Wenn Git nicht installiert ist, schlagen die `FreeRTOSIntegrity` Testgruppen entweder fehl oder laufen nicht wie erwartet. Wenn IDT einen Fehler wie `git executable not found` oder zurückgibt`git command not found`, installieren Sie Git oder installieren Sie es erneut und versuchen Sie es erneut.
**Topics**
+ [Bereiten Sie sich auf die FreeRTOS-Qualifikation vor](#idt-preparing-qualification)
+ [Laden Sie IDT für FreeRTOS herunter](#idt-download-dev-tester-afr)
+ [Laden Sie Git herunter](#idt-download-git)
+ [Erstelle ein Konto AWS](#lts-config-aws-account)
+ [AWS IoT Device Tester verwaltete Richtlinie](#managed-policy)
+ [(Optional) Installieren Sie den AWS Command Line Interface](#install-cli)
## Erstelle ein Konto AWS
**Anmerkung**
Die vollständige IDT-Qualifizierungssuite wird nur in den folgenden Fällen unterstützt AWS-Regionen
USA Ost (Nord-Virginia)
USA West (Oregon)
Asien-Pazifik (Tokio)
Europa (Irland)
Um Ihr Gerät zu testen, erstellt IDT for FreeRTOS Ressourcen wie AWS IoT Dinge, FreeRTOS-Gruppen und Lambda-Funktionen. Um diese Ressourcen zu erstellen, müssen Sie für IDT for FreeRTOS ein AWS Konto und eine IAM-Richtlinie erstellen und konfigurieren, die IDT for FreeRTOS die Erlaubnis erteilt, während der Ausführung von Tests in Ihrem Namen auf Ressourcen zuzugreifen.
In den folgenden Schritten erstellen und konfigurieren Sie Ihr Konto. AWS
1. Wenn Sie bereits ein AWS Konto haben, fahren Sie mit dem nächsten Schritt fort. Andernfalls erstellen Sie ein [AWS Konto](https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/).
1. Folgen Sie den Schritten unter [IAM-Rollen erstellen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html). Fügen Sie derzeit keine Berechtigungen oder Richtlinien hinzu.
1. Um OTA-Qualifizierungstests durchzuführen, fahren Sie mit Schritt 4 fort. Andernfalls fahren Sie mit Schritt 5 fort.
1. Hängen Sie die Inline-Richtlinie für OTA-IAM-Berechtigungen an Ihre IAM-Rolle an.
1.
**Wichtig**
Die folgende Richtlinienvorlage erteilt die IDT-Berechtigung zum Erstellen von Rollen, Erstellen von Richtlinien und Zuweise von Richtlinien an Rollen. IDT for FreeRTOS verwendet diese Berechtigungen für Tests, die Rollen erstellen. Obwohl die Richtlinienvorlage dem Benutzer keine Administratorrechte gewährt, können die Berechtigungen verwendet werden, um Administratorzugriff auf Ihr Konto zu erhalten. AWS
1. Gehen Sie wie folgt vor, um Ihrer IAM-Rolle die erforderlichen Berechtigungen zuzuweisen:
1. Wählen Sie auf der Seite **Berechtigungen** die Option **Berechtigungen hinzufügen** aus.
1. Wählen Sie **Inline-Richtlinie erstellen** aus.
1. Wählen Sie die Registerkarte **JSON** aus und kopieren Sie die folgenden Berechtigungen in das **JSON-Textfeld**. Verwenden Sie die Vorlage unter **Die meisten Regionen**, wenn Sie sich nicht in der Region China befinden. Wenn Sie sich in der Region China befinden, verwenden Sie die Vorlage unter den **Regionen Peking und Ningxia**.
------
#### [ Most Regions ]
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iotdeviceadvisor:*",
"Resource": [
"arn:aws:iotdeviceadvisor:*:*:suiterun/*/*",
"arn:aws:iotdeviceadvisor:*:*:suitedefinition/*"
]
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/idt*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "iotdeviceadvisor.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke*",
"iam:ListRoles",
"iot:Connect",
"iot:CreateJob",
"iot:DeleteJob",
"iot:DescribeCertificate",
"iot:DescribeEndpoint",
"iot:DescribeJobExecution",
"iot:DescribeJob",
"iot:DescribeThing",
"iot:GetPolicy",
"iot:ListAttachedPolicies",
"iot:ListCertificates",
"iot:ListPrincipalPolicies",
"iot:ListThingPrincipals",
"iot:ListThings",
"iot:Publish",
"iot:UpdateThingShadow",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:PutRetentionPolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iotdeviceadvisor:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "logs:DeleteLogGroup",
"Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*"
},
{
"Effect": "Allow",
"Action": "logs:GetLogEvents",
"Resource": "arn:aws:logs:*:*:log-group:/aws/iot/deviceadvisor/*:log-stream:*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreatePolicy",
"iam:DetachRolePolicy",
"iam:DeleteRolePolicy",
"iam:DeletePolicy",
"iam:CreateRole",
"iam:DeleteRole",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::*:policy/idt*",
"arn:aws:iam::*:role/idt*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters"
],
"Resource": [
"arn:aws:ssm:*::parameter/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:RunInstances",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateKeyPair",
"ec2:DeleteKeyPair"
],
"Resource": [
"arn:aws:ec2:*:*:key-pair/idt-ec2-ssh-key-*"
]
},
{
"Effect": "Allow",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:ResourceTag/Owner": "IoTDeviceTester"
}
},
"Action": [
"ec2:TerminateInstances",
"ec2:DeleteSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupIngress"
],
"Resource": [
"*"
]
}
]
}
```
------
------
#### [ Beijing and Ningxia Regions ]
Die folgende Richtlinienvorlage kann in den Regionen Peking und Ningxia verwendet werden.
------
1. Wählen Sie, wenn Sie fertig sind, **Review policy (Richtlinie überprüfen)** aus.
1. Geben Sie **IDTFreeRTOSIAMPermissions**den Namen der Richtlinie ein.
1. Wählen Sie **Richtlinie erstellen** aus.
1. Hängen Sie **AWSIoTDeviceTesterForFreeRTOSFullAccess** an Ihre IAM-Rolle an.
1. Gehen Sie wie folgt vor, um Ihrer IAM-Rolle die erforderlichen Berechtigungen zuzuweisen:
1. Wählen Sie auf der Seite **Berechtigungen** die Option **Berechtigungen hinzufügen** aus.
1. Wählen Sie **Richtlinien anfügen**.
1. Suchen Sie nach der **AWSIoTDeviceTesterForFreeRTOSFullZugriffsrichtlinie**. Markieren Sie das Kästchen.
1. Wählen Sie **Add permissions** (Berechtigungen hinzufügen) aus.
1. Anmeldeinformationen für IDT exportieren. Weitere Informationen finden Sie unter [Abrufen von IAM-Rollenanmeldedaten für den CLI-Zugriff](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html).
## AWS IoT Device Tester verwaltete Richtlinie
Die `AWSIoTDeviceTesterForFreeRTOSFullAccess` verwaltete Richtlinie enthält die folgenden AWS IoT Device Tester Berechtigungen für die Versionsprüfung, auto Aktualisierungsfunktionen und die Erfassung von Metriken.
+ `iot-device-tester:SupportedVersion`
Erteilt die AWS IoT Device Tester Berechtigung zum Abrufen der Liste der unterstützten Produkte, Testsuiten und IDT-Versionen.
+ `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 Testsuite-Updates.
+ `iot-device-tester:SendMetrics`
AWS Erteilt die Erlaubnis, Metriken zur AWS IoT Device Tester internen Nutzung zu sammeln.
## (Optional) Installieren Sie den AWS Command Line Interface
Möglicherweise ziehen Sie es vor, den zu verwenden AWS CLI , um einige Operationen auszuführen. Wenn Sie das nicht AWS CLI installiert haben, folgen Sie den Anweisungen unter [Installieren](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) von AWS CLI.
Konfigurieren Sie das AWS CLI für die AWS Region, die Sie verwenden möchten, indem Sie es **aws configure** von einer Befehlszeile aus ausführen. Informationen zu den AWS Regionen, die IDT für FreeRTOS unterstützen, finden Sie unter [AWS Regionen](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control) und Endpunkte. [Weitere Informationen finden Sie unter Schnellkonfiguration mit**aws configure**. **aws configure**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)
# Erster Test Ihres Mikrocontroller-Boards
Sie können IDT for FreeRTOS verwenden, um Ihre Implementierung der FreeRTOS-Bibliotheken zu testen. Nachdem Sie die FreeRTOS-Bibliotheken für die Gerätetreiber Ihres Boards portiert haben, verwenden Sie AWS IoT Device Tester sie, um die Qualifizierungstests auf Ihrer Mikrocontroller-Karte durchzuführen.
## Hinzufügen von Portierungsebenen für Bibliotheken
Informationen zur Portierung von FreeRTOS für Ihr Gerät finden Sie im [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/porting-guide.html) Porting Guide. Bei der Implementierung des FreeRTOS-Testrepositorys und der Portierung der FreeRTOS-Schichten müssen Sie Pfade zu jeder Bibliothek angeben, einschließlich des Test-Repositorys. `manifest.yml` Diese Datei befindet sich im Stammverzeichnis Ihres Quellcodes. Einzelheiten finden Sie in [den Anweisungen zur Manifestdatei](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist-manifest-instr.html).
## Konfigurieren Sie Ihre AWS Anmeldeinformationen für AWS IoT Device Tester die Kommunikation mit der AWS Cloud
Sie müssen Ihre AWS Anmeldeinformationen für AWS IoT Device Tester die Kommunikation mit der AWS Cloud konfigurieren. Weitere Informationen finden Sie unter [AWS Zugangsdaten und Region für die Entwicklung einrichten](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html). Gültige AWS Anmeldeinformationen sind in der `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/config.json` Konfigurationsdatei angegeben.
```
"auth": {
"method": "environment"
}
"auth": {
"method": "file",
"credentials": {
"profile": ""
}
}
```
Das `auth` Attribut der `config.json` Datei hat ein Methodenfeld, das die AWS Authentifizierung steuert, und kann entweder als Datei oder als Umgebung deklariert werden. Wenn Sie das Feld auf Umgebung setzen, werden Ihre AWS Anmeldeinformationen aus den Umgebungsvariablen Ihres Host-Computers abgerufen. Wenn Sie das Feld auf Datei setzen, wird ein bestimmtes Profil aus der `.aws/credentials` Konfigurationsdatei importiert.
**Topics**
+ [Hinzufügen von Portierungsebenen für Bibliotheken](#lts-add-port-layer)
+ [Konfigurieren Sie Ihre AWS Anmeldeinformationen für AWS IoT Device Tester die Kommunikation mit der AWS Cloud](#lts-cfg-aws-afr)
+ [Erstellen Sie einen Gerätepool in IDT für FreeRTOS](lts-cfg-dt-dp.md)
+ [Konfiguration von Build-, Flash- und Testeinstellungen](lts-cfg-dt-ud.md)
# Erstellen Sie einen Gerätepool in IDT für FreeRTOS
Zu testende Geräte werden in Gerätepools organisiert. Jeder Gerätepool besteht aus einem oder mehreren identischen Geräten. Sie können IDT for FreeRTOS so konfigurieren, dass ein einzelnes Gerät oder mehrere Geräte in einem Pool getestet werden. Um den Qualifizierungsprozess zu beschleunigen, kann IDT for FreeRTOS Geräte mit denselben Spezifikationen parallel testen. Er verwendet eine Round Robin-Methode, um auf jedem Gerät in einem Gerätepool eine andere Testgruppe auszuführen.
Die `device.json` Datei hat ein Array in der obersten Ebene. Jedes Array-Attribut ist ein neuer Gerätepool. Jeder Gerätepool hat ein Geräte-Array-Attribut, für das mehrere Geräte deklariert sind. In der Vorlage gibt es einen Gerätepool und nur ein Gerät in diesem Gerätepool. Sie können ein oder mehrere Geräte zu einem Gerätepool hinzufügen, indem Sie den Abschnitt `devices` der Vorlage `device.json` im Ordner `configs` bearbeiten.
**Anmerkung**
Alle Geräte im selben Pool müssen dieselbe technische Spezifikation und SKU haben. Um parallel Builds des Quellcodes für verschiedene Testgruppen zu ermöglichen, kopiert IDT for FreeRTOS den Quellcode in einen Ergebnisordner innerhalb des extrahierten IDT for FreeRTOS-Ordners. Sie müssen in Ihrem Build- oder Flash-Befehl mithilfe der Variablen auf den Quellcodepfad verweisen. `testdata.sourcePath` IDT for FreeRTOS ersetzt diese Variable durch einen temporären Pfad des kopierten Quellcodes. Weitere Informationen finden Sie unter [IDT für FreeRTOS-Variablen](lts-dt-vars.md).
Die folgende `device.json` Beispieldatei wurde verwendet, um einen Gerätepool mit mehreren Geräten zu erstellen.
```
[
{
"id": "pool-id",
"sku": "sku",
"features": [
{
"name": "Wifi",
"value": "Yes | No"
},
{
"name": "Cellular",
"value": "Yes | No"
},
{
"name": "BLE",
"value": "Yes | No"
},
{
"name": "PKCS11",
"value": "RSA | ECC | Both"
},
{
"name": "OTA",
"value": "Yes | No",
"configs": [
{
"name": "OTADataPlaneProtocol",
"value": "MQTT | HTTP | None"
}
]
},
{
"name": "KeyProvisioning",
"value": "Onboard | Import | Both | No"
}
],
"devices": [
{
"id": "device-id",
"connectivity": {
"protocol": "uart",
"serialPort": "/dev/tty*"
},
"secureElementConfig" : {
"publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key",
"publiDeviceCertificateArn": "arn:partition:iot:region:account-id:resourcetype:resource:qualifier",
"secureElementSerialNumber": "secure-element-serialNo-value",
"preProvisioned" : "Yes | No",
"pkcs11JITPCodeVerifyRootCertSupport": "Yes | No"
},
"identifiers": [
{
"name": "serialNo",
"value": "serialNo-value"
}
]
}
]
}
]
```
Die folgenden Attribute werden in der Datei `device.json` verwendet:
** `id` **
Eine benutzerdefinierte alphanumerische ID, die einen Gerätepool eindeutig identifiziert. Geräte, die zu einem Pool gehören, müssen vom gleichen Typ sein. Bei der Ausführung einer Reihe von Tests werden Geräte im Pool verwendet, um den Workload zu parallelisieren.
** `sku` **
Ein alphanumerischer Wert, mit dem das getestete Board eindeutig identifiziert wird. Die SKU wird verwendet, um qualifizierte Boards nachzuverfolgen.
Wenn du dein Mainboard im Gerätekatalog für AWS Partner anbieten möchtest, muss die hier angegebene SKU mit der SKU übereinstimmen, die du bei der Angebotserstellung verwendest.
** `features` **
Ein Array, das die vom Gerät unterstützten Funktionen enthält. AWS IoT Device Tester verwendet diese Informationen, um die durchzuführenden Qualifikationstests auszuwählen.
Unterstützte Werte sind:
** `Wifi` **
Gibt an, ob Ihr Board über WiFi-Funktionen verfügt.
** `Cellular` **
Zeigt an, ob Ihr Motherboard über Mobilfunkfunktionen verfügt.
** `PKCS11` **
Gibt den Kryptografiealgorithmus mit öffentlichen Schlüsseln an, den das Board unterstützt. PKCS11 ist für die Qualifikation erforderlich. Unterstützte Werte sind `ECC``RSA`, und`Both`. `Both`gibt an, dass das Board `ECC` sowohl als auch unterstützt`RSA`.
** `KeyProvisioning` **
Gibt an, wie ein vertrauenswürdiges X.509-Clientzertifikat auf das Board geschrieben werden kann.
Gültige Werte sind `Import``Onboard`, `Both` und`No`. `Onboard`,`Both`, oder die Bereitstellung von `No` Schlüsseln ist für die Qualifizierung erforderlich. `Import`allein ist keine gültige Qualifizierungsoption.
+ Verwenden Sie diese Option `Import` nur, wenn Ihr Board den Import von privaten Schlüsseln zulässt. `Import`Die Auswahl ist keine gültige Konfiguration für die Qualifizierung und sollte nur zu Testzwecken verwendet werden, insbesondere bei PKCS11 Testfällen. `Onboard`, `Both` oder `No` ist für die Qualifizierung erforderlich.
+ Verwenden Sie diese Option, `Onboard` wenn Ihr Board integrierte private Schlüssel unterstützt (z. B. wenn Ihr Gerät über ein sicheres Element verfügt oder wenn Sie es vorziehen, Ihr eigenes Geräteschlüsselpaar und Ihr eigenes Zertifikat zu generieren). Stellen Sie sicher, dass Sie in jedem der Geräteabschnitte ein `secureElementConfig`-Element hinzufügen und fügen Sie den absoluten Pfad zur Datei des öffentlichen Schlüssels in das Feld `publicKeyAsciiHexFilePath` ein.
+ Verwenden Sie diese `Both` Option, wenn Ihr Board sowohl den Import von privaten Schlüsseln als auch die integrierte Schlüsselgenerierung für die Schlüsselbereitstellung unterstützt.
+ Verwenden Sie diese `No` Option, wenn Ihr Board die Schlüsselbereitstellung nicht unterstützt. `No`ist nur dann eine gültige Option, wenn Ihr Gerät ebenfalls vorab bereitgestellt wurde.
** `OTA` **
Zeigt an, ob Ihr Board die over-the-air Aktualisierungsfunktion (OTA) unterstützt. Das Attribut `OtaDataPlaneProtocol` gibt an, welches OTA-Protokoll auf Datenebene das Gerät unterstützt. Für die Qualifizierung ist ein OTA mit entweder dem HTTP- oder dem MQTT-Datenebenenprotokoll erforderlich. Um die Ausführung von OTA-Tests während des Tests zu überspringen, setzen Sie die OTA-Funktion auf `No` und das `OtaDataPlaneProtocol` Attribut auf. `None` Dies wird kein Qualifikationslauf sein.
** `BLE` **
Gibt an, ob Ihr Board Bluetooth Low Energy (BLE) unterstützt.
** `devices.id` **
Eine benutzerdefinierte eindeutige Kennung für das zu testende Gerät.
** `devices.connectivity.serialPort` **
Der serielle Port des Host-Computers, der zur Herstellung einer Verbindung mit den getesteten Geräten verwendet wird.
** `devices.secureElementConfig.PublicKeyAsciiHexFilePath` **
Erforderlich, wenn Ihr Board NICHT `pre-provisioned` oder nicht zur Verfügung gestellt `PublicDeviceCertificateArn` wird. Da `Onboard` es sich um eine erforderliche Art der Schlüsselbereitstellung handelt, ist dieses Feld derzeit für die FullTransportInterface TLS-Testgruppe erforderlich. Ob Ihr Gerät es ist`pre-provisioned`, `PublicKeyAsciiHexFilePath` ist optional und muss nicht enthalten sein.
Der folgende Block ist ein absoluter Pfad zu der Datei, die den öffentlichen Hex-Byte-Schlüssel enthält, der aus dem `Onboard` privaten Schlüssel extrahiert wurde.
```
3059 3013 0607 2a86 48ce 3d02 0106 082a
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c
```
Wenn Ihr öffentlicher Schlüssel im.der-Format vorliegt, können Sie den öffentlichen Schlüssel direkt hexcodieren, um die Hex-Datei zu generieren.
Um die Hex-Datei aus einem öffentlichen .der-Schlüssel zu generieren, geben Sie den folgenden Befehl ein: **xxd**
```
xxd -p pubkey.der > outFile
```
Wenn Ihr öffentlicher Schlüssel im.pem-Format vorliegt, können Sie die Base64-codierten Kopf- und Fußzeilen extrahieren und in das Binärformat dekodieren. Anschließend kodieren Sie die binäre Zeichenfolge hexadezimal, um die Hex-Datei zu generieren.
Gehen Sie wie folgt vor, um eine Hex-Datei für einen öffentlichen PEM-Schlüssel zu generieren:
1. Führen Sie den folgenden **base64** Befehl aus, um die Base64-Kopf- und Fußzeile aus dem öffentlichen Schlüssel zu entfernen. Der dekodierte Schlüssel mit dem Namen wird `base64key` dann in die Datei ausgegeben: `pubkey.der`
```
base64 —decode base64key > pubkey.der
```
1. Führen Sie den folgenden **xxd** Befehl aus, um in das Hex-Format `pubkey.der` zu konvertieren. Der resultierende Schlüssel wird gespeichert als `outFile`
```
xxd -p pubkey.der > outFile
```
** `devices.secureElementConfig.PublicDeviceCertificateArn` **
Der ARN des Zertifikats von Ihrem sicheren Element, in das hochgeladen wird AWS IoT Core. Informationen zum Hochladen Ihres Zertifikats auf AWS IoT Core finden Sie unter [X.509-Client-Zertifikate](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html) im *AWS IoT Developer* Guide.
** `devices.secureElementConfig.SecureElementSerialNumber` **
(Optional) Die Seriennummer des sicheren Elements. Die Seriennummer wird optional verwendet, um Gerätezertifikate für die JITR-Schlüsselbereitstellung zu erstellen.
** `devices.secureElementConfig.preProvisioned` **
(Optional) Legen Sie diese Option auf „Ja“ fest, wenn das Gerät über ein vorab bereitgestelltes sicheres Element mit gesperrten Anmeldeinformationen verfügt, das keine Objekte importieren, erstellen oder zerstören kann. Wenn dieses Attribut auf **Ja** gesetzt ist, müssen Sie die entsprechenden pkcs11-Labels angeben.
** `devices.secureElementConfig.pkcs11JITPCodeVerifyRootCertSupport` **
(Optional) Auf **Ja** setzen, wenn die PKCS11 Core-Implementierung des Geräts Speicher für JITP unterstützt. Dadurch wird der `codeverify` JITP-Test beim Testen von Core-PKCS 11 aktiviert, und es müssen die PKCS 11-Labels für den Codeverifizierungsschlüssel, das JITP-Zertifikat und das Stammzertifikat bereitgestellt werden.
** `identifiers` **
(Optional) Ein Array beliebiger Namen-Wert-Paare. Sie können diese Werte in den im nächsten Abschnitt beschriebenen Build- und Flash-Befehlen verwenden.
# Konfiguration von Build-, Flash- und Testeinstellungen
IDT for FreeRTOS erstellt Tests automatisch und überträgt sie auf Ihr Board. Um dies zu aktivieren, müssen Sie IDT so konfigurieren, dass die Build- und Flash-Befehle für Ihre Hardware ausgeführt werden. Die Einstellungen für den Build- und den Flash-Befehl werden in der `userdata.json`-Vorlagendatei im Ordner `config` konfiguriert.
# Konfigurieren von Einstellungen für das Testen von Geräten
Build-, Flash- und Testeinstellungen werden in der `configs/userdata.json`-Datei vorgenommen. Das folgende JSON-Beispiel zeigt, wie Sie IDT für FreeRTOS konfigurieren können, um mehrere Geräte zu testen:
```
{
"sourcePath": "",
"retainModifiedSourceDirectories": true | false,
"freeRTOSVersion": "",
"freeRTOSTestParamConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_param_config.h",
"freeRTOSTestExecutionConfigPath": "{{testData.sourcePath}}/path/from/source/path/to/test_execution_config.h",
"buildTool": {
"name": "your-build-tool-name",
"version": "your-build-tool-version",
"command": [
" -any-additional-flags {{testData.sourcePath}}"
]
},
"flashTool": {
"name": "your-flash-tool-name",
"version": "your-flash-tool-version",
"command": [
" -any-additional-flags {{testData.sourcePath}} -any-additional-flags"
]
},
"testStartDelayms": 0,
"echoServerConfiguration": {
"keyGenerationMethod": "EC | RSA",
"serverPort": 9000
},
"otaConfiguration": {
"otaE2EFirmwarePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process",
"otaPALCertificatePath": "/path/to/ota/pal/certificate/on/device",
"deviceFirmwarePath" : "/path/to/firmware/image/name/on/device",
"codeSigningConfiguration": {
"signingMethod": "AWS | Custom",
"signerHashingAlgorithm": "SHA1 | SHA256",
"signerSigningAlgorithm": "RSA | ECDSA",
"signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file",
"untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier",
"signerCertificateFileName": "signerCertificate-file-name",
"compileSignerCertificate": true | false,
// ***********Use signerPlatform if you choose AWS for signingMethod***************
"signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF"
]
}
},
**********
This section is used for PKCS #11 labels of private key, public key, device certificate, code verification key, JITP certificate, and root certificate.
When configuring PKCS11, you set up labels and you must provide the labels of the device certificate, public key,
and private key for the key generation type (EC or RSA) it was created with. If your device supports PKCS11 storage of JITP certificate,
code verification key, and root certificate, set 'pkcs11JITPCodeVerifyRootCertSupport' to 'Yes' in device.json and provide the corresponding labels.
**********
"pkcs11LabelConfiguration":{
"pkcs11LabelDevicePrivateKeyForTLS": "",
"pkcs11LabelDevicePublicKeyForTLS": "",
"pkcs11LabelDeviceCertificateForTLS": "",
"pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS": "",
"pkcs11LabelPreProvisionedECDevicePublicKeyForTLS": "",
"pkcs11LabelPreProvisionedECDeviceCertificateForTLS": "",
"pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS": "",
"pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS": "",
"pkcs11LabelPreProvisionedRSADeviceCertificateForTLS": "",
"pkcs11LabelCodeVerifyKey": "",
"pkcs11LabelJITPCertificate": "",
"pkcs11LabelRootCertificate": ""
}
}
```
Im Folgenden werden die in der `userdata.json`-Datei verwendeten Attribute aufgelistet:
** `sourcePath` **
Der Pfad zum Stammverzeichnis des portierten FreeRTOS-Quellcodes.
** `retainModifiedSourceDirectories` **
(Optional) Überprüft, ob die modifizierten Quellverzeichnisse beibehalten werden sollen, die beim Erstellen und Flashen zu Debugging-Zwecken verwendet wurden. Wenn auf gesetzt`true`, erhalten die geänderten Quellverzeichnisse den Namen RetainedSrc und befinden sich bei jedem Testgruppenlauf in den Ergebnisprotokollordnern. Wenn nicht enthalten, ist das Feld standardmäßig auf eingestellt. `false`
** `freeRTOSTestParamConfigPath` **
Der Pfad zur `test_param_config.h` Datei für die FreeRTOS-Libraries-Integration-Tests Integration. Diese Datei muss die `{{testData.sourcePath}}` Platzhaltervariable verwenden, um sie relativ zum Quellcode-Stammverzeichnis zu machen. AWS IoT Device Tester verwendet die Parameter in dieser Datei, um die Tests zu konfigurieren.
** `freeRTOSTestExecutionConfigPath` **
Der Pfad zur `test_execution_config.h` Datei für die FreeRTOS-Libraries-Integration-Tests Integration. Diese Datei muss die `{{testData.sourcePath}}` Platzhaltervariable verwenden, um sie relativ zum Repository-Stamm zu machen. AWS IoT Device Tester verwendet diese Datei, um zu kontrollieren, welche Tests ausgeführt werden müssen.
** `freeRTOSVersion` **
Die Version von FreeRTOS, einschließlich der Patch-Version, die in Ihrer Implementierung verwendet wurde. Informationen zu den [FreeRTOS-Versionen, AWS IoT Device Tester die mit FreeRTOS kompatibel sind, finden Sie unter Unterstützte](https://docs.aws.amazon.com/freertos/latest/userguide/dev-test-versions-afr.html) Versionen von for FreeRTOS. AWS IoT Device Tester
** `buildTool` **
Der Befehl zum Erstellen Ihres Quellcodes. Alle Verweise auf den Quellcodepfad im Build-Befehl müssen durch die AWS IoT Device Tester Variable ersetzt werden`{{testData.sourcePath}}`. Verwenden Sie den `{{config.idtRootPath}}` Platzhalter, um relativ zum AWS IoT Device Tester Stammpfad auf ein Build-Skript zu verweisen.
** `flashTool` **
Der Befehl, um ein Bild auf Ihr Gerät zu flashen. Alle Verweise auf den Quellcodepfad im Flash-Befehl müssen durch die AWS IoT Device Tester Variable `{{testData.sourcePath}}` ersetzt werden. Verwenden Sie den `{{config.idtRootPath}}` Platzhalter, um auf ein Flash-Skript relativ zum AWS IoT Device Tester Stammpfad zu verweisen.
Die neue Struktur der Integrationstests mit FRQ 2.0 erfordert keine Pfadvariablen wie `{{enableTests}}` und. `{{buildImageName}}` Die OTA-End-to-End-Tests werden mit den im [ FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests/blob/main/config_template/) GitHub Repository bereitgestellten Konfigurationsvorlagen ausgeführt. Wenn die Dateien im GitHub Repository in Ihrem übergeordneten Quellprojekt vorhanden sind, wird der Quellcode zwischen den Tests nicht geändert. Wenn ein anderes Build-Image für OTA End to End benötigt wird, müssen Sie dieses Image im Build-Skript erstellen und es in der unter angegebenen `userdata.json` Datei angeben`otaConfiguration`.
** `testStartDelayms` **
Gibt an, wie viele Millisekunden der FreeRTOS-Testläufer wartet, bevor er mit der Ausführung von Tests beginnt. Dies kann nützlich sein, wenn das zu testende Gerät aufgrund von Netzwerk- oder anderen Latenzproblemen wichtige Testinformationen ausgibt, bevor IDT die Möglichkeit hat, eine Verbindung herzustellen und mit der Protokollierung zu beginnen. Dieser Wert gilt nur für FreeRTOS-Testgruppen und nicht für andere Testgruppen, die den FreeRTOS-Testrunner nicht verwenden, wie z. B. die OTA-Tests. Wenn Sie einen Fehler im Zusammenhang mit den **erwarteten 10, aber 5 erhalten haben**, sollte dieses Feld auf 5000 gesetzt werden.
** `echoServerConfiguration` **
Die Konfiguration zur Einrichtung des Echoservers für den TLS-Test. Dies ist ein Pflichtfeld.
** `keyGenerationMethod` **
Der Echoserver ist mit dieser Option konfiguriert. Die Optionen sind EC oder RSA.
** `serverPort` **
Die Portnummer, auf der der Echo-Server läuft.
** `otaConfiguration` **
Die Konfiguration für OTA PAL- und OTA E2E-Tests. Dies ist ein Pflichtfeld.
**`otaE2EFirmwarePath`**
Pfad zum OTA-Bin-Image, das IDT für die OTA-End-to-End-Tests verwendet.
** `otaPALCertificatePath` **
Der Pfad zum Zertifikat für den OTA-PAL-Test auf dem Gerät. Dies wird verwendet, um die Signatur zu überprüfen. Zum Beispiel **ecdsa-sha256-signer.crt.pem**.
** `deviceFirmwarePath` **
Der Pfad zum fest codierten Namen für das Firmware-Image, das gestartet werden soll. Wenn Ihr Gerät das Dateisystem NICHT für den Firmware-Start verwendet, geben Sie dieses Feld als an`'NA'`. Wenn Ihr Gerät das Dateisystem für den Firmware-Start verwendet, geben Sie den Pfad oder den Namen des Firmware-Startabbilds an.
** `codeSigningConfiguration` **
** `signingMethod` **
Die Code-Signaturmethode. Mögliche Werte sind AWS oder Benutzerdefiniert.
Verwenden Sie für die Regionen Peking und Ningxia die Option Benutzerdefiniert. AWS Codesignatur wird in dieser Region nicht unterstützt.
** `signerHashingAlgorithm` **
Der auf dem Gerät unterstützte Hashing-Algorithmus. Die möglichen Wert sind `SHA1` oder `SHA256`.
** `signerSigningAlgorithm` **
Der auf dem Gerät unterstützte Signaturalgorithmus. Die möglichen Wert sind `RSA` oder `ECDSA`.
** `signerCertificate` **
Das für OTA verwendete vertrauenswürdige Zertifikat. Verwenden Sie für die AWS Codesignaturmethode den Amazon-Ressourcennamen (ARN) für das vertrauenswürdige Zertifikat, das in den AWS Certificate Manager hochgeladen wurde. Verwenden Sie für die benutzerdefinierte Codesignaturmethode den absoluten Pfad zur Zertifikatsdatei des Unterzeichners. Informationen zum Erstellen eines vertrauenswürdigen Zertifikats finden Sie unter [Erstellen eines Codesignaturzertifikats.](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html)
** `untrustedSignerCertificate` **
Der ARN oder Dateipfad für ein zweites Zertifikat, das in einigen OTA-Tests als nicht vertrauenswürdiges Zertifikat verwendet wird. Informationen zum Erstellen eines Zertifikats finden Sie unter [Erstellen eines](https://docs.aws.amazon.com//freertos/latest/userguide/ota-code-sign-cert.html) Codesignaturzertifikats.
** `signerCertificateFileName` **
Der Dateiname des Codesignaturzertifikats auf dem Gerät. Dieser Wert muss mit dem Dateinamen übereinstimmen, den Sie bei der Ausführung des `aws acm import-certificate` Befehls angegeben haben.
** `compileSignerCertificate` **
Boolescher Wert, der den Status des Signaturverifizierungszertifikats bestimmt. Gültige Werte sind `true` und `false`.
Setzen Sie diesen Wert auf **true**, wenn das Zertifikat zur Überprüfung der Signatur des Codesigners nicht bereitgestellt oder geflasht wurde. Es muss in das Projekt kompiliert werden. AWS IoT Device Tester ruft das vertrauenswürdige Zertifikat ab und kompiliert es in. `aws_codesigner_certificate.h`
** `signerPlatform` **
Der Signier- und Hash-Algorithmus, den AWS Code Signer bei der Erstellung des OTA-Aktualisierungsjobs verwendet. Derzeit lauten die möglichen Werte für dieses Feld `AmazonFreeRTOS-TI-CC3220SF` und `AmazonFreeRTOS-Default`.
+ Wählen Sie bei `SHA1` und `RSA` `AmazonFreeRTOS-TI-CC3220SF` aus.
+ Wählen Sie bei `SHA256` und `ECDSA` `AmazonFreeRTOS-Default` aus.
+ Wenn Sie `SHA256` \$1 `RSA` oder `SHA1` \$1 `ECDSA` für Ihre Konfiguration benötigen, kontaktieren Sie uns, um weitere Unterstützung zu erhalten.
+ Konfigurieren Sie `signCommand`, wenn Sie `Custom` für `signingMethod` ausgewählt haben.
** `signCommand` **
Die beiden Platzhalter „`{{inputImageFilePath}}`“ und „`{{outputSignatureFilePath}}`“ sind im Befehl erforderlich. `{{inputImageFilePath}}` ist der Dateipfad des von IDT erstellten Images, das signiert werden soll. `{{outputSignatureFilePath}} ` ist der Dateipfad der Signatur, der vom Skript generiert wird.
** `pkcs11LabelConfiguration` **
PKCS11 Für die Labelkonfiguration ist mindestens ein Satz von Bezeichnungen aus Gerätezertifikatslabel, Etikett für öffentlichen Schlüssel und Bezeichnung für private Schlüssel erforderlich, um die PKCS11 Testgruppen ausführen zu können. Die erforderlichen PKCS11 Labels basieren auf Ihrer Gerätekonfiguration in der `device.json` Datei. Wenn „pre-provisioned“ auf **„Ja“** gesetzt ist`device.json`, muss es sich bei den erforderlichen Bezeichnungen um eine der folgenden Kategorien handeln, je nachdem, was für die PKCS11 Funktion ausgewählt wurde.
+ `PreProvisionedEC`
+ `PreProvisionedRSA`
Wenn pre-provisioned auf **Nein** in gesetzt ist`device.json`, lauten die erforderlichen Labels:
+ `pkcs11LabelDevicePrivateKeyForTLS`
+ `pkcs11LabelDevicePublicKeyForTLS`
+ `pkcs11LabelDeviceCertificateForTLS`
Die folgenden drei Bezeichnungen sind nur erforderlich, wenn Sie `pkcs11JITPCodeVerifyRootCertSupport` in Ihrer **`device.json`Datei Ja** für auswählen.
+ `pkcs11LabelCodeVerifyKey`
+ `pkcs11LabelRootCertificate`
+ `pkcs11LabelJITPCertificate`
Die Werte für diese Felder sollten den Werten entsprechen, die im [FreeRTOS Porting](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html) Guide definiert sind.
** `pkcs11LabelDevicePrivateKeyForTLS` **
(Optional) Dieses Label wird für das PKCS \$111 -Label des privaten Schlüssels verwendet. Bei Geräten mit integrierter Schlüsselbereitstellung und Importunterstützung wird dieses Label zu Testzwecken verwendet. Diese Bezeichnung kann sich von der Bezeichnung unterscheiden, die für den vorab bereitgestellten Fall definiert wurde. Wenn Sie die Schlüsselbereitstellung auf **Nein** und die Vorbereitstellung auf **Ja** eingestellt haben, ist dies undefiniert`device.json`.
** `pkcs11LabelDevicePublicKeyForTLS` **
(Optional) Dieses Label wird für das PKCS \$111 -Label des öffentlichen Schlüssels verwendet. Bei Geräten mit integrierter Schlüsselbereitstellung und Importunterstützung wird dieses Label zu Testzwecken verwendet. Diese Bezeichnung kann sich von der Bezeichnung unterscheiden, die für den vorab bereitgestellten Fall definiert wurde. Wenn Sie die Schlüsselbereitstellung auf **Nein** und die Vorbereitstellung auf **Ja** eingestellt haben, ist dies undefiniert`device.json`.
** `pkcs11LabelDeviceCertificateForTLS` **
(Optional) Diese Bezeichnung wird für das PKCS \$111 -Label des Gerätezertifikats verwendet. Bei Geräten mit integrierter Schlüsselbereitstellung und Importunterstützung wird dieses Etikett zu Testzwecken verwendet. Diese Bezeichnung kann sich von der Bezeichnung unterscheiden, die für den vorab bereitgestellten Fall definiert wurde. Wenn Sie die Schlüsselbereitstellung auf **Nein** und die Vorbereitstellung auf **Ja** eingestellt haben, ist dies undefiniert`device.json`.
** `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS` **
(Optional) Dieses Label wird für das PKCS \$111 -Label des privaten Schlüssels verwendet. Für Geräte mit sicheren Elementen oder Hardwarebeschränkungen wird dieses Gerät mit einer anderen Bezeichnung versehen, um die AWS IoT Anmeldeinformationen zu schützen. Wenn Ihr Gerät die Vorabbereitstellung mit einem EC-Schlüssel unterstützt, geben Sie dieses Etikett an. Wenn PreProvisioned auf **Ja** gesetzt ist`device.json`, muss dieses Label oder beides angegeben werden. `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS` Dieses Label kann sich von dem unterscheiden, das für Onboard- und Importfälle definiert wurde.
** `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS` **
(Optional) Dieses Label wird für das PKCS \$111 -Label des öffentlichen Schlüssels verwendet. Für Geräte mit sicheren Elementen oder Hardwarebeschränkungen wird dieses Gerät mit einer anderen Bezeichnung versehen, um die AWS IoT Anmeldeinformationen zu schützen. Wenn Ihr Gerät die Vorabbereitstellung mit einem EC-Schlüssel unterstützt, geben Sie dieses Etikett an. Wenn PreProvisioned auf **Ja** gesetzt ist`device.json`, muss dieses Label oder beides angegeben werden. `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS` Dieses Label kann sich von dem unterscheiden, das für Onboard- und Importfälle definiert wurde.
** `pkcs11LabelPreProvisionedECDeviceCertificateForTLS` **
(Optional) Dieses Label wird für das PKCS \$111 -Label des Gerätezertifikats verwendet. Für Geräte mit sicheren Elementen oder Hardwarebeschränkungen wird dieses Gerät mit einer anderen Bezeichnung versehen, um die AWS IoT Anmeldeinformationen zu schützen. Wenn Ihr Gerät die Vorabbereitstellung mit einem EC-Schlüssel unterstützt, geben Sie dieses Etikett an. Wenn PreProvisioned auf **Ja** gesetzt ist`device.json`, muss dieses Label oder beides angegeben werden. `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS` Dieses Label kann sich von dem unterscheiden, das für Onboard- und Importfälle definiert wurde.
** `pkcs11LabelPreProvisionedRSADevicePrivateKeyForTLS` **
(Optional) Dieses Label wird für das PKCS \$111 -Label des privaten Schlüssels verwendet. Für Geräte mit sicheren Elementen oder Hardwarebeschränkungen wird dieses Gerät mit einer anderen Bezeichnung versehen, um die AWS IoT Anmeldeinformationen zu schützen. Wenn Ihr Gerät die Vorabbereitstellung mit einem RSA-Schlüssel unterstützt, geben Sie diese Bezeichnung an. Wenn PreProvisioned auf **Ja** gesetzt ist`device.json`, muss dieses Label oder beide angegeben werden. `pkcs11LabelPreProvisionedECDevicePrivateKeyForTLS`
** `pkcs11LabelPreProvisionedRSADevicePublicKeyForTLS` **
(Optional) Dieses Label wird für das PKCS \$111 -Label des öffentlichen Schlüssels verwendet. Für Geräte mit sicheren Elementen oder Hardwarebeschränkungen wird dieses Gerät mit einer anderen Bezeichnung versehen, um die AWS IoT Anmeldeinformationen zu schützen. Wenn Ihr Gerät die Vorabbereitstellung mit einem RSA-Schlüssel unterstützt, geben Sie diese Bezeichnung an. Wenn PreProvisioned auf **Ja** gesetzt ist`device.json`, muss dieses Label oder beide angegeben werden. `pkcs11LabelPreProvisionedECDevicePublicKeyForTLS`
** `pkcs11LabelPreProvisionedRSADeviceCertificateForTLS` **
(Optional) Diese Bezeichnung wird für das PKCS \$111 -Label des Gerätezertifikats verwendet. Für Geräte mit sicheren Elementen oder Hardwarebeschränkungen wird dieses Gerät mit einer anderen Bezeichnung versehen, um die AWS IoT Anmeldeinformationen zu schützen. Wenn Ihr Gerät die Vorabbereitstellung mit einem RSA-Schlüssel unterstützt, geben Sie diese Bezeichnung an. Wenn PreProvisioned auf **Ja** gesetzt ist`device.json`, muss dieses Label oder beide angegeben werden. `pkcs11LabelPreProvisionedECDeviceCertificateForTLS`
** `pkcs11LabelCodeVerifyKey` **
(Optional) Diese Bezeichnung wird für das PKCS \$111 -Label des Codeverifizierungsschlüssels verwendet. Wenn Ihr Gerät über PKCS \$111 -Speicherunterstützung für das JITP-Zertifikat, den Codeverifizierungsschlüssel und das Stammzertifikat verfügt, geben Sie dieses Etikett an. Wenn `pkcs11JITPCodeVerifyRootCertSupport` in auf **Ja** gesetzt `device.json` ist, muss dieses Etikett angegeben werden.
** `pkcs11LabelJITPCertificate` **
(Optional) Diese Bezeichnung wird für das PKCS \$111 -Label des JITP-Zertifikats verwendet. Wenn Ihr Gerät über PKCS \$111 -Speicherunterstützung für das JITP-Zertifikat, den Codeverifizierungsschlüssel und das Stammzertifikat verfügt, geben Sie dieses Etikett an. Wenn `pkcs11JITPCodeVerifyRootCertSupport` in auf **Ja** gesetzt `device.json` ist, muss dieses Etikett angegeben werden.
# IDT für FreeRTOS-Variablen
Die Befehle zum Erstellen Ihres Codes und zum Flashen des Geräts erfordern möglicherweise Konnektivität oder andere Informationen zu Ihren Geräten, um erfolgreich ausgeführt zu werden. AWS IoT Device Tester ermöglicht es Ihnen, Geräteinformationen in Flash zu referenzieren und Befehle zu erstellen mit [JsonPath](https://goessner.net/articles/JsonPath/). Mithilfe einfacher JsonPath Ausdrücke können Sie die erforderlichen Informationen abrufen, die in Ihrer `device.json` Datei angegeben sind.
## Pfadvariablen
IDT for FreeRTOS definiert die folgenden Pfadvariablen, die in Befehlszeilen und Konfigurationsdateien verwendet werden können:
** `{{testData.sourcePath}}` **
Wird auf den Quellcodepfad erweitert. Wenn Sie diese Variable verwenden, muss sie sowohl in den Flash- als auch in den Build-Befehlen verwendet werden.
** `{{device.connectivity.serialPort}}` **
Wird auf die serielle Schnittstelle erweitert.
** `{{device.identifiers[?(@.name == 'serialNo')].value[0]}}` **
Wird zur Seriennummer Ihres Geräts erweitert.
** `{{config.idtRootPath}}` **
Erweitert auf den Stammpfad AWS IoT Device Tester .
# Benutzeroberfläche für IDT für FreeRTOS Qualification Suite 2.0 (FRQ 2.0)
AWS IoT Device Tester for FreeRTOS (IDT for FreeRTOS) umfasst eine webbasierte Benutzeroberfläche (UI), über die Sie mit der IDT-Befehlszeilenanwendung und den zugehörigen Konfigurationsdateien interagieren können. Sie verwenden die Benutzeroberfläche von IDT for FreeRTOS, um eine neue Konfiguration für Ihr Gerät zu erstellen oder eine bestehende zu ändern. Sie können die Benutzeroberfläche auch verwenden, um die IDT-Anwendung aufzurufen und die FreeRTOS-Tests auf Ihrem Gerät auszuführen.
Hinweise zur Verwendung der Befehlszeile zum Ausführen von Qualifikationstests finden Sie unter. [Erster Test Ihres Mikrocontroller-Boards](lts-qual-steps.md)
In diesem Abschnitt werden die Voraussetzungen für die Benutzeroberfläche von IDT for FreeRTOS und die Ausführung von Qualifikationstests über die Benutzeroberfläche beschrieben.
**Topics**
+ [Richten Sie die IDT-Voraussetzungen ein](#lts-dev-tester-ui-prereqs)
+ [AWS Konfigurieren Sie die Anmeldeinformationen für die Verwendung der IDT-Benutzeroberfläche](lts-configure-aws-credentials.md)
+ [Öffnen Sie die Benutzeroberfläche von IDT for FreeRTOS](lts-open-idt-ui.md)
+ [Erstellen Sie eine neue Konfiguration](lts-create-new-configuration.md)
+ [Ändern Sie eine bestehende Konfiguration](lts-modify-existing-configuration.md)
+ [Führen Sie Qualifizierungstests durch](lts-run-tests-from-ui.md)
## Richten Sie die IDT-Voraussetzungen ein
Um Tests über die Benutzeroberfläche von AWS IoT Device Tester (IDT) for FreeRTOS durchzuführen, müssen Sie die Voraussetzungen auf der [Richten Sie die Voraussetzungen für die LTS-Qualifikation ein](lts-idt-dev-tester-prereqs.md) Seite für IDT FreeRTOS Qualification (FRQ) 2.x erfüllen.
# AWS Konfigurieren Sie die Anmeldeinformationen für die Verwendung der IDT-Benutzeroberfläche
Sie müssen Ihre IAM-Benutzeranmeldedaten für den AWS Benutzer konfigurieren, in [Erstelle ein Konto AWS](lts-idt-dev-tester-prereqs.md#lts-config-aws-account) dem Sie sie erstellt haben. 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 Anmeldeinformationsdatei hängt vom verwendeten Betriebssystem ab:
+ **macOS und 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 = your_access_key_id
aws_secret_access_key = your_secret_access_key
```
**Anmerkung**
Wenn Sie das Profil nicht verwenden, müssen Sie den `default` AWS Profilnamen in der Benutzeroberfläche von IDT for FreeRTOS angeben. Weitere Informationen zu Profilen finden Sie unter [Konfiguration und Einstellungen für Anmeldeinformationsdateien](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.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. Die Benutzeroberfläche von IDT for FreeRTOS verwendet die `AWS_SECRET_ACCESS_KEY` Umgebungsvariablen `AWS_ACCESS_KEY_ID` und, um Ihre Anmeldeinformationen zu speichern. AWS
Um diese Variablen auf Linux, macOS oder Unix festzulegen, verwenden Sie **export**:
```
export AWS_ACCESS_KEY_ID=your_access_key_id
export AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
In Windows können Sie die Variablen mit **set** festlegen:
```
set AWS_ACCESS_KEY_ID=your_access_key_id
set AWS_SECRET_ACCESS_KEY=your_secret_access_key
```
# Öffnen Sie die Benutzeroberfläche von IDT for FreeRTOS
In diesem Thema wird erklärt, wie Sie die Benutzeroberfläche von IDT for FreeRTOS öffnen, um die FreeRTOS Qualification Suite zu verwenden.
**Um die Benutzeroberfläche von IDT für FreeRTOS zu öffnen**
1. Laden Sie eine unterstützte Version von IDT for FreeRTOS herunter. Extrahieren Sie dann das heruntergeladene Archiv in ein Verzeichnis, für das Sie Lese- und Schreibberechtigungen haben.
1. Navigieren Sie zum Installationsverzeichnis von IDT for FreeRTOS:
```
cd devicetester-extract-location/bin
```
1. Führen Sie den folgenden Befehl aus, um die Benutzeroberfläche von IDT for FreeRTOS zu öffnen:
------
#### [ Linux ]
```
.devicetester_ui_linux_x86-64
```
------
#### [ Windows ]
```
./devicetester_ui_win_x64-64
```
------
#### [ macOS ]
```
./devicetester_ui_mac_x86-64
```
**Anmerkung**
Gehen Sie in macOS zu **Systemeinstellungen -> Sicherheit und Datenschutz, damit Ihr System** die Benutzeroberfläche ausführen kann. Wenn Sie die Tests ausführen, müssen Sie dies möglicherweise noch dreimal durchführen. das
------
Die Benutzeroberfläche von IDT for FreeRTOS wird in Ihrem Standardbrowser geöffnet. Die neuesten drei Hauptversionen der folgenden Browser unterstützen die Benutzeroberfläche:
+ Google Chrome
+ Mozilla Firefox
+ Microsoft Edge
+ Apple Safari für macOS
**Anmerkung**
Für eine bessere Benutzererfahrung empfehlen wir Google Chrome oder Mozilla Firefox, um auf die Benutzeroberfläche von IDT for FreeRTOS zuzugreifen. Microsoft Internet Explorer wird von der Benutzeroberfläche nicht unterstützt.
**Wichtig**
Sie müssen Ihre AWS Anmeldeinformationen konfigurieren, bevor Sie die Benutzeroberfläche öffnen. Wenn Sie Ihre Anmeldeinformationen nicht konfiguriert haben, schließen Sie das Browserfenster von IDT for FreeRTOS UI, folgen Sie den Schritten unter und öffnen Sie dann die IDT for FreeRTOS UI erneut. [AWS Konfigurieren Sie die Anmeldeinformationen für die Verwendung der IDT-Benutzeroberfläche](lts-configure-aws-credentials.md)
# Erstellen Sie eine neue Konfiguration
Wenn Sie zum ersten Mal Benutzer sind, müssen Sie eine neue Konfiguration erstellen, um die JSON-Konfigurationsdateien einzurichten, die IDT for FreeRTOS zum Ausführen von Tests benötigt. Sie können dann Tests ausführen oder die erstellte Konfiguration ändern.
Beispiele für die `userdata.json` Dateien `config.json``device.json`, und finden Sie unter[Erster Test Ihres Mikrocontroller-Boards](lts-qual-steps.md).
**So erstellen Sie eine neue Konfiguration:**
1. Öffnen Sie in der Benutzeroberfläche von IDT for FreeRTOS das Navigationsmenü und wählen Sie Neue Konfiguration **erstellen** aus.
![\[Device Tester for FreeRTOS-Schnittstelle mit der Schaltfläche „Neue Konfiguration erstellen“ und Informationen zum automatisierten Selbsttest von Mikrocontrollern.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/gsg-create-configuration.png)
1. Folgen Sie dem Konfigurationsassistenten, um die IDT-Konfigurationseinstellungen einzugeben, die für die Durchführung von Qualifikationstests verwendet werden. Der Assistent konfiguriert die folgenden Einstellungen in JSON-Konfigurationsdateien, die sich im `devicetester-extract-location/config` Verzeichnis befinden.
+ **Geräteeinstellungen** — Die Gerätepool-Einstellungen für die zu testenden Geräte. Diese Einstellungen werden in den `sku` Feldern `id` und konfiguriert, und die **Geräte** blockieren für den Gerätepool in der `config.json` Datei.
![\[Device Tester for FreeRTOS Konfigurationsbildschirm mit Identifier- und SKU-Feldern zur Konfiguration eines Gerätepools, Geräteeinstellungsoptionen wie Verbindungsmethode, Schlüsselbereitstellung, PKCS #11 -Einstellungen, Eingabefeldern für Gerätedetails und Steuerelementen zum Hinzufügen von Geräten oder Kennungen.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/gsg-device-settings.png)
+ **AWS Kontoeinstellungen** — Die AWS-Konto Informationen, die IDT for FreeRTOS verwendet, um AWS Ressourcen während Testläufen zu erstellen. Diese Einstellungen sind in der Datei konfiguriert. `config.json`
![\[AWS-Konto Einstellungsseite mit Feldern für die Kontoregion, den Speicherort der Anmeldeinformationen als Datei oder Umgebung und den Profilnamen\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/gsg-account-settings.png)
+ **FreeRTOS-Implementierung** — Der absolute Pfad zum FreeRTOS-Repository und zum portierten Code sowie die FreeRTOS-Version, auf der Sie IDT FRQ ausführen möchten. Die Pfade zu den Ausführungs- und Parameter-Config-Header-Dateien aus dem Repository. `FreeRTOS-Libraries-Integration-Tests` GitHub Die Build- und Flash-Befehle für Ihre Hardware, mit denen IDT automatisch Tests auf Ihrem Board erstellen und flashen kann. Diese Einstellungen sind in der `userdata.json` Datei konfiguriert.
![\[Abschnitt zur Konfiguration der FreeRTOS-Implementierung mit Repository-Pfaden, Testausführungspfaden, FreeRTOS-Version, Build-Tool-Details und Flash-Tool-Einstellungen.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/gsg-implementation-settings.png)
+ **PKCS \$111 -Labels und Echo Server** — Die [PKCS \$111](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-pkcs.html) -Labels, die den auf Ihrer Hardware bereitgestellten Schlüsseln entsprechen, basierend auf der Schlüsselfunktionalität und der Methode zur Schlüsselbereitstellung. Die Konfigurationseinstellungen des Echoservers für die Transport Interface-Tests. Diese Einstellungen werden in den `device.json` Dateien `userdata.json` und konfiguriert.
![\[PKCS #11 -Labels und Echo-Serverkonfigurationen mit Eingabefeldern für Tastenbeschriftungen, Methode zur Schlüsselgenerierung und Serverportnummer\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/gsg-pkcs11-settings.png)
+ **Over-the-air (OTA) -Updates** — Die Einstellungen, die die OTA-Funktionstests steuern. Diese Einstellungen werden im `features` Block der `userdata.json` Dateien `device.json` und konfiguriert.
![\[Konfigurationsoptionen für das OTA-Update: Tests überspringen, Datenprotokolle, Firmware-Pfade, PAL-Zertifikatspfad, Codesignatur, hash/sign Algorithmen, Unterzeichnerzertifikate, trusted/untrusted Unterzeichnerzertifikatsdatei, Unterzeichnerzertifikat kompilieren, Unterzeichnerplattform.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/gsg-ota-settings.png)
1. **Überprüfen Sie auf der Überprüfungsseite Ihre Konfigurationsinformationen.**
![\[Die Konfiguration hat einen Dialog für Device Tester for FreeRTOS erstellt, der Details zum Erstellen einer neuen Testkonfiguration mit Optionen zum Bearbeiten oder Ausführen von Tests anzeigt.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/gsg-configuration-created.png)
**Wenn Sie mit der Überprüfung Ihrer Konfiguration fertig sind, wählen Sie Tests ausführen, um Ihre Qualifizierungstests durchzuführen.**
# Ändern Sie eine bestehende Konfiguration
Wenn Sie bereits Konfigurationsdateien für IDT for FreeRTOS eingerichtet haben, können Sie die Benutzeroberfläche von IDT for FreeRTOS verwenden, um Ihre bestehende Konfiguration zu ändern. Die vorhandenen Konfigurationsdateien müssen sich im Verzeichnis befinden. `devicetester-extract-location/config`
**Um eine Konfiguration zu ändern**
1. Öffnen Sie in der Benutzeroberfläche von IDT for FreeRTOS das Navigationsmenü und wählen Sie **Bestehende Konfiguration bearbeiten** aus.
Das Konfigurations-Dashboard zeigt Informationen zu Ihren vorhandenen Konfigurationseinstellungen an. Wenn eine Konfiguration falsch oder nicht verfügbar ist, lautet der Status für diese Konfiguration`Error validating configuration`.
![\[Konfigurationsbildschirm mit den Abschnitten Gerät AWS-Konto, FreeRTOS-Implementierung, PKCS-Labels und Echo-Server, over-the-air Updates und Testlaufeinstellungen, die den gültigen Status anzeigen.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/modify-existing-configuration.png)
1. Gehen Sie wie folgt vor, um eine bestehende Konfigurationseinstellung zu ändern:
1. Wählen Sie den Namen einer Konfigurationseinstellung, um die zugehörige Einstellungsseite zu öffnen.
1. Ändern Sie die Einstellungen und wählen Sie dann **Speichern**, um die entsprechende Konfigurationsdatei neu zu generieren.
1. Um die IDT for FreeRTOS-Testlaufeinstellungen zu ändern, wählen Sie in der **Bearbeitungsansicht IDT-Testlaufeinstellungen aus**:
![\[Dialogfeld mit IDT-Testlaufeinstellungen mit Optionen für die Testauswahl, das Überspringen von Testgruppen, den Timeout-Multiplikator und das Stoppen beim ersten Fehler.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/idt-testrun-settings.png)
Nachdem Sie die Änderung Ihrer Konfiguration abgeschlossen haben, stellen Sie sicher, dass alle Ihre Konfigurationseinstellungen die Validierung bestehen. Wenn der Status für jede Konfigurationseinstellung lautet`Valid`, können Sie Ihre Qualifizierungstests mit dieser Konfiguration ausführen.
# Führen Sie Qualifizierungstests durch
Nachdem Sie eine Konfiguration für die Benutzeroberfläche von IDT for FreeRTOS erstellt haben, können Sie Ihre Qualifikationstests ausführen.
**Um Qualifizierungstests durchzuführen**
1. Wählen Sie im Navigationsmenü die Option **Tests ausführen aus**.
1. Wählen Sie **Tests starten**, um den Testlauf zu starten. Standardmäßig werden alle zutreffenden Tests für Ihre Gerätekonfiguration ausgeführt. IDT for FreeRTOS generiert einen Qualifikationsbericht, wenn alle Tests abgeschlossen sind.
![\[Die Benutzeroberfläche von Device Tester for FreeRTOS zeigt an, dass noch keine Tests ausgeführt wurden. Sie bietet Optionen zum Erstellen einer neuen Konfiguration, zum Bearbeiten vorhandener Konfigurationen und zum Ausführen von Tests.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/idt-run-tests.png)
IDT for FreeRTOS führt die Qualifikationstests durch. Anschließend werden die Zusammenfassung des Testlaufs und alle Fehler in der **Test** Runner-Konsole angezeigt. Nach Abschluss des Testlaufs können Sie die Testergebnisse und Protokolle an den folgenden Orten einsehen:
+ Die Testergebnisse befinden sich im `devicetester-extract-location/results/execution-id` Verzeichnis.
+ Testprotokolle befinden sich im `devicetester-extract-location/results/execution-id/logs` Verzeichnis.
Weitere Informationen zu Testergebnissen und Protokollen finden Sie unter [Sehen Sie sich das IDT kostenlos an RTOSresults](view-results-lts.md) und[Sehen Sie sich das IDT kostenlos an RTOSlogs](view-logs-lts.md).
![\[Das Ausführungsprotokoll von Device Tester for FreeRTOS zeigt die bestandenen Tests, Testgruppen und Dateipfade für Protokolle und Berichte.\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/idt-results.png)
# Führen Sie die FreeRTOS Qualification 2.0 Suite aus
Verwenden Sie die ausführbare Datei AWS IoT Device Tester for FreeRTOS, um mit IDT for FreeRTOS zu interagieren. In den folgenden Befehlszeilenbeispielen wird veranschaulicht, wie Sie die Qualifikationsprüfungen für einen Gerätepool (Satz identischer Geräte) durchführen.
------
#### [ IDT v4.5.2 and later ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--group-id group-id \
--pool-id your-device-pool \
--test-id test-id \
--userdata userdata.json
```
Führt eine Reihe von Tests in einem Pool von Geräten aus. Die Datei `userdata.json` muss sich im Verzeichnis `devicetester_extract_location/devicetester_freertos_[win|mac|linux]/configs/` befinden.
**Anmerkung**
Wenn Sie IDT for FreeRTOS unter Windows ausführen, verwenden Sie Schrägstriche (/), um den Pfad zur Datei anzugeben. `userdata.json`
Verwenden Sie den folgenden Befehl zum Ausführen einer bestimmten Testgruppe:
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.99.0 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
Die Parameter `suite-id` und `pool-id` sind optional, wenn Sie eine einzige Testsuite in einem einzigen Gerätepool ausführen (d. h. in Ihrer `device.json`-Datei ist nur ein Gerätepool definiert).
Verwenden Sie den folgenden Befehl zum Ausführen eines bestimmten Testfalls in einer Testgruppe:
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
Mit dem Befehl `list-test-cases` können Sie die Testfälle in einer Testgruppe auflisten.
**IDT für FreeRTOS-Befehlszeilenoptionen**
**group-id**
(Optional) Die auszuführenden Testgruppen als kommagetrennte Liste. Bei fehlender Angabe führt IDT alle Testgruppen in der Testsuite aus.
**pool-id**
(Optional) Der zu testende Gerätepool. Dies ist erforderlich, wenn Sie mehrere Gerätepools in `device.json` definieren. Wenn Sie nur einen Gerätepool haben, können Sie diese Option weglassen.
**suite-id**
(Optional) Die auszuführende Test-Suite-Version. Falls nicht angegeben, verwendet IDT die neueste Version im Verzeichnis der Tests auf Ihrem System.
**test-id**
(Optional) Die auszuführenden Tests als kommagetrennte Liste. Wenn angegeben, muss `group-id` eine einzelne Gruppe angeben.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
**h**
Verwenden Sie die Hilfe-Option, um mehr über `run-suite`-Optionen zu erfahren.
**Example**
**Beispiel**
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
## IDT für FreeRTOS-Befehle
Der Befehl IDT for FreeRTOS unterstützt die folgenden Operationen:
------
#### [ IDT v4.5.2 and later ]
** `help` **
Listet Informationen über den angegebenen Befehl auf.
** `list-groups` **
Listet die Gruppen in der jeweiligen Suite auf.
** `list-suites` **
Listet die verfügbaren Suites auf.
** `list-supported-products` **
Listet die unterstützten Produkte und Testsuiteversionen auf.
** `list-supported-versions` **
Listet die FreeRTOS- und Testsuite-Versionen auf, die von der aktuellen IDT-Version unterstützt werden.
** `list-test-cases` **
Listet die Testfälle in einer angegebenen Gruppe auf.
** `run-suite` **
Führt eine Reihe von Tests in einem Pool von Geräten aus.
Verwenden Sie die Option `--suite-id`, um eine Test-Suite-Version anzugeben, oder lassen Sie sie weg, um die neueste Version auf Ihrem System zu verwenden.
Verwenden Sie die `--test-id` um einen einzelnen Testfall auszuführen.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id FreeRTOSVersion --test-id FreeRTOSVersion
```
Ab IDT v3.0.0 sucht IDT online nach neueren Testsuiten. Weitere Informationen finden Sie unter [Test-Suite-Versionen](idt-test-suite-versions.md).
------
# Sehen Sie sich das IDT kostenlos an RTOSresults
Während der Ausführung schreibt IDT Fehler in die Konsole, Protokolldateien und Testberichte. Nachdem IDT die Qualifikations-Testsuite abgeschlossen hat, schreibt es eine Zusammenfassung der Testläufe in die Konsole und erstellt zwei Testberichte. Diese Berichte befinden sich in `devicetester-extract-location/results/execution-id/`. Beide Berichte erfassen die Ergebnisse von der Ausführung der Qualifikations-Testsuite.
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 Version IDT für FreeRTOS.
+ Die getestete FreeRTOS-Version.
+ Die Funktionen von FreeRTOS, die vom Gerät unterstützt werden, basieren auf den bestandenen Tests.
+ SKU und Gerätename, die in der `device.json`-Datei angegeben wurden.
+ Die Funktionen des Geräts, das in der `device.json`-Datei angegeben wurde.
+ Die aggregierte Zusammenfassung der Ergebnisse der Testfälle.
+ Eine Aufschlüsselung der Testfallergebnisse nach Bibliotheken, die basierend auf den Geräteeigenschaften getestet wurden.
Das `FRQ_Report.xml` ist ein Bericht im [JUnit Standard-XML-Format](https://llg.cubic.org/docs/junit/). Sie können ihn in CI/CD 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 Ergebnisse der Testfälle.
+ Eine Aufschlüsselung der Testfallergebnisse nach Bibliotheken, die basierend auf den Geräteeigenschaften getestet wurden.
# Interpretieren Sie die IDT for FreeRTOS-Ergebnisse
Der Berichtsabschnitt in `awsiotdevicetester_report.xml` oder `FRQ_Report.xml` listet die Ergebnisse der durchgeführten Tests auf.
Im ersten XML-Tag `` ist die Gesamtzusammenfassung der Testausführung enthalten. Beispiel:
``
**Im `` Tag verwendete Attribute**
** `name` **
Name der Testsuite
** `time` **
Zeit (in Sekunden), die zur Ausführung der Qualifikations-Suite erforderlich war
** `tests` **
Anzahl der ausgeführten Testfälle
** `failures` **
Anzahl der ausgeführten Testfälle, die den Test nicht bestanden haben
** `errors` **
Die Anzahl der Testfälle, die IDT für FreeRTOS nicht ausführen konnte.
** `disabled` **
Dieses Attribut wird nicht verwendet und kann ignoriert werden.
Wenn es keine Testfallausfälle oder Fehler gibt, erfüllt Ihr Gerät die technischen Voraussetzungen für die Ausführung von FreeRTOS und kann mit Diensten zusammenarbeiten. AWS IoT Wenn Sie Ihr Gerät im AWS Partner-Gerätekatalog auflisten möchten, können Sie diesen Bericht als Qualifikationsnachweis verwenden.
Falls bei Testfällen Fehler auftreten, können Sie den fehlgeschlagenen Testfall identifizieren, indem Sie die XML-Tags von `` überprüfen. Die XML-Tags von `` im ``-Tag zeigen die Ergebniszusammenfassung des Testfalls für eine Testgruppe.
``
Das Format ähnelt dem ``-Tag, weist aber ein zusätzliches Attribut mit dem Namen `skipped` auf, das nicht verwendet wird und ignoriert werden kann. Innerhalb der einzelnen XML-Tags von `` befinden sich ``-Tags für alle Testfälle, die für eine Testgruppe ausgeführt wurden. Beispiel:
``
**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 dies in der `awsiotdevicetester_report.xml` Datei aussieht.
```
```
Als `optional` gekennzeichnete Funktionen sind für die Qualifizierung nicht erforderlich. Die folgenden Codeausschnitte zeigen optionale Funktionen.
```
```
Wenn es keine Testfehler oder Fehler für die erforderlichen Funktionen gibt, erfüllt Ihr Gerät die technischen Voraussetzungen für die Ausführung von FreeRTOS und kann mit Diensten zusammenarbeiten. AWS IoT Wenn Sie Ihr Gerät im [AWS Partner-Gerätekatalog](https://partners.amazonaws.com/qualified-devices) 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. Beispiel:
```
```
Das Format ähnelt dem `` Tag, hat jedoch ein `skipped` Attribut, das nicht verwendet wird und ignoriert werden kann. Innerhalb der einzelnen ``-XML-Tags befinden sich ``-Tags für alle ausgeführten Tests einer Testgruppe. Beispiel:
```
```
**Im `` Tag verwendete Attribute**
** `name` **
Name des Testfalls
** `attempts` **
Gibt an, wie oft IDT für FreeRTOS 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. Beispiel:
```
Reason for the test case failure
Reason for the test case execution error
```
Weitere Informationen finden Sie unter [Beheben von Fehlern in der ](dt-afr-troubleshooting.md).
# Sehen Sie sich das IDT kostenlos an RTOSlogs
Logs, die IDT for FreeRTOS bei der Testausführung generiert, finden Sie unter. `devicetester-extract-location/results/execution-id/logs` Es werden zwei Protokollgruppen generiert:
+ `test_manager.log`
Enthält von IDT für FreeRTOS generierte Protokolle (z. B. Protokolle zur Konfiguration und Berichtserstellung).
+ `test_group_id/test_case_id/test_case_id.log`
Die Protokolldatei für einen Testfall, einschließlich der Ausgabe des zu testenden Geräts. Die Protokolldatei wird nach der Testgruppe und dem ausgeführten Testfall benannt.
# IDT mit FreeRTOS Qualification Suite 1.0 (FRQ 1.0)
**Wichtig**
Stand Oktober 2022 generiert AWS IoT FreeRTOS Qualification (FRQ) 1.0 keine signierten Qualifikationsberichte. AWS IoT Device Tester Sie können neue AWS IoT FreeRTOS-Geräte nicht für die Aufnahme in den [AWS Partnergerätekatalog über das AWS Gerätequalifizierungsprogramm](https://partners.amazonaws.com/qualified-devices) [qualifizieren](https://aws.amazon.com/partners/programs/dqp/), wenn Sie IDT FRQ 1.0-Versionen verwenden. Sie können FreeRTOS-Geräte zwar nicht mit IDT FRQ 1.0 qualifizieren, aber Sie können Ihre FreeRTOS-Geräte weiterhin mit FRQ 1.0 testen. [Wir empfehlen Ihnen, [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) zu verwenden, um FreeRTOS-Geräte zu qualifizieren und im Partnergerätekatalog aufzulisten.AWS](https://partners.amazonaws.com/qualified-devices)
Sie können IDT für die FreeRTOS-Qualifizierung verwenden, um zu überprüfen, ob das FreeRTOS-Betriebssystem lokal auf Ihrem Gerät funktioniert und mit diesem kommunizieren kann. AWS IoT Insbesondere wird überprüft, ob die Schnittstellen der Portierungsschicht für die FreeRTOS-Bibliotheken korrekt implementiert sind. Es führt end-to-end auch Tests mit durch. AWS IoT Core So wird beispielsweise überprüft, ob Ihr Board MQTT-Nachrichten senden und empfangen und korrekt verarbeiten kann. [Die von IDT für FreeRTOS ausgeführten Tests sind im FreeRTOS-Repository definiert. GitHub ](https://github.com/aws/amazon-freertos)
Die Tests laufen als Embedded-Anwendungen, die auf Ihr Board geflasht werden. Die Binär-Images der Anwendung enthalten FreeRTOS, die portierten FreeRTOS-Schnittstellen des Halbleiterherstellers, und Platinengerätetreiber. Der Zweck der Tests besteht darin, zu überprüfen, ob die portierten FreeRTOS-Schnittstellen neben den Gerätetreibern korrekt funktionieren.
IDT for FreeRTOS generiert Testberichte, die Sie einreichen können, AWS IoT um Ihre Hardware zum AWS Partnergerätekatalog hinzuzufügen. Weitere Informationen finden Sie unter [AWS Device Qualification Program](https://aws.amazon.com/partners/dqp/).
IDT for FreeRTOS läuft auf einem Host-Computer (Windows, macOS oder Linux), der an das zu testende Board angeschlossen ist. IDT führt Testfälle aus und fasst Ergebnisse zusammen. Er stellt ebenfalls eine Befehlszeilenschnittstelle zur Verwaltung der Testausführung bereit.
IDT for FreeRTOS testet nicht nur Geräte, sondern erstellt auch Ressourcen (z. B. AWS IoT Dinge, FreeRTOS-Gruppen, Lambda-Funktionen usw.), um den Qualifizierungsprozess zu erleichtern. Um diese Ressourcen zu erstellen, verwendet IDT for FreeRTOS die in der konfigurierten AWS Anmeldeinformationen, `config.json` um API-Aufrufe in Ihrem Namen durchzuführen. Diese Ressourcen werden zu verschiedenen Zeiten während eines Tests bereitgestellt.
Wenn Sie IDT for FreeRTOS auf Ihrem Host-Computer ausführen, werden die folgenden Schritte ausgeführt:
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.
**Topics**
+ [Richten Sie die 1.0-Qualifikationsvoraussetzungen ein](dev-tester-prereqs.md)
+ [Erster Test Ihres Mikrocontroller-Boards](qual-steps.md)
+ [Verwenden Sie die IDT-Benutzeroberfläche, um die FreeRTOS Qualification Suite auszuführen](device-tester-ui.md)
+ [Führen Sie Bluetooth Low Energy-Tests durch](afr-bridgekeeper-dt-bt.md)
+ [Führen Sie die FreeRTOS Qualification Suite aus](run-tests.md)
+ [Sehen Sie sich die Ergebnisse von IDT for FreeRTOS an](view-results-frq.md)
+ [Interpretieren Sie die IDT for FreeRTOS-Ergebnisse](interpreting-results-frq.md)
+ [Die IDT for FreeRTOS-Protokolle anzeigen](view-logs-frq.md)
# Richten Sie die 1.0-Qualifikationsvoraussetzungen ein
In diesem Abschnitt werden die Voraussetzungen für das Testen von Mikrocontrollern mit AWS IoT Device Tester beschrieben.
## FreeRTOS herunterladen
Sie können eine Version von FreeRTOS [GitHub](https://github.com/aws/amazon-freertos)mit dem folgenden Befehl herunterladen:
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
wo ist eine Version von FreeRTOS (zum Beispiel 202007.00), die einer IDT-Version entspricht, die unter aufgeführt ist. [Unterstützte Versionen von AWS IoT Device Tester](dev-test-versions-afr.md) Dadurch wird sichergestellt, dass Sie über den vollständigen Quellcode einschließlich der Submodule verfügen und die richtige Version von IDT für Ihre Version von FreeRTOS verwenden und umgekehrt.
Windows hat eine Pfadlängenbegrenzung von 260 Zeichen. Die Pfadstruktur von FreeRTOS ist vielschichtig. Wenn Sie also Windows verwenden, sollten Sie Ihre Dateipfade unter dem Limit von 260 Zeichen halten. Klonen Sie FreeRTOS beispielsweise auf `C:\FreeRTOS` statt. `C:\Users\username\programs\projects\myproj\FreeRTOS\`
### FreeRTOS-Qualifikation mit LTS-Bibliotheken
+ Damit Ihr Mikrocontroller im AWS Partner Device Catalog als auf Long-Term Support (LTS) basierende Versionen von FreeRTOS unterstützt werden kann, müssen Sie eine Manifestdatei bereitstellen. Weitere Informationen finden Sie in der [FreeRTOS Qualification Checklist](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html) im *FreeRTOS* Qualification Guide.
+ Um zu überprüfen, ob Ihr Mikrocontroller LTS-basierte Versionen von FreeRTOS unterstützt, und um ihn für die Einreichung im AWS Partner Device Catalog zu qualifizieren, müssen Sie AWS IoT Device Tester (IDT) mit der FreeRTOS Qualification (FRQ) Test Suite Version v1.4.x verwenden.
+ Die Support für LTS-basierte Versionen von FreeRTOS ist auf die Version 202012.xx von FreeRTOS beschränkt.
## Laden Sie IDT für FreeRTOS herunter
Jede Version von FreeRTOS hat eine entsprechende Version von IDT für FreeRTOS zur Durchführung von Qualifizierungstests. Laden Sie die entsprechende Version von IDT für FreeRTOS von herunter. [Unterstützte Versionen von AWS IoT Device Tester](dev-test-versions-afr.md)
Extrahieren Sie IDT for FreeRTOS an einen Speicherort im Dateisystem, für den Sie Lese- und Schreibberechtigungen haben. Da Microsoft Windows eine Zeichenbeschränkung für die Pfadlänge hat, extrahieren Sie IDT für FreeRTOS in ein Stammverzeichnis wie oder. `C:\` `D:\`
**Anmerkung**
Es wird nicht empfohlen, dass mehrere Benutzer IDT aus einem freigegebenen Speicherort ausführen, z. B. einem NFS-Verzeichnis oder einem freigegebenen Windows-Netzwerkordner. Dies kann zu Abstürzen oder Datenbeschädigung führen. Es wird empfohlen, das IDT-Paket in einem lokalen Laufwerk zu extrahieren.
## Erstellen und konfigurieren Sie ein Konto AWS
### Melden Sie sich an für eine AWS-Konto
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).
AWS sendet Ihnen nach Abschluss des Anmeldevorgangs eine Bestätigungs-E-Mail. Sie können Ihre aktuellen Kontoaktivitäten jederzeit einsehen und Ihr Konto verwalten, indem Sie zu [https://aws.amazon.com/](https://aws.amazon.com/)gehen und **Mein Konto** auswählen.
### Erstellen eines Benutzers mit Administratorzugriff
Nachdem Sie sich für einen angemeldet haben AWS-Konto, sichern Sie Ihren Root-Benutzer des AWS-Kontos AWS IAM Identity Center, aktivieren und erstellen Sie einen Administratorbenutzer, sodass Sie den Root-Benutzer nicht für alltägliche Aufgaben verwenden.
**Sichern Sie Ihre Root-Benutzer des AWS-Kontos**
1. Melden Sie sich [AWS-Managementkonsole](https://console.aws.amazon.com/)als Kontoinhaber an, indem Sie **Root-Benutzer** auswählen und Ihre AWS-Konto E-Mail-Adresse eingeben. Geben Sie auf der nächsten Seite Ihr Passwort ein.
Hilfe bei der Anmeldung mit dem Root-Benutzer finden Sie unter [Anmelden als Root-Benutzer](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) im *AWS-Anmeldung -Benutzerhandbuch* zu.
1. Aktivieren Sie die Multi-Faktor-Authentifizierung (MFA) für den Root-Benutzer.
Anweisungen finden Sie unter [Aktivieren eines virtuellen MFA-Geräts für Ihren AWS-Konto Root-Benutzer (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) im *IAM-Benutzerhandbuch*.
**Erstellen eines Benutzers mit Administratorzugriff**
1. Aktivieren Sie das IAM Identity Center.
Anweisungen finden Sie unter [Aktivieren AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
1. Gewähren Sie einem Administratorbenutzer im IAM Identity Center Benutzerzugriff.
*Ein Tutorial zur Verwendung von IAM-Identity-Center-Verzeichnis als Identitätsquelle finden Sie IAM-Identity-Center-Verzeichnis im Benutzerhandbuch unter [Benutzerzugriff mit der Standardeinstellung konfigurieren](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html).AWS IAM Identity Center *
**Anmelden als Administratorbenutzer**
+ Um sich mit Ihrem IAM-Identity-Center-Benutzer anzumelden, verwenden Sie die Anmelde-URL, die an Ihre E-Mail-Adresse gesendet wurde, als Sie den IAM-Identity-Center-Benutzer erstellt haben.
Hilfe bei der Anmeldung mit einem IAM Identity Center-Benutzer finden Sie [im *AWS-Anmeldung Benutzerhandbuch* unter Anmeldung beim AWS Access-Portal](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html).
**Weiteren Benutzern Zugriff zuweisen**
1. Erstellen Sie im IAM-Identity-Center einen Berechtigungssatz, der den bewährten Vorgehensweisen für die Anwendung von geringsten Berechtigungen folgt.
Anweisungen hierzu finden Sie unter [ Berechtigungssatz erstellen](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
1. Weisen Sie Benutzer einer Gruppe zu und weisen Sie der Gruppe dann Single Sign-On-Zugriff zu.
Eine genaue Anleitung finden Sie unter [ Gruppen hinzufügen](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
## AWS IoT Device Tester verwaltete Richtlinie
Die `AWSIoTDeviceTesterForFreeRTOSFullAccess` verwaltete Richtlinie enthält die folgenden AWS IoT Device Tester Berechtigungen für die Versionsprüfung, auto Aktualisierungsfunktionen und die Erfassung von Metriken.
+ `iot-device-tester:SupportedVersion`
Erteilt die AWS IoT Device Tester Berechtigung zum Abrufen der Liste der unterstützten Produkte, Testsuiten und IDT-Versionen.
+ `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 Testsuite-Updates.
+ `iot-device-tester:SendMetrics`
AWS Erteilt die Erlaubnis, Metriken zur AWS IoT Device Tester internen Nutzung zu sammeln.
## (Optional) Installieren Sie AWS Command Line Interface
Möglicherweise ziehen Sie es vor, den zu verwenden AWS CLI , um einige Operationen auszuführen. Wenn Sie das nicht AWS CLI installiert haben, folgen Sie den Anweisungen unter [Installieren](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) von AWS CLI.
Konfigurieren Sie das AWS CLI für die AWS Region, die Sie verwenden möchten, indem Sie es **aws configure** von einer Befehlszeile aus ausführen. Informationen zu den AWS Regionen, die IDT für FreeRTOS unterstützen, finden Sie unter [AWS Regionen](https://docs.aws.amazon.com/general/latest/gr/rande.html#amazon-freertos-ota-control) und Endpunkte. [Weitere Informationen finden Sie unter Schnellkonfiguration mit**aws configure**. **aws configure**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)
# Erster Test Ihres Mikrocontroller-Boards
Sie können IDT for FreeRTOS zum Testen verwenden, während Sie die FreeRTOS-Schnittstellen portieren. Nachdem Sie die FreeRTOS-Schnittstellen für die Gerätetreiber Ihres Boards portiert haben, führen Sie AWS IoT Device Tester damit die Qualifizierungstests auf Ihrem Mikrocontroller-Board durch.
## Hinzufügen von Portierungsebenen für Bibliotheken
Um FreeRTOS für Ihr Gerät zu portieren, folgen Sie den Anweisungen im [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/) Porting Guide.
## AWS Konfigurieren Sie Ihre Zugangsdaten
Sie müssen Ihre AWS Anmeldeinformationen für AWS IoT Device Tester die Kommunikation mit der AWS Cloud konfigurieren. Weitere Informationen finden Sie unter [AWS Zugangsdaten und Region für die Entwicklung einrichten](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html). In der `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/config.json` Konfigurationsdatei müssen gültige AWS Anmeldeinformationen angegeben werden.
**Topics**
+ [Hinzufügen von Portierungsebenen für Bibliotheken](#add-port-layer)
+ [AWS Konfigurieren Sie Ihre Zugangsdaten](#cfg-aws-afr)
+ [Erstellen Sie einen Gerätepool in IDT für FreeRTOS](cfg-dt-dp.md)
+ [Konfiguration von Build-, Flash- und Testeinstellungen](cfg-dt-ud.md)
# Erstellen Sie einen Gerätepool in IDT für FreeRTOS
Zu testende Geräte werden in Gerätepools organisiert. Jeder Gerätepool besteht aus einem oder mehreren identischen Geräten. Sie können IDT for FreeRTOS so konfigurieren, dass ein einzelnes Gerät in einem Pool oder mehrere Geräte in einem Pool getestet werden. Um den Qualifizierungsprozess zu beschleunigen, kann IDT for FreeRTOS Geräte mit denselben Spezifikationen parallel testen. Er verwendet eine Round Robin-Methode, um auf jedem Gerät in einem Gerätepool eine andere Testgruppe auszuführen.
Sie können ein oder mehrere Geräte zu einem Gerätepool hinzufügen, indem Sie den Abschnitt `devices` der Vorlage `device.json` im Ordner `configs` bearbeiten.
**Anmerkung**
Alle Geräte im selben Pool müssen dieselbe technische Spezifikation und SKU aufweisen.
Um parallel Builds des Quellcodes für verschiedene Testgruppen zu ermöglichen, kopiert IDT for FreeRTOS den Quellcode in einen Ergebnisordner innerhalb des extrahierten IDT for FreeRTOS-Ordners. Der Quellcodepfad in Ihrem Build- oder Flash-Befehl muss entweder mit der Variablen oder referenziert werden. `testdata.sourcePath` `sdkPath` IDT for FreeRTOS ersetzt diese Variable durch einen temporären Pfad des kopierten Quellcodes. Weitere Informationen finden Sie unter [IDT für FreeRTOS-Variablen](dt-vars.md).
Im Folgenden sehen Sie, wie eine `device.json`-Datei zur Erstellung eines Gerätepools mit mehreren Geräten verwendet wird:
```
[
{
"id": "pool-id",
"sku": "sku",
"features": [
{
"name": "WIFI",
"value": "Yes | No"
},
{
"name": "Cellular",
"value": "Yes | No"
},
{
"name": "OTA",
"value": "Yes | No",
"configs": [
{
"name": "OTADataPlaneProtocol",
"value": "HTTP | MQTT"
}
]
},
{
"name": "BLE",
"value": "Yes | No"
},
{
"name": "TCP/IP",
"value": "On-chip | Offloaded | No"
},
{
"name": "TLS",
"value": "Yes | No"
},
{
"name": "PKCS11",
"value": "RSA | ECC | Both | No"
},
{
"name": "KeyProvisioning",
"value": "Import | Onboard | No"
}
],
"devices": [
{
"id": "device-id",
"connectivity": {
"protocol": "uart",
"serialPort": "/dev/tty*"
},
***********Remove the section below if the device does not support onboard key generation***************
"secureElementConfig" : {
"publicKeyAsciiHexFilePath": "absolute-path-to/public-key-txt-file: contains-the-hex-bytes-public-key-extracted-from-onboard-private-key",
"secureElementSerialNumber": "secure-element-serialNo-value",
"preProvisioned" : "Yes | No"
},
**********************************************************************************************************
"identifiers": [
{
"name": "serialNo",
"value": "serialNo-value"
}
]
}
]
}
]
```
Die folgenden Attribute werden in der Datei `device.json` verwendet:
**`id`**
Eine benutzerdefinierte alphanumerische ID, die einen Gerätepool eindeutig identifiziert. Geräte, die zu einem Pool gehören, müssen vom gleichen Typ sein. Bei der Ausführung einer Reihe von Tests werden Geräte im Pool verwendet, um den Workload zu parallelisieren.
**`sku`**
Ein alphanumerischer Wert, mit dem das getestete Board eindeutig identifiziert wird. Die SKU wird verwendet, um qualifizierte Boards nachzuverfolgen.
Wenn Sie Ihr Motherboard im Gerätekatalog für AWS Partner anbieten möchten, muss die hier angegebene SKU mit der SKU übereinstimmen, die Sie bei der Angebotserstellung verwenden.
**`features`**
Ein Array, das die vom Gerät unterstützten Funktionen enthält. AWS IoT Device Tester verwendet diese Informationen, um die durchzuführenden Qualifikationstests auszuwählen.
Unterstützte Werte sind:
**`TCP/IP`**
Zeigt an, ob Ihre Platine einen TCP/IP Stack unterstützt und ob dieser On-Chip (MCU) unterstützt oder auf ein anderes Modul ausgelagert wird. TCP/IP ist für die Qualifikation erforderlich.
**`WIFI`**
Gibt an, ob Ihr Board über WiFi-Funktionen verfügt. Muss auf gesetzt werden, `No` wenn auf gesetzt `Cellular` ist`Yes`.
**`Cellular`**
Zeigt an, ob Ihr Board über Mobilfunkfunktionen verfügt. Muss auf eingestellt sein, `No` wenn auf eingestellt `WIFI` ist`Yes`. Wenn diese Funktion auf eingestellt ist`Yes`, wird der FullSecureSockets Test mithilfe von AWS t2.micro EC2-Instances ausgeführt, was zu zusätzlichen Kosten für Ihr Konto führen kann. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/).
**`TLS`**
Gibt an, ob Ihr Board TLS unterstützt. TLS ist für die Qualifizierung erforderlich.
**`PKCS11`**
Gibt den Kryptografiealgorithmus mit öffentlichen Schlüsseln an, den das Board unterstützt. PKCS11 ist für die Qualifikation erforderlich. Unterstützte Werte sind `ECC`, `RSA`, `Both` und `No`. `Both` zeigt an, dass das Board sowohl den `ECC`- als auch den `RSA`-Algorithmus unterstützt.
**`KeyProvisioning`**
Gibt an, wie ein vertrauenswürdiges X.509-Clientzertifikat auf das Board geschrieben werden kann. Gültige Werte sind `Import`, `Onboard` und `No`. Schlüsselbereitstellung ist für die Qualifizierung erforderlich.
+ Verwenden Sie `Import`, wenn Ihr Board den Import von privaten Schlüsseln erlaubt. IDT erstellt einen privaten Schlüssel und baut diesen in den FreeRTOS-Quellcode ein.
+ Verwenden Sie `Onboard`, wenn Ihr Board die interne Erstellung von privaten Schlüsseln unterstützt (z. B. wenn Ihr Gerät über ein sicheres Element verfügt oder wenn Sie es vorziehen, ein eigenes Geräte-Schlüsselpaar und ein eigenes Zertifikat zu generieren). Stellen Sie sicher, dass Sie in jedem der Geräteabschnitte ein `secureElementConfig`-Element hinzufügen und fügen Sie den absoluten Pfad zur Datei des öffentlichen Schlüssels in das Feld `publicKeyAsciiHexFilePath` ein.
+ Wenn Ihr Board die Schlüsselbereitstellung nicht unterstützt, verwenden Sie die Option `No`.
**`OTA`**
Zeigt an, ob Ihr Board die Aktualisierungsfunktion over-the-air (OTA) unterstützt. Das Attribut `OtaDataPlaneProtocol` gibt an, welches OTA-Protokoll auf Datenebene das Gerät unterstützt. Das Attribut wird ignoriert, wenn die OTA-Funktion vom Gerät nicht unterstützt wird. Wenn ausgewählt `"Both"` ist, wird die Ausführungszeit des OTA-Tests verlängert, da sowohl MQTT-, HTTP- als auch gemischte Tests ausgeführt werden.
Beginnend mit IDT v4.1.0 werden nur `HTTP` und `MQTT` als unterstützte Werte `OtaDataPlaneProtocol` akzeptiert.
**`BLE`**
Gibt an, ob Ihr Board Bluetooth Low Energy (BLE) unterstützt.
**`devices.id`**
Eine benutzerdefinierte eindeutige Kennung für das zu testende Gerät.
**`devices.connectivity.protocol`**
Das Kommunikationsprotokoll, das für die Kommunikation mit diesem Gerät verwendet wird. Unterstützter Wert: `uart`.
**`devices.connectivity.serialPort`**
Der serielle Port des Host-Computers, der zur Herstellung einer Verbindung mit den getesteten Geräten verwendet wird.
**`devices.secureElementConfig.PublicKeyAsciiHexFilePath`**
Der absolute Pfad zu der Datei, die den öffentlichen Hex-Byte-Schlüssel enthält, der aus dem integrierten privaten Schlüssel extrahiert wurde.
Beispielformat:
```
3059 3013 0607 2a86 48ce 3d02 0106 082a
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c
```
Wenn Ihr öffentlicher Schlüssel im.der-Format vorliegt, können Sie den öffentlichen Schlüssel direkt hexcodieren, um die Hex-Datei zu generieren.
Beispielbefehl für den öffentlichen Schlüssel .der zur Generierung einer Hex-Datei:
```
xxd -p pubkey.der > outFile
```
Wenn Ihr öffentlicher Schlüssel im.pem-Format vorliegt, können Sie den Base64-kodierten Teil extrahieren, ihn in das Binärformat dekodieren und ihn dann hexadezimalkodieren, um die Hex-Datei zu generieren.
Verwenden Sie beispielsweise diese Befehle, um eine Hex-Datei für einen öffentlichen PEM-Schlüssel zu generieren:
1. Nehmen Sie den Base64-kodierten Teil des Schlüssels heraus (entfernen Sie die Kopf- und Fußzeile) und speichern Sie ihn in einer Datei. Geben Sie ihm beispielsweise einen Namen und führen Sie diesen Befehl aus`base64key`, um ihn in das Format.der zu konvertieren:
```
base64 —decode base64key > pubkey.der
```
1. Führen Sie den `xxd` Befehl aus, um ihn in das Hex-Format zu konvertieren.
```
xxd -p pubkey.der > outFile
```
**`devices.secureElementConfig.SecureElementSerialNumber`**
(Optional) Die Seriennummer des sicheren Elements. Geben Sie dieses Feld an, wenn die Seriennummer zusammen mit dem öffentlichen Schlüssel des Geräts ausgedruckt wird, wenn Sie das demo/test FreeRTOS-Projekt ausführen.
**`devices.secureElementConfig.preProvisioned`**
(Optional) Wählen Sie „Ja“, wenn das Gerät über ein vorab bereitgestelltes sicheres Element mit gesperrten Anmeldeinformationen verfügt, das keine Objekte importieren, erstellen oder zerstören kann. Diese Konfiguration wird nur wirksam, wenn sie `features` zusammen mit „ECC“ auf „Onboard“ `PKCS11` gesetzt ist. `KeyProvisioning`
**`identifiers`**
(Optional) Ein Array beliebiger Namen-Wert-Paare. Sie können diese Werte in den im nächsten Abschnitt beschriebenen Build- und Flash-Befehlen verwenden.
# Konfiguration von Build-, Flash- und Testeinstellungen
Damit IDT for FreeRTOS automatisch Tests auf Ihrem Board erstellen und flashen kann, müssen Sie IDT so konfigurieren, dass die Build- und Flash-Befehle für Ihre Hardware ausgeführt werden. Die Einstellungen für den Build- und den Flash-Befehl werden in der `userdata.json`-Vorlagendatei im Ordner `config` konfiguriert.
# Konfigurieren von Einstellungen für das Testen von Geräten
Build-, Flash- und Testeinstellungen werden in der `configs/userdata.json`-Datei vorgenommen. Wir unterstützen die Echo Server-Konfiguration, indem wir sowohl die Client- als auch die Serverzertifikate und Schlüssel in den laden`customPath`. Weitere Informationen finden Sie unter [Einen Echo-Server einrichten](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html) im *FreeRTOS Porting Guide*. Das folgende JSON-Beispiel zeigt, wie Sie IDT für FreeRTOS konfigurieren können, um mehrere Geräte zu testen:
```
{
"sourcePath": "/absolute-path-to/freertos",
"vendorPath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name",
// ***********The sdkConfiguration block below is needed if you are not using the default, unmodified FreeRTOS repo.
// In other words, if you are using the default, unmodified FreeRTOS repo then remove this block***************
"sdkConfiguration": {
"name": "sdk-name",
"version": "sdk-version",
"path": "/absolute-path-to/sdk"
},
"buildTool": {
"name": "your-build-tool-name",
"version": "your-build-tool-version",
"command": [
"{{config.idtRootPath}}/relative-path-to/build-parallel.sh {{testData.sourcePath}} {{enableTests}}"
]
},
"flashTool": {
"name": "your-flash-tool-name",
"version": "your-flash-tool-version",
"command": [
"/{{config.idtRootPath}}/relative-path-to/flash-parallel.sh {{testData.sourcePath}} {{device.connectivity.serialPort}} {{buildImageName}}"
],
"buildImageInfo" : {
"testsImageName": "tests-image-name",
"demosImageName": "demos-image-name"
}
},
"testStartDelayms": 0,
"clientWifiConfig": {
"wifiSSID": "ssid",
"wifiPassword": "password",
"wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
},
"testWifiConfig": {
"wifiSSID": "ssid",
"wifiPassword": "password",
"wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
},
//**********
//This section is used to start echo server based on server certificate generation method,
//When certificateGenerationMethod is set as Automatic specify the eccCurveFormat to generate certifcate and key based on curve format,
//When certificateGenerationMethod is set as Custom specify the certificatePath and PrivateKeyPath to be used to start echo server
//**********
"echoServerCertificateConfiguration": {
"certificateGenerationMethod": "Automatic | Custom",
"customPath": {
"clientCertificatePath":"/path/to/clientCertificate",
"clientPrivateKeyPath": "/path/to/clientPrivateKey",
"serverCertificatePath":"/path/to/serverCertificate",
"serverPrivateKeyPath": "/path/to/serverPrivateKey"
},
"eccCurveFormat": "P224 | P256 | P384 | P521"
},
"echoServerConfiguration": {
"securePortForSecureSocket": 33333, // Secure tcp port used by SecureSocket test. Default value is 33333. Ensure that the port configured isn't blocked by the firewall or your corporate network
"insecurePortForSecureSocket": 33334, // Insecure tcp port used by SecureSocket test. Default value is 33334. Ensure that the port configured isn't blocked by the firewall or your corporate network
"insecurePortForWiFi": 33335 // Insecure tcp port used by Wi-Fi test. Default value is 33335. Ensure that the port configured isn't blocked by the firewall or your corporate network
},
"otaConfiguration": {
"otaFirmwareFilePath": "{{testData.sourcePath}}/relative-path-to/ota-image-generated-in-build-process",
"deviceFirmwareFileName": "ota-image-name-on-device",
"otaDemoConfigFilePath": "{{testData.sourcePath}}/relative-path-to/ota-demo-config-header-file",
"codeSigningConfiguration": {
"signingMethod": "AWS | Custom",
"signerHashingAlgorithm": "SHA1 | SHA256",
"signerSigningAlgorithm": "RSA | ECDSA",
"signerCertificate": "arn:partition:service:region:account-id:resource:qualifier | /absolute-path-to/signer-certificate-file",
"signerCertificateFileName": "signerCertificate-file-name",
"compileSignerCertificate": boolean,
// ***********Use signerPlatform if you choose aws for signingMethod***************
"signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF",
"untrustedSignerCertificate": "arn:partition:service:region:account-id:resourcetype:resource:qualifier",
// ***********Use signCommand if you choose custom for signingMethod***************
"signCommand": [
"/absolute-path-to/sign.sh {{inputImageFilePath}} {{outputSignatureFilePath}}"
]
}
},
// ***********Remove the section below if you're not configuring CMake***************
"cmakeConfiguration": {
"boardName": "board-name",
"vendorName": "vendor-name",
"compilerName": "compiler-name",
"frToolchainPath": "/path/to/freertos/toolchain",
"cmakeToolchainPath": "/path/to/cmake/toolchain"
},
"freertosFileConfiguration": {
"required": [
{
"configName": "pkcs11Config",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/core_pkcs11_config.h"
},
{
"configName": "pkcs11TestConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/iot_test_pkcs11_config.h"
}
],
"optional": [
{
"configName": "otaAgentTestsConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_tests/config_files/ota_config.h"
},
{
"configName": "otaAgentDemosConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_config.h"
},
{
"configName": "otaDemosConfig",
"filePath": "{{testData.sourcePath}}/vendors/vendor-name/boards/board-name/aws_demos/config_files/ota_demo_config.h"
}
]
}
}
```
Im Folgenden werden die in der `userdata.json`-Datei verwendeten Attribute aufgelistet:
**`sourcePath`**
Der Pfad zum Stammverzeichnis des portierten FreeRTOS-Quellcodes. Für parallel Tests mit einem SDK `sourcePath` kann das über den `{{userData.sdkConfiguration.path}}` Platzhalter eingestellt werden. Beispiel:
```
{ "sourcePath":"{{userData.sdkConfiguration.path}}/freertos" }
```
**`vendorPath`**
Der Pfad zum herstellerspezifischen FreeRTOS-Code. Für serielle Tests kann der `vendorPath` als absoluter Pfad festgelegt werden. Beispiel:
```
{ "vendorPath":"C:/path-to-freertos/vendors/espressif/boards/esp32" }
```
Für parallele Tests kann der `vendorPath` mit dem Platzhalter `{{testData.sourcePath}}` eingestellt werden. Beispiel:
```
{ "vendorPath":"{{testData.sourcePath}}/vendors/espressif/boards/esp32" }
```
Die `vendorPath` Variable ist nur notwendig, wenn sie ohne SDK läuft, andernfalls kann sie entfernt werden.
Wenn Tests ohne SDK parallel ausgeführt werden, muss der `{{testData.sourcePath}}` Platzhalter in den `flashTool` Feldern`vendorPath`,`buildTool`, verwendet werden. Wenn der Test mit einem einzigen Gerät ausgeführt wird, müssen absolute Pfade in den Feldern `vendorPath`, `buildTool`, `flashTool` verwendet werden. Bei der Ausführung mit einem SDK muss der `{{sdkPath}}` Platzhalter in den Befehlen `sourcePath``buildTool`, und `flashTool` verwendet werden.
**`sdkConfiguration`**
Wenn Sie FreeRTOS mit Änderungen an der Datei- und Ordnerstruktur qualifizieren, die über das für die Portierung erforderliche Maß hinausgehen, müssen Sie Ihre SDK-Informationen in diesem Block konfigurieren. Wenn Sie sich nicht mit einem portierten FreeRTOS innerhalb eines SDK qualifizieren, sollten Sie diesen Block komplett weglassen.
**`sdkConfiguration.name`**
Der Name des SDK, das Sie mit FreeRTOS verwenden. Wenn Sie kein SDK verwenden, sollte der gesamte `sdkConfiguration` Block weggelassen werden.
**`sdkConfiguration.version`**
Die Version des SDK, das Sie mit FreeRTOS verwenden. Wenn Sie kein SDK verwenden, sollte der gesamte `sdkConfiguration` Block weggelassen werden.
**`sdkConfiguration.path`**
Der absolute Pfad zu Ihrem SDK-Verzeichnis, das Ihren FreeRTOS-Code enthält. Wenn Sie kein SDK verwenden, sollte der gesamte `sdkConfiguration` Block weggelassen werden.
**`buildTool`**
Der vollständige Pfad zu Ihrem Build-Skript (.bat oder .sh), das die Befehle zur Erstellung Ihres Quellcodes enthält. Alle Verweise auf den Quellcodepfad im Build-Befehl müssen durch die AWS IoT Device Tester Variable ersetzt werden `{{testdata.sourcePath}}` und Verweise auf den SDK-Pfad sollten durch ersetzt werden`{{sdkPath}}`. Verwenden Sie den `{{config.idtRootPath}}` Platzhalter, um auf den absoluten oder relativen IDT-Pfad zu verweisen.
**`testStartDelayms`**
Gibt an, wie viele Millisekunden der FreeRTOS-Testläufer wartet, bevor er mit der Ausführung von Tests beginnt. Dies kann nützlich sein, wenn das zu testende Gerät aufgrund von Netzwerk- oder anderen Latenzen mit der Ausgabe wichtiger Testinformationen beginnt, bevor IDT die Möglichkeit hat, eine Verbindung herzustellen und mit der Protokollierung zu beginnen. Der zulässige Höchstwert ist 30000 ms (30 Sekunden). Dieser Wert gilt nur für FreeRTOS-Testgruppen und nicht für andere Testgruppen, die den FreeRTOS-Testrunner nicht verwenden, wie z. B. die OTA-Tests.
**`flashTool`**
Vollständiger Pfad zu Ihrem Flash-Skript (.sh oder.bat), der die Flash-Befehle für Ihr Gerät enthält. Alle Verweise auf den Quellcodepfad im Befehl flash müssen durch die Variable IDT for FreeRTOS ersetzt werden `{{testdata.sourcePath}}` und alle Verweise auf Ihren SDK-Pfad müssen durch die Variable IDT for FreeRTOS ersetzt werden. `{{sdkPath}}` Verwenden Sie den `{{config.idtRootPath}}` Platzhalter, um auf den absoluten oder relativen IDT-Pfad zu verweisen.
**`buildImageInfo`**
**`testsImageName`**
Der Name der Datei, die vom Build-Befehl beim Erstellen von Tests aus dem Ordner erzeugt wurde. `freertos-source/tests`
**`demosImageName`**
Der Name der Datei, die vom Build-Befehl beim Erstellen von Tests aus dem `freertos-source/demos` Ordner erzeugt wurde.
**`clientWifiConfig`**
Die Client-WLAN-Konfiguration. Die Tests für die WLAN-Bibliothek erfordern ein MCU-Board, um eine Verbindung mit zwei Zugriffspunkten herzustellen. (Die beiden Zugangspunkte können identisch sein.) Dieses Attribut konfiguriert die WLAN-Einstellungen für den ersten Zugriffspunkt. In einigen WLAN-Testfällen wird erwartet, dass der Zugriffspunkt über ein gewisses Maß an Sicherheit verfügt und nicht offen ist. Bitte stellen Sie sicher, dass sich beide Access Points im selben Subnetz befinden wie der Host-Computer, auf dem IDT ausgeführt wird.
**`wifi_ssid`**
Die WLAN-SSID.
**`wifi_password`**
Das WLAN-Passwort.
**`wifiSecurityType`**
Die Art der verwendeten WLAN-Sicherheit. Einer der Werte:
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Wenn Ihr Board kein WLAN unterstützt, müssen Sie Ihrer `device.json`-Datei dennoch den Abschnitt `clientWifiConfig` hinzufügen. Werte für diese Attribute können Sie jedoch weglassen.
**`testWifiConfig`**
Die WLAN-Testkonfiguration. Die Tests für die WLAN-Bibliothek erfordern ein MCU-Board, um eine Verbindung mit zwei Zugriffspunkten herzustellen. (Die beiden Zugangspunkte können identisch sein.) Dieses Attribut konfiguriert die WLAN-Einstellungen für den zweiten Zugriffspunkt. In einigen WLAN-Testfällen wird erwartet, dass der Zugriffspunkt über ein gewisses Maß an Sicherheit verfügt und nicht offen ist. Bitte stellen Sie sicher, dass sich beide Access Points im selben Subnetz befinden wie der Host-Computer, auf dem IDT ausgeführt wird.
**`wifiSSID`**
Die WLAN-SSID.
**`wifiPassword`**
Das WLAN-Passwort.
**`wifiSecurityType`**
Die Art der verwendeten WLAN-Sicherheit. Einer der Werte:
+ `eWiFiSecurityOpen`
+ `eWiFiSecurityWEP`
+ `eWiFiSecurityWPA`
+ `eWiFiSecurityWPA2`
+ `eWiFiSecurityWPA3`
Wenn Ihr Board kein WLAN unterstützt, müssen Sie Ihrer `device.json`-Datei dennoch den Abschnitt `testWifiConfig` hinzufügen. Werte für diese Attribute können Sie jedoch weglassen.
**`echoServerCertificateConfiguration`**
Der konfigurierbare Platzhalter für die Generierung von Echo-Serverzertifikaten für Secure-Socket-Tests. Dies ist ein Pflichtfeld.
**`certificateGenerationMethod`**
Gibt an, ob das Serverzertifikat automatisch generiert oder manuell bereitgestellt wird.
**`customPath`**
Es `certificateGenerationMethod` ist „Benutzerdefiniert“ `certificatePath` und `privateKeyPath` sie sind erforderlich.
**`certificatePath`**
Gibt den Dateipfad für das Serverzertifikat an.
**`privateKeyPath`**
Gibt den Dateipfad für den privaten Schlüssel an.
**`eccCurveFormat`**
Gibt das von der Karte unterstützte Kurvenformat an. `PKCS11`Erforderlich, wenn in `device.json` auf „ecc“ gesetzt ist. Gültige Werte sind „P224", „P256", „P384" oder „P521".
**`echoServerConfiguration`**
Die konfigurierbaren Echo-Server-Ports für und sichere Socket-Tests. WiFi Dies ist ein optionales Feld.
**`securePortForSecureSocket`**
Der Port, der zum Einrichten eines Echo-Servers mit TLS für den Secure Sockets-Test verwendet wird. Der Standardwert ist 33333. Stellen Sie sicher, dass der konfigurierte Port nicht von einer Firewall oder Ihrem Unternehmensnetzwerk blockiert wird.
**`insecurePortForSecureSocket`**
Der Port, der zum Einrichten eines Echo-Servers ohne TLS für den Secure Sockets-Test verwendet wird. Der Standardwert für den Test ist 33334. Stellen Sie sicher, dass der konfigurierte Port nicht von einer Firewall oder Ihrem Unternehmensnetzwerk blockiert wird.
**`insecurePortForWiFi`**
Der Port, der verwendet wird, um den Echo-Server ohne TLS für WiFi Tests einzurichten. Der Standardwert für den Test ist 33335. Stellen Sie sicher, dass der konfigurierte Port nicht von einer Firewall oder Ihrem Unternehmensnetzwerk blockiert wird.
**`otaConfiguration`**
Die OTA-Konfiguration. [Optional]
**`otaFirmwareFilePath`**
Der vollständige Pfad zum OTA-Image, das nach dem Build erstellt wird. Beispiel, `{{testData.sourcePath}}/relative-path/to/ota/image/from/source/root`.
**`deviceFirmwareFileName`**
Der vollständige Dateipfad auf dem MCU-Gerät, auf dem sich die OTA-Firmware befindet. Einige Geräte verwenden dieses Feld nicht, aber Sie müssen trotzdem einen Wert angeben.
**`otaDemoConfigFilePath`**
Der vollständige Pfad zu `aws_demo_config.h`, zu finden in `afr-source/vendors/vendor/boards/board/aws_demos/config_files/`. Diese Dateien sind in der Portierungscode-Vorlage enthalten, die FreeRTOS bereitstellt.
**`codeSigningConfiguration`**
Die Code-Signaturkonfiguration.
**`signingMethod`**
Die Code-Signaturmethode. Die möglichen Wert sind `AWS` oder `Custom`.
Verwenden Sie für die Regionen Peking und Ningxia. `Custom` `AWS`Codesignatur wird in diesen Regionen nicht unterstützt.
**`signerHashingAlgorithm`**
Der auf dem Gerät unterstützte Hashing-Algorithmus. Die möglichen Wert sind `SHA1` oder `SHA256`.
**`signerSigningAlgorithm`**
Der auf dem Gerät unterstützte Signaturalgorithmus. Die möglichen Wert sind `RSA` oder `ECDSA`.
**`signerCertificate`**
Das für OTA verwendete vertrauenswürdige Zertifikat.
Verwenden Sie als AWS Codesignaturmethode den Amazon-Ressourcennamen (ARN) für das vertrauenswürdige Zertifikat, das in den hochgeladen wurde AWS Certificate Manager.
Verwenden Sie für benutzerdefinierte Codesignaturmethode den absoluten Pfad zur Signiererzertifikatdatei.
Weitere Hinweise zum Erstellen eines vertrauenswürdigen Zertifikats finden Sie unter [Erstellen eines Zertifikats für die Codesignierung](ota-code-sign-cert.md).
**`signerCertificateFileName`**
Der Dateiname des Codesignaturzertifikats auf dem Gerät. Dieser Wert muss mit dem Dateinamen übereinstimmen, den Sie bei der Ausführung des `aws acm import-certificate` Befehls angegeben haben.
Weitere Informationen finden Sie unter [Erstellen eines Zertifikats für die Codesignierung](ota-code-sign-cert.md).
**`compileSignerCertificate`**
`true`Wird auf gesetzt, wenn das Zertifikat zur Überprüfung der Signatur des Codesigners nicht bereitgestellt oder geflasht wurde und daher in das Projekt kompiliert werden muss. AWS IoT Device Tester ruft das vertrauenswürdige Zertifikat ab und kompiliert es in. `aws_codesigner_certifiate.h`
**`untrustedSignerCertificate`**
Der ARN oder Dateipfad für ein zweites Zertifikat, das in einigen OTA-Tests als nicht vertrauenswürdiges Zertifikat verwendet wird. Weitere Informationen zum Erstellen eines Zertifikats finden Sie unter [Erstellen eines](https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert.html) Codesignaturzertifikats.
**`signerPlatform`**
Der Signier- und Hash-Algorithmus, den AWS Code Signer bei der Erstellung des OTA-Aktualisierungsjobs verwendet. Derzeit lauten die möglichen Werte für dieses Feld `AmazonFreeRTOS-TI-CC3220SF` und `AmazonFreeRTOS-Default`.
+ Wählen Sie bei `SHA1` und `RSA` `AmazonFreeRTOS-TI-CC3220SF` aus.
+ Wählen Sie bei `SHA256` und `ECDSA` `AmazonFreeRTOS-Default` aus.
Wenn Sie `SHA256` \$1 `RSA` oder `SHA1` \$1 `ECDSA` für Ihre Konfiguration benötigen, kontaktieren Sie uns, um weitere Unterstützung zu erhalten.
Konfigurieren Sie `signCommand`, wenn Sie `Custom` für `signingMethod` ausgewählt haben.
**`signCommand`**
Der Befehl, der zum Ausführen benutzerdefinierter Codesignaturen verwendet wird. Sie finden die Vorlage im Verzeichnis „`/configs/script_templates`“.
Die beiden Platzhalter „`{{inputImageFilePath}}`“ und „`{{outputSignatureFilePath}}`“ sind im Befehl erforderlich. `{{inputImageFilePath}}` ist der Dateipfad des von IDT erstellten Images, das signiert werden soll. `{{outputSignatureFilePath}}` ist der Dateipfad der Signatur, der vom Skript generiert wird.
**`cmakeConfiguration`**
CMake Konfiguration [optional]
Um CMake Testfälle auszuführen, müssen Sie den Boardnamen, den Herstellernamen und entweder das `frToolchainPath` Oder angeben`compilerName`. Sie können das auch angeben`cmakeToolchainPath`, wenn Sie einen benutzerdefinierten Pfad zur CMake Toolchain haben.
**`boardName`**
Der Name des Boards, das getestet wird. Der Boardname sollte mit dem Ordnernamen unter `path/to/afr/source/code/vendors/vendor/boards/board` übereinstimmen.
**`vendorName`**
Der Herstellername für die zu testende Karte. Der Anbieter sollte mit dem Ordnernamen unter `path/to/afr/source/code/vendors/vendor` übereinstimmen.
**`compilerName`**
Der Name des Compilers.
**`frToolchainPath`**
Der vollqualifizierte Pfad zur Compiler-Toolchain.
**`cmakeToolchainPath` **
Der vollständig qualifizierte Pfad zur Toolchain. CMake Dies ist ein optionales Feld.
**`freertosFileConfiguration`**
Die Konfiguration der FreeRTOS-Dateien, die IDT vor der Ausführung von Tests ändert.
**`required`**
In diesem Abschnitt werden die erforderlichen Tests angegeben, deren Konfigurationsdateien Sie verschoben haben PKCS11, z. B. TLS usw.
**`configName`**
Der Name des Tests, der konfiguriert wird.
**`filePath`**
Der absolute Pfad zu den Konfigurationsdateien innerhalb des `freertos` Repos. Verwenden Sie die `{{testData.sourcePath}}` Variable, um den Pfad zu definieren.
**`optional`**
In diesem Abschnitt werden optionale Tests angegeben, deren Konfigurationsdateien Sie verschoben haben WiFi, z. B. OTA usw.
**`configName`**
Der Name des Tests, der konfiguriert wird.
**`filePath`**
Der absolute Pfad zu den Konfigurationsdateien innerhalb des `freertos` Repos. Verwenden Sie die `{{testData.sourcePath}}` Variable, um den Pfad zu definieren.
**Anmerkung**
Um CMake Testfälle auszuführen, müssen Sie den Boardnamen, den Herstellernamen und entweder das `afrToolchainPath` Oder angeben`compilerName`. Sie können auch angeben`cmakeToolchainPath`, ob Sie einen benutzerdefinierten Pfad zur CMake Toolchain haben.
# IDT für FreeRTOS-Variablen
Die Befehle zum Erstellen Ihres Codes und zum Flashen des Geräts erfordern möglicherweise Konnektivität oder andere Informationen zu Ihren Geräten, um erfolgreich ausgeführt zu werden. AWS IoT Device Tester ermöglicht es Ihnen, Geräteinformationen in Flash zu referenzieren und Befehle zu erstellen mit [JsonPath](https://goessner.net/articles/JsonPath/). Mithilfe einfacher JsonPath Ausdrücke können Sie die erforderlichen Informationen abrufen, die in Ihrer `device.json` Datei angegeben sind.
## Pfadvariablen
IDT for FreeRTOS definiert die folgenden Pfadvariablen, die in Befehlszeilen und Konfigurationsdateien verwendet werden können:
**`{{testData.sourcePath}}`**
Wird auf den Quellcodepfad erweitert. Wenn Sie diese Variable verwenden, muss sie sowohl in den Flash- als auch in den Build-Befehlen verwendet werden.
**`{{sdkPath}}`**
Wird auf den Wert in Ihrem erweitert, `userData.sdkConfiguration.path` wenn es in den Befehlen Build und Flash verwendet wird.
**`{{device.connectivity.serialPort}}`**
Wird auf die serielle Schnittstelle erweitert.
**`{{device.identifiers[?(@.name == 'serialNo')].value[0]}}`**
Wird zur Seriennummer Ihres Geräts erweitert.
**`{{enableTests}}`**
Ganzzahliger Wert, der angibt, ob der Build für Tests (Wert 1) oder Demos (Wert 0) bestimmt ist.
**`{{buildImageName}}`**
Der Dateiname des mit dem Build-Befehl erstellten Image.
**`{{otaCodeSignerPemFile}}`**
PEM-Datei für den OTA-Codesigner.
**`{{config.idtRootPath}}`**
Erweitert auf den AWS IoT Device Tester Stammpfad. Diese Variable ersetzt den absoluten Pfad für IDT, wenn sie von den Befehlen build und flash verwendet wird.
# Verwenden Sie die IDT-Benutzeroberfläche, um die FreeRTOS Qualification Suite auszuführen
Ab IDT v4.3.0 enthält AWS IoT Device Tester for FreeRTOS (IDT-FreeRTOS) eine webbasierte Benutzeroberfläche, über die Sie mit der ausführbaren IDT-Befehlszeile und den zugehörigen Konfigurationsdateien interagieren können. Sie können die IDT-FreeRTOS-Benutzeroberfläche verwenden, um eine neue Konfiguration zum Ausführen von IDT-Tests zu erstellen oder eine bestehende Konfiguration zu ändern. Sie können die Benutzeroberfläche auch verwenden, um die IDT-Programmdatei aufzurufen und Tests auszuführen.
Die IDT-FreeRTOS-Benutzeroberfläche bietet die folgenden Funktionen:
+ Vereinfachen Sie die Einrichtung von Konfigurationsdateien für IDT-FreeRTOS-Tests.
+ Vereinfachen Sie die Verwendung von IDT-FreeRTOS zur Durchführung von Qualifikationstests.
Hinweise zur Verwendung der Befehlszeile zum Ausführen von Qualifikationstests finden Sie unter. [Erster Test Ihres Mikrocontroller-Boards](qual-steps.md)
Dieser Abschnitt beschreibt die Voraussetzungen für die Verwendung der IDT-FreeRTOS-Benutzeroberfläche und zeigt Ihnen, wie Sie mit der Ausführung von Qualifizierungstests in der Benutzeroberfläche beginnen.
**Topics**
+ [Richten Sie die Voraussetzungen für den Betrieb der FreeRTOS Qualification Suite ein](dev-tester-ui-prereqs.md)
+ [Erste Schritte mit der IDT-FreeRTOS-Benutzeroberfläche](dev-tester-ui-getting-started.md)
# Richten Sie die Voraussetzungen für den Betrieb der FreeRTOS Qualification Suite ein
In diesem Abschnitt werden die Voraussetzungen für das Testen von Mikrocontrollern mit AWS IoT Device Tester beschrieben.
**Topics**
+ [Verwenden Sie einen unterstützten Webbrowser](#idt-ui-supported-web-browser)
+ [FreeRTOS herunterladen](#ui-download-afr)
+ [Laden Sie IDT für FreeRTOS herunter](#ui-download-dev-tester-afr)
+ [Erstellen und konfigurieren Sie ein Konto AWS](#ui-config-aws-account)
+ [AWS IoT Device Tester verwaltete Richtlinie](#ui-managed-policy)
## Verwenden Sie einen unterstützten Webbrowser
Die IDT-FreeRTOS-Benutzeroberfläche unterstützt die folgenden Webbrowser.
| Browser | Version |
| --- | --- |
| Google Chrome | Die letzten drei Hauptversionen |
| Mozilla Firefox | Die letzten drei Hauptversionen |
| Microsoft Edge | Die letzten drei Hauptversionen |
| Apple Safari für macOS | Die letzten drei Hauptversionen |
Wir empfehlen Ihnen, Google Chrome oder Mozilla Firefox für eine bessere Benutzererfahrung zu verwenden.
**Anmerkung**
Die IDT-FreeRTOS-Benutzeroberfläche unterstützt Microsoft Internet Explorer nicht.
## FreeRTOS herunterladen
Sie können eine Version von FreeRTOS [GitHub](https://github.com/aws/amazon-freertos)mit dem folgenden Befehl herunterladen:
```
git clone --branch --recurse-submodules https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
wo ist eine Version von FreeRTOS (zum Beispiel 202007.00), die einer IDT-Version entspricht, die unter aufgeführt ist. [Unterstützte Versionen von AWS IoT Device Tester](dev-test-versions-afr.md) Dadurch wird sichergestellt, dass Sie über den vollständigen Quellcode einschließlich der Submodule verfügen und die richtige Version von IDT für Ihre Version von FreeRTOS verwenden und umgekehrt.
Windows hat eine Pfadlängenbegrenzung von 260 Zeichen. Die Pfadstruktur von FreeRTOS ist vielschichtig. Wenn Sie also Windows verwenden, sollten Sie Ihre Dateipfade unter dem Limit von 260 Zeichen halten. Klonen Sie FreeRTOS beispielsweise auf `C:\FreeRTOS` statt. `C:\Users\username\programs\projects\myproj\FreeRTOS\`
### Überlegungen zur LTS-Qualifizierung (Qualifizierung für FreeRTOS, das LTS-Bibliotheken verwendet)
+ Damit Ihr Mikrocontroller im AWS Partner Device Catalog als auf Long-Term Support (LTS) basierende Versionen von FreeRTOS unterstützt werden kann, müssen Sie eine Manifestdatei bereitstellen. Weitere Informationen finden Sie in der [FreeRTOS Qualification Checklist](https://docs.aws.amazon.com/freertos/latest/qualificationguide/afq-checklist.html) im *FreeRTOS* Qualification Guide.
+ Um zu überprüfen, ob Ihr Mikrocontroller LTS-basierte Versionen von FreeRTOS unterstützt, und um ihn für die Einreichung im AWS Partner Device Catalog zu qualifizieren, müssen Sie AWS IoT Device Tester (IDT) mit der FreeRTOS Qualification (FRQ) Test Suite Version v1.4.x verwenden.
+ Die Support für LTS-basierte Versionen von FreeRTOS ist auf die Version 202012.xx von FreeRTOS beschränkt.
## Laden Sie IDT für FreeRTOS herunter
Jede Version von FreeRTOS hat eine entsprechende Version von IDT für FreeRTOS zur Durchführung von Qualifizierungstests. Laden Sie die entsprechende Version von IDT für FreeRTOS von herunter. [Unterstützte Versionen von AWS IoT Device Tester](dev-test-versions-afr.md)
Extrahieren Sie IDT for FreeRTOS an einen Speicherort im Dateisystem, für den Sie Lese- und Schreibberechtigungen haben. Da Microsoft Windows eine Zeichenbeschränkung für die Pfadlänge hat, extrahieren Sie IDT für FreeRTOS in ein Stammverzeichnis wie oder. `C:\` `D:\`
**Anmerkung**
Es wird empfohlen, das IDT-Paket auf ein lokales Laufwerk zu extrahieren. Wenn mehrere Benutzer IDT von einem gemeinsam genutzten Speicherort ausführen können, z. B. von einem NFS-Verzeichnis oder einem gemeinsam genutzten Windows-Netzwerkordner, kann dies dazu führen, dass das System nicht reagiert oder Daten beschädigt werden.
## Erstellen und konfigurieren Sie ein Konto AWS
### Melden Sie sich an für ein AWS-Konto
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).
AWS sendet Ihnen nach Abschluss des Anmeldevorgangs eine Bestätigungs-E-Mail. Du kannst jederzeit deine aktuellen Kontoaktivitäten einsehen und dein Konto verwalten, indem du zu [https://aws.amazon.com/](https://aws.amazon.com/)gehst und **Mein Konto** auswählst.
### Erstellen eines Benutzers mit Administratorzugriff
Nachdem Sie sich für einen angemeldet haben AWS-Konto, sichern Sie Ihren Root-Benutzer des AWS-Kontos AWS IAM Identity Center, aktivieren und erstellen Sie einen Administratorbenutzer, sodass Sie den Root-Benutzer nicht für alltägliche Aufgaben verwenden.
**Sichern Sie Ihre Root-Benutzer des AWS-Kontos**
1. Melden Sie sich [AWS-Managementkonsole](https://console.aws.amazon.com/)als Kontoinhaber an, indem Sie **Root-Benutzer** auswählen und Ihre AWS-Konto E-Mail-Adresse eingeben. Geben Sie auf der nächsten Seite Ihr Passwort ein.
Hilfe bei der Anmeldung mit dem Root-Benutzer finden Sie unter [Anmelden als Root-Benutzer](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) im *AWS-Anmeldung -Benutzerhandbuch* zu.
1. Aktivieren Sie die Multi-Faktor-Authentifizierung (MFA) für den Root-Benutzer.
Anweisungen finden Sie unter [Aktivieren eines virtuellen MFA-Geräts für Ihren AWS-Konto Root-Benutzer (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) im *IAM-Benutzerhandbuch*.
**Erstellen eines Benutzers mit Administratorzugriff**
1. Aktivieren Sie das IAM Identity Center.
Anweisungen finden Sie unter [Aktivieren AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
1. Gewähren Sie einem Administratorbenutzer im IAM Identity Center Benutzerzugriff.
*Ein Tutorial zur Verwendung von IAM-Identity-Center-Verzeichnis als Identitätsquelle finden Sie IAM-Identity-Center-Verzeichnis im Benutzerhandbuch unter [Benutzerzugriff mit der Standardeinstellung konfigurieren](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html).AWS IAM Identity Center *
**Anmelden als Administratorbenutzer**
+ Um sich mit Ihrem IAM-Identity-Center-Benutzer anzumelden, verwenden Sie die Anmelde-URL, die an Ihre E-Mail-Adresse gesendet wurde, als Sie den IAM-Identity-Center-Benutzer erstellt haben.
Hilfe bei der Anmeldung mit einem IAM Identity Center-Benutzer finden Sie [im *AWS-Anmeldung Benutzerhandbuch* unter Anmeldung beim AWS Access-Portal](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html).
**Weiteren Benutzern Zugriff zuweisen**
1. Erstellen Sie im IAM-Identity-Center einen Berechtigungssatz, der den bewährten Vorgehensweisen für die Anwendung von geringsten Berechtigungen folgt.
Anweisungen hierzu finden Sie unter [ Berechtigungssatz erstellen](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
1. Weisen Sie Benutzer einer Gruppe zu und weisen Sie der Gruppe dann Single Sign-On-Zugriff zu.
Eine genaue Anleitung finden Sie unter [ Gruppen hinzufügen](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
## AWS IoT Device Tester verwaltete Richtlinie
Damit der Gerätetester ausgeführt und Messwerte gesammelt werden kann, enthält die `AWSIoTDeviceTesterForFreeRTOSFullAccess` verwaltete Richtlinie die folgenden Berechtigungen:
+ `iot-device-tester:SupportedVersion`
Erteilt die Erlaubnis, die Liste der von IDT unterstützten FreeRTOS-Versionen und Testsuite-Versionen abzurufen, sodass sie auf der verfügbar sind. AWS CLI
+ `iot-device-tester:LatestIdt`
Erteilt die Erlaubnis, die neueste AWS IoT Device Tester Version herunterzuladen, die zum Herunterladen verfügbar ist.
+ `iot-device-tester:CheckVersion`
Gewährt die Berechtigung, zu überprüfen, ob Kombinationen aus Produkt, Testsuite und AWS IoT Device Tester -Versionen kompatibel sind.
+ `iot-device-tester:DownloadTestSuite`
Erteilt die Erlaubnis AWS IoT Device Tester zum Herunterladen von Testsuiten.
+ `iot-device-tester:SendMetrics`
Erteilt die Erlaubnis zur Veröffentlichung AWS IoT Device Tester von Nutzungsmetrikdaten.
# Erste Schritte mit der IDT-FreeRTOS-Benutzeroberfläche
Dieser Abschnitt zeigt Ihnen, wie Sie die IDT-FreeRTOS-Benutzeroberfläche verwenden, um Ihre Konfiguration zu erstellen oder zu ändern, und zeigt Ihnen dann, wie Sie Tests ausführen.
**Topics**
+ [Anmeldeinformationen konfigurieren AWS](#configure-aws-credentials)
+ [Öffnen Sie die IDT-FreeRTOS-Benutzeroberfläche](#open-idt-ui)
+ [Erstellen Sie eine neue Konfiguration](#create-new-configuration)
+ [Ändern Sie eine bestehende Konfiguration](#modify-existing-configuration)
+ [Führen Sie Qualifizierungstests durch](#run-tests-from-ui)
## Anmeldeinformationen konfigurieren AWS
Sie müssen die Anmeldeinformationen für den AWS Benutzer konfigurieren, den Sie in erstellt haben[Erstellen und konfigurieren Sie ein Konto AWS](dev-tester-ui-prereqs.md#ui-config-aws-account). 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 Anmeldeinformationsdatei 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 =
```
**Anmerkung**
Wenn Sie das `default` AWS Profil nicht verwenden, geben Sie unbedingt den Profilnamen in der IDT-FreeRTOS-Benutzeroberfläche an. Weitere Informationen zu Profilen finden Sie unter [Konfiguration und Einstellungen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html) für Anmeldeinformationsdateien.
### 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. Die IDT-FreeRTOS-Benutzeroberfläche verwendet die `AWS_SECRET_ACCESS_KEY` Umgebungsvariablen `AWS_ACCESS_KEY_ID` und, um Ihre Anmeldeinformationen zu speichern. 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=
```
## Öffnen Sie die IDT-FreeRTOS-Benutzeroberfläche
**Um die IDT-FreeRTOS-Benutzeroberfläche zu öffnen**
1. Laden Sie eine unterstützte IDT-FreeRTOS-Version herunter und extrahieren Sie das heruntergeladene Archiv an einen Speicherort auf Ihrem Dateisystem, für den Sie Lese- und Schreibberechtigungen haben.
1. Führen Sie den folgenden Befehl aus, um zum IDT-FreeRTOS-Installationsverzeichnis zu navigieren:
```
cd devicetester-extract-location/bin
```
1. Führen Sie den folgenden Befehl aus, um die IDT-FreeRTOS-Benutzeroberfläche zu öffnen:
------
#### [ Linux ]
```
.devicetestergui_linux_x86-64.exe
```
------
#### [ Windows ]
```
./devicetestergui_win_x64-64
```
------
#### [ macOS ]
```
./devicetestergui_mac_x86-64
```
**Anmerkung**
Gehen Sie auf einem Mac zu **Systemeinstellungen -> Sicherheit und Datenschutz, damit Ihr System** die Benutzeroberfläche ausführen kann. Wenn Sie die Tests ausführen, müssen Sie dies möglicherweise noch dreimal tun.
------
Die IDT-FreeRTOS-Benutzeroberfläche wird in Ihrem Standardbrowser geöffnet. Informationen zu unterstützten Browsern finden Sie unter. [Verwenden Sie einen unterstützten Webbrowser](dev-tester-ui-prereqs.md#idt-ui-supported-web-browser)
## Erstellen Sie eine neue Konfiguration
Wenn Sie zum ersten Mal Benutzer sind, müssen Sie eine neue Konfiguration erstellen, um die JSON-Konfigurationsdateien einzurichten, die IDT-FreeRTOS zum Ausführen von Tests benötigt. Anschließend können Sie Tests ausführen oder die erstellte Konfiguration ändern.
Beispiele für die `userdata.json` Dateien `config.json``device.json`, und finden Sie unter[Erster Test Ihres Mikrocontroller-Boards](qual-steps.md). Ein Beispiel für die `resource.json` Datei, die nur für die Ausführung von Bluetooth Low Energy (BLE) -Tests verwendet wird, finden Sie unter[Führen Sie Bluetooth Low Energy-Tests durch](afr-bridgekeeper-dt-bt.md).
**Um eine neue Konfiguration zu erstellen**
1. **Öffnen Sie in der IDT-FreeRTOS-Benutzeroberfläche das Navigationsmenü und wählen Sie dann Neue Konfiguration erstellen.**
**Wichtig**
Sie müssen Ihre AWS Anmeldeinformationen konfigurieren, bevor Sie die Benutzeroberfläche öffnen. Wenn Sie Ihre Anmeldeinformationen nicht konfiguriert haben, schließen Sie das IDT-FreeRTOS-UI-Browserfenster, folgen Sie den Schritten unter[Anmeldeinformationen konfigurieren AWS](#configure-aws-credentials), und öffnen Sie dann die IDT-FreeRTOS-Benutzeroberfläche erneut.
1. Folgen Sie dem Konfigurationsassistenten, um die IDT-Konfigurationseinstellungen einzugeben, die für die Durchführung von Qualifikationstests verwendet werden. Der Assistent konfiguriert die folgenden Einstellungen in JSON-Konfigurationsdateien, die sich im `devicetester-extract-location/config` Verzeichnis befinden.
+ **AWS settings** — Die AWS-Konto Informationen, die IDT-FreeRTOS verwendet, um AWS Ressourcen während Testläufen zu erstellen. Diese Einstellungen sind in der Datei konfiguriert. `config.json`
+ **FreeRTOS-Repository** — Der absolute Pfad zum FreeRTOS-Repository und zum portierten Code sowie die Art der Qualifikation, die Sie durchführen möchten. Diese Einstellungen sind in der Datei konfiguriert. `userdata.json`
Sie müssen FreeRTOS für Ihr Gerät portieren, bevor Sie Qualifikationstests durchführen können. Weitere Informationen finden Sie im [FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/) Porting Guide
+ **Build and Flash** — Die Build- und Flash-Befehle für Ihre Hardware, mit denen IDT automatisch Tests auf Ihrem Board erstellen und flashen kann. Diese Einstellungen sind in der `userdata.json` Datei konfiguriert.
+ **Geräte** — Die Gerätepool-Einstellungen für die zu testenden Geräte. Diese Einstellungen werden in den `sku` Feldern `id` und und im `devices` Block für den Gerätepool in der `device.json` Datei konfiguriert.
+ **Netzwerk** — Die Einstellungen zum Testen der Netzwerkkommunikationsunterstützung für Ihre Geräte. Diese Einstellungen werden im `features` Block der `device.json` Datei und in den `testWifiConfig` Blöcken `clientWifiConfig` und in der `userdata.json` Datei konfiguriert.
+ **Echo-Server** — Die Echo-Server-Konfigurationseinstellungen für Secure-Socket-Tests. Diese Einstellungen sind in der `userdata.json` Datei konfiguriert.
Weitere Hinweise zur Echo-Serverkonfiguration finden Sie unter[https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-echo-server.html).
+ **CMake**— (Optional) Die Einstellungen für die Ausführung von CMake Build-Funktionstests. Diese Konfiguration ist nur erforderlich, wenn Sie sie CMake als Build-System verwenden. Diese Einstellungen sind in der `userdata.json` Datei konfiguriert.
+ **BLE** — Die Einstellungen für die Durchführung von Bluetooth Low Energy-Funktionstests. Diese Einstellungen werden im `features` Block der `device.json` Datei und in der `resource.json` Datei konfiguriert.
+ **OTA** — Die Einstellungen für die Ausführung von OTA-Funktionstests. Diese Einstellungen werden im `features` Block der `device.json` Datei und in der `userdata.json` Datei konfiguriert.
1. Überprüfen Sie auf der Seite **„**Überprüfen“ Ihre Konfigurationsinformationen.
Wenn Sie mit der Überprüfung Ihrer Konfiguration fertig sind, wählen Sie Tests **ausführen aus, um Ihre Qualifizierungstests durchzuführen**.
## Ändern Sie eine bestehende Konfiguration
Wenn Sie bereits Konfigurationsdateien für IDT eingerichtet haben, können Sie die IDT-FreeRTOS-Benutzeroberfläche verwenden, um Ihre bestehende Konfiguration zu ändern. Stellen Sie sicher, dass Ihre vorhandenen Konfigurationsdateien im Verzeichnis verfügbar sind. `devicetester-extract-location/config`
**Um eine neue Konfiguration zu ändern**
1. **Öffnen Sie in der IDT-FreeRTOS-Benutzeroberfläche das Navigationsmenü und wählen Sie dann Bestehende Konfiguration bearbeiten aus.**
Das Konfigurations-Dashboard zeigt Informationen zu Ihren vorhandenen Konfigurationseinstellungen an. Wenn eine Konfiguration falsch oder nicht verfügbar ist, lautet der Status für diese Konfiguration`Error validating configuration`.
1. Gehen Sie wie folgt vor, um eine bestehende Konfigurationseinstellung zu ändern:
1. Wählen Sie den Namen einer Konfigurationseinstellung, um die zugehörige Einstellungsseite zu öffnen.
1. Ändern Sie die Einstellungen und wählen Sie dann **Speichern**, um die entsprechende Konfigurationsdatei neu zu generieren.
Nachdem Sie die Änderung Ihrer Konfiguration abgeschlossen haben, stellen Sie sicher, dass alle Ihre Konfigurationseinstellungen die Validierung bestanden haben. Wenn der Status für jede Konfigurationseinstellung lautet`Valid`, können Sie Ihre Qualifizierungstests mit dieser Konfiguration ausführen.
## Führen Sie Qualifizierungstests durch
Nachdem Sie eine Konfiguration für IDT-FreerTOS erstellt haben, können Sie Ihre Qualifizierungstests ausführen.
**Um Qualifizierungstests durchzuführen**
1. Überprüfen Sie Ihre Konfiguration.
1. Wählen Sie im Navigationsmenü die Option **Tests ausführen aus**.
1. Um den Testlauf zu starten, wählen Sie **Tests starten**.
**IDT-FreerTOS führt die Qualifikationstests aus und zeigt die Zusammenfassung des Testlaufs sowie alle Fehler in der Test Runner-Konsole an.** Nach Abschluss des Testlaufs können Sie die Testergebnisse und Protokolle an den folgenden Orten einsehen:
+ Die Testergebnisse befinden sich im `devicetester-extract-location/results/execution-id` Verzeichnis.
+ Testprotokolle befinden sich im `devicetester-extract-location/results/execution-id/logs` Verzeichnis.
Weitere Informationen zu Testergebnissen und Protokollen finden Sie unter [Sehen Sie sich die Ergebnisse von IDT for FreeRTOS an](view-results-frq.md) und[Die IDT for FreeRTOS-Protokolle anzeigen](view-logs-frq.md).
# Führen Sie Bluetooth Low Energy-Tests durch
In diesem Abschnitt wird beschrieben, wie Sie Bluetooth Low Energy-Tests mit AWS IoT Device Tester for FreeRTOS einrichten und ausführen.
Bluetooth-Tests sind für wichtige Kernqualifikationen nicht erforderlich. Wenn Sie Ihr Gerät nicht mit FreeRTOS Bluetooth-Unterstützung testen möchten, können Sie diese Einrichtung überspringen. Achten Sie darauf, dass die BLE-Funktion in device.json auf eingestellt ist. `No`
## Voraussetzungen
+ Folgen Sie den Anweisungen in [Erster Test Ihres Mikrocontroller-Boards](qual-steps.md).
+ Ein Raspberry Pi 4B oder 3B\$1. (Erforderlich zum Ausführen der Raspberry Pi BLE-Begleitanwendung)
+ Ein MicroSD-Karten- und SD-Karten-Adapter für die Raspberry Pi-Software.
## Einrichtung von Raspberry Pi
Um die BLE-Funktionen des zu testenden Geräts (DUT) zu testen, benötigen Sie einen Raspberry Pi Model 4B oder 3B\$1.
**So konfigurieren Sie Ihren Raspberry Pi zum Ausführen von BLE-Tests**
1. Laden Sie eines der benutzerdefinierten Yocto-Images herunter, das die für die Durchführung der Tests erforderliche Software enthält.
+ [Bild für Raspberry Pi 4B](https://docs.aws.amazon.com/freertos/latest/userguide/freertos/IDTFR_BLE_RaspberryPi4B_1.0.0_2021-04-13.rpi-sd.img)
+ [Bild für Raspberry Pi 3B\$1](https://docs.aws.amazon.com/freertos/latest/userguide/freertos/IDTFR_BLE_RaspberryPi3Bplus_1.0.0_2021-04-13.rpi-sd.img)
**Anmerkung**
Das Yocto-Image sollte nur zum Testen mit FreeRTOS und nicht AWS IoT Device Tester für andere Zwecke verwendet werden.
1. Stellen Sie das Yocto-Image auf der SD-Karte für Raspberry Pi bereit.
1. Verwenden Sie ein Tool zum Schreiben von SD-Karten wie [Etcher](https://www.balena.io/etcher), um die heruntergeladene Datei auf die SD-Karte zu flashen. `image-name.rpi-sd.img` Da das Betriebssystem-Image sehr groß ist, kann dieser Schritt einige Zeit in Anspruch nehmen. Werfen Sie die SD-Karte dann aus und setzen Sie die microSD-Karte in Ihren Raspberry Pi ein.
1. Konfigurieren Sie Ihren Raspberry Pi.
1. Für den ersten Systemstart empfehlen wir, den Raspberry Pi mit einem Monitor, einer Tastatur und einer Maus zu verbinden.
1. Schließen Sie Ihren Raspberry Pi an eine Micro-USB-Energiequelle an.
1. Melden Sie sich mit den Standard-Anmeldeinformationen an. Geben Sie für die Benutzer-ID **root** ein. Geben Sie für Passwort **idtafr** ein.
1. Verbinden Sie den Raspberry Pi über eine Ethernet- oder WLAN-Verbindung mit Ihrem Netzwerk.
1. Um Ihren Raspberry Pi über WLAN zu verbinden, öffnen Sie `/etc/wpa_supplicant.conf` auf dem Raspberry Pi und fügen Sie Ihre WLAN-Anmeldeinformationen zur `Network`-Konfiguration hinzu.
```
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
network={
scan_ssid=1
ssid="your-wifi-ssid"
psk="your-wifi-password"
}
```
1. Führen Sie `ifup wlan0` aus, um die WLAN-Verbindung zu starten. Es kann einige Minuten dauern, eine Verbindung mit Ihrem WLAN-Netzwerk herzustellen.
1. Führen Sie für eine Ethernet-Verbindung `ifconfig eth0` aus. Führen Sie für eine WLAN-Verbindung `ifconfig wlan0` aus. Notieren Sie sich die IP-Adresse, die als `inet addr` in der Befehlsausgabe angezeigt wird. Sie benötigen die IP-Adresse zu einem späteren Zeitpunkt in diesem Verfahren.
1. (Optional) Die Tests führen Befehle auf dem Raspberry Pi unter Verwendung der Standard-Anmeldeinformationen für das Yocto Image über SSH aus. Als zusätzliche Sicherheitsmaßnahme empfehlen wir, die Authentifizierung über öffentliche Schlüssel für SSH einzurichten und passwortbasiertes SSH zu deaktivieren.
1. Erstellen Sie mithilfe des OpenSSL-Befehls `ssh-keygen` einen SSH-Schlüssel. Wenn Sie bereits ein SSK-Schlüsselpaar auf Ihrem Host-Computer haben, empfiehlt es sich, ein neues zu erstellen, damit AWS IoT Device Tester sich FreeRTOS auf Ihrem Raspberry Pi anmelden kann.
**Anmerkung**
Windows wird nicht mit einem installierten SSH-Client geliefert. Weitere Informationen zum Installieren eines SSH-Clients unter Windows finden Sie unter [Download SSH Software](https://www.ssh.com/ssh/#sec-Download-client-software).
1. 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\user-name`.
1. Wenn Sie zur Eingabe einer Schlüsselphrase aufgefordert werden, drücken Sie einfach die Eingabetaste, um fortzufahren.
1. Um Ihren SSH-Schlüssel zu Ihrem Raspberry Pi hinzuzufügen, damit AWS IoT Device Tester sich FreeRTOS auf dem Gerät anmelden kann, verwenden Sie den `ssh-copy-id` Befehl von Ihrem Host-Computer. Dieser Befehl fügt Ihren öffentlichen Schlüssel zur Datei `~/.ssh/authorized_keys` auf Ihrem Raspberry Pi hinzu.
`ssh-copy-id root@raspberry-pi-ip-address`
1. Wenn Sie zur Eingabe eines Passworts aufgefordert werden, geben Sie **idtafr** ein. Dies ist das Standard-Passwort für das Yocto Image.
**Anmerkung**
Der Befehl `ssh-copy-id` setzt voraus, dass der öffentliche Schlüssel die Bezeichnung `id_rsa.pub` trägt. Unter macOS und Linux ist der Standard-Speicherort ` ~/.ssh/`. Unter Windows ist der Standard-Speicherort `C:\Users\user-name\.ssh`. 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 ~/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).
1. Um zu testen, ob die Authentifizierung über öffentliche Schlüssel funktioniert, führen Sie `ssh -i /my/path/myKey root@raspberry-pi-device-ip` aus.
Wenn Sie nicht zur Eingabe eines Passworts aufgefordert werden, funktioniert Ihre Authentifizierung über öffentliche Schlüssel.
1. Stellen Sie sicher, dass Sie sich mit einem öffentlichen Schlüssel bei Ihrem Raspberry Pi anmelden können, und deaktivieren Sie anschließend das passwortbasierte SSH.
1. Bearbeiten Sie die Datei `/etc/ssh/sshd_config` auf dem Raspberry Pi.
1. Legen Sie für das Attribut `PasswordAuthentication` `no` fest.
1. Speichern und schließen Sie die Datei `sshd_config`.
1. Laden Sie den SSH-Server erneut, indem Sie `/etc/init.d/sshd reload` ausführen.
1. Erstellen Sie eine `resource.json`-Datei.
1. Erstellen Sie in dem Verzeichnis, in das Sie AWS IoT Device Tester extrahiert haben, eine Datei mit dem Namen. `resource.json`
1. Fügen Sie der Datei die folgenden Informationen über Ihren Raspberry Pi hinzu und *rasp-pi-ip-address* ersetzen Sie sie durch die IP-Adresse Ihres Raspberry Pi.
```
[
{
"id": "ble-test-raspberry-pi",
"features": [
{"name":"ble", "version":"4.2"}
],
"devices": [
{
"id": "ble-test-raspberry-pi-1",
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address"
}
}
]
}
]
```
1. Wenn Sie sich nicht dafür entschieden haben, die Authentifizierung mit öffentlichem Schlüssel für SSH zu verwenden, fügen Sie dem `connectivity` Abschnitt der `resource.json` Datei Folgendes hinzu.
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "password",
"credentials": {
"user": "root",
"password": "idtafr"
}
}
}
```
1. (Optional) Wenn Sie die Authentifizierung über öffentliche Schlüssel für SSH verwenden möchten, fügen Sie den folgenden `connectivity`-Abschnitt der `resource.json`-Datei hinzu.
```
"connectivity": {
"protocol": "ssh",
"ip": "rasp-pi-ip-address",
"auth": {
"method": "pki",
"credentials": {
"user": "root",
"privKeyPath": "location-of-private-key"
}
}
}
```
## FreeRTOS-Geräteeinrichtung
Legen Sie für die `BLE`-Funktion in Ihrer `device.json`-Datei `Yes` fest. Wenn Sie mit einer `device.json`-Datei von einem Zeitpunkt, bevor Bluetooth-Tests verfügbar waren, starten, müssen Sie die Funktion für BLE zum `features`-Array hinzufügen:
```
{
...
"features": [
{
"name": "BLE",
"value": "Yes"
},
...
}
```
## Führen Sie die BLE-Tests aus
Nachdem Sie die BLE-Funktion in `device.json` aktiviert haben, werden die BLE-Tests ausgeführt, wenn Sie `devicetester_[linux | mac | win_x86-64] run-suite` *ohne Angabe einer Gruppen-ID* ausführen.
Wenn Sie die BLE-Tests separat ausführen möchten, können Sie die Gruppen-ID für BLE angeben: `devicetester_[linux | mac | win_x86-64] run-suite --userdata path-to-userdata/userdata.json --group-id FullBLE`.
Um eine möglichst zuverlässige Leistung zu gewährleisten, platzieren Sie Ihren Raspberry Pi in der Nähe des zu prüfenden Geräts (Device under Test, DUT).
## Beheben Sie Fehler bei BLE-Tests
Stellen Sie sicher, dass Sie die unter [Erster Test Ihres Mikrocontroller-Boards](qual-steps.md) aufgeführten Schritte befolgt haben. Wenn andere Tests als BLE fehlschlagen, liegt das Problem mit hoher Wahrscheinlichkeit nicht an der Bluetooth-Konfiguration.
# Führen Sie die FreeRTOS Qualification Suite aus
Sie verwenden die ausführbare Datei AWS IoT Device Tester for FreeRTOS, um mit IDT for FreeRTOS zu interagieren. In den folgenden Befehlszeilenbeispielen wird veranschaulicht, wie Sie die Qualifikationsprüfungen für einen Gerätepool (Satz identischer Geräte) durchführen.
------
#### [ IDT v3.0.0 and later ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--group-id group-id \
--pool-id your-device-pool \
--test-id test-id \
--upgrade-test-suite y|n \
--update-idt y|n \
--update-managed-policy y|n \
--userdata userdata.json
```
Führt eine Reihe von Tests in einem Pool von Geräten aus. Die Datei `userdata.json` muss sich im Verzeichnis `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/` befinden.
**Anmerkung**
Wenn Sie IDT for FreeRTOS unter Windows ausführen, verwenden Sie Schrägstriche (/), um den Pfad zur Datei anzugeben. `userdata.json`
Verwenden Sie den folgenden Befehl zum Ausführen einer bestimmten Testgruppe:
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1.0.1 \
--group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
Die Parameter `suite-id` und `pool-id` sind optional, wenn Sie eine einzige Testsuite in einem einzigen Gerätepool ausführen (d. h. in Ihrer `device.json`-Datei ist nur ein Gerätepool definiert).
Verwenden Sie den folgenden Befehl zum Ausführen eines bestimmten Testfalls in einer Testgruppe:
```
devicetester_[linux | mac | win_x86-64] run-suite \
--group-id group-id \
--test-id test-id
```
Mit dem Befehl `list-test-cases` können Sie die Testfälle in einer Testgruppe auflisten. IDT für FreeRTOS-Befehlszeilenoptionen
**group-id**
(Optional) Die auszuführenden Testgruppen als kommagetrennte Liste. Bei fehlender Angabe führt IDT alle Testgruppen in der Testsuite aus.
**pool-id**
(Optional) Der zu testende Gerätepool. Dies ist erforderlich, wenn Sie mehrere Gerätepools in `device.json` definieren. Wenn Sie nur einen Gerätepool haben, können Sie diese Option weglassen.
**suite-id**
(Optional) Die auszuführende Test-Suite-Version. Falls nicht angegeben, verwendet IDT die neueste Version im Verzeichnis der Tests auf Ihrem System.
Ab IDT v3.0.0 sucht IDT online nach neueren Testsuiten. Weitere Informationen finden Sie unter [Test-Suite-Versionen](idt-test-suite-versions.md).
**test-id**
(Optional) Die auszuführenden Tests als kommagetrennte Liste. Wenn angegeben, muss `group-id` eine einzelne Gruppe angeben.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
**update-idt**
(Optional) Wenn dieser Parameter nicht festgelegt ist und eine neuere IDT-Version verfügbar ist, werden Sie aufgefordert, IDT zu aktualisieren. Wenn dieser Parameter auf gesetzt ist`Y`, stoppt IDT die Testausführung, wenn festgestellt wird, dass eine neuere Version verfügbar ist. Wenn dieser Parameter auf gesetzt ist`N`, setzt IDT die Testausführung fort.
**update-managed-policy**
(Optional) Wenn dieser Parameter nicht verwendet wird und IDT feststellt, dass Ihre verwaltete Richtlinie nicht verwendet wird up-to-date, werden Sie aufgefordert, Ihre verwaltete Richtlinie zu aktualisieren. Wenn dieser Parameter auf gesetzt ist`Y`, stoppt IDT die Testausführung, wenn festgestellt wird, dass Ihre verwaltete Richtlinie dies nicht tut. up-to-date Wenn dieser Parameter auf gesetzt ist`N`, setzt IDT die Testausführung fort.
**upgrade-test-suite**
(Optional) Wenn diese Version nicht verwendet wird und eine neuere Test-Suite-Version verfügbar ist, werden Sie aufgefordert, sie herunterzuladen. Um die Eingabeaufforderung auszublenden, geben Sie `y` an, damit immer die neueste Testsuite heruntergeladen wird, oder `n`, damit die angegebene Testsuite oder die neueste Version auf Ihrem System verwendet wird.
**Example**
**Beispiel**
Verwenden Sie den folgenden Befehl, um immer die neueste Testsuite herunterzuladen und zu verwenden.
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite y
```
Verwenden Sie den folgenden Befehl, um die neueste Testsuite auf Ihrem System zu verwenden.
```
devicetester_[linux | mac | win_x86-64] run-suite --userdata userdata file --group-id group ID --upgrade-test-suite n
```
**h**
Verwenden Sie die Hilfe-Option, um mehr über `run-suite`-Optionen zu erfahren.
**Example**
**Beispiel**
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
------
#### [ IDT v1.7.0 and earlier ]
```
devicetester_[linux | mac | win] run-suite \
--suite-id suite-id \
--pool-id your-device-pool \
--userdata userdata.json
```
Die Datei `userdata.json` sollte sich im Verzeichnis `devicetester_extract_location/devicetester_afreertos_[win|mac|linux]/configs/` befinden.
**Anmerkung**
Wenn Sie IDT for FreeRTOS unter Windows ausführen, verwenden Sie Schrägstriche (/), um den Pfad zur Datei anzugeben. `userdata.json`
Verwenden Sie den folgenden Befehl zum Ausführen einer bestimmten Testgruppe.
```
devicetester_[linux | mac | win] run-suite \
--suite-id FRQ_1 --group-id group-id \
--pool-id pool-id \
--userdata userdata.json
```
`suite-id` und `pool-id` sind optional, wenn Sie eine einzige Testsuite in einem einzigen Gerätepool ausführen (d. h. Sie haben nur einen Gerätepool in Ihrer `device.json`-Datei definiert).IDT für FreeRTOS-Befehlszeilenoptionen
**group-id**
(Optional) Gibt die Testgruppe an.
**pool-id**
Gibt den Gerätepool an, der getestet werden soll. Wenn Sie nur einen Gerätepool haben, können Sie diese Option weglassen.
**suite-id**
(Optional) Gibt die Testsuite an, die ausgeführt werden soll.
------
## IDT für FreeRTOS-Befehle
Der Befehl IDT for FreeRTOS unterstützt die folgenden Operationen:
------
#### [ IDT v3.0.0 and later ]
**`help`**
Listet Informationen über den angegebenen Befehl auf.
**`list-groups`**
Listet die Gruppen in der jeweiligen Suite auf.
**`list-suites`**
Listet die verfügbaren Suites auf.
**`list-supported-products`**
Listet die unterstützten Produkte und Testsuiteversionen auf.
**`list-supported-versions`**
Listet die FreeRTOS- und Testsuite-Versionen auf, die von der aktuellen IDT-Version unterstützt werden.
**`list-test-cases`**
Listet die Testfälle in einer angegebenen Gruppe auf.
**`run-suite`**
Führt eine Reihe von Tests in einem Pool von Geräten aus.
Verwenden Sie die Option `--suite-id`, um eine Test-Suite-Version anzugeben, oder lassen Sie sie weg, um die neueste Version auf Ihrem System zu verwenden.
Verwenden Sie die `--test-id` um einen einzelnen Testfall auszuführen.
**Example**
```
devicetester_[linux | mac | win_x86-64] run-suite --group-id mqtt --test-id mqtt_test
```
Eine vollständige Liste der Optionen finden Sie unter [Führen Sie die FreeRTOS Qualification Suite aus](#run-tests).
Ab IDT v3.0.0 sucht IDT online nach neueren Testsuiten. Weitere Informationen finden Sie unter [Test-Suite-Versionen](idt-test-suite-versions.md).
------
#### [ IDT v1.7.0 and earlier ]
**`help`**
Listet Informationen über den angegebenen Befehl auf.
**`list-groups`**
Listet die Gruppen in der jeweiligen Suite auf.
**`list-suites`**
Listet die verfügbaren Suites auf.
**`run-suite`**
Führt eine Reihe von Tests in einem Pool von Geräten aus.
------
## Tests für erneute Qualifikationen
Sobald neue Versionen von IDT for FreeRTOS Qualifizierungstests veröffentlicht werden oder wenn Sie Ihre platinenspezifischen Pakete oder Gerätetreiber aktualisieren, können Sie IDT for FreeRTOS verwenden, um Ihre Mikrocontroller-Boards zu testen. Stellen Sie für nachfolgende Qualifikationen sicher, dass Sie über die neuesten Versionen von FreeRTOS und IDT for FreeRTOS verfügen, und führen Sie die Qualifizierungstests erneut durch.
# Sehen Sie sich die Ergebnisse von IDT for FreeRTOS an
Während der Ausführung schreibt IDT Fehler in die Konsole, Protokolldateien und Testberichte. Nachdem IDT die Qualifikations-Testsuite abgeschlossen hat, schreibt es eine Zusammenfassung der Testläufe in die Konsole und erstellt zwei Testberichte. Diese Berichte befinden sich in `devicetester-extract-location/results/execution-id/`. Beide Berichte erfassen die Ergebnisse von der Ausführung der Qualifikations-Testsuite.
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 Version IDT für FreeRTOS.
+ Die getestete FreeRTOS-Version.
+ Die Funktionen von FreeRTOS, die vom Gerät unterstützt werden, basieren auf den bestandenen Tests.
+ SKU und Gerätename, die in der `device.json`-Datei angegeben wurden.
+ Die Funktionen des Geräts, das in der `device.json`-Datei angegeben wurde.
+ Die aggregierte Zusammenfassung der Ergebnisse der Testfälle.
+ Eine Aufschlüsselung der Testfallergebnisse nach Bibliotheken, die auf der Grundlage der Gerätefunktionen getestet wurden ( FullWiFiz. B. fullMQTT usw.).
+ Ob diese Qualifikation von FreeRTOS für Version 202012.00 gilt, die LTS-Bibliotheken verwendet.
[Das `FRQ_Report.xml` ist ein Bericht im Standard-XML-Format. JUnit ](https://llg.cubic.org/docs/junit/) Sie können ihn in CI/CD 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 Ergebnisse der Testfälle.
+ Eine Aufschlüsselung der Testfallergebnisse nach Bibliotheken, die basierend auf den Geräteeigenschaften getestet wurden.
# Interpretieren Sie die IDT for FreeRTOS-Ergebnisse
Der Berichtsabschnitt in `awsiotdevicetester_report.xml` oder `FRQ_Report.xml` listet die Ergebnisse der durchgeführten Tests auf.
Im ersten XML-Tag `` ist die Gesamtzusammenfassung der Testausführung enthalten. Beispiel:
``
**Im `` Tag verwendete Attribute**
**`name`**
Name der Testsuite
**`time`**
Zeit (in Sekunden), die zur Ausführung der Qualifikations-Suite erforderlich war
**`tests`**
Anzahl der ausgeführten Testfälle
**`failures`**
Anzahl der ausgeführten Testfälle, die den Test nicht bestanden haben
**`errors`**
Die Anzahl der Testfälle, die IDT für FreeRTOS nicht ausführen konnte.
**`disabled`**
Dieses Attribut wird nicht verwendet und kann ignoriert werden.
Wenn es keine Testfallausfälle oder Fehler gibt, erfüllt Ihr Gerät die technischen Voraussetzungen für die Ausführung von FreeRTOS und kann mit Diensten zusammenarbeiten. AWS IoT Wenn Sie Ihr Gerät im AWS Partner-Gerätekatalog auflisten möchten, können Sie diesen Bericht als Qualifikationsnachweis verwenden.
Falls bei Testfällen Fehler auftreten, können Sie den fehlgeschlagenen Testfall identifizieren, indem Sie die XML-Tags von `` überprüfen. Die XML-Tags von `` im ``-Tag zeigen die Ergebniszusammenfassung des Testfalls für eine Testgruppe.
``
Das Format ähnelt dem ``-Tag, weist aber ein zusätzliches Attribut mit dem Namen `skipped` auf, das nicht verwendet wird und ignoriert werden kann. Innerhalb der einzelnen XML-Tags von `` befinden sich ``-Tags für alle Testfälle, die für eine Testgruppe ausgeführt wurden. Beispiel:
``
**Im `` Tag verwendete Attribute**
**`name`**
Der Name des getesteten Produkts.
**`version`**
Die Version des getesteten Produkts.
**`sdk`**
Wenn Sie IDT mit einem SDK ausgeführt haben, enthält dieser Block den Namen und die Version Ihres SDK. Wenn Sie IDT nicht mit einem SDK ausgeführt haben, enthält dieser Block:
```
N/A
N/A
```
**`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 dies in der Datei aussieht. `awsiotdevicetester_report.xml`
```
```
Als `optional` gekennzeichnete Funktionen sind für die Qualifizierung nicht erforderlich. Die folgenden Codeausschnitte zeigen optionale Funktionen.
```
```
Wenn es keine Testfehler oder Fehler für die erforderlichen Funktionen gibt, erfüllt Ihr Gerät die technischen Voraussetzungen für die Ausführung von FreeRTOS und kann mit Diensten zusammenarbeiten. AWS IoT Wenn Sie Ihr Gerät im [AWS Partner-Gerätekatalog](https://partners.amazonaws.com/qualified-devices) 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. Beispiel:
```
```
Das Format ähnelt dem `` Tag, hat jedoch ein `skipped` Attribut, das nicht verwendet wird und ignoriert werden kann. Innerhalb der einzelnen ``-XML-Tags befinden sich ``-Tags für alle ausgeführten Tests einer Testgruppe. Beispiel:
```
```
**`lts`**
True, wenn Sie sich für eine Version von FreeRTOS qualifizieren, die LTS-Bibliotheken verwendet, andernfalls false.
**Im Tag verwendete Attribute ``**
**`name`**
Name des Testfalls
**`attempts`**
Gibt an, wie oft IDT für FreeRTOS 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. Beispiel:
```
Reason for the test case failure
Reason for the test case execution error
```
Weitere Informationen finden Sie unter [Beheben von Fehlern in der ](dt-afr-troubleshooting.md).
# Die IDT for FreeRTOS-Protokolle anzeigen
Logs, die IDT for FreeRTOS bei der Testausführung generiert, finden Sie unter. `devicetester-extract-location/results/execution-id/logs` Es werden zwei Protokollgruppen generiert:
**`test_manager.log`**
Enthält von IDT für FreeRTOS generierte Protokolle (z. B. Protokolle zur Konfiguration und Berichtserstellung).
**`test_group_id__test_case_id.log` (z. B. `FullMQTT__Full_MQTT.log`)**
Die Protokolldatei für einen Testfall, einschließlich der Ausgabe des zu testenden Geräts. Die Protokolldatei wird nach der Testgruppe und dem ausgeführten Testfall benannt.
# Entwickeln und betreiben Sie Ihre eigenen IDT-Testsuiten
Ab IDT v4.0.0 kombiniert IDT for FreeRTOS ein standardisiertes Konfigurations-Setup und ein 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 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 AWS IoT Device Tester for FreeRTOS herunter
Laden Sie die [neueste Version](dev-test-versions-afr.md#idt-latest-version-afr) von IDT herunter und extrahieren Sie die Software an einen Speicherort in Ihrem Dateisystem, für den Sie Lese- und 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 der 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](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-config-custom.md), um die Testsuite auszuführen.
1. Stellen Sie sicher, dass IDT Ihre Testsuite ausführen und die [Testergebnisse](run-tests-custom.md) erwartungsgemäß liefern kann.
Folgen Sie den Anweisungen unter, um schnell eine benutzerdefinierte Beispielsuite zu erstellen und auszuführen. [Tutorial: Erstellen Sie die IDT-Testsuite als Beispiel und führen Sie sie aus](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: Erstellen Sie die IDT-Testsuite als Beispiel und führen Sie sie aus
Der AWS IoT Device Tester Download enthält den Quellcode für eine Beispiel-Testsuite. Sie können dieses Tutorial abschließen, um die Beispiel-Testsuite zu erstellen und auszuführen, um zu verstehen, wie Sie AWS IoT Device Tester for FreeRTOS verwenden können, um benutzerdefinierte Testsuiten auszuführen. Obwohl dieses Tutorial SSH verwendet, ist es hilfreich zu lernen, wie man es AWS IoT Device Tester mit FreeRTOS-Geräten verwendet.
In diesem Tutorial werden Sie die folgenden Schritte ausführen:
1. [Erstellen Sie die Beispiel-Testsuite](build-sample.md)
1. [Verwenden Sie IDT, um die Beispieltestsuite auszuführen](run-sample.md)
**Topics**
+ [Richten Sie die Voraussetzungen für die Beispieltestsuite ein](prereqs-tutorial-sample.md)
+ [Geräteinformationen für IDT konfigurieren](configure-idt-sample.md)
+ [Erstellen Sie die Beispiel-Testsuite](build-sample.md)
+ [Verwenden Sie IDT, um die Beispieltestsuite auszuführen](run-sample.md)
+ [Beheben von Fehlern](tutorial-troubleshooting-custom.md)
# Richten Sie die Voraussetzungen für die Beispieltestsuite ein
Zum Durcharbeiten dieses Tutorials ist Folgendes erforderlich:
+
**Anforderungen an den Host-Computer**
+ Aktuelle Version von AWS IoT Device Tester
+ [Python](https://docs.python.org/3/) 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/3/).
+ [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.com/documentation/computers/remote-access.html) 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 durchzufü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 Testkonfigurationsdateien 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.md).
# 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 AWS 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
```
# Beheben von Fehlern
Verwenden Sie die folgenden Informationen, um Probleme beim Ausfüllen 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.md) 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:
+ Ausführbare Testdatei, die die Testlogik enthält
+ Konfigurationsdateien, die die Testsuite beschreiben
Dieses Tutorial zeigt Ihnen, wie Sie IDT for FreeRTOS verwenden, um eine Python-Testsuite zu entwickeln, die einen einzigen Testfall enthält. Obwohl dieses Tutorial SSH verwendet, ist es hilfreich zu lernen, wie man es AWS IoT Device Tester mit FreeRTOS-Geräten verwendet.
In diesem Tutorial werden Sie die folgenden Schritte ausführen:
1. [Erstellen Sie ein Testsuite-Verzeichnis](test-suite-dir.md)
1. [Erstellen Sie Konfigurationsdateien](test-suite-json.md)
1. [Erstellen Sie die ausführbare Testfalldatei](test-suite-exe.md)
1. [Führen Sie die Testsuite aus](run-test-suite.md)
Folgen Sie den nachstehenden Schritten, um ein Tutorial zur Entwicklung einer einfachen IDT-Testsuite abzuschließen.
**Topics**
+ [Richten Sie die Voraussetzungen für eine einfache IDT-Testsuite ein](prereqs-tutorial-custom.md)
+ [Erstellen Sie ein Testsuite-Verzeichnis](test-suite-dir.md)
+ [Erstellen Sie Konfigurationsdateien](test-suite-json.md)
+ [Holen Sie sich das IDT-Client-SDK](add-idt-sdk.md)
+ [Erstellen Sie die ausführbare Testfalldatei](test-suite-exe.md)
+ [Geräteinformationen für IDT konfigurieren](configure-idt-sample2.md)
+ [Führen Sie die Testsuite aus](run-test-suite.md)
+ [Beheben von Fehlern](tutorial-troubleshooting.md)
+ [Erstellen Sie Konfigurationsdateien für die IDT-Testsuite](idt-json-config.md)
+ [Konfigurieren Sie den IDT-Testorchestrator](idt-test-orchestrator.md)
+ [Konfigurieren Sie die IDT-Zustandsmaschine](idt-state-machine.md)
+ [Erstellen Sie eine ausführbare IDT-Testfalldatei](test-executables.md)
+ [Verwenden Sie den IDT-Kontext](idt-context.md)
+ [Konfigurieren Sie Einstellungen für Testläufer](set-config-custom.md)
+ [Debuggen Sie benutzerdefinierte Testsuiten und führen Sie sie aus](run-tests-custom.md)
+ [Überprüfen Sie die IDT-Testergebnisse und -Protokolle](idt-review-results-logs.md)
+ [Senden Sie IDT-Nutzungsmetriken](idt-usage-metrics.md)
# Richten Sie die Voraussetzungen für eine einfache IDT-Testsuite ein
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/3/).
+ [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.com/documentation/computers/remote-access.html) 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 Dateien**
**`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](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
Ausführbare 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 AWS 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
```
# Beheben von Fehlern
Verwenden Sie die folgenden Informationen, um Probleme beim Ausfüllen 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 unter beschrieben. [Holen Sie sich das IDT-Client-SDK](add-idt-sdk.md)
+ Sie erfüllen alle Voraussetzungen für dieses Tutorial. Weitere Informationen finden Sie unter [Richten Sie die Voraussetzungen für eine einfache IDT-Testsuite ein](prereqs-tutorial-custom.md).
**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.2 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-config-custom.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. [Erstellen Sie eine ausführbare IDT-Testfalldatei](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 Test-Runner 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 verglichen. 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. [Erstellen Sie eine ausführbare IDT-Testfalldatei](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#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-test-orchestrator.md#idt-test-orchestrator-context)](idt-context.md) verfügbar.
# Konfigurieren Sie den IDT-Testorchestrator
*Ab IDT v4.5.2 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 Testorchestrator ersetzt die IDT-Zustandsmaschine. Wir empfehlen dringend, anstelle der IDT State Machine den Test Orchestrator 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 Berichtsgenerierung, 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 `custom-test-suite-folder/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**
**Beispiel**
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. Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format).
`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`.
## 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.2 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 `statemachine.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](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 anzugeben, ohne einen einzelnen Testfall 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 der Status auf einen Ausführungsfehler stößt, 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` `true` ausgewertet wird.
**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 sequentiell 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, in dem Ausführungsfehler behoben werden.
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, setzen Sie ihn `ResultVar` auf`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 `suite-name_Report.xml` `awsiotdevicetester_report.xml` UND-Dateien. 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 zu ermitteln, 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 der Blöcke ü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 Zweigzustandsmaschinen 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"
}
}
}
```
# Erstellen Sie eine ausführbare IDT-Testfalldatei
Sie können eine ausführbare Testfalldatei auf folgende Weise erstellen und in einem Testsuite-Ordner ablegen:
+ Für Testsuiten, die Argumente oder Umgebungsvariablen aus den `test.json` Dateien verwenden, um zu bestimmen, welche Tests ausgeführt werden sollen, können Sie einen einzelnen ausführbaren Testfall für die gesamte Testsuite oder eine ausführbare Testdatei für jede Testgruppe in der Testsuite erstellen.
+ Für eine Testsuite, in der Sie bestimmte Tests auf der Grundlage bestimmter Befehle ausführen möchten, erstellen Sie für jeden Testfall in der Testsuite eine ausführbare Testfalldatei.
Als Testautor können Sie bestimmen, welcher Ansatz für Ihren Anwendungsfall geeignet ist, und die ausführbare Testfalldatei entsprechend strukturieren. Stellen Sie sicher, dass Sie in jeder `test.json` Datei den richtigen Pfad für die ausführbare Testfalldatei angeben und dass die angegebene ausführbare Datei korrekt ausgeführt wird.
Wenn alle Geräte für die Ausführung eines Testfalls bereit sind, 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**
+ [Interaktion mit Geräten](#api-device-interaction)
+ [IDT-Interaktion](#api-idt-interaction)
+ [Interaktion mit dem Host](#api-host-interaction)
### Interaktion mit Geräten
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
Mit den folgenden Befehlen können Ihre Testsuiten mit IDT 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. Damit Testläufer diese Optionen zum Ausführen Ihrer benutzerdefinierten Testsuite verwenden können, implementieren Sie Unterstützung für die IDT-CLI. Wenn Sie keine Unterstützung implementieren, können Testläufer weiterhin Tests ausführen, aber einige CLI-Optionen funktionieren nicht richtig. Um ein optimales Kundenerlebnis zu bieten, empfehlen wir, die Unterstützung für die folgenden Argumente für den `run-suite` Befehl in der IDT-CLI zu implementieren:
**`timeout-multiplier`**
Gibt einen Wert größer als 1,0 an, der auf alle Timeouts beim Ausführen von Tests angewendet wird.
Testläufer können dieses Argument verwenden, um das Timeout für die Testfälle zu erhöhen, die sie ausführen möchten. Wenn ein Testläufer dieses Argument in seinem `run-suite` Befehl angibt, verwendet IDT es, um den Wert der Umgebungsvariablen IDT\$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 die Zustandsmaschine für Ihre Testsuite einen bestimmten Satz von `RunTask` `Choice` Zuständen in Ihrer Zustandsmaschine enthalten. Wenn Sie keine benutzerdefinierte Zustandsmaschine verwenden, enthält die standardmäßige IDT-Zustandsmaschine die erforderlichen Zustände für Sie, und Sie müssen keine zusätzlichen Maßnahmen ergreifen. Wenn Sie jedoch eine benutzerdefinierte Zustandsmaschine verwenden, verwenden Sie sie [Beispiel für eine Zustandsmaschine: Führen Sie vom Benutzer ausgewählte Testgruppen aus](idt-state-machine.md#allow-specific-groups) als Beispiel, um die erforderlichen Zustände zu Ihrer Zustandsmaschine hinzuzufügen.
Weitere Informationen zu IDT-CLI-Befehlen finden Sie unter[Debuggen Sie benutzerdefinierte Testsuiten und führen Sie sie aus](run-tests-custom.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,
"idtRootPath":
},
"device": {
},
"devicePool": {
},
"resource": {
"devices": [
{
"name": ""
}
]
},
"testData": {
"awsCredentials": {
"awsAccessKeyId": "",
"awsSecretAccessKey": "",
"awsSessionToken": ""
},
"logFilePath": "/path/to/log/file"
},
"userData": {
}
}
```
**`config`**
Informationen aus der [`config.json`Datei](set-config-custom.md#config-json-custom). Das `config` Feld enthält außerdem die folgenden zusätzlichen Felder:
**`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`.
**`config.idRootPath`**
Dieser Wert ist ein Platzhalter für den absoluten Pfadwert von IDT bei der Konfiguration der Datei. `userdata.json` Dies wird von den Befehlen Build und Flash verwendet.
**`device`**
Informationen über das für den Testlauf ausgewählte Gerät. Diese Information entspricht dem `devices` Array-Element in der [`device.json`Datei](set-config-custom.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-config-custom.md#userdata-config-custom) bereitgestellt wurden.
## Greifen Sie auf Daten im Kontext zu
Sie können den Kontext anhand der JSONPath Notation aus Ihren Konfigurationsdateien 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`statemachine.json`, du benutzt`{{$.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 Foobar-Ausdruck beschrieben:
| Operator | Description |
| --- | --- |
| \$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 Abfragen \$1. 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 Zeichenkettenarrays 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.
# Konfigurieren Sie Einstellungen für Testläufer
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-tests-custom.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 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": "",
"pairedResource": "", //used for no-op protocol
"connectivity": {
"protocol": "ssh | uart | docker | no-op",
// ssh
"ip": "",
"port": ,
"publicKeyPath": "",
"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 Board im Gerätekatalog für AWS Partner anbieten 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 Funktionsnamen an und setzen den Funktionswert auf die von ihrem Gerät unterstützten QoS-Stufen. Sie können die bereitgestellten Informationen mit der Abfrage aus dem [IDT-Kontext](idt-context.md) oder mit der `devicePool.features` Abfrage aus dem [State-Machine-Kontext](idt-state-machine.md#state-machine-context) abrufen. `pool.features`
**`features.name`**
Der Name des Features.
**`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.
**`devices.pairedResource`**
Eine benutzerdefinierte eindeutige Kennung für ein Ressourcengerät. Dieser Wert ist erforderlich, wenn Sie Geräte testen, die das `no-op` Konnektivitätsprotokoll verwenden.
**`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 sind die einzigen unterstützten Werte `ssh` und `uart` für physische Geräte, `docker` für Docker-Container und `no-op` für Geräte, die keine direkte Verbindung mit dem IDT-Hostcomputer haben, aber ein Ressourcengerät als physische Middleware für die Kommunikation mit dem Host-Computer benötigen.
Für No-Op-Geräte konfigurieren Sie die Ressourcen-Geräte-ID in. `devices.pairedResource` Sie müssen diese ID auch in der `resource.json` Datei angeben. Bei dem gekoppelten Gerät muss es sich um ein Gerät handeln, das physisch mit dem zu testenden Gerät gekoppelt ist. Nachdem IDT das gekoppelte Ressourcengerät identifiziert und eine Verbindung zu diesem hergestellt hat, stellt IDT gemäß den in der Datei beschriebenen Funktionen keine Verbindung zu anderen Ressourcengeräten her. `test.json`
**`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 auf Befehlszeilenbasis 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`
**`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 `docker` 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 `docker` festgelegt ist.
Um zu überprüfen, ob Testläufer die falsche Geräteverbindung für einen Test konfigurieren, können Sie Daten `pool.Devices[0].Connectivity.Protocol` aus dem Zustandsmaschinenkontext abrufen und 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 über alle Geräte, 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": ,
"publicKeyPath": "",
"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.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 auf Befehlszeilenbasis 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`
**`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 `docker` 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 `docker` 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 [Senden Sie 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 Sie benutzerdefinierte Testsuiten und führen Sie sie aus
Nachdem die [erforderliche Konfiguration](set-config-custom.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 FreeRTOS-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 in einer IDE debuggen, ohne dass IDT interagiert. 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 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 FreeRTOS-Versionen und FreeRTOS Qualification Test Suite-Versionen, 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 an die Konsole, wenn eine Testsuite gestartet wird. Der folgende Auszug zeigt ein Beispiel für eine von IDT generierte Konsolennachricht.
```
[INFO] [2000-01-02 03:04:05]: 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.
```
[INFO] [2000-01-02 03:04:05]: Hello world! suiteId=MyTestSuitegroupId=myTestGroup testCaseId=myTestCase deviceId=my-deviceexecutionId=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.
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 AWS 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 unterschriebener 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 in der `device.json` Datei angegebene Gerätepoolname.
+ 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. 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. 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. 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. Beispiel:
```
Reason for the test failure
Reason for the test execution error
```
# Senden Sie IDT-Nutzungsmetriken
Wenn Sie AWS Anmeldeinformationen mit den erforderlichen Berechtigungen angeben, AWS IoT Device Tester sammelt und sendet Nutzungsdaten 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 zum Ausführen von IDT verwendet wurde
+ Die IDT-CLI-Befehle, die zum Ausführen von Tests verwendet werden
+ Die Testsuite, die ausgeführt wird
+ 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. unerwartete oder vorzeitige Austritte
Alle Informationen, die IDT sendet, werden auch in einer `metrics.log` Datei im Ordner protokolliert. `/results//` In der Protokolldatei können Sie die Informationen einsehen, die während eines Testlaufs gesammelt wurden. Diese Datei wird nur generiert, wenn Sie Nutzungsmetriken erfassen möchten.
Um die Erfassung von Messwerten zu deaktivieren, müssen Sie keine zusätzlichen Maßnahmen ergreifen. Speichern Sie Ihre AWS Anmeldeinformationen einfach nicht, und wenn Sie AWS Anmeldeinformationen gespeichert haben, konfigurieren Sie die `config.json` Datei nicht für den Zugriff darauf.
## Melden Sie sich an für ein AWS-Konto
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).
AWS sendet Ihnen nach Abschluss des Anmeldevorgangs eine Bestätigungs-E-Mail. Du kannst jederzeit deine aktuellen Kontoaktivitäten einsehen und dein Konto verwalten, indem du zu [https://aws.amazon.com/](https://aws.amazon.com/)gehst und **Mein Konto** auswählst.
## Erstellen eines Benutzers mit Administratorzugriff
Nachdem Sie sich für einen angemeldet haben AWS-Konto, sichern Sie Ihren Root-Benutzer des AWS-Kontos AWS IAM Identity Center, aktivieren und erstellen Sie einen Administratorbenutzer, sodass Sie den Root-Benutzer nicht für alltägliche Aufgaben verwenden.
**Sichern Sie Ihre Root-Benutzer des AWS-Kontos**
1. Melden Sie sich [AWS-Managementkonsole](https://console.aws.amazon.com/)als Kontoinhaber an, indem Sie **Root-Benutzer** auswählen und Ihre AWS-Konto E-Mail-Adresse eingeben. Geben Sie auf der nächsten Seite Ihr Passwort ein.
Hilfe bei der Anmeldung mit dem Root-Benutzer finden Sie unter [Anmelden als Root-Benutzer](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) im *AWS-Anmeldung -Benutzerhandbuch* zu.
1. Aktivieren Sie die Multi-Faktor-Authentifizierung (MFA) für den Root-Benutzer.
Anweisungen finden Sie unter [Aktivieren eines virtuellen MFA-Geräts für Ihren AWS-Konto Root-Benutzer (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) im *IAM-Benutzerhandbuch*.
**Erstellen eines Benutzers mit Administratorzugriff**
1. Aktivieren Sie das IAM Identity Center.
Anweisungen finden Sie unter [Aktivieren AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
1. Gewähren Sie einem Administratorbenutzer im IAM Identity Center Benutzerzugriff.
*Ein Tutorial zur Verwendung von IAM-Identity-Center-Verzeichnis als Identitätsquelle finden Sie IAM-Identity-Center-Verzeichnis im Benutzerhandbuch unter [Benutzerzugriff mit der Standardeinstellung konfigurieren](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html).AWS IAM Identity Center *
**Anmelden als Administratorbenutzer**
+ Um sich mit Ihrem IAM-Identity-Center-Benutzer anzumelden, verwenden Sie die Anmelde-URL, die an Ihre E-Mail-Adresse gesendet wurde, als Sie den IAM-Identity-Center-Benutzer erstellt haben.
Hilfe bei der Anmeldung mit einem IAM Identity Center-Benutzer finden Sie [im *AWS-Anmeldung Benutzerhandbuch* unter Anmeldung beim AWS Access-Portal](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html).
**Weiteren Benutzern Zugriff zuweisen**
1. Erstellen Sie im IAM-Identity-Center einen Berechtigungssatz, der den bewährten Vorgehensweisen für die Anwendung von geringsten Berechtigungen folgt.
Anweisungen hierzu finden Sie unter [ Berechtigungssatz erstellen](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
1. Weisen Sie Benutzer einer Gruppe zu und weisen Sie der Gruppe dann Single Sign-On-Zugriff zu.
Eine genaue Anleitung finden Sie unter [ Gruppen hinzufügen](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
Um Zugriff zu gewähren, fügen Sie Ihren Benutzern, Gruppen oder Rollen Berechtigungen hinzu:
+ Benutzer und Gruppen in AWS IAM Identity Center:
Erstellen Sie einen Berechtigungssatz. Befolgen Sie die Anweisungen unter [Erstellen eines Berechtigungssatzes](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
+ Benutzer, die in IAM über einen Identitätsanbieter verwaltet werden:
Erstellen Sie eine Rolle für den Identitätsverbund. Befolgen Sie die Anleitung unter [Eine Rolle für einen externen Identitätsanbieter (Verbund) erstellen](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) im *IAM-Benutzerhandbuch*.
+ IAM-Benutzer:
+ Erstellen Sie eine Rolle, die Ihr Benutzer annehmen kann. Befolgen Sie die Anleitung unter [Eine Rolle für einen IAM-Benutzer erstellen](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) im *IAM-Benutzerhandbuch*.
+ (Nicht empfohlen) Weisen Sie einem Benutzer eine Richtlinie direkt zu oder fügen Sie einen Benutzer zu einer Benutzergruppe hinzu. Befolgen Sie die Anweisungen unter [Hinzufügen von Berechtigungen zu einem Benutzer (Konsole)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) im *IAM-Benutzerhandbuch*.
## Geben Sie AWS Anmeldeinformationen für IDT ein
Gehen Sie wie folgt vor, damit IDT auf Ihre AWS Anmeldeinformationen zugreifen und Messwerte an AWS senden kann:
1. Speichern Sie die AWS Anmeldeinformationen für Ihren IAM-Benutzer als Umgebungsvariablen oder in einer Anmeldeinformationsdatei:
1. Führen Sie den folgenden Befehl aus, um Umgebungsvariablen zu verwenden:
```
AWS_ACCESS_KEY_ID=access-key
AWS_SECRET_ACCESS_KEY=secret-access-key
```
1. Um die Datei mit den Anmeldeinformationen zu verwenden, fügen Sie der Datei die folgenden Informationen hinzu `.aws/credentials file:`
```
[profile-name]
aws_access_key_id=access-key
aws_secret_access_key=secret-access-key
```
1. Konfigurieren Sie den `auth` Abschnitt der `config.json` Datei. Weitere Informationen finden Sie unter [(Optional) Konfigurieren Sie config.json](set-config-custom.md#config-json-custom).
# Pflegen Sie die Versionen der Testsuiten
IDT for FreeRTOS organisiert Testressourcen in Testsuiten und Testgruppen:
+ Eine Testsuite besteht aus einer Reihe von Testgruppen, die verwendet werden, um zu überprüfen, ob ein Gerät mit bestimmten Versionen von FreeRTOS funktioniert.
+ Eine Testgruppe ist der Satz einzelner Tests, die sich auf ein bestimmtes Funktion beziehen, z. B. BLE und MQTT Messaging.
Ab IDT v3.0.0 sind Testsuites beginnend mit 1.0.0 im Format `major`.`minor`.`patch` versioniert. Wenn Sie IDT herunterladen, enthält das Paket die neueste Test-Suite-Version.
Wenn Sie IDT in der Befehlszeilenschnittstelle starten, prüft IDT, ob eine neuere Test-Suite-Version verfügbar ist. Wenn ja, werden Sie aufgefordert, auf die neue Version zu aktualisieren. Sie können wählen, ob Sie aktualisieren oder mit Ihren aktuellen Tests fortfahren möchten.
**Anmerkung**
IDT unterstützt zur Qualifizierung die drei neuesten Test-Suite-Versionen. Weitere Informationen finden Sie unter [Machen Sie sich mit den Support-Richtlinien vertraut für AWS IoT Device Tester](idt-support-policy.md).
Mit dem Befehl `upgrade-test-suite` können Sie Testsuiten herunterladen. Oder Sie können den optionalen Parameter verwenden, `-upgrade-test-suite flag` wenn Sie IDT starten. Dabei *flag* kann '`y`' angegeben werden, um immer die neueste Version herunterzuladen, oder '`n`', um die vorhandene Version zu verwenden.
Sie können den `list-supported-versions` Befehl auch ausführen, um die FreeRTOS- und Testsuite-Versionen aufzulisten, die von der aktuellen Version von IDT unterstützt werden.
Neue Tests können neue IDT-Konfigurationseinstellungen einführen. Wenn die Einstellungen optional sind, benachrichtigt IDT Sie und setzt die Ausführung der Tests fort. Wenn die Einstellungen erforderlich sind, benachrichtigt IDT Sie und beendet die Ausführung. Nachdem Sie die Einstellungen konfiguriert haben, können Sie die Ausführung der Tests fortsetzen.
# Beheben von Fehlern in der
Jede Ausführung einer Testsuite verfügt über eine eindeutige Ausführungs-ID, die verwendet wird, um im Verzeichnis `results` einen Ordner mit dem Namen `results/execution-id` zu erstellen. Die einzelnen Testgruppenprotokolle befinden sich im Verzeichnis `results/execution-id/logs`. Verwenden Sie die IDT for FreeRTOS-Konsolenausgabe, um die Ausführungs-ID, Testfall-ID und Testgruppen-ID des fehlgeschlagenen Testfalls zu ermitteln, und öffnen Sie dann die Protokolldatei für diesen Testfall mit dem Namen. `results/execution-id/logs/test_group_id__test_case_id.log` Die Informationen in dieser Datei beinhalten Folgendes:
+ Vollständige Build- und Flash-Befehlsausgabe.
+ Testausführungsausgabe.
+ Ausführlichere IDT für die FreeRTOS-Konsolenausgabe.
Wir empfehlen folgenden Workflow für die Fehlersuche:
1. Wenn der Fehler "*user/role*ist nicht berechtigt, auf diese Ressource zuzugreifen“ angezeigt wird, stellen Sie sicher, dass Sie die Berechtigungen wie unter konfiguriert haben. [Erstellen und konfigurieren Sie ein Konto AWS](dev-tester-prereqs.md#config-aws-account)
1. Lesen Sie die Konsolenausgabe, um Informationen zu finden, wie z. B. Ausführungs-UUID und aktuell ausgeführte Aufgaben.
1. Suchen Sie in der Datei `FRQ_Report.xml` nach Fehleranweisungen für jeden Test. Dieses Verzeichnis enthält Ausführungsprotokolle für jede Testgruppe.
1. Schauen Sie in den Protokolldateien unter nach`/results/execution-id/logs`.
1. Untersuchen Sie einen der folgenden Problembereiche:
+ Gerätekonfiguration, wie z. B. JSON-Konfigurationsdateien im Ordner `/configs/`.
+ Geräteschnittstelle Überprüfen Sie die Protokolle, um festzustellen, welche Schnittstelle fehlschlägt.
+ Geräte-Tools Stellen Sie sicher, dass die Toolchains zum Erstellen und Flashen des Gerätes korrekt installiert und konfiguriert sind.
+ Stellen Sie für FRQ 1.x.x sicher, dass eine saubere, geklonte Version des FreeRTOS-Quellcodes verfügbar ist. FreeRTOS-Versionen sind entsprechend der FreeRTOS-Version gekennzeichnet. Verwenden Sie die folgenden Befehle, um eine bestimmte Version des Codes zu klonen:
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout --init --recursive
```
## Beheben Sie Fehler bei der Gerätekonfiguration
Wenn Sie IDT für FreeRTOS verwenden, müssen Sie die richtigen Konfigurationsdateien einrichten, bevor Sie die Binärdatei ausführen. Wenn Sie Parsing- und Konfigurationsfehler erhalten, sollten Sie als Erstes eine für Ihre Umgebung geeignete Konfigurationsvorlage suchen und anwenden. Diese Vorlagen befinden sich im Verzeichnis `IDT_ROOT/configs`.
Wenn weiterhin Probleme auftreten, beachten Sie den folgenden Debugging-Vorgang.
### Wo suche ich?
Lesen Sie zunächst die Konsolenausgabe, um Informationen zu finden, z. B. die Ausführungs-UUID, die in dieser Dokumentation als `execution-id` bezeichnet wird.
Suchen Sie als Nächstes in der Datei `FRQ_Report.xml` im Verzeichnis `/results/execution-id`. Diese Datei enthält alle ausgeführten Testfälle und Fehlerausschnitte zu jedem Fehler. Suchen Sie zum Abrufen aller Ausführungsprotokolle für jeden Testfall jeweils nach der Datei `/results/execution-id/logs/test_group_id__test_case_id.log`.
### IDT-Fehlercodes
In der folgenden Tabelle werden die von IDT für FreeRTOS generierten Fehlercodes erklärt:
| Fehlercode | Name des Fehlercodes | Mögliche Ursache | Fehlerbehebung |
| --- | --- | --- | --- |
| 201 | InvalidInputError | Felder in `device.json`, `config.json` oder `userdata.json` fehlen entweder oder haben ein falsches Format. | Stellen Sie sicher, dass die Pflichtfelder in den aufgelisteten Dateien nicht fehlen und dass sie das erforderliche Format aufweisen. Weitere Informationen finden Sie unter [Erster Test Ihres Mikrocontroller-Boards](qual-steps.md). |
| 202 | ValidationError | Felder in `device.json`, `config.json` oder `userdata.json` enthalten ungültige Werte. | Überprüfen Sie die Fehlermeldung auf der rechten Seite des Fehlercodes im Bericht: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 203 | CopySourceCodeError | Der FreeRTOS-Quellcode konnte nicht in das angegebene Verzeichnis kopiert werden. | Überprüfen Sie Folgendes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 204 | BuildSourceError | Der FreeRTOS-Quellcode konnte nicht kompiliert werden. | Überprüfen Sie Folgendes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/dt-afr-troubleshooting.html) |
| 205 | FlashOrRunTestError | IDT FreeRTOS kann FreeRTOS nicht auf Ihrem DUT flashen oder ausführen. | Überprüfen Sie, ob die Informationen unter `flashTool` in der Datei `userdata.json` korrekt sind. Weitere Informationen finden Sie unter [Konfiguration von Build-, Flash- und Testeinstellungen](cfg-dt-ud.md). |
| 206 | StartEchoServerError | IDT FreeRTOS kann den Echo-Server für die WiFi oder Secure Socket-Tests nicht starten. | Stellen Sie sicher, dass die unter `echoServerConfiguration` in Ihrer `userdata.json`-Datei konfigurierten Ports nicht von der Firewall oder den Netzwerkeinstellungen verwendet oder blockiert werden. |
### Fehler beim Parsen der Konfigurationsdatei debuggen
Es kann vorkommen, dass ein Tippfehler in einer JSON-Konfiguration zu Parsing-Fehlern führt. In den meisten Fällen ist die Ursache des Problems eine fehlende Klammer oder ein fehlendes Komma oder Anführungszeichen in Ihrer JSON-Datei. IDT for FreeRTOS führt eine JSON-Validierung durch und druckt Debugging-Informationen. Gedruckt werden die Zeile, in der der Fehler aufgetreten ist, sowie Zeilennummer und Spaltennummer des Syntaxfehlers. Diese Informationen sollten ausreichen, um Ihnen bei der Behebung des Fehlers zu helfen. Wenn Sie jedoch immer noch Probleme haben, den Fehler zu finden, können Sie die Validierung manuell in Ihrer IDE, einem Texteditor wie Atom oder Sublime oder über ein Online-Tool wie durchführen. JSONLint
### Debug-Testergebnisse, Analysieren von Fehlern
Beim Ausführen einer Testgruppe wie **FullTransportInterfaceTLS [ FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests), Full PKCS11 \$1Core, Full \$1Onboard\$1ECC, Full PKCS11 \$1Onboard\$1RSA, Full \$1 PKCS11 \$1ECC, Full PKCS11 \$1 PreProvisioned \$1RSA oder IDT for PreProvisioned FreeRTOS** analysiert die Testergebnisse des Testgeräts mit der seriellen **OTACore**Verbindung. PKCS11 Manchmal können zusätzliche serielle Ausgänge am Gerät die Auswertung der Testergebnisse beeinträchtigen.
Im oben genannten Fall werden seltsame Gründe für das Scheitern eines Testfalls ausgegeben, z. B. Zeichenfolgen, die von nicht verwandten Geräteausgängen stammen. Die IDT for FreeRTOS-Testfallprotokolldatei (die alle seriellen Ausgaben enthält, die IDT for FreeRTOS während des Tests erhalten hat) kann Folgendes enthalten:
```
TEST(Full_PKCS11_Capabilities, PKCS11_Capabilities)
PASS
```
**Im obigen Beispiel verhindert die unabhängige Geräteausgabe, dass IDT for FreeRTOS das Testergebnis PASS erkennt.**
Überprüfen Sie Folgendes, um ein optimales Testen sicherzustellen.
+ Stellen Sie sicher, dass die auf dem Gerät verwendeten Protokollierungsmakros threadsicher sind. Weitere Informationen finden Sie unter [Implementieren der Bibliotheksprotokollierungsmakros](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html).
+ Stellen Sie sicher, dass die serielle Verbindung während der Tests nur minimal ausgibt. Andere Geräteausgänge können ein Problem darstellen, selbst wenn Ihre Protokollierungsmakros ordnungsgemäß threadsicher sind, da die Testergebnisse während des Tests in separaten Aufrufen ausgegeben werden.
Ein IDT for FreeRTOS-Testfallprotokoll würde idealerweise eine unterbrechungsfreie Ausgabe der Testergebnisse wie folgt anzeigen:
```
---------STARTING TESTS---------
TEST(Full_OTA_PAL, otaPal_CloseFile_ValidSignature) PASS
TEST(Full_OTA_PAL, otaPal_CloseFile_InvalidSignatureBlockWritten) PASS
-----------------------
2 Tests 0 Failures 0 Ignored
```
### Fehler bei der Integritätsprüfung debuggen
Wenn Sie die FRQ 1.x.x-Version von FreeRTOS verwenden, gelten die folgenden Integritätsprüfungen.
Wenn Sie die kostenlose RTOSIntegrity Testgruppe ausführen und Fehler auftreten, stellen Sie zunächst sicher, dass Sie keine der Verzeichnisdateien geändert haben. `freertos` Falls dies nicht der Fall ist und weiterhin Probleme auftreten, stellen Sie sicher, dass Sie den richtigen Zweig verwenden. Wenn Sie den `list-supported-products` Befehl IDT ausführen, können Sie herausfinden, welchen markierten Zweig des `freertos` Repositorys Sie verwenden sollten.
Wenn Sie den richtigen markierten Zweig des `freertos` Repositorys geklont haben und immer noch Probleme haben, stellen Sie sicher, dass Sie den Befehl auch ausgeführt haben. `submodule update` Der Klon-Workflow für das `freertos` Repo sieht wie folgt aus.
```
git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout —init —recursive
```
Die Liste der Dateien, nach denen die Integritätsprüfung sucht, befindet sich in der `checksums.json` Datei in Ihrem `freertos` Verzeichnis. Um einen FreeRTOS-Port ohne Änderungen an den Dateien und der Ordnerstruktur zu qualifizieren, stellen Sie sicher, dass keine der in den Abschnitten '' und `exhaustive` '`minimal`' der `checksums.json` Datei aufgelisteten Dateien geändert wurde. Um die Ausführung mit einem konfigurierten SDK durchzuführen, stellen Sie sicher, dass keine der Dateien im Abschnitt `minimal` '' geändert wurde.
Wenn Sie IDT mit einem SDK ausführen und einige Dateien in Ihrem `freertos` Verzeichnis geändert haben, stellen Sie sicher, dass Sie Ihr SDK in Ihrer `userdata` Datei korrekt konfigurieren. Andernfalls überprüft der Integritätsprüfer alle Dateien im `freertos` Verzeichnis.
### Fehler bei FullWiFi Testgruppen debuggen
Wenn Sie FRQ 1.x.x verwenden und Fehler in der FullWiFi Testgruppe auftreten und der "`AFQP_WiFiConnectMultipleAP`" Test fehlschlägt, kann dies daran liegen, dass sich beide Access Points nicht im selben Subnetz befinden wie der Host-Computer, auf dem IDT ausgeführt wird. Stellen Sie sicher, dass sich beide Access Points im selben Subnetz befinden wie der Hostcomputer, auf dem IDT ausgeführt wird.
### Fehler „Erforderlicher Parameter fehlt“ beheben
Da IDT for FreeRTOS um neue Funktionen erweitert wird, können Änderungen an den Konfigurationsdateien vorgenommen werden. Bei Verwendung einer alten Konfigurationsdatei kann Ihre Konfiguration beschädigt werden. In diesem Fall listet die Datei `test_group_id__test_case_id.log` im Verzeichnis `results/execution-id/logs` explizit alle fehlenden Parameter auf. IDT for FreeRTOS validiert Ihre JSON-Konfigurationsdateischemas, um sicherzustellen, dass die neueste unterstützte Version verwendet wurde.
### Debuggen Sie die Fehler „Test konnte nicht gestartet werden“
Möglicherweise finden Sie Hinweise auf Fehler beim Teststart. Da es mehrere mögliche Ursachen gibt, überprüfen Sie die folgenden Bereiche auf ihre Richtigkeit:
+ Stellen Sie sicher, dass der in Ihrem Ausführungsbefehl enthaltene Poolname tatsächlich vorhanden ist. Auf diesen wird direkt über Ihre `device.json`-Datei verwiesen.
+ Stellen Sie sicher, dass die Geräte in Ihrem Pool über die richtigen Konfigurationsparameter verfügen.
### Debug-Fehler „Beginn der Testergebnisse konnte nicht gefunden werden“
Möglicherweise treten Fehler auf, wenn IDT versucht, die vom zu testenden Gerät ausgegebenen Ergebnisse zu analysieren. Es gibt mehrere mögliche Ursachen. Überprüfen Sie daher die folgenden Bereiche auf Richtigkeit:
+ Stellen Sie sicher, dass das zu testende Gerät eine stabile Verbindung zu Ihrem Host-Computer hat. Sie können in der Protokolldatei nach einem Test suchen, der diese Fehler anzeigt, um zu sehen, was IDT empfängt.
+ Wenn Sie FRQ 1.x.x verwenden und das zu testende Gerät über ein langsames Netzwerk oder eine andere Schnittstelle verbunden ist oder Sie das Flag „---------STARTING TESTS---------“ in einem FreeRTOS-Testgruppenprotokoll nicht zusammen mit anderen FreeRTOS-Testgruppenausgaben sehen, können Sie versuchen, den Wert von in Ihrer Benutzerdatenkonfiguration zu erhöhen. `testStartDelayms` Weitere Informationen finden Sie unter [Konfiguration von Build-, Flash- und Testeinstellungen](cfg-dt-ud.md).
### Debuggen Sie die Fehler „Testfehler: erwartete \$1\$1 Ergebnisse, aber es wurden \$1\$1\$1 gesehen“
Möglicherweise werden beim Testen Fehler angezeigt, die auf einen Testfehler hinweisen. Der Test erwartet eine bestimmte Anzahl von Ergebnissen und wird während des Tests nicht angezeigt. Einige FreeRTOS-Tests werden ausgeführt, bevor IDT die Ausgabe des Geräts sieht. *Wenn Sie diesen Fehler sehen, können Sie versuchen, den Wert von `testStartDelayms` in Ihrer Benutzerdatenkonfiguration zu erhöhen.* Weitere Informationen finden Sie unter [Konfiguration von Build-, Flash- und Testeinstellungen](lts-cfg-dt-ud.md).
### Debuggen Sie den Fehler „\$1\$1\$1\$1\$1\$1\$1\$1 wurde aufgrund von Einschränkungen nicht ausgewählt“ ConditionalTests
Das bedeutet, dass Sie einen Test auf einem Gerätepool ausführen, der mit dem Test nicht kompatibel ist. Dies kann bei den OTA E2E-Tests passieren. **Beispielsweise haben Sie beim Ausführen der `OTADataplaneMQTT` Testgruppe und in Ihrer `device.json` Konfigurationsdatei OTA als **Nein oder `OTADataPlaneProtocol` als HTTP** ausgewählt.** Die Testgruppe, die Sie ausführen möchten, muss Ihrer `device.json` Funktionsauswahl entsprechen.
### Debuggen Sie einen IDT-Timeout während der Überwachung der Geräteausgabe
IDT kann aus verschiedenen Gründen zu einem Timeout führen. Wenn während der Phase der Überwachung der Geräteausgänge eines Tests ein Timeout auftritt und Sie die Ergebnisse im IDT-Testfallprotokoll sehen können, bedeutet dies, dass die Ergebnisse von IDT falsch analysiert wurden. Ein Grund könnten die verschachtelten Protokollnachrichten in der Mitte der Testergebnisse sein. Wenn dies der Fall ist, finden Sie im [FreeRTOS Porting Guide](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-ota.html) weitere Informationen darüber, wie die UNITY-Logs eingerichtet werden sollten.
Ein weiterer Grund für ein Timeout bei der Überwachung der Geräteausgabe könnte sein, dass ein Gerät nach einem einzigen Fehler im TLS-Testfall neu gestartet wird. Das Gerät führt dann das Flash-Image aus und verursacht eine Endlosschleife, die in den Protokollen zu sehen ist. Stellen Sie in diesem Fall sicher, dass Ihr Gerät nach einem fehlgeschlagenen Test nicht neu gestartet wird.
### Debuggen Sie den Fehler „Nicht autorisiert, auf die Ressource zuzugreifen“
Möglicherweise wird der Fehler "*user/role*ist nicht berechtigt, auf diese Ressource zuzugreifen“ in der Terminalausgabe oder in der `test_manager.log` Datei unter angezeigt`/results/execution-id/logs`. Um dieses Problem zu beheben, fügen Sie die `AWS IoTDeviceTesterForFreeRTOSFullAccess`-verwaltete Richtlinie an Ihren Testbenutzer an. Weitere Informationen finden Sie unter [Erstellen und konfigurieren Sie ein Konto AWS](dev-tester-prereqs.md#config-aws-account).
### Fehler bei Netzwerktests debuggen
Für netzwerkbasierte Tests startet IDT einen Echo-Server, der sich an einen nicht reservierten Port auf dem Hostcomputer bindet. Wenn Sie aufgrund von Timeouts oder nicht verfügbaren Verbindungen bei den Tests WiFi oder Secure Sockets auf Fehler stoßen, stellen Sie sicher, dass Ihr Netzwerk so konfiguriert ist, dass Datenverkehr zu konfigurierten Ports im Bereich 1024 bis 49151 zugelassen wird.
Der Secure Sockets-Test verwendet standardmäßig die Ports 33333 und 33334. Die WiFi Tests verwenden standardmäßig Port 33335. Wenn diese drei Ports von einer Firewall oder einem Netzwerk verwendet oder blockiert werden, können Sie verschiedene Ports in userdata.json zum Testen verwenden. Weitere Informationen finden Sie unter [Konfiguration von Build-, Flash- und Testeinstellungen](cfg-dt-ud.md). Sie können mit den folgenden Befehle überprüfen, ob ein bestimmter Port verwendet wird:
+ Windows: `netsh advfirewall firewall show rule name=all | grep port`
+ Linux: `sudo netstat -pan | grep port`
+ macOS: `netstat -nat | grep port`
### Fehler beim OTA-Update aufgrund der Payload derselben Version
Wenn OTA-Testfälle fehlschlagen, weil sich dieselbe Version auf dem Gerät befindet, nachdem ein OTA ausgeführt wurde, kann dies daran liegen, dass Ihr Build-System (z. B. cmake) die Änderungen von IDT am FreeRTOS-Quellcode nicht bemerkt und keine aktualisierte Binärdatei erstellt. Dies führt dazu, dass OTA mit der gleichen Binärdatei durchgeführt wird, die sich bereits auf dem Gerät befindet, weshalb der Test fehlschlägt. Um OTA-Updatefehler zu beheben, stellen Sie zunächst sicher, dass Sie die neueste unterstützte Version Ihres Build-Systems verwenden.
### OTA-Testfehler im `PresignedUrlExpired`-Testfall
Eine Voraussetzung für diesen Test ist, dass die OTA-Update-Zeit mehr als 60 Sekunden betragen sollte, da der Test andernfalls fehlschlagen würde. In diesem Fall ist im Protokoll die folgende Fehlermeldung zu finden: „Test takes less than 60 seconds (url expired time) to finish. (Abschluss des Tests dauert weniger als 60 Sekunden (URL-Ablaufzeit). Please reach out to us (Bitte kontaktieren Sie uns).“
### Debuggen Sie Geräteschnittstellen- und Portfehler
Dieser Abschnitt enthält Informationen über die Geräteschnittstellen, die IDT zur Verbindung mit Ihren Geräten verwendet.
#### Unterstützte Plattformen
IDT unterstützt Linux, MacOS und Windows. Auf allen drei Plattformen werden unterschiedliche Benennungen für serielle Geräte verwendet, die mit ihnen verbunden sind:
+ Linux: `/dev/tty*`
+ macOS: `/dev/tty.*` oder `/dev/cu.*`
+ Windows: COM\$1
So überprüfen Sie den Geräteport:
+ Öffnen Sie unter Linux/macOS ein Terminal und führen Sie `ls /dev/tty*` aus.
+ Öffnen Sie unter macOS ein Terminal und führen Sie `ls /dev/tty.*` oder `ls /dev/cu.*` aus.
+ Öffnen Sie in Windows Sie den Geräte-Manager und erweitern Sie die Gruppe mit den seriellen Geräten.
Um zu überprüfen, welches Gerät mit einem Port verbunden ist:
+ Stellen Sie unter Linux sicher, dass das Paket `udev` installiert ist, und führen Sie dann `udevadm info –name=PORT` aus. Dieses Dienstprogramm gibt die Gerätetreiberinformationen aus, mit deren Hilfe Sie überprüfen können, ob Sie den richtigen Port verwenden.
+ Öffnen Sie für macOS Launchpad und suchen Sie nach **System Information**.
+ Öffnen Sie in Windows Sie den Geräte-Manager und erweitern Sie die Gruppe mit den seriellen Geräten.
#### Geräteschnittstellen
Jedes eingebettete Gerät ist anders. Dies bedeutet, dass sie einen oder mehrere serielle Ports haben können. Es ist üblich, dass Geräte über zwei Ports verfügen, wenn sie mit einer Maschine verbunden sind:
+ Ein Datenport zum Flashen des Geräts.
+ Ein Leseport zum Lesen der Ausgabe.
Sie müssen den richtigen Leseport in Ihrer `device.json`-Datei festlegen. Andernfalls kann das Lesen der Ausgabe vom Gerät fehlschlagen.
Vergewissern Sie sich bei mehreren Ports, dass Sie den Leseport des Geräts in Ihrer `device.json`-Datei verwenden. Wenn Sie beispielsweise ein WRover Espressif-Gerät anschließen und die beiden ihm zugewiesenen Anschlüsse als `/dev/ttyUSB0` und `/dev/ttyUSB1` `/dev/ttyUSB1` in Ihrer `device.json` Datei verwenden.
Folgen Sie derselben Logik in Windows.
#### Lesen von Gerätedaten
IDT for FreeRTOS verwendet individuelle Gerätebau- und Flash-Tools, um die Portkonfiguration zu spezifizieren. Wenn Sie Ihr Gerät testen und keine Ausgabe erhalten, versuchen Sie es mit den folgenden Standardeinstellungen:
+ Baudrate: 115200
+ Datenbits: 8
+ Parität: Keine
+ Stop-Bits: 1
+ Flusssteuerung: Keine
Diese Einstellungen werden von IDT für FreeRTOS verwaltet. Sie müssen sie nicht festlegen. Sie können jedoch dieselbe Methode verwenden, um die Geräteausgabe manuell zu lesen. Unter Linux oder macOS ist dies mit dem Befehl `screen` möglich. Unter Windows können Sie ein Programm wie verwenden. TeraTerm
`Screen: screen /dev/cu.usbserial 115200`
`TeraTerm: Use the above-provided settings to set the fields explicitly in the GUI.`
### Probleme mit der Entwicklungs-Toolchain
In diesem Abschnitt werden Probleme beschrieben, die mit Ihrer Tool-Chain auftreten können.
#### Code Composer Studio auf Ubuntu
In den neueren Versionen von Ubuntu (17.10 und 18.04) ist eine Version des `glibc`-Pakets enthalten, die nicht mit den Versionen von Code Composer Studio 7.*x* kompatibel ist. Wir empfehlen, Code Composer Studio Version 8.2 oder höher zu installieren.
Folgende Anzeichen der Inkompatibilität könnten auftreten:
+ FreeRTOS kann nicht erstellt oder auf Ihr Gerät geflasht werden.
+ Das Code Composer Studio-Installationsprogramm stürzt ab.
+ In der Konsole wird keine Protokollausgabe während des Build- oder Flash-Prozesses angezeigt.
+ Der Build-Befehl versucht, im GUI-Modus zu starten, auch wenn er im Headless-Modus aufgerufen wird.
### Protokollierung
IDT for FreeRTOS-Protokolle werden an einem einzigen Ort gespeichert. Im IDT-Stammverzeichnis sind diese Dateien unter `results/execution-id/` verfügbar:
+ `FRQ_Report.xml`
+ `awsiotdevicetester_report.xml`
+ `logs/test_group_id__test_case_id.log`
`FRQ_Report.xml` und `logs/test_group_id__test_case_id.log` sind die wichtigsten Protokolle, die Sie untersuchen sollten. `FRQ_Report.xml` enthält Informationen dazu, für welche Testfälle Fehler mit einer bestimmten Fehlermeldung aufgetreten sind. Anschließend können Sie `logs/test_group_id__test_case_id.log` verwenden, um das Problem genauer zu analysieren und so einen besseren Kontext zu erhalten.
#### Konsolenfehler
Wenn AWS IoT Device Tester es ausgeführt wird, werden Fehler mit kurzen Meldungen an die Konsole gemeldet. Weitere Informationen zum Fehler finden Sie unter `results/execution-id/logs/test_group_id__test_case_id.log`.
#### Protokollfehler
Jede Ausführung der Testsuite verfügt über eine eindeutige Ausführungs-ID, die zum Erstellen eines Ordners mit dem Namen `results/execution-id` verwendet wird. Einzelne Testfallprotokolle befinden sich im Verzeichnis `results/execution-id/logs`. Verwenden Sie die Ausgabe der IDT for FreeRTOS-Konsole, um die Ausführungs-ID, die Testfall-ID und die Testgruppen-ID des fehlgeschlagenen Testfalls zu ermitteln. Verwenden Sie dann diese Informationen, um die Protokolldatei für diesen Testfall mit dem Namen zu finden und zu öffnen. `results/execution-id/logs/test_group_id__test_case_id.log` Die Informationen in dieser Datei umfassen die vollständige Build- und Flash-Befehlsausgabe, die Ausgabe der Testausführung und eine AWS IoT Device Tester ausführlichere Konsolenausgabe.
#### Probleme mit dem S3-Bucket
Wenn Sie CTRL\$1C während der Ausführung von IDT die Taste drücken, startet IDT einen Bereinigungsprozess. Ein Teil dieser Bereinigung besteht darin, Amazon S3 S3-Ressourcen zu entfernen, die im Rahmen der IDT-Tests erstellt wurden. Wenn die Bereinigung nicht abgeschlossen werden kann, tritt möglicherweise ein Problem auf, bei dem zu viele Amazon S3 S3-Buckets erstellt wurden. Das bedeutet, dass die Tests fehlschlagen werden, wenn Sie IDT das nächste Mal ausführen.
Wenn Sie CTRL\$1C die Taste drücken, um IDT zu beenden, müssen Sie den Bereinigungsvorgang beenden lassen, um dieses Problem zu vermeiden. Sie können auch die manuell erstellten Amazon S3 S3-Buckets aus Ihrem Konto löschen.
## Beheben Sie Timeout-Fehler
Wenn beim Ausführen einer Testsuite Timeout-Fehler auftreten, erhöhen Sie das Timeout, indem Sie einen Timeout-Multiplikatorfaktor angeben. Dieser Faktor wird auf den Standardwert für die Zeitüberschreitung angewendet. Jeder Wert für dieses Kennzeichen muss größer als oder gleich 1,0 sein. Um den Timeout-Multiplikator zu verwenden, verwenden Sie beim Ausführen der Testsuite das Flag `--timeout-multiplier`.
**Example**
```
./devicetester_linux run-suite --suite-id FRQ_1.0.1 --pool-id DevicePool1 --timeout-multiplier 2.5
```
```
./devicetester_linux run-suite --suite-id FRQ_1 --pool-id DevicePool1 --timeout-multiplier 2.5
```
## Mobilfunkfunktion und Gebühren AWS
Wenn die `Cellular` Funktion `Yes` in Ihrer `device.JSON` Datei auf eingestellt ist, FullSecureSockets werden T.micro EC2-Instances für die Ausführung von Tests verwendet, was zu zusätzlichen Kosten für Ihr Konto führen kann. AWS Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/).
## Richtlinie zur Generierung von Qualifikationsberichten
Qualifizierungsberichte werden nur von AWS IoT Device Tester (IDT-) Versionen generiert, die FreeRTOS-Versionen unterstützen, die in den letzten zwei Jahren veröffentlicht wurden. Wenn Sie Fragen zu den Support-Richtlinien haben, wenden Sie sich bitte an. [AWS Support](https://aws.amazon.com/contact-us/)
# Verstehen Sie die AWS verwaltete Richtlinie für AWS IoT Device Tester
Eine AWS verwaltete Richtlinie ist eine eigenständige Richtlinie, die von erstellt und verwaltet wird AWS. AWS Verwaltete Richtlinien sind so konzipiert, dass sie Berechtigungen für viele gängige Anwendungsfälle bereitstellen, sodass Sie damit beginnen können, Benutzern, Gruppen und Rollen Berechtigungen zuzuweisen.
Denken Sie daran, dass AWS verwaltete Richtlinien für Ihre speziellen Anwendungsfälle möglicherweise keine Berechtigungen mit den geringsten Rechten gewähren, da sie für alle AWS Kunden verfügbar sind. Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie [vom Kunden verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind.
Sie können die in AWS verwalteten Richtlinien definierten Berechtigungen nicht ändern. Wenn die in einer AWS verwalteten Richtlinie definierten Berechtigungen AWS aktualisiert werden, wirkt sich das Update auf alle Prinzidentitäten (Benutzer, Gruppen und Rollen) aus, denen die Richtlinie zugeordnet ist. AWS aktualisiert eine AWS verwaltete Richtlinie höchstwahrscheinlich, wenn eine neue Richtlinie eingeführt AWS-Service wird oder neue API-Operationen für bestehende Dienste verfügbar werden.
Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) im *IAM-Benutzerhandbuch*.
**Topics**
+ [AWS verwaltete Richtlinie: AWS Io TDevice TesterForFree RTOSFull Access](#aws-managed-policies-AWSIoTDT)
+ [Aktualisierungen der AWS verwalteten Richtlinien](#aws-managed-policy-updates)
## AWS verwaltete Richtlinie: AWS Io TDevice TesterForFree RTOSFull Access
Die `AWSIoTDeviceTesterForFreeRTOSFullAccess` verwaltete Richtlinie enthält die folgenden AWS IoT Device Tester Berechtigungen für die Versionsprüfung, auto Aktualisierungsfunktionen und die Erfassung von Metriken.
**Berechtigungsdetails**
Diese Richtlinie umfasst die folgenden Berechtigungen:
+ `iot-device-tester:SupportedVersion`
Erteilt die AWS IoT Device Tester Berechtigung zum Abrufen der Liste der unterstützten Produkte, Testsuiten und IDT-Versionen.
+ `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 Testsuite-Updates.
+ `iot-device-tester:SendMetrics`
AWS Erteilt die Erlaubnis, Metriken zur AWS IoT Device Tester internen Nutzung zu sammeln.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/idt-*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "iot.amazonaws.com"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"iot:DeleteThing",
"iot:AttachThingPrincipal",
"iot:DeleteCertificate",
"iot:GetRegistrationCode",
"iot:CreatePolicy",
"iot:UpdateCACertificate",
"s3:ListBucket",
"iot:DescribeEndpoint",
"iot:CreateOTAUpdate",
"iot:CreateStream",
"signer:ListSigningJobs",
"acm:ListCertificates",
"iot:CreateKeysAndCertificate",
"iot:UpdateCertificate",
"iot:CreateCertificateFromCsr",
"iot:DetachThingPrincipal",
"iot:RegisterCACertificate",
"iot:CreateThing",
"iam:ListRoles",
"iot:RegisterCertificate",
"iot:DeleteCACertificate",
"signer:PutSigningProfile",
"s3:ListAllMyBuckets",
"signer:ListSigningPlatforms",
"iot-device-tester:SendMetrics",
"iot-device-tester:SupportedVersion",
"iot-device-tester:LatestIdt",
"iot-device-tester:CheckVersion",
"iot-device-tester:DownloadTestSuite"
],
"Resource": "*"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"signer:StartSigningJob",
"acm:GetCertificate",
"signer:DescribeSigningJob",
"s3:CreateBucket",
"execute-api:Invoke",
"s3:DeleteBucket",
"s3:PutBucketVersioning",
"signer:CancelSigningProfile"
],
"Resource": [
"arn:aws:execute-api:us-east-1:098862408343:9xpmnvs5h4/prod/POST/metrics",
"arn:aws:signer:*:*:/signing-profiles/*",
"arn:aws:signer:*:*:/signing-jobs/*",
"arn:aws:iam::*:role/idt-*",
"arn:aws:acm:*:*:certificate/*",
"arn:aws:s3:::idt-*",
"arn:aws:s3:::afr-ota*"
]
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"iot:DeleteStream",
"iot:DeleteCertificate",
"iot:AttachPolicy",
"iot:DetachPolicy",
"iot:DeletePolicy",
"s3:ListBucketVersions",
"iot:UpdateCertificate",
"iot:GetOTAUpdate",
"iot:DeleteOTAUpdate",
"iot:DescribeJobExecution"
],
"Resource": [
"arn:aws:s3:::afr-ota*",
"arn:aws:iot:*:*:thinggroup/idt*",
"arn:aws:iam::*:role/idt-*"
]
},
{
"Sid": "VisualEditor4",
"Effect": "Allow",
"Action": [
"iot:DeleteCertificate",
"iot:AttachPolicy",
"iot:DetachPolicy",
"s3:DeleteObjectVersion",
"iot:DeleteOTAUpdate",
"s3:PutObject",
"s3:GetObject",
"iot:DeleteStream",
"iot:DeletePolicy",
"s3:DeleteObject",
"iot:UpdateCertificate",
"iot:GetOTAUpdate",
"s3:GetObjectVersion",
"iot:DescribeJobExecution"
],
"Resource": [
"arn:aws:s3:::afr-ota*/*",
"arn:aws:s3:::idt-*/*",
"arn:aws:iot:*:*:policy/idt*",
"arn:aws:iam::*:role/idt-*",
"arn:aws:iot:*:*:otaupdate/idt*",
"arn:aws:iot:*:*:thing/idt*",
"arn:aws:iot:*:*:cert/*",
"arn:aws:iot:*:*:job/*",
"arn:aws:iot:*:*:stream/*"
]
},
{
"Sid": "VisualEditor5",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::afr-ota*/*",
"arn:aws:s3:::idt-*/*"
]
},
{
"Sid": "VisualEditor6",
"Effect": "Allow",
"Action": [
"iot:CancelJobExecution"
],
"Resource": [
"arn:aws:iot:*:*:job/*",
"arn:aws:iot:*:*:thing/idt*"
]
},
{
"Sid": "VisualEditor7",
"Effect": "Allow",
"Action": [
"ec2:TerminateInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor8",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:DeleteSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor9",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor10",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:image/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:placement-group/*",
"arn:aws:ec2:*:*:snapshot/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:subnet/*"
]
},
{
"Sid": "VisualEditor11",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Owner": "IoTDeviceTester"
}
}
},
{
"Sid": "VisualEditor12",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroups",
"ssm:DescribeParameters",
"ssm:GetParameters"
],
"Resource": "*"
},
{
"Sid": "VisualEditor13",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"Owner"
]
},
"StringEquals": {
"ec2:CreateAction": [
"RunInstances",
"CreateSecurityGroup"
]
}
}
}
]
}
```
------
## Aktualisierungen der AWS verwalteten Richtlinien
Sie können sich Details zu Aktualisierungen AWS verwalteter Richtlinien anzeigen lassen, die seit AWS IoT Device Tester dem Zeitpunkt gelten, zu dem dieser Dienst mit der Erfassung dieser Änderungen begonnen hat.
| Version | Änderungen | Beschreibung | Date |
| --- | --- | --- | --- |
| 7 (Aktuell) | Die `ec2:CreateTags` Bedingungen wurden neu strukturiert. | Die Verwendung von wird entfernt. `ForAnyValues` | 14.06.2023 |
| 6 | `freertos:ListHardwarePlatforms`Aus der Richtlinie entfernt. | Das Entfernen von Berechtigungen, da diese Aktion seit dem 1. März 2023 veraltet ist. | 02.06.2023 |
| 5 | Es wurden Berechtigungen zum Ausführen von Echo-Server-Tests mit EC2 hinzugefügt. | Dies dient zum Starten und Stoppen einer EC2-Instance in AWS Kundenkonten. | 15.12.2020 |
| 4 | `iot:CancelJobExecution` hinzugefügt. | Mit dieser Erlaubnis werden OTA-Jobs storniert. | 17.07.2020 |
| 3 | Die folgenden Berechtigungen wurden hinzugefügt: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/security-iam-aws-managed-policies.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/security-iam-aws-managed-policies.html) | 23.03.2020 |
| 2 | Berechtigungen hinzugefügt`iot-device-tester:SendMetrics`. | AWS Erteilt die Erlaubnis, Metriken zur AWS IoT Device Tester internen Nutzung zu sammeln. | 18.2.2020 |
| 1 | Erste Version | | 12.2.2020 |
# Machen Sie sich mit den Support-Richtlinien vertraut für AWS IoT Device Tester
**Wichtig**
Stand Oktober 2022 generiert AWS IoT FreeRTOS Qualification (FRQ) 1.0 keine signierten Qualifikationsberichte. AWS IoT Device Tester Sie können neue AWS IoT FreeRTOS-Geräte nicht für die Aufnahme in den [AWS Partnergerätekatalog über das AWS Gerätequalifizierungsprogramm](https://partners.amazonaws.com/qualified-devices) [qualifizieren](https://aws.amazon.com/partners/programs/dqp/), wenn Sie IDT FRQ 1.0-Versionen verwenden. Sie können FreeRTOS-Geräte zwar nicht mit IDT FRQ 1.0 qualifizieren, aber Sie können Ihre FreeRTOS-Geräte weiterhin mit FRQ 1.0 testen. [Wir empfehlen Ihnen, [IDT FRQ 2.0](https://docs.aws.amazon.com/freertos/latest/userguide/lts-idt-freertos-qualification.html) zu verwenden, um FreeRTOS-Geräte zu qualifizieren und im Partnergerätekatalog aufzulisten.AWS](https://partners.amazonaws.com/qualified-devices)
AWS IoT Device Tester for FreeRTOS ist ein Testautomatisierungstool zur Validierung des FreeRTOS-Ports zu Geräten. Darüber hinaus können Sie Ihre FreeRTOS-Geräte [qualifizieren](https://aws.amazon.com/partners/programs/dqp/) und sie im [AWS Partner-Gerätekatalog](https://partners.amazonaws.com/qualified-devices) auflisten. [Das AWS IoT Device Tester for FreeRTOS unterstützt die Validierung und Qualifizierung von FreeRTOS Long Term Supported (LTS) -Bibliotheken, die unter FreeRTOS/FreeRTOS-LTS verfügbar sind, und der FreeRTOS-Hauptlinie, die GitHub unter [FreeRTOS/FreeRTOS](https://github.com/FreeRTOS/FreeRTOS-LTS) verfügbar ist.](https://github.com/FreeRTOS/FreeRTOS) Wir empfehlen Ihnen, die neuesten Versionen sowohl von FreeRTOS als auch von FreeRTOS zu verwenden, um Ihre AWS IoT Device Tester Geräte zu validieren und zu qualifizieren.
Für FreeRTOS-LTS unterstützt IDT die Validierung und Qualifizierung der FreeRTOS 202210 LTS-Version. Weitere Informationen zu [FreeRTOS LTS-Versionen](https://www.freertos.org/lts-libraries.html) und deren Wartungszeitplan finden Sie hier. Sobald der Supportzeitraum für diese LTS-Versionen abgelaufen ist, können Sie die Validierung weiterhin fortsetzen. IDT erstellt jedoch keinen Bericht, anhand dessen Sie Ihr Gerät zur Qualifizierung einreichen können.
Für die Mainline-FreeRTOS, die unter [FreeRTOS/FreeRTOS verfügbar sind, unterstützen wir die Validierung und Qualifizierung aller Versionen, die in den letzten sechs Monaten veröffentlicht wurden, oder der vorherigen beiden Versionen von FreeRTOS](https://github.com/FreeRTOS/FreeRTOS), wenn sie im Abstand von mehr als sechs Monaten veröffentlicht wurden. [Informationen zu den derzeit unterstützten Versionen finden Sie hier.]( https://docs.aws.amazon.com//freertos/latest/userguide/dev-test-versions-afr.html) Für nicht unterstützte Versionen von FreeRTOS können Sie die Validierung trotzdem fortsetzen, IDT generiert jedoch keinen Bericht, mit dem Sie Ihr Gerät zur Qualifizierung einreichen können.
Die neuesten unterstützten IDT- und FreeRTOS-Versionen finden [Unterstützte Versionen von AWS IoT Device Tester](dev-test-versions-afr.md) Sie unter. Sie können jede der unterstützten Versionen von AWS IoT Device Tester mit der entsprechenden Version von FreeRTOS verwenden, um Ihr Gerät zu testen oder zu qualifizieren. Wenn Sie das weiterhin verwenden[Nicht unterstützte IDT-Versionen für FreeRTOS](idt-unsupported-versions-afr.md), erhalten Sie nicht die neuesten Bugfixes oder Updates.
Bei Fragen zu den Support-Richtlinien wenden Sie sich an [AWS den Kundensupport](https://aws.amazon.com/contact-us/).