2.
1  Dasar-Dasar 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. Sasarannya adalah mendesain pengujian yang secara sistematis mengungkap kelas kesalahan yang berbeda dan melakkukannya 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 dipenuhi. 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.

2.    Prinsip Pengujian

Prinsip Pengujian meliputi :

a.    Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.

b.   Pengujian harus direncanakan lama sebelum pengujian itu mulai.

c.    Pengujian harus mulai dari yang kecil dan berkembang ke pengujian yang besar.

d.   Pengujian yang mendalam tidak mungkin.

e.    Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independent.

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 keproses pengujian).

2)    Tidak ada bug yang memblok eksekusi pengujian Produk berkembang di dalam tahapan fungsional (memungkinkan pengemabangan 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).

4)   Semua faktor yang mempengaruhi output dapat dilihat.

5)   Kesalahan itnernal dideteksi secara otomatis melalui mekanisme selftesting.

6)   Kesalahan internal dilaporkan secara otomatis.

7)   Kode sumber dapat diakses

c.    Kontrolabilitas. “Semakin baik kita dapat mengontrol perangkat luank, 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.    Kesederhanaan. “Semakin sedikit yang diuji, semakin cepat kita dapat mengujinya”.

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

2)   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

Berikut adalah atribut-atribut pengujian yang “baik” :

a.    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 adalah kegagalan untuk mengenali posisi mouse yang sesuai. Serangkaian pengujian akan dirancang untuk menguji mouse untuk memperlihatkan kesalahan di dalam pengenalan posisi mouse.

b.    Pengujian yang baik tidak redudan. Waktu pengujian dan sumber daya terbatas. Tidak ada manfaatnya melakukan pengujian dengan tujuan yang sama dengan pengujian lainnya. Setiap pengujian arus memiliki tujuan yang berbeda.

c.     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 harus digunakan.

d.    Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks. Secara umum masing-masing test case harus dieksekusi secara terpisah.

2.2. 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 : (1) denganmengetahui fungsi yang ditentukan dimana produk dirancang untuk melakukannya, pengujian dapatdilakukan untuk memperlihatkan bahwa masing-masing fungsi beroperasi sepenuhnya, pada waktu yang sama mencari kesalahan pada setiap fungsi; (2) 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. 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 integrasi informasi eksternal (seperti file data) dipelihara. Pengujian balck 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 pada berbgai titik untuk menentukan apakah status yang diharapkan atau dituntut sesuai dengan status aktual.

2.3. 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. Dengan menggunakan metode pengujian white box, perekayasa sistem dapat melakukan test case yang :

1.    memberikan jaminan bahwa semua jalur independen pada suatu modal telah digunakan, paling tidak satu kali.

2.    Menggunakan semua keputusan logis pada sisi true dan false.

3.    Mengeksekusi semua loop pada batasan mereka dan bahasa operasional mereka.

4.    Menggunakan struktur data internal untuk menjamin validitasnya.

Pada titik ini, dapat diajukan pertanyaan yang beralasan, yaitu “Mengapa menghabiskan waktu dan energi untuk 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 mainstraim. Pemrosesan setiap hari cenderung dipahami dengan baik sementara pemrosesan “kasus khusus” cenderung berantakan.

·      Kita sering percaya bahwa jalur logis mungkin tidak akan diseksekusi bila pada kenyataannya akan diseksekusi pada basis reguler. Aliran logika dari suatu program kadangkadang bersifat konterintuitif yang berarti asumsi kita yang tidak kita sasari mengenai aliran dan data kontrol dapat menyebabkan kita membuat kesalahan desai yang akan terungkap hanya setelah pengujian jalur mulai.

·      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 pengujianmulai.

Masing-masing alasan tersebut memberikan suatu argurmen untuk melakukan pengujian white box. Pengujian black box, tidak peduli seberapa cermat dilakukan, dapat menangkap bentuk kesalahan tersebut.

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

1.    Notasi Diagram Alir

Sebelum metode babsis path diperkenalkan, terlebih dahulu akan dijelaskanmengenasi notasi sederhana dalam bentuk diagram alir (grafik alir). Diagral alir menggambarkan aliran kontrol logika yang menggunakan notasi seperti ditunjukkan pada gambar 1. Masing-masing gagasan terstruktur memiliki simbol diagram alir yang sesuai.

Gambar 2 merepresentasikan desain prsedural grafik alir. Paga gambar tersebut tampak struktrul kontrol progrm. Gambar 3 memetakan grafik alir tersebut ke dalam grafik alir yang sesuai. Pada gambar tersebut masing-masing lingkaran disebut simpulu grafik alir, merepresentasikan satu atau lebih statemen prosedural. Urutan kotak proses dan belahketupat keputusan dapat memetakan simpul tunggal. Anak panah pada grafik alir tersebut disebut edges atau links, merepresentasikan aliran kontrol dan analog dengan anak panah bagan alir. Edge harus berhenti pada suatu simpul, mesikipun nila simpul tersebut tidak merepresentasikan statemen prosedural (misal simpul untuk bangun if-then-else). Area yang dibatasi oleh edge dan simpul disebtu region. Pada saat menghitung region kita perlu memasukkan area di luar grafik dan menghitungnya sebgai sebuah region.

• Twitter
• Facebook
• Google
• Tumblr
• Pinterest