Black Box Testing

Pengujian black-box juga disebut uji fungsional, teknik pengujian yang mengabaikan detail internal sistem dan hanya berfokus pada masukan yang diterima, keluaran yang dihasilkan, dan kondisi eksekusi (Naik & Tripathy, 2008,p.163). Perangkat lunak diperlakukan sebagai kotak hitam, logika internal diabaikan, satu set masukan diberikan, kemudian keluaran dibandingkan dengan yang diharapkan, digambarkan sebagai berikut (Chemuturi, 2011, p.139):
Pengujian black box cenderung untuk menemukan berbagai jenis kesalahan: 
  • Fungsi yang hilang
  • Masalah kegunaan
  • Masalah kinerja
  • Kesalahan waktu
  • Inisialisasi dan penghentian kesalahan
  • Dan lain-lain 

Tidak seperti pengujian white box, pengujian black box cenderung diterapkan setelah proses pembangunan.Berikut ini adalah langkah-langkah pengujian Black Box (Chemuturi, 2011, p.140): 
  • Menyiapkan unit perangkat lunak berupa file executable, dan menginstalnya pada sistem pengujian
  • Menyiapkan data master yang dibutuhkan untuk pengujian
  • Mempelajari rencana pengujian dan memperhatikan tujuan pengujian
  • Mempelajari uji kasus yang didesain untuk pengujian
  • Menjalankan program baik dari command line, atau graphical user Interface
  • Jalankan uji kasus dalam urutan tertentu, catat hasilnya untuk menentukan gagal, atau berhasil
  • Jika ragu terhadap hasilnya, kembalikan ke kondisi sebelum pengujian, kemudian lakukan pengujian ulang
  • Setelah semua uji kasus dieksekusi, atur review manajerial, danhasilnya laporkan ke pencetus/penggagas permintaan pengujian
  • Memberikan klarifikasi kepada pencetus/penggagas permintaan pengujian, membantu pihak yang terlibat dalam memahami, dan menyelesaikan cacat
  • Sebagaimana disyaratkan, lakukan uji regresi untuk memastikan bahwa cacat tel
  • Jika pada uji regresi masih menemukan cacat, ulangi langkah 7 sampai 9 
Kebanyakan tester, saat memulai proyek testing, akan menghadapi masalah untuk memutuskan test cases apa yang akan mereka eksekusi untuk melakukan tes sistem mereka. Untuk dapat membuat test cases yang efektif, harus dilakukan dekomposisi dari tugas-tugas testing suatu sistem ke aktivitasaktivitas yang lebih kecil dan dapat dimanajemeni, hingga tercapai test caseindividual. Tentunya, dalam disain test case juga digunakan mekanisme untukmemastikan bahwa test case yang ada telah cukup mencakup semua aspek dari sistem. 

Pendesainan test case dilakukan secara manual, Tidak ada alat bantu otomasi guna menentukan test cases yang dibutuhkan oleh sistem, karena tiap sistem berbeda, dan alat bantu tes tak dapat mengetahui aturan benar-salah dari suatu operasi. Disain tes membutuhkan pengalaman, penalaran dan intuisi dari seorang tester.

Spesifikasi sebagai tuntunan testing 
Spesifikasi atau model sistem adalah titik awal dalam memulai disain tes. Spesifikasi atau model sistem dapat berupa spesifikasi fungsional, spesifikasi kinerja atau keamanan, spesifikasi skenario pengguna, atau spesifikasi berdasarkan pada resiko sistem. Spesifikasi menggambarkan kriteria yangdigunakan untuk menentukan operasi yang benar atau dapat diterima, sebagaiacuan pelaksanaan tes.

Banyak kasus, biasanya berhubungan dengan sistem lama, hanyaterdapat sedikit atau bahkan tidak ada dokumentasi dari spesifikasi sistem. Dalam hal ini sangat dibutuhkan peran dari pengguna akhir yang mengetahui sistemuntuk diikutsertakan ke dalam disain tes, sebagai ganti dari dokumenspesifikasi sistem. Walaupun demikian, harus tetap ada dokumentasi spesifikasi,yang bisa saja dibuat dalam bentuk sederhana, yang berisi sekumpulan obyektifitas tes di level atas.

Dekomposisi obyektifitas tes
Disain tes berfokus pas tda spesifikasi komponen yang dites. Obyektifitas tes tingkat atas disusun berdasarkan pada spesifikasi komponen. Tiap obyektifitas tes ini untuk kemudian didekomposisikan ke dalam obyektifitas tes lainnya atau test cases menggunakan teknik disain tes. 

Terdapat banyak jenis teknik disain tes yang dapat dipilih berdasarkan pada tipe testing yang akan digunakan, yaitu: 
  • Equivalence Class Partitioning
  • Boundary Value Analysis
  • State Transitions Testing
  • Cause-Effect Graphing 
Langkah pertama pada black box testing adalah memahami obyek yang dimodelkan dalam software dan hubungan koneksi antar obyek, kemudian definisikan serangkaian tes yang merupakan verifikasi bahwa semua obyek telah mempunyai hubungan dengan yang lainnya sesuai yang diharapkan. Langkah ini dapat dicapai dengan membuat grafik, dimana berisi kumpulan node yang mewakili obyek, penghubung / link yang mewakili hubungan antar obyek, bobot node yang menjelaskan properti dari suatu obyek, dan bobot penghubung yang menjelaskan beberapa karakteristik dari penghubung / link. 

Representasi secara simbolik dari grafik terlihat seperti pada gambar A. Nodes direpresentasikan sebagai lingkaran yang dihubungkan dengan garis penghubung. Suatu hubungan langsung (digambarkan dalam bentuk anak panah) mengindikasikan suatu hubungan yang bergerak hanya dalam satu arah. Hubungan dua arah, juga disebut sebagai hubungan simetris, menggambarkan hubungan yang dapat bergerak dalam dua arah. Hubungan paralel digunakan bila sejumlah hubungan ditetapkan antara dua nodes.  Equivalence partitioning adalah metode black box testing yang membagi domain masukan dari suatu program ke dalam kelas-kelas data, dimana test cases dapat diturunkan. Equivalence partitioning berdasarkan pada premis masukan dan keluaran dari suatu komponen yang dipartisi ke dalam kelas-kelas, menurut spesifikasi dari komponen tersebut, yang akan diperlakukan sama (ekuivalen) oleh komponen tersebut. Dapat juga diasumsikan bahwa masukan yang sama akan menghasilkan respon yang sama pula. Pada equivalence partitioning ruang/range masukan dibagi menjadi 2, valid dan tidak valid (Chemuturi, 2011, p.153). 




Jangan Lupa Subcribe, Klik Tombol Youtube

closeKawan Jangan Lupa Amal, Klik Iklannya
close