MQTT

Memvalidasi bahwa perangkat yang sedang diuji mengirimkan permintaan CONNECT.

Definisi kasus uji API:

"tests":[
   {
      "name":"my_mqtt_connect_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",   // in seconds
      },
      "test":{
         "id":"MQTT_Connect",
         "version":"0.0.0"
      }
   }
]      

Kasus uji ini akan memeriksa apakah perangkat (klien) dapat mengembalikan pesan PUBACK jika menerima pesan publikasi dari broker setelah berlangganan topik dengan QoS1.

Konten muatan dan ukuran muatan dapat dikonfigurasi untuk kasus uji ini. Jika ukuran payload dikonfigurasi, Device Advisor akan mengganti nilai untuk konten payload, dan mengirim muatan yang telah ditentukan sebelumnya ke perangkat dengan ukuran yang diinginkan. Ukuran payload adalah nilai antara 0 hingga 128 dan tidak boleh melebihi 128 KB. AWS IoT Core menolak permintaan publikasi dan menghubungkan yang lebih besar dari 128 KB, seperti yang terlihat di halaman broker AWS IoT Core pesan dan batas protokol dan kuota.

Definisi kasus uji API:

"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"
        }
    }
]

Memvalidasi bahwa perangkat yang sedang diuji menggunakan backoff jitter yang tepat saat menghubungkan kembali dengan broker setidaknya lima kali. Pialang mencatat stempel waktu perangkat di bawah permintaan CONNECT yang diuji, melakukan validasi paket, berhenti tanpa mengirim CONNACK ke perangkat yang sedang diuji, dan menunggu perangkat yang diuji untuk mengirim ulang permintaan. Upaya koneksi keenam diizinkan untuk melewati dan CONNACK diizinkan mengalir kembali ke perangkat yang sedang diuji.

Proses sebelumnya dilakukan lagi. Secara total, kasus uji ini mengharuskan perangkat untuk terhubung setidaknya 12 kali secara total. Stempel waktu yang dikumpulkan digunakan untuk memvalidasi bahwa jitter backoff digunakan oleh perangkat yang sedang diuji. Jika perangkat yang diuji memiliki penundaan mundur eksponensial yang ketat, kasus uji ini akan lulus dengan peringatan.

Kami merekomendasikan penerapan mekanisme Eksponensial Backoff And Jitter pada perangkat yang diuji untuk lulus uji kasus ini.

Definisi kasus uji API:

"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"
      }
   }
]

Memvalidasi bahwa perangkat yang diuji menggunakan backoff eksponensial yang tepat saat menghubungkan kembali dengan broker setidaknya lima kali. Pialang mencatat stempel waktu perangkat di bawah permintaan CONNECT yang diuji, melakukan validasi paket, berhenti tanpa mengirim CONNACK ke perangkat klien, dan menunggu perangkat yang diuji untuk mengirim ulang permintaan. Stempel waktu yang dikumpulkan digunakan untuk memvalidasi bahwa backoff eksponensial digunakan oleh perangkat yang sedang diuji.

Kami merekomendasikan penerapan mekanisme Eksponensial Backoff And Jitter pada perangkat yang diuji untuk lulus uji kasus ini.

Definisi kasus uji API:

"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"
      }
   }
]      

Memvalidasi jika perangkat yang sedang diuji menggunakan jitter dan backoff yang diperlukan saat menyambung kembali setelah terputus dari server. Device Advisor memutuskan sambungan perangkat dari server setidaknya lima kali dan mengamati perilaku perangkat untuk koneksi ulang MQTT. Device Advisor mencatat stempel waktu permintaan CONNECT untuk perangkat yang sedang diuji, melakukan validasi paket, jeda tanpa mengirim CONNACK ke perangkat klien, dan menunggu perangkat yang diuji untuk mengirim ulang permintaan. Stempel waktu yang dikumpulkan digunakan untuk memvalidasi bahwa perangkat yang diuji menggunakan jitter dan backoff saat menghubungkan kembali. Jika perangkat yang diuji memiliki backoff eksponensial yang ketat atau tidak menerapkan mekanisme backoff jitter yang tepat, kasus uji ini akan lulus dengan peringatan. Jika perangkat yang diuji telah menerapkan mekanisme backoff linier atau mundur konstan, pengujian akan gagal.

Untuk lulus kasus uji ini, kami sarankan menerapkan mekanisme Eksponensial Backoff And Jitter pada perangkat yang sedang diuji.

Definisi kasus uji API:

"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"
      }
   }
]

Memvalidasi jika perangkat yang sedang diuji menggunakan jitter dan backoff yang diperlukan saat menyambung kembali pada koneksi yang tidak stabil. Device Advisor memutuskan sambungan perangkat dari server setelah lima koneksi berhasil, dan mengamati perilaku perangkat untuk koneksi ulang MQTT. Device Advisor mencatat stempel waktu permintaan CONNECT untuk perangkat yang sedang diuji, melakukan validasi paket, mengirim kembali CONNACK, memutuskan sambungan, mencatat stempel waktu pemutusan, dan menunggu perangkat yang diuji untuk mengirim ulang permintaan. Stempel waktu yang dikumpulkan digunakan untuk memvalidasi bahwa perangkat yang diuji menggunakan jitter dan backoff saat menyambung kembali setelah koneksi berhasil tetapi tidak stabil. Jika perangkat yang diuji memiliki backoff eksponensial yang ketat atau tidak menerapkan mekanisme backoff jitter yang tepat, kasus uji ini akan lulus dengan peringatan. Jika perangkat yang diuji telah menerapkan mekanisme backoff linier atau mundur konstan, pengujian akan gagal.

Untuk lulus kasus uji ini, kami sarankan menerapkan mekanisme Eksponensial Backoff And Jitter pada perangkat yang sedang diuji.

Definisi kasus uji API:

"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"
      }
   }
]

Memvalidasi bahwa perangkat yang sedang diuji menerbitkan pesan dengan QoS0 atau QoS1. Anda juga dapat memvalidasi topik pesan dan payload dengan menentukan nilai topik dan payload dalam pengaturan pengujian.

"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"
      }
   }
]      

Memvalidasi bahwa perangkat yang sedang diuji meneruskan pesan yang dikirim dengan QoS1, jika broker tidak mengirim PUBACK. Anda juga dapat memvalidasi topik pesan dengan menentukan topik ini di pengaturan pengujian. Perangkat klien tidak boleh memutuskan sambungan sebelum menerbitkan ulang pesan. Tes ini juga memvalidasi bahwa pesan yang diterbitkan ulang memiliki pengenal paket yang sama dengan aslinya. Selama eksekusi pengujian, jika perangkat kehilangan koneksi dan terhubung kembali, case uji akan diatur ulang tanpa gagal dan perangkat harus melakukan langkah-langkah kasus uji lagi.

Definisi kasus uji API:

"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"
      }
   }
]      

Memvalidasi bahwa perangkat yang sedang diuji menerbitkan pesan dengan diset retainFlag el ke true. Anda dapat memvalidasi topik dan payload pesan dengan menetapkan nilai topik dan payload di pengaturan pengujian. Jika yang retainFlag dikirim dalam paket PUBLISH tidak disetel ke true, kasus uji akan gagal.

Definisi kasus uji API:

"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"
      }
   }
]      

Memvalidasi bahwa perangkat yang sedang diuji menerbitkan pesan dengan properti pengguna yang benar. Anda dapat memvalidasi properti pengguna dengan menyetel pasangan nama-nilai di pengaturan pengujian. Jika properti pengguna tidak disediakan atau tidak cocok, kasus uji gagal.

Definisi kasus uji API:

"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"
      }
   }
]      

Memvalidasi bahwa perangkat yang sedang diuji berlangganan topik MQTT. Anda juga dapat memvalidasi topik yang berlangganan perangkat yang sedang diuji dengan menentukan topik ini di pengaturan pengujian.

Definisi kasus uji API:

"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"
      }
   }
]      

Memvalidasi bahwa perangkat yang sedang diuji mencoba lagi langganan yang gagal ke topik MQTT. Server kemudian menunggu dan tidak mengirim SUBACK. Jika perangkat klien tidak mencoba lagi langganan, pengujian gagal. Perangkat klien harus mencoba lagi langganan yang gagal dengan Id paket yang sama. Anda juga dapat memvalidasi topik yang berlangganan perangkat yang sedang diuji dengan menentukan topik ini di pengaturan pengujian. Selama eksekusi pengujian, jika perangkat kehilangan koneksi dan terhubung kembali, case uji akan diatur ulang tanpa gagal dan perangkat harus melakukan langkah-langkah kasus uji lagi.

Definisi kasus uji API:

"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"
      }
   }
]      

Kasus uji ini memvalidasi jika perangkat yang diuji terputus saat tidak menerima respons ping. Sebagai bagian dari kasus uji ini, Device Advisor memblokir tanggapan yang dikirim AWS IoT Core untuk permintaan publikasi, berlangganan, dan ping. Ini juga memvalidasi jika perangkat yang diuji memutuskan koneksi MQTT.

Definisi kasus uji API:

"tests":[
    {
       "name":"Mqtt No Ack PingResp",
       "configuration": 
          //optional:
          "EXECUTION_TIMEOUT":"306",   // in seconds
       },
       "test":{
          "id":"MQTT_No_Ack_PingResp",
          "version":"0.0.0"
       }
    }
]

Kasus uji ini memvalidasi perilaku perangkat saat terputus dari sesi persisten. Kasus uji memeriksa apakah perangkat dapat menyambung kembali, melanjutkan langganan ke topik pemicunya tanpa secara eksplisit berlangganan ulang, menerima pesan yang disimpan dalam topik, dan bekerja seperti yang diharapkan selama sesi persisten. Ketika kasus uji ini lulus, ini menunjukkan bahwa perangkat klien dapat mempertahankan sesi persisten dengan AWS IoT Core broker dengan cara yang diharapkan. Untuk informasi selengkapnya tentang S AWS IoT esi Persisten, lihat Menggunakan sesi persisten MQTT.

Dalam kasus pengujian ini, perangkat klien diharapkan untuk TERHUBUNG dengan flag sesi bersih yang disetel ke false, dan kemudian berlangganan topik pemicu. AWS IoT Core Setelah berlangganan berhasil, perangkat akan terputus oleh AWS IoT Core Device Advisor. Saat perangkat dalam keadaan terputus, payload pesan QoS 1 akan disimpan dalam topik itu. Device Advisor kemudian akan mengizinkan perangkat klien untuk terhubung kembali dengan titik akhir pengujian. Pada titik ini, karena ada sesi persisten, perangkat klien diharapkan untuk melanjutkan langganan topiknya tanpa mengirim paket SUBSCRIBE tambahan dan menerima pesan QoS 1 dari broker. Setelah menghubungkan kembali, jika perangkat klien berlangganan kembali ke topik pemicunya lagi dengan mengirimkan paket SUBSCRIBE tambahan and/or jika klien gagal menerima pesan yang disimpan dari topik pemicu, kasus uji akan gagal.

Definisi kasus uji API:

"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"
      }
   }
]      

Kasus uji ini membantu memvalidasi perilaku perangkat saat perangkat yang terputus menyambung kembali ke sesi persisten yang kedaluwarsa. Setelah sesi berakhir, kami mengharapkan perangkat untuk berlangganan kembali ke topik yang sebelumnya berlangganan dengan secara eksplisit mengirim paket SUBSCRIBE baru.

Selama koneksi pertama, kami mengharapkan perangkat uji TERHUBUNG dengan broker AWS IoT, karena CleanSession benderanya diatur ke false untuk memulai sesi persisten. Perangkat kemudian harus berlangganan topik pemicu. Kemudian perangkat terputus oleh AWS IoT Core Device Advisor, setelah berlangganan berhasil dan inisiasi sesi persisten. Setelah pemutusan, Dev AWS IoT Core ice Advisor memungkinkan perangkat uji untuk terhubung kembali dengan titik akhir pengujian. Pada titik ini, ketika perangkat uji mengirim paket CONNECT lain, AWS IoT Core Device Advisor mengirimkan kembali paket CONNACK yang menunjukkan bahwa sesi persisten telah kedaluwarsa. Perangkat uji perlu menafsirkan paket ini dengan benar, dan diharapkan untuk berlangganan kembali ke topik pemicu yang sama lagi saat sesi persisten dihentikan. Jika perangkat uji tidak berlangganan kembali ke pemicu topiknya lagi, kasus uji gagal. Agar tes lulus, perangkat perlu memahami bahwa sesi persisten telah berakhir, dan mengirim kembali paket SUBSCRIBE baru untuk topik pemicu yang sama di koneksi kedua.

Jika kasus uji ini lulus untuk perangkat uji, ini menunjukkan bahwa perangkat dapat menangani koneksi ulang pada berakhirnya sesi persisten dengan cara yang diharapkan.

Definisi kasus uji API:

"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"
      }
   }
]