Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Konfigurieren Sie Einstellungen für Testläufer - Kostenlos RTOS

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.

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.

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 <device-tester-extract-location>/configs/ Ordner befinden. Falls erforderlich, müssen Testläufer auch AWS Anmeldeinformationen einrichten, die für die Verbindung mit der AWS Cloud verwendet IDT werden.

Als Testautor müssen Sie diese Dateien konfigurieren, um Ihre Testsuite zu debuggen. 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 Architektur). CPU

Testläufer können diese Informationen mithilfe der folgenden device.json Vorlagendatei bereitstellen, die sich im <device-tester-extract-location>/configs/ Ordner befindet.

[ { "id": "<pool-id>", "sku": "<pool-sku>", "features": [ { "name": "<feature-name>", "value": "<feature-value>", "configs": [ { "name": "<config-name>", "value": "<config-value>" } ], } ], "devices": [ { "id": "<device-id>", "pairedResource": "<device-id>", //used for no-op protocol "connectivity": { "protocol": "ssh | uart | docker | no-op", // ssh "ip": "<ip-address>", "port": <port-number>, "publicKeyPath": "<public-key-path>", "auth": { "method": "pki | password", "credentials": { "user": "<user-name>", // pki "privKeyPath": "/path/to/private/key", // password "password": "<password>", } }, // uart "serialPort": "<serial-port>", // docker "containerId": "<container-id>", "containerUser": "<container-user-name>", } } ] } ]

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 zu verfolgen.

Anmerkung

Wenn Sie Ihr Motherboard im Gerätekatalog für AWS Partner auflisten möchten, muss das, was SKU Sie hier angeben, mit dem Gerät übereinstimmenSKU, das Sie bei der Angebotserstellung verwendet haben.

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 eine Funktion mit dem Namen überprüft werdenMQTT_QoS. 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 aus dem IDTKontext mit der devicePool.features Abfrage oder aus dem Zustandsmaschinenkontext mit der pool.features Abfrage abrufen.

features.name

Der Name der Funktion.

features.value

Die unterstützten Feature-Werte.

features.configs

Konfigurationseinstellungen für die Funktion, falls erforderlich.

features.config.name

Der Name der Konfigurationseinstellung.

features.config.value

Die unterstützten Einstellungswerte.

devices

Eine Reihe von Geräten im Pool, die getestet werden sollen. Es ist mindestens ein Gerät erforderlich.

devices.id

Eine benutzerdefinierte eindeutige Kennung für das zu testende Gerät.

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 Host-Computer haben, aber ein Ressourcengerät als physische Middleware für die Kommunikation mit dem Host-Computer benötigen.

Für Geräte ohne Betriebsbereitschaft konfigurieren Sie die Geräte-ID der Ressource 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 das gekoppelte Ressourcengerät IDT identifiziert und eine Verbindung hergestellt wurde, IDT wird gemäß den in der test.json Datei beschriebenen Funktionen keine Verbindung zu anderen Ressourcengeräten hergestellt.

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 den angebenpublicKeyPath, wird der öffentliche Schlüssel des Geräts IDT validiert, wenn eine SSH Verbindung zu dem zu testenden Gerät hergestellt wird. Wenn dieser Wert nicht angegeben ist, wird IDT eine SSH Verbindung hergestellt, der öffentliche Schlüssel des Geräts wird jedoch nicht validiert.

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 SSH Standard-Clients, die auf der Befehlszeile basieren, ist der öffentliche Schlüssel in der known_hosts Datei enthalten. 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.

Anmerkung

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 ihn mit dem erwarteten Wert in einem Choice Status vergleichen. Wenn ein falsches Protokoll verwendet wird, drucken Sie eine Nachricht mit dem LogMessage Status und wechseln Sie zum Fail Status.

Alternativ können Sie den Fehlerbehandlungscode verwenden, um einen Testfehler für falsche Gerätetypen zu melden.

(Optional) Konfigurieren Sie userdata.json

Die userdata.json Datei enthält alle zusätzlichen Informationen, die für eine Testsuite erforderlich sind, aber nicht in der Datei angegeben sind. device.json Das Format dieser Datei hängt von der userdata_scheme.jsonDatei 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, 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 <device-tester-extract-location>/configs/ Ordner befindet.

[ { "id": "<pool-id>", "features": [ { "name": "<feature-name>", "version": "<feature-value>", "jobSlots": <job-slots> } ], "devices": [ { "id": "<device-id>", "connectivity": { "protocol": "ssh | uart | docker", // ssh "ip": "<ip-address>", "port": <port-number>, "publicKeyPath": "<public-key-path>", "auth": { "method": "pki | password", "credentials": { "user": "<user-name>", // pki "privKeyPath": "/path/to/private/key", // password "password": "<password>", } }, // uart "serialPort": "<serial-port>", // docker "containerId": "<container-id>", "containerUser": "<container-user-name>", } } ] } ]

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 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 den angebenpublicKeyPath, wird der öffentliche Schlüssel des Geräts IDT validiert, wenn eine SSH Verbindung zu dem zu testenden Gerät hergestellt wird. Wenn dieser Wert nicht angegeben ist, wird IDT eine SSH Verbindung hergestellt, der öffentliche Schlüssel des Geräts wird jedoch nicht validiert.

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 SSH Standard-Clients, die auf der Befehlszeile basieren, ist der öffentliche Schlüssel in der known_hosts Datei enthalten. 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ürIDT. In der Regel müssen Testläufer diese Datei nicht ändern, es sei dennIDT, sie geben ihre AWS Benutzeranmeldeinformationen für eine Region und optional eine AWS Region an. Wenn AWS Anmeldeinformationen mit den erforderlichen Berechtigungen bereitgestellt werden, werden Nutzungsdaten AWS IoT Device Tester erfasst und an diese AWS gesendet. Dies ist eine Opt-in-Funktion, die zur Verbesserung IDT der Funktionalität verwendet wird. Weitere Informationen finden Sie unter IDTNutzungsmetriken einreichen.

Testläufer können ihre AWS Anmeldeinformationen auf eine der folgenden Arten konfigurieren:

  • Anmeldeinformationsdatei

    IDTverwendet dieselbe Anmeldeinformationsdatei wie der AWS CLI. Weitere Informationen finden Sie unter Konfigurations- und Anmeldeinformationsdateien.

    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 der Sitzung nicht verfügbar. IDTkann die AWS_SECRET_ACCESS_KEY Umgebungsvariablen AWS_ACCESS_KEY_ID und zum Speichern von AWS Anmeldeinformationen verwenden

    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>

Um die AWS Anmeldeinformationen für zu konfigurierenIDT, bearbeiten Testläufer den auth Abschnitt in der config.json Datei, die sich im <device-tester-extract-location>/configs/ Ordner befindet.

{ "log": { "location": "logs" }, "configFiles": { "root": "configs", "device": "configs/device.json" }, "testPath": "tests", "reportPath": "results", "awsRegion": "<region>", "auth": { "method": "file | environment", "credentials": { "profile": "<profile-name>" } } } ]

Nachfolgend sind alle Pflichtfelder beschrieben:

Anmerkung

Alle Pfade in dieser Datei sind relativ zu dem definiert <device-tester-extract-location>.

log.location

Der Pfad zum Logs-Ordner im <device-tester-extract-location>.

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 die Testergebnisse nach der IDT Ausführung einer Testsuite enthält.

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 dient IDT zum Abrufen von AWS Anmeldeinformationen. 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.

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.