Debug skenario uji stres - Performance Testing

Setelah mengonfigurasi skenario uji stres, Anda dapat men-debug skenario tersebut untuk memastikan konfigurasinya sesuai dengan kebutuhan bisnis Anda. Hal ini juga memastikan keberhasilan uji stres. Topik ini menjelaskan cara men-debug skenario Performance Testing (PTS) dan skenario JMeter.

Prasyarat

Skenario PTS atau skenario JMeter telah dibuat. Untuk informasi lebih lanjut, lihat Buat skenario PTS atau Buat skenario JMeter.

Prosedur

Masuk ke Konsol PTS dan pilih Performance Test > Scenarios.
Di halaman Scenarios, temukan skenario uji stres yang diinginkan dan klik Edit di kolom Actions untuk masuk ke halaman Edit Scenario. Di bagian bawah halaman Edit Scenario, klik Debug untuk men-debug skenario uji stres.
Selama proses debugging, Anda dapat mengklik ikon di pojok kanan atas kotak dialog Debug untuk meminimalkan kotak dialog. Ini memungkinkan Anda memantau proses debugging kapan saja di jendela pop-up yang ditampilkan di pojok kanan bawah halaman Edit Scenario. Untuk memaksimalkan kotak dialog Debug, Anda dapat mengklik jendela pop-up.
Lihat log permintaan dari semua tautan dalam hasil debugging. Untuk melihat informasi debugging dari Operasi API tunggal, klik nama Operasi API.
Jika ingin men-debug Operasi API tunggal, Anda dapat mengklik Debug API di sebelah kanan nama Operasi API pada tab Scenario Settings. Setelah debugging selesai, Anda dapat melihat hasilnya.
Penting
PTS tidak mendukung debugging Operasi API tunggal dalam virtual private cloud (VPC). Jika Anda ingin men-debug Operasi API tunggal dalam VPC, Anda dapat mengklik Debug di bagian bawah halaman Edit Scenario untuk men-debug seluruh skenario uji stres.

Deskripsi antarmuka untuk men-debug skenario PTS

Gambar berikut menunjukkan informasi yang ditampilkan di antarmuka saat Anda men-debug skenario PTS.

Penilaian asersi
Tanda silang (×) menunjukkan terjadinya pengecualian respons. Anda dapat mengklik Operasi API tempat terjadinya pengecualian respons dan melihat detail respons Operasi API di sebelah kanan.
Status respons
Kata kunci Status Exception atau kode status seperti 200, 302, 403, 503, atau 500 mungkin ditampilkan. Jika kata kunci Status Exception ditampilkan, tidak ada respons yang dikembalikan karena permintaan habis waktu atau URL permintaan yang berisi badan permintaan salah. Kesalahan ini dapat terjadi jika fungsi yang ditentukan tidak dapat diidentifikasi atau format URL tidak valid.
Catatan
Anda dapat melihat detail permintaan dan respons setiap Operasi API yang didebug. Anda dapat menyelesaikan masalah terkait status respons berdasarkan instruksi berikut:
- Jika Status Exception ditampilkan untuk status respons, Anda dapat melihat informasi pengecualian di bagian Error Information tab Response Details di sebelah kanan. Sebagai contoh, dalam gambar di atas, penyebab pengecualian adalah parameter tidak valid, yang menunjukkan bahwa fungsi sistem digunakan secara salah.
- Jika kode status selain 200 ditampilkan untuk status respons, Anda dapat melihat informasi respons dan menyelesaikan masalah berdasarkan log di server terkait.
- Jika terjadi pengecualian dalam asersi, Anda dapat melihat informasi asersi di bagian Checkpoint information tab Response Details. Jika tidak ada informasi asersi yang ditampilkan, tidak ada nilai parameter keluaran yang diperoleh.
Informasi kesalahan
Detail tentang respons abnormal ditampilkan, seperti informasi timeout, kesalahan parameter, dan penolakan koneksi.
Detail konsumsi waktu permintaan dalam siklus hidup inti pada tab Timing
Anda dapat melihat informasi pengecualian yang muncul selama proses debugging menggunakan model waterfall waktu. Semua pesan kesalahan dapat disajikan dalam model waterfall waktu.
Sebagai contoh, jika Anda mengaktifkan pengalihan 302 saat mengonfigurasi skenario uji stres, Anda dapat memeriksa apakah pengalihan dilakukan selama uji stres dan jalur pengalihan dalam waterfall waktu.
Titik masuk untuk menguji ekspresi parameter keluaran
Jika Anda ingin mengekstrak string tertentu berdasarkan detail respons permintaan, Anda dapat menggunakan ekspresi reguler. Untuk memastikan bahwa string dapat diekstraksi, Anda dapat menguji apakah ekspresi reguler benar saat Anda men-debug skenario uji stres. Jika parameter keluaran yang ada tidak memenuhi kebutuhan bisnis Anda, Anda dapat mengonfigurasi ulang parameter keluaran berdasarkan kebutuhan bisnis Anda. Dalam banyak kasus, string yang dapat Anda ekstrak berdasarkan detail respons permintaan adalah badan respons bertipe TEXT.
Catatan
Penguraian format Application/JSON dan TEXT/JSON sederhana. Oleh karena itu, fitur pengujian ekspresi parameter keluaran tidak disediakan untuk detail respons dalam format ini.
1. Di sebelah kanan kotak dialog Debug, klik Click to test the regular expression untuk Operasi API.
2. Dalam kotak dialog yang muncul, konfigurasikan parameter Source, Regular Expression, dan Nth match. Lalu, klik Test Expression. Anda dapat menilai sebelumnya apakah informasi yang diekstraksi memenuhi harapan Anda berdasarkan hasil pencocokan detail respons.
3. Jika Anda perlu mengubah konfigurasi parameter keluaran, klik Sync Output Parameter untuk menyinkronkan ekspresi reguler ke parameter keluaran Operasi API.
  Catatan
  Setelah debugging selesai, Anda harus kembali ke tab Scenario Settings dan mengonfigurasi nama parameter keluaran di subtab Output Parameter Definition.

Deskripsi antarmuka untuk menguji skenario JMeter

Gambar berikut menunjukkan informasi yang ditampilkan di antarmuka saat Anda men-debug skenario JMeter.

Klik Sampler. Lalu, lihat detail permintaan, detail respons, dan waterfall waktu di bagian Sampling log.

Bagian Sampling log menampilkan informasi berikut:
- Tab General menampilkan URL, metode, dan kode status permintaan.
- Tab Request Details menampilkan header, body, dan paket asli permintaan.
- Tab Response Details menampilkan header, body, dan paket asli respons.
- Tab Timing menampilkan informasi konsumsi waktu dari semua Operasi API.
Bagian Engine logs menampilkan log operasi Apache JMeter. Jika tidak ada log sampel yang dikembalikan setelah debugging, Anda dapat menganalisis dan menyelesaikan masalah berdasarkan pesan kesalahan di log mesin. Untuk informasi tentang kesalahan umum dan penyebab kesalahan, lihat Kesalahan umum.