Lompat ke konten Lompat ke sidebar Lompat ke footer

Metode Pengujian Perangkat Lunak Blackbox dan White Box

Metode Pengujian Perangkat Lunak Blackbox dan White Box - Membahas mengenai dasar pengujian perangkat lunak, model pengujian perangkat Lunak Blackbox dan White Box. Melalui artikel ini diharapkan dapat memahami metodologi untuk menguji software dengan grafik, path.

 Prosedur pengujian unit.
  • Pengujian unit pada umumnya merupakan perkembangan dari langkah pengkodean.
  • Setelah program sumber dikembangkan, ditinjau kembali dan diverifikasi untuk sintaknya, maka perancangan test case di mulai.
  • Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk menentukan test case.
  • Karena modul bukan program yang berdiri sendiri, maka driver (pengendali) dan atau stub perangkat lunak harus dikembangkan untuk tiap-tiap pengujian unit.

MODUL TESTING (pengujian modul)
  • Pengujian interaksi dari semua komponen yang berhubungan terhadap modul.
  • Pengujian modul yang indpendent.
  • Modul secara individu diuji secara terpisah.
  • Modul berupa kumpulan fungsi, prosedure atau program-program.
  • Tidak secara increment, biasanya dilakukan oleh seorang programmer yang membuat program tersebut.
  • Menggunakan stub dan driver.
  • Pengujian whit-box cocok untuk tingkatan ini.
  • Pengujian struktur data lokal, kondisi batasan, jalur independen, jalur penanganan kesalahan.
  • Formal : rencana pengujian dijelaskan dan tertulis.
  • Modul bukanlah program yang berdiri sendiri, perangkat lunak driver dan atau stub harus dikembangkan bagi masing-masing pengujian unit.
  • Pada sebagian besar aplikasi, driver tidak lebih dari sebuah “program utama”, yang menerima data test case.
  • Data sampai ke modul untuk diuji, dan kemudian mencetak hasil yang relevan.
  • Stub berfungsi untuk menggantikan modul yang merupakan subordinat dari modul yang akan diuji.
  • Stub menggunakan interface modul subordinat untuk melakukan manipulasi data minimal, mencetak , entri dan kembali.
Metode Pengujian Perangkat Lunak Blackbox dan White Box_
image source: skillfindergroup.com
baca juga:

INTEGRATION TESTING (pengujian integrasi)

  • Pengujian integrasi adalah teknik yang sistematis untuk mengkonstruksi susunan program sambil melakukan pengujian  untuk memeriksa kesalahan yang nantinya digabungkan dengan interface.
  • Sasarannya adalah untuk mengambil modul yang dikenai pengujian unit dan membangun struktur program yang telah ditentukan oleh desain.
  • Kesulitannya adalah lokalisasi error yang sulit ditemukan pada saat proses.
  • Terdapat interaksi yang rumit antara komponen sistem dan ketika ditemukan output yang menyimpang, mungkin sulit untuk menemukan sumber error tersebut.


Integrasi non-inkremental

Program diuji sebagai satu kesatuan. Serangkaian kesalahan akan terjadi. Koreksi sulit dilakukan karena isolasi penyebab diperumit oleh luasnya program keseluruhan. Sekali kesalahan tersebut dibetulkan, maka akan muncul lagi yang baru dan proses itu terus berlanjut dalam loop yang kelihatannya tidak akan pernah berhenti.

Integrasi inkremental

Program dibangun dan diuji di dalam segmen-segmen kecil, sehingga kesalahan lebih mudah diisolasi dan dibetulkan, interface lebih mungkin untuk diuji secara lengkap, dan pendekatan pengujian yang sistematis dapat diaplikasikan.

Top-down Integrasi
  • adalah pendekatan inkremental terhadap struktur program.
  • Modul diintegrasikan dengan menggerakkan ke bawah melalui hirarki kontrol, dimulai dengan modul kontrol utama (program utama).
  • Memverifikasi kontrol utama dan keputusan pada saat awal proses pengujian.
  • Pada struktur program yang dibuat dengan baik, keputusan akan dikerjakan pada tingkat atas hirarki.
  • Stub mengganti modul tingkat rendah pada awal pengujian top-down, sehingga tidak ada data yang penting yang dapat mengalir ke atas di dalam struktur program.

Proses integrasi dilakukan dalam 5 (lima) langkah  :
  1. Modul kontrol utama digunakan sebagai test driver, dan stub ditambahkan pada semua modul yang secara langsung subordinat terhadap modul kontrol utama.
  2. Stub subordinat diganti pada suatu saat dengan modul aktual.
  3. Pengujian dilakukan pada saat masing-masing modul diintegrasi.
  4. Pada pelengkapan masing-masing rangkaian pengujian, stub yang lain diganti dengan modul real.
  5. Pengujian regresi dapat dilakukan untuk memastikan bahwa kesalahan baru belum dimunculkan.

Bottom-up Integrasi
  • Dapat dinyatakan dengan penyusunan yang dimulai dan diuji dengan atomic modul (modul tingkat paling bawah pada struktur program).
  • Modul diintegrasikan dari bawah ke atas sehingga pemrosesan yang diperlukan untuk modul subordinat yang selalu diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi.

Strategi bottom-up integration dapat diterapkan dengan urutan langkah-langkah sebagai berikut  :
  1. Modul tingkat bawah digabungkan ke dalam cluster (sering disebut build) yang malakukan subfungsi perangkat lunak spesifik.
  2. Driver (program kontrol untuk pengujian) ditulis untuk mengkoordinasi input dan output test case.
  3. Cluster diuji.
  4. Driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam struktur program.

Regression Testing (pengujian regresi)
  • adalah aktivitas yang membantu memastikan bahwa perubahan (karena pengujian atau alasan lain) tidak menimbulkan tingkah laku yang tidak diharapkan atau kesalahan tambahan.
  • Merupakan eksekusi ulang dari beberapa subset yang telah dilakukan untuk memastikan bahwa perubahan tidak menimbulkan efek samping yang tidak diharapkan.
  • Pengujian yang berhasil akan menghasilkan kesalahan, dan setiap kesalahan harus dikoreksi.
  • Setiap kali perangkat lunak dikoreksi, maka banyak aspek konfigurasi perangkat lunak (program, dokumentasi atau data yang mendukung) akan diubah.

Pengujian regresi (subset dari pengujian yang akan dieksekusi) berisi tiga kelas test case yang berbeda, yaitu  :
  • Sampel respresentatif dari pengujian yang akan menggunakan semua fungsi perangkat lunak.
  • Pengujian tambahan yang berfokus pada fungsi-fungsi perangkat lunak yang mungkin dipengaruhi oleh perubahan tersebut.
  • Pengujian yang berfokus pada komponen perangkat lunak yang telah diubah.
  • Pemilihan strategi integrasi, tergantung pada karakteristik perangkat lunak dan kadang-kadang juga pada jadwal proyek.
  • Secara umum, pendekatan yang digabungkan (sandwitch testing), yang menggunakan strategi top-down untuk tingkat yang lebih tinggi dari struktur program, dipasangkan dengan strategi bottom-up untuk tingkat subordinat.
  • Pada saat pengujian integrasi dilakukan, penguji  harus mengidentifikasi modul kritis. Modul kritis memiliki karakteristik sebagai berikut :
  1. menekankan beberapa persyaratan perangkat lunak.
  2. memiliki tingkat kontrol yang tinggi.
  3. Kompleks (cyclomatic complexity dapat digunakan sebagai indikator).
  4. memiliki persyaratan kinerja yang terbatas.

Scope of Testing merangkum fungsi yang spesifik, kinerja dan karakteristik desain internal yang akan diuji. Pengujian dibatasi ; kriteria perlengkapan dari masing-masing fase pengujian digambarkan; dan batasan jadwal didokumentasikan.

Test Plan menggambarkan seluruh strategi integrasi. Pengujian dibagi ke dalam phases dan builds yang menekankan fungsional spesifik dan karakteristik tingkah laku dari perangkat lunak tersebut. Misalnya pengujian integrasi untuk sebuah sistem komputer yang berorientasi pada grafik dapat dibagi ke dalam fase-fase pengujian sebagai berikut  :
  • Interaksi pemakai (seleksi perintah, representasi tampilan, pemrosesan dan respresentasi kesalahan).
  • Manipulasi dan analisis data (pembuatan simbol, penentuan dimensi, rotasi, komputasi sifat fisis)
  • Pemrosesan dan pemunculan tampilan (tampilan dua dimensi, tampilan tiga dimensi, grafik dan bagan)
  • Manajemen database (akses, update, integritas, kinerja)

Kriteria dan pengujian yang sesuai diaplikasikan untuk semua fase pengujian  :
  • Integritas interface. Antar muka internal dan eksternal diuji pada saat masing-masing modul (kluster) ditambahkan ke dalam struktur.
  • Validitas fungsional. Pengujian yang didesain untuk mengungkap kesalahan fungsional yang dilakukan.
  • Isi informasi. Pengujian yang didesain untuk mengungkap kesalahan yang berhubungan dengan struktur data global atau lokal yang dilakukuan.
  • Kinerja. Pengujian yang didesain untuk memeriksa batasan kinerja yang dibangun selama desain perangkat lunak dilakukan.

VALIDATION TESTING (pengujian validasi)
  • Dilakukan setelah integration testing dilakukan serta kesalahan-kesalahan yang ditemukan telah diperbaiki.
  • Validasi berhasil jika fungsi-fungsi yang ada pada perangkat lunak telah sesuai dengan yang diharapkan oleh pemakai.
  • Merupakan kumpulan pengujian black-box yang memperlihatkan atau menunjukkan sesuai dengan yang diperlukan.
  • Garis besar rencana pengujian dikerjakan dan prosedur pengujian didefinisikan dengan test case yang spesifik untuk menunjukkan sesuai dengan yang diperlukan.
  • Rencana dan prosedur dirancang untuk menjamin seluruh keperluan fungsional telah terpenuhi, seluruh performansi dapat dicapai, dokumentasi dilakukan dengan benar.

Setelah pengujian dikerjakan, ada satu kemungkinan dari dua kondisi yang ada, yaitu  :
  1. Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima.
  2. Penyimpangan dari spesifikasi ditemukan dan daftar penyimpangan dibuat.

Kajian Konfigurasi
  • Merupakan elemen penting dari proses validasi.
  • Tujuannya untuk memastikan apakah semua elemen konfigurasi perangkat lunak telah dikembangkan dengan tepat, dikatalog, dan memiliki detail yang perlu untuk mendukung fase pemeliharaan dari siklus hidup perangkat lunak.
  • Sering disebut audit.

ALPHA & BETA TESTING
  • Sangat tidak mungkin bagi pengembang perangkat lunak untuk meramalkan bagaimana pelanggan akan benar-benar menggunakan sebuah program.
  • Instruksi yang digunakan dapat disalah-interprestasikan, kombinasi data yang aneh dapat dipakai secara reguler, dan output yang kelihatannya sudah jelas bagi penguji tidak dapat dimengerti oleh pemakai di lapangan.
  • Bila perangkat lunak biasa dibangun bagi satu pelanggan, maka dapat acceptance test dapat dilakukan untuk memungkinkan pelanggan memvalidasi semua persyaratan.
  • Acceptance test dilakukan karena memungkinkan pelanggan untuk menemukan kesalahan yang lebih terinci dan membiasakan pelanggan memahami perangkat lunak yang telah dibuat.
  • Jika perangkat lunak dikembangkan atau dibuat untuk dipakai oleh banyak pelanggan, maka tidak praktis untuk melakukan pengujian satu per satu terhadap perangkat lunak tersebut.
  • Maka digunakan alpha dan beta testing.
  • Alpha testing adalah tahap pengembangan, dimana perangkat lunak atau perangkat keras yang telah dibuat dikirim ke kelompok pemakai atau pembeli yang potensial kemudian mereka akan menggunakan produk ini untuk melaporkan jika produk itu gagal ?
  • Pengujian aplha dilakukan pada sebuah lingkungan yang terkontrol.
  • Pengujian beta dilakukan oleh pelanggan yang merupakan pemakai akhir perangkat lunak.
  • Pengujian beta merupakan sebuah aplikasi “live” dari perangkat lunak dalam suatu lingkungan yang tidak dapat dikontrol oleh pengembang.
  • Pelanggan merekam semua masalah yang ditemui selama pengujian beta dan melaporkannya kepada pengembang.
  • Pengembang melakukan modifikasi kemudian mempersiapkan pelepasan produk ke seluruh pelanggan.

SYSTEM  TESTING
  • Perangkat lunak merupakan salah satu elemen dari sistem yang berbasis komputer yang sangat besar.
  • Perangkat lunak diintegrasi dengan elemen sistem lainnya (hardware, informasi) dan serangkaian integrasi sistem dan validasi test dilakukan.
  • Jika pengujian gagal atau diluar scope dari pengembangan sistem dan tidak hanya dikerjakan oleh programmer, maka langkah yang diambil selama perancangan dan pengujian dapat diperbaiki
  • Peran analis sistem antara lain  :
    • Menangani kesalahan yang muncul dari elemen-elemen perangkat lunak
    • Mengerjakan serangkaian pengujian
    • Mencatat hasil pengujian.
    • Berpartisipasi dalam perencanaan dan merangcang pengujian sistem untuk menjamin kualitas perangkat lunak.
    • System testing adalah sederetan pengujian yang berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen dalam sistem yang telah dikembangkan.

Stress Testing (pengujian stres)
  • Didesain untuk menghadapi situasi yang tidak normal pada saat program mengalami pengujian.
  • Dilakukan oleh sistem untuk kondisi-kondisi seperti volume data yang normal (melebihi atau kurang dari batasan), frekuensi dll.
  • Intinya penguji berusaha untuk merusak program.

Recovery Testing (pengujian perbaikan)
  • Adalah pengujian sistem yang memaksa perangkat lunak untuk mengalami kegagalan dalam berbagai cara dan melakukan verifikasi sesuai dengan performansi yang tepat.
  • Banyak sistem yang berbasis komputer harus melindungi dari kesalahan dan melanjutkan prosesnya dalam waktu yang telah ditentukan.
  • Sistem harus toleran terhadap kesalahan. Kesalahan pemrosesan tidak boleh menyebabkan keseluruhan fungsi sistem berhenti.

Security Testing (pengujian keamanan)
  • Adalah pengujian yang akan melakukan verifikasi dari mekanisme perlindungan yang akan dibuat oleh sistem, melindungi dari hal-hal yang mungkin terjadi.
  • Penguji memerankan individu yang akan menembus sistem.
  • Pengujian untuk mencoba menembus tingkat keamanan sebuah perangkat lunak.
  • Strategi Sandwich Compromise, menguji perangkat lunak dengan melakukan pengujian mulai dari entry-point tertentu kemudian bergerak keatas ataupun kebawah.
  • Volume Testing, menguji perangkat lunak dengan memberi data yang berlebihan.
  • Configuration Testing, menguji berbagai variasi perangkat lunak diberbagai lingkungan perangkat lunak.
  • Compatibility Testing, menguji kesesuaian sebuah perangkat lunak dengan sistem yang sedang dimanfaatkan.
  • Timing sistem, melakukan pengujian terhadap perangkat lunak untuk evaluasi terhadap waktu tanggap dan waktu proses Yng dibutuhkan untuk menyelesaikan sebuah tugas.
  • Enviromental Testing, menguji toleransi perangkat lunak terhadap suhu, kelembaban, gerak dan perpindahan.
  • Human Factor Testing, menguji antarmuka perangkat lunak bersama-sama dengan pemakai.

Interface Testing (pengujian interface)
  • Dilakukan ketika modul atau subsistem diintegrasi untuk membuat sistem yang lebih besar.
  • Setiap modul atau subsistem memiliki interface yang terdifinisi yang dipanggil oleh komponen program lain.
  • Tujuannya adalah untuk mendeteksi kesalahan yang mungkin telah masuk ke dalam sistem karena eror interface atau asumsi invalid mengenai interface.
  • Penting untuk pengembangan berorientasi objek

Sekian artikel tentang Metode Pengujian Perangkat Lunak Blackbox dan White Box. Semoga bermanfaat.
Nikita Dini
Nikita Dini Blogger, Internet Marketer, Web Designer

Posting Komentar untuk "Metode Pengujian Perangkat Lunak Blackbox dan White Box"