software testing techniques - gunadarmakartika_nur.staff.gunadarma.ac.id/downloads/files... ·...

TEKNIK PENGUJIAN PERANGKAT LUNAK(Software Testing Techniques)

Ujicoba software merupakan elemen yang kritis dari SQA dan merepresentasikan tinjauan ulang yang menyeluruh terhadap spesifikasi, desain dan pengkodean. Ujicoba merepresentasikan ketidaknormalan yang terjadi pada pengembangan software. Selama definisi awal dan fase pembangunan, pengembang berusaha untuk membangun software dari konsep yang abstrak sampai dengan implementasi yang memungkinkan.

Para pengembang membuat serangkaian uji kasus yang bertujuan untuk ”membongkar” software yang mereka bangun. Kenyataannya, ujicoba merupakan salah satu tahapan dalam proses pengembangan software yang dapat dilihat (secara psikologi) sebagai destruktif, dari pada sebagai konstruktif.

Pengembang software secara alami merupakan orang konstruktif. Ujicoba yang diperlukan oleh pengembang adalah untuk melihat kebenaran dari software yang dibuat dan konflik yang akan terjadi bila kesalahan tidak ditemukan. Dari sebuah buku, Glen Myers menetapkan beberapa aturan yang dapat dilihat sebagai tujuan dari ujicoba :

1. Ujicoba merupakan proses eksekusi program dengan tujuan untuk menemukan kesalahan.2. Sebuah ujicoba kasus yang baik adalah yang memiliki probabilitas yang tinggi dalam menemukan

kesalahan-kesalahan yang belum terungkap.3. Ujicoba yang berhasil adalah yang mengungkap kesalahan yang belum ditemukan.

Sehingga tujuan dari ujicoba ini adalah mendesain serangkaian tes yang secara sistematis mengungkap beberapa jenis kesalahan yang berbeda dan melakukannya dalam waktu dan usaha yang minimum.

Jika pengujian diselenggarakan dengan sukses, maka akan membongkar kesalahan yang ada didalam perangkat lunak, manfaat lain dari pengujian adalah menunjukkan bahwa fungsi perangkat lunak telah bekerja sesuai dengan spesifikasi, dan kebutuhan fungsi telah tercapai. Sebagai tambahan, data yang dikumpulkan pada saat pengujian dilaksanakan akan menyediakan suatu indikasi keandalan perangkat lunak yang baik dan beberapa indikasi mutu perangkat lunak secara keseluruhan.

Alur informasi test (Test Information Flow)

Test Information Flow

Ayuliana/Testing dan Implementasi/Mar2011

Correction

Test result

evaluation

TestingDebug

ReliabilityModel

SoftwareConfiguration

TestConfiguration

ExpectedResult

ErrorRate data

Predictedreliability

error

1

Alur informasi untuk ujicoba mengikuti pola seperti gambar diatas. Dua kategori input yang disediakan untuk proses ujicoba adalah : 1. Software configuration yang terdiri dari spesifikasi kebutuhan software, spesifikasi desain dan kode sumber.2. Test configuration yang terdiri dari rencana dan prosedur ujicoba, Tools ujicoba apapun yang dapat

digunakan, dan kasus ujicoba termasuk hasil yang diharapkan. Pada kenyataannya, konfigurasi ujicoba merupakan subset dari konfigurasi software.

Setiap lingkaran merepresentasikan transformasi yang lebih kompleks. Ujicoba dilakukan dan hasilnya dievaluasi, kemudian hasil ujicoba dibandingkan dengan hasil yang diharapkan . Ketika ditemukan data yang keliru, maka error ditemukan dan debug dimulai. Ketika hasil ujicoba dikumpulkan dan dievaluasi, indikasi kualitatif dari kualitas dan reliabilitas software mulai terlihat. Jika terjadi kesalahan fatal dan memerlukan modifikasi desain ditemukan secara reguler, maka kualitas dan reliabilitas software akan dipertanyakan dan diperlukan ujicoba lanjutan.

Sebaliknya jika fungsi software bekerja sebagaimana mestinya dan kesalahan yang terjadi dapat diatasi dengan mudah maka, dapat diambil 1 dari 2 kesimpulan dapat dibuat, yaitu : (1) Kualitas dan reliabilitas software dapat diterima, atau (2) Ujicoba tidak cukup untuk menemukan kesalahan yang fatal.

Akhirnya, jika ujicoba tidak menghasilkan kesalahan, maka harus terjadi keraguan bahwa konfigurasi ujicoba tersebut tidak berhasil dan masih terjadi kesalahan dalam software. Hal ini, akan dibuktikan oleh user dan akan diperbaiki oleh pengembang dalam fase pemeliharaan. Hasil-hasil yang dikumpulkan selama ujicoba dapat dievaluasi dengan cara formal.

Desain kasus Ujicoba (Test Case Design)Desain ujicoba untuk software atau produk teknik lainnya sama sulitnya dengan desain inisial dari

produk itu sendiri. Dengan tujuan dari ujicoba itu sendiri yaitu, mendesain ujicoba yang tingkat kemungkinan penemuan kesalahan yang tinggi dengan jumlah waktu dan usaha yang sedikit.

Selama beberapa dekade, metode desain ujicoba kasus telah dikembangkan. Metode ini menyediakan pendekatan sistematik untuk ujicoba. Hal yang lebih penting yaitu, metode-metode ini menyediakan mekanisme yang dapat membantu memastikan kelengkapan ujicoba dan menyediakan tingkat kemungkinan yang tinggi dalam penemuan kesalahan pada software.

Semua produk yang dikembangkan (engineered) dapat diujicoba dengan salah satu cara dari 2 cara berikut :1. Mengetahui fungsi-fungsi yang dispesifikasikan pada produk yang didesain untuk melakukannya, ujicoba

dapat dilakukan dengan mendemonstrasikan setiap fungsi secara menyeluruh;2. Mengetahui cara kerja internal dari produk, ujicoba dapat dilakukan untuk memastikan bahwa seluruh

operasi internal dari produk dilaksanakan berdasarkan pada spesifikasi dan komponen internal telah digunakan secara tepat.

Pendekatan pertama adalah black box testing dan yang kedua adalah white box testing. Black box testing menyinggung ujicoba yang dilakukan pada interface software. Walaupun didesain untuk menemukan kesalahan, ujicoba blackbox digunakan untuk mendemonstrasikan fungsi software yang dioperasikan; apakah input diterima dengan benar, dan ouput yang dihasilkan benar; apakah integritas informasi eksternal terpelihara. Ujicoba blackbox memeriksa beberapa aspek sistem, tetapi memeriksa sedikit mengenai struktur logikal internal software.

White box testing didasarkan pada pemeriksaan detail prosedural. Alur logikal suatu software diujicoba dengan menyediakan kasus ujicoba yang melakukan sekumpulan kondisi dan/atau perulangan tertentu. Status dari program dapat diperiksa pada beberapa titik yang bervariasi untuk menentukan apakah status yang diharapkan atau ditegaskan sesuai dengan status sesungguhnya.

Sepintas seolah-olah white box testing akan menghasilkan program yang 100% benar, yang diperlukan hanyalah mendefinisikan alur logikal, membangun kasus uji untuk memeriksa software tersebut dan mengevaluasi hasil yang diperoleh. Sayangnya, ujicoba yang menyeluruh ini menghadirkan masalah logikal tertentu. Untuk sebuah program sederhana sekalipun, terdapat banyak alur logikal yang memungkinkan. Sehingga white box testing sebaiknya hanya dilakukan pada alur logikal yang penting. Struktur data-struktur data yang penting dapat diujikan dengan uji validitas. Atribut dari black box testing dan white box testing dapat dikombinasikan untuk digunakan bersama.

Ayuliana/Testing dan Implementasi/Mar2011 2

WHITEBOX TESTINGUjicoba Whitebox merupakan 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 operasionalnya4. 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 perlu dilakukan selain blackbox testing.

UJICOBA BERBASIS 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.

A. Notasi graf Alur (Path Graph Notation)Notasi sederhana untuk merepresentasikan alur kontrol disebut graf alur (flow graph), seperti gambar dibawah ini :

Flow Graph Notation

Ayuliana/Testing dan Implementasi/Mar2011

Sequenceif

while

until

case

3

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.

(a)flow chart; (b)flow graph


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 :

(a) Translating PDL to flow graph

(b) Translating PDL with compound conditions to flow graph


B. Cyclomatic ComplexityCyclomatic 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 – 11Path 2 : 1 – 2 – 3 – 4 – 5 – 10 – 1 – 11Path 3 : 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11Path 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 cyclomatic2. Kompleksitas cyclomatic untuk graf alur G didefinisikan :

V(G) = E – N + 2Dimana 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 = 43. 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.

C. Deriving Test CasesMetode ujicoba berbasis alur dapat diaplikasikan pada detail desain prosedural atau kode sumber. Ujicoba berbasis alur direpresentasikan menjadi beberapa tahapan :1. Menggunakan desain atau kode sebagai pondasi, menggambarkan graf alur yang berhubungan.

Dengan menggunakan contoh Gambar (a), diagram alur dapat dibentuk dengan memberikan nomor untuk PDL. Perintah-perintah yang ada akan mengacu pada node dari suatu diagram alur. Perintah yang telah diberi nomor terlihat pada gambar (b).

2. Menetapkan komplesitas cyclomatic dari graf alur yang dihasilkan. Berdasarkan flow graph yang didapat pada Gambar (c), maka :

V(G) = 6 regionV(G) = 18 edges – 14 Nodes + 2 = 6V(G) = 5 Predicate nodes + 1 = 6


Gambar (a) PDL for test design

3. Menentukan himpunan basis dari alur independen yang linear.Nilai dari V(G) menyediakan sejumlah alur independen yang linear melalui struktur kontrol. Dalam kasusprosedur Average terdapat 6 : Path 1 : 1 – 2 – 10 – 11 – 13Path 2 : 1 – 2 – 10 – 12 – 13Path 3 : 1 – 2 – 3 – 10 – 11 – 13Path 4 : 1 – 2 – 3 – 4 – 5 – 8 – 9 – 2 – ...Path 5 : 1 – 2 – 3 – 4 – 5 – 6 – 8 – 9 – 2 – ...Path 6 : 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9 – 2 – ...

Tanda (...) mengindikasikan perulangan yang diperbolehkan. Dalam kasus ini node 2, 3, 5, 6, 10 merupakan Predicates node


Gambar (b) Identifying Nodes

Gambar (c) Flow Graph of procedure Average

4. Menyiapkan kasus uji yang akan mengeksekusi setiap alur dalam himpunan basisData harus dipilih sehingga kondisi pada predicate nodes dapat di uji dengan tepat


UJI KASUS Path 1:nilai (k) = Input yang Valid, dimana k < i yang didefinisikannilai (i) = -999 dimana 2 ≤ i ≤ 100Hasil yang diharapkan :

Nilai rata-rata yang benar berdasarkan nilai k dan total yang tepatCatatan :

Tidak dapat diujicoba secara terpisah, harus diujikan sebagai bagian dari uji Path 4, 5, dan 6

UJI KASUS Path 2:nilai (1) = -999Hasil yang diharapkan :

Nilai rata-rata/average = -999; total lainnya berisi nilai awal

UJI KASUS Path 3:Berusaha untuk memproses nilai 101 atau lebih100 nilai pertama harus validHasil yang diharapkan :

Sama dengan UJI KASUS Path 1

UJI KASUS Path 4:nilai (i) = Input yang Valid, dimana i < 100nilai (k) < minimum dimana k < iHasil yang diharapkan :

Nilai rata-rata yang benar berdasarkan nilai k dan total yang tepat

UJI KASUS Path 5:nilai (i) = Input yang Valid, dimana i < 100nilai (k) > maksimum dimana k ≤ iHasil yang diharapkan :

Nilai rata-rata yang benar berdasarkan nilai n dan total yang tepat

UJI KASUS Path 6:nilai (i) = Input yang Valid, dimana i < 100Hasil yang diharapkan :

Nilai rata-rata yang benar berdasarkan nilai n dan total yang tepat

Setiap uji kasus dijalankan dan hasil yang diperoleh dibandingkan dengan hasil yang diharapkan. Ketika seluruh uji kasus telah dijalankan, maka penguji dapat memastikan bahwa setiap perintah yang ada telah dieksekusi sedikitnya 1 kali.

D. Graph MatrixProsedur untuk menghasilkan graf alur dan menentukan himpunan alur basis dapat di mekanisasi. Untuk membangun tool software yang membantu dalam ujicoba berbasis alur, struktur data yang disebut graph matrix. Graph matrix merupakan matrik persegi yang jumlah baris dan kolomnya sesuai dengan jumlah node pada graf alur. Setiap baris dan kolom mengacu kepada sebuah node dan isi dari matrix mengacu kepada edge, contoh gambar (d).

Graph Matrix merupakan representasi tabular dari flow graph, dengan menambahkan link weight untuk setiap input pada matrik, maka matrik graf menjadi alat bantu yang lebih berguna untuk mengevaluasi struktur kontrol program selama ujicoba. link weight menyediakan informasi tambahan mengenai aliran kontrol. Dengan bentuk sederhana, yaitu berikan nilai 1 jika ada koneksi antar node dan nilai 0 jika tidak ada koneksi. Hal lain yang dapat diketahui melalui matrik graf :

1. Kemungkinan suatu link/ edge akan dieksekusi2. Waktu proses yang dibutuhkan selama traversal suatu link3. Memori yang diperlukan selama traversal suatu link4. Sumber daya yang diperlukan selama traversal suatu link


connected to node1 2 3 4 5

1 a23 d b4 c f5 g e

nodeGambar (d) Flow graph dan graph matric-nya

Perhatikan Gambar (e) dibawah ini, setiap huruf telah diganti dengan angka 1, yang mengindikasikan terdapat koneksi. Setiap baris dengan 2 atau lebih input merepresentasikan predicate node. Lihat bagian kanan tabel menunjukan cyclomatic complexity.

Gambar (d) Connection Matrix

UJICOBA BERBASIS STRUKTUR KONTROL (CONTROL STRUCTURE TESTING) Ujicoba berbasis struktur kontrol merupakan variasi lain yang memperluas cakupan uji dan meningkatkan kualitas whitebox testing.

A. Ujicoba Kondisi (Condition Testing)Ujicoba kondisi merupakan rancangan metode ujicoba kasus yang menguji kondisi logikal yang ada didalam modul program. Kondisi sederhana (simple condition) adalah variabel boolean atau ekspresi relational, yang mungkin dimulai dengan satu operator NOT ( ⌉ ). Ekspresi relasional mempunyai bentuk :

E1 <operator relasional> E2


Dimana, E1 dan E2 merupakan ekspresi aritmatika dan <operator relational> adalah salah satu dari operator <, >, =, ≤, ≥, ≠. Kondisi gabungan (compound condition) merupakan gabungan dari dua atau lebih kondisi sederhana, operator boolean dan parantesis (tanda kurung). Diasumsikan operator boolean yang diperbolehkan dalam kondisi gabungan termasuk OR ( | ), AND (&), dan NOT ( ⌉ ). Kondisi tanpa ekspresi relasional direferensikan sebagai ekspresi boolean.

Karena itu jenis-jenis komponen yang mungkin dalam kondisi termasuk operator boolean, variabel boolean, sapasang parantesis boolean, operator relasional atau ekspresi aritmatika. Jika kondisi salah, maka sedikitnya satu komponen dari kondisi ada yang salah. Jenis-jenis kesalahan dalam kondisi meliputi :1. Kesalahan operator boolean ( keberadaan operator boolean yang salah/berlebih/kurang)2. Kesalahan variable Boolean3. Kesalahan parantesis Boolean4. Kesalahan operator relasional5. Kesalahan ekspresi aritmatika

Metode ujicoba kondisi (condition testing) memfokuskan pada ujicoba setiap kondisi dalam program. Strategi ujicoba kondisi secara umum mempunyai 2 keuntungan, yaitu :1. pengukuran dari ujicoba mencakup kondisi senderhana2. Ujicoba mencakup kondisi dalam program menyediakan panduan untuk pembentukan ujicoba tambahan

bagi program

Kegunaan dari ujicoba kondisi adalah untuk mendeteksi, tidak hanya kesalahan kondisi dalam suatu program, tetapi juga kesalahan lain dalam program. Jika suatu ujicoba ditentukan untuk suatu program P, maka diharapkan ujicoba ini juga efektif untuk mendeteksi kesalahan lain dalam P. Jika suatu ujicoba efektif dalam mendeteksi kesalahan dalam kondisi, maka akan efektif juga untuk mendeteksi kesalahan lain.

Terdapat sejumlah strategi ujicoba kondisi. Ujicoba percabangan (branch testing ) merupakan strategi ujicoba kondisi yang paling sederhana. Jika terdapat kondisi gabungan C, true dan false merupakan percabangan dari C, maka setiap cabang sederhana harus dieksekusi sedikitnya satu kali.Ujicoba domain (domain testing) memerlukan 3 atau 4 kali ujicoba yang dilakukan untuk sebuah ekspresi relasional, misalkan saja ekspresi relasional dengan bentuk :

E1 <operator relasional> E2

Memerlukan 3 ujicoba untuk membuat nilai E1 lebih besar dari, sama dengan atau lebih kecil dari pada E2. Jika <operator relasional> salah dan E1 juga E2 benar, maka ketiga ujicoba ini menjamin pendeteksian dari kesalahan operator relasional. Untuk mendeteksi kesalahan dalam E1 dan E2, ujicoba yang menyebabkan nilai E1 lebih besar atau kurang dari E2 harus dibuat selisih sekecil mungkin.

Untuk ekspresi boolean dengan n variabel, maka diperlukan 2n ujicoba (n > 0). Strategi ini dapat mendeteksi kesalahan operator boolean, variabel dan parantesis. Jika ujicoba dilakukan pada ekspresi boolean singular ( yaitu setiap variabel boolean hanya muncul sekali) maka dibutuhkan ujicoba yang lebih sedikit dari 2n ujicoba.

Branch and relational operator testing (BRO) merupakan teknik yang menjamin pendeteksian dari kesalahan percabangan dan operator relasional dalam kondisi yang disediakan, dimana seluruh variabel boolean dan operator relasional dalam kondisi muncul hanyan sekali. Strategi BRO menggunakan batasan kondisi. Untuk kondisi C, maka batasan kondisi untuk C dengan n kondisi sederhana didefinisikan sebagai (D1, D2, .., Dn), dimana Di (0 < i ≤ n) merupakan simbol yang menspesifikasikan batasan dari hasil kondisi sederhana ke-i dalam kondisi C. Batasan kondisi D dalam kondisi C harus tercakupi dengan pengeksekusian C, jika selama eksekusi C, output dari setiap kondisi sederhana dalam C memenuhi batasan D yang ditetapkan. Misal diketahui contoh kondisi berikut (contoh 1):

C1 : B1 & B2

Dimana :B1 dan B2 : variabel boolean.Batasan kondisi untuk C1 adalah (D1, D2), dimana untuk setiap D1 dan D2 : true (t) atau false (f).


Nilai (t, f) merupakan batasan kondisi untuk C1 dan tercakupi oleh ujicoba yang menyebabkan nilai dari B1 menjadi true dan nilai B2 menjadi false.

Strategi ujicoba BRO membutuhkan himpunan batasan {(t, t), (f, t), (t, f)} tercakupi dengan pengeksekusian C1. Jika C1 salah disebabkan karena satu atau lebih kesalahan operator boolean, sedikitnya satu dari pasangan batasan akan menyebabkan C1 gagal.

Perhatikan contoh berikut (contoh 2):C2 : B1 & (E3 = E4)

Dimana :B1 : ekspresi boolean E3, E4 : ekspresi aritmatika. Batasan kondisi untuk C2 adalah (D1, D2) dimana : setiap D1 adalah t atau f, dan D2 adalah >, =, atau <,

maka dapat dibentuk himpunan batasan untuk C2 dengan memodifikasi batasan yang didefinisikan untuk C1. Dimana t untuk (E3=E4) mengamplikasikan =, dan f untuk (E3=E4)mengaplikasikan < atau >. Dengan mengganti (t, t) dan (f, t) dengan (t, =) dan (f, =) dan mengganti (t, f) dengan (t, <) dan (t, >) maka himpunan batasan untuk C2 adalah {(t, =), (f, =), (t, <), (t, >)}, maka himpunan batasan tadi akan menjamin pendeteksian kesalahan operator boolean dan operasional dalam C2.

Perhatikan contoh berikut (contoh 3) :C3 : (E1 > E2) & (E3 = E4)

Dimana :E1, E2, E3, E4 : operator aritmatika. Batasan kondisi untuk C3 dalam bentuk (D1, D2)dimana setiap D1 dan D2 adalah >, =, <.

Maka dapat dibentuk himpunan batasan sebagai berikut : {(>, =), (=, =), (<, =), (>, >), (<, <)}

B. Ujicoba Aliran Data (Data Flow Testing)Metode ujicoba aliran data memilih alur dari program berdasarkan lokasi pendefinisian dan penggunaan variabel dalam program. Untuk mengilustrasikan pendekatan ujicoba aliran data, asumsikan bahwa setiap perintah dalam program ditentukan sejumlah perintah yang unique dan setiap fungsi tidak merubah parameternya atau variabel global. Untuk perintah dengan S sebagai nomor perintah :

DEF (S) = {X| perintah S mengandung definisi X}USE (S) = {X| Perintah S mengandung penggunaan X}

Jika perintah S merupakan perintah if atau loop, himpunan DEF = kosong (empty) dan himpunan USE berdasarkan pada kondisi perintah S. Definisi variable X pada perintah S akan ada pada perintah S` jika ada alur(path) dari perintah S ke perintah S` yang tidak mengandung pendefinisian lain dari variable X.

Definition Use Chain (DU chain) dari variable X mempunyai bentuk [X, S, S`] dimana S dan S` adalah nomor perintah dan X dalam DEF(S) dan USE(S`) dan definisi X dalam perintah S ada dalam perintah S`. Contoh sederhana dari strategi ujicoba aliran data adalah untuk memastikan setiap DU chain tercakupi sedikitnya satu kali. Ujicoba DU tidak menjamin cakupan dari seluruh bagian program. Misalkan perintah if-then-else dan tidak menyertakan perintah untuk else maka ujicoba DU tidak diperlukan untuk kondisi else ini.

Strategi ujicoba aliran data berguna untuk menyeleksi ujicoba alur (path) program yang mengandung nested if dan perintah perulangan. Perhatikan contoh program berikut :

proc XB1;do while C1

if c2 then


if C4 then B4;else B5;

endif;else

if C3 then B2;else B3;

endif;endif;

enddo;B6;

End proc;

Untuk mengaplikasikan strategi DU untuk memilih ujicoba alur dari diagram kontrol, perlu mengetahui definisi dan penggunaan variabel dalam setiap kondisi atau blok dalam program. Diasumsikan bahwa variabel X didefinisikan pada perintah terakhir dari blok B1, B2, B3, B4, B5 dan digunakan dalam perintah pertama dari blok B2, B3, B4, B5, B6. Strategi ujicoba DU membutuhkan eksekusi dari alur terpendek dari setiap Bi, 0 < i ≤ 5, untuk setiap Bj, 2 < j ≤ 6 (Ujicoba jenis ini juga mencakup setiap penggunaan variabel X dalam kondisi C1, C2, C3, C4). Walaupun terdapat 25 rantai Duvariabel X, hanya dibutuhkan 5 alur untuk mencakup rantai DU ini. Alasannya adalah 5 alur ini dibutuhkan untuk mencakup rantai DU X dari Bi, 0 < i ≤ 5, ke B6 dan rantai DU lainnya dapat dicakup dengan membuat alur ini berulang.

Jika mengaplikasikan strategi percabangan untuk menyeleksi ujicoba alur program diatas, dengan ujicoba BRO perlu diketahui struktur dari setiap kondisi atau blok. ( Setelah memilih alur program, perlu menentukan apakah alur tersebut mungkin untuk program misal : terdapat sedikitnya satu input yang dilakukan untuk setiap alur)

Jika perintah dalam program dihubungkan antara satu dengan lainnya berdasarkan definisi dan penggunaan variabel, maka pendekatan ujicoba aliran data efektif untuk penjagaan kesalahan. Bagaimanapun, masalah pengukuran kecakupan (coverage) dan pemilihan alur (path) uji untuk ujicoba aliran data lebih sulit dibandingkan dengan ujicoba kondisi.

C. Ujicoba Perulangan (Loop Testing)Ujicoba perulangan (Loop Testing) merupakan ujicoba whitebox yang memfokuskan secara khusus pada validitas pembentukan loop. Terdapat 4 jenis loop yang berbeda, yaitu : simple loop, concatenated loop, nested loop, unstructured loop.

Simple loop, serangkaian ujicoba harus diaplikasikan pada loop sederhana, dimana n merupakan jumlah maksimum yang diperbolehkan dalam loop :1. Lewati loop secara keseluruhan (skip the loop entirely)2. Hanya satu yang melalui loop (only one pass through the loop)3. 2 melalui loop (two passes through the loop)4. m melalui loop, jika m < n (m passes the loop where m < n)5. n – 1, n, n+1 passes the loop

Nested loop, bila menerapkan ujicoba untuk loop sederhana pada nested loop, maka jumlah dari ujicoba yang mungkin berkembang secara geometri sejalan dengan peningkatan level dari nested. Beizer menyarankan pendekatan yang akan mengurangi jumlah ujicoba :1. Mulai dari loop terdalam, Tetapkan loop lainnya pada nilai minimum2. Lakukan uji loop sederhana untuk loop terdalam dan loop luar tetap pada parameter iterasi minimum.

Tambahkan ujicoba lainnya untuk out-of-range atau nilai lainnya (exclude value)3. Lakukan mengarah keluar, dan tetap mempertahankan loop luarnya dalam nilai minimum dan nested

loop lainnya dengan nilai yang sesuai.4. Lanjutkan sampai seluruh loop teruji.


Concatenated loop, dapat diuji dengan menggunakan pendekatan yang didefinisikan untuk loop sederhana, jika setiap loop saling independen. Jika loop digabungkan (concatenated) dan counter untuk loop1 digunakan sebagai nilai awal dari loop2, maka loop saling bergantung dan pendekatan untuk nested loop direkomendasikan

Unstructured loop, Jika mungkin sebaiknya loop jenis ini didesain ulang untuk merefleksikan kegunaan pembentukan struktur program.


software testing techniques - gunadarmakartika_nur.staff.gunadarma.ac.id/downloads/files... ·...

Documents