Apa itu Pengujian Destruktif dalam Perangkat Lunak?

Oleh: Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Ringkasan Cerdas

Pengujian destruktif sengaja mendorong aplikasi perangkat lunak hingga gagal, mengungkap titik-titik tepat di mana ketahanan (robustness) runtuh akibat penggunaan yang tidak tepat, input yang tidak valid, dan perilaku yang tidak dapat diprediksi yang tidak pernah dijangkau oleh pemeriksaan fungsional biasa.

  • 💥 Ide inti: Aplikasi ini sengaja dibuat gagal agar titik-titik kegagalannya terlihat dan terukur.
  • 🔎 Tidak ada persyaratan yang dibutuhkan: Pengetahuan sebelumnya tentang spesifikasi bersifat opsional, meskipun hal itu mempertajam strategi pengujian.
  • ️ Pasangan yang berlawanan: Pengujian non-destruktif berjalan di jalur yang mudah; pengujian destruktif menyerangnya dari setiap sudut yang salah.
  • 🧰 Pendekatan: Analisis titik kegagalan, tinjauan sejawat penguji, tinjauan bisnis, dan uji coba eksplorasi dengan lembar kerja.
  • 🧪 Metode yang digunakan kembali: Pengujian regresi, antarmuka, partisi kesetaraan, perulangan, dan penerimaan semuanya memiliki tujuan yang merusak.
  • 📉 Batasan yang jujur: Cakupannya sulit dijamin, upaya yang dibutuhkan tinggi, dan temuannya sulit direplikasi.
Baca Selengkapnya

Apa itu pengujian destruktif dalam perangkat lunak beserta metode dan tekniknya?

Apa itu Pengujian Destruktif?

Pengujian yang merusak Pengujian destruktif adalah metode pengujian perangkat lunak yang digunakan untuk menemukan titik kegagalan dalam sebuah program perangkat lunak. Dalam teknik ini, aplikasi sengaja dibuat gagal, sehingga ketahanannya dapat diperiksa dan titik kegagalannya dapat diidentifikasi. Tidak seperti metode pengujian yang memverifikasi apa yang seharusnya dilakukan aplikasi, pengujian destruktif memeriksa perilaku pengguna yang tidak terduga di dalam aplikasi.

Pengetahuan tentang persyaratan asli tidak diperlukan untuk pengujian destruktif. Namun, beberapa pengetahuan memang membantu dalam pengembangan...ping Strategi pengujian yang baik.

Ilustrasi di bawah ini menggambarkan idenya — penguji bekerja melawan produk, bukan bekerja sama dengannya.

Konsep pengujian destruktif: sebuah aplikasi yang sengaja didorong hingga mencapai titik kegagalan.

Mengapa Melakukan Pengujian Destruktif?

  • Hal ini membantu memahami perilaku perangkat lunak yang dapat diprediksi ketika perangkat lunak tersebut digunakan secara tidak tepat.
  • Ini membantu untuk memeriksa ketahanan produk perangkat lunak.
  • Ini mengungkap cacat langka yang tidak pernah dipicu oleh pengguna biasa, tetapi muncul kemudian dalam proses produksi.

Pengujian Destruktif vs Pengujian Non-Destruktif

Kedua pendekatan tersebut saling melengkapi, bukan bersaing. Pengujian non destruktif — juga disebut pengujian jalur positif atau jalur sukses — berinteraksi dengan perangkat lunak dengan benar dan membiarkan build tetap utuh. Pengujian destruktif melakukan hal sebaliknya: ia memasukkan data yang tidak valid dan urutan yang salah hingga terjadi kerusakan.

Aspek Pengujian yang merusak Pengujian non destruktif
Maksud Paksa aplikasi untuk gagal Konfirmasikan bahwa aplikasi berfungsi sesuai spesifikasi.
Masukan yang digunakan Tidak valid, cacat, di luar jangkauan, di luar urutan Data valid dalam rentang yang diharapkan
Pertanyaan terjawab Di mana dan bagaimana cara kerusakannya? Apakah fungsinya sesuai dengan yang seharusnya?
Persyaratan pengetahuan Opsional penting
Biaya tipikal Tingkat lanjut — eksploratif dan terbuka Lebih rendah — terprogram dan dapat diulang
Hasil Titik kegagalan, batas jangkauan, perilaku pemulihan Lulus atau gagal berdasarkan spesifikasi.

Apa yang Anda periksa dalam pengujian destruktif?

Pengujian destruktif melihat kedua sisi batas perilaku:

  • Perilaku perangkat lunak yang tepat
  • Perilaku perangkat lunak yang tidak tepat
  • Penggunaan yang tidak tepat
  • Data masukan yang tidak tepat
  • Data keluaran yang tepat

Dua kondisi berikut harus terpenuhi selama pelaksanaan latihan:

  • Perangkat lunak tidak akan pernah memproses atau menerima data masukan yang tidak valid.
  • Terlepas dari keabsahan atau kebenaran data masukan, perangkat lunak harus selalu menghasilkan data keluaran yang tepat.
Jangan lewatkan:

Bagaimana cara melakukan Pengujian Destruktif?

Pengujian destruktif melibatkan banyak aktivitas, seperti merancang serangkaian skrip pengujian, menjalankan skrip tersebut, melaporkan bug, menutup bug, dan memberikan metrik lulus atau gagal kepada pemangku kepentingan di akhir iterasi.

Ada banyak cara untuk menjalankannya. Beberapa contohnya akan disajikan berikut ini.

  • Metode analisis titik kegagalan: Penelusuran sistem yang menilai apa yang bisa salah di berbagai titik. Bantuan dari seorang analis bisnis dapat dipertimbangkan untuk strategi ini.
  • Peninjauan sejawat oleh penguji: dapatkan kasus uji dianalisis atau ditinjau oleh sesama penguji yang kurang familiar dengan sistem atau fungsi tersebut.
  • Tinjauan bisnis terhadap kasus uji: Pengguna akhir atau pakar sering kali memikirkan skenario valid yang terlewatkan oleh penguji, karena fokus penguji hanya tertuju pada persyaratan yang telah ditetapkan.
  • Lakukan pengujian eksplorasi menggunakan lembar kerja (run sheet): pengujian eksplorasi Dengan adanya lembar kerja (run sheet), tercatat apa saja yang telah diuji, memungkinkan pengujian untuk diulang, dan menjaga cakupan pengujian tetap terkendali.
  • Gunakan sumber lain: Mintalah orang lain untuk menemukan kesalahan pada produk perangkat lunak tersebut dan menganalisis skenario yang mereka temukan.

Contoh Pengujian Destruktif

Perhatikan layar login dan profil aplikasi perbankan. Serangan yang merusak akan berhasil dalam kasus-kasus seperti ini:

  • Tempelkan string sepanjang 5,000 karakter ke dalam kolom yang dibatasi hingga 50 karakter dan pastikan kolom tersebut menolaknya alih-alih memotongnya secara diam-diam.
  • Masukkan huruf, simbol, dan nilai negatif ke dalam kolom jumlah numerik.
  • Melanggar urutan yang diharapkan — langsung membuka halaman konfirmasi pembayaran tanpa menyelesaikan langkah sebelumnya.
  • Tekan tombol kirim berulang kali dan dengan cepat untuk melihat apakah ada data duplikat yang dibuat.
  • Putuskan koneksi jaringan di tengah transaksi dan periksa apakah aplikasi pulih dengan bersih atau meninggalkan catatan yang tidak lengkap.

Setiap kasus memiliki ekspektasi yang jelas: pesan validasi yang jelas, tidak ada kerusakan data, dan tidak ada pengecualian yang tidak ditangani. Jika terjadi hal lain, itu merupakan titik kegagalan yang perlu dilaporkan sebagai cacat.

Metode Pengujian Destruktif

Metode-metode berikut digunakan dalam rekayasa perangkat lunak untuk mencapai tujuan pengujian destruktif:

Teknik Pengujian Destruktif

Teknik-teknik di bawah ini dapat digunakan dengan beberapa modifikasi:

Teknik-teknik terkait yang layak ditambahkan ketika tujuan utamanya adalah kekokohan (robustity) adalah... pengujian negatif, stress testing, pengujian pemulihan ke pengujian kabur.

Keuntungan dan Kerugian Pengujian Destruktif

Ada baiknya menjelaskan secara gamblang tentang konsekuensi yang ditimbulkan sebelum teknik ini direncanakan untuk dirilis.

Kelebihan

  • Revtitik kegagalan yang tidak pernah dicapai oleh pengujian berbasis spesifikasi.
  • Menetapkan batasan jangkauan nyata, sehingga produk dapat dioperasikan di dalam batasan tersebut dengan percaya diri.
  • Mengungkapkan cacat langka yang muncul dalam produksi lama setelah peluncuran produk.
  • Memeriksa daya tahan, kemampuan pemulihan, dan penanganan kesalahan dalam kondisi penyalahgunaan.

Kekurangan

  • Bersifat terbuka, sehingga cakupannya tidak dapat dijamin atau diukur dengan mudah.
  • Memakan waktu dan bergantung pada pengalaman serta kreativitas penguji.
  • Temuan sulit direproduksi tanpa pencatatan langkah-langkah yang digunakan secara cermat.
  • Pengujian yang tidak terkontrol dengan baik dapat merusak data pengujian bersama, sehingga diperlukan lingkungan yang terisolasi.

Pertanyaan Umum Demo Slot

Keduanya tumpang tindih tetapi berbeda dalam cakupannya. Pengujian negatif Pengujian destruktif memeriksa input yang tidak valid yang telah ditentukan terhadap penanganan kesalahan yang diharapkan. Pengujian destruktif lebih luas dan terbuka, mencari kondisi apa pun yang menyebabkan aplikasi gagal.

Biasanya, insinyur QA berpengalaman, didukung oleh rekan-rekan yang tidak familiar dengan modul tersebut dan oleh pengguna bisnis. Pengawasan dari luar sangat penting, karena orang-orang yang membangun fitur tersebut cenderung mengujinya sesuai dengan desainnya.

Setelah rangkaian fungsi stabil, maka kegagalan akan menunjukkan masalah ketahanan, bukan fitur yang belum selesai. Banyak tim menjadwalkannya selama pengujian sistem dan mengulanginya sebelum rilis utama. siklus hidup pengujian.

Model-model tersebut menghasilkan muatan yang cacat, nilai batas, dan urutan tindakan yang tidak biasa dalam volume yang tidak dapat ditandingi oleh penguji mana pun, kemudian memberi peringkat mana yang menghasilkan anomali. Pembelajaran mesin pada data cacat masa lalu juga memprediksi modul mana yang pantas mendapatkan perlakuan paling keras.

Kopilot GitHub Membuat draf generator input, kasus batas, dan rutinitas pembersihan dengan cepat. Penguji tetap memutuskan mode kegagalan mana yang penting dan apakah perilaku yang diamati dianggap sebagai hasil yang dapat diterima.

Input atau urutan yang tepat yang digunakan, kegagalan yang diamati, log dan tangkapan layar, lingkungan, dan tingkat keparahan dampaknya. Metrik lulus atau gagal untuk iterasi tersebut disampaikan kepada pemangku kepentingan bersamaan dengan... catatan cacat.

Seharusnya tidak pernah menyentuh lingkungan produksi. Jalankan di lingkungan terisolasi dengan data yang dapat dipulihkan, karena input yang sengaja tidak valid dan kerusakan paksa dapat meninggalkan catatan parsial yang mahal untuk dibersihkan.

Buat lembar catatan selama sesi berlangsung, mencatat setiap tindakan dan input secara berurutan. Putar ulang lembar catatan dari kondisi bersih, lalu perpendek menjadi urutan terpendek yang masih memicu kegagalan.

Ringkaslah postingan ini dengan: