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.

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:

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.

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.

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.

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.

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.

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.

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

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.

RECEIVE LARGE PAYLOAD

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.

PERSISTENT SESSION

In diesem Szenario wird das Geräteverhalten bei der Aufrechterhaltung persistenter Sitzungen validiert. Der Test validiert, wenn die folgenden Bedingungen erfüllt sind:

Weitere Informationen zu AWS IoT persistenten Sitzungen finden Sie unter Verwenden persistenter MQTT-Sitzungen.

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.

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.

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 (Exponentielles Backoff und Jitter) auf dem getesteten Gerät zu implementieren.

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.

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. Verfügbar sind die nachfolgend aufgeführten Optionen:

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: