PENGUJIAN PERANGKAT LUNAK

DASAR -DASAR PENGUJIAN PERANGKAT LUNAK DENGAN METODE WHITE BOX DAN BLACK BOX DAN TUJUAN DARI PENGUJIAN PERANGKAT LUNAK

 

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.

Sasaran Pengujian Perangkat Lunak

—- 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

Prinsip Pengujian
1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.
2. Pengujian harus direncanakan lama sebelum pengujian itu mulai.
3. Pengujian harus mulai “dari yang kecil” dan berkembang menjadi pengujian “yang besar”.

Karakteristik yang Membawa Perangkat Lunak Dapat Diuji
1. Operabilitas, yaitu : Semakin baik Dia bekerja, semakin efisien Dia dapat diuji.
2. Obsaikervabilitas, yaitu : “Apa yang Anda lihat adalah apa yang Anda uji”.
3. Kontralabilitas, yaitu : “Semakin baik kita dapat mengontrol perangkat lunak, semakin banyak pengujian yang dapat diotomasisasi dan dioptimalkan”.
4. Dekomposabilitas, yaitu : “Dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih halus”.
5. Kesederhanaan, yaitu : “Semakin sedikit yang kita uji, semakin cepat kita dapat mengujinya’.
6. Stabilitas, yaitu : “Semakin sedikit perubahan, semakin sedikit pula gangguan dalam pengujian’.
7. Kemampuan untuk dapat dipahami, yaitu : “Semakin banyak informasi yang kita miliki, semakin halus pengujian yang akan dilakukan’.

Atribut-­atribut pengujian yang baik :
1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.
2. Pengujian yang baik tidak redudan.
3. Pengujian yang baik seharusnya “jenis terbaik”,
4. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks.

Tujuan Pengujian :
•    Menjalankan program untuk menemukan error yang tersembunyi atau yang sebelumnya tidak terduga.

Fase Pengujian
Ada 2 tingkat yang tersedia pada proses pegujian, yaitu :
1. Konfigurasi perangkat lunak yang mencakup spesifikasi keperluan perangkat lunak, spesifikaasi perancangan, test case dan program sumber
2. Konfigurasi uji coba yang mencakup rencana dan prosedur uji coba, test case dan hasil yang diharapkan.

 

 pengujian tidak dapat memperlihatkan tidak adanya cacat, pengujian hanya dapat memperlihatkan bahwa ada kesalahan perangkat lunak.

Sebelum mengaplikasikan metode untuk mendesain test case yang efektif, perekayasa perangkat lunak harus memahami prinsip dasar yang menuntun pengujian perangkat lunak, yaitu:

• semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan, maksudnya mengungkap kesalahan dari cacat yang menyebabkan program gagal.
• Pengujian harus direncanakan lama sebelum pengujian itu mulai, maksudnya semua pengujian dapat direncanakan dan dirancang sebelum semua kode dijalankan
• Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program.
• Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian “yang besar”, Selagi pengujian berlangsung maju, pengujian mengubah focus dalam usaha menemukan kesalahan pada cluster modul yang terintegrasi dan akhirnya pada sistem.
• Pengujian yang mendalam tidak mungkin karena tidak mungkin mengeksekusi setiap kombinasi jalur skema pengujian dikarenakan jumlah jalur permutasi untuk program menengah pun sangat besar.
• Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independent

Dalam lingkungan yang ideal, perekayasa perangkat lunak mendesain suatu program computer, sebuah sistem atau produk dengan testabilitas dalam pikirannya. Hal ini memungkinkan individu yang berurusan dengan pengujian mendesain test case yang efektif secara lebih mudah. Testabilitas adalah seberapa mudah sebuah program computer dapat diuji. Karena sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi lebih mudah. Procedural dan menggunakannya sebagai pedoman untuk menetapkan basis set dari jalur eksekusi.

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 4 kategori yang berbeda dari tehnik desain test case: Pengujian white-box, pengujian black-box, Integrasi Bottom-Up dan Integrasi Top-Down.

• Pengujian white-box

Berfokus pada struktur control 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 basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear yang akan memastikan cakupan.

Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.

• Tehnik pengujian black-box

Berfokus pada domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input 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 memeriksaa kemampuan program untuk menangani data pada batas yang dapat diterima.

Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.

• Integrasi Top-Down

Adalah pendekatan incremental dengan menggerakkan ke bawah melalui hirarki control, dimulai dengan control utama. Strategi intergrasi top-down memeriksa control mayor atau keputusan pada saat awal di dalam proses pengujian. Pada struktur program yang difaktorkan dengan baik, penarikan keputusan terjadi pada tingkat hirarki yang lebih tinggi sehingga terjadi lebih dulu.

Strategi top-down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic. Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.

• Pengujian Integrasi Bottom-up

Memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi. Strategi integrasi bottom-up dapat diimplementasi dengan langkah-langkah:

Modul tingkat rendah digabung ke dalam cluster (build) yang melakukan subfungsi perangkat lunak spesifik.
Driver (program control untuk pengujian) ditulis untuk mengkoordinasi input dan output test case
Cluster diuji 
Driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam struktur program.

Tujuan Pengujian Perangkat Lunak

Tujuan Langsung :

• Untuk mengidentifikasi dan mengungkapkan sebagai kesalahan sebanyak mungkin  dalam perangkat lunak yang diuji.
• Untuk membawa perangkat lunak diuji, setelah memperbaiki kesalahan yang diidentifikasi dan melakukan pengujian ulang, pada tingkat kualitas yang memadai.
• Untuk melakukan tes yang diperlukan secara efisien dan efektif, dalam keterbatasan anggaran dan penjadwalan.

Tujuan Tidak Langsung :

• Untuk menyusun catatan kesalahan perangkat lunak untuk digunakan dalam pencegahan kesalahan (dengan tindakan perbaikan dan pencegahan).

Dalam banyak hal, disiplin tes bertindak sebagai penyedia layanan kepada disiplin lain. Pengujian berfokus terutama pada evaluasi atau menilai kualitas produk, menggunakan sejumlah praktek inti:

1. Menemukan dan dokumen kegagalan dalam produk perangkat lunak: cacat,  masalah
2. Menyarankan manajemen pada kualitas yang dirasakan pada perangkat lunak
3. Mengevaluasi asumsi yang dibuat dalam spesifikasi rancangan dan persyaratan melalui demonstrasi nyata
4. Memvalidasi bahwa produk perangkat lunak yang dibuat bekerja sesuai rancangan
5. Memvalidasi bahwa persyaratan diterapkan secara tepat

Sebuah perbedaan menarik yang ada antara pengujian dan disiplin ilmu RUP lain :

Pada dasarnya disiplin Test bertugas menemukan dan mengekspos kelemahan dalam produk perangkat lunak. Untuk mendapatkan manfaat terbesar, kita memerlukan filosofi atau pola pikir yang berbeda dari yang digunakan dalam disiplin Persyaratan, Analisis dan Desain, dan Implementasi. Sementara tiga disiplin tersebut fokus pada kelengkapan, konsistensi, dan kebenaran, disiplin Test berfokus pada apa yang hilang, salah, atau tidak konsisten.

Upaya pengujian yang baik didorong oleh pertanyaan seperti ini:

• Bagaimana suatu perangkat lunak dapat gagal?
• Dalam situasi apa yang mungkin ada sehingga perangkat lunak ini gagal bekerja sesuai perkiraan?

Disiplin Test menantang asumsi, risiko, dan ketidakpastian yang melekat dalam karya disiplin lain, dan mengalamatkan kekhawatiran mereka menggunakan demonstrasi nyata dan evaluasi yang tidak memihak. Kita ingin menghindari dua hal ekstrem potensial:

• Pendekatan yang tidak sesuai atau secara efektif menantang perangkat lunak dalam mengekspos kelemahan dan  masalah yang melekat.
• Pendekatan yang tidak tepat negatif atau merusak akan mengadopsi suatu pendekatan negatif, kita  merasa tidak mungkin untuk pernah mempertimbangkan produk perangkat lunak dari kualitas yang dapat diterima. Mengambil pendekatan seperti itu dapat menjauhkan upaya Test dari disiplin lain.

Informasi yang disajikan dalam berbagai survei dan esai menyatakan bahwa pengujian perangkat lunak menghabiskan 30% sampai 50% dari biaya pengembangan perangkat lunak. Oleh karena itu, agak mengejutkan untuk dicatat bahwa sebagian besar orang percaya bahwa perangkat lunak komputer belum diuji dengan baik sebelum itu disampaikan. Kontradiksi ini berakar dalam beberapa isu kunci:

1. Pengujian perangkat lunak sangat sulit. Bagaimana cara kita mengukur berbagai kondisi dimana program yang diberikan dapat berhasil atau gagal?
2. Biasanya, pengujian dilakukan tanpa metodologi yang jelas, menciptakan hasil yang bervariasi dari proyek untuk proyek dan dari organisasi ke organisasi. Sukses bergantung terutama pada faktor kualitas dan keterampilan individu dalam tim penguji
3. Alat Produktivitas digunakan secara tidak efisien atau tidak sama sekali, yang membuat aspek pengujian melelahkan dan tidak teratur. Selain kurangnya pelaksanaan tes otomatis, banyak upaya pengujian dilakukan tanpa alat yang memungkinkankita secara efektif mengelola luasnya Data Uji dan Hasil Uji
4. Fleksibilitas dari penggunaan dan kompleksitas perangkat lunak membuat pengujian lengkap menjadi tujuan yang mustahil. Penggunaan strategi yang disusun dan alat-alat yang tepat dapat meningkatkan produktivitas dan efektivitas pengujian perangkat lunak.