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-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.*