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 payload dan ukuran payload dapat dikonfigurasi untuk kasus uji ini. Jika ukuran payload dikonfigurasi, Device Advisor akan menimpa nilai untuk konten payload, dan mengirim payload yang telah ditentukan ke perangkat dengan ukuran yang diinginkan. Ukuran muatan adalah nilai antara 0 hingga 128 dan tidak boleh melebihi 128 KB. AWS IoT Core menolak mempublikasikan dan menghubungkan permintaan yang lebih besar dari 128 KB, seperti yang terlihat di broker AWS IoT Core pesan dan batas protokol dan halaman 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 diuji menggunakan backoff jitter yang tepat saat terhubung kembali dengan broker setidaknya lima kali. Broker mencatat stempel waktu perangkat di bawah permintaan CONNECT pengujian, melakukan validasi paket, berhenti sejenak 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 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 diuji. Jika perangkat yang diuji memiliki penundaan backoff eksponensial yang ketat, kasus uji ini akan lulus dengan peringatan.

Kami merekomendasikan implementasi mekanisme Exponential Backoff And Jitter pada perangkat yang diuji untuk lulus kasus uji 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 terhubung kembali dengan broker setidaknya lima kali. Broker mencatat stempel waktu perangkat di bawah permintaan CONNECT pengujian, melakukan validasi paket, berhenti sejenak 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 diuji.

Kami merekomendasikan implementasi mekanisme Exponential Backoff And Jitter pada perangkat yang diuji untuk lulus kasus uji 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 diuji menggunakan jitter dan backoff yang diperlukan saat menyambung kembali setelah terputus dari server. Device Advisor memutus perangkat dari server setidaknya lima kali dan mengamati perilaku perangkat untuk penyambungan ulang MQTT. Device Advisor mencatat stempel waktu permintaan CONNECT untuk perangkat yang sedang diuji, melakukan validasi paket, berhenti sejenak 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 menyambung 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 backoff linier atau mekanisme backoff konstan, pengujian akan gagal.

Untuk lulus kasus uji ini, kami sarankan untuk menerapkan mekanisme Exponential Backoff And Jitter pada perangkat yang 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 diuji menggunakan jitter dan backoff yang diperlukan saat menyambung kembali pada koneksi yang tidak stabil. Device Advisor memutus 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 backoff linier atau mekanisme backoff konstan, pengujian akan gagal.

Untuk lulus kasus uji ini, kami sarankan untuk menerapkan mekanisme Exponential Backoff And Jitter pada perangkat yang 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 diuji menerbitkan kembali 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 memublikasikan 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 menyambung kembali, kasus 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 retainFlag disetel ke true. Anda dapat memvalidasi topik dan payload pesan dengan menyetel nilai topik dan payload dalam setelan 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 dalam 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 dilanggani perangkat yang sedang diuji dengan menentukan topik ini di setelan 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 ulang 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 dilanggani perangkat yang sedang diuji dengan menentukan topik ini di setelan pengujian. Selama eksekusi pengujian, jika perangkat kehilangan koneksi dan menyambung kembali, kasus 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 dari AWS IoT Core 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 berlangganan ulang secara eksplisit, menerima pesan yang disimpan dalam topik, dan bekerja seperti yang diharapkan selama sesi persisten. Ketika kasus uji ini berlalu, ini menunjukkan bahwa perangkat klien dapat mempertahankan sesi persisten dengan AWS IoT Core broker dengan cara yang diharapkan. Untuk informasi selengkapnya tentang Sesi AWS IoT Persisten, lihat Menggunakan sesi persisten MQTT.

Dalam kasus pengujian ini, perangkat klien diharapkan untuk TERHUBUNG dengan flag sesi bersih yang disetel ke false, lalu berlangganan topik pemicu. AWS IoT Core Setelah berlangganan berhasil, perangkat akan terputus oleh AWS IoT Core Device Advisor. Saat perangkat dalam keadaan terputus, muatan 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 menyambung kembali, jika perangkat klien berlangganan kembali ke topik pemicunya lagi dengan mengirimkan paket SUBSCRIBE tambahan dan/atau 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 tersambung kembali ke sesi persisten yang kedaluwarsa. Setelah sesi berakhir, kami mengharapkan perangkat untuk berlangganan kembali ke topik yang sebelumnya berlangganan dengan secara eksplisit mengirimkan paket SUBSCRIBE baru.

Selama koneksi pertama, kami mengharapkan perangkat uji untuk TERHUBUNG dengan broker AWS IoT, karena CleanSession benderanya disetel ke false untuk memulai sesi persisten. Perangkat kemudian harus berlangganan topik pemicu. Kemudian perangkat diputuskan oleh AWS IoT Core Device Advisor, setelah berlangganan berhasil dan memulai sesi persisten. Setelah pemutusan sambungan, AWS IoT Core Device 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 lolos untuk perangkat uji, ini menunjukkan bahwa perangkat dapat menangani koneksi ulang saat 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"
      }
   }
]