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”.
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’.
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.
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.
• 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.
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
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
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
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
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:
- Menemukan dan dokumen kegagalan dalam produk perangkat lunak: cacat, masalah
- Menyarankan manajemen pada kualitas yang dirasakan pada perangkat lunak
- Mengevaluasi asumsi yang dibuat dalam spesifikasi rancangan dan persyaratan melalui demonstrasi nyata
- Memvalidasi bahwa produk perangkat lunak yang dibuat bekerja sesuai rancangan
- 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:
- Pengujian perangkat lunak sangat sulit. Bagaimana cara kita mengukur berbagai kondisi dimana program yang diberikan dapat berhasil atau gagal?
- 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
- 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
- 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.