Strategi Pengujian Perangkat Lunak

Pokok Bahasan Pengujian Perangkat Lunak Pendekatan strategis pengujian PL

Pengujian / testing Pengujian PL adalah proses eksekusi suatu program dengan maksud menemukan kesalahan Pengujian PL merupakan elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean

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

Sasaran di atas sekaligus mengimplikasikan adanya perubahan cara pandang dimana sebelumnya dikatakan bahwa pengujian yang berhasil adalah pengujian yang tidak menemukan kesalahan. Jika pengujian sukses dilakukan, maka akan ditemukan kesalahan dalam perangkat lunak.

Prinsip Pengujian PL 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

Testability Testabilitas perangkat lunak adalah seberapa mudah sebuah perangkat lunak dapat diuji. Karena pengujian merupakan proses yang sangat sulit, perlu diketahui apa saja yang dapat dilakukan untuk membuatnya menjadi mudah. Salah satu caranya adalah dengan menyediakan checklist mengenai masalah-masalah desain yang mungkin, fitur, dll yang dapat membantu untuk bernegosiasi dengan pemrogram

Checklist Pengujian PL

1. Operabilitas “Semakin baik dia bekerja, semakin efisien dia dapat diuji.” Sistem memiliki sedikit bug (bug menambah analisis dan biaya pelaporan ke proses pengujian) Tidak ada bug yang memblokir eksekusi program Produk berubah pada tahapan fungsional (memungkinkan pengembangan dan pengujian secara simultan)

Observabilitas “Apa yang Anda lihat adalah apa yang Anda uji.” Output yang berbeda dihasilkan oleh masing-masing input Status dan variabel sistem dapat diamati selama eksekusi Status dan variabel sistem di masa lalu dapat diamati (mis. transaction log) Semua faktor yang mempengaruhi output dapat diamati Output yang salah dapat diidentifikasi dengan mudah Kesalahan internal dapat dideteksi secara otomatis melalui mekanisme self-testing Kesalahan internal dilaporkan secara otomatis Source code dapat diakses

Kontrolabilitas “Semakin baik perangkat lunak dapat dikontrol, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan” Semua output yang mungkin dapat dimunculkan melalui beberapa kombinasi input Semua kode dapat dieksekusi melalui berbagai kombinasi input Keadaan dan variabel perangkat lunak dan perangkat keras dapat dikontrol secara langsung oleh perekayasa pengujian Format input dan output konsisten dan terstruktur Pengujian dapat dispesifikasi, dioptimasi, dan diproduksi ulang dengan baik

Dekomposabilitas “Dengan mengontrol ruang lingkup pengujian, kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali dengan lebih baik” Sistem perangkat lunak dibangun dari modul-modul yang independen Modul-modul perangkat lunak dapat diuji secara independen

Kesederhanaan “Semakin sedikit yang perlu diuji, semakin cepat pengujiannya” Kesederhanaan pengujian (contohnya kumpulan fitur adalah kebutuhan minimum untuk memenuhi persyaratan) Kesederhanaan struktural (contohnya arsitektur dimodularisasi untuk membatasi propagasi kesalahan) Kesederhanaan kode (contohnya sebuah standar pengkodean diadopsi untuk kemudahan inspeksi dan pemeliharaan)

Stabilitas “Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian.” Perubahan pada perangkat lunak jarang Perubahan pada perangkat lunak dapat dikontrol Perubahan pada perangkat lunak tidak membuat pengujian yang telah ada menjadi tidak valid Perangkat lunak dapat pulih dengan baik dari kerusakan

Mudah Dipahami “Semakin banyak informasi yang dimiliki, semakin baik pengujiannya” Rancangan dapat dipahami dengan baik Ketergantungan antara komponen internal, eksternal, dan yang dipakai bersama dapat dipahami dengan baik Perubahan terhadap rancangan dikomunikasikan Dokumen teknis dapat diakses secara cepat Dokumen teknis diorganisasikan dengan baik Dokumen teknis bersifat spesifik dan detail Dokumen teknis bersifat akurat

Pengujian yang Baik 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 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” 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

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

Proses Testing System Testing Acceptance Testing Pengujian terhadap integrasi sub-system, yaitu keterkaitan antar sub-system Acceptance Testing Pengujian terakhir sebelum sistem dipakai oleh user. Melibatkan pengujian dengan data dari pengguna sistem. Biasa dikenal sebagai “alpha test” (“beta test” untuk software komersial, dimana pengujian dilakukan oleh potensial customer)

Proses Testing Unit Testing Module Testing Sub-system Testing System Acceptance Testing Component Testing Integration Testing User Testing

The testing process Component testing Integration testing Pengujian komponen-komponen program Biasanya dilakukan oleh component developer (kecuali untuk system kritis) Integration testing Pengujian kelompok komponen-komponen yang terintegrasi untuk membentuk sub-system ataupun system Dilakukan oleh tim penguji yang independent Pengujian berdasarkan spesifikasi sistem

Pendekatan Strategis ke pengujian perangkat lunak Pengujian Unit Pengujian Integrasi Pengujian Validasi Pengujian Sistem

Pengujian Unit Berfokus pada inti terkecil dari desain perangkat lunak yaitu modul Biasanya berorientasi pada white box MODUL Interface Struktur data lokal Kondisi Batas Jalur independen Jalur penanganan kesalahan Test Case

Pengujian Unit Checklist untuk pengujian interface Apakah jumlah parameter input sama dengan jumlah argumen? Apakah antara atribut dan parameter argumen sudah cocok? Apakah antara sistem satuan parameter dan argumen sudah cocok? Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?

Pengujian Unit Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter? Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter? Apakah jumlah atribut dan urutan argumen ke fungsi-fungsi built-in sudah benar? Adakah referensi ke parameter yang tidak sesuai dengan poin entri yang ada? Apakah argumen input only diubah?

Pengujian Unit Apakah definisi variabel global konsisten dengan modul ? Apakah batasan yang dilalui merupakan argumen? Test case harus didesain untuk mengungkap kesalahan dalam kategori pengetikan yang tidak teratur dan tidak konsisten inisialisasi yang salah atau nilai-nilai default Nama variabel yang tidak benar Tipe data yang tidak konsisten Underflow, overflow dan pengecualian pengalamatan

Seberapa baik sistem yang sudah dibangun ? Dua Aspek yang dipertimbangkan: Apakah implementasi sudah sesuai dengan spesifikasi ? Apakah spesifikasi sesuai dengan kebutuhan user ? Validasi “Apakah sistem yang dikembangkan sudah benar?” Pengujian dimana sistem ketika diimplementasikan sesuai dengan yang iharapkan Verifikasi “Apakah sistem dikembangkan dengan cara yang benar ?” Pengujian apakah sistem sudah sesuai dengan spesifikasi

Integration testing Pengujian keseluruhan system atau sub-system yang terdiri dari komponen yang terintegrasi. Test integrasi menggunakan black-box dengan test case ditentukan dari spesifikasi. Kesulitannya adalah menemukan/melokasikan Penggunaan Incremental integration testing dapat mengurangi masalah tersebut.

Incremental integration testing

Pendekatan integration testing Top-down testing Berawal dari level-atas system dan terintegrasi dengan mengganti masing-masing komponen secara top-down dengan suatu stub (program pendek yg mengenerate input ke sub-system yg diuji). Bottom-up testing Integrasi components di level hingga sistem lengkap sudah teruji. Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi kedua strategi pengujian tersebut.

Top-down testing

Bottom-up testing

Pendekatan Testing Architectural validation System demonstration Top-down integration testing lebih baik digunakan dalam menemukan error dalam sistem arsitektur. System demonstration Top-down integration testing hanya membatasi pengujian pada awal tahap pengembangan system. Test implementation Seringkali lebih mudah dengan menggunakan bottom-up integration testing

Interface testing Dilakukan kalau module-module dan sub-system terintegrasi dan membentuk sistem yang lebih besar Tujuannya untuk mendeteksi fault terhadap kesalahan interface atau asumsi yang tidak valid tentang interface tersebut. Sangat penting untuk pengujian terhadap pengembangan sistem dengan menggunakan pendekatan object-oriented yang didefinisikan oleh object-objectnya

Pengujian Validasi Kajian Konfigurasi (audit) Elemen dari proses validasi Memastikan apakah semua elemen konfigurasi perangkat lunak telah dikembangkan dengan tepat

Pengujian Validasi Pengujian Alpha dan Beta Pengujian Alpha Usability labs Usability factors checklist Pengujian Beta

Pengujian Sistem Pengujian Perbaikan Pengujian Keamanan Pengujian Stress Pengujian Kinerja

Pengujian Aplikasi Server Volume Testing Stress Testing Performance Testing Data Recovery Testing Data Backup and Restore Testing Data Security Testing

Volume Testing Menemukan kelemahan sistem selama melakukan pemrosesan data dalam jumlah yang besar dalam periode waktu yang singkat. Tujuan: meyakinkan bahwa sistem tetap melakukan pemrosesan data anatar batasan fisik dan batasan logik. Contoh: Mengujikan proses antar server dan antar partisi hardisik pada satu server.

Stress Testing Tujuan: mengetahui kemampuan sistem dalam melakukan transaksi selama periode waktu puncak proses. Contoh periode puncak: ketika penolakan proses login on-line setelah sistem down atau pada kasus batch, pengiriman batch proses dalam jumlah yg besar dilakukan setelah sistem down. Contoh: Melakukan login ke server ketika sejumlah besar workstation melakukan proses menjalankan perintah sql database.

Performance Testing Dilakukan secara paralel dengan Volume dan Stress testing untuk mengetahui unjuk kerja sistem (waktu respon, throughput rate) pada beberapa kondisi proses dan konfigurasi. Dilakukan pada semua konfigurasi sistem perangkat keras dan lunak. Mis.: pd aplikasi Client-Server diujikan pd kondisi korporate ataupun lingkungan sendiri (LAN vs. WAN, Laptop vs. Desktop) Menguji sistem dengan hubungannya sistem ke lain pada server yg sama. Load Balancing Monitor Network Monitor

Data Recovery Testing Investigasi dampak kehilangan data melalui proses recovery ketika terjadi kegagalan proses. Penting dilakukan karena data yg disimpan di server dapat dikonfigurasi dengan berbagai cara. Kehilangan Data terjadi akibat kegagalan sistem, hardisk rusak, peghapusan yg tidak sengaja, kecelakaan, virus dan pencuri.

Data Backup and Restore Testing Dilakukan untuk melihat prosedur back-up dan recovery. Diakukan dengan mensimulasikan beberapa kesalahan untuk menguji proses backup dan recovery. Pengujian dilakukan terhadap strategi backup: frekuensi , medium, waktu, mekanisme backup (manual/ otomatis), personal, ? Berapa lama backup akan disimpan. Switching antara live dan backup server ketika terjadi kerusakan (load log transaction pada back-up kemudian melaku recovery).

Data Security Testing Privilege access terhadap database diujikan pada beberapa user yang tidak memiliki privilege access ke database. Shutdown database engine melalui operating system (dengan beberapa perintah OS) yang dapat mematikan aplikasi database.

Debugging Test Case Hasil Eksekusi case of case Pengujian Tambahan Penyebab yang dicurigai Debugging Penyebab yang diidentifikasi Koreksi Pengujian regresi Hasil