B.  TEKNIK PENGUJIAN PERANGKAT LUNAK

Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean. 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 dilakukan pengujian. Perekayasa menciptakan sederetan test case yang dimaksudkan untuk “membongkar” perangkat lunak yang sudah dibangun. Pada dasarnya, pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang dapat dianggap (paling tidak secara psikologis) sebagai hal yang destruktif daripada konstruktif.

1.    Sasaran-sasaran pengujian

Beberapa sasaran pengujian diantaranya :

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

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

c.         Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya.

       Sasaran tersebut mengimplikasikan adanya perubahan titik pandang yang dramatis. Sasaran itu berlawanan dengan pandangan yang biasanya dipegang yang menyatakan bahwa pengujian yang berhasil adalah pengujian yang tidak ada kesalahan yang ditemukan. 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 dipenuhi.

2.    Prinsip Pengujian

Prinsip Pengujian meliputi :

a.   Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan. Sebagaimana telah kita ketahui, sasaran pengujian perangkat lunak adalah untuk mengungkapkan kesalahan. Hal ini memenuhi kriteria bahwa cacat yang paling fatal (dari titik pandang pelanggan) adalah cacat yang menyebabkan program gagal memenuhi persyaratannya.

b.  Pengujian harus direncanakan lama sebelum pengujian itu mulai. Perencanaan pengjuian dapat dimulai segera setelah model pernyaratan dilengkapi. Definisi detail mengeani test case dapat dimulai segera setelah model desain diteguhkan. Dengan demikian, semua pengujian dapat direncanakan dan dirancang sebelum semua kode dibangkitkan.

c. Prinsip Pareto berlaku untuk pengujian perangkat lunak. Secara singkat prinsip Pareto mengimplikasikan bahwa 80 persen dari semua kesalahan yang ditemukan 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.

d.   Pengujian yang mendalam tidak mungkin. Jumlah jalur permutasi untuk program yang berukuran menengah-pun sangat besar. Karean itulah tidak mungkin untuk mengeksekusi setiap kombinasi jalus skema pengujian. Tetapi dimungkinkan untuk secara tepat mencakup logika program dan memastikan bahwa semua kondisi dalam desai prosedural telah diuji.

e.   Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independent.Yang dimaksud dengan kata “yang paling efektif” adalah pengujian yang memiliki probabilitas tertinggi di dalam menemukan kesalahan (sasaran utama pengujian). Karena perekayasa perangkat lunak yang membuat sistem tersebut bukanlah orang yang paling tepat untuk melakukan semua pengujian bagi perangkat lunak.

3.    Testabilitas

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

Checklist berikut memberikan serangkaian karakteristik yang membawa kepada perangkat lunak yang dapat diuji :

a.    Operabilitas (Semakin baik dia bekerja, semakin efisien dia dapat diuji)

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

2)    Tidak ada bug yang memblok eksekusi pengujian

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

b.    Observabilitas (Apa yang Anda lihat adalah apa yang Anda uji)

1)    Output yang berbeda dikeluarkan oleh masing-masing input

2)    Tahap dan variabel sistem dapat dilihat atau diantrikan selama eksekusi.

3)     Sistem dan variabel yang lalu dapat dilihat atau diantrikan (misal : log transaksi) secara otomatis

4)     Kode sumber dapat diakses

c.     Kontrolabilitas (Semakin baik kita dapat mengontrol perangkat lunak, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan)

1)     Semua output yang mungkin dapat dimnculkan melalui beberapa kombinasi input

2)      Semua kode dapat dieksekusi melalui berbagai kombinasi input

3)     Keadaan dan varibale perangkat lunak dan perangkat keras dapat dikontrol secara langsung oleh perekayasa pengujian

4)     Format input dan output konsistem dan terstruktur

5)     Pengujian dapat dispesifikasi, dioptimasi dan direproduksi dengan baik

d.   Dekomposabilitas (Dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi masalah dan melakuakn pengujian kembali secara lebih halus)

1)     Sistem perangkat luank dibangun dari modul-modul independen

2)    Modul-modul perangkat lunak dapat diuji secara independen

e.  Dekomposabilitas (Dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi masalah dan melakuakn pengujian kembali secara lebih halus)

1)   Sistem perangkat luank dibangun dari modul-modul independen

2)  Modul-modul perangkat lunak dapat diuji secara independen Kesederhanaan struktural (seperti, arsitektur dimodularisasi untuk membatasi penyebaran kesalahan)

3) Kesederhanaan kode (seperti, standar pengkodean diadopsi demi kemduahan inspeksi dan pemeliharaan)

f.    Stabilitas (Semakin sedikti perubahan, semakin sedikit ganggunan dalam pengujian)

1)    Pengujian ke perangkat lunak tidak sering

2)    Perubahan ke perangkat lunak terkontrol

3)     Perubahan ke perangkat lunak memvalidasi pengujian yang sudah ada

4)     Kegagalan perangkat lunak dapat diperbaiki dengan baik

g.    Kemampuan untuk dapat dipahami (Semakin banyak informasi yang kita miliki, semakin halus pengujian yang akan dilakukan)

1)      Desain dipahami dengan baik

2)   Ketergantungan di antara komponen internal, eksternal dan yang dipakai bersama dipahami dengan baik.

3)     Perubahan ke desai dikomunikasikan

4)     Dokumentasi teknik dapat diakses dengan cepat

5)     Dokumentasi teknis diorganisasikan dengan baik

6)      Dokumentasi teknis spesifik dan detail

7)     Dokumentasi teknis akurat

4.        Desain Test Case

Lebih dari dua dekade terakhir telah berkembang berbagai metode desai test case untuk perangkat lunak. Metode-metode tersebut memebrikan 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 dapat diuji dengan satu atau dua cara:

a. Denganmengetahui fungsi yang ditentukan dimana produk dirancang untuk melakukannya, pengujian dapat dilakukan untuk memperlihatkan bahwa masing-masing fungsi beroperasi sepenuhnya, pada waktu yang sama mencari kesalahan pada setiap fungsi.

b.  Mengetahui kerja internal suatu produk, maka pengujian dapat dilakukan untuk memastikan bahwa “semua roda gigi berhubungan”, yaitu operasi internal bekerja sesuai dnegan spesifikasi dan semua komponen ineternal telah diamati dengan baik.Pendekatan pengujian pertama disebut pengujian black box dan yang kedua disebut white box.

5.        Pengujian White-Box

Pengujian white box, kadang-kadang disebut pengujian glass box, adalah metode desaintest case yang menggunakan struktur kontrol desain prosedural untuk memperoleh test case.

6.        Pengujian Basis-Path

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

7.         Pengujian struktural kontrol

a.          Pengujian Kondisi

b.        Pengujian Aliran Data

c.         Pengujian Loop

8.        Pengujian black box

a.         Pengujian blackbox berfokus pada persyaratan fungsional pe rangkat lunak.

b.        Disebut juga pengujian behavioral atau pengujian partisi.

c.         Pengujian blackbox memungkinkan perekayasa perangkat lunak mendapatkan serangkaian input yang sepenuhnya menggunakan semua persyaratan fungsional untuk suatu program.