Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Tes durasi panjang

Tes durasi panjang adalah rangkaian pengujian baru yang memantau perilaku perangkat saat beroperasi dalam jangka waktu yang lebih lama. Dibandingkan dengan menjalankan pengujian individual yang berfokus pada perilaku tertentu perangkat, uji durasi panjang memeriksa perilaku perangkat dalam berbagai skenario dunia nyata selama masa pakai perangkat. Device Advisor mengatur pengujian dalam urutan seefisien mungkin. Pengujian menghasilkan hasil dan log, termasuk log ringkasan dengan metrik berguna tentang kinerja perangkat saat sedang diuji.

Kasus uji durasi panjang MQTT

Dalam kasus uji durasi panjang MQTT, perilaku perangkat awalnya diamati dalam skenario happy case seperti MQTT Connect, Subscribe, Publish, dan Reconconnect. Kemudian, perangkat diamati dalam beberapa skenario kegagalan yang kompleks seperti MQTT Reconconnect Backoff, Long Server Disconnect, dan Intermittent Connectivity.

Alur eksekusi kasus uji durasi panjang MQTT

Ada tiga fase dalam pelaksanaan kasus uji durasi panjang MQTT:

Eksekusi tes dasar

Pada fase ini, kasus uji menjalankan tes sederhana secara paralel. Tes memvalidasi jika perangkat memiliki operasi yang dipilih dalam konfigurasi.

Kumpulan tes dasar dapat mencakup yang berikut, berdasarkan operasi yang dipilih:

MENGHUBUNG

Skenario ini memvalidasi jika perangkat dapat membuat koneksi yang berhasil dengan broker.

MENERBITKAN

Skenario ini memvalidasi jika perangkat berhasil menerbitkan terhadap broker.

QoS 0

Kasus uji ini memvalidasi jika perangkat berhasil mengirim PUBLISH pesan ke broker selama publikasi dengan QoS 0. Tes tidak menunggu PUBACK pesan untuk diterima oleh perangkat.

QoS 1

Dalam kasus uji ini, perangkat diharapkan mengirim dua PUBLISH pesan ke broker dengan QoS 1. Setelah PUBLISH pesan pertama, broker menunggu hingga 15 detik sebelum merespons. Perangkat harus mencoba kembali PUBLISH pesan asli dengan pengenal paket yang sama dalam jendela 15 detik. Jika ya, broker merespons dengan PUBACK pesan dan tes memvalidasi. Jika perangkat tidak mencoba lagiPUBLISH, yang asli PUBACK dikirim ke perangkat dan tes ditandai sebagai Lulus dengan peringatan, bersama dengan pesan sistem. Selama eksekusi pengujian, jika perangkat kehilangan koneksi dan terhubung kembali, skenario pengujian akan diatur ulang tanpa gagal dan perangkat harus melakukan langkah-langkah skenario pengujian lagi.

BERLANGGANAN

Skenario ini memvalidasi jika perangkat berhasil berlangganan terhadap broker.

QoS 0

Kasus uji ini memvalidasi jika perangkat berhasil mengirim SUBSCRIBE pesan ke broker selama berlangganan dengan QoS 0. Tes tidak menunggu perangkat menerima pesan SUBACK.

QoS 1

Dalam kasus uji ini, perangkat diharapkan mengirim dua SUBSCRIBE pesan ke broker dengan QoS 1. Setelah SUBSCRIBE pesan pertama, broker menunggu hingga 15 detik sebelum merespons. Perangkat harus mencoba kembali SUBSCRIBE pesan asli dengan pengenal paket yang sama dalam jendela 15 detik. Jika ya, broker merespons dengan SUBACK pesan dan tes memvalidasi. Jika perangkat tidak mencoba lagiSUBSCRIBE, yang asli SUBACK dikirim ke perangkat dan tes ditandai sebagai Lulus dengan peringatan, bersama dengan pesan sistem. Selama eksekusi pengujian, jika perangkat kehilangan koneksi dan terhubung kembali, skenario pengujian akan diatur ulang tanpa gagal dan perangkat harus melakukan langkah-langkah skenario pengujian lagi.

MENYAMBUNG KEMBALI

Skenario ini memvalidasi jika perangkat berhasil terhubung kembali dengan broker setelah perangkat terputus dari koneksi yang berhasil. Device Advisor tidak akan memutuskan sambungan perangkat jika terhubung lebih dari sekali sebelumnya selama rangkaian pengujian. Sebaliknya, itu akan menandai tes sebagai Lul us.

Eksekusi tes lanjutan

Pada fase ini, uji coba menjalankan pengujian yang lebih kompleks secara serial untuk memvalidasi jika perangkat mengikuti praktik terbaik. Tes lanjutan ini tersedia untuk seleksi dan dapat dipilih keluar jika tidak diperlukan. Setiap pengujian lanjutan memiliki nilai batas waktu sendiri berdasarkan apa yang dituntut skenario.

KEMBALIKAN PUBACK PADA LANGGANAN QoS 1

Skenario ini memvalidasi jika, setelah perangkat berlangganan topik dan menerima PUBLISH pesan dari broker, ia mengembalikan pesanPUBACK.

MENERIMA MUATAN BESAR

Skenario ini memvalidasi jika perangkat merespons dengan PUBACK pesan setelah menerima PUBLISH pesan dari broker untuk topik QoS 1 dengan muatan besar. Format muatan yang diharapkan dapat dikonfigurasi menggunakan LONG_PAYLOAD_FORMAT opsi.

SESI PERSISTEN

Skenario ini memvalidasi perilaku perangkat dalam mempertahankan sesi persisten. Tes memvalidasi ketika kondisi berikut terpenuhi:

Untuk informasi selengkapnya tentang S AWS IoT esi Persisten, lihat Menggunakan sesi persisten MQTT.

TETAP HIDUP

Skenario ini memvalidasi jika perangkat berhasil terputus setelah tidak menerima respons ping dari broker. Koneksi harus memiliki timer keep-alive yang valid yang dikonfigurasi. Sebagai bagian dari tes ini, broker memblokir semua tanggapan yang dikirimPUBLISH,SUBSCRIBE, dan PINGREQ pesan. Ini juga memvalidasi jika perangkat yang diuji memutuskan koneksi MQTT.

KONEKTIVITAS INTERMITEN

Skenario ini memvalidasi jika perangkat dapat terhubung kembali ke broker setelah broker memutuskan perangkat secara acak untuk periode waktu acak.

SAMBUNGKAN KEMBALI BACKOFF

Skenario ini memvalidasi jika perangkat memiliki mekanisme mundur yang diterapkan ketika broker memutuskan sambungannya beberapa kali. Device Advisor melaporkan jenis backoff sebagai eksponensial, jitter, linier atau konstan. Jumlah upaya mundur dapat dikonfigurasi menggunakan opsi. BACKOFF_CONNECTION_ATTEMPTS Nilai bawaannya adalah 5. Nilai dapat dikonfigurasi antara 5 dan 10.

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

PEMUTUSAN SERVER YANG PANJANG

Skenario ini memvalidasi jika perangkat berhasil terhubung kembali setelah broker memutuskan perangkat untuk jangka waktu yang lama (hingga 120 menit). Waktu pemutusan server dapat dikonfigurasi menggunakan LONG_SERVER_DISCONNECT_TIME opsi. Nilai defaultnya adalah 120 menit. Nilai ini dapat dikonfigurasi dari 30 hingga 120 menit.

Waktu eksekusi tambahan

Waktu eksekusi tambahan adalah waktu tes menunggu setelah menyelesaikan semua tes di atas dan sebelum mengakhiri kasus uji. Pelanggan menggunakan periode waktu tambahan ini untuk memantau dan mencatat semua komunikasi antara perangkat dan broker. Waktu eksekusi tambahan dapat dikonfigurasi menggunakan ADDITIONAL_EXECUTION_TIME opsi. Secara default, opsi ini diatur ke 0 menit dan bisa 0 hingga 120 menit.

Opsi konfigurasi uji durasi panjang MQTT

Semua opsi konfigurasi yang disediakan untuk uji durasi panjang MQTT adalah opsional. Pilihan berikut tersedia:

Definisi kasus uji API:

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

Log ringkasan kasus uji durasi panjang MQTT

Kasus uji durasi panjang MQTT berjalan untuk durasi yang lebih lama daripada kasus uji biasa. Log ringkasan terpisah disediakan, yang mencantumkan peristiwa penting seperti koneksi perangkat, publikasi, dan berlangganan selama menjalankan. Rincian termasuk apa yang diuji, apa yang tidak diuji dan apa yang gagal. Di akhir log, pengujian menyertakan ringkasan semua peristiwa yang terjadi selama uji coba dijalankan. Hal ini mencakup: