0

BAB I. PENGUJIAN PERANGKAT LUNAK (SOFTWARE TESTING)

Pengujian Perangkat Lunak adalah elemen kritis dari jaminan kualitas perangkat
lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean.
Pengujian merepresentasikan ketidak normalan yang terjadi pada pengembangan perangkat
lunak. Selama definisi awal dari fase pembangunan, pengembangan berusaha untuk
membangun perangkat lunak dari konsep yang abstrak sampai dengan implementasi
Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas
perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produksi di
mana peluang terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia
untuk melakukan dan berkomunikasi dengan sempurna maka pengembangan perangkat lunak
diiringi dengan aktivitas jaminan kualitas.
Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen sistem
dan “biaya” yang muncul akibat kegagalan perangkat lunak, memotivasi dilakukannya
perencanaan yang baik melalui pengujian yang teliti. Pada dasarnya, pengujian merupakan
satu langkah dalam proses rekayasa perangkat lunak yang dapat dianggap sebagai hal yang
merusak daripada membangun.

1. Dasar-dasar Pengujian Perangkat Lunak

Pengembang perangkat lunak sesuai dengan sifatnya dasar, mereka adalah manusia
pembangun. Pengujian mengharuskan pengembang membuang pemikiran-pemikiran
sebelumnya mengenai “kebenaran” perangkat lunak yang baru saja dikembangkan dan
mengatasi konflik minat yang terjadi pada saat kesalahan ditemukan.

2. Sasaran Pengujian
- Pengujian adalah proses eksekusi suatu program dengan maksud menemukan
kesalahan.
- Pengujian yang sukses adalah pengujian yang memiliki probabilitas tinggi untuk
menemukan dan mengungkapkan semua kesalahan yang belum pernah ditemukan
atau diduga sebelumnya.

- Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk
menemukan kesalahan yang belum pernah ditemukan sebelumnya

1
- Sasaran itu berlawanan dengan pandangan yang biasanya dipegang yang menyatakan
bahwa pengujian yang berhasil adalah pengujian yang tidak ada kesalahan yang
ditemukan. Data yang dikumpulkan pada saat pengujian dilakukan memberikan
indikasi yang baik mengenai reliabilitas perangkat lunak dan beberapa menunjukkan
kualitas perangkat lunak secara keseluruhan, tetapi ada satu hal yang tidak dapat
dilakukan oleh pengujian, yaitu pengujian tidak dapat memperlihatkan tidak adanya
cacat, pengujian hanya dapat memperlihatkan bahwa ada kesalahan perangkat lunak.
perangkat lunak harus memahami prinsip dasar yang menuntun pengujian perangkat lunak, yaitu:

3. Prinsip-prinsip pengujian perangkat lunak

- Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan, maksudnya

mengungkap kesalahan dari cacat yang menyebabkan program gagal.
- Pengujian harus direncanakan lama sebelum pengujian itu mulai, maksudnya semua
pengujian dapat direncanakan dan dirancang sebelum semua kode dijalankan.
- Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80%
kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua
modul program.
- Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian “yang besar”,
Selagi pengujian berlangsung maju, pengujian mengubah focus dalam usaha
menemukan kesalahan pada cluster modul yang terintegrasi dan akhirnya pada sistem.

- Pengujian yang mendalam tidak mungkin karena tidak mungkin mengeksekusi setiap
kombinasi jalur skema pengujian dikarenakan jumlah jalur permutasi untuk program
menengah pun sangat besar.
- Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang
independent.
4. Karakteristik yang Membawa Perangkat Lunak Dapat Diuji

1) Operabilitas, yaitu : Semakin baik Dia bekerja, semakin efisien Dia dapat diuji.
2) Obsaikervabilitas, yaitu : “Apa yang Anda lihat adalah apa yang Anda uji”.
3) Kontralabilitas, yaitu : “Semakin baik kita dapat mengontrol perangkat lunak,
semakin banyak pengujian yang dapat diotomasisasi dan dioptimalkan”.

2
4) Dekomposabilitas, yaitu : “Dengan mengontrol ruang lingkup pengujian, kita dapat
dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara
lebih halus”.

5) Kesederhanaan, yaitu : “Semakin sedikit yang kita uji, semakin cepat kita dapat
mengujinya’.
6) Stabilitas, yaitu : “Semakin sedikit perubahan, semakin sedikit pula gangguan dalam
pengujian’.
7) Kemampuan untuk dapat dipahami, yaitu : “Semakin banyak informasi yang kita
miliki, semakin halus pengujian yang akan dilakukan’.

5. Atribut--Atribut Pengujian yang baik :

a. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.
b. Pengujian yang baik tidak redudan.
c. Pengujian yang baik seharusnya “jenis terbaik”,

d. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks.

6. Tujuan Pengujian :
Menjalankan program untuk menemukan error yang tersembunyi atau yang sebelumnya tidak
terduga.
7. Fase Pengujian

Ada 2 tingkat yang tersedia pada proses pegujian, yaitu :

1. Konfigurasi perangkat lunak yang mencakup spesifikasi keperluan perangkat lunak,
spesifikaasi perancangan, test case dan program sumber
2. Konfigurasi uji coba yang mencakup rencana dan prosedur uji coba, test case dan
hasil yang diharapkan.

BAB II. DESAIN TEST CASE

Desain test case merupakan metode pengujian untuk perangkat lunak untuk
memastikan kelengkapan pengujian dan memberikan kemungkinan tertinggi untuk
mengungkap kesalahan pada perangkat lunak.

Dalam lingkungan yang ideal, perekayasa perangkat lunak mendesain suatu program

computer, sebuah sistem atau produk dengan testabilitas dalam pikirannya. Hal ini
memungkinkan individu yang berurusan dengan pengujian mendesain test case yang efektif
secara lebih mudah. Testabilitas adalah seberapa mudah sebuah program computer dapat

3
 diuji. Karena sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya
menjadi lebih mudah. Procedural dan menggunakannya sebagai pedoman untuk menetapkan
basis set dari jalur eksekusi.
Sasaran utama desain test case adalah untuk mendapatkan serangkaian pengujian yang
memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak.
Untuk mencapai sasaran tersebut, digunakan 4 kategori yang berbeda dari tehnik desain test
case: Pengujian white-box, pengujian black-box, Integrasi Bottom-Up dan Integrasi Top-
Down.
Semua produk yang direkayasa dapat diuji dengan dua cara :
1) Dengan mengetahui fungsi yang ditentukan dimana produk yang dirancang untuk
melakukanya, pengujian dapat dilakukan untuk memperlihatkan bahwa
masing-masing fungsi beroperasi sepenuhnya, pada waktu yang sama mencari
kesalahan pada setiap fungsi.

2) Dengan mengetahui kinerja internal suatu produk, maka pengujian dapat dilakukan
untuk memastikan bahwa semua roda gigi berhubungan, yaitu operasi internal bekerja
sesuai dengan spesifikasi dan semua komponen internal telah diamati dengan baik. Ada
dua macam pendekatan test yaitu :
a) Black Box Testing
Test case ini bertujuan untuk menunjukkan fungsi PL tentang cara beroperasinya,
apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan
apakah informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya.
b) White Box Testing
Meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur
logika) perangkat lunak akan ditest dengan menyediakan test case yang akan
mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekilas
dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan
program yang benar secara 100%.

4
 BAB III. PENGUJIAN WHITE BOX (WHITE BOX TESTING)

Pengujian white box adalah pengujian yang didasarkan pada pengecekan terhadap detail perancangan,
menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke
dalam beberapa kasus pengujian.
Pengujian White Box berfokus pada struktur control program. Test case dilakukan
untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu
kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik
pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian
pengujian yang independent secara linear yang akan memastikan cakupan. White box testing
disebut juga pengujian glass-box.
Pada dasarnya white box testing system di perlukan dalam membangun ataupun
menganasila sebuah system apakah sudah berjalan sebagai mana mestinya atau tidak. Hal ini
perlu dilakukan mengingat white box testing merupakan pengecekan system secara lebih
detail dan komplek ketimbang system black box testing, di white box testing system tidak
hanya di cek dari fungsional luarnya saja "interface" melainkan juga dari berbagai aspek
system, termasuk diagram alur system dan berbagai komponent lainnya yang ada dalam
system.
Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan
pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah
prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box
didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja
internal dari suatu program.

1. Penggunaan metode pengujian white box dilakukan untuk :

- Memberikan jaminan bahwa semua jalur independen suatu modul digunakan

minimal satu kali
- Menggunakan semua keputusan logis untuk semua kondisi true atau false

- Mengeksekusi semua perulangan pada batasan nilai dan operasional pada

setiap kondisi.
- Menggunakan struktur data internal untuk menjamin validitas jalur keputusan.

5
 2. Dengan menggunakan metode white box, analis sistem akan dapat
memperoleh test case yang:

- Menjamin seluruh independent path di dalam modul yang dikerjakan

sekurang-kurangnya sekali.
- Mengerjakan seluruh keputusan logikal.
- Mengerjakan seluruh loop yang sesuai dengan batasannya.
- Mengerjakan seluruh struktur data internal yang menjamin validitas.
3. Persyaratan dalam menjalankan strategi White Box Testing:
- Mendefinisikan semua alur logika
- Membangun kasus untuk digunakan dalam pengujian
- Mengevaluasi semua hasil pengujian
- Melakukan pengujian secara menyeluruh
4. Keunggulan dan Kekurangan White Box
Keunggulan:

 Kebenaran program dalam mendefinisikan algoritma dapat diketahui secara

langsung dengan pengolahan path.
 Menentukan kualitas pekerjaan coding dan pengaruhnya untuk standard
coding.
 Mampu menditeksi kesalahan ;
- Kesalahan logika, digunakan pada sintaks ‘if’ dan pengulangan. Dimana
White Box Testing akan mendeteksi kondisi-kondisi yang tidak sesuai dan
mendeteksi kapan proses pengulangan akan berhenti.

- Ketidaksesuaian asums,. menampilkan asumsi yang tidak sesuai dengan

kenyataan, untuk di analisa dan diperbaiki.
- Kesalahan Ketik, mendeteksi bahasa pemrograman yang bersifat case
sensitive
Kekurangan :

 Jumlah biaya untuk white box testing lebih besar daripada biaya yang dibutuhkan
untuk black box, untuk ukuran software yang sama.

6
 - Belum mampu melakukan tes ketersediaan, kehandalan, daya tahan beban dan testing
- testing lain yang berhubungan dengan kebutuhan faktor - faktor untuk operasi,
revisi dan transisi.
- Untuk perangkat lunak yang tergolong besar, White Box Testing dianggap sebagai
strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar untuk
melakukannya.

BAB IV. PENGUJIAN BASIS PATH (BASIS PATH TESTING)

Pengujian basis path adalah teknik uji coba white box yg diusulkan Tom McCabe.
Metode ini memungkinkan perancang test case mendapatkan ukuran kompleks logical dari
perancangan prosedural dan menggunakan ukuran ini sebagai petunjuk untuk mendefinisikan
himpunan jalur (Basis Set) yang akan diuji.
Basis Path menggunakan notasi graph atau flow graph untuk menggambarkan aliran
kontrolnya. Test case yang dilakukan untuk menggunakan basis set tersebut dijamin untuk
menggunakan setiap statemen di dalam program paling tidak sekali selama pengujian. Notasi
yang digunakan untuk menggambarkan jalur eksekusi adalah notasi diagram alir (atau grafik
program), yang menggunakan notasi lingkaran (simpul atau node) dan anak panah (link atau
edge). Notasi ini menggambarkan aliran control logika yang digunakan dalam suatu bahasa
pemrograman. Perangkat yang digunakan :
1. Notasi Diagram Alir
2. Cyclomatic Complexity (Kompleksitas Siklomatis)

Cyclomatic complexity adalah metrik PL yang menyediakan ukuran kuantitatif dari

kekompleksan logikal program. Apabila digunakan dalam kontek metode uji coba basis path,
nilai yang dihitung untuk cyclomatic complexity menentukan jumlah jalur independen dalam
basis set suatu program dan memberi batas atas untuk jumlah uji coba yang harus dikerjakan
untuk menjamin bahwa seluruh perintah sekurang-kurangnya telah dikerjakan sekali.

Pada Basis Path Testing, hasil dari cyclomatic complexity digunakan untuk
menentukan banyaknya independent paths. Independent path adalah sebuah kondisi pada
program yang menghubungkan node awal dengan node akhir.

7
 3. Melakukan Test Case
Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci
atau program sumber. Pada bagian ini akan dijelaskan langkah-langkah uji coba basis path.
Langkah-Iangkah pembuatan test case:
1. Dengan mempergunakan perancangan prosedural atau program sumber sebagaidasar,
digambarkan diagram alirnya.
2. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat.
3. Tentukan independent path pada flowgraph
4. Buat test case yang akan mengerjakan masing-masing path pada basis set. Data yang
dipilih harus tepat sehingga setiap kondisi dari predicate node dikerjakan semua.

4. Graph Metrik
Graph metrik merupakan PL yang dikembangkan untuk membantu uji coba basis path
atau struktur data. Graph metrik adalah matrik empat persegi yang mempunyai ukuran
(sejumlah baris dan kolom) yang sama dengan jumlah node pada flowgraph. Masing-masing
baris dan kolom mempunyai hubungan dengan node yang telah ditentukan dan pemasukan
data matrik berhubungan dengan hubungan (edge) antanode.
BAB V. PENGUJIAN STRUKTURAL KONTROL (CONTROL STRUCTURE TESTING)

- Merupakan pendekatan terhadap pengujian yang diturunkan dari pengetahuan struktur

dan implementasi perangkat lunak
- Biasanya diterapkan untuk unit program yang relatif kecil seperti subroutine atau
operasi yang terkait dengan suatu objek
- Penguji dapat menganalisa kode dan menggunakan pengetahuan mengenai struktur
komponen untuk menurunkan data uji
- Analisa kode dapat digunakan untuk menemukan beberapa kasus uji yang dibutuhkan
untuk menjamin bahwa semua statement pada program atau komponen dieksekusi
paling tidak satu kali pada proses pengujian.

BAB VI. PENGUJIAN BLACK-BOX (BLACK BOX TESTING

Black-box testing adalah metode pengujian perangkat lunak yang tes fungsionalitas dari
aplikasi yang bertentangan dengan struktur internal atau kerja (lihat pengujian white-box).
pengetahuan khusus dari kode aplikasi / struktur internal dan pengetahuan

8
 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. Metode ujicoba blackbox memfokuskan pada keperluan fungsional dari software. Karna
itu ujicoba blackbox memungkinkan pengembang software untuk membuat himpunan
kondisi input yang akan melatih seluruh syarat-syarat fungsional suatu program. Ujicoba
blackbox bukan merupakan alternatif dari ujicoba whitebox, tetapi merupakan pendekatan
yang melengkapi untuk menemukan kesalahan lainnya, selain menggunakan metode
whitebox. Ujicoba blackbox berusaha untuk menemukan kesalahan dalam beberapa kategori,
diantaranya :
a. Fungsi-fungsi yang salah atau hilang
b. Kesalahan interface
c. Kesalahan dalam struktur data atau akses database eksternal.
d. Kesalahan kinerja
e. Kesalahan Inisialisasi dan terminasi
Dengan mengaplikasikan teknik black-box maka kita menarik serangkaian test case
yang memenuhi kriteria berikut :
- Test case yang mengurangi, dengan harga lebih dari satu, jumlah test case tambahan
yang harus di desain untuk mencapai pengujian yang dapat dipertanggungjawabkan.
- Test case yang memberitahu kita sesuatu mengenai kehadiran atau ketidakhadiran
kelas kesalahan, daripada memberitahu kesalahan yang berhubungan hanya dengan
pengujian spesifik.

1. 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.

9
 3. Black box testing melakukan pengujian 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.

2. Teknik khas Black Box Testing desain meliputi:

a) DECISION TABLE
Decision Tablel adalah cara yang tepat belum kompak untuk model logika rumit,
seperti diagram alur dan jika-then-else dan switch-laporan kasus, kondisi mengaitkan dengan
tindakan untuk melakukan, tetapi dalam banyak kasus melakukannya dengan cara yang lebih
elegan. Pada tahun 1960-an dan 1970-an berbagai “Decision Table Based“ bahasa seperti
Filetab sangat populer untuk pemrograman bisnis.
b) ALL-PAIRS TESTING
All-pairs testing atau pairwise testing adalah metode pengujian perangkat lunak
kombinatorial bahwa, untuk setiap pasangan parameter masukan ke sistem (biasanya, sebuah
algoritma perangkat lunak), tes semua kombinasi yang mungkin diskrit parameter tersebut.
Menggunakan vektor uji dipilih dengan cermat, hal ini dapat dilakukan jauh lebih cepat
daripada pencarian lengkap semua kombinasi dari semua parameter, dengan “parallelizing“
pengujian pasangan parameter. Jumlah tes biasanya O (nm), dimana n dan m adalah jumlah
kemungkinan untuk masing-masing dua parameter dengan pilihan yang paling.
Alasan di balik semua-All-pairs testing ini: yang sederhana dalam sebuah program
umumnya dipicu oleh parameter masukan tunggal. Kategori paling sederhana berikutnya bug
terdiri dari mereka bergantung pada interaksi antara pasangan parameter, yang bisa ditangkap
dengan menguji semua-pasangan. yang melibatkan interaksi antara tiga atau lebih parameter
secara progresif kurang umum, sementara pada saat yang sama waktu semakin lebih
mahal untuk mencari oleh pengujian mendalam, yang sebagai batas pengujian lengkap semua
input yang mungkin.
Banyak metode pengujian menganggap semua-pasang pengujian sistem atau

subsistem sebagai kompromi biaya-manfaat yang wajar antara sering komputasi tidak layak
tingkat tinggi metode pengujian kombinatorial, dan metode yang kurang lengkap yang gagal
untuk menjalankan semua pasangan yang mungkin dari parameter. Karena tidak ada teknik

pengujian dapat menemukan semua bug, semua-pasangan pengujian biasanya digunakan

bersama dengan berbagai teknik jaminan mutu seperti unit testing, eksekusi simbolik,

pengujian bulu halus, dan memeriksa kode.

10
 c) STATE TRANSITION TABLE
Dalam teori automata dan logika sekuensial, state transition table adalah tabel yang
menunjukkan apa yang negara (atau negara dalam kasus robot terbatas nondeterministic)
suatu semiautomaton terbatas atau mesin finite state akan pindah ke, berdasarkan kondisi saat
ini dan masukan lainnya. Sebuah tabel negara pada dasarnya adalah sebuah tabel kebenaran
di mana beberapa input adalah kondisi saat ini, dan output termasuk negara berikutnya,
bersama dengan keluaran lain.
State transition table adalah salah satu dari banyak cara untuk menentukan mesin
negara, cara lain menjadi diagram negara, dan persamaan karakteristik.
d) EQUIVALENCE PARTITIONING
Equivalence partitioning adalah metode pengujian black-box yang memecah atau
membagi domain input dari program ke dalam kelas-kelas data sehingga test case dapat
diperoleh. Pada prinsipnya, uji kasus dirancang untuk menutupi setiap partisi minimal sekali.
Teknik ini mencoba untuk mendefinisikan kasus uji yang mengungkap kelas kesalahan,
sehingga mengurangi jumlah kasus uji yang harus dikembangkan.
Perancangan test case equivalence partitioning berdasarkan evaluasi kelas equivalence
untuk kondisi input yang menggambarkan kumpulan keadaan yang valid atau tidak. Kondisi
input dapat berupa nilai numeric, range nilai, kumpulan nilai yang berhubungan atau kondisi
Boolean.
Dalam kasus yang jarang Equivalence partitioning juga diterapkan pada output dari
komponen perangkat lunak, biasanya itu diterapkan pada masukan dari komponen diuji.
Partisi ekivalen 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 fungsi yang mengambil sebuah parameter “bulan“. 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.

11
 e) BOUNDRY VALUES ANALYSIS (BVA)

Boundary value analysis merupakan suatu teknik pengujian perangkat lunak di mana
tes dirancang untuk mencakup perwakilan dari nilai-nilai batas. Nilai-nilai di tepi sebuah
partisi kesetaraan atau sebesar nilai terkecil di kedua sisi tepi. Nilai dapat berupa rentang
masukan atau keluaran dari komponen perangkat lunak. Karena batas-batas tersebut adalah
lokasi umum untuk kesalahan yang mengakibatkan kesalahan perangkat lunak mereka sering
dilakukan dalam kasus-kasus uji.
Untuk permasalahan yang tidak diketahui dengan jelas cenderung menimbulkan
kesalahan pada domain outputnya. BVA merupakan pilihan test case yang mengerjakan nilai
yang telah ditentukan, dengan teknik perancangan test case melengkapi test case equivalence
partitioning yang fokusnya pada domain input.
Petunjuk pengujian BVA :
- Jika kondisi input berupa range yang dibatasi 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 nilai tersebut.
- Sesuai petunjuk 1 dan 2 untuk kondisi output dirancang test case sampai jumlah
maksimal.

- Untuk struktur data pada program harus dirancang sampai batas kemampuan.

3. Keunggulan dan Kekurangan Black Box:

Keunggulan :

- Black box testing dapat menguji keseluruhan fungsionalitas perangkat lunak.

- Black box testing dapat memilih subset test yang secara efektif dan efisien dapat
menemukan cacat. Dengan cara ini black box testing dapat membantu
memaksimalkan testing investment.

Kekurangan :

Ketika Tester/Penguji melakukan black box testing, tester tidak akan pernah yakin apakah
perangkat lunak yang diuji telah benar-benar lolos pengujian.

12
 - 4. Perbedaan White Box & Black Box
 White box (Struktural)
- Dilakukan oleh penguji yang mengetahui tentang QA.
- Melakukan testing pada software/program aplikasi menyangkut security dan
performance program tersebut (meliputi tes code, desain implementasi, security, data
flow, software failure).

-Dilakukan seiring dengan tahapan pengembangan software atau pada tahap testing.
 Metode BlackBox (Fungsional)
- Dilakukan oleh penguji Independent.
- Melakukan pengujian berdasarkan apa yang dilihat, hanya fokus terhadap
fungsionalitas dan output. Pengujian lebih ditujukan pada desain software sesuai
standar dan reaksi apabila terdapat celah-celah bug/vulnerabilitas pada program
aplikasi tersebut setelah dilakukan white box testing.

- Dilakukan setelah white box testing.

13
14
15
16
17
18
19