MQTT Test Kontrol Listesi: Canlıya Almadan Önce Yapılacak 12 Kontrol

Bu MQTT test kontrol listesi, MQTT uygulamalarındaki üretim olaylarının çoğunu kullanıcılarınızdan önce yakalayan on iki kontrolde size yol gösterir. Her madde, bir dizüstü bilgisayardan genel bir broker'a karşı çalıştırabileceğiniz hızlı bir testle gelir; böylece sonunda "benim masamda çalışıyordu" gibi belirsiz bir his yerine tekrarlanabilir bir canlıya geçiş rutininiz olur.

MQTT Uygulamaları Neden Kendi Test Planına İhtiyaç Duyar

Birim testleri ayrıştırma ve iş mantığınızı kapsar, ancak MQTT arızalarının çoğu client ile broker arasındaki boşlukta yaşanır: Yeniden bağlandıktan sonra bir daha hiç abone olmayan bir cihaz, bayat bir retained değeri gösteren bir dashboard, yanlış nedenle tetiklenen bir Last Will ya da biri bir debug alanı eklediği için birden 70 KB olan bir payload. Bunların hiçbiri sorunsuz senaryolu bir demoda ortaya çıkmaz.

İyi haber şu ki MQTT davranışı gözlemlenebilirdir. Her mesaj broker'dan geçer; bu yüzden iki terminal ve joker karakterli bir abone ile cihazlarınızın ve servislerinizin tam olarak ne yaptığını görebilirsiniz. Hareketli parçalar hakkında hafızanızı tazelemeniz gerekiyorsa MQTT nasıl çalışır yazısıyla başlayın ve buraya geri dönün.

Önce Bir Test Ortamı Kurun

Bu kontroller için kullanılıp atılabilir bir ortam kullanın. broker.connectmq.com adresindeki genel MQTT test broker'ı, boş olmayan ve benzersiz herhangi bir client ID ile anonim bağlantıları kabul eder. Testlerinizin başkalarınınkiyle çakışmaması için rastgele bir topic öneki seçin ve genel alanın herkes tarafından okunabildiğini unutmayın; asla gerçek kimlik bilgileri veya müşteri verisi göndermeyin.

# Bu test oturumu için benzersiz bir önek seçin
export PREFIX="connectmq/demo/$(openssl rand -hex 4)"
echo $PREFIX

# Terminal 1: önekinizin altındaki her şeyi ayrıntılı olarak izleyin, MQTT 5
mosquitto_sub -h broker.connectmq.com -p 1883 -V mqttv5 \
  -i watcher-$RANDOM -t "$PREFIX/#" -v

Bu izleyiciyi tüm oturum boyunca açık tutun.

Başlamadan önce genel broker'ın sınırlarını bilin, çünkü bazı kontroller bilerek bunlara takılır: Mesaj başına 64 KB, client başına saniyede 10 mesaj, client başına 10 abonelik, 8 topic seviyesi ve azami 30 dakikalık oturum süresi. Üretim broker'ınızın sınırları farklı olacaktır; onları açıkça test etmeniz gerekmesinin nedeni de tam olarak budur.

MQTT Test Kontrol Listesi

Listeyi sırayla uygulayın. 1-4. maddeler bağlantıyla, 5-8. maddeler mesaj semantiğiyle, 9-12. maddeler ise sağlamlıkla ilgilidir.

1. Bağlantı ve kimlik doğrulama. Yanlış parola, yanlış port ve TLS arızaları anlaşılır hatalar üretir.
2. Client ID benzersizliği. Aynı kimliğe sahip iki client birbirini sessizce bir döngü içinde düşürmez.
3. Yeniden bağlanma ve yeniden abone olma. Bir ağ kopmasından sonra client geri çekilme (backoff) ile yeniden bağlanır ve aboneliklerini geri yükler.
4. Keep alive. Yarı açık bir bağlantı, keep alive aralığının yaklaşık 1,5 katı içinde tespit edilir.
5. QoS davranışı. İstediğiniz QoS, aldığınız QoS'tur ve yinelemeler ele alınır.
6. Retained durum. Yeni aboneler doğru bilinen son değeri alır ve bayat retained message'lar temizlenebilir.
7. Last Will and Testament. Düzgün olmayan bir bağlantı kopması çevrimdışı durumu üretir; temiz bir kapanış üretmez.
8. Kalıcı oturumlar. Bir abone çevrimdışıyken yayınlanan mesajlar, o geri döndüğünde ulaşır (yalnızca QoS 1 ve 2).
9. Payload doğrulama. Hatalı JSON, eksik alanlar ve yanlış türler tüketiciyi çökertmeden reddedilir.
10. Boyut, hız ve topic sınırları. Aşırı büyük payload'lar, yayın patlamaları ve derin topic'ler öngörülebilir şekilde başarısız olur.
11. Topic ve joker karakter tasarımı. Abonelikler tam olarak amaçladığınız şeyle eşleşir, fazlasıyla değil.
12. Yük ve dayanıklılık (soak). Sistem gerçekçi bağlantı sayılarına ve mesaj hızlarına saniyeler değil saatlerce dayanır.

Aşağıdaki bölümler her grubun nasıl çalıştırılacağını gösterir.

Bağlantı Kontrolleri (Madde 1-4)

Olumsuz senaryolarla başlayın. İyi bir client bağlanamadığında anlamlı bir neden kaydeder; kötü bir client ise sonsuza kadar sessizce yeniden dener.

# Düz TCP başarılı olmalı
mosquitto_pub -h broker.connectmq.com -p 1883 -i test-pub-$RANDOM \
  -t "$PREFIX/ping" -m "hello"

# 8883 üzerinde TLS başarılı olmalı ve Let's Encrypt sertifikasını doğrulamalı
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i test-tls-$RANDOM -t "$PREFIX/ping" -m "hello over tls"

# TLS portuna karşı düz MQTT takılmadan hızla başarısız olmalı
mosquitto_pub -h broker.connectmq.com -p 8883 -i test-bad-$RANDOM \
  -t "$PREFIX/ping" -m "should fail"

2. madde için aynı client ID ile iki abone başlatın. Yenisi bağlandığında broker eski oturumun bağlantısını keser. Her iki client da otomatik yeniden bağlanıyorsa sırayla birbirlerini düşürürler; bu da günlüklerinizde hızlı bir bağlanma ve kopma deseni olarak görünür. Client ID'leri sabit bir cihaz tanımlayıcısı artı bir rolden üretin; asla bir filo genelinde paylaşılan sabit kodlanmış bir değerden üretmeyin.

3. madde için en güvenilir test fizikseldir: Client'ınızı çalıştırın, ardından ağ kablosunu çekin veya Wi-Fi'ı 60 saniyeliğine devre dışı bırakın. Bağlantı geri geldiğinde izleyici terminalden bir mesaj yayınlayın ve client'ınızın onu hâlâ aldığını doğrulayın. Birçok kütüphane otomatik olarak yeniden bağlanır, ancak abonelikleri yalnızca on-connect callback'i içinde abone olursanız geri yükler. Aşağıdaki Python betiği bu deseni gösterir ve ne olduğunu görebilmeniz için her durum değişikliğini yazdırır.

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}")
    # Burada abone olmak, aboneliklerin her yeniden bağlanmadan sonra geri gelmesi demektir
    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)

20 saniyelik bir keep alive ile broker, trafik durduktan yaklaşık 30 saniye sonra client'ı gitmiş kabul etmelidir. 4. madde budur: Cihazınızın ölü bir bağlantıyı fark etmesi birkaç dakika sürüyorsa keep alive süreniz çok uzundur ya da kütüphane PINGREQ göndermiyordur.

Mesaj Semantiği Kontrolleri (Madde 5-8)

QoS abonelik başına ve yayın başına müzakere edilir ve etkin teslimat seviyesi ikisinden düşük olanıdır. Bunu varsaymak yerine açıkça test edin. Her seviyenin neyi garanti ettiğinden emin değilseniz önce MQTT QoS seviyeleri açıklaması yazısını okuyun.

# QoS 1 ile abone olun, QoS 2 ile yayınlayın: teslimat QoS 1'e düşürülür
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

-d bayrağı paket akışını (PUBLISH, PUBACK, PUBREC vb.) yazdırır ve düşürmeyi görünür kılar. Tüketici kodunuz QoS 1'de yinelemelere de dayanabilmelidir: Aynı mesajı iki kez işleyin ve hiçbir şeyin bozulmadığını doğrulayın; örneğin yazma işlemlerini payload içindeki bir mesaj kimliğine göre anahtarlayarak.

Retained durum için retained bir değer yayınlayın, ardından yepyeni bir abone bağlayın ve değeri retain bayrağı ayarlanmış olarak hemen aldığını doğrulayın. Sonra boş bir retained payload yayınlayarak temizleyin ve bir sonraki yeni abonenin hiçbir şey almadığını doğrulayın.

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

# Retained message'ı temizleyin
mosquitto_pub -h broker.connectmq.com -i ret-clear-$RANDOM -r -n \
  -t "$PREFIX/sensor1/state"

Last Will kontrolü, düzgün olmayan şekilde ölen bir client gerektirir. Bir will mesajıyla bağlanın, ardından süreci kill -9 ile öldürün veya ağı çekin. İzleyici, keep alive süresi dolduktan sonra will mesajını görmelidir. DISCONNECT gönderen temiz bir Ctrl+C çıkışıyla tekrarlayın: Will yayınlanmamalıdır. Last Will and Testament rehberi, çoğu filonun kullandığı retained çevrimiçi/çevrimdışı desenini açıklar.

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"

Kalıcı oturumlar için sabit bir client ID, QoS 1 ve bir oturum süresiyle bir abone bağlayın, bağlantısını kesin, üç QoS 1 mesajı yayınlayın, ardından aynı kimlikle yeniden bağlanın. Üçü de ulaşmalıdır. Genel broker'da oturum süresini 1.800 saniye veya altında tutun.

mosquitto_sub -h broker.connectmq.com -V mqttv5 -i persist-fixed-001 \
  -c -x 600 -q 1 -t "$PREFIX/queue" -v

Sağlamlık Kontrolleri (Madde 9-12)

Payload doğrulama her tüketicide bulunmalıdır. Bilerek çöp yayınlayın: geçersiz JSON, dize olarak bir sayı, boş bir payload, kısa olmasını beklediğiniz bir alanda 10 KB'lık bir dize. Tüketici kaydetmeli ve atlamalı; çökmemeli ve veritabanına anlamsız veri yazmamalıdır.

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

Sınırlar, genel ve üretim ortamlarının en çok farklılaştığı yerdir; bu yüzden yalnızca sayıyı değil davranışı test edin. Genel broker'da 64 KB'ı aşan bir payload, tek bir client'tan saniyede 10'dan fazla mesaj, on birinci bir abonelik veya dokuzuncu bir topic seviyesi reddedilmelidir. Client'ınızın bunu bir hata olarak gösterdiğinden ve broker'ı yüklenmek yerine geri çekildiğinden emin olun. MQTT 5'te bağlantı kesme veya onay içinde 0x97 (quota exceeded) gibi reason code'lara bakın. Bir yönetilen MQTT broker üzerindeki boyut sınırları plana bağlıdır; örneğin ConnectMQ'da ücretsiz Serverless planı 256 KB, ücretli Serverless planı ise 1 MB mesajlara izin verir.

# 70 KB payload: genel broker'da reddedilmeli
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

Joker karakter tasarımı için servisinizin kullandığı tam filtreyle abone olun ve eşleşmesi gereken ve gerekmeyen topic'lere yayın yapın. +/+/telemetry gibi bir filtre çoğu zaman amaçlanandan fazlasıyla eşleşir.

Yük ve dayanıklılık testi son adımdır. Gerçek cihaz sayısını gerçekçi aralıklar ve payload boyutlarıyla simüle edin ve birkaç saat çalıştırın. Genel broker'daki client başına hız sınırı bilerek düşük tutulduğu için bunu genel broker yerine özel bir broker'a karşı yapın. MQTT yük testi araçları derlemesi seçenekleri karşılaştırır.

Hızlı Başvuru Tablosu

Testi Hızlandıran Araçlar

Komut satırı client'ları betikler için mükemmeldir, ancak görsel bir araç keşif amaçlı testi hızlandırır. ConnectMQ, portalda tarayıcı içi bir MQTT client'ı ve canlı bir topic gezgininin yanı sıra bir Desktop MQTT explorer ve bir VS Code eklentisi sunar; böylece test betikleriniz çalışırken topic'leri izleyebilirsiniz. Ne kullanırsanız kullanın, test komutlarınızı depoya kaydedin ki bir sonraki sürüm aynı kontrol listesini çalıştırsın. Protokolde genel olarak yeniyseniz, bu kontrollerin dayandığı temeli oluşturmak için en iyi yer MQTT eğitimi yazısıdır.

Özel Bir ConnectMQ Broker Üzerinde Test Edin

Genel broker kontrolleri geçtikten sonra bunları gerçekten yayına alacağınız ortamda tekrarlayın. ConnectMQ, birkaç tıklamayla 8883 üzerinde TLS, 8084 üzerinde WebSocket, plana özgü kotalar ve oluşturulmuş kimlik bilgileri içeren özel bir broker sunar. app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun, YOUR_USERNAME, YOUR_PASSWORD ve YOUR_CLIENT_ID değerlerini yerleştirin ve canlıya geçmeden önce aynı kontrol listesini ona karşı çalıştırın.

Sık Sorulan Sorular

Bir MQTT test kontrol listesi neleri içermeli?

En azından: kimlik doğrulama ve TLS, client ID benzersizliği, yeniden abone olmayla yeniden bağlanma, keep alive, QoS, retained message'lar, Last Will, kalıcı oturumlar, payload doğrulama, broker sınırları, joker karakter eşleşmesi ve birkaç saatlik bir yük testi.

MQTT uygulamamı genel bir broker'da test edebilir miyim?

Evet, işlevsel kontroller için. Benzersiz bir client ID ve topic öneki kullanın ve genel topic'ler herkes tarafından okunabildiği için asla hassas veri göndermeyin. Yük testlerini özel bir broker'da çalıştırın.

MQTT Last Will'i donanımı fişten çekmeden nasıl test ederim?

Client sürecini DISCONNECT gönderemeyecek şekilde sert bir sonlandırmayla (örneğin kill -9) öldürün. Broker, keep alive süresi dolduktan sonra will mesajını yayınlar.

Client'ım yeniden bağlandıktan sonra neden mesaj almayı bırakıyor?

Muhtemelen başlangıçta yalnızca bir kez abone oluyordur. Abone olma çağrılarını on-connect callback'ine taşıyın ya da kalıcı bir oturum kullanın; böylece abonelikler her yeniden bağlanmada geri yüklenir.