TESTING DAN IMPLEMENTASI

TEKNIK PENGUJIAN PERANGKAT LUNAK

Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekankan seperti yang dikatakan oleh Deutsch dalam Pressman (1997;525)

“Pengembangan sistem perangkat lunak melibatkan sederetan aktivitas produksi, peluang terjadinya kesalahan manusia sangat besar.  Kesalahan dapat mulai terjadi pada permulaan proses, sasaran ditetapkan secara tidak sempurna dan dalam desain dan tahapan pengembangan selanjutnya … Karena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna, maka pengembangan perangkat lunak diiringi dengan aktivitas jaminan kualitas”

Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan mempresentasikan kajian pokok dan spesifikasi, desain dan pengkodean.

Meningkatkan visibilitas (keadaan yang dapat dilihat dan diamati) perangkat lunak sebagai suatu elemen sistem dan biaya yang muncul akibat kegagalan perangkat lunak, memotivasi dilakukannyaperencanaan yang baik melalui pengujian yang teliti.  Hal wajar bagi organisasi pengembangan perangkat lunak untuk meningkatkan 30 % sampai 40 % usaha proyek total pada tahap pengujian.   Secara ekstrim pengujian perangkat lunak human rate (seperti kontrol penerbangan, memonitoring reaktor nuklir) dapat menelan biaya tiga sampai lima kali dari aktivitas rekayasa perangkat lunak lain yang dikombinasikan.

2.1. DASAR-DASAR PENGUJIAN PERANGKAT LUNAK

Pengujian menyajikan anomali yang menarik bagi perekayasa perangkat lunak.  Pada proses perangkat lunak, perekayasa pertama-tama berusaha membangun perangkat lunak dari konsep abstrak ke implementasi yang dapat dilihat, baru kemudian dilakukan pengujian .  perekayasa menciptakan sederetan test case yang dimaksudkan untuk “membongkar” perangkat lunak yang sudah dibangun.  Pada dasarnya, pengujian merupakan satu langkah dalm proses rekayasa perangkat lunak yang dapat dianggap (paling tidak secara psikologis) sebagai hal yang deskruktif daripada konstruktif.

Pengembangan  perangkat lunak, sesuai sifat 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 Beizer dalam Pressman (1997;526) menggambarkan situasi tersebut dengan mengatakan :

“Ada mitos yang menyatakan bahwa jika kita benar-benar baik dalam pemograman, maka tidak akan terjadi bug.  Jika kita benar-benar dapat berkosentrasi, jika setiap orang menggunakan pemograman terstruktur, desain top-down, tabel keputusan, jika program-program ditulis di dalam SQUISH, jika kita memiliki standar yang benar, maka tidak akan ada bug.  Kalau begitu, teruslah memegang mitos tersebut. Ada bug, kata mitos tersebut, karena kita buruk dalam apa yang kita lakukan dan jika kita buruk dalam hal itu, maka kita harus merasa bersalah karenanya.  Demikianlah, pengujian dan test case merupakan pemakluman terhadap kegagalan, yang tetap meninggalkan rasa bersalah. Rasa bosan dari pengujian hanyalah hukuman terhadap kesalahan kita.  Hukuman untuk apa? Untuk tidak membedakan antara apa yang dipikirkan oleh pemogram lain dan apa yang dikatakannya? Karena gagal menjadi telepatis? Karena tidak memecahkan masalah komunikasi manusia yang telah terjadi … selama 40 dekade?”

Haruskah pengujian meninggalkan rasa bersalah ?  Apakah pengujian benar-benar bersifat merusak ? Jawaban untuk pertanyaan-pertanyaan tersebut adalah “Tidak!” tetapi sasaran pengujian bagaimanapun berbeda dari apa yang kita harapkan.

Sasaran-Sasaran Pengujian

Dalam buku klasiknya mengenai pengujian perangkat lunak,Glen Myers dalam Pressman (1997;526) menyatakan sejumlah aturan yang berfungsi sebagai sasaran pengujian :

1.        Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan

2.        Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah diketemukan sebelumnya

3.        Pengujian yang sukses adalah pengujian yang mengungkapkan semua kesalahan yang belum pernah ditemukan sebelumnya

Sasaran tersebut mengimplikasikan adanya perubahan titik pandang yang dramatis.  Sasaran ini berlawanan dengan pandangan yang biasanya dipegang yang menyatakan bahwa pengujian yang berhasil adalah pengujian yang tidak ada kesalahan yang diketemukan.  Sasaran kita adalah mendesain pengujian yang secara sistematis mengungkapkan kelas kesalahan yang berbeda dan melakukannya dengan jumlah waktu dan usaha minimum.

Bila pengujian dilakukan secara sukses (sesuai dengan sasaran tersebut), maka akan ditemukan kesalahan di dalam perangkat lunak.  Sebagai keuntungan sekunder, pengujian menunjukkan bahwa fungsi perangkat lunak bekerja sesuai dengan spesifikasi dan bahwa persyaratan kinerja telah terpenuhi.  Sebagai tambahan, 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.

“Pengujian tidak dapat memperlihatkan tidak adanya cacat, pengujian hanya dapat memperlihatkan bahwa ada kesalahan perangkat lunak”

Penting untuk mengingat statemen tersebut pada saat pengujian dilakukan

Prinsip Pengujian

Sebelum mengaplikasikan metode untuk mendesain test case yang efektif, perekayasa perangkat lunak harus memahami prinsip dasar yang menuntun pengujian perangkat lunak. Davis dalam Pressman (1997;527) mengusulkan serangkaian prinsip pengujian yang telah diadaptasi untuk digunakan :

·           Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan. 

Sebagaimana telah kita ketahui, sasaran pengujian perangkat lunak adalah untuk mengungkap kesalahan.  Hal ini memenuhi kriteria bahwa cacat yang paling fatal (dari titik pandang pelanggan) adalah cacat yang menyebabkan program gagal memenuhi persyaratannya.

·           Pengujian harus direncanakan lama sebelum pengujian itu mulai. 

Perencanaan pengujian dapat dimulai segera setelah model persyaratan dilengkapi.  Definisi detail mengenai test case dapat dimulai segera setelah model desain diteguhkan.  Dengan demikian, semua pengujian dapat direncanakan dan dirancang sebelum semua kode dibangkitkan.

·           Prinsip Pareto berlaku untuk pengujian perangkat lunak.

Secara singkat, prinsip Pareto mengimplikasikan bahwa 80 persen dari semua kesalahan yang diketemukan selama pengujian sepertinya akan dapat ditelusuri sampai 20 persen dari semua modul program.  Masalahnya, bagaimana mengisolasi modul yang dicurigai dan mengujinya dengan teliti.

·           Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian “yang besar”.

Pengujian pertama yang direncanakan dan dieksekusi biasanya berfokus pada modul program individual.  Selagi pengujian berlangsung maju, pengujian mengubah fokus dalam usaha menemukan kesalahan pada cluster modul yang terintegrasi dan akhirnya pada sistem secara keseluruhan.

·           Pengujian yang mendalam tidak mungkin.

Jumlah jalur permutasi untuk program yang berukuran menengah pun sangat besar.  Oleh karena itu maka tidak mungkin mengeksekusi setiap kombinasi jalur skema pengujian.  Tetapi dimungkinkan untuk secara “adekuat” mencakup logika program dan memastikan bahwa semua kondisi dalam desain prosedural telah diuji.

·           Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independen.

Yang dimaksud dengan kata “yang paling efektif” adalah pengujian yang memiliki probabilitas tertinggi di dalam menemukan kesalahan (sasaran utama pengujian).  Perekayasa perangkat lunak yang membuat sistem tersebut bukanlah orang yang paling tepat untuk melakukan semua pengujian bagi perangkat lunak.

Testabilitas

Dalam lingkungan yang ideal, perekayasa perangkat lunak mendesain suatu program komputer, sebuah sistem atau suatu produk dengan “testabilitas” di dalam pikirannya.  Hal ini memungkinkan individu yang berurusan dengan pengujian mendesain test case yang efektif secara lebih mudah.  Tetapi apakah “testabilitas” itu ? James Bach dalam Pressman (1997;528) menggambarkan testabilitas dengan cara berikut :

Testabilitas perangkat lunak secara sederhana adalah seberapa mudah sebuah program komputer dapat diuji.  Karena pengujian sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi mudah.  Kadang-kadang pemogram bersedia melakukan hal-hal yang akan membantu proses pengujian dan checklist mengenai masalah-masalah desain yang mungkin, fitur dan lain sebagainya dapat menjadi berguna dalam bernegosiasi dengan mereka.

Sebenarnya ada metrik yang dapat digunakan untuk mengukur testabilitas di dalam sebagian besar aspeknya.  Kadang-kadang testabilitas digunakan untuk melihat seberapa “adekuat” serangkaian pengujian tertentu akan mencakup produk. 

Testabilitas juga digunakan oleh pihak militer untuk melihat seberapa mudah suatu piranti dapat diatur dan diperbaiki di lapangan.  Kedua hal tersebut tidak sama dengan “testabilitas perangkat lunak”.  Checklist berikut ini memberikan serangkaian karakteristik yang membawa kepada perangkat lunak yang dapat diuji.

1.        Operabilitas. “Semakin baik dia bekerja, semakin efisien dia dapat diuji”

·      Sistem memiliki beberapa bug (bug menambah analisis dan biaya pelaporan ke proses pengujian)

·      Tidak ada bug yang memblok eksekusi pengujian

·      Produk berkembang di dalam tahapan fungsional (memungkinkan pengembangan dan pengujian secara simultan)

2.        Observabilitas. “Apa yang anda lihat adalah apa yang anda uji”

·      Output yang berbeda dikeluarkan oleh masing-masing input

·      Tahap dan variabel sistem dapat dilihat atau diantrikan selama eksekusi

·      Sistem dan variabel yang lalu dapat dilihat atau didiantrikan(misalnya, log transaksi)

·      Semua faktor yang mempengaruhi output dapat dilihat

·      Output yang tidak benar dapat diidentifikasi dengan mudah

·      Kesalahan internal dideteksi secara otomatis melalui mekanisme self-testing

·      Kesalahan internal dilaporkan secara otomatis

·      Kode sumber dapat diakses

3.        Kontrolabilitas. “semakin baik kita dapat mengontrol perangkat lunak, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalisasikan”

·      Semua output yang mungkin dapat dimunculkan melalui beberapa kombinasi input

·      Semua kode dapat dieksekusi melalui berbagai kombinasi input

·      Keadaan dan variabel perangkat lunak dan perangkat keras dapat dikontrol secara langsung oleh perekayasa pengujian

·      Format input dan output kosisten dan terstruktur

·      Pengujian dapat dispesifikasi, dioptimasi dan di reproduksi dengan baik.

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

·      Sistem perangkat lunak dibangun dari modul-modul independen

·      Modul-modul perangkat lunak dapat diuji secara independen

5.        Kesederhanaan.  “Semakin sedikit yang diuji, semakin cepat kita dapat mengujinya”.

·      Kesederhanaan fungsional (seperti, kumpulan fitur adalah kebutuhan minimum untuk memenuhi persyaratan)

·      Kesederhanaan struktural  (seperti, arsitektur dimodularisasi untuk membatasi penyebaran kesalahan)

·      Kesederhanaan kode (seperti, standar pengkodean diadopsi demi kemudahan inspeksi dan pemeliharaan)

6.        Stabilitas. “Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian”

·      Perubahan ke perangkat lunak tidak sering

·      Perubahan ke perangkat lunak terkontrol

·      Perubahan ke perangkat lunak memvalidasi pengujian yang sudah ada

·      Kegagalan perangkat lunak dapat diperbaiki dengan baik

7.        Kemampuan untuk dapat dipahami.  “Semakin banyak informasi yang kita miliki, semakin halus pengujian yang akan dilakukan.”

·      Desain dipahami dengan baik

·      Ketergantungan di antara komponen internal, eksternal dan yang dipakai bersama, dipahami dengan baik

·      Perubahan ke desain dikomunikasikan.

·      Dokumentasi teknik dapat diakses dengan cepat

·      Dokumentasi teknik diorganisasikan dengan baik

·      Dokumentasi teknis spesifik dan detail

·      Dokumentasi teknis akurat

Atribut-atribut yang diusulkan oleh James Bach dapat digunakan oleh perekayasa perangkat lunak untuk mengembangkan suatu konfigurasi perangkat lunak (yakni program, data dan dokumen dll) yang dapat dipertanggung jawabkan pada pengujian.

Bagaimana dengan pengujian itu sendiri ? Kaner, Falk dan Nguyen dalam Pressman (1997;530) mengusulkan atribut-atribut dari pengujian yang “baik” sebagai berikut :

1.        Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.

Untuk mencapai hal ini, penguji harus memahami perangkat lunak dan berusaha mengembangkan gambaran mental mengenai bagaimana perangkat lunak dapat gagal.  Idealnya kelas-kelas kegagalan itu diselidiki.  Sebagai contoh, kelas kegagalan potensial pada GUI (Graphical User Interface) adalah kegagalan untuk mengenali posisi mouse untuk memperlihatkan kesalahan di dalam pengenalan posisi mouse.

2.        Pengujian yang baik tidak redundan.

Waktu pengujian dan sumber daya terbatas.  Tidak ada manfaatnya melakukan pengujian dengan tujuan yang sama dengan pengujian lainnya.  Setiap pengujian harus memiliki tujuan yang berbeda (bahkan meskipun benar-benar berbeda).  Sebagai contoh, modul perangkat lunak safehome (sistem keamanan rumah yang digunakan sebagai aplikasi contoh) didesain untuk mengenali password pemakai untuk mengaktifkan dan mendeaktifkan sistem.  Dalam usaha mengungkapkan kesalahan pada input password, penguji mendesain serangkaian pengujian yang memasukkan serangkaian password.  Password yang berlaku dan tidak berlaku (empat urutan numeris) diinputkan sebagai pengujian yang berbeda.  Tetapi masing-masing password valid / invalid harus memeriksa model kegagalan yang berbeda.  Sebagai contoh, password invalid 1234 tidak boleh diterima oleh sistem yang diprogram untuk mengenali 8080 sebagai password yang valid (berlaku).  Bila 1234 diterima, maka kesalahan muncul.  Pengujian yang lain, katakanlah 1235, akan memiliki tujuan yang sama dengan 1234 sehingga redundan.  Tetapi input invalid 8081 atau 8180 memiliki perbedaan yang jelas, yang berusaha memperlihatkan bahwa suatu kesalahan akan muncul untuk password yang “dekat” tetapi tidak sama dengan password yang valid.

3.        Pengujian yang baik seharusnya “jenis terbaik”.

Dalam suatu kelompok pengujian yang memiliki tujuan yang serupa, batasan waktu dan sumber daya dapat menghalangi eksekusi hanya kelompok kecil dari pengujian tersebut.  Pada kasus semacam ini maka pengujian yang memiliki kemungkinan paling besar untuk mengungkap seluruh kelas kesalahan yang tinggi yang harus digunakan.

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

Meskipun kadang-kadang mungkin untuk menggabungkan serangkaian pengujian ke dalam satu test case secara umum masing-masing test case harus dieksekusi secara terpisah.

2.2. DESAIN TEST CASE

Desain pengujian perangkat lunak dan produk rekayasa lain dapat sama-sama menantang dengan desain awal dari produk itu sendiri.  Tetapi untuk alsan yang telah disebutkan, perekayasa perangkat lunak sering memperlakukan pengujian sebagai pikiran yang timbul kemudian, mengembangkan test case yang mungkin “merasa benar” tetapi tidak menjamin kelengkapannya. Dengan melihat lagi sasaran pengujian, kita harus mendesain yang memiliki kemungkinan tertinggi dalam menemukan kesalahan dengan jumlah waktu dan usaha yang minimum.

Lebih dari dua dekadeterakhir ini telah berkembang berbagai metode desain test case untuk perangkat lunak.  Metode-metode tersebut memberikan kepada pengembang sebuah pendekatan yang sistematik ke pengujian.  Yang lebih penting, metode itu memberikan mekanisme yang dapat membantu memastikan kelengkapan pengujian dan memberikan kemungkinan tertinggi untuk mengungkap kesalahan pada perangkat lunak.

Semua produk yang direkayasa (dan sebagian besar hal lain) dapat  diuji  dengan  satu   atau   dua cara :

4.    Dengan mengetahui fungsi yang ditentukan, produk dirancang untuk melakukannya, pengujian dapat dilakukan untuk memperlihatkan bahwa masing-masing fungsi beroperasi sepenuhnya pada waktu yang sama mencari kesalahan pada setiap fungsi.  Pendekatan pengujian tersebut yang disebut pengujian black-box

5.    Dengan mengetahui kerja 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.  Pendekatan pengujian tersebut yang disebut pengujian white-box.

Jika perangkat lunak komputer dipertimbangkan, maka pengujian black-box berkaitan dengan pengujian yang dilakukan pada interface perangkat lunak.  Meskipun didesain untuk mengungkap kesalahan, pengujian black-box digunakan untuk memperlihatkan bahwa fungsi-fungsi perangkat lunak adalah : operasional; Bahwa input diterima dengan baik dan output dihasilkan dengan tepat dan integritas informasi eksternal (seperti file data) dipelihara.  Pengujian black-box menguji beberapa aspek dasar suatu sistem dengan sedikit memperhatikan struktur logika internal perangkat lunak tersebut.

Pengujian white-box perangkat lunak didasarkan pada pengamatan yang teliti terhadap detail prosedural.  Jalur-jalur logika yang melewati perangkat lunak diuji dengan memberikan test case yang menguji serangkaian kondisi dan atau loop tertentu.  “Status program tersebut” dapat diuji pada berbagai titik untuk menentukan apakah status yang diharapkan atau dituntut sesuai dengan status aktual.

Sekilas sepertinya pengujian white-box yang sangat teliti akan membawa kepada “Program yang benar 100 persen”.  Yang kita perlukan adalah menentukan semua jalur logika, mengembangkan test case untuk mengujinya dan mengevaluasi hasil, yaitu memunculkan test case yang menguji logika program secara mendalam.  Sayangnya, pengujian yang mendalam menimbulkan masalah logistik tertentu. Bahkan untuk program yang kecil, jumlah jalur logika yang mungkin dapat sangat luas.  Sebagai contoh, perhatikan program 100 baris dalam bahasa C.  setelah beberapa deklarasi data, program berisi dua loop tersarang yang masing-masing mengeksekusi dari 1 sampai 20 kali, tergantung kondisi yang ditentukan pada input.  Pada loop bagian dalam, empat bangun if-then-else diperlukan.  Kira-kira ada 10¹⁴ jalur yang mungkin yang dapat dieksekusi pada program ini.

Untuk menaruh jumlah tersebut dalam perspektif sebenarnya, kita asumsikan bahwa sebuah prosesor pengujian ajaib (“Ajaib” karena tidak ada prosesor semacam itu) telah dikembangkan untuk pengujian mendalam. Prosesor tersebut dapat mengembangkan suatu test case, mengeksekusi dan mengevaluasi hasilnya dalam satu milidetik.  Dengan bekerja 24 jam sehari, 365 hari satu tahun, prosesor akan bekerja selama 3170 tahun untuk menguji program.  Jelas hal itu akan menyebabkan kerusakan pada sebagian besar jadwal pengembangan.  Pengujian yang mendalam tidak mungkin dilakukan untuk sistem perangkat lunak yang besar.

 Tetapi pengujian white-box tidak boleh dianggap tidak praktis.  Sejumlah terbatas dari jalur logika yang penting dapat dipilih dan digunakan.  Struktur-struktur data yang penting dapat diperiksa validitasnya. Atribut pengujian black-box dan white-box dapat digabungkan untuk memberikan pendekatan yang memvalidasi interface perangkat lunak dan secara selektif menjamin bahwa kerja internal dari perangkat lunak itu benar.

2.3. PENGUJIAN WHITE-BOX

Pengujian white-box, yang kadang-kadang disebut pengujian glass-box, adalah metode desain test case yang menggunakan struktur kontrol desain prosedural untuk memperoleh test case.  Dengan menggunakan metode pengujian white-box, perekayasa sistem dapat melakukan test case yang :

6.        Memberikan jaminan bahwa semua jalur independen pada suatu modul yang telah paling tidak satu kali

7.        Menggunakan semua keputusan logis pada sisi true dan false

8.        Mengeksekusi semua loop pada batasan mereka dan pada batas operasional mereka

9.        Menggunakan struktur data internal untuk menjamin validitasnya.

Pada titik ini, dapat diajukan pertanyaan yang beralasan, yaitu : “Mengapa menghabiskan waktu dan energi untuk mencemaskan (dan menguji) logika jika kita dapat dengan lebih baik memperluas kerja yang dapat memastikan bahwa persyaratan program telah dipenuhi ?”.  Bila dinyatakan dengan cara lain, mengapa kita tidak menggunakan semua energi kita untuk melakukan pengujian black-box ? Jawabannya ada pada sifat cacat perangkat lunak :

·           Kesalahan logis dan asumsi yang tidak benar berbanding terbalik dengan probabilitas jalur program yang akan dieksekusi.

Kesalahan cenderung muncul dalam kerja kita pada saat kita mendesain dan mengimplementasi fungsi, kondisi atau kontrol yang berada di luar mainstream.  Pemrosesan setiap hari cenderung dipahami dengan baik (dan diteliti dengan baik) sementara pemrosesan “kasus khusus” cenderung berantakan.

·           Kita sering percaya bahwa jalur logis mungkin tidak akan dieksekusi bila pada kenyataannya akan dieksekusi pada basis reguler.

Aliran logika dari suatu program kadang-kadang bersifat konterintuitif, yang berarti asumsi kita yang kita tidak sadari mengenai aliran dan data kontrol dapat menyebabkan kita membuat kesalahan desain yang akan terungkap hanya setelah pengujian jalur memulai.

·           Kesalahan tipografis adalah random.

Bila sebuah program diterjemahkan ke dalam kode sumber bahasa pemrograman maka dimungkinkan akan terjadi banyak kesalahan pengetikan.  Beberapa akan ditemukan dengan mekanisme pengecekan sintaks, tetapi yang lainnya akan tetap tidak terdeteksi sampai pengujian mulai.  Dimungkinkan bahwa suatu type akan ada pada suatu jalur logika tidak jelas seperti pada jalur mainstream.

Masing-masing alasan tersebut memberikan suatu argumen untuk melakukan pengujian white-box.  Pengujian black-box, tidak peduli seberapa cermat dilakukan dapat tidak menangkap bentuk kesalahan tersebut.  Seperti dikatakan oleh Beizer dalam Pressman (1997;534) adalah “Bug bersembunyi di sudut-sudut dan berkerumun di perbatasan-perbatasan”.  Tetapi pengujian white-box sangat mungkin untuk menemukannya.

2.4. PENGUJIAN BASIS PATH

Pengujian basis Path adalah teknik pengujian white-box yang diusulkan pertama kali oleh Tom McCabe.  Metode basis path ini memungkinkan desainer test case mengukur kompleksitas logis dari desain prosedural dan menggunakannya sebagai pedoman untuk menetapkan basis set dari jalur eksekusi.  Test case yang dilakukan untuk menggunakan basis set tersebut dijamin untuk menggunakan setiap statemen di dalam program paling tidak sekali selama pengujian.

Notasi Diagram Alir

Sebelum metode basis path dapat diperkenalkan, notasi sederhana untuk representasi aliran kontrol yang disebut diagram alir (atau grafik program), harus diperkenalkan. 

Untuk menggambarkan grafik alir, perhatikan representasi desain prosedural pada gambar 2a di sini bagan alir digunakan untuk menggambarkan struktur kontrol program. 

Gambar 2b. memetakan bagan alir tersebut ke dalam grafik alir yang sesuai (dengan mengasumsikan bahwa tidak ada kondisi senyawa yang diisikan di dalam diamond keputusan dari bagan alir tersebut.  Pada gambar 2b. masing-masing lingkaran, yang disebut simpul grafik alir, mempresentasikan satu atau lebih statemen prosedural.  Urutan kotak proses dan permata keputusan dapat memetakan simpul tunggal. Anak panah pada grafik alir tersebut, yang disebut edges atau links, mempresentasikan aliran kontrol dan analog dengan anak panah bagan alir. Edge harus berhenti pada suatu simpul, meskipun bila simpul tersebut tidak mempresentasikan statemen prosedural (misalnya, lihat simpul untuk bangun if-then-else).  Area yang dibatasi oleh edge dan simpul disebut region.  Pada saat menghitung region, kita memasukkan area di luar grafik dan menghitungnya sebagai sebuah region.

Setiap representasi desain prosedural dapat diterjemahkan ke dalam suatu grafik alir.                            Pada gambar 3. diperlihatkan segmen PDL dan grafik alirnya yang sesuai.  Perhatikan bahwa statemen PDL telah diberi nomor dan penomoran yang sesuai digunakan untuk grafik alir tersebut.

Bila ada kondisi gabungan dalam desain prosedural, maka pembuatan grafik alir menjadi sangat rumit.  Kondisi gabungan terjadi bila satu atau lebih operator Boolean (logika OR, AND, NAND, NOR) ada pada statemen kondisional.  Gambar 4. menunjukkan sebuah segmen PDL menerjemahkan ke dalam grafik alir.  Perhatikan bahwa simpul (node) yang terpisah diciptakan untuk masing-masing kondisi a dan b pada statemen IF a OR b.  Masing-masing simpul yang berisi sebuah kondisi disebut simpul predikat dan ditandai dengan dua atau lebih edge yang berasal darinya.

 Kompleksitas Siklomatis

Kompleksitas Siklomatis adalah metriks perangkat lunak yang memberikan pengukuran kuntitatif terhadap kompleksitas logis suatu program.  Bila metriks ini digunakan dalam konteks metode pengujian basis path, maka nilai yang terhitung untuk kompleksitas siklomatis menentukan jumlah jalur independen dalam basis set suatu program dan memberi batas atas bagi jumlah pengujian yang harus dilakukan untuk memastikan bahwa semua statemen telah dieksekusi sedikitnya satu kali.

Jalur independen adalah jalur yang melalui program yang mengintroduksi sedikitnya satu rangkaian statemen proses baru atau suatu kondisi baru.  Bila dinyatakan dengan terminologi grafik alir, jalur independen harus bergerak sepanjang paling tidak satu edge yang tidak dilewatkan sebelum jalur tersebut ditentukan. 

Sebagai contoh serangkaian jalur independen untuk grafik alir yang ditunjukkan pada gambar 2b. adalah :

Jalur 1 : 1 – 11

Jalur 2 : 1-2-3-4-5-10-1-11

Jalur 3 : 1-2-3-6-8-9-10-1-11

Jalur 4 : 1-2-3-6-7-9-10-1-11

Perhatikan bahwa masing-masing jalur baru memperkenalkan sebuah edge baru.

Jalur 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

Tidak dianggap jalur independen karena merupakan gabungan dari jalur-jalur yang sudah ditentukan dan tidak melewati beberapa edge baru.

Jalur 1, 2, 3 dan 4 yang ditentukan di atas terdiri dari sebuah basis set untuk grafik alir pada gambar 2b. bila pengujian dapat dilakukan untuk memaksa adanya eksekusi dari jalur-jalur tersebut (sebuah basis set), maka setiap statemen pada program tersebut akan dieksekusi paling tidak satu kali dan setiap kondisi sudah akan dieksekusi pada sisi true dan false – nya.  Perlu dicatat bahwa basis set tidaklah unik.  Pada dasarnya, semua jumlah basis set yang berbeda dapat diperoleh untuk suatu desain prosedural yang diberikan.

Bagaimana kita tahu banyaknya jalur yang dicari? Komputasi kompleksitas siklomatis memberikan jawaban.  Fondasi kompleksitas siklomatis adalah teori grafik dan memberi kita metriks perangkat lunak yang sangat berguna.  Kompleksitas dihitung dalam salah satu dari tiga cara berikut :

10.    Jumlah region  grafik alir sesuai dengan kompleksitas siklomatis

11.    Kompleksitas siklomatis, V(G), untuk grafik alir G ditentukan sebagai V(G) = E – N + 2 dimana E adalah jumlah edge grafik alir dan N adalah jumlah simpul grafik alir

12.    Kompleksitas siklomatis, V(G), untuk grafik alir G juga ditentukan sebagai V(G) = P + 1 dimana P adalah jumlah simpul predikat yang diisikan dalam grafik alir G.

Lihat sekali lagi grafik alir pada gambar 2b. kompleksitas siklomatis dapat dihitung dengan menggunakan masing-masing dari algoritma yang ditulis di atas :

1.        Grafik alir mempunyai 4 region

2.        V(G) = 11 edge – 9 simpul + 2 = 4

3.        V(G) = 3 simpul yang diperkirakan + 1 = 4

Dengan demikian, kompleksitas siklomatis dari grafik alir pada gambar 2b. adalah 4.

Yang lebih penting, nilai untuk V(G) memberi kita batas atas untuk jumlah jalur independen yang membentuk basis set dan implikasinya, batas atas jumlah pengujian yang harus didesain dan dieksekusi untuk menjamin semua statemen program.

Melakukan Test Case

Metode pengujian basis pat dapat diaplikasikan pada desain prosedural atau kode sumber.  Pada subbab ini akan disajikan pengujian basis path sebagai sederetan langkah.  Average prosedur yang digambarkan dalam PDL pada gambar 5, akan digunakan sebagai contoh untuk menggambarkan masing-masing langkah pada metode desain test case.  Perhatikan bahwa average, meskipun merupakan suatu algoritma yang sederhana, berisi kondisi gabungan dan loop.

PROCEDURE Average

·         This procedure computes the everage of 100 or fewer

Number that lie between bounding values; it also computes

The sum and the total number valid

            INTERFACE RETURNS average, total.input, total.valid;

            INTERFACE ACCEPTS Accepts value, minimum, maximum;

            TYPE value[1:100] IS SCALAR ARRAY;

            TYPE average, total.input, total.valid;

                        Minimum, maximum, sum IS scalar;

            TYPE i IS INTEGER;

            i = 1;

            total.input = total.valid = 0;

            sum = 0;

            DO WHILE value [i] < > 999  and total.input < 100

                        Increment tital.input by 1;

                        IF value [i] > = minimum AND value [i] < = maximum

                                    THEN increment total.valid by 1;

                                                Sum = sum + value [i]

                                    ELSE skip

                        ENDIF

                        Increment I by 1;

            ENDDO

            IF total.valid > 0

                        THEN average = sum / total.valid;

                        ELSE average = - 999;

            ENDIF

END average 

Gambar 5. PDL untuk desain test case dengan simpul-simpul yang diidentifikasi

1.        Dengan menggunakan atau kode sebagai dasar, gambarkan sebuah grafik alir yang sesuai.

Grafik alir diciptakan dengan menggunakan simbol dan aturan konstruksi yang disajikan pada notasi diagram Alir. Lihat PDL untuk average pada gambar 5. Grafik aliran diciptakan dengan menomori statemen-statemen PDL yang akan dipetakan ke dalam simpul grafik aliran yang sesuai.  

2.        Tentukan kompleksitas siklomatis dari grafik alir resultan.

Kompleksitas  siklomatis, V(G), ditentukan dengan mengaplikasikan satu dari algoritma-algoritma yang telah digambarkan di atas.  Perlu dicatat bahwa V(G) dapat ditentukan tanpa mengembangkan grafik alir dengan menghitung semua statemen kondisional dalam PDL (Program Description Language) (untuk average prosedur, kondisi gabungan menghitung 2) dan penambahan 1.

V(G) = 6 Region

V(G) = 18 edge – 14 simpul + 2 = 6

V(G) = 5 simpul predikat + 1 = 6

3.        Tentukan sebuah basis set dari jalur independen secara linier.

Harga V(G) memberikan jumlah jalur independen secara linier melalui struktur kontrol program.  Dalam kasus average prosedur, kita dapat menentukan 6 jalur adalah :

Jalur 1 : 1-2-10-11-13

Jalur 2 : 1-2-10-12-13

Jalur 3 : 1-2-3-10-11-13

Jalur 4 : 1-2-3-4-5-8-9-2-…

Jalur 5 : 1-2-3-4-5-6-8-9-2-…

Jalur 6 : 1-2-3-4-5-6-7-8-9-2-…

Elips (…) yang mengikuti jalur 4, 5 dan 6 menunjukkan bahwa sembarang jalur yang peringatan struktur kontrol dapat diterima.  Seringkali berguna untuk mengidentifikasi simpul predikat sebagai peranti dalam derivasi test case.  Pada kasus ini, simpul 2, 3, 5, 6 dan 10 adalah simpul predikat.

4.        Siapkan test case yang akan memaksa adanya eksekusi setiap basis set.

Data harus dipilih sehingga kondisi pada simpul-simpul predikat terpasang secara tepat pada saat masing-masing jalur diuji. Test case yang memenuhi basis set yang digambarkan di atas adalah :

Test case jalur 1 :

Harga (k) = input valid, dimana k<I yang ditetapkan di bawah

Harga (i) =  - 999, dimana 2 ≤ i ≤ 100

Hasil yang diharapkan : rata-rata yang benar berdasarkan nilai k dan total yang tepat

Catatan : jalur 1 tidak dapat diuji sendiri karena harus diuji sebagai bagian dari pengujian    jalur 4, 5 dan 6 

Test case jalur 2 :

Harga (i) = - 999

Hasil yang diharapkan : rata-rata = - 999; total yang lain pada nilai awal

Test case jalur 3 :

Usahakan untuk memproses 101 nilai atau lebih

100 nilai pertama harus valid

Hasil yang diharapkan : sama seperti test case 1

Test case jalur 4 :

Nilai (i) = input valid, dimana i < 100

Nilai (k) < minimum, dimana k < i

Hasil yang diharapkan : rata-rata yang benar berdasarkan nilai-nilai k dan total yang tepat.

Test case jalur 5 :

Nilai (i) = input valid, dimana i < 100

Nilai (k) > minimum, dimana k ≤ i

Hasil yang diharapkan : rata-rata yang benar berdasarkan nilai-nilai n dan total yang tepat.

Test Case jalur 6 :

Nilai (i) = input valid, dimana i < 100

Hasil yang diharapkan : rata-rata yang benar berdasarkan nilai-nilai n dan total yang tepat.

Masing-masing test case dieksekusi dan dibandingkan untuk mendapatkan hasil yang diharapkan.  Sekali semua test case telah dilengkapi maka penguji dapat yakin bahwa semua statemen pada program telah dieksekusi paling tidak satu kali.

Penting untuk dicatat bahwa beberapa jalur independen (misalnya, jalur 1 pada contoh tersebut) tidak dapat diuji secara terpisah (sendiri), karena kombinasi aliran normal dari program.  Dalam kasus semacam ini, jalur-jalur itu diuji sebagai bagian dari pengujian jalur yang lain.

Matriks Grafik

Prosedur untuk mendapatkan grafik alir dan bahkan menentukan serangkaian basis path cocok dengan mekanisasi.  Untuk mengembangkan peranti perangkat lunak yang membantu pengujian basis path, struktur data yang disebut matriks grafis dapat sangat berguna.

Matriks grafis adalah matriks bujur sangkar yang ukurannya (yakni jumlah baris dan kolom) sama dengan jumlah simpul pada grafik alir.  Masing-masing baris dan kolom sesuai dengan simpul yang diidentifikasikan dan entri matriks sesuai dengan edge di antara simpul.  Contoh sederhana grafik alir dan matriks grafisnya yang sesuai diperlihatkan pada gambar 7.

Pada gambar tersebut, masing-masing simpul pada grafik alir diidentifikasi oleh bilangan, sementara masing-masing edge diidentifikasi dengan huruf.  Entri huruf dibuat di dalam matriks tersebut untuk cocok dengan koneksi di antara dua simpul.  Sebagai contoh, simpul 3 disambungkan dengan simpul 4 oleh edge b.

	Terhubung ke simpul
Simpul		1	2	3	4	5
	1			a
	2
	3		d		b
	4		c			f
	5		g	e

Gambar 7. Matriks Koneksi

Untuk titik ini, matriks grafis tidak lebih dari sekedar representasi tabuler dari grafik alir.  Tetapi dengan menambahkan sebuah link weight pada masing-masing entri matriks, maka matriks grafisdapat menjadi alat yang sangat kuat untuk mengevaluasi struktur kontrol program selama pengujian.  Link weight memberikan informasi tambahan mengenai aliran kontrol.  Dalam bentuknya yang paling sederhana, link weight adalah 1 (ada hubungan) atau 0 (tidak ada hubungan) tetapi link weight dapat diterapkan lain, yaitu properti yang lebih menarik :

·           Probabilitas sebuah link (edge) akan dieksekusi

·           Waktu pemrosesan yang digunakan selama pelewatan sebuah link

·           Memori yang diperlukan selama pelewatan link, dan

·           Sumber daya yang diperlukan selama pelewatan link

Untuk menggambarkan, kita gunakan pembebanan sederhana untuk menunjukkan hubungan (0 atau 1).  Matriks grafis pada gambar 7 digambarkan lagi seperti yang ditunjukkan pada gambar 8. Masing-masing huruf telah diganti dengan dengan angka 1yang menunjukkan bahwa ada hubungan (nil telah dihilangkan supaya jelas).  Dengan bentuk seperti itu, matriks grafis disebut matriks koneksi.  Pada gambar 8, masing-masing baris dengan dua entri atau lebih mempresentasikan sebuah simpul predikat.  Dengan demikian, dengan mengerjakan aritmatika yang diperlihatkan di sebelah kanan sambungan matriks akan memberi kita metode lain untuk menentukan kompleksitas siklomatis.

	Terhubung ke simpul
Simpul		1	2	3	4	5	Koneksi
	1			1			1 – 1 = 0
	2
	3		1		1		2 – 1 = 1
	4		1			1	2 – 1 = 1
	5		1	1			2 – 1 = 1
		Matriks Grafik					3 + 1 = 4 Kompleksitas Siklomatis

Gambar 8. Matriks Koneksi

Beizar dalam Pressman (1997;544) memberikan perlakuan yang terliti dari algoritma matematika tambahan yang dapat diaplikasikan pada matriks-matriks grafis.  Dengan menggunakan teknik tersebut, maka analisis yang diperlukan untuk mendesain test case dapat diotomasi sebagian atau sepenuhnya.

2.5. PENGUJIAN STRUKTUR KONTROL

Teknik pengujian basis path yang digambarkan adalah satu dari sejumlah teknikuntuk pengujian struktur kontrol.  Meskipun pengujian basis path adalah sederhana dan sangat efektif, tetapi pengujian itu tidak memadai.  Dalam subbab ini akan dibahas variasi lain pada pengujian struktur kontrol.  Hal ini memperluas kupasan pengujian dan meningkatkan kualitas pengujian white-box.

Pengujian Kondisi

Pengujian kondisi adalah sebuah metode desain test case yang menggunakan kondisi logis yang ada pada suatu program.  Kondisi sederhana adalah variabel Boolean atau suatu persamaan hubungan, dapat didahului dengan satu operator NOT (“­­¬”).  Persamaan relasional mengambil bentuk : E1 (Operator-relasional) E2

Dimana E1 dan E2 merupakan persamaan aritmatika dan (operator relasional) adalah salah satu dari operator berikut ini : “<”, “≤”, “=”, “≠”, (“­­¬ =”) (pertidaksamaam), “>” atau “≥”.              Kondisi gabungan terdiri dari dua atau lebih kondisi sederhana, operator Boolean dan tanda kurung.  Diasumsikan nahwa operator Boolean yang diijinkan dalam suatu kondisi gabungan meliputi OR (“|”), AND (“&”) dan NOT (“­­¬”).  Kondisi tanpa persamaan relasional disebut persamaan Boolean.

Dengan demikian, tipe-tipe komponen yang mungkin di dalam suatu kondisi meliputi operator Boolean, sebuah variabel Boolean, sepasang tanda kurung Noolean (yang mengelilingi suatu kondisi gabungan atau sederhana), sebuah operator relasional atau sebuah persamaan aritmatika.

Bila suatu kondisi tidak benar, maka paling tidak satu komponen dari kondisi itu salah.  Dengan demikian, tipe kesalahan pada suatu kondisi meliputi berikut ini :

·           Kesalahan operator Boolean (adanya operator Boolean yang salah / hilang / ekstra)

·           Kesalahan variabel Boolean

·           Kesalahan tanda kurung Boolean

·           Kesalahan operator relasional

·           Kesalahan  persamaan aritmatika

Metode pengujian kondisi berfokus pada pengujian masing-masing kondisi di dalam program.  Strategi pengujian kondisi biasanya memiliki dua keuntungan :

13.    Pengukuran kupasan pengujian dari suatu kondisi adalah sederhana

14.    Cakupan pengujian terhadap kondisi di dalam suatu program memberikan pedoman untuk melakukan pengujian tambahan untuk program tersebut.

Tujuan pengujian kondisi adalah mendeteksi tidak hanya kesalahan di dalam kondisi program, tetapi juga kesalahan lain pada program.  Jika pengujian ditentukan untuk program P efektif untuk mendeteksi kesalahan pada kondisi yang ada pada P, maka kemungkinan besar pengujian itu juga efektif untuk mendeteksi kesalahan lain pada P.  sebagai tambahan, jika strategi efektif untuk mendeteksi kesalahan-kesalahan pada suatu kondisi maka kemungkinan besar strategi tersebut juga efektif untuk mendeteksi kesalahan pada suatu program.

Sejumlah strategi pengujian kondisitelah diusulkan.  Pengujian cabang mungkin merupakan strategi pengujian kondisi yang paling sederhana.  Untuksuatu kondisi gabungan C, cabang-cabang tru dan false dari C dan setiap kondisi sederhana pada C perlu dieksekusi paling tidak satu kai.

Pengujian domain membutuhkan tiga atau empat pengujian untuk dilakukan untuksebuah persamaan rasional karena persamaan relasional mengambil bentuk : E1 (Operator relasional) E2 maka diperlikan tiga pengujian untuk membuat nilai E1 lebih tinggi daripada, sama dengan atau kurang dari nilai E2 secara berurutan.  Bila (operator relasional) salah dan E1 dan E2 benar. Maka ketiga pengujian itu menjamin pendeteksian kesalahan operator relasional.  Untuk mendeteksi kesalahan pada E1 dan E2, maka tes yang membuat harga E1 lebih besar atau kurang dari harga E2 harus membuat perbedaan antara dua harga itu menjadi sekecil mungkin.

Untuk persamaan Boolean dengan n variabel, semua 2ⁿ pengujian yang mungkin ( n > 0) perlu dilakukan.  Strategi itu dapat mendeteksi operator, variabel dan kesalahan tanda kurung Boolean tetapi hanya praktis jika n kecil.

Pengujian error-sensitive untuk persamaan Boolean dapat juga dilakukan.  Untuk persamaan Boolean tunggal (persamaan Boolean masing-masing variabel Boolean terjadi hanya sekali) dengan n variabel Boolean (n > 0), kita dapat dengan mudah memunculkan serangkaian pengujian dengan kurang dari 2ⁿ pengujian sehingga rangkaian pengujian itu menjamin pendeteksian kesalahan operator Boolean bertingkat secara efektif untuk mendeteksi kesalahan-kesalahan yang lain.

Tai dalam pressman (1997;547) mengusulkan strategi pengujian kondisi yang didasarkan atas teknik yang sidah diuraikan.  Disebut pengujian BRO (Branch and Relational Operator), teknik tersebut menjamin pendeteksian kesalahan cabang dan operator relasional dengan kondisi bahwa semua variabel Boolean dan operator relasional pada kondisi itu terjadi hanya sekali dan tidak memiliki variabel umum.

Strategi BRO menggunakan batasan kondisi bagi suatu kondisi C.  batasan kondisi untuk C dengan n kondisi sederhana ditentukan sebagai (D₁, D₂, …, D_n), dimana D_i (0 < i  ≤ n) merupakan simbol yang menentukan batasan pada hasil akhir dari kondisi sederhana ke-i dalam kondisi C.  batasan kondisi D untuk kondisi C dikatakan dipenuhi oleh eksekusi dari C bila selama eksekusi dari C, hasil akhir dari masing-masing kondisi sederhana di dalam C memenuhi batasan yang bersesuaian di dalam D.

Untuk variabel Boolean, B, kita menentukan batasan pada hasil akhir B yang menyatakan bahwa B harus true (t) atau false (f) dengan cara yang sama, untuk suatu persamaan relasional, simbol-simbol >, = dan < digunakan untuk menentukan batasan pada hasil akhir persamaan.               

Sebagai contoh, perhatikan kondisi bentuk C2 : B1 & (E3 = E4), dimana B1 adalah persamaan Boolean dan E3 dan E4 adalah persamaan aritmatika.  Batasan kondisi untuk C2 adalah bentuk (D1, D2), dimana D1 adalah “t” atau “f” dan D2 adalah >, = atau < karena C2 sama seperti C1 kecuali bahwa kondisi sederhana kedua di dalam C2 adalah persamaan relasional, kita dapat membangun himpunan batasan untuk C2 dengan memodifikasi himpunan pembatas [(t, t), (f, t), (t, f)] yang ditentukan untuk C1.  Perhatikan bahwa “t” untuk (E3 = E4) mengimplikasikan “=” dan bahwa “f” untuk (E3 = E4) mengimplikasikan “<” atau “>”.  Dengan menggantikan (t, t) dengan (t, =) dan (f, t) dengan (f, =) dan dengan menggantikan (t, f) dengan (t, <) \< >) dan (t, >) maka hasil himpunan batasan untuk C2 adalah {(t, =), (t, <), (t, >).  Cakupan himpunan batasan tersebut akan menjamin pendeteksian Boolean dan kesalahan-kesalahan operator relasional pada C2.

Sebagai contoh ketiga, perhatikan kondisi bentuk : C3 : (E1 > E2) & (E3 =E4), di mana E1, E2, E3 dan E4 adalah persamaan aritmatika. Pembatas kondisi untuk C3 adalah bentuk (D1, D2), di mana masing-masing dari D1 dan D2 adalah >, = atau <, karena C3 sama seperti C2 kecuali bahwa kondisi sederhana yang pertama pada C3 adalah persamaan relasional, maka kita dapat membangun himpunan batasan untuk C3 dengan memodifikasi himpunan batasan untuk C2 dan akan diperoleh : {(>, =), (=, =), (<, =), (>, >), (>, <)} cakupan dari himpunan batasan tersebut akan menjamin pendeteksian kesalahan operator relasional pada C3.

Pengujian Aliran Data

Metode pengujian aliran data memilih jalur pengujian dari suatu program sesuai dengan lokasi definisi dan menggunakan variabel-variabel pada program.  Sejumlah pengujian aliran data telah dipelajari dan dibandingkan.

Untuk menggambarkan pendekatan pengujian aliran data, diasumsikan bahwa masing-masing statemen pada suatu program diberi nomor statemen yang unik dan setiap fungsi tidak memodifikasi parameter atau variabel globalnya.  Untuk statemen dengan S sebagai nomor statemennya.

DEF(S) = {X | statemen S berisi sebuah definisi dari X}

USE(S) = {X | statemen S berisi suatu penggunaan dari X}

Bila statemen S adalah statemen if atau loop, maka himpunan DEF-nya kosong dan himpunan Use-nya didasarkan pada kondisi statemen S.  Definisi variabel X pada statemen S dinyatakan hidup pada statemen S’ jika ada suatu jalur dari statemen S ke statemen S’ yang tidak berisi definisi yang lain dari X.

Rantai definition-use (atau rantai DU) dari variabel X berbentuk [X, S, S’], di mana S dan S’ adalah nomor statemen, X pada DEF(S) dan USE(S’) dan definisi X pada statemen S hidup pada statemen S’.

Strategi pengujian aliran data sederhana adalah untuk mengharuskan agar setiap rantai DU dicakup paling tidak satu kali.  Strategi ini disebut strategi pengujian DU.  Telah diperlihatkan bahwa pengujian DU tidak menjamin pencakupan semua cabang sebuah program.  Akan tetapi, satu cabang tidak dijamin dicakup oleh pengujian DU hanya pada situai jarang seperti konstruksi if-then-else di mana bagian then tidak memiliki definisi mengenai sembarang variabel dan bagian else tidak ada.  Dalam situasi seperti itu, cabang else dari statemen if tersebut tidak perlu dicakup oleh pengujian DU.

Strategi pengujian aliran data berguna untuk memilih jalur pengujian dari satu program yang berisi statement if dan loop yang tersarang.  

Untuk membuat strategi pengujian DU memilih jalur pengujian dari diagram aliran kontrol, kita perlu tahu definisi dari penggunaan masing-masing kondisi atau blok pada PDL.  Anggap bahwa variabel X didefinisikan pada statemen terakhir dari blok B1, B2, B3, B4 dan B5 dan digunakan dalam statemen pertama dari blok B2, B3, B4, B5 dan B6.  Strategi pengujian DU memerlukan eksekusi jalur terpendek dari masing-masing dari Bi, 0 < i ≤ 5, ke masing-masing dari Bj,                       1 < j ≤ 6.   (Pengujian semacam itu juga mencakup banyak penggunaan variabel X dalam kondisi C1, C2, C3 dan C4).  Meskipun ada 25 rantai DU dari variabel X, kita hanya membutuhkan lima jalur untuk mencakup rantai-rantai DU tersebut. Alasannya adalah diperlukan lima jalur untuk mencakuprantai-rantai DU X dari Bi, 0 < i ≤ 5, ke B6 dan rantai DU yang lain dapat dicakup dengan membuat lima jalut tersebut berisi iterasi dari loop.

Perhatikan bahwa bila kita mengaplikasikan strategi pengujian cabang untuk memilih jalur pengujian dari PDL tersebut di atas, kita tidak memerlukan informasi tambahan. Untuk memilih jalur dari diagram pengujian BRO, kita perlu tahu struktur masing-masing kondisi atau blok (setelah pemilihan suatu jalur dari suatu program, kita harus menentukan apakah jalur tersebut mungkin dikerjakan dengan mudah untuk program itu; misalnya apakah ada paling tidak satu input yang menggunakan jalur tersebut).

Karena statemen pada suatu program berhubungan satu dengan yang lainnya sesuai dengan definisi dan penggunaan variabel, maka pendekatan aliran data efektif untuk perlindungan dan kesalahan.  Tetapi, masalah cakupan pengujian pengukuran dan pemilihan jalur pengujian untuk pengujian aliran data lebih sulit daripada masalah yang berhubungan dengan pengujian kondisi.

Pengujian Loop

Loop adalah batu pertama untuk mayoritas algoritma yang diimplementasikan pada perangkat lunak.  Seringkali sedikit saja perhatian yang kita berikan pada loop, sementara melakukan pengujian perangkat lunak.

Pengujian loop merupakan teknik pengujian white-box yang secara ekslusif berfokus pada validitas konstruksi loop.  Empat kelas loop yang berbeda dapat didefinisikan, yaitu loop sederhana, loop terangkai, loop tersarang dan loop tidak terstruktur terlihat pada gambar 9.

Loop Sederhana

Himpunan pengujian berikut harus diaplikasikan pada loop sederhana, di mana n adalah jumlah maksimum yang diijinkan melewati loop tersebut.

1.        Abaikan keseluruhan loop

2.        Hanya satu yang melewati loop

3.        Dua yang melewati loop

4.        m melewati loop di mana m < n

5.        n-1, n, n+1melewati loop

Loop tersarang

Bila kita ingin memperluas pendekatan pengujian bagi loop sederhana ke loop tersarang.  Jumlah pengujian mungkin akan berkembang secara geometris sesuai tingkatan pertambahan persarangan sehingga sejumlah pengujian menjadi tidak praktis.  Beizer dalam pressman (2002;551) mengusulkan suatu pendekatan yang membantu mengurangi jumlah pengujian :

1.        mulai pada loop yang paling dalam.  Atur semua loop ke nilai minimum.

2.        Lakukan pengujian loop sederhana untuk loop yang paling dalam sementara menjaga loop yang paling luar pada nilai parameter iterasi minimumnya (misalnya, pencacah loop).  Tambahkan pengujian yang lain untuk nilai out-of-range atau nilai yang tidak diperbolehkan

3.        Bekerja menuju ke luar, dengan melakukan pengujian untuk loop selanjutnya, tetapi menjaga semua loop bagian luar yang lain pada nilai minimumnya dan loop tersarang lainnya pada harga “tertentu”.

4.        Lanjutkan sampai semua loop telah bersarang.

Loop Terangkai.

Loop terangkai dapat diuji dengan menggunakan pendekatan yang ditentukan untuk loop sederhana bila masing-masing dari loop itu independen terhadap yang lain.  Tetapi bila dua loop dirangkai dan pencacah loop untuk loop 1 digunakan sebagai harga awal untuk loop 2, kemudian loop tersebut menjadi tidak independen, maka pendekatan yang diaplikasikan ke loop tersarang direkomendasikan.

Loop tidak terstruktur

Kapan saja memungkinkan kelas loop ini harus didesain lagi untuk mencerminkan penggunaan konsepsi pemograman terstruktur.

2.6. PENGUJIAN BLACK-BOX

Pengujian Black-box berfokus pada persyaratan fungsional perangkat lunak.  Dengan demikian, pengujian black-box memungkinkan perekayasa perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnyamenggunakan semua persyaratan fungsional untuk suatu program.  Pengujian black-box bukan merupakan alternatif dari teknik white-box, tetapi merupakan pendekatan komplementer yang kemungkinan besar mampu mengungkap kelas kesalahan daripada metode white-box.

Pengujian black-box berusaha menemukan kesalahan dalam kategori sebagai berikut :

15.    Fungsi-fungsi yang tidak benar atau hilang

16.    Kesalahan interface

17.    Kesalahan dalam struktur data atau akses database eksternal

18.    Kesalahan kinerja

19.    Inisialisasi dan kesalahan terminasi

Tidak seperti pengujian white-box yang dilakukan pada saat awal proses pengujian, pengujian black-box cenderung diaplikasikan selama tahap akhir pengujian.  Karena pengujian balck-box memperhatikan struktur kontrol maka perhatian berfokus pada domain informasi.  Pengujian didesain untuk menjawab pertanyaan-pertanyaan berikut :

·           Bagaimana validitas fungsional diuji?

·           Kelas input apa yang akan membuat test case menjadi baik?

·           Apakah sistem sangat sensitif terhadap harga input tertentu?

·           Bagaimana batasan dari suatu data diisolasi?

·           Kecepatan data apa dan volume data apa yang dapat ditolerir oleh sistem?

·           Apa pengaruh kombinasi tertentu dari data terhadap operasi sistem

Dengan mengaplikasikan teknik black-box, maka kita menarik serangkaian test case yang memenuhi kriteria berikut :

1.        Test case yang mengurangi dengan harga lebih dari satu, jumlah test case tambahan yang harus didesain untuk mencapai pengujian yang dapat dipertanggung jawabkan

2.        Test case yang memberitahu kita sesuatu mengenai kehadiran atau ketidak hadiran kelas kesalahan dari pada memberitahu kesalahan yang berhubungan hanya dengan pengujian spesifik yang ada.

Metode Pengujian Graph-Based

Langkah pertama pada pengujian black-box (pengujian behaviour atau pengujian partisi) adalah memahami objek yang dimodel di dalam perangkat lunak dan hubungan yang akan menghubungkan objek tersebut.  Setelah itu dilakukan, maka langkah selanjutnya adalah menentukan sederetan pengujian yang membuktikan bahwa “semua objek memiliki hubungan yang diharapkan satu dengan yang lainnya”.  Dengan kata lain, pengujian perangkat lunak dimulai dengan membuat grafik dari objek-objek yang penting dan hubungan objek-objek serta kemudian memikirkan sederatan pengujian yang mencakup grafik tersebut sehingga masing-masing objek dan hubungan digunakan dan kesalahan ditemukan.  Untuk melakukan langkah tersebut, perekayasa perangkat lunak memulainya dengan membuat suatu grafik – sekumpulan simpul yang mempresentasikan objek; link yang mempresentasikan hubungan antar objek; node weight yang menggambarkan properti dari suatu simpul (misalnya, nilai data tertentu atau tingkah laku keadaan dan links weight yang menggambarkan beberapa karakteristik suatu link.

Representasi simbolik dari grafik diperlihatkan pada gambar 10a. simpul-simpul dipresentasikan sebagai lingkaran yang dihubungkan oleh link yang memakai sejumlah bentuk yang berbeda.  Link terarah (direpresentasikan oleh sebuah anak panah) yang menunjukan bahwa hubungan bergerak hanya dalam satu arah.  Link dua arah yang disebut juga link simetris, mengimplikasikan bahwa hubungan tersebut berlaku dalam dua arah.  Link paralel digunakan pada saat sejumlah hubungan yang berbeda dibangun di antara simpul-simpul grafik.

Sebagai contoh sederhana perhatikan bagiandari suatu grafik untuk aplikasi pengolahan kata gambar 10b. di bawah ini :

Gambar 10. (a) Notasi Grafik  (b) Contoh Sederhana

Objek #1 = New file menu select

Objek #2 = document window

Objek #3 = document text

Seperti dilihatkan pada gambar, pemilihan menu New File menghasilkan Document Window.  Node weight dari Document Window memberikan daftar atribut window tersebut yang akan diharapkanpada saat window dimunculkan.  Link weight menunjukkan bahwa window harus dimunculkan dalam kurang dari 1,0 detik.  Link tak terarah membangun hubungan simetris di antara New File Select Menu dan Text Document dan link paralel menunjukkan hubungan antara Document Window dan Document Text.

Kenyataannya grafik yang jauh lebih lebih detail harus dimunculkan sebagai pendahuluan ke desain test case.  Perekayasa perangkat lunak kemudian melakukan test case dengan melewatkan grafik tersebut dan mencakup masing-masing dari hubungan yang diperlihatkan. Test case itu didesain untuk menemukan kesalahan pada berbegai hubungan.

Beizer dalam pressman (2002; 554) menggambarkan sejumlah metode pengujian behavioral yang dapat menggunakan grafik :

1.        Pemodelan Aliran Transaksi

Simpul-simpul mempresentasikan langkah-langkah pada beberapa transaksi (misalnya, langkah yang diperlukan untuk membuat reservasi pesawat dengan menggunakan layanan on-line) dan link mempresentasikan hubungan logis di antara langkah-langkah (misalnya, flight.information.input diikuti oleh validation/availibility-processing).  Diagram aliran data dapat digunakan untk membantu menciptakan grafik tipe ini.

2.        Pemodelan Keadaan Terbatas

Simpul-simpul mempresentasikan keadaan perangkat lunak yang dapat diamati oleh pemakai yang berbeda (misalnya, masing-masing “layar” muncul sebagai sebuah juru tulis entri order yang mengambil urutan telepon) dan link mempresentasikan transisi yang terjadi untuk bergerak dari satu keadaan ke keadaan lainnya (misalnya, order-information diperiksa selama inventory-availibility-look-up diikuti dengan customer-billing-information-input).  Diagram transisi keadaan dapat digunakan untuk membantu membuat grapik tipe ini.

3.        Pemodelan Aliran Data

Simpul-simpul merupakan objek data, sementara link adalah transformasi yang terjadi untuk menerjemahkan satu objek data ke objek data yang lain.  Contoh, simpul FICA.tax.withheld (FTW) dihitung dari Gross.Wages (GW) dengan menggunakan hubungan FTW = 0,062 X GW.

4.        Pemodelan Timing

Simpul-simpul mempresentasikan objek program dan link adalah hubungan sekuensial antara objek-objek tersebut.  Link weight digunakan untuk menentukan waktu eksekusi yang dibutuhkan pada saat program mengeksekusi.

Pengujian graph-base dimulai dengan definisi semua simpul dan node weight, objek dan atribut diidentifikasi.  Model data dapat digunakan sebagai titik awal, tetapi penting untuk dicatat bahwa banyak simpul dapat merupakan objek program (tidak secara eksplisit dipresentasikandalam model data).  Untuk memberikan indikasi dari titik mulai dan berhenti untuk grafik tersebut berguna sekali bila simpul masuk dan keluarnya ditentukan.

Sekali simpul diidentifikasi maka link dan link weight harus dibangun.  Secara umum, link harus diberi nama, meskipun link yang mempresentasikan aliran kontrol di antara objek program tidak perlu diberi nama.

Dalam banyak kasus, model grafik dapat memiliki loop (yaitu, jalur melalui grafik, satu simpul atau lebih ditemui lebih dari satu kali).  Pengujian loop juga dapat diaplikasikan pada tingkat tingkah laku (black-box).  Grafik tersebut akan membantu mengidentifikasi loop-loop yang memerlukan pengujian tersebut.

Masing-masing hubungan dipelajari secara terpisah sehingga test case dapat dilakukan.  Transitivitas hubungan sekuensial dipelajari untuk menentukan bagaimana pengaruh hubungan tersebut menyebar pada objek yang ditentukan pada suatu grafik.  Transitivitas dapat digambarkan dengan memperhatikan tiga objek X, Y dan Z.  perhatikan hubungan berikut ini :

X diperlukan untuk menghitung Y

Y diperlukan untuk menghitung Z

Sehingga dibangun hubungan transitif antara X dan Z :

X diperlukan untuk menghitung Z

Berdasarkan hubungan transitif ini, pengujian untuk menemukan kesalahan dalam perhitungan Z harus mempertimbangkan berbagai harga untuk X maupun Y.

Simetri hubungan (link grafik) juga merupakan panduan penting ke desain test case.  Bila suatu link benar-benar dua arah (simetris), maka penting untuk menguji fitur tersebut.  Fitur UNDO pada berbagai aplikasi personal komputer mengimplementasikan simetri yang terbatas, yaitu bahwa UNDO mengijinkan suatu aksi dihapuskan setelah aksi itu diselesaikan.  Hal itu harus diuji secara mendalam dan semua perkecualian (yakni tempat UNDO tidak dapat digunakan) harus dicatat. Akhirnya, setiap simpul pada grafik harus memiliki hubungan yang mengarahkepada dirinya sendiri; pada dasarnya adalah loop “no action” atau “action null”.  Hubungan refleksif itu juga harus diuji.

Pada saat desain test case dimulai, maka sasaran pertamanya adalah mencapai cakupan simpul (node coverage). Ini berarti bahwa pengujian harus didesain untuk memperlihatkan bahwa tidak ada simpul yang dengan sembrono diabaikan dan bahwa node weight (atribut objek) adalah benar.

Selanjutnya, menekankan cakupan link. Masing-masing hubungan diuji berdasarkan propertinya.  Misalnya, hubungan simetri diuji untuk memperlihatkan bahwa pada pada dasarnya hubungan itu memiliki dua arah.  Hubungan transitif diuji untuk memperlihatkan bahwa ada transitivitas.  Hubungan refleksif diuji untuk memastikan bahwa loop null ada.  Bula link weight telah ditentukan, pengujian dilakukan untuk menunjukkan bahwa weight itu valid.  Akhirnya, pengujian loop dipanggil.

Partisi Ekivalensi

Partisi ekivalensi adalah metode pengujian black-box yang membagi domain input dari suatu program ke dalam kelas data, test case dapat dilakukan.  Test case yang ideal mengungkap kelas kesalahan (misalnya, pemrosesan yang tidak benar terhadap semua data karakter) yang akan memerlukan banyak kasus untuk dieksekusi sebelum kesalahan umum diamati.  Partisi ekivalensi berusaha menentukan sebuah test case yang mengungkap kelas-kelas kesalahan sehingga mengurangi jumlah total test case yang harus dikembangkan.

Desain test case untuk partisi ekivalensi didasarkan pada evaluasi terhadap kelas ekivalensi untuk suatu kondisi input.  Dengan menggunakan konsep yang telah dijelaskan pada bagian sebelumnya, bila serangkaian objek dapat di-link oleh hubungan yang simetris, transitif dan refleksif, maka ada kelas ekivalensi.  Kelas ekivalensi mempresentasikan serangkaian keadaan valid atau invalid untuk kondisi input.  Secara khusus, suatu kondisi input dapat berupa harga numeris, suatu rentang harga atau serangkaian harga terkait atau sebuah kondisi Boolean.  Kelas ekivalensi dapat ditentukan sesuai pedoman berikut ini :

1.        Bila kondisi input menentukan suatu range, maka satu kelas ekivalensi valid dan dua yang invalid ditentukan

2.        Bila suatu kondisi input membutuhkan suatu harga khusus, maka satu kelas ekivalensi valid dan dua yang invalid ditentukan

3.        Bila suatu kondisi menentukan anggota suatu himpunan, maka satu kelas ekivalensi valid atau dua yang invalid ditentukan

4.        Bila suatu kondisi input adalah Boolean, maka satu kelas valid dan satu yang invalid ditentukan.

Sebagai contoh, perhatikan data yang dijaga sebagai bagian dari suatu aplikasi perbankan otomatis.  Pemakai dapat “menghubungi” bank tersebut dengan menggunakan komputer personalnya, sebuah password enam digit dan diikuti dengan serangkaian perintah kata kunci yang memicu berbagai fungsi perbankan.  Perangkat lunak yang dipasok untuk aplikasi perbankan menerima data dalam bentuk :

Kode area	Kosong atau tiga nomor digit
Prefik	Tiga nomor digittidak mulai dengan 1 atau 0
Sufik	Empat nomor digit
Password	Enam nilai alphanumerik digit
perintah	“cek”, “deposit”, “bayar pajak” dan sebagainya

Kondisi input yang sesuai dengan masing-masing elemen data untuk aplikasi perbankan dapat ditentukan sebagai :

Kode area	:	Kondisi input, Boolean – kode area mungkin atau mungkin tidak ada kondisi Input, range – nilai yang ditentukan antara 200 dan 999, dengan pengecualian khuhus
Prefik	:	Kondisi input, range – harga yang ditetapkan > 200 dengan tanpa digit 0
Sufik	:	Kondisi input, harga – panjang empat digit
Password	:	Kondisi input, Boolean – password dapat ada atau tidak ada Kondisi input, harga – antrian enam karakter
perintah	:	Kondisi input, himpunan – berisi perintah yang sudah ditulis di atas

Dengan mengaplikasikan pedoman untuk derivasi kelas ekivalensi, test case untuk masing-masing item data domain input dapat dikembangkan dan dieksekusi.  Test case dipilih sehingga jumlah atribut yang terbesar dari suatu kelas ekivalensi digunakan saat itu juga.

Analisis Nilai Batas

Karena alasan yang tidak sangat tidak jelas, jumlah kesalahan yang lebih besarcenderung terjadi pada batas domain imput daripada di “pusat”.  Karena itulah analisis nilai batas / boundary value analysis (BVA) telah  dikembangkan sebagai teknik pengujian.  Analisis nilai batas memunculkan pemilihan test case yang menggunakan nilai batas.

Analisis nilai batas adalah teknik desain proses yang melengkapi partisi ekivalensi.  Daripada memilih sembarang elemen kelas ekivalensi, BVA lebih mengarah kepada pemilihan test case pada “edge” dari kelas.  Daripada hanya berfokus pada kondisi input, BVA melakukan test case dari domain output.

Dalam banyak hal, pedoman untuk BVA sama dengan yang diberikan untuk partisi ekivalensi adalah :

1.        Nila suatu kondisi input mengkhususkan suatu range dibatasi oleh nilai a dan b, maka test case harus didesain dengan nilai a dan b, persis di atas dan di bawah a dan b, secara bersesuaian

2.        Bila suatu kondisi input mengkhususkan sejumlah nilai, maka test case harus dikembangkan dengan menggunakan jumlah minimum dan maksimum.  Nilai tepat di atas dan di bawah minimum dan maksimum juga diuji

3.        Pedoman 1 dan 2 diaplikasikan ke kondisi output.  Contohnya, dianggap bahwa suhu vs. tabel tekanan diperlukan sebagai output dari program analisis rekayasa. Test case harus didesain untuk menciptakan laporan output yang menghasilkan jumlah minimum (dan maksimum) entri tabel yang diijinkan

4.        Bila struktur data program telah memesan batasan (misalnya, suatu array memiliki suatu batas yang ditentukan dari 100 entri), pastikan untuk mendesain test case yang menggunakan struktur data pada batasannya.

Sebagian besar perekayasa perangkat lunak secara intuitif melakukan BVA sampai beberapa tingkatan.  Dengan mengaplikasikan pedoman tersebut, pengujian batasan akan lebih lengkap sehingga kemungkinan untuk berhasil mendeteksi kesalahan menjadi lebih besar.

Pengujian Perbandingan

 Adanya banyak situasi (seperti avionik pesawat terbang, kontrol sumber tenaga nuklir), reliabilitas perangkat lunaknya sangat kritis.  Dalam aplikasi semacam itu, perangkat lunak dan perangkat keras redundan sering digunakan untuk meminimalkan kemungkinan kesalahan.  Pada saat perangkat lunak redundan dikembangkan, tim rekayasa perangkat lunak yang terpisah mengembangkan versi-versi independen dari suatu aplikasi dengan menggunakan spesifikasi yang sama. Dalam situasis semacam itu, setiap versi dapat diuji dengan data uji yang sama untuk memastikan bahwa semua versi memberikan output yang identik.  Kemudian semua versi dieksekusi secara paralel dengan perbandingan real time hasil untuk memastikan konsistensi.

Dengan pelajaran mengenai sistem redundan, para peneliti (misalnya, mengusulkan agar versi perangkat lunak independen dikembangkan bagi aplikasi kritis, bahkan bila hanya sebuah versi tunggal saja yang akan digunakan pada sistem berbasis komputer yang disampaikan.  Versi independen membentuk basis teknik pengujian balck-box yang disebut pengujian perbandingan atau pengujian back-to-back.

Bila implementasi bertingkat dari spesifikasi yang sama telah dihasilkan, maka test case yang didesain dengan menggunakan teknik black-box yang lain (misalnya partisi ekivalensi) diberikan sebagai input untuk masing-masing versi perangkat lunak tersebut.  Bila output dari masing-masing versi sama, maka diasumsikan bahwa implementasinya benar.  Bila outputnya berbeda, maka masing-masing dari aplikasi itu diperiksa untuk menentukan cacat pada suatu versi atau perbedaan itu dapat lebih jelas.  Pada sebagian besar kasus, perbandingan output dapat dilakukan dengan suatu piranti yang diotomatisasi.

Pengujian perbandingan tidaklah mudah.  Bila spesifikasi dari semua fungsi telah dikembangkan mengandung kesalahan, maka semua versi kemungkinan besar merefleksikan kesalahan.  Lagi pula, jika masing-masing versi independen identik tetapi tidak benar, maka pengujian kondisi akan gagal mendeteksi kesalahan.

2.7. PENGUJIAN UNTUK APLIKASI DAN LINGKUNGAN KHUSUS

Pada saat perangkat lunak komputer menjadi semakin kompleks, maka kebutuhan akan pendekatan pengujian yang khusus juga semakin berkembang.  Metode pengujian black-box dan white-box dapat diaplikasikan pada semua lingkungan, arsitektur dan aplikasi, tetapi kadang-kadang dalam pengujian diperlukan pedoman dan pendekatan yang unik.  Pedoman pengujian bagi lingkungan, arsitektur dan aplikasi khusus yang umumnya diketahui oleh para perekayasa perangkat lunak.

Pengujian GUI

Graphical User Interfaces (GUIs) menyajikan tantangan yang menarik bagi para perekayasa.  Karena komponen reusable berfungsi sebagai bagian dari lingkungan pengembangan GUI, pembuatan interface pemakai telah menjadi hemat waktu dan lebih teliti.  Pada saat yang sama, kompleksitas GUI telah berkembang, menimbulkan kesulitan yang lebih besar di dalam desain dan eksekusi test case.

Karena GUI modern memiliki bentuk dan cita rasa yang sama, maka dapat dilakukan sederetan pengujian standar.  Pertanyaan berikut dapat berfungsi sebagai panduan untuk serangkaian pengujian generik untuk GUI adalah :

Untuk Windows :

·           Apakah window akan membuka secara tepat berdasarkan tipe yang sesuai atau perintah berbasis menu?

·           Dapatkah window di-resize, digerakkan atau digulung?

·           Apakah semua isi data yang diisikan pada window dapat dituju dengan tepat dengan sebuah mause, function keys, anak panah penunjuk dan keyboard?

·           Apakah window dengan cepat muncul kembali bila dia ditindih dan kemudian dipanggil lahi?

·           Apakah semua fungsi yang berhubungan dengan window dapat diperoleh bila diperlukan?

·           Apakah semua fungsi yang berhubungan dengan window operasional?

·           Apakah semua menu pull-down, toolbar, scrollbar, kotak dialog, tombol, ikon dan control yang lain dapat diperoleh dan dengan tepat ditampilkan untuk window tersebut?

·           Pada saat window bertingkat ditampilkan, apakah nama window tersebut direpresentasikan secara tepat?

·           Apakah window yang aktif disorot secara tepat?

·           Bila multitasking digunakan, apakah semua window diperbaharui pada waktu yang sesuai?

·           Apakah pemilihan mouse bertingkat atau tidak benar di dalam window menyebabkan efek samping yang tidak diharapkan?

·           Apakah audio prompt dan atau color prompt ada di dalam window atau sebagai konsekuensi dari operasi window disajikan menurut spesifikasi?

·           Apakah window akan menutup secara tepat?

Untuk menu pull-down dan operasi mouse :

·           Apakah menu bar yang sesuai ditampilkan di dalam konteks yang sesuai?

·           Apakah menu bar aplikasi menampilkan fitur-fitur yang terkait dengan sistem (misalnya tampilan jam)?

·           Apakah operasi menu pull-down bekerja secara tepat?

·           Apakah menu breakway, pallete dan toolbar bekerja secara tepat?

·           Pakah semua fungsi menu dan subfungsi pull-down didaftar secara tepat?

·           Apakah semua fungsi menu dapat dituju secara tepat oleh mouse?

·           Apakah typeface, ukuran dan format teks benar?

·           Memungkinkah memanggil masing-masing fungsi menu dengan menggunakan perintah berbasis teks alternatif?

·           Apakah fungsi menu disorot (atau dibuat kelabu) berdasarkan konteks operasi yang sedang berlangsung di dalam suatu window?

·           Apakah semua menu function bekerja seperti diiklankan?

·           Apakah nama-nama menu function bersifat self-explanatory?

·           Apakah help dapat diperoleh untuk masing-masing item menu, apakah dia sensitif terhadap konteks?

·           Apakah operasi mouse dikenali dengan baik pada seluruh konteks interaktif?

·           Bila klik ganda diperlukan, apakah operasi dikenali di dalam konteks?

·           Jika mouse mempunyai tombol ganda, apakah tombol itu dikenali sesuai konteks?

·           Apakah kursor, indikator pemrosesan (misalnya, sebuah jam atau hour glass), dan pointer secara tepat berubah pada saat operasi yang berbeda dipanggil?

Entri data :

·           Apakah entri data alphanumerik dipantulkan dan diinput ke sistem?

·           Apakah mode grafik dari entri data (seperti slidebar) bekerja dengan baik?

·           Apakah data invalid dikenali dengan baik?

·           Apakah pesan input data sangat pintar?

Sebagai tambahan untuk pedoman tersebut, grafik pemodelan keadaan yang terbatas dapat digunakan untuk melakukan sederetan pengujian yang menekankan objek program dan data spesifik yang relevan dengan GUI.

Karena sejumlah besar permutasi yang bersesuaian dengan operasi GUI, maka pengujian harus didekati dengan menggunakan piranti otomatis.  Sudah ada banyak piranti pengujian GUI yang muncul di pasar selama beberapa tahun terakhir.

Pengujian Arsitektur Client / Server

Arsitektur client/server (C/S) (misalnya, menghadirkan tantangan yang berarti bagi para penguji perangkat lunak.  Sifat terdistribusi dari lingkungan C/S, masalah kinerja yang berhubungan dengan pemrosesan transaksi, kehadiran potensial dari sejumlah platform perangkat keras yang berbeda, kompleksitas komunikasi jaringan, kebutuhan akan layanan client multiple dari suatu database terpusat (atau dalam beberapa kasus, terdistribusi) dan persyaratan koordinasi yang dibebankan pada server, semua secara bersama-sama membuat pengujian terhadap arsitektur C/S dan perangkat lunak yang ada didalamnya menjadi jauh lebih sulit daripada pengujian aplikasi yang berdiri sendiri.  Kenyataannya, studi industri yang terakhir menunjukkan pertambahan berarti di dalam waktu pengujian dan biaya ketika lingkungan C/S dikembangkan.

Pengujian Dokumentasi dan Fasilitas Help

Istilah “pengujian perangkat lunak” memunculkan citra terhadap sejumlah besar test case yang disiapkan untuk menggunakan program komputer dan data yang dimanipulasi oleh program.  Dengan melihat kembali definisi perangkat lunak, penting dicatat bahwa pengujian harus berkembang ke elemen ketiga dari konfigurasi perangkat lunak – dokumentasi.

Kesalahan dalam dokumentasi dapat menghancurkan penerimaan program seperti halnya kesalahan pada data atau kode sumber.  Tidak ada yang lebih membuat frustasi dibandingkan mengikuti tuntutan pemakai secara tepat dan mendapatkan hasil atau tingkah laku yang tidak sesuai dengan yang diprediksi oleh dokumen.  Karena itulah pengujian dokumentasi harus menjadi suatu bagian yang berarti dari setiap rencana pengujian perangkat lunak.

Pengujian dokumentasi dapat didekati dalam dua fase adalah :

20.    Kajian teknis formal, yang menguji kejelasan editorial dokumen

21.    Live test, menggunakan dokumentasi dalam kaitannya dengan penggunaan program aktual

Mengejutkan bahwa live test untuk dokumentasi dapat didekati dengan menggunakan teknik yang analog dengan berbagai metode pengujian black-box.  Pengujian graph-based dapat digunakan untuk menggambarkan penggunaan program tersebut.  Partisi ekivalensi dan analisis nilai batas dapat digunakan untuk menentukan berbagai kelas input dan interaksi yang sesuai.  Kegunaan program kemudian ditelusuri pada seluruh dokumen :

·           Apakah dokumen tersebut secara akurat menggambarkan bagaimana menyelesaikan masing-masing metode penggunaan?

·           Apakah deskripsi dari masing-masing urutan interaksi akurat?

·           Apakah contoh-contoh akurat?

·           Apakah terminologi, gambaran menu dan respon sistem konsisten dengan program aktual?

·           Apakah relatif mudah untuk menempatkan panduan di dalam dokumentasi?

·           Dapatkah trouble shooting dilakukan dengan mudah dengan dokumentasi?

·           Apakah tabel dolumen dari isi dan indeks akurat dan lengkap?

·           Apakah desain dolumen (layout, typeface, indentasi, grafik) kondusif untuk pemahaman dan asimilasi cepat terhadap informasi?

·           Apakah semua pesan kesalahan ditampilkan bagi pemakai dan digambarkan secara lebih detail di dalam dokumen?

·           Bila link hiperteks digunakan, apakah mereka akurat dan lengkap?

Satu-satunya cara yang dapat berjalan untuk menjawab pertanyaan-pertanyaan tersebut adalah dengan menggunakan bagian ketika yang independen (misalnya, pemakai yang diseleksi) yang menguji dokumentasi di dalam konteks kegunaan program.  Semua diskrepansi dicatat dan area ambiguitas atau kelemahan dokumen ditentukan untuk penulisan ulang yang potensial.

Pengujian Sistem Real-Time

Sifat asinkron dan tergantung waktu yang ada pada banyak aplikasi real-time.  Menambahkan elemen baru yang sulit dan potensial untuk bauran pengujian – waktu. Tidak hanya desainer test case yang harus mempertimbangkan test case black-box dan white-box, tetapi juga penanganan kejadian (yakni pemrosesan interupsi), timing data dan paralelisme tugas-tugas (proses) yang menangani data.  Pada banyak situasi, data pengujian yang diberikan pada saat sebuah sistem real-time ada dalam suatu keadaan akan menghasilkan pemrosesan yang baik, sementara data yang sama yang diberikan pada saat sistem berada dalam keadaan yang berbeda dapat menyebabkan kesalahan.

Contohnya, perangkat lunak real-time yang mengontrol alat foto-kopi yang baru menerima interupsi operator (yakni operator mesin menekan kunci kontrol seperti “reset” atau “darken”) dengan tanpa kesalahan pada saat mesin sedang membuat kopian ( di dalam keadaan “copying”).  Interupsi operator yang sama ini, bila diinputkan pada saat mesin ada dalam keadaan “jammed” akan menyebabkan sebuah kode diagnostik yang menunjukkan lokasi jam yang akan hilang (sebuah kesalahan).

Sebagai tambahan, hubungan erat yang ada di antara perangkat lunak real-time dan lingkungan perangkat kerasnya dapat juga menyebabkan masalah pengujian. Pengujian perangkat lunak harus mempertimbangkan pengaruh kegagalan perangkat keras pada pemrosesan perangkat lunak.  Kesalahan semacam itu dapat sangat sulit untuk bersimulasi secara realistis.

Metode desain test case yang komprehensif untuk sistem real-time harus berkembang.  Tetapi strategi empat langkah berikut ini dapat diusulkan :

1.        Pengujian Tugas

Langkah pertama dalam pengujian perangkat lunak real-time adalah mengujimasing-masing tugas secara independen yaitu pengujian white-box dan black-box yang didesain dan dieksekusi bagi masing-masing tugas. Masing-masing tugas dieksekusi secara independen selama pengujian ini.  Pengujian tugas mengungkap kesalahan di dalam logika dan fungsi, tetapi tidak akan mengungkap timing atau kesalahan tingkah laku.

2.        Pengujian Tingkah Laku

Dengan menggunakan model yang diciptakan dengan piranti CASE dimungkinkan untuk mensimulasi tingkah laku sistem real-time dan menguji tingkah lakunya sebagai konsekuensi dari event eksternal. Aktivitas analisis ini dapat berfungsi sebagai dasar bagi desain test case yang dilakukan pada saat perangkat lunak real-time dibangun.  Dengan menggunakan teknik yang sama dengan partisi ekivalensi event-event (misalnya, interupsi, signal kontrol, data) dikategorikan untuk pengujian.  Sebagai contoh, event untuk mesin fotokopi dapat merupakan interupsi pemakai (misalnya pencacah reset), interupsi mekanis (misalnya, paper jammed), interupsi sistem (misalnya, tone rendah) dan mode kegagalan (misalnya, roller yang terlalu panas).  Masing-masing event tersebut diuji secara individual dan tingkah laku sistem yang dapat dieksekusi diperiksa untuk mendeteksi kesalahan yang terjadi sebagai akibat pemrosesan yang terkait untuk event tersebut.  Perilaku model sistem (dikembangkan selama aktivitas analisis) dan perangkat lunak yang dapat dieksekusi dapat dibandingkan untuk penyesuaian.   Sekali masing-masing kelas event telah diuji, maka vent-event disajikan pada sistem dalam urutan acak dan dengan frekuensi acak.  Perilaku sistem diuji untuk mendeteksi kesalahan perilaku.

3.        Pengujian Antar Tugas

Setelah kesalahan-kesalahan pada tugas-tugas individual dan pada perilaku sistem diisolasi, maka pengujian beralih kepada kesalahan yang berkaitan dengan waktu.  Tugas-tugas asinkron yang dikenali untuk saling berkomunikasi diuji dengan tingkat data yang berbeda dan pemrosesan dipanggil untuk menentukan apakah kesalahan sinkronisasi antar tugas akan terjadi.  Sebagai tambahan, tugas-tugas yang berkomunikasi melalui antrian pesan atau penyimpanan data diuji untuk menemukan kesalahan dalam ukuran area penyimpanan data tersebut.

4.        Pengujian Sistem

Perangkat lunak dan perangkat keras diintegrasi dan suatu rentang penuh dari pengujian sistem dilakukan di dalam usaha mengungkap kesalahan pada interface perangkat lunak / perangkat keras.

Sebagian besar sistem real-time memproses interupsi, karena itu pengujian penanganan terhadap kejadian-kejadian Boolean ini merupakan hal yang penting, dengan menggunakan diagram keadaan-transisi dan spesifikasi kontrol.  Pengujian mengembangkan daftar semua interupsi yang mungkin dan pemrosesan yang terjadi sebagai konsekuensi dari interupsi.  Kemudian pengujian didesain untuk menilai karakteristik sistem berikut ini :

·           Apakah prioritas interupsi ditetapkan dan ditangani secara tepat?

·           Apakah pemrosesan untuk masing-masing interupsi ditangani dengan tepat?

·           Apakah kinerja (misalnya, waktu pemrosesan) dari masing-masing prosedur penanganan interupsi sesuai dengan persyaratan?

·           Apakah volume interupsi yang tinggi yang terjadi pada waktu kritis menimbulkan masalah di dalam fungsi atau kinerja?

Sebagai tambahan, area data global juga digunakan untuk mentransfer informasi sebagai bagian dari pemrosesan interupsi yang harus diuji untuk menilai potensi munculnya efek samping.

2.8. RANGKUMAN

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 dua kategori yang berbeda dari teknik desain test case yaitu pengujian white-box dan pengujian blackbox.

Pengujian white-box berfokus pada struktur kontrol 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 basis path, teknik pengujian white-box, menggunakan grafik program (atau matriks grafik) untuk melakukan serangkaian pengujian yang independen secara linear yang akan 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.

Hetzel dalam pressman (2002;565) menggambarkan pengujian white-box sebagai “pengujian kecil”.  Implikasinya, pengujian white-box secara khusus diaplikasikan ke dalam komponen program yang terkecil (misalnya,modul atau kelompok kecil dari modul),  tetapi pengujian white-box memperluas fokus kita dan akan disebut :pengujian luas”

Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.  Teknik pengujian black-box berfokus pada domain informasi dari perangkat lunak dengan melakukan test case dengan mempartisi domain input dan output dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.  Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku objek-objek program.  Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu.  Analisis nilai batas memeriksa kemampuan program untuk menangani data pada batas yang dapat diterima.

Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi.  Graphical User Interfaces, Arsitektur C/S, dokumentasi dan fasilitas help dan sistem real-time, masing-masing membutuhkan pedoman dan teknik khusus untuk pengujian perangkat lunak.

Pengembangan perangkat lunak yang berpengalaman sering mengatakan, “pengujian tidak akan pernah berakhir.  Pengujian hanya berpindah dari Anda (perekayasa perangkat lunak) ke pelanggan Anda.  Setiap kali pelanggan Anda menggunakan program tersebut, berarti suatu pengujian sedang dilakukan”.  Dengan mengaplikasikan desain test case, perekayasa perangkat lunak dapat mencapai pengujian yang lebih lengkap sehingga dapat mengungkap dan melakukan koreksi sebelum “pengujian pelanggan” dimulai.