Diese MQTT-Test-Checkliste führt Sie durch die zwölf Prüfungen, mit denen Sie die meisten Produktionsvorfälle in MQTT-Anwendungen entdecken, bevor es Ihre Nutzer tun. Zu jedem Punkt gibt es einen schnellen Test, den Sie vom Laptop aus gegen einen öffentlichen MQTT-Broker ausführen können. Am Ende haben Sie eine wiederholbare Go-Live-Routine statt des vagen Gefühls, dass „es auf meinem Schreibtisch funktioniert hat“.
Warum MQTT-Anwendungen einen eigenen Testplan brauchen
Unit-Tests decken Ihr Parsing und Ihre Geschäftslogik ab, doch die meisten MQTT-Fehler entstehen im Raum zwischen Client und Broker: ein Gerät, das nach einem Reconnect nie neu abonniert, ein Dashboard, das einen veralteten retained Wert zeigt, ein Last Will, der aus dem falschen Grund ausgelöst wird, oder eine Payload, die plötzlich 70 KB groß ist, weil jemand ein Debug-Feld ergänzt hat. Nichts davon zeigt sich in einer Demo, in der alles glattläuft. In der Fertigung sind die Folgen besonders teuer: Ein Gateway an einer SPS, das nach einem kurzen Netzausfall in der Halle nicht neu abonniert, liefert keine Maschinendaten mehr an MES oder OEE-Dashboard, und das fällt oft erst in der nächsten Schicht auf.
Die gute Nachricht: MQTT-Verhalten ist beobachtbar. Jede Nachricht läuft über den Broker, sodass Sie mit zwei Terminals und einem Subscriber auf einer Wildcard genau sehen, was Ihre Geräte und Dienste tun. Wenn Sie die Grundlagen auffrischen möchten, lesen Sie zuerst, wie MQTT funktioniert, und kommen Sie dann hierher zurück.
Zuerst eine Testumgebung einrichten
Verwenden Sie für diese Prüfungen eine Wegwerf-Umgebung. Der öffentliche MQTT-Broker unter broker.connectmq.com ist für Tests und Prototypen gedacht, nicht für Produktionsdaten, und akzeptiert anonyme Verbindungen mit jeder nicht leeren, eindeutigen Client-ID. Wählen Sie ein zufälliges Topic-Präfix, damit Ihre Tests nicht mit denen anderer kollidieren, und denken Sie daran, dass alles auf dem öffentlichen MQTT-Broker für jeden lesbar ist. Senden Sie also niemals echte Zugangsdaten oder Kundendaten.
# Ein eindeutiges Präfix für diese Testsitzung wählen
export PREFIX="connectmq/demo/$(openssl rand -hex 4)"
echo $PREFIX
# Terminal 1: alles unter dem Präfix beobachten, ausführlich, MQTT 5
mosquitto_sub -h broker.connectmq.com -p 1883 -V mqttv5 \
-i watcher-$RANDOM -t "$PREFIX/#" -v
Lassen Sie diesen Beobachter während der gesamten Sitzung geöffnet.
Kennen Sie die Limits des öffentlichen Brokers, bevor Sie beginnen, denn einige Prüfungen stoßen absichtlich daran: 64 KB pro Nachricht, 10 Nachrichten pro Sekunde und Client, 10 Subscriptions pro Client, 8 Topic-Ebenen und eine maximale Session Expiry von 30 Minuten. Ihr Produktions-Broker hat andere Limits, und genau deshalb sollten Sie sie explizit testen.
Die MQTT-Test-Checkliste
Arbeiten Sie die Liste der Reihe nach ab. Die Punkte 1 bis 4 betreffen die Konnektivität, 5 bis 8 die Nachrichtensemantik und 9 bis 12 die Robustheit.
- Verbindung und Authentifizierung. Falsches Passwort, falscher Port und TLS-Fehler erzeugen klare Fehlermeldungen.
- Eindeutige Client-IDs. Zwei Clients mit derselben ID werfen sich nicht stillschweigend in einer Schleife gegenseitig hinaus.
- Reconnect und erneutes Abonnieren. Nach einem Netzwerkabbruch verbindet sich der Client mit Backoff neu und stellt seine Subscriptions wieder her.
- Keep Alive. Eine halboffene Verbindung wird innerhalb von etwa dem 1,5-Fachen des Keep-Alive-Intervalls erkannt.
- QoS-Verhalten. Die angeforderte QoS ist die QoS, die Sie erhalten, und Duplikate werden behandelt.
- Retained State. Neue Subscriber erhalten den richtigen letzten bekannten Wert, und veraltete Retained Messages lassen sich löschen.
- Last Will and Testament. Ein unsauberer Verbindungsabbruch erzeugt einen Offline-Status, ein sauberes Herunterfahren nicht.
- Persistente Sessions. Nachrichten, die publiziert werden, während ein Subscriber offline ist, kommen an, wenn er zurückkehrt (nur QoS 1 und 2).
- Payload-Validierung. Fehlerhaftes JSON, fehlende Felder und falsche Typen werden abgewiesen, ohne den Konsumenten zum Absturz zu bringen.
- Größen-, Raten- und Topic-Limits. Übergroße Payloads, Publish-Bursts und tiefe Topics scheitern auf vorhersehbare Weise.
- Topic- und Wildcard-Design. Subscriptions erfassen genau das, was Sie beabsichtigen, und nicht mehr.
- Last- und Dauertest. Das System übersteht realistische Verbindungszahlen und Nachrichtenraten über Stunden, nicht nur Sekunden.
Die folgenden Abschnitte zeigen, wie Sie jede Gruppe durchführen.
Konnektivitätsprüfungen (Punkte 1 bis 4)
Beginnen Sie mit den Negativfällen. Ein guter Client protokolliert einen aussagekräftigen Grund, wenn er sich nicht verbinden kann; ein schlechter versucht es stillschweigend endlos weiter.
# Reines TCP sollte funktionieren
mosquitto_pub -h broker.connectmq.com -p 1883 -i test-pub-$RANDOM \
-t "$PREFIX/ping" -m "hello"
# TLS auf 8883 sollte funktionieren und das Let's-Encrypt-Zertifikat validieren
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i test-tls-$RANDOM -t "$PREFIX/ping" -m "hello over tls"
# Reines MQTT gegen den TLS-Port sollte schnell scheitern, nicht hängen
mosquitto_pub -h broker.connectmq.com -p 8883 -i test-bad-$RANDOM \
-t "$PREFIX/ping" -m "should fail"
Für Punkt 2 starten Sie zwei Subscriber mit derselben Client-ID. Der Broker trennt die ältere Session, sobald sich die neuere verbindet. Verbinden sich beide Clients automatisch neu, werfen sie sich abwechselnd hinaus, was sich in Ihren Logs als schnelles Muster aus Verbinden und Trennen zeigt. Erzeugen Sie Client-IDs aus einer stabilen Gerätekennung plus einer Rolle, niemals aus einer fest codierten Konstante, die sich eine ganze Flotte teilt.
Für Punkt 3 ist der zuverlässigste Test physisch: Starten Sie Ihren Client, ziehen Sie dann das Netzwerkkabel oder deaktivieren Sie das WLAN für 60 Sekunden. Sobald die Verbindung zurück ist, publizieren Sie eine Nachricht aus dem Beobachter-Terminal und prüfen Sie, ob Ihr Client sie noch empfängt. Viele Bibliotheken verbinden sich automatisch neu, stellen Subscriptions aber nur wieder her, wenn Sie im On-Connect-Callback abonnieren. Das folgende Python-Skript zeigt das Muster und gibt jede Zustandsänderung aus, damit Sie sehen, was passiert.
import time
import uuid
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/replace-me"
client_id = f"reconnect-test-{uuid.uuid4().hex[:8]}"
def on_connect(client, userdata, flags, reason_code, properties):
print(f"{time.strftime('%X')} connected: {reason_code}")
# Hier zu abonnieren bedeutet, dass Subscriptions nach jedem Reconnect zurückkommen
client.subscribe(f"{PREFIX}/cmd/#", qos=1)
def on_disconnect(client, userdata, disconnect_flags, reason_code, properties):
print(f"{time.strftime('%X')} disconnected: {reason_code}")
def on_message(client, userdata, msg):
print(f"{time.strftime('%X')} {msg.topic} qos={msg.qos} retain={msg.retain} {msg.payload!r}")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=client_id,
protocol=mqtt.MQTTv5)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message
client.reconnect_delay_set(min_delay=1, max_delay=30)
client.connect("broker.connectmq.com", 1883, keepalive=20)
client.loop_forever(retry_first_connection=True)
Bei einem Keep Alive von 20 Sekunden sollte der Broker den Client etwa 30 Sekunden nach dem Ende des Verkehrs als verschwunden betrachten. Das ist Punkt 4: Braucht Ihr Gerät mehrere Minuten, um eine tote Verbindung zu bemerken, ist Ihr Keep Alive zu lang oder die Bibliothek sendet kein PINGREQ.
Prüfungen der Nachrichtensemantik (Punkte 5 bis 8)
QoS wird pro Subscription und pro Publish ausgehandelt, und die effektive Zustellstufe ist die niedrigere der beiden. Testen Sie das explizit, statt es anzunehmen. Wenn Sie unsicher sind, was jede Stufe garantiert, lesen Sie zuerst MQTT-QoS-Stufen erklärt.
# Subscribe mit QoS 1, Publish mit QoS 2: die Zustellung wird auf QoS 1 herabgestuft
mosquitto_sub -h broker.connectmq.com -i qos-sub-$RANDOM -q 1 \
-t "$PREFIX/qos" -v -d
mosquitto_pub -h broker.connectmq.com -i qos-pub-$RANDOM -q 2 \
-t "$PREFIX/qos" -m "qos test" -d
Das Flag -d gibt den Paketfluss aus (PUBLISH, PUBACK, PUBREC und so weiter) und macht die Herabstufung sichtbar. Ihr Konsumentencode sollte außerdem Duplikate bei QoS 1 vertragen: Verarbeiten Sie dieselbe Nachricht zweimal und prüfen Sie, dass nichts kaputtgeht, etwa indem Schreibvorgänge über eine Nachrichten-ID in der Payload abgesichert werden.
Für Retained State publizieren Sie einen retained Wert, verbinden dann einen ganz neuen Subscriber und prüfen, ob er ihn sofort mit gesetztem Retain-Flag erhält. Löschen Sie ihn danach, indem Sie eine leere retained Payload publizieren, und prüfen Sie, dass der nächste neue Subscriber nichts erhält.
mosquitto_pub -h broker.connectmq.com -i ret-$RANDOM -r \
-t "$PREFIX/sensor1/state" -m '{"temp":21.4}'
mosquitto_sub -h broker.connectmq.com -i ret-check-$RANDOM \
-t "$PREFIX/sensor1/state" -v -C 1 -W 5
# Die Retained Message löschen
mosquitto_pub -h broker.connectmq.com -i ret-clear-$RANDOM -r -n \
-t "$PREFIX/sensor1/state"
Die Last-Will-Prüfung braucht einen Client, der unsauber stirbt. Verbinden Sie sich mit einer Will-Nachricht und beenden Sie den Prozess dann mit kill -9 oder trennen Sie das Netzwerk. Der Beobachter sollte den Will sehen, nachdem das Keep Alive abgelaufen ist. Wiederholen Sie das mit einem sauberen Beenden per Ctrl+C, das DISCONNECT sendet: Dann darf der Will nicht publiziert werden. Der Leitfaden zu Last Will and Testament erklärt das retained Online/Offline-Muster, das die meisten Flotten nutzen.
mosquitto_sub -h broker.connectmq.com -i lwt-dev-$RANDOM -k 10 \
--will-topic "$PREFIX/dev1/status" --will-payload offline --will-retain \
-t "$PREFIX/dev1/cmd"
Für persistente Sessions verbinden Sie einen Subscriber mit fester Client-ID, QoS 1 und einer Session Expiry, trennen ihn, publizieren drei QoS-1-Nachrichten und verbinden ihn dann mit derselben ID neu. Alle drei sollten ankommen. Halten Sie die Session Expiry auf dem öffentlichen MQTT-Broker bei höchstens 1.800 Sekunden.
mosquitto_sub -h broker.connectmq.com -V mqttv5 -i persist-fixed-001 \
-c -x 600 -q 1 -t "$PREFIX/queue" -v
Robustheitsprüfungen (Punkte 9 bis 12)
Payload-Validierung gehört in jeden Konsumenten. Publizieren Sie absichtlich Unsinn: ungültiges JSON, eine Zahl als String, eine leere Payload, einen 10-KB-String in einem Feld, das Sie kurz erwarten. Der Konsument sollte protokollieren und überspringen, nicht abstürzen und keinen Unsinn in die Datenbank schreiben.
for p in '{"temp":' '{"temp":"hot"}' '' '{"unexpected":true}'; do
mosquitto_pub -h broker.connectmq.com -i bad-$RANDOM \
-t "$PREFIX/sensor1/telemetry" -m "$p"
done
Bei Limits unterscheiden sich öffentliche und Produktionsumgebungen am stärksten, testen Sie also das Verhalten, nicht nur die Zahl. Auf dem öffentlichen MQTT-Broker sollten eine Payload über 64 KB, mehr als 10 Nachrichten pro Sekunde von einem Client, eine elfte Subscription oder eine neunte Topic-Ebene allesamt abgewiesen werden. Stellen Sie sicher, dass Ihr Client das als Fehler meldet und zurückweicht, statt den Broker zu bombardieren. Achten Sie bei MQTT 5 auf Reason Codes wie 0x97 (Quota exceeded) im Disconnect oder in der Bestätigung. Größenlimits auf einem verwalteten MQTT-Broker hängen vom Plan ab; bei ConnectMQ erlaubt beispielsweise der kostenlose Serverless-Plan Nachrichten bis 256 KB und der kostenpflichtige Serverless-Plan bis 1 MB.
# 70-KB-Payload: sollte auf dem öffentlichen Broker abgewiesen werden
head -c 71680 /dev/urandom | base64 > /tmp/big.txt
mosquitto_pub -h broker.connectmq.com -V mqttv5 -i big-$RANDOM \
-t "$PREFIX/big" -f /tmp/big.txt -d
Für das Wildcard-Design abonnieren Sie mit genau dem Filter, den Ihr Dienst verwendet, und publizieren auf Topics, die passen sollen und die nicht passen sollen. Ein Filter wie +/+/telemetry erfasst oft mehr als beabsichtigt.
Last- und Dauertests sind der letzte Schritt. Simulieren Sie die reale Anzahl an Geräten mit realistischen Intervallen und Payload-Größen, etwa alle Maschinen einer Linie in werk-muenchen mit ihrem tatsächlichen Takt für Energiemonitoring und Zustandsdaten, und lassen Sie das mehrere Stunden laufen. Tun Sie das gegen einen privaten Broker statt gegen den öffentlichen, da das öffentliche Ratenlimit pro Client bewusst niedrig ist. Die Übersicht der MQTT-Lasttest-Tools vergleicht die Optionen.
Kurzreferenz-Tabelle
| Prüfung | Bestanden, wenn | Typischer Fehler |
|---|---|---|
| Auth und TLS | Klare Fehlermeldung bei falschen Zugangsdaten oder Port | Stille endlose Wiederholung |
| Client-ID | Eine Session pro Gerät | Zwei Geräte werfen sich gegenseitig hinaus |
| Reconnect | Subscriptions automatisch wiederhergestellt | Verbunden, aber tauber Client |
| Keep Alive | Tote Verbindung in etwa 1,5 × Intervall erkannt | Gerät minutenlang unbemerkt offline |
| QoS | Effektive QoS wie geplant, Duplikate harmlos | Doppelt gezählte Ereignisse |
| Retained | Neuer Subscriber sieht letzten Wert; löschbar | Veralteter Wert für immer |
| Last Will | Wird nur bei Absturz ausgelöst | Wird bei sauberem Beenden oder nie ausgelöst |
| Sessions | Offline-QoS-1-Nachrichten zugestellt | Versehentlich Clean Session |
| Payloads | Fehlerhafte Eingaben übersprungen und protokolliert | Absturz des Konsumenten |
| Limits | Vorhersehbare Ablehnung und Backoff | Retry-Sturm |
| Wildcards | Nur beabsichtigte Topics erfasst | Datenleck zwischen Mandanten oder Standorten |
| Last | Stabiler Speicher und stabile Latenz über Stunden | Schleichendes Leck ab Tag zwei |
Werkzeuge, die das Testen beschleunigen
Kommandozeilen-Clients sind ideal für Skripte, doch ein visuelles Werkzeug beschleunigt exploratives Testen. ConnectMQ bietet im Portal einen MQTT-Client im Browser und einen Live-Topic-Explorer sowie einen Desktop-MQTT-Explorer und eine VS-Code-Erweiterung, sodass Sie Topics beobachten können, während Ihre Testskripte laufen. Was Sie auch verwenden: Speichern Sie Ihre Testbefehle im Repository, damit das nächste Release dieselbe Checkliste durchläuft. Wenn das Protokoll insgesamt neu für Sie ist, legt das MQTT-Tutorial am besten das Fundament, auf dem diese Prüfungen aufbauen.
Testen Sie auf einem privaten ConnectMQ-Broker
Sobald die Prüfungen auf dem öffentlichen MQTT-Broker bestanden sind, wiederholen Sie sie in der Umgebung, in die Sie tatsächlich ausliefern. ConnectMQ stellt Ihnen mit wenigen Klicks einen privaten Broker mit TLS auf 8883, WebSocket auf 8084, Kontingenten pro Plan und generierten Zugangsdaten bereit. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, setzen Sie YOUR_USERNAME, YOUR_PASSWORD und YOUR_CLIENT_ID ein und führen Sie vor dem Go-Live dieselbe Checkliste dagegen aus.
Häufig gestellte Fragen
Was sollte eine MQTT-Test-Checkliste enthalten?
Mindestens: Authentifizierung und TLS, eindeutige Client-IDs, Reconnect mit erneutem Abonnieren, Keep Alive, QoS, Retained Messages, Last Will, persistente Sessions, Payload-Validierung, Broker-Limits, Wildcard-Matching und einen mehrstündigen Lasttest.
Kann ich meine MQTT-Anwendung auf einem öffentlichen MQTT-Broker testen?
Ja, für funktionale Prüfungen. Verwenden Sie eine eindeutige Client-ID und ein eindeutiges Topic-Präfix und senden Sie niemals sensible Daten, denn öffentliche Topics kann jeder lesen. Führen Sie Lasttests auf einem privaten Broker durch.
Wie teste ich den MQTT Last Will, ohne Hardware abzustecken?
Beenden Sie den Client-Prozess hart (zum Beispiel mit kill -9), damit er kein DISCONNECT senden kann. Der Broker publiziert den Will, nachdem die Keep-Alive-Zeit abgelaufen ist.
Warum empfängt mein Client nach einem Reconnect keine Nachrichten mehr?
Wahrscheinlich abonniert er nur einmal beim Start. Verschieben Sie die Subscribe-Aufrufe in den On-Connect-Callback oder nutzen Sie eine persistente Session, damit Subscriptions bei jedem Reconnect wiederhergestellt werden.
