

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

# Tes durasi panjang
<a name="device-advisor-tests-long-duration"></a>

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
<a name="long-duration-test-case"></a>

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
<a name="long-duration-test-case-execution-flow"></a>

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
<a name="basic-tests-execution"></a>

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
<a name="basic-tests-execution-connect"></a>

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
<a name="basic-tests-execution-publish"></a>

Skenario ini memvalidasi jika perangkat berhasil menerbitkan terhadap broker.

##### QoS 0
<a name="publish-qos0"></a>

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
<a name="publish-qos1"></a>

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
<a name="basic-tests-execution-subscribe"></a>

Skenario ini memvalidasi jika perangkat berhasil berlangganan broker.

##### QoS 0
<a name="subscribe-qos0"></a>

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
<a name="subscribe-qos1"></a>

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
<a name="basic-tests-execution-reconnect"></a>

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
<a name="advanced-tests-execution"></a>

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
<a name="advanced-tests-execution-return-puback"></a>

**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
<a name="advanced-tests-execution-receive-large-payload"></a>

**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
<a name="advanced-tests-execution-persistent-session"></a>

**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
<a name="advanced-tests-execution-keep-alive"></a>

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
<a name="advanced-tests-execution-intermittent-connectivity"></a>

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
<a name="advanced-tests-execution-reconnect-backoff"></a>

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
<a name="advanced-tests-execution-longserver-disconnect"></a>

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
<a name="additional-execution-time"></a>

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
<a name="long-duration-test-case-config-options"></a>

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
<a name="long-duration-test-case-summary-log"></a>

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.*