Rekayasa Perangkat Lunak

Dasar-Dasar Pengujian Perangkat Lunak

Pada proses Rekayasa Perangkat Lunak (RPL), pelaku RPL mula-mula berusaha untuk membangun perangkat lunak mulai dari konsep abstrak sampai kepada tahap implementasi yang dapat dilihat, baru kemudian dilakukan pengujian.
Pada pengujian perangkat lunak, pelaku RPL menciptakan sekumpulan kasus uji untuk diujikan kepada perangkat lunak. Proses ini lebih terkesan berusaha untuk “membongkar” perangkat lunak yang sudah dibangun. Proses pengujian merupakan tahapan dalam RPL di mana secara fisik terlihat lebih banyak sisi desktruktifnya dibandingkan sisi konstruktifnya karena tujuannya adalah untuk menemukan kesalahan pada perangkat lunak.


Sasaran Pengujian Perangkat Lunak

Sasaran pengujian perangkat lunak antara lain:

• Pengujian adalah proses mengeksekusi program dengan tujuan khusus untuk menemukan kerusakan
• Kasus uji yang baik adalah yang memiliki tingkat kemungkinan tinggi untuk menemukan kerusakan yang belum ditemukan
• Pengujian dikatakan berhasil jika berhasil menemukan kerusakan yang belum ditemukan

Sasaran di atas sekaligus mengimplikasikan adanya perubahan cara pandang di mana sebelumnya dikatakan bahwa pengujian yang berhasil adalah pengujian yang tidak menemukan kesalahan.
Jika pengujian sukses dilakukan, maka akan ditemukan kesalahan dalam perangkat lunak. Sebagai keuntungan tambahan, pengujian menunjukkan bahwa fungsi perangkat lunak bekerja sesuai spesifikasi dan bahwa persyaratan kinerja telah dipenuhi.
Data yang dikumpulkan pada saat pengujian dilakukan memberikan indikasi yang baik mengenai realibilitas perangkat lunak dan beberapa indikasi dari kualitas keseluruhan perangkat lunak. Akan tetapi, pengujian tidak dapat memperlihatkan bahwa perangkat lunak yang diuji tidak memiliki cacat.


Prinsip Pengujian Perangkat Lunak

Serangkaian prinsip pengujian perangkat lunak antara lain:

• Semua pengujian harus dapat ditelusuri sampai ke kebutuhan pelanggan. Sasaran pengujian perangkat lunak adalah untuk menemukan kesalahan. Hal ini memenuhi kriteria bahwa cacat yang paling fatal dilihat dari sisi pandang pelanggan adalah cacat yang mengakibatkan program gagal memenuhi persyaratannya
• Pengujian harus direncanakan lama sebelum pengujian dimulai. Perencanaan pengujian dapat dimulai segera setelah model kebutuhan dilengkapi. Definisi detail kasus uji dapat dibuat segera setelah model perancangan dibuat. Dengan demikian, semua pengujian dapat direncanakan dan dirancang sebelum semua kode dibangkitkan
• Prinsip Pareto berlaku untuk pengujian perangkat lunak. Prinsip Pareto mengimplikasikan bahwa 80% dari semua kesalahan yang ditemukan selama pengujian akan dapat ditelusuri sampai 20% dari modul program. Permasalahannya adalah bagaimana mengisolasi modul yang dicurigai dan mengujinya dengan teliti
• Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian “yang besar”. Pengujian pertama kali dilakukan fokus pada modul individual perangkat lunak, kemudian pengujian mengubah fokus menjadi menemukan kesalahan pada cluster modul yang terintegrasi, dan akhirnya pada sistem secara keseluruhan
• Tidak mungkin melakukan pengujian yang mendalam. Jumlah jalur permutasi untuk program yang berukuran menengah sangat besar. Karena itulah, tidak mungkin untuk mengeksekusi setiap kombinasi jalur skema pengujian. Tetapi dimungkinkan untuk secara memadai mencakup logika program dan memastikan bahwa semua kondisi dalam rancangan prosedural telah diuji
•  Agar memperoleh pengujian yang paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independen. Maksudnya, agar pengujian memiliki tingkat kemungkinan yang tinggi untuk menemukan kesalahan, maka pelaku RPL yang membuat sistem tersebut bukanlah orang yang paling tepat untuk melakukan semua pengujian bagi perangkat lunak

Sementara itu, pengujian yang “baik” dapat dilihat dari atribut-atribut berikut:

• Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan. Untuk mencapai hal ini, penguji harus memahami perangkat lunak dan berusaha mengembangkan gambaran mengenai bagaimana perangkat lunak dapat gagal. Kemudian kegagalan-kegagalan tersebut diselidiki
• Pengujian yang baik tidak redundan. Waktu dan sumber daya yang tersedia untuk pengujian terbatas. Tidak ada gunanya melakukan pengujian dengan tujuan yang sama dengan pengujian yang telah dilakukan sebelumnya. Setiap pengujian harus memiliki tujuan yang berbeda
• Pengujian yang baik seharusnya “jenis terbaik”. Untuk pengujian-pengujian yang memiliki tujuan serupa, batasan waktu dan sumber daya dapat menghalangi eksekusi kelompok pengujian tersebut. Pada kasus semacam ini, maka pengujian yang memiliki kemungkinan paling besar untuk mengungkap seluruh kesalahan 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 kasus uji, namun secara umum masing-masing kasus uji harus dieksekusi secara terpisah

Perancangan Kasus Uji

Saat ini sudah banyak berkembang berbagai metode untuk pengujian perangkat lunak. Metode-metode tersebut memberikan pendekatan yang sistematik untuk pengujian perangkat lunak kepada pengembang. Selain itu, metode-metode tersebut 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, yaitu:

• Dengan mengetahui fungsi yang ditentukan untuk dilakukan oleh suatu produk, pengujian dapat dilakukan untuk memperlihatkan bahwa masing-masing fungsi beroperasi sepenuhnya dan pada waktu yang sama mencari kesalahan pada setiap fungsi
• Dengan mengetahui kerja internal suatu produk, maka pengujian dapat dilakukan untuk memastikan bahwa seluruh operasi internal bekerja sesuai spesifikasi dan semua komponen internal telah diamati dengan memadai

Pendekatan pengujian pertama disebut sebagai pengujian black-box dan pengujian kedua disebut sebagai pengujian white-box.

Pengujian black-box berkaitan dengan pengujian yang dilakukan pada antarmuka perangkat lunak. Meskipun dirancang untuk mengungkap kesalahan, pengujian black-box digunakan untuk memperlihatkan bahwa fungsi-fungsi perangkat lunak dapat beroperasi, 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 memperhatikan sedikit struktur logika internal perangkat lunak tersebut.

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

Sekilas terlihat bahwa pengujian white-box yang sangat teliti akan membawa kepada program yang benar 100%. Yang diperlukan adalah menentukan semua jalur logika, mengembangkan kasus uji untuk mengujinya, dan mengevaluasi hasil, yaitu memunculkan kasus uji untuk menguji logika program secara mendalam. Namun sesuai dengan prinsip pengujian, pengujian secara mendalam akan menimbulkan masalah logistik. Bahkan untuk program yang kecil, dapat dibangkitkan jumlah jalur logika yang besar.

Tetapi pengujian white-box tidak boleh dianggap tidak praktis. Sejumlah 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 antarmuka perangkat lunak, dan secara selektif menjamin bahwa kerja internal perangkat lunak itu benar.

White-Box Testing

White-box testing (kadang-kadang disebut sebagai glass-box testing) adalah metode desain kasus uji yang menggunakan struktur kontrol desain prosedural untuk memperoleh kasus uji. Dengan menggunakan metode pengujian white-box, perekayasa sistem dapat melakukan kasus uji yang:

• Memberikan jaminan bahwa semua jalur independen pada suatu modul telah digunakan paling tidak satu kali
• Menggunakan semua keputusan logis pada sisi true dan false
• Mengeksekusi semua loop pada batasan mereka dan pada batas operasional mereka
• Menggunakan struktur data internal untuk menjamin validitasnya

Muncul pertanyaan tentang mengapa menghabiskan waktu dan sumber daya untuk menguji logika jika dapat memastikan bahwa persyaratan program telah dapat dipenuhi dengan lebih baik. Jawaban dari pertanyaan ini ada pada sifat cacat perangkat lunak seperti:

• Kesalahan logis dan asumsi yang tidak benar berbanding terbalik dengan probabilitas jalur program yang akan dieksekusi. Kesalahan cenderung muncul pada saat perancangan dan implementasi fungsi, kondisi, atau kontrol yang berada di luar mainstream
• Kepercayaan bahwa jalur logika mungkin tidak akan dieksekusi bila pada kenyataannya mungkin dieksekusi pada basis reguler. Aliran logika dari program kadang bersifat konterintuitif, artinya asumsi yang tidak disadari mengenai aliran dan data kontrol dapat menyebabkan kesalahan perancangan yang akan terungkap setelah pengujian jalur dimulai
• Kesalahan tipografi sifatnya acak. Bila sebuah program diterjemahkan ke dalam source code bahasa pemrograman, maka dimungkinkan akan terjadi banyak kesalahan pengetikan. Beberapa kesalahan dapat ditemukan melalui mekanisme pengecekan sintaks, namun yang lainnya tidak akan terdeteksi sampai dilakukan pengujian

Sifat cacat tersebut sangat mungkin ditemukan dengan menggunakan pengujian white-box sedangkan pengujian black-box tidak dapat menemukannya seberapa cermat pun pengujian black-box dilakukan. Alasan inilah yang mendasari mengapa pengujian white-box dilakukan.

Jenis pengujian White-Box testing antara lain:

• Basis path testing
• Control Structure Testing, yang terdiri dari:
• Condition Testing
• Data Flow Testing
• Loop Testing

Black-Box Testing

Pengujian ini fokus kepada persyaratan fungsional perangkat lunak. Pengujian ini memungkinkan pelaku RPL mendapatkan serangkaian kondisi input yang memenuhi persyaratan fungsional suatu program.

Pengujian ini berusaha menemukan kesalahan dengan kategori sebagai berikut:

• Fungsi-fungsi yang salah atau hilang
• Kesalahan antarmuka
• Kesalahan struktur data atau akses basisdata eksternal
• Kesalahan kinerja
• Kesalahan inisialisasi atau terminasi

Pengujian ini cenderung untuk dilakukan pada tahap akhir pengujian berbeda dengan white-box testing. Penguji dituntut untuk menjawab pertanyaan-pertanyaan berikut:

• Bagaimana validitas fungsional diuji?
• Kelas input apa yang akan membuat kasus uji menjadi baik?
• Apakah sistem sangat sensitif terhadap nilai input tertentu?
• Bagaimana batasan suatu data diisolasi?
• Berapa kecepatan dan volume data yang dapat ditolerir sistem?
• Apa pengaruh kombinasi tertentu dari data terhadap operasi sistem?

Dengan mengaplikasikan teknik pengujian ini, penguji membuat serangkaian kasus uji yang:

• Mengurangi jumlah kasus uji tambahan yang harus dirancang untuk mencapai pengujian yang benar
• Memberi tahu mengenai ada atau tidaknya kesalahan

Contoh pengujian Black-Box testing antara lain:

• Graph Based Testing Method
• Equivalence Partitioning
• Boundary Value Analysis
• Comparison Testing
• Orthogonal Array Testing