Follow Us @soratemplates

Selasa, 10 Oktober 2017

Black Box

Black Box

Oktober 10, 2017 0 Comments


. 20



 Defenisi Black Box Testing
Black box testing adalah pengujian yang dilakukan hanya mengamati hasil eksekusi melalui data uji dan memeriksa fungsional dari perangkat lunak. Jadi dianalogikan seperti kita melihat suatu kotak hitam, kita hanya bisa melihat penampilan luarnya saja, tanpa tau ada apa dibalik bungkus hitam nya. Sama seperti pengujian black box, mengevaluasi hanya dari tampilan luarnya (interfacenya), fungsionalitasnya tanpa mengetahui apa sesungguhnya yang terjadi dalam proses detilnya (hanya mengetahui input dan output). Black Box pengujian adalah metode pengujian perangkat lunak yang menguji fungsionalitas aplikasi yang bertentangan dengan struktur internal atau kerja. Pengetahuan khusus dari kode aplikasi / struktur internal dan pengetahuan pemrograman pada umumnya tidak diperlukan. Uji kasus dibangun di sekitar spesifikasi dan persyaratan, yakni, aplikasi apa yang seharusnya dilakukan. Menggunakan deskripsi eksternal perangkat lunak, termasuk spesifikasi, persyaratan, dan desain untuk menurunkan uji kasus. Tes ini dapat menjadi fungsional atau non-fungsional, meskipun biasanya fungsional. Perancang uji memilih input yang valid dan tidak valid dan menentukan output yang benar. Tidak ada pengetahuan tentang struktur internal benda uji itu.
Metode uji dapat diterapkan pada semua tingkat pengujian perangkat lunak: unit, integrasi, fungsional, sistem dan penerimaan. Ini biasanya terdiri dari kebanyakan jika tidak semua pengujian pada tingkat yang lebih tinggi, tetapi juga bisa mendominasi unit testing juga.


Pengujian pada Black Box berusaha menemukan kesalahan seperti:
  • Fungsi-fungsi yang tidak benar atau hilang
  • Kesalahan interface
  • Kesalahan dalam struktur data atau akses database eksternal
  • Kesalahan kinerja
  • Inisialisasi dan kesalahan terminasi

Pengujian kotak hitam (Black Box) bukan teknik alternatif untuk kotak putih (White Box). Sebaliknya, ini merupakan pendekatan pelengkap yang memungkinkan dilakukan untuk mengungkapkan kesalahan yang berbeda dari yang diungkap oleh motede kotak putih (White Box).
Pengujian Kotak Hitam (Blackbox Testing) khusus di didesain untuk mencari kesalahan dengan melakukan ujicoba pada interface software. Pegujian Kotak Hitam (Blackbox Testing) mendemonstrasikan fungsi dari perangkat lunak yang beroperasi, dengan mengecek apakah input sudah bisa diterima dengan baik, dan hasil outputnya sesuai dengan apa yang diharapkan, uji coba Kotak Hitam (Blackbox Testing) melakukan pengecekan pada integritas informasi eksternal, pada dasarnya pengujian Kotak Hitam (Blackbox Testing) hanya memeriksa hasil output yang dihasilkan apakah sudah sesuai dengan apa yang diharapkan dan dinyatakan benar,namun pengujian Kotak Hitam (Blackbox Testing) tidak mengecek logika dari perangkat lunak,

Pengujian unit merupakan pengujian secara individual terhadap semua program untuk memastikan bahwa program bebas dari kesalaan. namun jika ditemukan error atau kesalahan pada program, user akan langsung mencari kesalahannya dan  proses untuk melakukan pencarian kesalahan ini dikenal dengan debugging.
Pengujian dengan menggunakan metode black box, adalah suatu pendekatan untuk dapat menguji dalam setiap fungsi di pada suatu program agar dapat berjalan dengan benar, kamu dapat melihat beberapa proses yang dilakukan dalam pengujian ini diantaranya yaitu :
  1. Fungsi-fungsi yang tidak benar, baik input atau pun output, dalam hal ini hanya melihat apakah proses input dan output sudah sesuai, contohnya jika ada software yang menampilkan form input data identitas, jika user melengkapi form maka program akan melakukan proses simpan, namun jika user tidak melengkapi form program tidak boleh melakukan proses simpan, jika perangkat lunak tidak sesuai misalnya tidak melengkapi form namun dapat tersimpan, hal ini perlu untuk diperbaiki.
  2. Kesalahan interface,dalam hal kesalahan interface sering terjadi pada software yang tidak diuji coba dengan baik, misalnya tampilan web dengan menggunakan framework, ada beberapa framework yang tidak mendukung dengan beberapa browser, hingga tampilan interface kamu kurang maksimal saat user memakai browser yang tidak mendukung frameword yang kamu gunakan.
  3. Kesalahan dalam struktur data atau akses database, yang sering menjadi kendala, karena hal ini dapat berdampak pada akses web menjadi lamban, jika tidak memperhatikannya.
  4. Prilaku atau kinerja kesalahan yang ada pada perangkat lunak.
  5. Inisialisasi dan penghentian kesalahan pada perangkat
Dengan menerapkannya Pengujian Kotak Hitam (Blackbox Testing) dapat mendapatkan suatu set kasus uji yang sudah memenuhi kriteria berikut  yaitu:
1.      Dimana pengujian kasus yang sudah mengurangi dengan suatu perhitungan yang lebih besar dari satu, pada jumlah suatu kasus pengujian tambahan yang wajib dirancang untuk mencapai pengujian yang relevan.
  1. Pengujian kasus yang memberitahu kamu tentang hal yang ada bahkan tidaknya kesalahan, dibandingkan suatu kesalahan yang sudah terkait dengan tes yang khusus.
Untuk lebih jelasnya contoh dari Pengujian Kotak Hitam (Blackbox Testing). Berikut terlampir contoh Tabel Pengujian Kotak Hitam (Blackbox Testing).
Kesimpulannya Pengujian Kotak Hitam (Blackbox Testing), hanya berfokus  pada persyaratan fungsional perangkat lunak atau luarnya saja sama seperti gambar kotak hitam yang hanya terlihat bentuk luar tanpa mengetahui bagaimana isi dari kotak tersebut, namun ini sangat bertolak belakang dengan Pengujian Kotak Putih (Whitebox Testing), yang memerlukan pemeriksaan yang detail dan prosedural, rangkaian logika dari software diujicoba dengan menyediakan objek ujicoba yang memerlukan sekumpulan dari suatu kondisi dan perulangan tertentu, pengujian Kotak Hitam (Blackbox Testing) dan Pengujian Kotak Putih (Whitebox Testing) diwajibkan ada saat kamu mulai merancang suatu perangkat lunak untuk industri atau untuk institusi yang memerlukan hasil maksimal dan tidak mengharapkan ada bug pada perangkat lunak yang digunakan.
Ciri-Ciri Black Box Testing:
  1. Black box testing berfokus pada kebutuhan fungsional pada software, berdasarkan pada spesifikasi kebutuhan dari software.
  2. Black box testing bukan teknik alternatif daripada white box testing. Lebih daripada itu, ia merupakan pendekatan pelengkap dalam mencakup error dengan kelas yang berbeda dari metode white box testing. 
  3. Black box testing melakukan pengujian tanpa pengetahuan detail struktur internal dari sistem atau komponen yang dites. Juga disebut sebagai behavioral testing, specification-based testing, input/output testing atau functional testing
Pada black box testing terdapat jenis teknik disain tes yang dapat dipilih berdasarkan pada tipe testing yang akan digunakan, yang diantaranya  :
  1. Equivalence Class Partitioning
  2. Boundary Value Analysis
  3. State Transitions Testing
  4. Cause-Effect Graphing
Kategori error yang akan diketahui melalui black box testing  :
  • Fungsi yang hilang atau tidak  benar
  • Error  dari antar-muka (interface)
  • Error  dari struktur data atau  akses eksternal database
  • Error  dari kinerja atau tingkah  laku
  • Error  dari inisialisasi dan  terminasi  
Langkah pertama pada black box testing adalah dengan Memahami obyek yang dimodelkan dalam software dan hubungan koneksi antar obyek, selanjutnya didefenisikan serangkaian tes yang merupakan verifikasi bahwa semua obyek telah mempunyai hubungan dengan yang lainnya sesuai yang diharapkan.

2.2. Equlvalence Portitioning


Equvalence partitioning adalah metode black box testing yang membagi domain masukan dari suaatu 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.
Dalam kasus yang jarang partisi kesetaraan juga diterapkan pada output dari komponen perangkat lunak, biasanya itu diterapkan pada masukan dari komponen diuji .Partisi ekuivalen biasanya berasal dari spesifikasi persyaratan untuk atribut masukan yang mempengaruhi pengolahan benda uji.Sebuah masukan telah rentang tertentu yang rentang sah dan lainnya yang tidak valid. Data yang tidak valid di sini tidak berarti bahwa data tidak benar, itu berarti bahwa data ini terletak diluar dari partisi tertentu.Hal ini mungkin lebih tepat dijelaskan oleh contoh.
Contoh:Jangkauan bulan adalah 1 sampai 12, mewakili Januari-Desember.Jangkauan ini disebut partisi.Dalam contoh ini ada dua partisi lebih lanjut rentang tidak valid.Partisi pertama akan menjadi tidak valid <= 0 dan partisi tidak valid kedua akan menjadi> = 13.
Contoh Ilustrasi
Suatu fungsi, generate_grading, dengan spesifikasi sebagai berikut :
Fungsi mempunyai dua perintah, yaitu “Ujian” (diatas 75) dan “Tugas” (diatas 25). Fungsi melakukan gradasi nilai kursus dalam rentang ‘A’ sampai ‘D’. Tingkat gradasi dihitung dari kedua penanda, yang dihitung sebagai total penjumlahan nilai “Ujian”dan nilai “Tugas”, sebagaimana dinyatakan berikut ini :
1.      Lebih besar dari atau sama dengan 70-‘A’
2.      Lebih besar dari atau sama dengan 50, tapi lebih kecil dari 70-‘B’
3.      Lebih besar dari atau sama dengan 30, tapi lebih kecil dari 50-‘C’
4.      Lebih kecil dari 30-‘D’
Dimana bila nilai berada diluar rentang yang diharapkan akan muncul pesan kesalahan (‘FM’). Semua masukan berupa integer.
Equivalence partioning berusaha untuk mendefinisikan kasus uji yang menemukan sejumlah jenis kesalahan, dan mengurangi jumlah kasus uji yang harus dibuat. Kasus uji yang didesain untuk Equivalence partioning berdasarkan pada evaluasi dari ekuivalensi jenis/class untuk kondisi input. Class-class yang ekuivalen merepresentasikan sekumpulan keadaan valid dan invalid untuk kondisi input.

2.3. Boundary Value Analysis

Sejumlah besar kesalahan cenderung terjadi dalam batasan domain input dari pada nilai tengah. Untuk alasan ini boundary value analysis (BVA) dibuat sebagai teknik ujicoba. BVA mengarahkan pada pemilihan kasus uji yang melatih nilai-nilai batas. BVA merupakan desain teknik kasus uji yang melengkapi equivalenceparitioning.
1.      Untuk suatu alasan yang tidak dapat sepenuhnya dijelaskan, sebagian besar jumlah errors cenderung terjadi di sekitar batasan dari domain masukan daripada di “pusat”nya.
2.      Karena alasan inilah boundary value analysis (BVA) dikembangkan sebagai salah satu teknik testing.
3.      Boundary value analysis adalah suatu teknik disain test cases yang berguna untuk melakukan pengujian terhadap nilai sekitar dari pusat domain masukan.
4.      Teknik boundary value analysis merupakan komplemen dari teknik equivalence partitioning.
5.      Setelah dilakukan pemilihan tiap elemen suatu kelas ekuivalensi (menggunakan equivalence partitioning), BVA melakukan pemilihan nilai batas-batas dari kelas untuk test cases.
6.      .BVA tidak hanya berfokus pada kondisi masukan, BVA membuat test cases dari domain keluaran juga.

7.      Boundary-values merupakan nilai batasan dari kelas-kelas ekuivalensi. Contoh:
o   Senin dan Minggu untuk hari.
o   Januari dan Desember untuk bulan.
o   (-32767) dan 32767 untuk 16-bit integers.
o   Satu karakter string dan maksimum panjang string.
8.      Test cases dilakukan untuk menguji nilai-nilai di kedua sisi dari batasan.
9.      Nilai tiap sisi dari batasan yang dipilih, diusahakan mempunyai selisih sekecil mungkin dengan nilai batasan (misal: selisih 1 untuk bilangan integers).

2.4 Cause Effect Graphic

Caeuse-effect graphing merupakan desain teknik kasus ujicoba yang menyediakan representasi singkat mengenai kondisi logikal dan aksi yang berhubungan. Tekniknya mengikuti 4 tahapan berikut :
  1. Causes (kondisi input), dan Effects (aksi) didaftarkan untuk modul dan identifier yang dtujukan untukmasing-masing
  2. Causes-effect graph (seperti pada gambar dibawah) dibuat
  3. Graph dikonversikan kedalam tabel keputusan
  4. Aturan tabel keputusan dikonversikan kedalam kasus uji
Merupakan teknik disain test cases yang menggambarkan logika dari kondisi terhadap aksi yang dilakukan.
Terdapat empat langkah, yaitu :
1.      Tiap penyebab (kondisi masukan) dan di daftarkan akibat (aksi) yang ada pada suatu modul.
2.      Gambar sebab-akibat (cause-effect graph) dibu
3.      Gambar di konversikan ke tabel keputus

2.5 Comparison Testing

Dalam beberapa situasi (seperti : aircraft avionic, nuclear power plant control) dimana keandalan suatu software amat kritis, beberapa aplikasi sering menggunakan software dan hardware ganda (redundant). Ketika software redundant dibuat, tim pengembangan software lainnya membangun versi independen dari aplikasi dengan menggunakan spesifikasi yang sama. Setiap versi dapat diuji dengan data uji yang sama untuk memastikan seluruhnya menyediakan output yang sama. Kemudian seluruh versi dieksekusi secara paralel dengan perbandingan hasil real-time untuk memastikan konsistensi.
Dianjurkan bahwa versi independen suatu software untuk aplikasi yang amat kritis harus dibuat, walaupun nantinya hanya satu versi saja yang akan digunakan dalam sistem.
Versi independen ini merupakan basis dari teknik black box testing yang disebut comparison testing atau back-to-back testing. Ketika multiple implementasi dari spesifikasi yang sama telah diproduksi, kasus uji didesain dengan menggunakan teknik black box yang lain (misalkan equivalence partitioning) disediakan sebagai input untuk setiap versi dari software. Jika setiap outputnya sama, diasumsikan implementasinya benar, jika tidak, setiap versi di periksa untuk menentukan jika kerusakan terdapat pada satu atau lebih versi yang akan bertanggung jawab atas perbedaan tersebut.
Karakteristik khusus untuk sistem realtime memberikan tantangan tersendiri ketika ujicoba dilaksanakan. Ketergantungannya dengan waktu, sifat alami dari beberapa aplikasi yang tidak sinkron, menambah kesulitan baru dan potensial sebagai elemen untuk ujicoba dengan waktu beragam. Tidak hanya ujicoba whitebox maupun blackbox, tetapi juga ketepatan waktu pengiriman data dan pemrosesan paralel. Contohnya software realtime yang mengontrol mesin fotocopy, yang dapat menerima interupsi dari operator (berupa penekanan tombol ‘RESET’ atau ‘DARKEN’ ) dengan tanpa kesalahan ketika mesin sedang berjalan (‘COPYING’ state). Operator yang sama akan menginterupsi, ketika mesin nberada dalam posisi ‘jamned’.
Sebegai tambahan, keterkaitan antara software real time dengan perangkat keras pendukungnya juga dapat menyebabkan masalah dalam ujicoba. Ujicoba software harus mempertimbangkan kesalahan perangkat keras yang disebabkan karena pemrosesan software. Belum ada uji kasus yang komprehensif yang dikembangkan untuk sistem realtime, tetapi 4 langkah strategi berikut dapat dilaksanakan :
  1. Task Testing, yaitu dengan mengujicobakan setiap task secara independen. Dalam hal ini metode whitebox dan blckbox testing dapat digunakan untuk menemukan kesalahan logika dan kesalahan fungsional, tetapi untuk kesalahan ketepatan waktu dan prilaku software (timing or behavioral errors), tidak dapat terdeteksi.
  2. Behavioral Testing, dengan menggunakan model sistem dengan CASE tool, memungkinkan untuk mensimulasikan prilaku sistem realtime dan menentukannya sebagai konsekwensi dari peristiwa eksternal. Aktivitas analisis ini dapat dilaksanakan sebagai dasar untuk desain kasus uji yang diadakan ketika sebuah sistem realtime berhasil dibuat. Dengan menggunakan teknik yang sesuai (seperti equivalence partitioning), event dikategorikan (misalnya : interrupts, control signals, data), misalkan event pada sebuah buah mesin fotocopy dapat berupa interupsi dari user (‘reset counter’), interupsi mekanikal (‘paper jamned’), interupsi sistem (‘toner low’), dan kesalahan bentuk (‘overheated’). Setiap kesalahan yang terjadi diuji secara individual, dan prolaku executable sistem diperiksa. Prilaku software diperiksa untuk menentukan apakah terdeteksi kesalahan prilaku sistem
  3. Intertask Testing, ketika sebuah kesalahan dari individual task berhasil diisolasi, ujucoba berlanjut kepada kesalahan pada waktu yang terkait. Task yang tidak sinkron yang berkomunikasi dengan task lainnya diuji dengan beberapa data dan pemrosesan untuk menentukan apakah kesalahan antar task akan terjadi. Sebagai tambahan task yang berkomunikasi via antrian pesan atau penyimpanan data, diujikan untuk menemukan kesalahan ukuran penyimpanan
  4. System Testing, software dan hardware telah disatukan dan diujikan dalam uji sistem sebagai satu kesatuan. Uji ini dilakukan untuk menemukan kesalahan pada software/hardware interface.
Comparison testing atau back-to-back testing biasa digunakan pada beberapa aplikasi yang mempunyai kebutuhan terhadap reliabilitas amat penting / kritis, seperti sistem rem pada mobil, sistem navigasi pesawat terbang.Untuk itu redundansi hardware dan software bisa saja digunakan agar dapat meminimalkan kemungkinan error, dengan memakai tim terpisah untuk mengembangkan versi yang berbeda namun mengacu pada spesifikasi yang sama dari software, walaupun untuk selanjutnya hanya akan ada satu versi saja yang dirilis atau digunakan.Test  cases  dibangun  dengan  menggunakan  teknik  disain  test  cases  yang  ada,  seperti equevalence dan partitioning.
Tes dilakukan pada tiap versi dengan data tes yang sama secara paralel dan real time untuk memastikan konsistensi (keluaran yang dihasilkan dari tiap versi identik).Bila keluaran berbeda atau terjadi defect pada satu atau lebih versi aplikasi, masing-masing diinvestigasi untuk menentukan dimana letak kesalahannya, dan versi aplikasi mana yang melakukan kesalahan.
Black box testing, dilakukan tanpa pengetahuan detil struktur internal dari sistem atau komponen yang dites. Juga disebut sebagai behavioral testing, specification-based testing, input/output testing atau functional testing.Black box testing berfokus pada kebutuhan fungsional pada software, berdasarkan pada spesifikasi kebutuhan dari software.
Dengan adanya black box testing, perekayasa software dapat menggunakan sekumpulan kondisi masukan yang dapat   secara penuh memeriksa keseluruhan kebutuhan fungsional pada suatu program.Black box testing bukan teknik alternatif daripada white box testing. Lebih daripada itu, ia merupakan pendekatan pelengkap  dalam mencakup error dengan kelas yang berbeda dari metode white box testing.









         






Continue reading...
di Tidak ada komentar: quickedit