Pengujian Whitebox Testing adalah metode desain uji kasus yang menggunakan struktur kontrol dari desain prosedural untuk menghasilkan kasus-kasus uji. Dengan menggunakan metode ujicoba whitebox, para pengembang software dapat menghasilkan kasus-kasus uji yang :
1. Menjamin bahwa seluruh independent paths dalam modul telah dilakukan sedikitnya satu kali,
2. Melakukan seluruh keputusan logikal baik dari sisi benar maupun salah,
3. Melakukan seluruh perulangan sesuai batasannya dan dalam batasan operasionalnya
4. Menguji struktur data internal untuk memastikan validitasnya
Mengapa menghabiskan banyak waktu dan usaha dengan menguji logikal software? Hal ini dikarenakan sifat
kerusakan alami dari software itu sendiri, yaitu :
1. Kesalahan logika dan kesalahan asumsi secara proposional terbalik dengan kemungkinan bahwa alur program akan dieksekusi. Kesalahan akan selalu ada ketika mendesain dan implementasi fungsi, kondisi atau kontrol yang keluar dari alur utama. Setiap harinya pemrosesan selalu berjalan dengan baik dan dimengerti sampai bertemu ”kasus spesial” yang akan mengarahkannya kepada kehancuran.
2. Sering percaya bahwa alur logikal tidak akan dieksekusi ketika dikenyataannya, mungkin akan dieksekusi dengan basis regular. Alur logika program biasanya berkebalikan dari intuisi, yaitu tanpa disadari asumsi mengenai alur kontrol dan data dapat mengarahkan pada kesalahan desain yang tidak dapat terlihat hanya dengan satu kali ujicoba.
3. Kesalahan typographical (cetakan) bersifat random. Ketika program diterjemahkan kedalam kode sumber bahasa pemrograman, maka akan terjadi kesalahan pengetikan. Banyak yang terdeteksi dengan mekanisme pemeriksaan sintaks, tetapi banyak juga yang tidak terdeteksi sampai dengan dimulainya ujicoba. Karena alasan tersebut diatas, maka ujicoba whitebox testing diperlukan selain blackbox testing.
1. Menjamin bahwa seluruh independent paths dalam modul telah dilakukan sedikitnya satu kali,
2. Melakukan seluruh keputusan logikal baik dari sisi benar maupun salah,
3. Melakukan seluruh perulangan sesuai batasannya dan dalam batasan operasionalnya
4. Menguji struktur data internal untuk memastikan validitasnya
Mengapa menghabiskan banyak waktu dan usaha dengan menguji logikal software? Hal ini dikarenakan sifat
kerusakan alami dari software itu sendiri, yaitu :
1. Kesalahan logika dan kesalahan asumsi secara proposional terbalik dengan kemungkinan bahwa alur program akan dieksekusi. Kesalahan akan selalu ada ketika mendesain dan implementasi fungsi, kondisi atau kontrol yang keluar dari alur utama. Setiap harinya pemrosesan selalu berjalan dengan baik dan dimengerti sampai bertemu ”kasus spesial” yang akan mengarahkannya kepada kehancuran.
2. Sering percaya bahwa alur logikal tidak akan dieksekusi ketika dikenyataannya, mungkin akan dieksekusi dengan basis regular. Alur logika program biasanya berkebalikan dari intuisi, yaitu tanpa disadari asumsi mengenai alur kontrol dan data dapat mengarahkan pada kesalahan desain yang tidak dapat terlihat hanya dengan satu kali ujicoba.
3. Kesalahan typographical (cetakan) bersifat random. Ketika program diterjemahkan kedalam kode sumber bahasa pemrograman, maka akan terjadi kesalahan pengetikan. Banyak yang terdeteksi dengan mekanisme pemeriksaan sintaks, tetapi banyak juga yang tidak terdeteksi sampai dengan dimulainya ujicoba. Karena alasan tersebut diatas, maka ujicoba whitebox testing diperlukan selain blackbox testing.
Uji coba berbasi alur (Basis path testing)
Ujicoba berbasis alur merupakan teknik ujicoba whitebox pertama yang diusulkan oleh Tom McCabe. Metode berbasis alur memungkinkan perancang kasus uji untuk menghasilkan ukuran kompleksitas logikal dari desain prosedural dan menggunakan ukuran ini untuk mendefinisikan himpunan basis dari alur eksekusi. Kasus uji dihasilkan untuk melakukan sekumpulan basis yang dijamin untuk mengeksekusi setiap perintah dalam program, sedikitnya satu kali selama ujicoba. Notasi graf Alur (Path Graph Notation) Notasi sederhana untuk merepresentasikan alur kontrol disebut graf alur (flow graph), seperti gambar dibawah ini :
Ujicoba berbasis alur merupakan teknik ujicoba whitebox pertama yang diusulkan oleh Tom McCabe. Metode berbasis alur memungkinkan perancang kasus uji untuk menghasilkan ukuran kompleksitas logikal dari desain prosedural dan menggunakan ukuran ini untuk mendefinisikan himpunan basis dari alur eksekusi. Kasus uji dihasilkan untuk melakukan sekumpulan basis yang dijamin untuk mengeksekusi setiap perintah dalam program, sedikitnya satu kali selama ujicoba. Notasi graf Alur (Path Graph Notation) Notasi sederhana untuk merepresentasikan alur kontrol disebut graf alur (flow graph), seperti gambar dibawah ini :
Untuk mengilustrasikan kegunaan dari diagram alir dapat dilihat pada gambar dibawah ini. Gambar bagian (a) digunakan untuk menggambarkan struktur kontrol program, sedangkan gambar bagian (b) setiap lingkaran disebut dengan flow graph node, merepresentasikan satu atau lebih perintah prosedural. Urutan dari simbol proses dan simbol keputusan dapat digambarkan menjadi sebuah node, sedangkan anak panah disebut edges, menggambarkan aliran dari kontrol sesuai dengan diagram alir. Sebuah edge harus berakhir pada sebuah node walaupun tidak semua node merepresentasikan perintah prosedural. Area yang dibatasi oleh edge dan node disebut region, area diluar graph juga dihitung sebagai region.
Setiap representasi rancangan prosedural dapat diterjemahkan kedalam flow graph. Gambar (a) dibawah ini merupakan bagian dari PDL (Program Design Language) dan flow graph-nya (perhatikan nomor untuk setiap perintahnya). Ketika kondisi gabungan ditemukan, maka penggambaran flow graph akan menjadi lebih rumit. Kondisi gabungan biasanya muncul jika satu atau lebih operator Boolean (OR, AND, NAND, NOR) ditemukan dalam perintah, seperti terlihat pada gambar (b) dibawah ini :
Cyclomatic Complexity
Cyclomatic complexity merupakan software metric yang menyediakan ukuran kuantitatif dari komplesitas logikal suatu program. Ketika digunakan dalam konteks metode ujicoba berbasis alur, nilai yang dikomputasi untuk kompleksitas cyclomatic mendefinisikan jumlah independent path dalam himpunan basis suatu program dan menyediakan batas atas untuk sejumlah ujicoba yang harus dilakukan untuk memastikan bahwa seluruh perintah telah dieksekusi sedikitnya satu kali.
Cyclomatic complexity merupakan software metric yang menyediakan ukuran kuantitatif dari komplesitas logikal suatu program. Ketika digunakan dalam konteks metode ujicoba berbasis alur, nilai yang dikomputasi untuk kompleksitas cyclomatic mendefinisikan jumlah independent path dalam himpunan basis suatu program dan menyediakan batas atas untuk sejumlah ujicoba yang harus dilakukan untuk memastikan bahwa seluruh perintah telah dieksekusi sedikitnya satu kali.
Independent path adalah alur manapun dalam program yang memperkenalkan sedikitnya satu kumpulan perintah pemrosesan atau kondisi baru. Contoh independent path dari gambar flow graph diatas :
Path 1 : 1 – 11
Path 2 : 1 – 2 – 3 – 4 – 5 – 10 – 1 – 11
Path 3 : 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11
Path 4 : 1 – 2 – 3 – 6 – 7 – 9 – 10 – 1 – 11
Misalkan setip path yang baru memunculkan edge yang baru, dengan path :
1 - 2 – 3 – 4 – 5 – 10 - 1 - 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11
path diatas tidak dianggap sebagai independent path karena kombinasi path diatas telah didefinisikan sebelumnya Ketika ditetapkan dalam graf alur, maka independent path harus bergerak sedikitnya 1 edge yang belum pernah dilewati sebelumnya. Kompleksitas cyclomatic dapat dicari dengan salah satu dari 3 cara berikut :
1. Jumlah region dari graf alur mengacu kepada komplesitas cyclomatic
2. Kompleksitas cyclomatic untuk graf alur G didefinisikan :
V(G) = E – N + 2
Dimana E = jumlah edge, dan N = jumlah node
3. Kompleksitas cyclomatic untuk graf alur G didefinisikan :
V(G) = P + 1
Dimana P = jumlah predicates nodes
Berdasarkan flow graph gambar (b) diatas, maka kompleksitas cyclomatic-nya dapat di hitung sebagai berikut :
1. Flow graph diatas mempunyai 4 region
2. V(G) = 11 edges – 9 nodes + 2 = 4
3. V(G) = 3 predicates nodes + = 4
Hasil kompleksitas cyclomatic menggambarkan banyaknya path dan batas atas sejumlah ujicoba yang harus
dirancang dan dieksekusi untuk seluruh perintah dalam program.
Path 2 : 1 – 2 – 3 – 4 – 5 – 10 – 1 – 11
Path 3 : 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11
Path 4 : 1 – 2 – 3 – 6 – 7 – 9 – 10 – 1 – 11
Misalkan setip path yang baru memunculkan edge yang baru, dengan path :
1 - 2 – 3 – 4 – 5 – 10 - 1 - 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11
path diatas tidak dianggap sebagai independent path karena kombinasi path diatas telah didefinisikan sebelumnya Ketika ditetapkan dalam graf alur, maka independent path harus bergerak sedikitnya 1 edge yang belum pernah dilewati sebelumnya. Kompleksitas cyclomatic dapat dicari dengan salah satu dari 3 cara berikut :
1. Jumlah region dari graf alur mengacu kepada komplesitas cyclomatic
2. Kompleksitas cyclomatic untuk graf alur G didefinisikan :
V(G) = E – N + 2
Dimana E = jumlah edge, dan N = jumlah node
3. Kompleksitas cyclomatic untuk graf alur G didefinisikan :
V(G) = P + 1
Dimana P = jumlah predicates nodes
Berdasarkan flow graph gambar (b) diatas, maka kompleksitas cyclomatic-nya dapat di hitung sebagai berikut :
1. Flow graph diatas mempunyai 4 region
2. V(G) = 11 edges – 9 nodes + 2 = 4
3. V(G) = 3 predicates nodes + = 4
Hasil kompleksitas cyclomatic menggambarkan banyaknya path dan batas atas sejumlah ujicoba yang harus
dirancang dan dieksekusi untuk seluruh perintah dalam program.
sumber : Ayuliana/Testing dan Implementasi/Mar2009
