Pengujian Ketahanan (Soak Test) dalam Perangkat Lunak: Arti dan Contoh
Thomas Hamilton
⚡ Ringkasan Cerdas
Pengujian Beban Berkelanjutan (Soak Testing) menerapkan beban realistis dan berkelanjutan pada aplikasi dalam jangka waktu yang lama untuk mengungkap masalah yang hanya muncul seiring waktu. Kebocoran memori, kehabisan koneksi, dan penurunan kinerja yang lambat adalah cacat yang dirancang untuk dideteksi.
Apa itu Uji Perendaman?
Pengujian Rendam adalah jenis pengujian non fungsional yang digunakan untuk mengukur kinerja aplikasi perangkat lunak di bawah beban bervolume besar untuk jangka waktu yang lama. Tujuan dari pengujian Soak adalah untuk memastikan apakah aplikasi perangkat lunak dapat mempertahankan penggunaan dalam jumlah besar dan untuk memeriksa apa yang akan terjadi di luar ekspektasi desainnya.
Gambar di bawah menggambarkan siklus pengujian yang menunjukkan pada tahap mana Pengujian Rendam (Jenis Tes Kinerja) dilakukan pada suatu aplikasi.
Pada pengujian jenis ini, yang pada dasarnya dipantau adalah pemanfaatan memori oleh suatu aplikasi dalam suatu sistem. Ini adalah pengujian pada tingkat sistem, untuk mengetahui apakah sistem akan bertahan terhadap volume penggunaan yang sangat tinggi dan untuk melihat apa yang akan terjadi di luar ekspektasi desainnya.
Mengapa Pengujian Rendam?
Suatu sistem mungkin berperilaku normal ketika digunakan selama 2 jam, tetapi ketika sistem yang sama digunakan terus menerus selama 10 jam atau lebih dari itu maka sistem tersebut mungkin gagal atau berperilaku tidak normal/acak/dapat crash. Untuk memprediksi kegagalan tersebut, Uji Rendam dilakukan.
Kapan Melakukan Pengujian Rendam?
Pengujian Perendaman harus dilakukan dalam skenario berikut: –
- Sebelum aplikasi yang dibangun disebarkan ke klien, yaitu sebelum aplikasi apa pun dirilis pada platform tertentu, aplikasi tersebut harus melalui serangkaian uji beban yang berhasil pada tingkat lalu lintas yang tinggi atau setara. Setelah itu pengujian rendam dilakukan. Ini membantu kita menentukan cara menjalankan aplikasi tertentu untuk jangka waktu lama. Jika masalah seperti kebocoran memori/kerusakan memori ditemukan selama periode Soak, maka harus segera dilaporkan.
- Waktu terbaik untuk melakukan pengujian perendaman adalah pada akhir pekan karena aplikasi harus berada dalam kondisi berjalan selama siang atau malam. Hal ini sepenuhnya bergantung pada keterbatasan situasi pengujian. Tes rendam adalah salah satu persyaratan kepatuhan terpenting yang harus diikuti dengan ketat oleh setiap perusahaan.
Strategi Pengujian Rendam
Pengujian Perendaman Sesi Panjang adalah strategi di mana sistem berada di bawah beban untuk waktu yang lebih lama.
Contoh sederhananya adalah pengguna tetap login ke sistem selama berjam-jam untuk menjalankan sejumlah transaksi bisnis. Dengan cara ini, banyak data yang dibuat. Dapat terjadi banyak beban pada sistem/server database yang dapat mengakibatkan terhentinya/crashnya sistem/server database.
Dalam Pengujian Rendam Sesi Panjang, aktivitas beberapa hari (misalnya 30 hari) dilakukan dalam jangka waktu terbatas (misalnya 2 hari). Jumlah transaksi dalam jangka waktu terbatas ini harus sama atau melampaui transaksi beberapa hari. Fokusnya harus pada jumlah transaksi yang diproses. Bagian terpenting dari Soak Testing adalah memeriksa memori yang tersedia di CPU dan jumlah memori yang akan digunakan. Kita perlu mencatat penggunaan memori di awal dan akhir tes rendam. Jika perlu, maka penggunaan fasilitas memori seperti Java Mesin Virtual juga penting dan perlu dipantau.
Berikut adalah beberapa pemeriksaan lagi yang perlu dilakukan oleh pengguna/penguji mana pun sebelum memulai Pengujian Rendam:
a) Pantau konsumsi sumber daya database.
b) Pantau konsumsi sumber daya server (misal penggunaan CPU).
c) Tes rendam harus dijalankan dengan konkurensi pengguna yang realistis.
Karakteristik Pengujian Rendam
Metode Pengujian Perendaman standar harus memiliki karakteristik berikut: –
- Durasi sebagian besar Tes Rendam sering kali ditentukan oleh waktu yang tersedia.
- Aplikasi apa pun harus berjalan tanpa gangguan apa pun jika memerlukan jangka waktu yang lama.
- Ini harus mencakup semua skenario yang disepakati oleh para pemangku kepentingan.
- Hampir setiap sistem memiliki periode waktu pemeliharaan rutin dan waktu antara periode jendela tersebut merupakan pendorong utama untuk menentukan cakupan Uji Rendam.
Contoh Pengujian Perendaman
- Dalam kasus domain perbankan ketika ada sejumlah besar data dari pedagang, penguji akan memuat sistem secara terus menerus selama 70 jam hingga 150 jam untuk memeriksa bagaimana perilaku aplikasi selama periode pemuatan ini.
- Misalkan ada 33,000 login yang perlu dimasukkan ke dalam sistem, ini mewakili aktivitas tujuh setengah hari. Dalam hal ini, Tes Rendam selama 60-70 jam dapat dimulai pada Jumat malam sekitar jam 6 sore yang dapat diselesaikan pada hari Jumat. Monday pagi jam 6 pagi. Hanya dengan pengujian seperti itu, akan dimungkinkan untuk mengamati adanya penurunan kinerja dalam kondisi terkendali.
- Dalam kasus Video Game, Nomor WhatsApp aplikasi, dll. melibatkan membiarkan game atau aplikasi dalam keadaan berjalan untuk jangka waktu yang lama, dalam berbagai mode operasi- seperti diam, berhenti di layar judul, dan sebagainya untuk mengetahui apakah suatu aplikasi dapat menangani beban yang diharapkan terus-menerus .
Masalah umum yang diamati selama Pengujian Rendam
- Alokasi memori (kebocoran memori yang pada akhirnya akan mengakibatkan krisis memori atau kesalahan pembulatan yang hanya terjadi seiring berjalannya waktu).
- Pemanfaatan sumber daya basis data (Kegagalan menutup kursor basis data dalam kondisi tertentu yang pada akhirnya akan mengakibatkan seluruh sistem terhenti).
- Hal ini juga dapat menyebabkan penurunan kinerja, yaitu memastikan bahwa waktu respons setelah aktivitas berkelanjutan dalam jangka waktu lama sama baiknya dengan saat awal pengujian.
- Kegagalan untuk menutup koneksi antar tingkatan sistem multi-tingkat dalam keadaan tertentu yang dapat menghentikan beberapa atau semua modul sistem.
- Penurunan bertahap waktu respons beberapa fungsi karena struktur data internal menjadi kurang efisien selama pengujian yang lama.
Bagaimana Tes Ini Sesuai dengan Rangkaian Pengujian Kinerja
Pengujian kinerja adalah istilah umum. Varian-varian di bawah ini hanya berbeda pada bentuk beban yang diterapkan dan durasi penahanannya, itulah sebabnya mengapa seringkali terjadi kebingungan satu sama lain.
| Jenis pengujian | Pola beban | Pertanyaan itu menjawab |
|---|---|---|
| Uji beban | Beban puncak yang diperkirakan, durasi singkat | Apakah sistem tersebut mencapai targetnya dalam kondisi lalu lintas puncak normal? |
| Tes stres | Ditingkatkan melebihi kapasitas hingga terjadi kegagalan. | Di mana letak kerusakannya, dan apakah kegagalannya ditangani dengan baik? |
| Pengujian lonjakan | Lonjakan ekstrem tiba-tiba, lalu penurunan. | Apakah ia mampu bertahan dan pulih dari guncangan lalu lintas? |
| Pengujian ketahanan | Beban normal ditahan selama berjam-jam. | Apakah kinerja menurun seiring waktu? |
| Pengujian perendaman | Beban berkelanjutan dalam jangka waktu yang lama | Apakah terjadi kebocoran memori atau kehabisan sumber daya? |
| Pengujian stabilitas | Beban yang bervariasi di berbagai kondisi | Apakah sistem tetap andal seiring perubahan kondisi? |
| Pengujian volume | Pengguna biasa, volume data sangat besar | Apakah sistem ini mampu menangani pertumbuhan basis data? |
Pengujian daya tahan dan pengujian perendaman sering dianggap sebagai sinonim. Dalam penggunaan umum, keduanya memiliki arti yang sama: keduanya mampu menahan beban berkelanjutan dalam jangka waktu lama. Jika tim membedakannya, pengujian ketahanan (endurance testing) berfokus pada apakah waktu respons meningkat, sementara pengujian beban berlebih (soak testing) berfokus pada konsumsi sumber daya seperti memori, penanganan file, dan kumpulan koneksi. Menjalankan salah satunya biasanya memberikan bukti untuk keduanya.
Metrik Utama yang Perlu Dicatat Selama Pengujian
Suatu pengujian performa hanya akan sebaik apa yang Anda rekam selama proses eksekusi. Rekam keenam hal ini di sisi server dan klien, lalu bandingkan dengan data dasar, bukan hanya berdasarkan firasat.
| metrik | Apa yang dikatakannya padamu | Tanda peringatan |
|---|---|---|
| Waktu respons rata-rata | Pengalaman pengguna tipikal | Pergeseran ke atas apa pun di sepanjang jalur tersebut |
| Waktu respons persentil ke-95 | Pengalaman pengguna paling lambat | Jauh di atas rata-rata, artinya tidak konsisten. |
| Throughput | Permintaan yang diproses per detik | Terjatuh sementara beban tetap konstan |
| Tingkat kesalahan | Persentase permintaan yang gagal atau habis waktu | Kenaikan apa pun di atas ambang batas yang disepakati |
| Penggunaan CPU dan memori | Kapasitas sumber daya server yang tersedia | Kenangan yang terus mendaki dan tak pernah kembali |
| Koneksi dan thread basis data | Kelelahan kolam renang | Jumlah yang terus bertambah tanpa dirilis |
Bacalah nilai rata-rata dan persentil secara bersamaan. Rata-rata 800 ms dengan persentil ke-95 sebesar 900 ms menggambarkan sistem yang konsisten. Rata-rata yang sama dengan persentil ke-95 sebesar 9 detik berarti satu dari dua puluh pengguna mengalami masalah, dan rata-rata tersebut menyembunyikan masalah itu.
Perhatikan bentuknya, bukan hanya nilainya. Dalam pengujian jangka panjang apa pun, garis sumber daya yang datar berarti lulus dan garis yang meningkat berarti ada kebocoran, bahkan ketika angka absolutnya masih berada di dalam batas yang diizinkan pada saat pengujian berakhir.
