Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Kasus uji Device Advisor
Device Advisor menyediakan pengujian bawaan dalam enam kategori.
+ [TLS](device-advisor-tests-tls.md)
+ [MQTT](device-advisor-tests-mqtt.md)
+ [Bayangan](device-advisor-tests-shadow.md)
+ [Eksekusi Job](device-advisor-tests-job-execution.md)
+ [Izin dan kebijakan](device-advisor-tests-permissions-policies.md)
+ [Tes durasi panjang](device-advisor-tests-long-duration.md)
## Kasus uji Penasihat Perangkat agar memenuhi syarat untuk Program Kualifikasi AWS Perangkat.
Perangkat Anda harus lulus tes berikut agar memenuhi syarat sesuai dengan [Program Kualifikasi AWS Perangkat](https://aws.amazon.com/partners/programs/dqp/).
**catatan**
Ini adalah daftar tes kualifikasi yang direvisi.
+ [TLS Connect](device-advisor-tests-tls.md#TLS_Connect) (“TLS Connect”)
+ [Sertifikat Server Nama Subjek Salah TLS](device-advisor-tests-tls.md#TLS_Incorrect_Subject_Name) (“Nama Umum Subjek Salah (CN) /Nama Alternatif Subjek (SAN)”)
+ [Sertifikat Server Tidak Aman TLS](device-advisor-tests-tls.md#TLS_Unsecure_Server_Cert) (“Tidak Ditandatangani Oleh CA yang Diakui”)
+ [Dukungan Perangkat TLS untuk AWS IoT Cipher Suites](device-advisor-tests-tls.md#TLS_DeviceSupport_For_IOT) (“Dukungan Perangkat TLS AWS IoT untuk Suite Cipher yang direkomendasikan”)
+ [TLS Menerima Fragmen Ukuran Maksimum](device-advisor-tests-tls.md#TLS_MaximumSize) (“TLS Menerima Fragmen Ukuran Maksimum”)
+ Sertifikat Server [Kedaluwarsa TLS (“Sertifikat server](device-advisor-tests-tls.md#TLS_Expired_Server_Cert) kedaluwarsa”)
+ [Sertifikat Server Ukuran Besar TLS](device-advisor-tests-tls.md#TLS_LargeServerCert) (“Sertifikat Server Ukuran Besar TLS”)
+ [MQTT Connect](device-advisor-tests-mqtt.md#MQTT_Connect) (“Perangkat kirim CONNECT AWS IoT Core ke (Happy case)”)
+ [MQTT Berlangganan (“Bisa Berlangganan](device-advisor-tests-mqtt.md#MQTT_Subscribe) (Happy Case)”)
+ [MQTT Publikasikan](device-advisor-tests-mqtt.md#MQTT_Publish) (“QoS0 (Happy Case)”)
+ [MQTT Connect Jitter Retries (“Perangkat menghubungkan percobaan ulang dengan jitter](device-advisor-tests-mqtt.md#MQTT_ConnectJitterBackoff) backoff - Tidak ada respons CONNACK”)
# TLS
Gunakan tes ini untuk menentukan apakah protokol keamanan lapisan transport (TLS) antara perangkat Anda dan AWS IoT aman.
**catatan**
Device Advisor sekarang mendukung TLS 1.3.
## Jalan Bahagia
**TLS Connect**
Memvalidasi jika perangkat yang diuji dapat menyelesaikan jabat tangan TLS. AWS IoT Tes ini tidak memvalidasi implementasi MQTT perangkat klien.
**Example Definisi kasus uji API:**
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Untuk hasil terbaik, kami merekomendasikan nilai batas waktu 2 menit.
```
"tests":[
{
"name":"my_tls_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Connect",
"version":"0.0.0"
}
}
]
```
**Example Output kasus uji:**
+ **Lulus** — Perangkat yang diuji menyelesaikan jabat tangan TLS dengan. AWS IoT
+ **Lulus dengan peringatan** — Perangkat yang diuji menyelesaikan jabat tangan TLS dengan AWS IoT, tetapi ada pesan peringatan TLS dari perangkat atau. AWS IoT
+ **Gagal** - Perangkat yang diuji gagal menyelesaikan jabat tangan TLS AWS IoT karena kesalahan jabat tangan.
**TLS Menerima Fragmen Ukuran Maksimum**
Kasus uji ini memvalidasi bahwa perangkat Anda dapat menerima dan memproses fragmen ukuran maksimum TLS. Perangkat pengujian Anda harus berlangganan topik yang telah dikonfigurasi sebelumnya dengan QoS 1 untuk menerima muatan besar. Anda dapat menyesuaikan payload dengan konfigurasi`${payload}`.
**Example Definisi kasus uji API:**
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Untuk hasil terbaik, kami merekomendasikan nilai batas waktu 2 menit.
```
"tests":[
{
"name":"TLS Receive Maximum Size Fragments",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
"PAYLOAD_FORMAT":"{"message":"${payload}"}", // A string with a placeholder ${payload}, or leave it empty to receive a plain string.
"TRIGGER_TOPIC": "test_1" // A topic to which a device will subscribe, and to which a test case will publish a large payload.
},
"test":{
"id":"TLS_Receive_Maximum_Size_Fragments",
"version":"0.0.0"
}
}
]
```
## Cipher Suite
**TLS Device Support untuk Cipher Suites yang AWS IoT direkomendasikan**
[Memvalidasi bahwa cipher suite dalam pesan TLS Client Hello dari perangkat yang diuji berisi cipher suite yang direkomendasikan.AWS IoT](transport-security.md) Ini memberikan lebih banyak wawasan tentang cipher suite yang didukung oleh perangkat.
**Example Definisi kasus uji API:**
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"tests":[
{
"name":"my_tls_support_aws_iot_cipher_suites_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Support_AWS_IoT_Cipher_Suites",
"version":"0.0.0"
}
}
]
```
**Example Output kasus uji:**
+ **Lulus** — Perangkat di bawah rangkaian cipher pengujian berisi setidaknya satu dari rangkaian AWS IoT sandi yang direkomendasikan dan tidak berisi rangkaian sandi yang tidak didukung.
+ **Lulus dengan peringatan** - Suite cipher perangkat berisi setidaknya satu AWS IoT cipher suite tetapi:
1. Itu tidak mengandung suite cipher yang direkomendasikan
1. Ini berisi cipher suite yang tidak didukung oleh. AWS IoT
Kami menyarankan Anda memverifikasi bahwa setiap cipher suite yang tidak didukung aman.
+ **Gagal** - Perangkat di bawah rangkaian cipher pengujian tidak berisi rangkaian sandi yang AWS IoT didukung.
## Sertifikat Server Ukuran Lebih Besar
**Sertifikat Server Ukuran Besar TLS**
Validasi di perangkat Anda dapat menyelesaikan jabat tangan TLS AWS IoT saat menerima dan memproses sertifikat server ukuran yang lebih besar. Ukuran sertifikat server (dalam byte) yang digunakan oleh pengujian ini lebih besar daripada yang saat ini digunakan dalam kasus uji **TLS Connect** dan IoT Core sebesar 20 Selama kasus pengujian ini, AWS IoT uji ruang buffer perangkat Anda untuk TLS Jika ruang buffer cukup besar, jabat tangan TLS tidak ada kesalahan. Pengujian ini tidak memvalidasi implementasi MQTT perangkat. Kasus uji ds setelah proses jabat tangan TLS selesai.
**Example Definisi kasus uji API:**
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Untuk hasil terbaik, kami merekomendasikan nilai batas waktu 2 menit. Jika kasus pengujian ini gagal tetapi kasus uji **TLS Connect** lolos, kami sarankan Anda meningkatkan batas ruang buffer perangkat untuk TLS Meningkatkan batas ruang buffer memastikan bahwa perangkat Anda dapat memproses sertifikat server ukuran yang lebih besar jika ukurannya bertambah.
```
"tests":[
{
"name":"my_tls_large_size_server_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Large_Size_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Output kasus uji:**
+ **Lulus** — Perangkat yang diuji menyelesaikan jabat tangan TLS dengan. AWS IoT
+ **Lulus dengan peringatan** — Perangkat yang diuji menyelesaikan jabat tangan TLS dengan AWS IoT, tetapi ada pesan peringatan TLS baik dari perangkat atau. AWS IoT
+ **Gagal** — Perangkat yang diuji gagal menyelesaikan jabat tangan TLS AWS IoT karena kesalahan selama proses jabat tangan.
## Sertifikat Server TLS Tidak Aman
**Tidak Ditandatangani Oleh CA yang Diakui**
Memvalidasi bahwa perangkat yang sedang diuji menutup sambungan jika disajikan dengan sertifikat server tanpa tanda tangan yang valid dari ATS CA. Perangkat hanya boleh terhubung ke titik akhir yang menampilkan sertifikat yang valid.
**Example Definisi kasus uji API:**
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"tests":[
{
"name":"my_tls_unsecure_server_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Unsecure_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Output kasus uji:**
+ **Lulus** — Perangkat yang diuji menutup koneksi.
+ **Gagal** - Perangkat yang diuji menyelesaikan jabat tangan TLS dengan. AWS IoT
**TLS Sertifikat Server Nama Subjek Salah/Nama Umum Subjek Salah (CN) /Nama Alternatif Subjek (SAN)**
Memvalidasi bahwa perangkat yang sedang diuji menutup koneksi jika disajikan dengan sertifikat server untuk nama domain yang berbeda dari yang diminta.
**Example Definisi kasus uji API:**
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"tests":[
{
"name":"my_tls_incorrect_subject_name_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"TLS_Incorrect_Subject_Name_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Output kasus uji:**
+ **Lulus** — Perangkat yang diuji menutup koneksi.
+ **Gagal** - Perangkat yang diuji menyelesaikan jabat tangan TLS dengan. AWS IoT
## Sertifikat Server Kedaluwarsa TLS
**Sertifikat server kedaluwarsa**
Memvalidasi bahwa perangkat yang sedang diuji menutup koneksi jika disajikan dengan sertifikat server yang kedaluwarsa.
**Example Definisi kasus uji API:**
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"tests":[
{
"name":"my_tls_expired_cert_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", //in seconds
},
"test":{
"id":"TLS_Expired_Server_Cert",
"version":"0.0.0"
}
}
]
```
**Example Output kasus uji:**
+ **Lulus** — Perangkat yang diuji menolak untuk menyelesaikan jabat tangan TLS. AWS IoT Perangkat mengirimkan pesan peringatan TLS sebelum menutup koneksi.
+ **Lulus dengan peringatan** — Perangkat yang diuji menolak untuk menyelesaikan jabat tangan TLS. AWS IoT Namun, itu tidak mengirim pesan peringatan TLS sebelum menutup koneksi.
+ **Gagal** - Perangkat yang diuji melengkapi jabat tangan TLS dengan. AWS IoT
# MQTT
## CONNECT, DISCONNECT, dan RECONNECT
**“Perangkat mengirim CONNECT ke AWS IoT Core (Happy case)”**
Memvalidasi bahwa perangkat yang sedang diuji mengirimkan permintaan CONNECT.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"tests":[
{
"name":"my_mqtt_connect_test",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
},
"test":{
"id":"MQTT_Connect",
"version":"0.0.0"
}
}
]
```
**“Perangkat dapat mengembalikan PUBACK ke topik arbitrer untuk QoS1"**
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](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits).
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit. `PAYLOAD_SIZE`dapat dikonfigurasi ke nilai antara 0 dan 128 kilobyte. Mendefinisikan ukuran payload akan menggantikan konten payload karena Device Advisor akan mengirimkan payload yang telah ditentukan sebelumnya dengan ukuran yang diberikan kembali ke perangkat.
```
"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"
}
}
]
```
**“Perangkat menghubungkan percobaan ulang dengan jitter backoff - Tidak ada respons CONNACK”**
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](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) pada perangkat yang diuji untuk lulus kasus uji ini.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 4 menit.
```
"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"
}
}
]
```
**“Perangkat menghubungkan percobaan ulang dengan backoff eksponensial - Tidak ada respons CONNACK”**
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](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) pada perangkat yang diuji untuk lulus kasus uji ini.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 4 menit.
```
"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"
}
}
]
```
**“Perangkat terhubung kembali dengan jitter backoff - Setelah server terputus”**
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](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) pada perangkat yang diuji.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 4 menit.
Jumlah upaya koneksi ulang untuk memvalidasi backoff dapat diubah dengan menentukan. `RECONNECTION_ATTEMPTS` Jumlahnya harus antara 5 dan 10. Nilai bawaannya adalah 5.
```
"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"
}
}
]
```
**“Perangkat terhubung kembali dengan jitter backoff - Pada koneksi yang tidak stabil”**
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](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) pada perangkat yang diuji.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 4 menit.
Jumlah upaya koneksi ulang untuk memvalidasi backoff dapat diubah dengan menentukan. `RECONNECTION_ATTEMPTS` Jumlahnya harus antara 5 dan 10. Nilai bawaannya adalah 5.
```
"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"
}
}
]
```
## Publikasikan
**“QoS0 (Kasus Bahagia)”**
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.
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"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"
}
}
]
```
**“QoS1 terbitkan coba lagi - Tanpa PUBACK”**
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:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Disarankan setidaknya selama 4 menit.
```
"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"
}
}
]
```
**“Publikasikan pesan yang disimpan”**
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 pengaturan pengujian. Jika yang `retainFlag` dikirim dalam paket PUBLISH tidak disetel ke true, kasus uji akan gagal.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit. Untuk menjalankan kasus uji ini, tambahkan `iot:RetainPublish` tindakan dalam [peran perangkat](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role) Anda.
```
"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"
}
}
]
```
**“Publikasikan dengan Properti Pengguna”**
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:*
Ini adalah MQTT5 satu-satunya kasus uji.
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"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"
}
}
]
```
## Langganan
**“Bisa Berlangganan (Happy Case)”**
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:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"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"
}
}
]
```
**“Berlangganan Coba Lagi - Tanpa SUBACK”**
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:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 4 menit.
```
"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"
}
}
]
```
## Jaga-Hidup
**“Mqtt Tanpa Ack” PingResp**
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:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan batas waktu yang lebih besar dari 1,5 kali `keepAliveTime` nilainya.
Maksimum `keepAliveTime` harus tidak lebih dari 230 detik untuk tes ini.
```
"tests":[
{
"name":"Mqtt No Ack PingResp",
"configuration":
//optional:
"EXECUTION_TIMEOUT":"306", // in seconds
},
"test":{
"id":"MQTT_No_Ack_PingResp",
"version":"0.0.0"
}
}
]
```
## Sesi Persisten
**“Sesi Persisten (Happy Case)”**
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](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
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 and/or jika klien gagal menerima pesan yang disimpan dari topik pemicu, kasus uji akan gagal.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu minimal 4 menit. Pada koneksi pertama, perangkat klien perlu secara eksplisit berlangganan `TRIGGER_TOPIC` yang tidak berlangganan sebelumnya. Untuk lulus test case, perangkat klien harus berhasil berlangganan `TRIGGER_TOPIC` dengan QoS 1. Setelah terhubung kembali, perangkat klien diharapkan untuk memahami bahwa ada sesi persisten aktif; jadi harus menerima pesan tersimpan yang dikirim oleh topik pemicu dan mengembalikan PUBACK untuk pesan tertentu.
```
"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"
}
}
]
```
**“Sesi Persisten - Kedaluwarsa Sesi”**
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:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu minimal 4 menit. Perangkat uji perlu secara eksplisit berlangganan`TRIGGER_TOPIC`, yang sebelumnya tidak berlangganan. Untuk lulus test case, perangkat uji harus mengirim paket CONNECT dengan `CleanSession` flag disetel ke false, dan berhasil berlangganan topik pemicu dengan QoS 1. Setelah koneksi berhasil, AWS IoT Core Device Advisor memutus perangkat. Setelah pemutusan, AWS IoT Core Device Advisor memungkinkan perangkat untuk terhubung kembali, dan perangkat diharapkan untuk berlangganan ulang yang sama `TRIGGER_TOPIC` karena AWS IoT Core Device Advisor akan menghentikan sesi persisten.
```
"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"
}
}
]
```
# Bayangan
Gunakan pengujian ini untuk memverifikasi perangkat Anda yang sedang diuji, gunakan layanan AWS IoT Device Shadow dengan benar. Untuk informasi selengkapnya, lihat [AWS IoT Layanan Device Shadow](iot-device-shadows.md). Jika kasus pengujian ini dikonfigurasi dalam rangkaian pengujian Anda, maka penyediaan sesuatu diperlukan saat memulai suite run.
**MQTT over** tidak WebSocket didukung saat ini.
## Publikasikan
***“Perangkat menerbitkan status setelah terhubung (Happy case)”***
Memvalidasi jika perangkat dapat mempublikasikan statusnya setelah terhubung AWS IoT Core
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"tests":[
{
"name":"my_shadow_publish_reported_state",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"SHADOW_NAME": "SHADOW_NAME",
"REPORTED_STATE": {
"STATE_ATTRIBUTE": "STATE_VALUE"
}
},
"test":{
"id":"Shadow_Publish_Reported_State",
"version":"0.0.0"
}
}
]
```
`REPORTED_STATE`Dapat disediakan untuk validasi tambahan pada status bayangan persis perangkat Anda, setelah terhubung. Secara default, kasus uji ini memvalidasi status penerbitan perangkat Anda.
Jika tidak `SHADOW_NAME` disediakan, kasus uji akan mencari pesan yang dipublikasikan ke awalan topik tipe bayangan Unnamed (klasik) secara default. Berikan nama bayangan jika perangkat Anda menggunakan tipe bayangan bernama. Lihat [Menggunakan bayangan di perangkat](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html) untuk informasi selengkapnya.
## Perbarui
***“Pembaruan perangkat melaporkan status ke status yang diinginkan (Happy case)”***
Memvalidasi jika perangkat Anda membaca semua pesan pembaruan yang diterima dan menyinkronkan status perangkat agar sesuai dengan properti status yang diinginkan. Perangkat Anda harus mempublikasikan status terbaru yang dilaporkan setelah disinkronkan. Jika perangkat Anda sudah memiliki bayangan yang ada sebelum menjalankan pengujian, pastikan status yang diinginkan dikonfigurasi untuk kasus pengujian dan status laporan yang ada belum cocok. Anda dapat mengidentifikasi pesan pembaruan Shadow yang dikirim oleh Device Advisor dengan melihat **ClientToken**bidang di dokumen Shadow sebagaimana `DeviceAdvisorShadowTestCaseSetup` adanya.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 2 menit.
```
"tests":[
{
"name":"my_shadow_update_reported_state",
"configuration": {
"DESIRED_STATE": {
"STATE_ATTRIBUTE": "STATE_VALUE"
},
// optional:
"EXECUTION_TIMEOUT":"300", // in seconds
"SHADOW_NAME": "SHADOW_NAME"
},
"test":{
"id":"Shadow_Update_Reported_State",
"version":"0.0.0"
}
}
]
```
`DESIRED_STATE`Harus memiliki setidaknya satu atribut dan nilai terkait.
Jika tidak `SHADOW_NAME` disediakan, maka kasus uji mencari pesan yang dipublikasikan ke awalan topik dari tipe bayangan Unnamed (klasik) secara default. Berikan nama bayangan jika perangkat Anda menggunakan tipe bayangan bernama. Lihat [Menggunakan bayangan di perangkat](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html) untuk informasi selengkapnya.
# Eksekusi Job
**“Perangkat dapat menyelesaikan eksekusi pekerjaan”**
Kasus uji ini membantu Anda memvalidasi jika perangkat Anda dapat menerima pembaruan menggunakan AWS IoT Pekerjaan, dan mempublikasikan status pembaruan yang berhasil. Untuk informasi selengkapnya tentang AWS IoT Pekerjaan, lihat [Pekerjaan](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
Agar berhasil menjalankan kasus uji ini, ada dua AWS topik cadangan yang Anda perlukan untuk memberikan [Peran Perangkat](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role) Anda. Untuk berlangganan pesan terkait aktivitas pekerjaan, gunakan topik **pemberitahuan dan beri** **tahu berikutnya**. Peran perangkat Anda harus memberikan tindakan PUBLISH untuk topik berikut:
+ ****\$1aws/things/thingName /jobs/joBid/dapatkan****
+ ****\$1 aws/things/ ThingName /jobs/joBid/update****
Disarankan untuk memberikan tindakan SUBSCRIBE dan RECEIVE untuk topik-topik berikut:
+ **\$1 aws/hal/ThingName/**jobs/get/accepted
+ ****\$1aws/things/thingName /jobs/ joBid/dapatkan/ditolak****
+ ****\$1aws/things/ ThingName /jobs/ joBid/update/diterima****
+ ****\$1aws/things/ ThingName /jobs/ joBid/update/ditolak****
Disarankan untuk memberikan tindakan BERLANGGANAN untuk topik berikut:
+ **\$1aws/things/ ThingName /jobs/notify-next**
Untuk informasi selengkapnya tentang topik yang dicadangkan ini, lihat topik yang dicadangkan untuk [AWS IoT Pekerjaan](https://docs.aws.amazon.com/iot/latest/developerguide/reserved-topics.html#reserved-topics-job).
**MQTT over** tidak WebSocket didukung saat ini.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 5 menit. Kami merekomendasikan nilai batas waktu 3 menit. Bergantung pada dokumen AWS IoT Job atau sumber yang disediakan, sesuaikan nilai batas waktu (misalnya, jika pekerjaan akan memakan waktu lama untuk dijalankan, tentukan nilai batas waktu yang lebih lama untuk kasus uji). Untuk menjalankan pengujian, diperlukan dokumen AWS IoT Job yang valid atau ID pekerjaan yang sudah ada. Dokumen AWS IoT Job dapat disediakan sebagai dokumen JSON atau tautan S3. Jika dokumen pekerjaan disediakan, memberikan ID pekerjaan adalah opsional. Jika ID lowongan diberikan, Device Advisor akan menggunakan ID tersebut saat membuat AWS IoT Job atas nama Anda. Jika dokumen pekerjaan tidak disediakan, Anda dapat memberikan ID yang ada di wilayah yang sama dengan saat Anda menjalankan kasus uji. Dalam hal ini, Device Advisor akan menggunakan AWS IoT Job tersebut saat menjalankan test case.
```
"tests": [
{
"name":"my_job_execution",
"configuration": {
// optional:
// Test case will create a job task by using either JOB_DOCUMENT or JOB_DOCUMENT_SOURCE.
// If you manage the job task on your own, leave it empty and provide the JOB_JOBID (self-managed job task).
// JOB_DOCUMENT is a JSON formatted string
"JOB_DOCUMENT": "{
\"operation\":\"reboot\",
\"files\" : {
\"fileName\" : \"install.py\",
\"url\" : \"${aws:iot:s3-presigned-url:https://s3.amazonaws.com/bucket-name/key}\"
}
}",
// JOB_DOCUMENT_SOURCE is an S3 link to the job document. It will be used only if JOB_DOCUMENT is not provided.
"JOB_DOCUMENT_SOURCE": "https://s3.amazonaws.com/bucket-name/key",
// JOB_JOBID is mandatory, only if neither document nor document source is provided. (Test case needs to know the self-managed job task id).
"JOB_JOBID": "String",
// JOB_PRESIGN_ROLE_ARN is used for the presign Url, which will replace the placeholder in the JOB_DOCUMENT field
"JOB_PRESIGN_ROLE_ARN": "String",
// Presigned Url expiration time. It must be between 60 and 3600 seconds, with the default value being 3600.
"JOB_PRESIGN_EXPIRES_IN_SEC": "Long"
"EXECUTION_TIMEOUT": "300", // in seconds
},
"test": {
"id": "Job_Execution",
"version": "0.0.0"
}
}
]
```
Untuk informasi selengkapnya tentang membuat dan menggunakan dokumen pekerjaan, lihat [dokumen pekerjaan](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).
# Izin dan kebijakan
Anda dapat menggunakan pengujian berikut untuk menentukan apakah kebijakan yang dilampirkan pada sertifikat perangkat Anda mengikuti praktik terbaik standar.
**MQTT over** tidak WebSocket didukung saat ini.
**“Kebijakan terlampir sertifikat perangkat tidak mengandung wildcard”**
Memvalidasi jika kebijakan izin yang terkait dengan perangkat mengikuti praktik terbaik dan tidak memberi perangkat izin lebih dari yang diperlukan.
*Definisi kasus uji API:*
`EXECUTION_TIMEOUT`memiliki nilai default 1 menit. Sebaiknya atur batas waktu minimal 30 detik.
```
"tests":[
{
"name":"my_security_device_policies",
"configuration": {
// optional:
"EXECUTION_TIMEOUT":"60" // in seconds
},
"test": {
"id": "Security_Device_Policies",
"version": "0.0.0"
}
}
]
```
# 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.
## Kasus uji durasi panjang MQTT
Dalam kasus uji durasi panjang MQTT, 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.
## Alur eksekusi kasus uji durasi panjang MQTT
Ada tiga fase dalam pelaksanaan kasus uji durasi panjang MQTT:
![\[“Eksekusi uji Durasi Panjang MQTT” yang menunjukkan eksekusi pengujian Dasar, Eksekusi tes lanjutan, dan waktu eksekusi tambahan.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/mqtt-execution-flow.png)
### 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:
#### MENGHUBUNG
Skenario ini memvalidasi jika perangkat mampu membuat koneksi yang sukses dengan broker.
![\[Alur koneksi dasar yang mencakup perangkat yang mengirim pesan CONNECT dan Broker merespons dengan pesan CONNACK dengan kode pengembalian yang berhasil.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/basic-connect.png)
#### 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 diterima oleh perangkat.
![\[Aliran PUBLISH QoS 0 yang mencakup perangkat yang mengirim pesan PUBLISH dengan level QoS 0.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/Qos0.png)
##### 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 lagi `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 lagi`PUBLISH`, 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.
![\[Aliran PUBLISH QoS 1 yang mencakup perangkat yang mengirim pesan PUBLISH dengan level QoS 1 dan beberapa interaksi dengan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/Qos1.png)
#### BERLANGGANAN
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 pesan SUBACK.
![\[Aliran SUBSCRIBE QoS 0 yang mencakup perangkat yang mengirim pesan SUBSCRIBE dengan level QoS 0 dan broker merespons dengan pesan SUBACK dan kode Sukses Maksimum QoS 0.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/subscribe-Qos0.png)
##### 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 lagi `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 lagi`SUBSCRIBE`, 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 pesan SUBSCRIBE dengan level QoS 1 dan beberapa interaksi dengan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/subscribe-Qos1.png)
#### SAMBUNGKAN 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 satu kali sebelumnya selama rangkaian pengujian. Sebaliknya, itu akan menandai tes sebagai **Lulus**.
![\[Aliran RECONNECT antara DUT dan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/reconnect.png)
### 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.
#### KEMBALIKAN PUBACK PADA LANGGANAN QoS 1
**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 pesan`PUBACK`.
![\[RETURN PUBACK ON QoS 1 SUBSCTIPTION mengalir antara DUT dan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/return-puback.png)
#### MENERIMA MUATAN BESAR
**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.
![\[Aliran RECEIVE PAYLOAD BESAR antara DUT dan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/large-payload.png)
#### SESI PERSISTEN
**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 persisten MQTT](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).
![\[Aliran SESI PERSISTEN antara DUT dan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/persistent-session.png)
#### 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 dikirim untuk`PUBLISH`,`SUBSCRIBE`, dan `PINGREQ` pesan. Ini juga memvalidasi jika perangkat yang diuji memutuskan koneksi MQTT.
![\[Aliran KEEP ALIVE antara DUT dan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/keep-alive.png)
#### KONEKTIVITAS INTERMITEN
Skenario ini memvalidasi jika perangkat dapat terhubung kembali ke broker setelah broker memutus perangkat pada interval acak untuk jangka waktu acak.
![\[Aliran KONEKTIVITAS INTERMITEN antara DUT dan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/intermittent.png)
#### SAMBUNGKAN KEMBALI 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](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) pada perangkat yang diuji.
![\[Aliran RECONNECT BACKOFF antara DUT dan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/reconnect-backoff.png)
#### PEMUTUSAN SERVER PANJANG
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.
![\[Aliran LONG SERVER DISCONNECT antara DUT dan broker.\]](http://docs.aws.amazon.com/id_id/iot/latest/developerguide/images/longserver-disconnect.png)
### 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.
## Opsi konfigurasi uji durasi panjang MQTT
Semua opsi konfigurasi yang disediakan untuk uji durasi panjang MQTT adalah opsional. Pilihan berikut tersedia:
**OPERASI**
Daftar operasi yang dilakukan perangkat, seperti`CONNECT`, `PUBLISH` dan`SUBSCRIBE`. 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
}
```
**SKENARIO**
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\$1TESTS\$1EXECUTION\$1TIME\$1OUT:**
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\$1SERVER\$1DISCONNECT\$1TIME:**
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.
**TAMBAHAN\$1EXECUTION\$1TIME:**
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\$1CONNECTION\$1ATTEMPTS:**
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.
**FORMAT LONG\$1PAYLOAD\$1:**
Format payload pesan yang diharapkan perangkat saat kasus uji diterbitkan ke topik QoS 1 yang dilanggan oleh perangkat.
**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, 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.*