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.
# Device Advisor
[Device Advisor](https://aws.amazon.com/iot-core/features/) ist eine cloudbasierte, vollständig verwaltete Testfunktion zur Validierung von IoT-Geräten während der Entwicklung von Gerätesoftware. Device Advisor bietet vorgefertigte Tests, mit denen Sie IoT-Geräte auf zuverlässige und sichere Konnektivität überprüfen können AWS IoT Core, bevor Sie Geräte in der Produktion einsetzen. Die vorgefertigten Tests von Device Advisor helfen Ihnen dabei, Ihre Gerätesoftware anhand von Best Practices für die Verwendung von [TLS](https://docs.aws.amazon.com//iot/latest/developerguide/protocols.html)-, [MQTT](https://docs.aws.amazon.com//iot/latest/developerguide/protocols.html)-, [Device Shadow](https://docs.aws.amazon.com//iot/latest/developerguide/iot-device-shadows.html)- und [IoT](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html)-Aufträgen zu validieren. Sie können auch signierte Qualifikationsberichte herunterladen, um sie an das AWS -Partnernetzwerk zu senden, damit Ihr Gerät für den [AWS -Partnergerätekatalog](https://devices.amazonaws.com/) qualifiziert wird, ohne dass Sie Ihr Gerät einschicken und warten müssen, bis es getestet wird.
**Anmerkung**
Device Advisor wird in den Regionen us-east-1, us-west-2, ap-northeast-1 und eu-west-1 unterstützt.
Device Advisor unterstützt Geräte und Clients, die die Protokolle MQTT und MQTT over WebSocket Secure (WSS) verwenden, um Nachrichten zu veröffentlichen und zu abonnieren. Alle Protokolle unterstützen IPv4 und. IPv6
Device Advisor unterstützt RSA-Serverzertifikate.
Jedes Gerät, mit dem eine Verbindung hergestellt wurde, AWS IoT Core kann Device Advisor nutzen. Sie können über die [AWS IoT Konsole](https://us-east-1.console.aws.amazon.com/iot/home?region=us-east-1#/deviceadvisor/intro) oder mithilfe des AWS CLI oder SDK auf Device Advisor zugreifen. Wenn Sie bereit sind, Ihr Gerät zu testen, registrieren Sie es AWS IoT Core und konfigurieren Sie die Gerätesoftware mit dem Device Advisor-Endpunkt. Wählen Sie dann die vorgefertigten Tests aus, konfigurieren Sie sie und führen Sie die Tests auf Ihrem Gerät aus. Sie erhalten dann die Testergebnisse zusammen mit detaillierten Protokollen oder einem Qualifizierungsbericht.
Device Advisor ist ein Testendpunkt in der AWS Cloud. Sie können Ihre Geräte testen, indem Sie sie so konfigurieren, dass sie eine Verbindung zu dem vom Device Advisor bereitgestellten Testendpunkt herstellen. Nachdem ein Gerät für die Verbindung mit dem Testendpunkt konfiguriert wurde, können Sie die Device Advisor-Konsole aufrufen oder das AWS SDK verwenden, um die Tests auszuwählen, die Sie auf Ihren Geräten ausführen möchten. Device Advisor verwaltet dann den gesamten Lebenszyklus eines Tests, einschließlich der Bereitstellung von Ressourcen, der Planung des Testprozesses, der Verwaltung des Zustandsautomats, der Aufzeichnung des Geräteverhaltens, der Protokollierung der Ergebnisse und der Bereitstellung der Endergebnisse in Form eines Testberichts.
**TLS-Protokolle**
Das TLS-Protokoll (Transport Layer Security) wird für die Verschlüsselung vertraulicher Daten über unsichere Netzwerke wie das Internet verwendet. Das TLS-Protokoll ist der Nachfolger des SSL-Protokolls (Secure Sockets Layer).
Device Advisor unterstützt die folgenden TLS-Protokolle:
+ TLS 1.3 (empfohlen)
+ TLS 1.2
**Protokolle, Port-Zuweisungen und Authentifizierung**
Das Gerätekommunikationsprotokoll wird von einem Gerät oder einem Client verwendet, um über einen Geräteendpunkt eine Verbindung zum Message Broker herzustellen. In der folgenden Tabelle sind die Protokolle aufgeführt, die von den Device-Advisor-Endpunkten unterstützt werden, sowie die verwendeten Authentifizierungsmethoden und Ports.
**Protokolle, Authentifizierung und Port-Zuweisungen**
| Protocol (Protokoll) | Unterstützte Operationen | Authentifizierung | Port | ALPN-Protokollname |
| --- | --- | --- | --- | --- |
| MQTT über WebSocket | Veröffentlichen, Abonnieren | Signaturversion 4 | 443 | – |
| MQTT | Veröffentlichen, Abonnieren | X.509-Clientzertifikat | 8883 | `x-amzn-mqtt-ca` |
| MQTT | Veröffentlichen, Abonnieren | X.509-Clientzertifikat | 443 | – |
**Topics**
+ [Einrichtung](device-advisor-setting-up.md)
+ [Erste Schritte mit Device Advisor in der Konsole](da-console-guide.md)
+ [Device-Advisor-Workflow](device-advisor-workflow.md)
+ [Ausführlicher Konsolen-Workflow von Device Advisor](device-advisor-console-tutorial.md)
+ [Konsolen-Workflow für Tests mit langer Dauer](device-advisor-long-duration-console-tutorial.md)
+ [Device-Advisor-VPC-Endpunkte (AWS PrivateLink)](device-advisor-vpc-endpoint.md)
+ [Device-Advisor-Testfälle](device-advisor-tests.md)
# Einrichtung
Führen Sie die folgenden Schritte aus, bevor Sie Device Advisor zum ersten Mal verwenden:
## Erstellen eines IoT-Dings
Erstellen Sie zunächst ein IoT-Ding und fügen Sie diesem Ding ein Zertifikat hinzu. Ein Tutorial zum Erstellen von Dingen finden Sie unter [Create a thing object](https://docs.aws.amazon.com/iot/latest/developerguide/create-iot-resources.html#create-aws-thing) (Erstellen eines Dingobjekts).
## Erstellen einer IAM-Rolle, die Sie als Ihre Geräterolle verwenden möchten
**Anmerkung**
Sie können die Geräterolle mit der Device-Advisor-Konsole schnell erstellen. Informationen zum Einrichten Ihrer Geräterolle mit der Device-Advisor-Konsole finden Sie unter [Getting started with the Device Advisor in the console](https://docs.aws.amazon.com/iot/latest/developerguide/da-console-guide.html).
1. Gehen Sie zur [AWS Identity and Access Management Konsole](https://console.aws.amazon.com/iam/home?region=us-west-2#/home) und melden Sie sich bei dem an, den AWS-Konto Sie für Device Advisor-Tests verwenden.
1. Wählen Sie im linken Navigationsbereich die Option **Richtlinien** aus.
1. Wählen Sie **Richtlinie erstellen** aus.
1. Gehen Sie unter **Richtlinie erstellen** wie folgt vor:
1. Wählen Sie unter **Service** die Option **IoT** aus.
1. Führen Sie unter **Aktionen** eine der folgenden Aktionen aus.
+ (Empfohlen) Wählen Sie Aktionen auf der Grundlage der Richtlinie aus, die dem IoT-Ding oder dem IoT-Zertifikat zugeordnet ist, das Sie im vorherigen Abschnitt erstellt haben.
+ Suchen Sie im Feld **Filteraktion** nach den folgenden Aktionen und wählen Sie sie aus:
+ `Connect`
+ `Publish`
+ `Subscribe`
+ `Receive`
+ `RetainPublish`
1. Schränken Sie unter **Ressourcen** die Ressourcen für Client und Thema ein. Die Einschränkung dieser Ressourcen ist eine bewährte Sicherheitsmethode. Gehen Sie wie folgt vor, um Ressourcen einzuschränken:
1. Wählen Sie **Specify client resource ARN for the Connect action** (Client-Ressourcen-ARN für die Connect-Aktion angeben) aus.
1. Wählen Sie **ARN hinzufügen** aus und führen Sie dann einen der folgenden Schritte aus:
**Anmerkung**
Die *clientId* ist die MQTT-Client-ID, die Ihr Gerät für die Interaktion mit Device Advisor verwendet.
+ Geben Sie die **Region**, die **accountID** und die **clientID** im visuellen ARN-Editor an.
+ Geben Sie manuell die Amazon-Ressourcennamen (ARNs) der IoT-Themen ein, mit denen Sie Ihre Testfälle ausführen möchten.
1. Wählen Sie **Hinzufügen** aus.
1. Wählen **Specify topic resource ARN for the Receive and one more action** (ARN der Themenressource für den Receive und eine weitere Aktion angeben) aus.
1. Wählen Sie **ARN hinzufügen** aus und führen Sie dann einen der folgenden Schritte aus:
**Anmerkung**
Der *Themenname* ist das MQTT-Thema, zu dem Ihr Gerät Nachrichten veröffentlicht.
+ Geben Sie die **Region**, die **accountID** und den **Themennamen** im visuellen ARN-Editor an.
+ Geben Sie manuell ARNs die IoT-Themen ein, mit denen Sie Ihre Testfälle ausführen möchten.
1. Wählen Sie **Hinzufügen** aus.
1. Wählen Sie **Specify topicFilter resource ARN for the Subscribe action** (ARN der topicFilter-Ressource für die Subscribe-Aktion angeben) aus.
1. Wählen Sie **ARN hinzufügen** aus und führen Sie dann einen der folgenden Schritte aus:
**Anmerkung**
Der *Themenname* ist das MQTT-Thema, das Ihr Gerät abonniert.
+ Geben Sie die **Region**, die **accountID** und den **Themennamen** im visuellen ARN-Editor an.
+ Geben Sie manuell ARNs die IoT-Themen ein, mit denen Sie Ihre Testfälle ausführen möchten.
1. Wählen Sie **Hinzufügen** aus.
1. Wählen Sie **Next: Tags** (Weiter: Tags) aus.
1. Klicken Sie auf **Weiter: Prüfen**.
1. Geben Sie unter **Richtlinie überprüfen** einen **Namen** für Ihre Richtlinie ein.
1. Wählen Sie **Richtlinie erstellen** aus.
1. Wählen Sie im linken Navigationsbereich **Rollen** aus.
1. Wählen Sie **Rolle erstellen** aus.
1. Wählen Sie unter **Vertrauenswürdige Entitäten auswählen** die Option **Benutzerdefinierte Vertrauensrichtlinie** aus.
1. Geben Sie die folgende Vertrauensrichtlinie in das Feld **Benutzerdefinierte Vertrauensrichtlinie** ein. Verwenden Sie die globalen Konditionsschlüssel `[aws:SourceArn](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` und `[aws:SourceAccount](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` für die Richtlinie, um vor dem Confused-Deputy-Problem zu schützen.
**Wichtig**
Ihr `aws:SourceArn` muss mit dem `format: arn:aws:iotdeviceadvisor:region:account-id:*.` konform sein. Stellen Sie sicher, dass `region` Ihrer AWS IoT -Region entspricht und dass `account-id` Ihrer Kundenkonto-ID entspricht. Weitere Informationen finden Sie unter [Vermeidung des dienstübergreifenden Confused-Deputy-Problems](https://docs.aws.amazon.com/iot/latest/developerguide/security-best-practices.html#cross-service-confused-deputy-prevention-DA).
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAwsIoTCoreDeviceAdvisor",
"Effect": "Allow",
"Principal": {
"Service": "iotdeviceadvisor.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:iotdeviceadvisor:*:123456789012:suitedefinition/*"
}
}
}
]
}
```
1. Wählen Sie **Weiter** aus.
1. Wählen Sie die Richtlinie aus, den Sie in Schritt 4 erstellt haben.
1. (Optional) Wählen Sie unter **Berechtigungsgrenze festlegen** die Option **Use a permissions boundary to control the maximum role permissions** (Eine Berechtigungsgrenze verwenden, um die maximalen Rollenberechtigungen zu kontrollieren) aus und dann die Richtlinie, die Sie erstellt haben.
1. Wählen Sie **Weiter** aus.
1. Geben Sie einen **Rollennamen** und eine **Rollenbeschreibung** an.
1. Wählen Sie **Rolle erstellen** aus.
## Erstellen einer individuell verwalteten Richtlinie für einen IAM-Benutzer zur Verwendung von Device Advisor
1. Navigieren Sie zur IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). Geben Sie bei Aufforderung Ihre AWS -Anmeldeinformationen ein.
1. Wählen Sie im linken Navigationsbereich **Richtlinien** aus.
1. Wählen Sie **Richtlinie erstellen** und anschließend die Registerkarte **JSON** aus.
1. Fügen Sie die erforderlichen Berechtigungen hinzu, um Device Advisor zu verwenden. Das Richtliniendokument finden Sie im Thema [Bewährte Methoden für die Sicherheit](https://docs.aws.amazon.com/iot/latest/developerguide/security-best-practices.html#device-advisor-perms).
1. Wählen Sie **Review policy** (Richtlinie überprüfen) aus.
1. Geben Sie **Name (Name)** und **Description (Beschreibung)** ein.
1. Wählen Sie **Richtlinie erstellen** aus.
## Erstellen eines IAM-Benutzers für die Verwendung von Device Advisor
**Anmerkung**
Wir empfehlen, einen IAM-Benutzer für die Ausführung von Device-Advisor-Tests zu erstellen. Das Ausführen von Device-Advisor-Tests als Administratorbenutzer kann Sicherheitsrisiken bergen und wird nicht empfohlen.
1. Navigieren Sie zur IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)Wenn Sie dazu aufgefordert werden, geben Sie Ihre AWS Anmeldedaten ein, um sich anzumelden.
1. Wählen Sie im linken Navigationsbereich **Benutzer** aus.
1. Wählen Sie **Benutzer hinzufügen**.
1. Geben Sie einen **Benutzernamen** ein.
1. Benutzer benötigen programmgesteuerten Zugriff, wenn sie mit AWS außerhalb des interagieren möchten. AWS-Managementkonsole Die Art und Weise, wie programmatischer Zugriff gewährt wird, hängt vom Benutzertyp ab, der zugreift. AWS
Um Benutzern programmgesteuerten Zugriff zu gewähren, wählen Sie eine der folgenden Optionen.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/device-advisor-setting-up.html)
1. Wählen Sie **Weiter: Berechtigungen** aus.
1. 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*.
1. Geben Sie in das Suchfeld den Namen der individuell verwalteten Richtlinie ein, die Sie erstellt haben. Aktivieren Sie dann das Kontrollkästchen für **Richtliniennamen**.
1. Wählen Sie **Next: Tags** (Weiter: Tags) aus.
1. Klicken Sie auf **Next: Review** (Weiter: Prüfen).
1. Wählen Sie **Create user** aus.
1. Klicken Sie auf **Schließen**.
Device Advisor benötigt in Ihrem Namen Zugriff auf Ihre AWS Ressourcen (Dinge, Zertifikate und Endpunkte). Ihr IAM-Benutzer muss über die nötigen Berechtigungen verfügen. Device Advisor veröffentlicht auch Protokolle auf Amazon, CloudWatch wenn Sie Ihrem IAM-Benutzer die erforderlichen Berechtigungsrichtlinien zuordnen.
## Konfigurieren Ihres Geräts
Device Advisor nutzt die TLS-Erweiterung für die Servernamenindikation (SNI), um TLS-Konfigurationen anzuwenden. Geräte müssen diese Erweiterung verwenden, wenn sie eine Verbindung herstellen und einen Servernamen übergeben, der mit dem Device-Advisor-Testendpunkt identisch ist.
Device Advisor ermöglicht die TLS-Verbindung, wenn sich ein Test im `Running`-Status befindet. Es verweigert die TLS-Verbindung vor und nach jedem Testlauf. Aus diesem Grund empfehlen wir, den Mechanismus zur Wiederholung der Geräteverbindung zu verwenden, um ein vollautomatisches Testerlebnis mit Device Advisor zu gewährleisten. Sie können Testsuiten ausführen, die mehr als einen Testfall enthalten, z. B. TLS Connect, MQTT Connect und MQTT Publish. Wenn Sie mehrere Testfälle ausführen, empfehlen wir, dass Ihr Gerät versucht, alle fünf Sekunden eine Verbindung zu unserem Testendpunkt herzustellen. Sie können dann die Ausführung mehrerer Testfälle nacheinander automatisieren.
**Anmerkung**
Um Ihre Gerätesoftware für das Testen vorzubereiten, empfehlen wir Ihnen, ein SDK zu verwenden, das eine Verbindung zu AWS IoT Core herstellen kann. Anschließend sollten Sie das SDK mit dem Device-Advisor-Testendpunkt aktualisieren, der für Ihr AWS-Konto bereitgestellt wurde.
Device Advisor unterstützt zwei Arten von Endpunkten: Endpunkte auf Kontoebene und Endpunkte auf Geräteebene. Wählen Sie den Endpunkt aus, der Ihrem Anwendungsfall am besten entspricht. Um mehrere Testsuiten für verschiedene Geräte gleichzeitig auszuführen, verwenden Sie einen Endpunkt auf Geräteebene.
Führen Sie den folgenden Befehl aus, um den Endpunkt auf Geräteebene abzurufen:
Für MQTT-Kunden, die X.509-Client-Zertifikate verwenden:
```
aws iotdeviceadvisor get-endpoint --thing-arn your-thing-arn
```
oder
```
aws iotdeviceadvisor get-endpoint --certificate-arn your-certificate-arn
```
Für WebSocket MQTT-Kunden, die Signature Version 4 verwenden:
```
aws iotdeviceadvisor get-endpoint --device-role-arn your-device-role-arn --authentication-method SignatureVersion4
```
Um jeweils eine Testsuite auszuführen, wählen Sie einen Endpunkt auf Kontoebene. Führen Sie den folgenden Befehl aus, um den Endpunkt auf Kontoebene abzurufen:
```
aws iotdeviceadvisor get-endpoint
```
# Erste Schritte mit Device Advisor in der Konsole
Dieses Tutorial hilft Ihnen bei den ersten Schritten AWS IoT Core Device Advisor auf der Konsole. Device Advisor bietet Features wie erforderliche Tests und signierte Qualifikationsberichte. Sie können diese Tests und Berichte verwenden, um Geräte zu qualifizieren und im [-Partner-Gerätekatalog](https://devices.amazonaws.com/) aufzulisten, wie im [AWS IoT Core -Qualifizierungsprogramm](https://aws.amazon.com/partners/dqp/) beschrieben.
Weitere Informationen zum Verwenden von Device Advisor finden Sie unter [Device-Advisor-Workflow](device-advisor-workflow.md) und [Ausführlicher Konsolen-Workflow von Device Advisor](device-advisor-console-tutorial.md).
Führen Sie die Schritte in [Einrichtung](device-advisor-setting-up.md) aus, um dieses Tutorial abzuschließen.
**Anmerkung**
Device Advisor wird in den folgenden Bereichen unterstützt AWS-Regionen:
USA Ost (Nord-Virginia)
USA West (Oregon)
Asien-Pazifik (Tokio)
Europa (Irland)
**Erste Schritte**
1. Wählen Sie im Navigationsbereich der [AWS IoT -Konsole](https://console.aws.amazon.com//iot) unter **Test** die Option **Device Advisor** aus. Wählen Sie dann auf der Konsole die Schaltfläche **Walkthrough starten** aus.
![\[Device Advisor ist eine vollständig verwaltete Testfunktion für IoT-Geräte, um die sichere Interaktion mit IoT-Geräten zu validieren AWS IoT Core, Softwareprobleme zu identifizieren und Testergebnisse zu erhalten.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-gs.png)
1. Die Seite **Erste Schritte mit Device Advisor** bietet einen Überblick über die Schritte, die zum Erstellen einer Testsuite und zum Ausführen von Tests auf Ihrem Gerät erforderlich sind. Den Device-Advisor-Testendpunkt für Ihr Konto finden Sie auch hier. Sie müssen die Firmware oder Software auf dem zum Testen verwendeten Gerät konfigurieren, um eine Verbindung zu diesem Testendpunkt herzustellen.
Um dieses Tutorial abzuschließen, müssen [Sie zunächst eine Sache und ein Zertifikat erstellen](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-create-thing-certificate). Nachdem Sie sich die Informationen unter **Funktionsweise** gelesen haben, wählen Sie **Weiter** aus.
![\[Schritte zum Testen der Konnektivität von IoT-Geräten: Protokoll auswählen, Testsuite erstellen, Geräteeinstellungen konfigurieren.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-gs1.png)
1. Wählen Sie in **Schritt 1: Protokoll auswählen** ein Protokoll aus den aufgelisteten Optionen aus. Wählen Sie anschließend **Weiter**.
![\[Device Advisor-Schnittstelle mit Optionen zur Auswahl eines Kommunikationsprotokolls (MQTT 3.1.1, MQTT 3.1.1 über, MQTT 5 WebSocket, MQTT 5 over WebSocket) zum Testen eines IoT-Geräts.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-protocol.png)
1. In **Schritt 2** erstellen und konfigurieren Sie eine benutzerdefinierte Testsuite. Eine benutzerdefinierte Testsuite muss mindestens eine Testgruppe haben und jede Testgruppe muss mindestens einen Testfall haben. Wir haben den **MQTT-Connect**-Testfall hinzugefügt, damit Sie erste Schritte unternehmen können.
Wählen Sie **Eigenschaften der Testsuite** aus.
![\[Der Bildschirm „Testsuite erstellen“ in Device Advisors, auf dem Benutzer Testgruppen und Fälle zum Testen von IoT-Geräten mit dem MQTT-Protokoll erstellen und konfigurieren können.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-test-suite-create.png)
Geben Sie die Eigenschaften der Testsuite an, wenn Sie Ihre Testsuite erstellen. Sie können die folgenden Eigenschaften auf Suite-Ebene konfigurieren:
+ **Name der Testsuite**: Geben Sie einen Namen für Ihre Testsuite ein.
+ **Timeout** (optional): Das Timeout (in Sekunden) für jeden Testfall in der aktuellen Testsuite. Wenn Sie keinen Timeout-Wert angeben, wird der Standardwert verwendet.
+ **Tags** (optional): Fügen Sie der Testsuite Tags hinzu.
Wenn Sie fertig sind, wählen Sie **Eigenschaften aktualisieren** aus.
![\[Formular zum Aktualisieren der Eigenschaften einer Testsuite, einschließlich Name, Timeout und Fähigkeit, Tags hinzuzufügen. Enthält eine Schaltfläche „Eigenschaften aktualisieren“.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-test-suite-properties.png)
1. (Optional) Um die Konfiguration der Testsuite-Gruppe zu aktualisieren, klicken Sie auf die Schaltfläche **Bearbeiten** neben dem Namen der Testgruppe.
+ **Name**: Geben Sie einen Namen für die Testsuite-Gruppe ein.
+ **Timeout** (optional): Das Timeout (in Sekunden) für jeden Testfall in der aktuellen Testsuite. Wenn Sie keinen Timeout-Wert angeben, wird der Standardwert verwendet.
Wenn Sie fertig sind, wählen Sie **Fertig** aus, um fortzufahren.
![\[Eine Testgruppe mit dem Namen „Testgruppe 1" wird mit Optionen zum Konfigurieren des Timeouts und zum Hinzufügen weiterer Testgruppen angezeigt.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-test-suite-config.png)
1. (Optional) Um die Testfall-Konfiguration für einen Testfall zu aktualisieren, klicken Sie auf die Schaltfläche **Bearbeiten** neben dem Namen der Testgruppe.
+ **Name**: Geben Sie einen Namen für die Testsuite-Gruppe ein.
+ **Timeout** (optional): Das Timeout (in Sekunden) für den ausgewählten Testfall. Wenn Sie keinen Timeout-Wert angeben, wird der Standardwert verwendet.
Wenn Sie fertig sind, wählen Sie **Fertig** aus, um fortzufahren.
![\[Die Oberfläche „Testsuite erstellen“, die Optionen zur Konfiguration einer Testsuite, Testgruppen und einzelner Testfälle zum Testen von IoT-Geräten zeigt.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-test-case-config.png)
1. (Optional) Um der Testsuite weitere Testgruppen hinzuzufügen, wählen Sie **Add test group** (Testgruppe hinzufügen) aus und folgen Sie dann den Anweisungen in Schritt 5.
1. (Optional) Um weitere Testfälle hinzuzufügen, ziehen Sie die Testfälle im Abschnitt **Testfälle** in eine Ihrer Testgruppen.
![\[Die Schnittstelle „Testsuite erstellen“, über die Benutzer Testgruppen und Testfälle für das Testen des MQTT-Protokolls von IoT-Geräten konfigurieren können.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-drag.png)
1. Sie können die Reihenfolge Ihrer Testgruppen und Testfälle ändern. Ziehen Sie die aufgelisteten Testfälle in der Liste nach oben oder unten, um Änderungen vorzunehmen. Device Advisor führt Tests in der Reihenfolge aus, in der Sie sie aufgelistet haben.
Nachdem Sie Ihre Testsuite konfiguriert haben, wählen Sie **Weiter** aus.
1. Wählen Sie in **Schritt 3** eine AWS IoT Sache oder ein Zertifikat aus, das mit Device Advisor getestet werden soll. Wenn Sie noch keine Dinge oder Zertifikate haben, finden Sie weitere Informationen unter [Einrichten](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html).
![\[Die Konfigurationsoptionen umfassen die Auswahl eines Protokolls, die Erstellung einer Testsuite, die Konfiguration von Geräteeinstellungen und die Überprüfung von Testläufen und Ergebnissen.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-device-settings.png)
1. Sie können eine Geräterolle konfigurieren, die Device Advisor verwendet, um AWS IoT MQTT-Aktionen im Namen Ihres Testgeräts auszuführen. Die **Connect**-Aktion wird nur für den **MQTT-Connect**-Testfall automatisch ausgewählt. Dies liegt daran, dass die Geräterolle diese Berechtigung benötigt, um die Testsuite auszuführen. Für andere Testfälle werden die entsprechenden Aktionen ausgewählt.
Geben Sie die Ressourcenwerte für jede der ausgewählten Aktionen an. Geben Sie beispielsweise für die **Connect**-Aktion die Client-ID an, die Ihr Gerät für die Verbindung mit dem Device-Advisor-Endpunkt verwendet. Sie können mehrere Werte mit durch Kommas getrennten Werten und Präfixwerte mit einem Platzhalterzeichen (\$1) angeben. Um beispielsweise die Erlaubnis zur Veröffentlichung zu einem beliebigen Thema zu erteilen, das mit `MyTopic` beginnt, geben Sie **MyTopic\$1** als Ressourcenwert ein.
![\[Die Device Advisor-Oberfläche, in der Sie eine Geräterolle auswählen und Berechtigungen für das Verbinden, Veröffentlichen, Abonnieren und Verwalten von MQTT-Themen und -Clients definieren können. IDs\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-device-role.png)
Um eine zuvor erstellte Geräterolle aus [Einrichten](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html) zu verwenden, wählen Sie **Vorhandene Rolle auswählen** aus. Wählen Sie dann unter **Rolle auswählen** Ihre Geräterolle aus.
![\[Eine Webformularschnittstelle zur Auswahl einer Geräterolle mit Optionen zum Erstellen einer neuen Rolle oder zum Auswählen einer vorhandenen Rolle mit dem Namen "“DeviceAdvisorServiceRole.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-select-device-role.png)
Konfigurieren Sie Ihre Geräterolle mit einer der beiden verfügbaren Optionen und wählen Sie dann **Weiter** aus.
1. Wählen Sie im Abschnitt **Testendpunkt** den Endpunkt aus, der am besten zu Ihrem Anwendungsfall passt. Um mehrere Testsuiten gleichzeitig mit derselben auszuführen AWS-Konto, wählen Sie Endpunkt **auf Geräteebene**. Wählen Sie **Endpunkt auf Kontoebene** aus, um jeweils eine Testsuite auszuführen.
![\[Optionen zur Auswahl eines Endpunkts auf Konto- oder Geräteebene für Tests mit Angabe einer Endpunkt-URL und der Schaltfläche Weiter.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-endpoint.png)
1. **Schritt 4** zeigt eine Übersicht über das ausgewählte Testgerät, den Testendpunkt, die Testsuite und die konfigurierte Testgeräterolle. Wählen Sie die Schaltfläche **Bearbeiten** für jeden Abschnitt aus, den Sie bearbeiten möchten, um Änderungen vorzunehmen. Nachdem Sie Ihre Testkonfiguration bestätigt haben, wählen Sie **Ausführen** aus, um die Testsuite zu erstellen und Ihre Tests auszuführen.
**Anmerkung**
Zum Erzielen optimaler Ergebnisse können Sie Ihr ausgewähltes Testgerät mit dem Device-Advisor-Testendpunkt verbinden, bevor Sie mit der Ausführung der Testsuite beginnen. Wir empfehlen, dass Sie für Ihr Gerät einen Mechanismus entwickeln, mit dem Sie alle fünf Sekunden bis zu ein bis zwei Minuten lang versuchen können, eine Verbindung zu unserem Testendpunkt herzustellen.
![\[Eine Gerätekonfigurationskonsole, auf der Details zur Geräterolle, Testendpunkt und Optionen zum Abbrechen, Zurückgehen oder Ausführen angezeigt werden.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-device-review.png)
![\[Eine Gerätekonfigurationskonsole, auf der Details zur Geräterolle, Testendpunkte und Optionen zum Abbrechen, Zurückgehen oder Ausführen angezeigt werden.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-device-review-contd.png)
1. Wählen Sie im Navigationsbereich unter **Test** die Option **Device Advisor** und dann **Testläufe und Ergebnisse** aus. Wählen Sie eine Testsuite-Ausführung aus, um deren Ausführungsdetails und Protokolle anzuzeigen.
![\[Die Testsuite-Schnittstelle, die darauf hinweist, dass für das Gerät "" MyThing ein MQTT 3.1.1-Test im Gange ist.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-console-runs-results.png)
1. Um auf die CloudWatch Amazon-Logs für die Suite zuzugreifen, führe folgenden Befehl aus:
+ Wählen Sie **Test Suite Log**, um die CloudWatch Protokolle für den Test Suite-Lauf anzuzeigen.
+ Wählen Sie **Testfallprotokoll** für einen beliebigen Testfall aus, um testfallspezifische CloudWatch Protokolle anzuzeigen.
1. Führen Sie auf der Grundlage Ihrer Testergebnisse eine [Fehlerbehebung](https://docs.aws.amazon.com/iot/latest/developerguide/iot_troubleshooting.html#device-advisor-troubleshooting) auf Ihrem Gerät durch, bis alle Tests bestanden sind.
# Device-Advisor-Workflow
In diesem Tutorial wird erklärt, wie Sie eine benutzerdefinierte Testsuite erstellen und Tests für das Gerät ausführen, das Sie in der Konsole testen möchten. Nach Abschluss der Tests können Sie die Testergebnisse und detaillierte Protokolle anzeigen.
## Voraussetzungen
Bevor Sie mit diesem Tutorial beginnen, führen Sie die unter [Einrichtung](device-advisor-setting-up.md) beschriebenen Schritte aus.
## Erstellen einer Testsuite-Definition
[Installieren Sie zunächst ein AWS SDK](https://docs.aws.amazon.com/iot/latest/developerguide/iot-connect-service.html#iot-service-sdks).
### `rootGroup`-Syntax
Eine Root-Gruppe ist eine JSON-Zeichenfolge, die angibt, welche Testfälle in Ihre Testsuite aufgenommen werden sollen. Sie spezifiziert auch alle erforderlichen Konfigurationen für diese Testfälle. Verwenden Sie die Root-Gruppe, um Ihre Testsuite nach Ihren Bedürfnissen zu strukturieren und zu ordnen. Die Hierarchie einer Testsuite ist folgende:
```
test suite → test group(s) → test case(s)
```
Eine Testsuite muss mindestens eine Testgruppe haben und jede Testgruppe muss mindestens einen Testfall haben. Device Advisor führt Tests in der Reihenfolge aus, in der Sie die Testgruppen und Testfälle definieren.
Jede Root-Gruppe folgt dieser Grundstruktur:
```
{
"configuration": { // for all tests in the test suite
"": ""
}
"tests": [{
"name": ""
"configuration": { // for all sub-groups in this test group
"": ""
},
"tests": [{
"name": ""
"configuration": { // for all test cases in this test group
"": ""
},
"test": {
"id": ""
"version": ""
}
}]
}]
}
```
In der Root-Gruppe definieren Sie die Testsuite mit einem `name`, der `configuration` und den `tests`, die die Gruppe enthält. Die `tests`-Gruppe enthält die Definitionen der einzelnen Tests. Sie definieren jeden Test mit einem `name`, einer `configuration` und einem `test`-Block, der die Testfälle für diesen Test definiert. Schließlich wird jeder Testfall mit einer `id` und einer `version` definiert.
Hinweise zur Verwendung der Felder `"id"` und `"version"` und für jeden Testfall (`test`-Block) finden Sie unter [Device-Advisor-Testfälle](device-advisor-tests.md). Dieser Abschnitt enthält auch Informationen zu den verfügbaren `configuration`-Einstellungen.
Der folgende Block ist ein Beispiel für eine Root-Gruppenkonfiguration. Diese Konfiguration spezifiziert die Testfälle *MQTT Connect Happy Case* und *MQTT Connect Exponential Backoff Retries* zusammen mit Beschreibungen der Konfigurationsfelder.
```
{
"configuration": {}, // Suite-level configuration
"tests": [ // Group definitions should be provided here
{
"name": "My_MQTT_Connect_Group", // Group definition name
"configuration": {} // Group definition-level configuration,
"tests": [ // Test case definitions should be provided here
{
"name": "My_MQTT_Connect_Happy_Case", // Test case definition name
"configuration": {
"EXECUTION_TIMEOUT": 300 // Test case definition-level configuration, in seconds
},
"test": {
"id": "MQTT_Connect", // test case id
"version": "0.0.0" // test case version
}
},
{
"name": "My_MQTT_Connect_Jitter_Backoff_Retries", // Test case definition name
"configuration": {
"EXECUTION_TIMEOUT": 600 // Test case definition-level configuration, in seconds
},
"test": {
"id": "MQTT_Connect_Jitter_Backoff_Retries", // test case id
"version": "0.0.0" // test case version
}
}]
}]
}
```
Sie müssen die Root-Gruppenkonfiguration angeben, wenn Sie Ihre Testsuite-Definition erstellen. Speichern Sie die `suiteDefinitionId`, die im Antwortobjekt zurückgegeben wird. Sie können diese ID verwenden, um Ihre Testsuite-Definitionsinformationen abzurufen und Ihre Testsuite auszuführen.
Hier ist ein Beispiel für ein Java-SDK:
```
response = iotDeviceAdvisorClient.createSuiteDefinition(
CreateSuiteDefinitionRequest.builder()
.suiteDefinitionConfiguration(SuiteDefinitionConfiguration.builder()
.suiteDefinitionName("your-suite-definition-name")
.devices(
DeviceUnderTest.builder()
.thingArn("your-test-device-thing-arn")
.certificateArn("your-test-device-certificate-arn")
.deviceRoleArn("your-device-role-arn") //if using SigV4 for MQTT over WebSocket
.build()
)
.rootGroup("your-root-group-configuration")
.devicePermissionRoleArn("your-device-permission-role-arn")
.protocol("MqttV3_1_1 || MqttV5 || MqttV3_1_1_OverWebSocket || MqttV5_OverWebSocket")
.build()
)
.build()
)
```
## Abrufen einer Testsuite-Definition
Nachdem Sie Ihre Testsuite-Definition erstellt haben, erhalten Sie die `suiteDefinitionId` im Antwortobjekt der `CreateSuiteDefinition`-API-Operation.
Wenn der Vorgang die `suiteDefinitionId` zurückgibt, sehen Sie möglicherweise neue `id`-Felder in jeder Gruppe und eine Testfalldefinition innerhalb der Root-Gruppe. Sie können diese verwenden IDs , um eine Teilmenge Ihrer Testsuite-Definition auszuführen.
Java-SDK-Beispiel:
```
response = iotDeviceAdvisorClient.GetSuiteDefinition(
GetSuiteDefinitionRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.build()
)
```
## Abrufen eines Testendpunkts
Verwenden Sie die `GetEndpoint`-API-Operation, um den von Ihrem Gerät verwendeten Testendpunkt abzurufen. Wählen Sie den Endpunkt aus, der am besten zu Ihrem Test passt. Um mehrere Testsuiten gleichzeitig auszuführen, verwenden Sie den Endpunkt auf Geräteebene, indem Sie einen `thing ARN`, `certificate ARN` oder `device role ARN` angeben. Um eine einzelne Testsuite auszuführen, geben Sie keine Argumente für den GetEndpoint Vorgang zur Auswahl des Endpunkts auf Kontoebene an.
SDK-Beispiel:
```
response = iotDeviceAdvisorClient.getEndpoint(GetEndpointRequest.builder()
.certificateArn("your-test-device-certificate-arn")
.thingArn("your-test-device-thing-arn")
.deviceRoleArn("your-device-role-arn") //if using SigV4 for MQTT over WebSocket
.build())
```
## Ausführen einer Testsuite
Nachdem Sie eine Testsuite-Definition erstellt und Ihr Testgerät so konfiguriert haben, dass es eine Verbindung zu Ihrem Device-Advisor-Testendpunkt herstellt, führen Sie Ihre Testsuite mit der `StartSuiteRun`-API aus.
Für MQTT-Kunden verwenden Sie entweder `certificateArn` oder `thingArn`, um die Testsuite auszuführen. Wenn beide konfiguriert sind, wird das Zertifikat verwendet, wenn es zum Ding gehört.
Verwenden Sie für MQTT statt WebSocket Kunde, `deviceRoleArn` um die Testsuite auszuführen. Wenn sich die angegebene Rolle von der in der Testsuite-Definition angegebenen Rolle unterscheidet, hat die angegebene Rolle Vorrang vor der definierten Rolle.
Verwenden Sie für `.parallelRun()` `true`, wenn Sie einen Endpunkt auf Geräteebene verwenden, um mehrere Testsuiten parallel mit einem AWS-Konto auszuführen.
SDK-Beispiel:
```
response = iotDeviceAdvisorClient.startSuiteRun(StartSuiteRunRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunConfiguration(SuiteRunConfiguration.builder()
.primaryDevice(DeviceUnderTest.builder()
.certificateArn("your-test-device-certificate-arn")
.thingArn("your-test-device-thing-arn")
.deviceRoleArn("your-device-role-arn") //if using SigV4 for MQTT over WebSocket
.build())
.parallelRun(true | false)
.build())
.build())
```
Speichern Sie die `suiteRunId` aus der Antwort. Sie werden diese verwenden, um die Ergebnisse dieser Testsuite-Ausführung abzurufen.
## Abrufen einer Testsuite-Ausführung
Nachdem Sie eine Testsuite ausgeführt haben, können Sie ihren Fortschritt und ihre Ergebnisse mit der `GetSuiteRun`-API überprüfen.
SDK-Beispiel:
```
// Using the SDK, call the GetSuiteRun API.
response = iotDeviceAdvisorClient.GetSuiteRun(
GetSuiteRunRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunId("your-suite-run-id")
.build())
```
## Beenden einer Testsuite-Ausführung
Um eine Testsuite-Ausführung, die noch läuft, zu beenden, können Sie die `StopSuiteRun`-API-Operation aufrufen. Nachdem Sie die `StopSuiteRun`-Operation aufgerufen haben, startet der Service den Bereinigungsvorgang. Während der Service den Bereinigungsvorgang ausführt, führt die Testsuite Statusaktualisierungen bis `Stopping` durch. Der Bereinigungsvorgang kann mehrere Minuten in Anspruch nehmen. Sobald der Vorgang abgeschlossen ist, führt die Testsuite Statusaktualisierungen bis `Stopped` durch. Nachdem ein Testlauf vollständig beendet wurde, starten Sie eine weitere Testsuite-Ausführung. Sie können den Status der Ausführung der Suite regelmäßig mithilfe der `GetSuiteRun`-API-Operation überprüfen, wie im vorherigen Abschnitt gezeigt.
SDK-Beispiel:
```
// Using the SDK, call the StopSuiteRun API.
response = iotDeviceAdvisorClient.StopSuiteRun(
StopSuiteRun.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunId("your-suite-run-id")
.build())
```
## Abrufen eines Qualifizierungsberichts für eine erfolgreiche Ausführung der Qualifizierungstestsuite
Wenn Sie eine Qualifizierungstestsuite ausführen, die erfolgreich abgeschlossen wurde, können Sie mit der `GetSuiteRunReport`-API-Operation einen Qualifizierungsbericht abrufen. Sie verwenden diesen Qualifizierungsbericht, um Ihr Gerät für das AWS IoT Core -Qualifizierungsprogramm zu qualifizieren. Um festzustellen, ob es sich bei Ihrer Testsuite um eine Qualifizierungstestsuite handelt, überprüfen Sie, ob der `intendedForQualification`-Parameter auf `true` eingestellt ist. Nachdem Sie die `GetSuiteRunReport`-API-Operation aufgerufen haben, können Sie den Bericht bis zu 90 Sekunden lang von der zurückgegebenen URL herunterladen. Wenn seit dem letzten Aufruf der `GetSuiteRunReport`-Operation mehr als 90 Sekunden vergangen sind, rufen Sie die Operation erneut auf, um eine neue, gültige URL abzurufen.
SDK-Beispiel:
```
// Using the SDK, call the getSuiteRunReport API.
response = iotDeviceAdvisorClient.getSuiteRunReport(
GetSuiteRunReportRequest.builder()
.suiteDefinitionId("your-suite-definition-id")
.suiteRunId("your-suite-run-id")
.build()
)
```
# Ausführlicher Konsolen-Workflow von Device Advisor
In diesem Tutorial erstellen Sie eine benutzerdefinierte Testsuite und führen Tests für das Gerät aus, das Sie in der Konsole testen möchten. Nach Abschluss der Tests können Sie die Testergebnisse und detaillierte Protokolle anzeigen.
**Topics**
+ [Voraussetzungen](#da-detailed-prereqs)
+ [Erstellen einer Testsuite-Definition](#device-advisor-console-create-suite)
+ [Ausführen einer Testsuite](#device-advisor-console-run-test-suite)
+ [Beenden einer Testsuite-Ausführung (optional)](#device-advisor-stop-test-run)
+ [Anzeigen von Details und Protokolle der Testsuite-Ausführung](#device-advisor-console-view-logs)
+ [Laden Sie einen AWS IoT Qualifikationsbericht herunter](#device-advisor-console-qualification-report)
## Voraussetzungen
Sie müssen zuerst [ein Ding und ein Zertifikat erstellen](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-create-thing-certificate), bevor Sie dieses Tutorial abschließen können.
## Erstellen einer Testsuite-Definition
Erstellen Sie eine Testsuite-Suite, damit Sie sie für Ihre Geräte ausführen und die Überprüfung durchführen können.
1. Erweitern Sie im Navigationsbereich in der [AWS IoT -Konsole](https://console.aws.amazon.com//iot) die Optionen **Test**, **Device Advisor** und wählen Sie dann **Testsuites** aus.
![\[Die Device Advisor-Oberfläche mit Optionen zur Erstellung von Testsuiten für qualifizierte Geräte, zur Durchführung von Langzeittests und benutzerdefinierten Testsuiten.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-testsuite.png)
Wählen Sie **Testsuite erstellen** aus.
1. Wählen Sie entweder `Use the AWS Qualification test suite` oder `Create a new test suite` aus.
Wählen Sie als Protokoll entweder **MQTT 3.1.1** oder **MQTT 5** aus.
![\[„Testsuite erstellen“ mit Optionen zur Auswahl des Testsuitetyps (AWS IoT Core Qualifikation, Langdauer oder Benutzerdefiniert) und des Protokolls (MQTT 3.1.1 oder MQTT 5).\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-create-test-suite.png)
Wählen Sie aus`Use the AWS Qualification test suite`, ob Sie Ihr Gerät qualifizieren und es im Gerätekatalog für AWS Partner auflisten möchten. Wenn Sie diese Option wählen, werden die Testfälle, die für die Qualifizierung Ihres Geräts für das AWS IoT Core -Qualifizierungsprogramm erforderlich sind, vorab ausgewählt. Testgruppen und Testfälle können nicht hinzugefügt oder entfernt werden. Sie müssen trotzdem die Eigenschaften der Testsuite konfigurieren.
Wählen Sie `Create a new test suite` aus, um eine benutzerdefinierte Testsuite zu erstellen und zu konfigurieren. Wir empfehlen, für erste Tests und zur Fehlerbehebung mit dieser Option zu beginnen. Eine benutzerdefinierte Testsuite muss mindestens eine Testgruppe haben und jede Testgruppe muss mindestens einen Testfall haben. Für die Zwecke dieses Tutorials wählen wir diese Option und wählen **Weiter** aus.
![\[Seite „Testsuite konfigurieren“, auf der Schritte zum Erstellen einer Testsuite mit Testgruppen und Fällen zum Testen von IoT-Geräten aufgeführt werden.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-configure-test-suite.png)
1. Wählen Sie **Eigenschaften der Testsuite** aus. Sie müssen die Eigenschaften der Testsuite erstellen, wenn Sie Ihre Testsuite erstellen.
![\[Die Oberfläche „Testsuite konfigurieren“ zeigt Optionen zum Erstellen von Testgruppen und Hinzufügen von Testfällen zum Testen der Funktionalität von IoT-Geräten.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-test-suite-properties.png)
Füllen Sie unter **Eigenschaften der Testsuite** die folgenden Felder aus:
+ **Name der Testsuite**: Sie können die Suite mit einem benutzerdefinierten Namen erstellen.
+ **Timeout** (optional): Das Timeout in Sekunden für jeden Testfall in der aktuellen Testsuite. Wenn Sie keinen Timeout-Wert angeben, wird der Standardwert verwendet.
+ **Tags** (optional): Fügen Sie der Testsuite Tags hinzu.
![\[Das Fenster mit dem Titel „Eigenschaften der Testsuite“ zeigt Felder zur Angabe eines Testsuite-Namens, eines Timeouts und benutzerdefinierter Tags für eine Device Advisor-Demosuite.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-test-suite-properties-1.png)
Wenn Sie fertig sind, wählen Sie **Eigenschaften aktualisieren** aus.
1. Um die Konfiguration auf Gruppenebene zu ändern, wählen Sie unter `Test group 1` **Bearbeiten** aus. Geben Sie dann einen **Namen** ein, um der Gruppe einen benutzerdefinierten Namen zu geben.
Optional können Sie unter der ausgewählten Testgruppe auch einen **Timeout-Wert** in Sekunden eingeben. Wenn Sie keinen Timeout-Wert angeben, wird der Standardwert verwendet.
![\[Die Schnittstelle „Testsuite konfigurieren“ zur Erstellung von Testgruppen und Fällen zur Validierung der Funktionalität von IoT-Geräten.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-edit-test-group.png)
Wählen Sie **Fertig** aus.
1. Ziehen Sie einen der verfügbaren Testfälle aus **Testfälle** in die Testgruppe.
![\[Die Konfigurationsoberfläche für die Erstellung einer Testsuite in Device Advisor mit Optionen zum Hinzufügen von Testgruppen und Testfällen zum Testen von IoT-Geräten.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-configure-test-suite-step5.png)
1. Um die Konfiguration auf Testfallebene für den Testfall zu ändern, den Sie Ihrer Testgruppe hinzugefügt haben, wählen Sie **Bearbeiten** aus. Geben Sie dann einen **Namen** ein, um der Gruppe einen benutzerdefinierten Namen zu geben.
Optional können Sie unter der ausgewählten Testgruppe auch einen **Timeout-Wert** in Sekunden eingeben. Wenn Sie keinen Timeout-Wert angeben, wird der Standardwert verwendet.
![\[Konfigurationsoberfläche für die Testsuite mit Optionen zur Konfiguration von Testgruppen, Testfällen, Timeout-Einstellungen und Startpunkten für die Ausführung der Testsuite.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-edit-test-case.png)
Wählen Sie **Fertig** aus.
**Anmerkung**
Um der Testsuite weitere Testgruppen hinzuzufügen, wählen Sie **Testgruppe hinzufügen** aus. Folgen Sie den vorherigen Schritten, um weitere Testgruppen zu erstellen und zu konfigurieren oder um einer oder mehreren Testgruppen weitere Testfälle hinzuzufügen. Testgruppen und Testfälle können neu angeordnet werden, indem Sie einen Testfall auswählen und an die gewünschte Position ziehen. Device Advisor führt Tests in der Reihenfolge aus, in der Sie die Testgruppen und Testfälle definieren.
1. Wählen Sie **Weiter** aus.
1. Konfigurieren Sie in **Schritt 3** eine Geräterolle, die Device Advisor verwendet, um AWS IoT MQTT-Aktionen im Namen Ihres Testgeräts auszuführen.
Wenn Sie in **Schritt 2** nur den **MQTT-Connect**-Testfall ausgewählt haben, wird die **Connect**-Aktion automatisch überprüft, da diese Berechtigung für die Geräterolle erforderlich ist, um diese Testsuite auszuführen. Wenn Sie andere Testfälle ausgewählt haben, werden die entsprechenden erforderlichen Aktionen überprüft. Stellen Sie sicher, dass die Ressourcenwerte für jede der Aktionen angegeben werden. Geben Sie beispielsweise für die **Connect**-Aktion die Client-ID an, mit der sich Ihr Gerät mit dem Device-Advisor-Endpunkt verbindet. Sie können mehrere Werte angeben, indem Sie die Werte durch Kommas trennen, und Sie können Präfixwerte auch mit einem Platzhalterzeichen (\$1) angeben. Um beispielsweise die Erlaubnis zur Veröffentlichung zu einem beliebigen Thema zu erteilen, das mit `MyTopic` beginnt, können Sie „`MyTopic*`“ als Ressourcenwert eingeben.
![\[Der Schritt „Wählen Sie eine Geräterolle“ in Device Advisor zum Erstellen einer Testsuite mit Optionen zum Erstellen einer neuen Rolle oder zum Auswählen einer vorhandenen Rolle sowie Feldern zur Angabe von Rollennamen, Berechtigungen und Ressourcendetails.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-connect-role.png)
Wenn Sie bereits zuvor eine Geräterolle erstellt haben und diese Rolle verwenden möchten, wählen Sie **Eine vorhandene Rolle auswählen** und anschließend unter **Rolle auswählen** Ihre Geräterolle aus.
![\[Die Seite zur Auswahl einer Geräterolle für Device Advisor-Tests mit Optionen zum Erstellen einer neuen Rolle oder zum Auswählen einer vorhandenen Rolle.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-existing-role.png)
Konfigurieren Sie Ihre Geräterolle mit einer der beiden verfügbaren Optionen und wählen Sie dann **Weiter** aus.
1. Stellen Sie in **Schritt 4** sicher, dass die in jedem der Schritte angegebene Konfiguration korrekt ist. Um die für einen bestimmten Schritt bereitgestellte Konfiguration zu bearbeiten, wählen Sie **Bearbeiten** für den entsprechenden Schritt aus.
Nachdem Sie die Konfiguration überprüft haben, wählen Sie **Testsuite erstellen** aus.
Die Testsuite sollte erfolgreich erstellt worden sein und Sie werden zur Seite **Testsuites** weitergeleitet, auf der Sie alle erstellten Testsuites anzeigen können.
Wenn die Erstellung der Testsuite fehlgeschlagen ist, stellen Sie sicher, dass die Testsuite, die Testgruppen, die Testfälle und die Geräterolle gemäß den vorherigen Anweisungen konfiguriert wurden.
## Ausführen einer Testsuite
1. Erweitern Sie im Navigationsbereich in der [AWS IoT -Konsole](https://console.aws.amazon.com//iot) die Optionen **Test**, **Device Advisor** und wählen Sie dann **Testsuites** aus.
1. Wählen Sie die Testsuite aus, für die Sie die Details der Testsuite anzeigen möchten.
![\[Die Konsole, auf der eine einzelne Testsuite mit dem Namen „Device Advisor Demo Suite“ angezeigt wird, die am 11. Mai 2021 erstellt wurde.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-test-suites.png)
Auf der Detailseite der Testsuite werden alle Informationen zur Testsuite angezeigt.
1. Wählen Sie **Aktionen** und dann **Testsuite ausführen** aus.
![\[Die Demo-Suite-Seite mit der Schaltfläche „Testsuite ausführen“ und einem leeren Aktivitätsprotokoll, das keine vorherigen Testsuite-Läufe anzeigt.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-run-test-suites.png)
1. Unter **Konfiguration ausführen** müssen Sie eine AWS IoT Sache oder ein Zertifikat auswählen, das Sie mit Device Advisor testen möchten. Wenn Sie noch keine vorhandenen Dinge oder Zertifikate haben, [erstellen Sie zunächst AWS IoT Core Ressourcen](device-advisor-setting-up.md).
Wählen Sie im Abschnitt **Testendpunkt** den Endpunkt aus, der am besten zu Ihrem Fall passt. Wenn Sie in future mehrere Testsuiten gleichzeitig mit demselben AWS Konto ausführen möchten, wählen Sie Endpunkt **auf Geräteebene** aus. Wenn Sie allerdings planen, jeweils nur eine Testsuite auszuführen, wählen Sie **Endpunkt auf Kontoebene** aus, um jeweils eine Testsuite auszuführen.
Konfigurieren Sie Ihr Testgerät mit dem Testendpunkt des ausgewählten Device Advisors.
Nachdem Sie ein Ding oder ein Zertifikat und einen Device-Advisor-Endpunkt ausgewählt haben, wählen Sie **Test ausführen** aus.
![\[Die Konfiguration für die Ausführung einer Testsuite AWS IoT Core, mit der Sie Testgeräte (Dinge oder Zertifikate) auswählen, einen Testendpunkt (auf Konto- oder Geräteebene) auswählen und optional Tags hinzufügen können.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-choose-thing-certificate.png)
1. Wählen Sie im oberen Banner die Option **Gehe zu den Ergebnissen**, um die Details des Testlaufs anzuzeigen.
![\[Einzelheiten zu einer benutzerdefinierten Testsuite mit dem Titel „Device Advisor Demo Suite“, die derzeit den Status „Ausstehend“ hat.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-test-run-results.png)
## Beenden einer Testsuite-Ausführung (optional)
1. Erweitern Sie im Navigationsbereich in der [AWS IoT -Konsole](https://console.aws.amazon.com//iot) die Optionen **Test**, **Device Advisor** und wählen Sie dann **Testläufe und Ergebnisse** aus.
1. Wählen Sie die laufende Testsuite, die Sie beenden möchten.
![\[Die Ergebnisse der Tests werden auf der Device Advisor-Konsole ausgeführt.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-test-suite-to-stop.PNG)
1. Wählen Sie **Aktionen** und dann **Testsuite beenden** aus.
![\[Die Ergebnisse von Testläufen auf der Device Advisor-Konsole.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-stop-test-suite.PNG)
1. Der Bereinigungsvorgang nimmt einige Minuten in Anspruch. Während der Bereinigungsvorgang läuft, ist der Status des Testlaufs `STOPPING`. Warten Sie, bis der Bereinigungsprozess abgeschlossen ist und sich der Status der Testsuite in den `STOPPED`-Status ändert, bevor Sie eine neue Suite ausführen.
![\[Die Ergebnisse der gestoppten Testläufe auf der Device Advisor-Konsole.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-stopped-test-suite.PNG)
## Anzeigen von Details und Protokolle der Testsuite-Ausführung
1. Erweitern Sie im Navigationsbereich in der [AWS IoT -Konsole](https://console.aws.amazon.com//iot) die Optionen **Test**, **Device Advisor** und wählen Sie dann **Testläufe und Ergebnisse** aus.
Diese Seite zeigt Folgendes an:
+ Anzahl der IoT-Dinge
+ Anzahl der IoT-Zertifikate
+ Anzahl der derzeit ausgeführten Testsuites
+ Alle Testsuite-Ausführungen, die erstellt wurden
1. Wählen Sie die Testsuite aus, für die Sie die Details der Ausführung und die Protokolle anzeigen möchten.
![\[Ein Abschnitt mit Testläufen und Ergebnissen, in dem Details zu einer Testsuite mit dem Namen „Device Advisor-Demosuite“ angezeigt werden, die derzeit in Bearbeitung ist.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-test-suite-run.png)
Auf der Seite mit der Zusammenfassung der Testsuite wird der Status der aktuellen Testsuite-Ausführung angezeigt. Diese Seite wird automatisch alle 10 Sekunden aktualisiert. Wir empfehlen, dass Sie für Ihr Gerät einen Mechanismus entwickeln, mit dem Sie alle fünf Sekunden ein bis zwei Minuten lang versuchen können, eine Verbindung zu unserem Testendpunkt herzustellen. Sie können dann mehrere Testfälle nacheinander automatisiert ausführen.
![\[Das Testfallprotokoll, das einen erfolgreichen MQTT Connect-Test ohne angezeigte Systemmeldung anzeigt.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-run-summary.png)
1. Um auf die CloudWatch Protokolle für den Testsuite-Lauf zuzugreifen, wählen Sie **Test Suite Log**.
Um auf die CloudWatch Protokolle für einen beliebigen Testfall zuzugreifen, wählen Sie **Testfallprotokoll**.
1. Führen Sie auf der Grundlage Ihrer Testergebnisse eine [Fehlerbehebung](https://docs.aws.amazon.com/iot/latest/developerguide/iot_troubleshooting.html#device-advisor-troubleshooting) auf Ihrem Gerät durch, bis alle Tests bestanden sind.
## Laden Sie einen AWS IoT Qualifikationsbericht herunter
Wenn Sie bei der Erstellung einer **Testsuite die Option AWS IoT Qualifizierungstestsuite verwenden** ausgewählt haben und eine Qualifizierungstestsuite ausführen konnten, können Sie einen Qualifizierungsbericht herunterladen, indem Sie auf der Übersichtsseite des Testlaufs die Option **Qualifikationsbericht herunterladen** wählen.
![\[Testergebnisse des Qualifizierungsprogramms, die die bestandenen Tests für MQTT, TLS und andere Komponenten belegen.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/da-qualification-report.png)
# Konsolen-Workflow für Tests mit langer Dauer
Dieses Tutorial hilft Ihnen bei den ersten Schritten mit der Durchführung von Tests mit langer Dauer auf Device Advisor mithilfe der Konsole. Folgen Sie den Schritten unter [Einrichtung](device-advisor-setting-up.md), um das Tutorial abzuschließen.
1. Erweitern Sie im Navigationsbereich in der [AWS IoT -Konsole](https://console.aws.amazon.com/iot) die Optionen **Test**, dann **Device Advisor** und dann **Testsuites**. Wählen Sie auf der Seite die Option **Create long duration test suite** (Testsuite mit langer Dauer erstellen) aus.
![\[Der Abschnitt Testsuite mit langer Laufzeit erstellen in der Device Advisor-Konsole.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/create-ld-ts.png)
1. Wählen Sie auf der Seite **Testsuite erstellen** die Option **Testsuite mit langer Dauer** und dann **Weiter** aus.
Wählen Sie als Protokoll entweder **MQTT 3.1.1** oder **MQTT 5** aus.
![\[Der Schritt Testsuite erstellen in der Device Advisor-Konsole.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/choose-ld-ts.png)
1. Führen Sie auf der Seite **Testsuite konfigurieren** die folgenden Schritte aus:
1. Aktualisieren Sie das Feld **Name der Testsuite**.
1. Aktualisieren Sie das Feld **Name der Testgruppe**.
1. Wählen Sie die **Geräteoperationen** aus, die das Gerät ausführen kann. Dadurch werden die auszuführenden Tests ausgewählt.
1. Wählen Sie die Option **Einstellungen** aus.
![\[Der Schritt Testsuite erstellen der Device Advisor-Konsole.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/configure-ld-ts.png)
1. (Optional) Geben Sie die maximale Zeit ein, die Device Advisor warten muss, bis die Basistests abgeschlossen sind. Wählen Sie **Speichern** aus.
![\[Das Feld „Timeout optional“ für „Basistests“ der Device Advisor-Konsole.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/timeout-ld-ts.png)
1. Gehen Sie in den Abschnitten **Advanced tests** (Erweiterte Tests) und **Zusätzliche Einstellungen** wie folgt vor.
1. Wählen Sie die **erweiterten Tests** aus, die Sie im Rahmen dieses Tests ausführen möchten, bzw. heben Sie die Auswahl auf.
1. **Bearbeiten** Sie gegebenenfalls die Konfigurationen für die Tests.
1. Konfigurieren Sie die **zusätzliche Ausführungszeit** im Abschnitt **Zusätzliche Einstellungen**.
1. Wählen Sie **Weiter** aus, um mit dem nächsten Schritt fortzufahren.
![\[Die Device Advisor-Schnittstelle, mit der Sie Tests auf IoT-Geräten konfigurieren und ausführen können.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/additional-ld-ts.png)
1. Erstellen Sie in diesem Schritt **eine neue Rolle** oder **wählen Sie eine vorhandene Rolle** aus. Details dazu finden Sie unter [Erstellen einer IAM-Rolle, die Sie als Ihre Geräterolle verwenden möchten](device-advisor-setting-up.md#da-iam-role).
![\[Der Schritt zur Geräterolle, in dem Sie eine neue Rolle erstellen oder eine vorhandene Rolle für das getestete Gerät auswählen können. Die Rolle gewährt Device Advisor die Erlaubnis, MQTT-Aktionen wie Connect, Veröffentlichen und Abonnieren im Namen des Testgeräts auszuführen.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/devicerole-ld-ts.png)
1. Überprüfen Sie alle bis zu diesem Schritt erstellten Konfigurationen und wählen Sie **Testsuite erstellen** aus.
![\[Die Seite „Überprüfen“, auf der Sie alle Details der Device Advisor-Konfiguration überprüfen können.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/finalconfigure1-ld-ts.png)
![\[Die Konfigurationsseite, auf der Sie alle Details für Device Advisor einsehen können.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/finalconfigure2-ld-ts.png)
1. Die erstellte Testsuite befindet sich im Abschnitt **Testsuites**. Wählen Sie die Suite aus, um Details dazu anzuzeigen.
![\[Eine neue Testsuite mit dem Namen „Long Duration Demo“ wurde erfolgreich im Device Advisor erstellt.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/finalts-ld-ts.png)
1. Um die erstellte Testsuite auszuführen, wählen Sie **Aktionen** und dann **Testsuite ausführen** aus.
![\[Das Dropdownmenü „Aktionen“ der neuen Testsuite mit dem Namen „Long Duration Demo“ in der Device Advisor-Oberfläche.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/runts-ld-ts.png)
1. Wählen Sie die Konfigurationsoptionen auf der Seite **Konfiguration ausführen** aus.
1. Wählen Sie die **Dinge** oder das **Zertifikat** aus, für das der Test ausgeführt werden soll.
1. Wählen Sie entweder den **Endpunkt auf Kontoebene** oder den **Endpunkt auf Geräteebene** aus.
1. Wählen Sie zum Ausführen des Tests die Option **Test ausführen** aus.
![\[Die Seite „Konfiguration ausführen“ in der Device Advisor-Oberfläche. Auf der Seite werden „Testgeräte auswählen“, „Dinge“, „Testendpunkt“ und „Tags“ angezeigt.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/runconfiguration-ld-ts.png)
1. Um die Ergebnisse der Testsuite-Ausführung anzuzeigen, wählen Sie im linken Navigationsbereich **Testläufe und Ergebnisse** aus. Wählen Sie die Testsuite aus, die ausgeführt wurde, um die Details der Ergebnisse anzuzeigen.
![\[Der Testfall „Long Duration Demo“ auf der Seite Testläufe und Ergebnisse.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/results-ld-ts.png)
1. Im vorherigen Schritt wird die Seite mit der Testzusammenfassung aufgerufen. Alle Details des Testlaufs werden auf dieser Seite angezeigt. Wenn Sie in der Konsole aufgefordert werden, die Geräteverbindung herzustellen, verbinden Sie Ihr Gerät mit dem angegebenen Endpunkt. Der Fortschritt der Tests ist auf dieser Seite zu sehen.
![\[Die Übersichtsseite des Tests „Long Duration Demo“, den Sie erstellt haben.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/summary-ld-ts.png)
1. Der Test mit langer Dauer bietet eine zusätzliche **Zusammenfassung des Testprotokolls** im Seitenbereich, in der alle wichtigen Ereignisse zwischen dem Gerät und dem Broker nahezu in Echtzeit angezeigt werden. Um detailliertere Protokolle anzuzeigen, klicken Sie auf **Testfallprotokoll**.
![\[Der Abschnitt mit der Zusammenfassung des Testprotokolls auf der Seite des Tests „Long Duration Demo“.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/log-ld-ts.png)
# Device-Advisor-VPC-Endpunkte (AWS PrivateLink)
Sie können eine private Verbindung zwischen Ihrer VPC und dem AWS IoT Core Device Advisor Testendpunkt (Datenebene) herstellen, indem Sie einen *VPC-Schnittstellen-Endpunkt* erstellen. Sie können diesen Endpunkt verwenden, um die zuverlässige und sichere Konnektivität von AWS IoT Geräten zu überprüfen, AWS IoT Core bevor Sie sie in der Produktion einsetzen. Die vorgefertigten Tests von Device Advisor helfen Ihnen dabei, Ihre Gerätesoftware anhand von Best Practices für die Verwendung von [TLS](https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html)-, [MQTT](https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html)-, [Device Shadow](https://docs.aws.amazon.com/iot/latest/developerguide/iot-device-shadows.html)- und [AWS IoT -Aufträgen](https://docs.aws.amazon.com/iot/latest/developerguide/iot-jobs.html) zu validieren.
[AWS PrivateLink](https://aws.amazon.com/privatelink)versorgt die Schnittstellenendpunkte, die mit Ihren IoT-Geräten verwendet werden. Über diesen Service können Sie privat auf den AWS IoT Core Device Advisor -Testendpunkt zugreifen, ohne Internet-Gateway, NAT-Gerät, VPN-Verbindung oder Direct Connect -Verbindung. Instances in Ihrer VPC, die TCP- und MQTT-Pakete senden, benötigen keine öffentlichen IP-Adressen, um mit AWS IoT Core Device Advisor Testendpunkten zu kommunizieren. Verkehr zwischen Ihrer VPC und AWS IoT Core Device Advisor geht nicht. AWS Cloud Jegliche TLS- und MQTT-Kommunikation zwischen IoT-Geräten und Device-Advisor-Testfällen bleibt innerhalb der Ressourcen in Ihrem AWS-Konto.
Jeder Schnittstellenendpunkt wird durch eine oder mehrere [Elastic Network-Schnittstellen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) in Ihren Subnetzen dargestellt.
Weitere Informationen zur Verwendung von Schnittstelllen-VPC-Endpunkten finden Sie unter [Schnittstellen-VPC-Endpunkte (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) im *Amazon-VPC-Benutzerhandbuch*.
## Überlegungen zu AWS IoT Core Device Advisor VPC-Endpunkten
Bevor Sie Schnittstellen-VPC-Endpunkte einrichten, lesen Sie über die [Eigenschaften und Einschränkungen von Schnittstellenendpunkten](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations) im *Amazon-VPC-Benutzerhandbuch* nach. Beachten Sie Folgendes, bevor Sie fortfahren:
+ AWS IoT Core Device Advisor unterstützt derzeit Aufrufe an den Device Advisor-Testendpunkt (Datenebene) von Ihrer VPC aus. Ein Message Broker verwendet Kommunikation auf Datenebene, um Daten zu senden und zu empfangen. Dies geschieht mithilfe von TLS- und MQTT-Paketen. VPC-Endpunkte für die AWS IoT Core Device Advisor Verbindung Ihres AWS IoT Geräts mit Device Advisor-Testendpunkten. [API-Aktionen der Steuerebene](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iotdeviceadvisor/index.html) werden von diesem VPC-Endpunkt nicht verwendet. Verwenden Sie die Konsole, ein AWS SDK oder eine AWS Befehlszeilenschnittstelle über das APIs öffentliche Internet, um eine Testsuite oder eine andere Steuerungsebene zu erstellen oder auszuführen.
+ Die folgenden AWS-Regionen unterstützen VPC-Endpunkte für: AWS IoT Core Device Advisor
+ USA Ost (Nord-Virginia)
+ USA West (Oregon)
+ Asien-Pazifik (Tokio)
+ Europa (Irland)
+ Device Advisor unterstützt MQTT mit X.509-Clientzertifikaten und RSA-Serverzertifikaten.
+ [VPC-Endpunktrichtlinien](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) werden derzeit nicht unterstützt.
+ Anweisungen zum [Erstellen von Ressourcen](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws), die VPC-Endpunkte verbinden, finden Sie unter [Voraussetzungen](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#prerequisites-interface-endpoints) für VPC-Endpunkte. Sie müssen eine VPC und private Subnetze erstellen, um AWS IoT Core Device Advisor VPC-Endpoints verwenden zu können.
+ Es gibt Kontingente für Ihre Ressourcen. AWS PrivateLink Weitere Informationen finden Sie unter [AWS PrivateLink -Kontingente](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html).
+ VPC-Endpunkte unterstützen nur IPv4 Datenverkehr.
## Erstellen Sie einen Schnittstellen-VPC-Endpunkt für AWS IoT Core Device Advisor
[Erstellen Sie einen Schnittstellen-VPC-Endpunkt](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html), um erste Schritte mit VPC-Endpunkten zu unternehmen. Wählen Sie AWS IoT Core Device Advisor als Nächstes als. AWS-Service Wenn Sie den verwenden AWS CLI, rufen Sie an, [describe-vpc-endpoint-services](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpc-endpoint-services.html)um zu bestätigen, dass er AWS IoT Core Device Advisor sich in einer Availability Zone in Ihrem befindet AWS-Region. Vergewissern Sie sich, dass die dem Endpunkt zugeordnete Sicherheitsgruppe die [TCP-Protokollkommunikation](https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html) für MQTT- und TLS-Datenverkehr zulässt. Verwenden Sie zum Beispiel in der Region USA Ost (Nord-Virginia) den folgenden Befehl:
```
aws ec2 describe-vpc-endpoint-services --service-name com.amazonaws.us-east-1.deviceadvisor.iot
```
Sie können einen VPC-Endpunkt für die AWS IoT Core Verwendung des folgenden Dienstnamens erstellen:
+ com.amazonaws.*region*.deviceadvisor.iot
Standardmäßig ist privates DNS für den Endpunkt aktiviert. Dadurch wird sichergestellt, dass der Standard-Testendpunkt weiterhin in Ihren privaten Subnetzen verwendet wird. Verwenden Sie die Konsole oder ein AWS SDK, um Ihren Endpunkt auf Konto AWS CLI - oder Geräteebene zu erhalten. Wenn Sie beispielsweise [get-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iotdeviceadvisor/get-endpoint.html) in einem öffentlichen Subnetz oder im öffentlichen Internet ausführen, können Sie Ihren Endpunkt abrufen und ihn verwenden, um eine Verbindung zu Device Advisor herzustellen. Weitere Informationen finden Sie unter [Zugriff auf einen Service über einen Schnittstellenendpunkt](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) im *Benutzerhandbuch für Amazon VPC*.
Um MQTT-Clients mit den VPC-Endpunktschnittstellen zu verbinden, erstellt der AWS PrivateLink Dienst DNS-Einträge in einer privaten gehosteten Zone, die an Ihre VPC angeschlossen ist. Diese DNS-Einträge leiten die Anforderungen des AWS IoT -Geräts an den VPC-Endpunkt weiter.
## Steuerung des Zugriffs auf AWS IoT Core Device Advisor über VPC-Endpunkte
Sie können den Gerätezugriff auf VPC-Endpunkte einschränken AWS IoT Core Device Advisor und den Zugriff nur über VPC-Endpunkte zulassen, indem Sie [VPC-Bedingungskontextschlüssel](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) verwenden. AWS IoT Core unterstützt die folgenden VPC-bezogenen Kontextschlüssel:
+ [SourceVpc](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpc)
+ [SourceVpce](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpce)
+ [VPCSourcelp](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-vpcsourceip)
**Anmerkung**
AWS IoT Core Device Advisor unterstützt derzeit keine [VPC-Endpunktrichtlinien](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#vpc-endpoint-policies).
Die folgende Richtlinie gewährt die Erlaubnis, AWS IoT Core Device Advisor mithilfe einer Client-ID, die dem Namen des Dings entspricht, eine Verbindung herzustellen. Außerdem veröffentlicht sie zu jedem Thema, dem der Dingname vorangestellt ist. Die Richtlinie ist abhängig davon, dass das Gerät eine Verbindung zu einem VPC-Endpunkt mit einer bestimmten VPC-Endpunkt-ID herstellt. Diese Richtlinie verweigert Verbindungsversuche zu Ihrem öffentlichen AWS IoT Core Device Advisor -Testendpunkt.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot:Connect"
],
"Resource": [
"arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1a2b3c4d"
}
}
},
{
"Effect": "Allow",
"Action": [
"iot:Publish"
],
"Resource": [
"arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}/*"
]
}
]
}
```
# Device-Advisor-Testfälle
Device Advisor bietet vorgefertigte Tests in sechs Kategorien.
+ [TLS](device-advisor-tests-tls.md)
+ [MQTT](device-advisor-tests-mqtt.md)
+ [Shadow](device-advisor-tests-shadow.md)
+ [Auftragsausführung](device-advisor-tests-job-execution.md)
+ [Berechtigungen und Richtlinien](device-advisor-tests-permissions-policies.md)
+ [Tests mit langer Dauer](device-advisor-tests-long-duration.md)
## Device Advisor-Testfälle, um sich für das AWS Gerätequalifizierungsprogramm zu qualifizieren.
Ihr Gerät muss die folgenden Tests bestehen, um sich gemäß dem [AWS -Gerätequalifizierungsprogramm](https://aws.amazon.com/partners/programs/dqp/) zu qualifizieren.
**Anmerkung**
Dies ist eine überarbeitete Liste der Qualifizierungstests.
+ [TLS Connect](device-advisor-tests-tls.md#TLS_Connect) („TLS Connect“)
+ [TLS Incorrect Subject Name Server Cert](device-advisor-tests-tls.md#TLS_Incorrect_Subject_Name) („Incorrect Subject Common Name (CN)/Subject Alternative Name (SAN)“)
+ [TLS Unsecure Server Cert](device-advisor-tests-tls.md#TLS_Unsecure_Server_Cert) („Not Signed By Recognized CA“)
+ [TLS-Geräteunterstützung für AWS IoT Cipher Suites](device-advisor-tests-tls.md#TLS_DeviceSupport_For_IOT) („TLS-Geräteunterstützung für AWS IoT empfohlene Cipher Suites“)
+ [TLS Receive Maximum Size Fragments](device-advisor-tests-tls.md#TLS_MaximumSize)(„TLS Receive Maximum Size Fragments“)
+ [TLS Expired Server Cert](device-advisor-tests-tls.md#TLS_Expired_Server_Cert)(„Expired server certificate“)
+ [TLS Large Size Server Cert](device-advisor-tests-tls.md#TLS_LargeServerCert)(„TLS large Size Server Certificate“)
+ [MQTT Connect](device-advisor-tests-mqtt.md#MQTT_Connect) („Gerät sendet CONNECT an AWS IoT Core (Happy Case)“)
+ [MQTT Subscribe](device-advisor-tests-mqtt.md#MQTT_Subscribe) („Can Subscribe (Happy Case)“)
+ [MQTT Publish](device-advisor-tests-mqtt.md#MQTT_Publish) („QoS0 (Happy Case)“)
+ [MQTT Connect Jitter Retries](device-advisor-tests-mqtt.md#MQTT_ConnectJitterBackoff)(„Device connect retries with jitter backoff - No CONNACK response“)
# TLS
Verwenden Sie diese Tests, um festzustellen, ob das Transport Layer Security Protocol (TLS) zwischen Ihren Geräten sicher AWS IoT ist.
**Anmerkung**
Device Advisor unterstützt jetzt TLS 1.3.
## Happy Path
**TLS Connect**
Überprüft, ob das zu testende Gerät den TLS-Handshake abschließen kann. AWS IoT Dieser Test validiert nicht die MQTT-Implementierung des Client-Geräts.
**Example Definition des API-Testfalls:**
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Für optimale Ergebnisse empfehlen wir einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_tls_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Connect",
"version":"0.0.0"
}
}
]
```
**Example Ergebnisse des Testfalls:**
+ **Bestanden** — Das zu testende Gerät hat den TLS-Handshake mit abgeschlossen. AWS IoT
+ **Mit Warnungen bestanden** — Das getestete Gerät hat den TLS-Handshake mit abgeschlossen AWS IoT, aber es gab TLS-Warnmeldungen vom Gerät oder. AWS IoT
+ **Fehlgeschlagen** — Das getestete Gerät konnte den TLS-Handshake AWS IoT aufgrund eines Handshake-Fehlers nicht abschließen.
**TLS empfängt Fragmente mit maximaler Größe**
Dieser Testfall bestätigt, dass Ihr Gerät TLS-Fragmente mit maximaler Größe empfangen und verarbeiten kann. Ihr Testgerät muss ein vorkonfiguriertes Thema mit QoS 1 abonnieren, um eine große Nutzlast zu empfangen. Sie können die Nutzlast mit der Konfiguration `${payload}` anpassen.
**Example Definition des API-Testfalls:**
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Für optimale Ergebnisse empfehlen wir einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"TLS Receive Maximum Size Fragments",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
"PAYLOAD_FORMAT":"{"message":"${payload}"}", // A string with a placeholder ${payload}, or leave it empty to receive a plain string.
"TRIGGER_TOPIC": "test_1" // A topic to which a device will subscribe, and to which a test case will publish a large payload.
},
"test":{
"id":"TLS_Receive_Maximum_Size_Fragments",
"version":"0.0.0"
}
}
]
```
## Cipher Suites
**TLS-Geräteunterstützung für AWS IoT empfohlene Cipher Suites**
Überprüft, ob die Cipher Suites in der TLS-Client-Hello-Nachricht des getesteten Geräts die empfohlenen [AWS IoT -Cipher-Suites](transport-security.md) enthalten. Es bietet mehr Einblicke in die vom Gerät unterstützten Verschlüsselungssammlungen.
**Example Definition des API-Testfalls:**
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_tls_support_aws_iot_cipher_suites_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Support_AWS_IoT_Cipher_Suites",
"version":"0.0.0"
}
}
]
```
**Example Ergebnisse des Testfalls:**
+ **Bestanden** — Das zu testende Gerät enthält mindestens eine der empfohlenen Verschlüsselungssammlungen und keine AWS IoT Verschlüsselungssammlungen, die nicht unterstützt werden.
+ **Pass with warnings** (Mit Warnungen bestanden): Die Cipher Suites des Geräts enthalten mindestens eine AWS IoT -Cipher-Suite, aber:
1. sie enthält keine der empfohlenen Cipher Suites.
1. Es enthält Verschlüsselungssammlungen, die von nicht unterstützt werden. AWS IoT
Wir empfehlen Ihnen, zu überprüfen, ob alle nicht unterstützten Cipher Suites sicher sind.
+ **Fehlgeschlagen** — Das zu testende Gerät enthält keine der unterstützten Verschlüsselungssammlungen. AWS IoT
## Größeres Serverzertifikat
**Großes TLS-Serverzertifikat**
Wird auf Ihrem Gerät validiert und kann den TLS-Handshake mit AWS IoT abschließen, wenn es ein größeres Serverzertifikat empfängt und verarbeitet. Die Größe des von diesem Test verwendeten Serverzertifikats (in Byte) ist um 20 größer als die, die derzeit im **TLS Connect-Testfall** und in IoT Core verwendet wird. In diesem Testfall wird der Pufferspeicher Ihres Geräts auf TLS getestet. Wenn der Pufferspeicher groß genug ist, wird der TLS-Handshake ohne Fehler abgeschlossen. AWS IoT Dieser Test validiert nicht die MQTT-Implementierung des Geräts. Der Testfall tritt auf, nachdem der TLS-Handshake-Vorgang abgeschlossen ist.
**Example Definition des API-Testfalls:**
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Für optimale Ergebnisse empfehlen wir einen Timeout-Wert von 2 Minuten. Wenn dieser Testfall fehlschlägt, der **TLS Connect**-Testfall jedoch erfolgreich ist, empfehlen wir Ihnen, das Pufferspeicherlimit Ihres Geräts für TLS zu erhöhen. Durch die Erhöhung des Pufferspeicherlimits wird sichergestellt, dass Ihr Gerät ein größeres Serverzertifikat verarbeiten kann, falls die Größe zunimmt.
```
"tests":[
{
"name":"my_tls_large_size_server_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Large_Size_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Ergebnisse des Testfalls:**
+ **Pass** (Bestanden): Das getestete Gerät hat den TLS-Handshake mit AWS IoT abgeschlossen.
+ **Mit Warnungen bestanden** — Das getestete Gerät hat den TLS-Handshake abgeschlossen AWS IoT, aber es gibt TLS-Warnmeldungen entweder vom Gerät oder. AWS IoT
+ **Fehlgeschlagen** — Das getestete Gerät konnte den TLS-Handshake AWS IoT aufgrund eines Fehlers während des Handshake-Vorgangs nicht abschließen.
## Zertifikat für unsicheren TLS-Server
**Nicht von einer anerkannten Zertifizierungsstelle signiert**
Überprüft, ob das getestete Gerät die Verbindung schließt, wenn ihm ein Serverzertifikat ohne gültige Signatur der ATS-Zertifizierungsstelle vorgelegt wird. Ein Gerät sollte nur eine Verbindung zu einem Endpunkt herstellen, der ein gültiges Zertifikat vorlegt.
**Example Definition des API-Testfalls:**
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_tls_unsecure_server_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Unsecure_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Ergebnisse des Testfalls:**
+ **Pass** (Bestanden): Das getestete Gerät hat die Verbindung geschlossen.
+ **Fehlgeschlagen** — Das getestete Gerät hat den TLS-Handshake mit abgeschlossen. AWS IoT
**TLS Incorrect Subject Name Server Cert/Incorrect Subject Common Name (CN)/Subject Alternative Name (SAN)**
Überprüft, ob das getestete Gerät die Verbindung schließt, wenn ihm ein Serverzertifikat für einen anderen Domainnamen als den angeforderten vorgelegt wird.
**Example Definition des API-Testfalls:**
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_tls_incorrect_subject_name_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Incorrect_Subject_Name_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Ergebnisse des Testfalls:**
+ **Pass** (Bestanden): Das getestete Gerät hat die Verbindung geschlossen.
+ **Fehlgeschlagen** — Das zu testende Gerät hat den TLS-Handshake mit abgeschlossen. AWS IoT
## TLS-Serverzertifikat ist abgelaufen
**Abgelaufenes Serverzertifikat**
Überprüft, ob das getestete Gerät die Verbindung schließt, wenn ihm ein abgelaufenes Serverzertifikat vorgelegt wird.
**Example Definition des API-Testfalls:**
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_tls_expired_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Expired_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Ergebnisse des Testfalls:**
+ **Bestanden** — Das zu testende Gerät weigert sich, den TLS-Handshake mit abzuschließen. AWS IoT Das Gerät sendet eine TLS-Warnmeldung, bevor es die Verbindung schließt.
+ **Pass with warnings** (Bestanden mit Warnungen): Das getestete Gerät weigert sich, den TLS-Handshake mit AWS IoT abzuschließen. Es sendet jedoch keine TLS-Warnmeldung, bevor die Verbindung geschlossen wird.
+ **Fehlgeschlagen** — Das zu testende Gerät schließt den TLS-Handshake mit ab. AWS IoT
# MQTT
## CONNECT, DISCONNECT und RECONNECT
**„Gerät sendet CONNECT an AWS IoT Core (Happy Case)“**
Überprüft, ob das getestete Gerät eine CONNECT-Anfrage sendet.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_mqtt_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Connect",
"version":"0.0.0"
}
}
]
```
**„Device can return PUBACK to an arbitrary topic for QoS1“**
In diesem Testfall wird geprüft, ob das Gerät (Client) eine PUBACK-Nachricht zurückgeben kann, wenn es nach dem Abonnieren eines Themas mit QoS1 eine Veröffentlichungsnachricht vom Broker erhalten hat.
Der Inhalt der Nutzlast und die Größe der Nutzlast sind für diesen Testfall konfigurierbar. Wenn die Nutzlastgröße konfiguriert ist, überschreibt Device Advisor den Wert für den Nutzlastinhalt und sendet eine vordefinierte Nutzlast mit der gewünschten Größe an das Gerät. Die Nutzlastgröße ist ein Wert zwischen 0 und 128 und darf 128 KB nicht überschreiten. AWS IoT Core lehnt Veröffentlichungs- und Verbindungsanfragen ab, die größer als 128 KB sind, wie auf der Seite [Grenzwerte und Kontingente für AWS IoT Core -Message-Broker und -Protokolle](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits) beschrieben.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten. `PAYLOAD_SIZE` kann auf einen Wert zwischen 0 und 128 Kilobyte konfiguriert werden. Die Definition einer Nutzlastgröße hat Vorrang vor dem Nutzlastinhalt, da Device Advisor eine vordefinierte Nutzlast mit der angegebenen Größe zurück an das Gerät sendet.
```
"tests":[
{
"name":"my_mqtt_client_puback_qos1",
"configuration": {
// optional:"TRIGGER_TOPIC": "myTopic",
"EXECUTION_TIMEOUT":"300", // in seconds
"PAYLOAD_FOR_PUBLISH_VALIDATION":"custom payload",
"PAYLOAD_SIZE":"100" // in kilobytes
},
"test": {
"id": "MQTT_Client_Puback_QoS1",
"version": "0.0.0"
}
}
]
```
**„Device connect retries with jitter backoff - No CONNACK response“**
Überprüft, ob das getestete Gerät den richtigen Jitter-Backoff verwendet, wenn es mindestens fünfmal erneut eine Verbindung zum Broker herstellt. Der Broker protokolliert den Zeitstempel der CONNECT-Anfrage des getesteten Geräts, führt eine Paketvalidierung durch, pausiert, ohne einen CONNACK an das getestete Gerät zu senden, und wartet, bis das getestete Gerät die Anfrage erneut sendet. Der sechste Verbindungsversuch darf übergeben werden und CONNACK darf zurück zum getesteten Gerät fließen.
Der vorherige Vorgang wird erneut ausgeführt. Insgesamt erfordert dieser Testfall, dass das Gerät insgesamt mindestens 12 Mal eine Verbindung herstellt. Die gesammelten Zeitstempel werden verwendet, um zu überprüfen, ob das getestete Gerät den Jitter-Backoff verwendet. Wenn das getestete Gerät eine streng exponentielle Backoff-Verzögerung aufweist, wird dieser Testfall mit Warnungen bestanden.
Wir empfehlen, den Mechanismus [Exponential Backoff And Jitter](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren, um diesen Testfall zu bestehen.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.
```
"tests":[
{
"name":"my_mqtt_jitter_backoff_retries_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Connect_Jitter_Backoff_Retries",
"version":"0.0.0"
}
}
]
```
**„Device connect retries with exponential backoff - No CONNACK response“**
Überprüft, ob das getestete Gerät das richtige exponentielle Backoff verwendet, wenn es mindestens fünfmal erneut eine Verbindung zum Broker herstellt. Der Broker protokolliert den Zeitstempel der CONNECT-Anfrage des getesteten Geräts, führt eine Paketvalidierung durch, pausiert, ohne einen CONNACK an das Client-Gerät zu senden, und wartet, bis das getestete Gerät die Anfrage erneut sendet. Die gesammelten Zeitstempel werden verwendet, um zu überprüfen, ob das getestete Gerät ein exponentielles Backoff verwendet.
Wir empfehlen, den Mechanismus [Exponential Backoff And Jitter](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren, um diesen Testfall zu bestehen.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.
```
"tests":[
{
"name":"my_mqtt_exponential_backoff_retries_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"600", // in seconds
},
"test":{
"id":"MQTT_Connect_Exponential_Backoff_Retries",
"version":"0.0.0"
}
}
]
```
**„Device re-connect with jitter backoff - After server disconnect“**
Überprüft, ob ein getestetes Gerät bei der Wiederherstellung der Verbindung, nachdem es vom Server getrennt wurde, die erforderlichen Jitter- und Backoff-Werte verwendet. Device Advisor trennt das Gerät mindestens fünfmal vom Server und beobachtet das Verhalten des Geräts bei der Wiederherstellung der Verbindung mit MQTT. Der Broker protokolliert den Zeitstempel der CONNECT-Anfrage des getesteten Geräts, führt eine Paketvalidierung durch, pausiert, ohne einen CONNACK an das Client-Gerät zu senden, und wartet, bis das getestete Gerät die Anfrage erneut sendet. Die gesammelten Zeitstempel werden verwendet, um zu überprüfen, ob das getestete Gerät den Jitter-Backoff verwendet. Wenn das getestete Gerät eine streng exponentielle Backoff-Verzögerung aufweist oder keinen ordnungsgemäßen Jitter-Backoff-Mechanismus implementiert, wird dieser Testfall mit Warnungen bestanden. Wenn das getestete Gerät entweder einen linearen Backoff-Mechanismus oder einen konstanten Backoff-Mechanismus implementiert hat, schlägt der Test fehl.
Damit dieser Testfall bestanden wird, empfehlen wir, den Mechanismus [Exponential Backoff And Jitter](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.
Die Anzahl der Wiederverbindungsversuche zur Überprüfung des Backoffs kann durch Angabe der `RECONNECTION_ATTEMPTS` geändert werden. Die Zahl muss zwischen 5 und 10 liegen. Der Standardwert ist 5.
```
"tests":[
{
"name":"my_mqtt_reconnect_backoff_retries_on_server_disconnect",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"RECONNECTION_ATTEMPTS": 5
},
"test":{
"id":"MQTT_Reconnect_Backoff_Retries_On_Server_Disconnect",
"version":"0.0.0"
}
}
]
```
**„Device re-connect with jitter backoff - On unstable connection“**
Überprüft, ob ein getestetes Gerät beim erneuten Herstellen der Verbindung über eine instabile Verbindung die erforderlichen Jitter- und Backoff-Werte verwendet. Device Advisor trennt das Gerät nach fünf erfolgreichen Verbindungen vom Server und beobachtet das Verhalten des Geräts bei der Wiederherstellung der Verbindung mit MQTT. Der Broker protokolliert den Zeitstempel der CONNECT-Anfrage des getesteten Geräts, führt eine Paketvalidierung durch, sendet CONNACK zurück, trennt die Verbindung, protokolliert den Zeitstempel der getrennten Verbindung und wartet, bis das getestete Gerät die Anfrage erneut sendet. Die gesammelten Zeitstempel werden verwendet, um zu überprüfen, ob das getestete Gerät Jitter und Backoff verwendet, während es nach erfolgreichen, aber instabilen Verbindungen erneut eine Verbindung herstellt. Wenn das getestete Gerät eine streng exponentielle Backoff-Verzögerung aufweist oder keinen ordnungsgemäßen Jitter-Backoff-Mechanismus implementiert, wird dieser Testfall mit Warnungen bestanden. Wenn das getestete Gerät entweder einen linearen Backoff-Mechanismus oder einen konstanten Backoff-Mechanismus implementiert hat, schlägt der Test fehl.
Damit dieser Testfall bestanden wird, empfehlen wir, den Mechanismus [Exponential Backoff And Jitter](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.
Die Anzahl der Wiederverbindungsversuche zur Überprüfung des Backoffs kann durch Angabe der `RECONNECTION_ATTEMPTS` geändert werden. Die Zahl muss zwischen 5 und 10 liegen. Der Standardwert ist 5.
```
"tests":[
{
"name":"my_mqtt_reconnect_backoff_retries_on_unstable_connection",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"RECONNECTION_ATTEMPTS": 5
},
"test":{
"id":"MQTT_Reconnect_Backoff_Retries_On_Unstable_Connection",
"version":"0.0.0"
}
}
]
```
## Veröffentlichen
**„QoS0 (Happy Case)“**
Überprüft, ob das getestete Gerät eine Nachricht mit QoS0 oder QoS1 veröffentlicht. Sie können auch das Thema der Nachricht und die Nutzlast überprüfen, indem Sie den Themenwert und die Nutzlast in den Testeinstellungen angeben.
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_mqtt_publish_test",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
"PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
},
"test":{
"id":"MQTT_Publish",
"version":"0.0.0"
}
}
]
```
**„QoS1 publish retry - No PUBACK“**
Überprüft, ob das getestete Gerät eine mit QoS1 gesendete Nachricht erneut veröffentlicht, falls der Broker PUBACK nicht sendet. Sie können auch das Thema der Nachricht überprüfen, indem Sie dieses Thema in den Testeinstellungen angeben. Das Client-Gerät darf die Verbindung nicht trennen, bevor die Nachricht erneut veröffentlicht wird. Mit diesem Test wird auch überprüft, ob die erneut veröffentlichte Nachricht dieselbe Paket-ID wie das Original hat. Wenn das Gerät während der Testausführung die Verbindung verliert und die Verbindung wiederherstellt, wird der Testfall ohne Fehler zurückgesetzt und das Gerät muss die Testfallschritte erneut ausführen.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Es wird eine Dauer von mindestens 4 Minuten empfohlen.
```
"tests":[
{
"name":"my_mqtt_publish_retry_test",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
"PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
},
"test":{
"id":"MQTT_Publish_Retry_No_Puback",
"version":"0.0.0"
}
}
]
```
**„Publish Retained messages“**
Überprüft, ob das getestete Gerät eine Nachricht veröffentlicht, bei der `retainFlag` auf „true“ gesetzt ist. Sie können das Thema der Nachricht und die Nutzlast überprüfen, indem Sie den Themenwert und die Nutzlast in den Testeinstellungen angeben. Wenn die `retainFlag`, die im PUBLISH-Paket gesendet wurde, nicht auf „true“ gesetzt ist, schlägt der Testfall fehl.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten. Um diesen Testfall auszuführen, fügen Sie die `iot:RetainPublish`-Aktion zu Ihrer [Geräterolle](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role) hinzu.
```
"tests":[
{
"name":"my_mqtt_publish_retained_messages_test",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"TOPIC_FOR_PUBLISH_RETAINED_VALIDATION": "my_TOPIC_FOR_PUBLISH_RETAINED_VALIDATION",
"PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION",
},
"test":{
"id":"MQTT_Publish_Retained_Messages",
"version":"0.0.0"
}
}
]
```
**„Publish with User Property“**
Überprüft, ob das getestete Gerät eine Nachricht mit der korrekten Benutzereigenschaft veröffentlicht. Sie können die Benutzereigenschaft überprüfen, indem Sie das Name-Wert-Paar in den Testeinstellungen festlegen. Wenn die Benutzereigenschaft nicht bereitgestellt wird oder nicht übereinstimmt, schlägt der Testfall fehl.
*Definition des API-Testfalls:*
Dies ist ein einziger Testfall MQTT5 .
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_mqtt_user_property_test",
"test":{
"USER_PROPERTIES": [
{"name": "name1", "value":"value1"},
{"name": "name2", "value":"value2"}
],
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Publish_User_Property",
"version":"0.0.0"
}
}
]
```
## Abonnieren
**„Can Subscribe (Happy Case)“**
Überprüft, ob das getestete Gerät MQTT-Themen abonniert hat. Sie können auch das Thema überprüfen, das das getestete Gerät abonniert, indem Sie dieses Thema in den Testeinstellungen angeben.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_mqtt_subscribe_test",
"configuration":{
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["my_TOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
},
"test":{
"id":"MQTT_Subscribe",
"version":"0.0.0"
}
}
]
```
**„Subscribe Retry - No SUBACK“**
Überprüft, ob das getestete Gerät ein fehlgeschlagenes Abonnement von MQTT-Themen erneut versucht. Der Server wartet dann und sendet kein SUBACK. Wenn das Client-Gerät das Abonnement nicht erneut versucht, schlägt der Test fehl. Das Client-Gerät muss das fehlgeschlagene Abonnement mit derselben Paket-ID erneut versuchen. Sie können auch das Thema überprüfen, das das getestete Gerät abonniert, indem Sie dieses Thema in den Testeinstellungen angeben. Wenn das Gerät während der Testausführung die Verbindung verliert und die Verbindung wiederherstellt, wird der Testfall ohne Fehler zurückgesetzt und das Gerät muss die Testfallschritte erneut ausführen.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 4 Minuten.
```
"tests":[
{
"name":"my_mqtt_subscribe_retry_test",
"configuration":{
"EXECUTION_TIMEOUT":"300", // in seconds
// optional:
"TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["myTOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
},
"test":{
"id":"MQTT_Subscribe_Retry_No_Suback",
"version":"0.0.0"
}
}
]
```
## Keep-Alive
**„Matt No Ack“ PingResp**
Dieser Testfall überprüft, ob das getestete Gerät die Verbindung trennt, wenn es keine Ping-Antwort erhält. Im Rahmen dieses Testfalls blockiert Device Advisor Antworten von AWS IoT Core Veröffentlichungs-, Abonnement- und Ping-Anfragen. Es überprüft auch, ob das getestete Gerät die MQTT-Verbindung unterbricht.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen ein Timeout, das mehr als das 1,5-fache des `keepAliveTime`-Werts beträgt.
Die maximale `keepAliveTime` darf für diesen Test nicht länger als 230 Sekunden betragen.
```
"tests":[
{
"name":"Mqtt No Ack PingResp",
"configuration":
//optional:
"EXECUTION_TIMEOUT":"306", // in seconds
},
"test":{
"id":"MQTT_No_Ack_PingResp",
"version":"0.0.0"
}
}
]
```
## Persistente Sitzung
**„Persistent Session (Happy Case)“**
Dieser Testfall validiert das Geräteverhalten, wenn die Verbindung zu einer persistenten Sitzung getrennt wird. Der Testfall prüft, ob das Gerät erneut eine Verbindung herstellen kann, die Abonnements für seine Trigger-Themen fortsetzen kann, ohne sich explizit erneut anzumelden, die in den Themen gespeicherten Nachrichten empfangen kann und während einer persistenten Sitzung erwartungsgemäß funktionieren kann. Wenn dieser Testfall erfolgreich ist, bedeutet dies, dass das Client-Gerät in der Lage ist, eine dauerhafte Sitzung mit dem AWS IoT Core Broker wie erwartet aufrechtzuerhalten. Weitere Informationen zu AWS IoT persistenten Sitzungen finden Sie unter [Verwenden persistenter MQTT-Sitzungen](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
In diesem Testfall wird erwartet, dass das Client-Gerät ein CONNECT mit dem AWS IoT Core mit einem Sitzungs-Flag auf „false“ gesetzt durchführt und dann ein Trigger-Thema abonniert. Nach einem erfolgreichen Abonnement wird das Gerät von AWS IoT Core Device Advisor getrennt. Solange sich das Gerät in einem getrennten Zustand befindet, wird eine QoS 1-Nachrichtennutzlast in diesem Thema gespeichert. Device Advisor ermöglicht dem Client-Gerät dann, erneut eine Verbindung mit dem Testendpunkt herzustellen. Da zu diesem Zeitpunkt eine persistente Sitzung besteht, wird erwartet, dass das Client-Gerät seine Themenabonnements wieder aufnimmt, ohne zusätzliche SUBSCRIBE-Pakete zu senden und die QoS 1-Nachricht vom Broker zu empfangen. Wenn das Client-Gerät nach der erneuten Verbindung sein Trigger-Thema erneut abonniert, indem es ein zusätzliches SUBSCRIBE-Paket and/or sendet und der Client die gespeicherte Nachricht vom Trigger-Thema nicht empfängt, schlägt der Testfall fehl.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von mindestens 4 Minuten. Bei der ersten Verbindung muss das Client-Gerät explizit ein `TRIGGER_TOPIC` abonnieren, die zuvor nicht abonniert wurde. Um den Testfall zu bestehen, muss das Client-Gerät erfolgreich `TRIGGER_TOPIC` mit einer QoS 1 abonnieren. Nach dem erneuten Herstellen der Verbindung wird erwartet, dass das Client-Gerät erkennt, dass eine aktive persistente Sitzung besteht. Daher sollte es die vom Trigger-Thema gesendete gespeicherte Nachricht akzeptieren und PUBACK für diese spezifische Nachricht zurückgeben.
```
"tests":[
{
"name":"my_mqtt_persistent_session_happy_case",
"configuration":{
//required:
"TRIGGER_TOPIC": "myTrigger/topic",
// optional:
// if Payload not provided, a string will be stored in the trigger topic to be sent back to the client device
"PAYLOAD": "The message which should be received from AWS IoT Broker after re-connecting to a persistent session from the specified trigger topic.",
"EXECUTION_TIMEOUT":"300" // in seconds
},
"test":{
"id":"MQTT_Persistent_Session_Happy_Case",
"version":"0.0.0"
}
}
]
```
**„Persistent Session - Session Expiry“**
Dieser Testfall hilft bei der Überprüfung des Geräteverhaltens, wenn ein getrenntes Gerät erneut eine Verbindung zu einer abgelaufenen persistenten Sitzung herstellt. Nach Ablauf der Sitzung erwarten wir, dass das Gerät die zuvor abonnierten Themen erneut abonniert, indem es explizit ein neues SUBSCRIBE-Paket sendet.
Während der ersten Verbindung erwarten wir, dass sich das Testgerät mit dem AWS IoT-Broker VERBINDET, da sein `CleanSession` Flag auf False gesetzt ist, um eine persistente Sitzung zu initiieren. Das Gerät sollte dann ein Trigger-Thema abonnieren. Dann wird das Gerät nach einem erfolgreichen Abonnement und der Initiierung einer dauerhaften Sitzung von AWS IoT Core Device Advisor getrennt. Nach dem Trennen der Verbindung ermöglicht AWS IoT Core Device Advisor dem Testgerät, sich wieder mit dem Testendpunkt zu verbinden. Wenn das Testgerät zu diesem Zeitpunkt ein weiteres CONNECT-Paket sendet, sendet AWS IoT Core Device Advisor ein CONNACK-Paket zurück, das angibt, dass die persistente Sitzung abgelaufen ist. Das Testgerät muss dieses Paket richtig interpretieren und es wird erwartet, dass es dasselbe Trigger-Thema erneut abonniert, wenn die persistente Sitzung beendet wird. Wenn das Testgerät seinen Themen-Trigger nicht erneut abonniert, schlägt der Testfall fehl. Damit der Test erfolgreich ist, muss das Gerät verstehen, dass die persistente Sitzung beendet ist, und in der zweiten Verbindung ein neues SUBSCRIBE-Paket für dasselbe Trigger-Thema zurücksenden.
Wenn dieser Testfall für ein Testgerät erfolgreich ist, bedeutet dies, dass das Gerät in der Lage ist, die erneute Verbindung nach Ablauf der persistenten Sitzung erwartungsgemäß zu handhaben.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von mindestens 4 Minuten. Das Testgerät muss explizit ein `TRIGGER_TOPIC` abonnieren, das es zuvor nicht abonniert hatte. Um den Testfall zu bestehen, muss das Testgerät ein CONNECT-Paket mit einem auf „false“ gesetzten `CleanSession`-Flag senden und erfolgreich ein Trigger-Thema mit QoS 1 abonnieren. Nach einer erfolgreichen Verbindung trennt AWS IoT Core Device Advisor die Verbindung zum Gerät. Nach dem Trennen der Verbindung ermöglicht AWS IoT Core Device Advisor dem Gerät, wieder eine Verbindung herzustellen, und es wird erwartet, dass das Gerät dieselbe erneut abonniert, `TRIGGER_TOPIC` da AWS IoT Core Device Advisor die persistente Sitzung beendet hätte.
```
"tests":[
{
"name":"my_expired_persistent_session_test",
"configuration":{
//required:
"TRIGGER_TOPIC": "myTrigger/topic",
// optional:
"EXECUTION_TIMEOUT":"300" // in seconds
},
"test":{
"id":"MQTT_Expired_Persistent_Session",
"version":"0.0.0"
}
}
]
```
# Shadow
Verwenden Sie diese Tests, um zu überprüfen, ob Ihre getesteten Geräte den AWS IoT Device Shadow-Dienst korrekt verwenden. Weitere Informationen finden Sie unter [AWS IoT Device Shadow-Dienst](iot-device-shadows.md). Wenn diese Testfälle in Ihrer Testsuite konfiguriert sind, müssen Sie beim Start der Suite-Ausführung etwas angeben.
** WebSocketMQTT-Over** wird derzeit nicht unterstützt.
## Veröffentlichen
***„Device publishes state after it connects (Happy case)“***
Überprüft, ob ein Gerät seinen Status veröffentlichen kann, nachdem es eine Verbindung hergestellt hat AWS IoT Core
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_shadow_publish_reported_state",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"SHADOW_NAME": "SHADOW_NAME",
"REPORTED_STATE": {
"STATE_ATTRIBUTE": "STATE_VALUE"
}
},
"test":{
"id":"Shadow_Publish_Reported_State",
"version":"0.0.0"
}
}
]
```
Der `REPORTED_STATE` kann für eine zusätzliche Überprüfung des exakten Shadow-Status Ihres Geräts bereitgestellt werden, nachdem es eine Verbindung hergestellt hat. Standardmäßig überprüft dieser Testfall den Veröffentlichungsstatus Ihres Geräts.
Falls `SHADOW_NAME` nicht angegeben, sucht der Testfall standardmäßig nach Nachrichten, die mit Themenpräfixen des Shadow-Typs Unbenannt (klassisch) veröffentlicht wurden. Geben Sie einen Shadow-Namen an, wenn Ihr Gerät den benannten Shadow-Typ verwendet. Weitere Informationen finden Sie unter [Verwenden von Shadows in Geräten](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html).
## Aktualisierung
***„Device updates reported state to desired state (Happy case)“***
Überprüft, ob Ihr Gerät alle empfangenen Aktualisierungsnachrichten liest, und synchronisiert den Status des Geräts so, dass er mit den gewünschten Statuseigenschaften übereinstimmt. Ihr Gerät sollte nach der Synchronisierung den zuletzt gemeldeten Status veröffentlichen. Wenn auf Ihrem Gerät bereits ein Shadow vorhanden ist, bevor Sie den Test ausführen, stellen Sie sicher, dass der für den Testfall konfigurierte gewünschte Status und der vorhandene gemeldete Status nicht bereits übereinstimmen. Sie können die vom Device Advisor gesendeten Shadow-Aktualisierungsnachrichten anhand des **ClientToken**Felds im Shadow-Dokument erkennen, wie es sein `DeviceAdvisorShadowTestCaseSetup` wird.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 2 Minuten.
```
"tests":[
{
"name":"my_shadow_update_reported_state",
"configuration": {
"DESIRED_STATE": {
"STATE_ATTRIBUTE": "STATE_VALUE"
},
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"SHADOW_NAME": "SHADOW_NAME"
},
"test":{
"id":"Shadow_Update_Reported_State",
"version":"0.0.0"
}
}
]
```
Der `DESIRED_STATE` sollte mindestens ein Attribut und einen zugehörigen Wert haben.
Falls `SHADOW_NAME` nicht angegeben, sucht der Testfall standardmäßig nach Nachrichten, die mit Themenpräfixen des Shadow-Typs Unbenannt (klassisch) veröffentlicht wurden. Geben Sie einen Shadow-Namen an, wenn Ihr Gerät den benannten Shadow-Typ verwendet. Weitere Informationen finden Sie unter [Verwenden von Shadows in Geräten](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html).
# Auftragsausführung
**„Device can complete a job execution“**
Mit diesem Testfall können Sie mithilfe von AWS IoT Jobs überprüfen, ob Ihr Gerät Updates empfangen kann, und den Status erfolgreicher Updates veröffentlichen. Weitere Informationen zu AWS IoT Jobs finden Sie unter [Jobs](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
Um diesen Testfall erfolgreich ausführen zu können, gibt es zwei reservierte AWS Themen, denen Sie Ihre [Geräterolle](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role) zuweisen müssen. Verwenden Sie die Themen **notify** und **notify-next**, um Nachrichten zu Auftragsaktivitäten zu abonnieren. Ihre Geräterolle muss die Aktion PUBLISH für die folgenden Themen gewähren:
+ \$1aws/things/**thingName**/jobs/**jobId**/get
+ \$1aws/things/**thingName**/jobs/**jobId**/update
Es wird empfohlen, die Aktionen SUBSCRIBE und RECEIVE für die folgenden Themen zu gewähren:
+ **\$1aws/things/ thingName/**jobs/get/accepted
+ \$1aws/things/**thingName**/jobs/**jobId**/get/rejected
+ \$1aws/things/**thingName**/jobs/**jobId**/update/accepted
+ \$1aws/things/**thingName**/jobs/**jobId**/update/rejected
Es wird empfohlen, die Aktionen SUBSCRIBE für die folgenden Themen zu gewähren:
+ \$1aws/things/**thingName**/jobs/notify-next
Weitere Informationen zu diesen reservierten Themen finden Sie unter Reservierte Themen für [AWS IoT -Aufträge](https://docs.aws.amazon.com/iot/latest/developerguide/reserved-topics.html#reserved-topics-job).
**MQTT-Over WebSocket** wird derzeit nicht unterstützt.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 5 Minuten. Wir empfehlen einen Timeout-Wert von 3 Minuten. Passen Sie je nach dem bereitgestellten AWS IoT Jobdokument oder der angegebenen Quelle den Timeout-Wert an (wenn die Ausführung eines Jobs beispielsweise lange dauert, definieren Sie einen längeren Timeout-Wert für den Testfall). Um den Test auszuführen, ist entweder ein gültiges AWS IoT Jobdokument oder eine bereits vorhandene Job-ID erforderlich. Ein AWS IoT Job-Dokument kann als JSON-Dokument oder als S3-Link bereitgestellt werden. Wenn ein Auftragsdokument bereitgestellt wird, ist die Angabe einer Auftrags-ID optional. Wenn eine Job-ID angegeben wird, verwendet Device Advisor diese ID bei der Erstellung des AWS IoT Jobs in Ihrem Namen. Wenn das Auftragsdokument nicht bereitgestellt wird, können Sie eine vorhandene ID angeben, die sich in derselben Region befindet, in der Sie den Testfall ausführen. In diesem Fall verwendet Device Advisor diesen AWS IoT Job bei der Ausführung des Testfalls.
```
"tests": [
{
"name":"my_job_execution",
"configuration": {
// optional:
// Test case will create a job task by using either JOB_DOCUMENT or JOB_DOCUMENT_SOURCE.
// If you manage the job task on your own, leave it empty and provide the JOB_JOBID (self-managed job task).
// JOB_DOCUMENT is a JSON formatted string
"JOB_DOCUMENT": "{
\"operation\":\"reboot\",
\"files\" : {
\"fileName\" : \"install.py\",
\"url\" : \"${aws:iot:s3-presigned-url:https://s3.amazonaws.com/bucket-name/key}\"
}
}",
// JOB_DOCUMENT_SOURCE is an S3 link to the job document. It will be used only if JOB_DOCUMENT is not provided.
"JOB_DOCUMENT_SOURCE": "https://s3.amazonaws.com/bucket-name/key",
// JOB_JOBID is mandatory, only if neither document nor document source is provided. (Test case needs to know the self-managed job task id).
"JOB_JOBID": "String",
// JOB_PRESIGN_ROLE_ARN is used for the presign Url, which will replace the placeholder in the JOB_DOCUMENT field
"JOB_PRESIGN_ROLE_ARN": "String",
// Presigned Url expiration time. It must be between 60 and 3600 seconds, with the default value being 3600.
"JOB_PRESIGN_EXPIRES_IN_SEC": "Long"
"EXECUTION_TIMEOUT": "300", // in seconds
},
"test": {
"id": "Job_Execution",
"version": "0.0.0"
}
}
]
```
Weitere Informationen zum Erstellen und Verwenden von Auftragsdokumenten finden Sie im [Auftragsdokument](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
# Berechtigungen und Richtlinien
Mithilfe der folgenden Tests können Sie feststellen, ob die mit den Zertifikaten Ihrer Geräte verknüpften Richtlinien den bewährten Standardmethoden entsprechen.
** WebSocketMQTT-Over** wird derzeit nicht unterstützt.
**„Device certificate attached policies don’t contain wildcards“**
Überprüft, ob die mit einem Gerät verknüpften Berechtigungsrichtlinien bewährten Methoden entsprechen und dem Gerät nicht mehr Berechtigungen als erforderlich gewähren.
*Definition des API-Testfalls:*
`EXECUTION_TIMEOUT` hat einen Standardwert von 1 Minute. Wir empfehlen, ein Timeout von mindestens 30 Sekunden festzulegen.
```
"tests":[
{
"name":"my_security_device_policies",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"60" // in seconds
},
"test": {
"id": "Security_Device_Policies",
"version": "0.0.0"
}
}
]
```
# Tests mit langer Dauer
Tests mit langer Dauer sind eine neue Testsuite, die das Verhalten eines Geräts überwacht, wenn es über einen längeren Zeitraum betrieben wird. Im Vergleich zur Durchführung einzelner Tests, die sich auf bestimmte Verhaltensweisen eines Geräts konzentrieren, untersucht der Tests mit langer Dauer das Verhalten des Geräts in einer Vielzahl von realen Szenarien über die gesamte Lebensdauer des Geräts. Device Advisor orchestriert die Tests in der effizientesten Reihenfolge. Der Test generiert Ergebnisse und Protokolle, einschließlich eines Übersichtsprotokolls mit nützlichen Messwerten zur Leistung des Geräts während des Tests.
## MQTT-Testfall mit langer Dauer
Im MQTT-Testfall mit langer Dauer wird das Verhalten des Geräts zunächst in Happy Case-Szenarien wie MQTT Connect, Subscribe, Publish und Reconnect beobachtet. Anschließend wird das Gerät in mehreren komplexen Ausfallszenarien wie MQTT Reconnect Backoff, Long Server Disconnect und Intermittent Connectivity beobachtet.
## Ablauf der Ausführung von MQTT-Testfällen mit langer Dauer
Die Ausführung eines MQTT-Testfalls mit langer Dauer besteht aus drei Phasen:
![\[Die „MQTT-Testausführung mit langer Dauer“, die die Standardtestausführung, die Ausführung erweiterter Tests und die zusätzliche Ausführungszeit anzeigt.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/mqtt-execution-flow.png)
### Grundlegende Testausführung
In dieser Phase führt der Testfall einfache Tests parallel durch. Der Test überprüft, ob für das Gerät die in der Konfiguration ausgewählten Operationen ausgewählt wurden.
Die grundlegenden Tests können je nach den ausgewählten Vorgängen Folgendes umfassen:
#### CONNECT
In diesem Szenario wird überprüft, ob das Gerät eine erfolgreiche Verbindung mit dem Broker herstellen kann.
![\[Der grundlegende Verbindungsablauf, bei dem ein Gerät eine CONNECT-Nachricht sendet und der Broker mit einer CONNACK-Nachricht mit einem erfolgreichen Rückgabecode antwortet.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/basic-connect.png)
#### PUBLISH
In diesem Szenario wird überprüft, ob das Gerät erfolgreich beim Broker veröffentlicht.
##### QoS 0
Dieser Testfall überprüft, ob das Gerät während einer Veröffentlichung mit QoS 0 erfolgreich eine `PUBLISH`-Nachricht an den Broker sendet. Der Test wartet nicht darauf, dass die `PUBACK`-Nachricht vom Gerät empfangen wird.
![\[Der PUBLISH QoS 0-Flow, der beinhaltet, dass ein Gerät eine PUBLISH-Nachricht mit QoS 0-Stufe sendet.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/Qos0.png)
##### QoS 0
In diesem Testfall wird erwartet, dass das Gerät zwei `PUBLISH`-Nachrichten mit QoS 1 an den Broker sendet. Nach der ersten `PUBLISH`-Nachricht wartet der Broker bis zu 15 Sekunden, bevor er antwortet. Das Gerät muss innerhalb des 15-Sekunden-Fensters die ursprüngliche `PUBLISH`-Nachricht mit derselben Paket-ID erneut versuchen. Ist dies der Fall, antwortet der Broker mit einer `PUBACK`-Nachricht und der Test wird validiert. Wenn das Gerät den `PUBLISH`-Versuch nicht wiederholt, wird das Original-`PUBACK` an das Gerät gesendet und der Test wird als **Pass with warnings** (Mit Warnungen bestanden) markiert, zusammen mit einer Systemnachricht. Wenn das Gerät während der Testausführung die Verbindung verliert und die Verbindung wiederherstellt, wird der Testszenario ohne Fehler zurückgesetzt und das Gerät muss die Schritte des Testszenarios erneut ausführen.
![\[Der PUBLISH QoS 1-Flow, der ein Gerät umfasst, das eine PUBLISH-Nachricht mit QoS 1-Stufe sendet, und mehrere Interaktionen mit dem Broker.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/Qos1.png)
#### SUBSCRIBE
In diesem Szenario wird überprüft, ob das Gerät erfolgreich beim Broker abonniert.
##### QoS 0
Dieser Testfall überprüft, ob das Gerät während eines Abonnements mit QoS 0 erfolgreich eine `SUBSCRIBE`-Nachricht an den Broker sendet. Der Test wartet nicht, bis das Gerät eine SUBACK-Nachricht erhält.
![\[Der SUBSCRIBE QoS 0-Flow, der ein Gerät umfasst, das eine SUBSCRIBE-Nachricht mit der Stufe QoS 0 sendet, und einen Broker, der mit einer SUBACK-Nachricht und dem Code Success Maximum QoS 0 antwortet.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/subscribe-Qos0.png)
##### QoS 0
In diesem Testfall wird erwartet, dass das Gerät zwei `SUBSCRIBE`-Nachrichten mit QoS 1 an den Broker sendet. Nach der ersten `SUBSCRIBE`-Nachricht wartet der Broker bis zu 15 Sekunden, bevor er antwortet. Das Gerät muss innerhalb des 15-Sekunden-Fensters die ursprüngliche `SUBSCRIBE`-Nachricht mit derselben Paket-ID erneut versuchen. Ist dies der Fall, antwortet der Broker mit einer `SUBACK`-Nachricht und der Test wird validiert. Wenn das Gerät den `SUBSCRIBE`-Versuch nicht wiederholt, wird das Original-`SUBACK` an das Gerät gesendet und der Test wird als **Pass with warnings** (Mit Warnungen bestanden) markiert, zusammen mit einer Systemnachricht. Wenn das Gerät während der Testausführung die Verbindung verliert und die Verbindung wiederherstellt, wird der Testszenario ohne Fehler zurückgesetzt und das Gerät muss die Schritte des Testszenarios erneut ausführen.
![\[Der SUBSCRIBE QoS 1-Flow, der ein Gerät, das eine SUBSCRIBE-Nachricht mit QoS 1-Stufe sendet, und mehrere Interaktionen mit dem Broker umfasst.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/subscribe-Qos1.png)
#### RECONNECT
In diesem Szenario wird überprüft, ob das Gerät erfolgreich wieder eine Verbindung zum Broker herstellt, nachdem das Gerät von einer erfolgreichen Verbindung getrennt wurde. Device Advisor trennt das Gerät nicht, wenn es zuvor während der Testsuite mehr als einmal eine Verbindung hergestellt hat. Stattdessen wird der Test als **Pass** (Bestanden) markiert.
![\[Der RECONNECT-Fluss zwischen DUT und dem Broker.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/reconnect.png)
### Erweiterte Testausführung
In dieser Phase führt der Testfall komplexere Tests seriell durch, um zu überprüfen, ob das Gerät den bewährten Methoden entspricht. Diese erweiterten Tests stehen zur Auswahl und können deaktiviert werden, falls sie nicht erforderlich sind. Jeder erweiterte Test hat seinen eigenen Timeout-Wert, der auf den Anforderungen des Szenarios basiert.
#### RETURN PUBACK ON QoS 1 SUBSCRIPTION
**Anmerkung**
Wählen Sie dieses Szenario nur aus, wenn Ihr Gerät QoS 1-Abonnements ausführen kann.
In diesem Szenario wird überprüft, ob das Gerät, nachdem es ein Thema abonniert und eine `PUBLISH`-Nachricht vom Broker erhalten hat, eine `PUBACK`-Nachricht zurückgibt.
![\[Der RETURN PUBACK ON QoS 1-ABONNEMENT-Fluss zwischen DUT und dem Broker.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/return-puback.png)
#### RECEIVE LARGE PAYLOAD
**Anmerkung**
Wählen Sie dieses Szenario nur aus, wenn Ihr Gerät QoS 1-Abonnements ausführen kann.
In diesem Szenario wird überprüft, ob das Gerät mit einer `PUBACK`-Nachricht antwortet, nachdem es eine `PUBLISH`-Nachricht vom Broker für ein QoS 1-Thema mit einer großen Nutzlast erhalten hat. Das Format der erwarteten Nutzlast kann mit der `LONG_PAYLOAD_FORMAT`-Option konfiguriert werden.
![\[Der RECEIVE LARGE PAYLOAD-Fluss zwischen DUT und dem Broker.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/large-payload.png)
#### PERSISTENT SESSION
**Anmerkung**
Wählen Sie dieses Szenario nur aus, wenn Ihr Gerät QoS 1-Abonnements ausführen und eine persistente Sitzung aufrechterhalten kann.
In diesem Szenario wird das Geräteverhalten bei der Aufrechterhaltung persistenter Sitzungen validiert. Der Test validiert, wenn die folgenden Bedingungen erfüllt sind:
+ Das Gerät stellt mit einem aktiven QoS 1-Abonnement und aktivierten persistenten Sitzungen eine Verbindung zum Broker her.
+ Das Gerät trennt während der Sitzung erfolgreich die Verbindung zum Broker.
+ Das Gerät stellt erneut eine Verbindung zum Broker her und nimmt die Abonnements für seine Trigger-Themen wieder auf, ohne diese Themen explizit erneut zu abonnieren.
+ Das Gerät empfängt erfolgreich Nachrichten, die vom Broker für die abonnierten Themen gespeichert wurden, und läuft wie erwartet.
Weitere Informationen zu AWS IoT persistenten Sitzungen finden Sie unter [Verwenden persistenter MQTT-Sitzungen](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
![\[Der PERSISTENT SESSION-Fluss zwischen DUT und dem Broker.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/persistent-session.png)
#### KEEP ALIVE
In diesem Szenario wird überprüft, ob das Gerät erfolgreich die Verbindung trennt, nachdem es keine Ping-Antwort vom Broker erhalten hat. Für die Verbindung muss ein gültiger Keep-Alive-Timer konfiguriert sein. Im Rahmen dieses Tests blockiert der Broker alle Antworten, die für `PUBLISH`-, `SUBSCRIBE`- und `PINGREQ`-Nachrichten gesendet wurden. Es überprüft auch, ob das getestete Gerät die MQTT-Verbindung unterbricht.
![\[Der KEEP-ALIVE-Fluss zwischen DUT und dem Broker.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/keep-alive.png)
#### INTERMITTENT CONNECTIVITY
In diesem Szenario wird überprüft, ob das Gerät wieder eine Verbindung zum Broker herstellen kann, nachdem der Broker die Verbindung zum Gerät in zufälligen Intervallen für einen zufälligen Zeitraum getrennt hat.
![\[Der INTERMITTIERENDE KONNEKTIVITÄTSFLUSS zwischen DUT und dem Broker.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/intermittent.png)
#### RECONNECT BACKOFF
In diesem Szenario wird überprüft, ob auf dem Gerät ein Backoff-Mechanismus implementiert ist, wenn der Broker die Verbindung mehrmals trennt. Device Advisor meldet den Backoff-Typ als exponentiell, Jitter, linear oder konstant. Die Anzahl der Backoff-Versuche ist mit der `BACKOFF_CONNECTION_ATTEMPTS`-Option konfigurierbar. Der Standardwert ist 5. Der Wert ist zwischen 5 und 10 konfigurierbar.
Damit dieser Test bestanden wird, empfehlen wir, den Mechanismus [Exponential Backoff And Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren.
![\[Der RECONNECT BACKOFF-Fluss zwischen DUT und dem Broker.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/reconnect-backoff.png)
#### LONG SERVER DISCONNECT
In diesem Szenario wird überprüft, ob das Gerät erfolgreich wieder eine Verbindung herstellen kann, nachdem der Broker die Verbindung zum Gerät über einen längeren Zeitraum (bis zu 120 Minuten) unterbrochen hat. Die Zeit für die Servertrennung kann mit der `LONG_SERVER_DISCONNECT_TIME`-Option konfiguriert werden. Der Standardwert beträgt 120 Minuten. Dieser Wert ist zwischen 30 und 120 Minuten konfigurierbar.
![\[Der LONG SERVER DISCONNECT-Fluss zwischen DUT und dem Broker.\]](http://docs.aws.amazon.com/de_de/iot/latest/developerguide/images/longserver-disconnect.png)
### Zusätzliche Ausführungszeit
Die zusätzliche Ausführungszeit ist die Zeit, die der Test nach Abschluss aller oben genannten Tests und vor dem Beenden des Testfalls wartet. Kunden nutzen diesen zusätzlichen Zeitraum, um die gesamte Kommunikation zwischen dem Gerät und dem Broker zu überwachen und zu protokollieren. Die zusätzliche Ausführungszeit kann mit der `ADDITIONAL_EXECUTION_TIME`-Option konfiguriert werden. Standardmäßig ist diese Option auf 0 Minuten eingestellt und kann 0 bis 120 Minuten betragen.
## Konfigurationsoptionen für MQTT-Tests mit langer Dauer
Alle für den MQTT-Test mit langer Dauer bereitgestellten Konfigurationsoptionen sind optional. Die folgenden Optionen sind verfügbar:
**OPERATIONEN**
Die Liste der Operationen, die das Gerät ausführt, wie `CONNECT`, `PUBLISH` Uand `SUBSCRIBE`. Im Testfall werden Szenarien ausgeführt, die auf den angegebenen Operationen basieren. Operationen, die nicht angegeben sind, werden als gültig vorausgesetzt.
```
{
"OPERATIONS": ["PUBLISH", "SUBSCRIBE"]
//by default the test assumes device can CONNECT
}
```
**SZENARIEN**
Basierend auf den ausgewählten Operationen führt der Testfall Szenarien aus, um das Verhalten des Geräts zu überprüfen. Es gibt zwei Arten von Szenarien:
+ Bei **Basisszenarien** handelt es sich um einfache Tests, mit denen überprüft wird, ob das Gerät die oben als Teil der Konfiguration ausgewählten Vorgänge ausführen kann. Diese werden auf der Grundlage der in der Konfiguration angegebenen Operationen vorab ausgewählt. In der Konfiguration sind keine weiteren Eingaben erforderlich.
+ **Fortgeschrittene Szenarien** sind komplexere Szenarien, die für das Gerät ausgeführt werden, um zu überprüfen, ob das Gerät unter realen Bedingungen bewährte Verfahren befolgt. Diese sind optional und können als eine Reihe von Szenarien an die Konfigurationseingabe der Testsuite übergeben werden.
```
{
"SCENARIOS": [ // list of advanced scenarios
"PUBACK_QOS_1",
"RECEIVE_LARGE_PAYLOAD",
"PERSISTENT_SESSION",
"KEEP_ALIVE",
"INTERMITTENT_CONNECTIVITY",
"RECONNECT_BACK_OFF",
"LONG_SERVER_DISCONNECT"
]
}
```
**BASIC\$1TESTS\$1EXECUTION\$1TIME\$1OUT:**
Die maximale Zeit, in der der Testfall auf den Abschluss aller Basistests wartet. Der Standardwert beträgt 60 Minuten. Dieser Wert ist zwischen 30 und 120 Minuten konfigurierbar.
**LONG\$1SERVER\$1DISCONNECT\$1TIME:**
Die Zeit, die der Testfall benötigt hat, um das Gerät während des Long-Server-Disconnect-Tests zu trennen und wieder zu verbinden. Der Standardwert beträgt 60 Minuten. Dieser Wert ist zwischen 30 und 120 Minuten konfigurierbar.
**ADDITIONAL\$1EXECUTION\$1TIME:**
Durch die Konfiguration dieser Option wird nach Abschluss aller Tests ein Zeitfenster zur Überwachung der Ereignisse zwischen dem Gerät und dem Broker bereitgestellt. Der Standardwert beträgt 0 Minuten. Dieser Wert ist zwischen 0 und 120 Minuten konfigurierbar.
**BACKOFF\$1CONNECTION\$1ATTEMPTS:**
Diese Option konfiguriert, wie oft das Gerät durch den Testfall getrennt wird. Dies wird vom Reconnect-Backoff-Test verwendet. Der Standardwert ist 5 Versuche. Dieser Wert ist von 5 bis 10 konfigurierbar.
**LONG\$1PAYLOAD\$1FORMAT:**
Das Format der Nachrichtennutzlast, die das Gerät erwartet, wenn der Testfall zu einem QoS 1-Thema veröffentlicht wird, das vom Gerät abonniert wurde.
**Definition des API-Testfalls:**
```
{
"tests":[
{
"name":"my_mqtt_long_duration_test",
"configuration": {
// optional
"OPERATIONS": ["PUBLISH", "SUBSCRIBE"],
"SCENARIOS": [
"LONG_SERVER_DISCONNECT",
"RECONNECT_BACK_OFF",
"KEEP_ALIVE",
"RECEIVE_LARGE_PAYLOAD",
"INTERMITTENT_CONNECTIVITY",
"PERSISTENT_SESSION",
],
"BASIC_TESTS_EXECUTION_TIMEOUT": 60, // in minutes (60 minutes by default)
"LONG_SERVER_DISCONNECT_TIME": 60, // in minutes (120 minutes by default)
"ADDITIONAL_EXECUTION_TIME": 60, // in minutes (0 minutes by default)
"BACKOFF_CONNECTION_ATTEMPTS": "5",
"LONG_PAYLOAD_FORMAT":"{"message":"${payload}"}"
},
"test":{
"id":"MQTT_Long_Duration",
"version":"0.0.0"
}
}
]
}
```
## Zusammenfassungsprotokoll des MQTT-Testfalls mit langer Dauer
Der MQTT-Testfall mit langer Dauer wird länger als normale Testfälle ausgeführt. Es wird ein separates Zusammenfassungsprotokoll bereitgestellt, das wichtige Ereignisse wie Geräteverbindungen, Veröffentlichungen und Abonnieren während der Ausführung auflistet. Zu den Details gehört, was getestet wurde, was nicht getestet wurde und was fehlgeschlagen ist. Am Ende des Protokolls enthält der Test eine Zusammenfassung aller Ereignisse, die während der Ausführung des Testfalls aufgetreten sind. Dies umfasst:
+ *Der Keep-Alive-Timer ist auf dem Gerät konfiguriert.*
+ *Auf dem Gerät ist ein persistentes Sitzungs-Flag konfiguriert.*
+ *Die Anzahl der Geräteverbindungen während des Testlaufs.*
+ *Der Backoff-Typ für die Wiederverbindung des Geräts, sofern er für den Backoff-Test für die Wiederherstellung der Verbindung validiert wurde.*
+ *Die Themen, zu denen das Gerät während der Testfallausführung veröffentlicht hat.*
+ *Die Themen, die das Gerät während der Testfallausführung abonniert hat.*