Tes durasi panjang - AWS IoT Core

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, tes durasi panjang memeriksa perilaku perangkat dalam berbagai skenario dunia nyata selama masa pakai perangkat. Device Advisor mengatur pengujian dalam urutan yang paling efisien. Pengujian menghasilkan hasil dan log, termasuk log ringkasan dengan metrik berguna tentang kinerja perangkat saat diuji.

MQTTkasus uji durasi panjang

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

MQTTalur eksekusi kasus uji durasi panjang

Ada tiga fase dalam pelaksanaan kasus uji durasi MQTT panjang:

“Eksekusi uji Durasi MQTT Panjang” yang menunjukkan eksekusi pengujian Dasar, Eksekusi tes lanjutan, dan waktu eksekusi tambahan.

Eksekusi tes dasar

Pada fase ini, test case menjalankan tes sederhana secara paralel. Pengujian memvalidasi jika perangkat memiliki operasi yang dipilih dalam konfigurasi.

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

CONNECT

Skenario ini memvalidasi jika perangkat mampu membuat koneksi yang sukses dengan broker.

Alur koneksi dasar yang mencakup perangkat yang mengirim CONNECT pesan dan Broker merespons dengan CONNACK pesan dengan kode pengembalian yang berhasil.

PUBLISH

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 diterima oleh perangkat.

Alur PUBLISH QoS 0 yang mencakup perangkat yang mengirim PUBLISH pesan dengan level QoS 0.
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 pengujian ditandai sebagai Lulus dengan peringatan, bersama dengan pesan sistem. Selama eksekusi pengujian, jika perangkat kehilangan koneksi dan menyambung kembali, skenario pengujian akan diatur ulang tanpa gagal dan perangkat harus melakukan langkah-langkah skenario pengujian lagi.

Alur PUBLISH QoS 1 yang mencakup perangkat yang mengirim PUBLISH pesan dengan level QoS 1 dan beberapa interaksi dengan broker.

SUBSCRIBE

Skenario ini memvalidasi jika perangkat berhasil berlangganan 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 SUBACK pesan.

Alur SUBSCRIBE QoS 0 yang mencakup perangkat yang mengirim SUBSCRIBE pesan dengan level QoS 0 dan broker merespons dengan pesan dan kode Sukses Maksimum QoS 0. 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 pengujian ditandai sebagai Lulus dengan peringatan, bersama dengan pesan sistem. Selama eksekusi pengujian, jika perangkat kehilangan koneksi dan menyambung kembali, skenario pengujian akan diatur ulang tanpa gagal dan perangkat harus melakukan langkah-langkah skenario pengujian lagi.

Alur SUBSCRIBE QoS 1 yang mencakup perangkat yang mengirim SUBSCRIBE pesan dengan level QoS 1 dan beberapa interaksi dengan broker.

RECONNECT

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 satu kali sebelumnya selama rangkaian pengujian. Sebaliknya, itu akan menandai tes sebagai Lulus.

RECONNECTAliran antara DUT dan broker.

Eksekusi tes lanjutan

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

RETURNPUBACKPADA QoS 1 SUBSCRIPTION

catatan

Pilih skenario ini hanya jika perangkat Anda mampu melakukan langganan QoS 1.

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

RETURNPUBACKON QoS 1 SUBSCTIPTION mengalir antara DUT dan broker.

RECEIVE LARGE PAYLOAD

catatan

Pilih skenario ini hanya jika perangkat Anda mampu melakukan langganan QoS 1.

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

RECEIVELARGEPAYLOADAliran antara DUT dan broker.

PERSISTENT SESSION

catatan

Pilih skenario ini hanya jika perangkat Anda mampu melakukan langganan QoS 1 dan dapat mempertahankan sesi persisten.

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

  • Perangkat terhubung ke broker dengan langganan QoS 1 aktif dan sesi persisten diaktifkan.

  • Perangkat berhasil terputus dari broker selama sesi berlangsung.

  • Perangkat terhubung kembali ke broker dan melanjutkan langganan ke topik pemicunya tanpa secara eksplisit berlangganan kembali topik tersebut.

  • Perangkat berhasil menerima pesan yang disimpan oleh broker untuk topik berlangganan dan berjalan seperti yang diharapkan.

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

PERSISTENTSESSIONAliran antara DUT dan broker.

KEEP ALIVE

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 dikirim untukPUBLISH,SUBSCRIBE, dan PINGREQ pesan. Ini juga memvalidasi jika perangkat yang diuji memutuskan koneksi. MQTT

KEEPALIVEAliran antara DUT dan broker.

INTERMITTENT CONNECTIVITY

Skenario ini memvalidasi jika perangkat dapat terhubung kembali ke broker setelah broker memutus perangkat pada interval acak untuk jangka waktu acak.

INTERMITTENTCONNECTIVITYAliran antara DUT dan broker.

RECONNECT BACKOFF

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

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

RECONNECTBACKOFFAliran antara DUT dan broker.

LONG SERVER DISCONNECT

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

LONGSERVERDISCONNECTAliran antara DUT dan broker.

Waktu eksekusi tambahan

Waktu eksekusi tambahan adalah waktu pengujian 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.

MQTTopsi konfigurasi uji durasi panjang

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

OPERATIONS

Daftar operasi yang dilakukan perangkat, sepertiCONNECT, PUBLISH danSUBSCRIBE. Kasus uji menjalankan skenario berdasarkan operasi yang ditentukan. Operasi yang tidak ditentukan dianggap valid.

{ "OPERATIONS": ["PUBLISH", "SUBSCRIBE"] //by default the test assumes device can CONNECT }
SCENARIOS

Berdasarkan operasi yang dipilih, kasus uji menjalankan skenario untuk memvalidasi perilaku perangkat. Ada dua jenis skenario:

  • Skenario Dasar adalah tes sederhana yang memvalidasi jika perangkat dapat melakukan operasi yang dipilih di atas sebagai bagian dari konfigurasi. Ini dipilih sebelumnya berdasarkan operasi yang ditentukan dalam konfigurasi. Tidak ada lagi input yang diperlukan dalam konfigurasi.

  • Skenario Lanjutan adalah skenario yang lebih kompleks yang dilakukan terhadap perangkat untuk memvalidasi jika perangkat mengikuti praktik terbaik saat dipenuhi dengan kondisi dunia nyata. Ini opsional dan dapat diteruskan sebagai larik skenario ke input konfigurasi rangkaian pengujian.

{ "SCENARIOS": [ // list of advanced scenarios "PUBACK_QOS_1", "RECEIVE_LARGE_PAYLOAD", "PERSISTENT_SESSION", "KEEP_ALIVE", "INTERMITTENT_CONNECTIVITY", "RECONNECT_BACK_OFF", "LONG_SERVER_DISCONNECT" ] }
BASIC_TESTS_EXECUTION_TIME_OUT:

Waktu maksimum kasus uji akan menunggu semua tes dasar selesai. Nilai default adalah 60 menit. Nilai ini dapat dikonfigurasi dari 30 hingga 120 menit.

LONG_SERVER_DISCONNECT_TIME:

Waktu yang dibutuhkan untuk kasus uji untuk memutuskan sambungan dan menyambungkan kembali perangkat selama pengujian Long Server Disconnect. Nilai default adalah 60 menit. Nilai ini dapat dikonfigurasi dari 30 hingga 120 menit.

ADDITIONAL_EXECUTION_TIME:

Mengkonfigurasi opsi ini menyediakan jendela waktu setelah semua tes selesai, untuk memantau peristiwa antara perangkat dan broker. Nilai defaultnya adalah 0 menit. Nilai ini dapat dikonfigurasi dari 0 hingga 120 menit.

BACKOFF_CONNECTION_ATTEMPTS:

Opsi ini mengonfigurasi berapa kali perangkat terputus oleh kasus uji. Ini digunakan oleh tes Reconnect Backoff. Nilai defaultnya adalah 5 percobaan. Nilai ini dapat dikonfigurasi dari 5 hingga 10.

LONG_PAYLOAD_FORMAT:

Format payload pesan yang diharapkan perangkat saat kasus uji diterbitkan ke topik QoS 1 yang dilanggan oleh perangkat.

APIdefinisi kasus uji:

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

MQTTlog ringkasan kasus uji durasi panjang

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

  • Keep Alive timer dikonfigurasi pada perangkat.

  • Bendera sesi persisten dikonfigurasi pada perangkat.

  • Jumlah koneksi perangkat selama uji coba.

  • Jenis backoff koneksi ulang perangkat, jika divalidasi untuk uji backoff sambungkan kembali.

  • Topik yang dipublikasikan perangkat, selama uji kasus dijalankan.

  • Topik yang dilanggani perangkat, selama uji kasus dijalankan.