Pengujian Perangkat Lunak dengan Blackbox dan Komponennya

Pengujian Perangkat Lunak dengan Blackbox dan Komponennya - Membahas mengenai pngujian blackbox dan teknik untuk melaksanakan pengujian perangkat lunak dengan blackbox. Melalui artikel ini diharapkan dapat memahami pengujian black box dan komponennya.

Black Box Testing

• Metode pengujian black box berfokus pada keperluan fungsional dari perangkat lunak dan domain informasi.
• Analis sistem memperoleh kumpulan kondisi dari input yang akan mengerjakan seluruh keperluan fungsional program.
• Cenderung diaplikasikan selama tahap akhir pengujian.
• Disebut juga pengujian behavioral/pengujian partisi/pengujian interface.
• Memperhatikan dari sudut pandang Input data dan Output data.

• Perangkat lunak ditinjau sebagai kotak hitam yang menyalurkan input kepada output berdasarkan rincian dimana perangkat lunak tersebut harus melakukannya.
• Periksa kecocokan dari pengujian S/W yang membentuk tingkah laku.
• Mencari kesalahan-kesalahan yang dihasilkan oleh kesalahan
• ŸKesalahan perangkat lunak adalah bagian dari perangkat lunak yang tidak menurut pada penyedian definisi itu sendiri dalam dokumen pengembangan.

Tujuannya untuk mencari kesalahan-kesalahan pada  :

• Fungsi yang salah atau hilang.
• Kesalahan pada interface.
• Kesalahan pada struktur data atau akses database.
• Kesalahan performansi (kinerja).
• Kesalahan initialisasi dan tujuan akhir.

image source: martystepp.com

baca juga:

• Metode Pengujian Perangkat Lunak Blackbox dan White Box

• Pendekatan dalam Teknik Pengujian Perangkat Lunak (Software)

• Teknik Pengujian dan Tes Kemampuan Perangkat Lunak

• Tujuan dan Sasaran Pengujian Perangkat Lunak di Industri

Type dari pengujian black box:

1. Equivalence Class Partitioning. (pembagian kelas yang sama)

• Metode pengujian black box yang memecah atau membagi domain input dari suatu program ke dalam kelas-kelas data.
• Perancangan test case berdasarkan evaluasi kelas equivalence untuk kondisi input.
• Kelas equivalence menggambarkan kumpulan keadaan yang valid dan tidak valid untuk kondisi input.
• Kondisi input dapat berupa nilai numerik, range dari nilai, kumpulan nilai yang berhubungan atau kondidi boolean.

Kelas equivalence dapat ditentukan sesuai pedoman berikut ini:

• Bila kondisi input menentukan suatu range, maka kelas equivalence valid dan dua yang invalid ditentukan.
• Bila kondisi input membutuhkan suatu harga khusus, maka satu kelas equivalence valid dan dua yang invalid ditentukan.
• Bila kondisi input menentukan anggota suatu himpunan, maka satu kelas equivalence valid dan dua yang invalid ditentukan.
• Bila kondisi input adalah boolean, maka satu kelas dan satu yang tidak valid ditentukan.

Contoh  :

Dalam persamaan matematika.
1 juta <= Gaji <= 5 juta
Valid        :               1 juta samapi 5 juta
Invalid     :               kurang dari 1 juta lebih dari 5 juta

1. Boundary Value Analysis.(analisa penilaian terbatas)

• Untuk permasalahan yang tidak diketahui dengan jelas, akan cenderung menimbulkan kesalahan pada domain output-nya.
• Pemilihan test case yang mengerjakan nilai-nilai yang telah ditentukan.
• Melengkapi equivalence class partitioning.

Petunjuk pemakaian BVA  :

• Jika kondisi input berupa range yang dibatasi oleh nilai a dan b, test case harus dirancang dengan nilai a dan b.
• Jika kondisi input ditentukan dengan sejumlah nilai, test case harus dikembangkan dengan mengerjakan sampai batas maksimal dari nilai tersebut.
• Sesuai dengan 1 dan 2, untuk kondisi output harus dirancang test case sampai jumlah maksimal.
• Untuk struktur data pada program juga harus dirancang sampai batas kemampuan.

1. Comparison Testing. (pengujian perbandingan)

• Perangkat keras dan perangkat lunak yang berlebihan memungkinkan untuk digunakan.
• Menggunakan team yang terpisah untuk mengembangkan versi-versi yang independent dari perangkat lunak dengan menggunakan spesifikasi yang sama.
• Mencoba masing-masing versi dengan data yang sama untuk  memastikan bahwa semua versi memberikan output yang identik.
• Semua versi dieksekusi secara paralel dengan perbandingan real time hasil untuk memastikan konsistensi.
• Output dari masing-masing versi sama implementasi benar.
• Output berbeda masing-masing versi dari aplikasi diperiksa untuk menentukan cacat pada suatu versi (perbedaan jelas)
• Spesifikasi semua fungsi yang dikembangkan mengandung kesalahan, maka semua versi kemungkinan besar merefleksikan kesalahan.
• Masing-masing versi independen identik tetapi tidak benar, maka pengujian kondisi akan gagal mendeteksi kesalahan.

TESTING STAGES

Sasaran utama desain test case
untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak.

Teknik yang digunakan

• Pengujian white-box (white–box testing)
• Pengujian black-box (black-box testing)

Pengujian white-box

• Berfokus pada struktur kontrol program.
• Pengujian dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian    dan semua kondisi telah diuji.
• Pengujian basis path, teknik pengujian white-box, menggunakan grafik program (matrik grafik) untuk melakukan serangkaian pengujian yang independen secara linear yang memastikan cakupan.
• Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program, dan pengujian loop menyempurnakan teknik white box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi.
• Implikasinya secara khusus diaplikasikan ke dalam komponen program yang kecil (modul atau kelompok kecil dari modul).

Pengujian black-box

• Didesain untuk mengungkap kesalahan pada persyaratan fungsional                 tanpa mengabaikan kerja internal dari suatu program.
• Berfokus pada domain informasi dari perangkat lunak.
• Melakukan teste case dengan  mempartisi domain input dan output dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.
• Partisi ekivalensi (Equivalence Class Partitioning) membagi domain input kedalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu.
• Analisis nilai terbatas (Boundary Value Analysis) memeriksa kemampuan program untuk menangani data pada patas yang dapat diterima.
• Pengujian perbandingan (Comparison Testing) mengembangkan perangkat lunak ke dalam versi-versi yang independen dari suatu aplikasi dengan menggunakan spesifikasi yang sama. Setiap versi diuji dengan data uji yang sama untuk memastikan bahwa                 semua versi memberikan output yagn identik. Disebut juga     pengujian back to   back.

Pengembang perangkat lunak yang berpengalaman sering mengatakan, “Pengujian tidak akan pernah berakhir. Pengujian hanya berpindah dari Penguji ke pelanggan. Setiap pelanggan menggunakan program tersebut, berarti suatu pengujian dilakukan.”

Dengan mengaplikasikan desain test case, perekayasa perangkat lunak  dapat menapai pengujian yang lebih lengkap sehingga dapat mengungkap dan melakukan koreksi sebelum “pengujian pelanggan” dimulai.

TESTING STAGES (tingkatan pengujian)

Validasi perangkat lunak (V & V) ditujukan untuk menunjukkan bahwa sistem sesuai dengan spesifikasinya dan bahwa sistem memenuhi harapan pelanggan yang membelinya. Validasi melibatkan proses pemeriksaan, seperti inspeksi dan peninjauan, pada setiap proses perangkat lunak dari definisi persyaratan user sampai pengembangan program.

Validasi perangkat lunak adalah proses pemeriksaan untuk menjamin agar sistem telah sesuai dengan spesifikasinya dan memenuhi kebutuhan sesungguhnya dari user sistem.

Namun demikian, mayoritas biaya validasi disediakan setelah implementasi sistem operasional diuji.

• Untuk program-program kecil, sistem seharusnya tidak diuji sebagai sistem tunggal. Sistem besar dibangun dari subsistem yang dibangun dari model yang terbuat dari prosedur dan fungsi.
• Proses demikian dengan demikian harus dilakukan bertahap, dimana pengujian dilakukan secara inkremental bersama dengan implementasi sistem.
• Proses pengujian terdiri dari 3 (tiga) tahap dimana komponen-komponen sistem diuji, sistem yang terintegrasi diuji, dan akhirnya sistem diuji dengan data pelanggan.
• Idealnya, kesalahan komponen ditemukan dini pada proses dan masalah interface ketika sistem diintegrasi.
• Namun demikian, dengan ditemukannya kesalahan, program harus didebug.
• Hal ini menuntut tahap proses pengujian ulang.
• Error pada komponen program, bisa muncul pada saat pengujian itegrasi.
• Proses dengan demikian bersifat iteratif, dengan informasi diumpan balik dari bagian akhir ke bagian awal proses.

Tahap-tahap pada proses pengujian  :

1. Unit Testing (pengujian unit).

• Komponen individual diuji untuk menjamin operasi yang     benar.
• Setiap komponen diuji secara independen, tanpa komponen sistem   yang lain.

2. Modul Testing (pengujian modul).

• Modul merupakan sekumpulan komponen yang berhubungan seperti kelas objek, atau sekumpulan prosedur dan fungsi. Sebuah modul merangkum komponen-komponen yang berhubungan, sehingga dapat diuji tanpa modul sistem yang lain.

3. Sub-system Testing (pengujian subsistem).

♠      Melibatkan pengujian sekumpulan modul yang telah diintegrasikan menjadi subsistem.
♠      Masalah yang sering muncul pada sistem perangkat lunak besar adalah ketidaksesuaian interface.
♠      Proses pengujian subsistem dengan demikian harus terkonsentrasi pada deteksi kesalahan interface modul dengan menjalankan interface ini berkali-kali.

4. System Testing (pengujian sistem).

• Subsistem diintegrasikan untuk membentuk sistem. Proses ini berkenaan dengan penemuan kesalahan yang diakibatkan dari interaksi yang tidak diharapkan antara subsistem dan masalah interface subsistem.
• Sistem pengujian secara keseluruhan dimana pengujian timbul karena sifat-sifat yang baru.
• Pengujian atas penggabungan sistem perangkat lunak.

5. Acceptance Testing (pengujian penerimaan).

-  Merupakan tahap akhir proses pengujian sebelum sistem diterima untuk penggunaan operasional.
-  Sistem diuji dengan data yang dipasok oleh pelanggan dan bukan data uji simulasi.
-  Bisa menunjukkan kesalahan dan penghapusan definisi persyaratan  sistem karena data riil menjalankan sistem dengan cara yang berbeda dari data uji.
-  Dapat mengungkap masalah persyaratan dimana fasilitas sistem tidak memenuhi keperluan user atau kinerja sistem tidak dapat diterima.

• Pengujian unit dan pengujian modul biasanya merupakan tanggung jawab programmer yang mengembangkan komponen tersebut. Programer membuat data uji sendiri dan secara inkremental menguji kode pada saat dikembangkan. Pengujian ini sangat ekonomis karena programmer adalah orang yang paling mengetahui komponen tersebut dan merupakan orang terbaik untuk membuat data uji.
• Tahap berikutnya mencakup integrasi dari sejumlah programmer dan harus direncanakan sebelumnya. Suatu tim penguji independent harus bekerja dari rencana uji pra-formulasi yang dikembangkan dari spesifikasi dan rancangan sistem.
• Pengujian penerimaan kadang-kadang disebut pengujian alpha. Sistem yang diperlihatkan dikembangkan untuk satu klien. Proses pengujian alpha berlanjut sampai pengembang sistem dan pelanggan setuju bahwa sistem yang diserahkan merupakan implementasi yang dapat diterima dari persyaratan sistem.