Strategi Pengujian Perangkat Lunak Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user.!
What Testing Shows! errors! requirements conformance! performance!
an indication! of quality!
Pendekatan Strategis ✪ Pengujian yang efektif dengan melakukan tinjauan teknis yang efektif. Dengan melakukan ini, banyak kesalahan akan dihilangkan sebelum pengujian dimulai. ✪ Pengujian dimulai pada tingkat komponen dan bekerja ”outward" terhadap integrasi sistem berbasis komputer secara keseluruhan. ✪ Teknik pengujian yang berbeda sesuai untuk pendekatan rekayasa perangkat lunak yang berbeda dan di berbagai titik dalam waktu. ✪ Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek-proyek besar) suatu kelompok uji independen. ✪ Pengujian dan debugging merupakan aktivitas yang berbeda, tetapi debugging harus diakomodasi dalam strategi pengujian.
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 diharapkan
●
Verifikasi • “Apakah sistem dikembangkan dengan cara yang benar ?” • Pengujian apakah sistem sudah sesuai dengan spesifikasi
Who Tests the Software?!
developer!
independent tester!
Understands the system ! ! but, will test "gently"! !and, is driven by "delivery"! ! !
Must learn about the system,! ! but, will attempt to break it! ! !and, ! is driven by quality! ! !
Pendekatan Strategis ke pengujian perangkat lunak
Strategi Pengujian O Dimulai dari‘testing-in-the-small’ kemudian ke
‘testing-in-the-large’! O Untuk PL Konvensional! O Fokus : module (komponen) ! O Dilanjutkan integrasi antar module!
! O Untuk PL Object Oriented! O Fokus “testing in the small” berubah dari modul ke
OO class meliputi atribut dan operation!
Isu Strategis ! O Tentukan persyaratan produk secara kuantitatif
jauh sebelum pengujian dimulai.! O Memahami pengguna perangkat lunak dan mengembangkan profil untuk setiap kategori pengguna.! O M engembangkan rencana pengujian yang menekankan "pengujian siklus yang cepat."! O Membangun ”robustt" perangkat lunak yang dirancang untuk menguji dirinya sendiri! O Mengembangkan pendekatan perbaikan terusmenerus untuk proses pengujian.!
Unit Testing! module! to be! tested! results! software! engineer!
test cases!
Pengujian Unit O Berfokus
pada inti terkecil dari desain perangkat lunak yaitu modul O Biasanya berorientasi pada white box MODUL
Interface Struktur data lokal Kondisi Batas Jalur independen Jalur penanganan kesalahan
Test Case
Lingkungan Pengujian Unit! driver!
Module!
stub!
!interface ! ! local data structures! ! boundary conditions! ! ! independent paths! ! error handling paths! !
stub!
test cases! RESULTS!
Pengujian Unit O Checklist untuk pengujian interface O Apakah jumlah parameter input sama
dengan jumlah argumen? O Apakah antara atribut dan parameter argumen sudah cocok? O Apakah antara sistem satuan parameter dan argumen sudah cocok? O A p a k a h j u m l a h a r g u m e n y a n g ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?
Pengujian Unit O A p a ka h a t r i b u t d a r i a r g u m e n y a n g
ditransmisikan ke modul yang dipanggil sama dengan atribut parameter? O Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter? O Apakah jumlah atribut dan urutan argumen ke fungsi-fungsi built-in sudah benar? O Adakah referensi ke parameter yang tidak sesuai dengan poin entri yang ada? O Apakah argumen input only diubah?
Pengujian Unit O Apakah definisi variabel global konsisten dengan
modul ? O 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
Integration testing ! Pengujian keseluruhan sistem atau sub-
sistem yang terdiri dr komponen yg 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 A
T1
T1
A T1
T2
A
T2 T2
B
B
T3 T3
B
C T4
T3 C
T4 T5
D Test sequence 1
Test sequence 2
Test sequence 3
Pendekatan integration testing ! Top-down testing n
Berawal dari level-atas sistem dan terintegrasi dengan mengganti masing-masing komponen secara top-down dengan suatu stub (program pendek yg mengenerate input ke sub-sistem yg diuji).
! Bottom-up testing n
Integrasi komponen di level hingga sistem lengkap sudah teruji.
! Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi kedua strategi pengujian tsb.
Top-down testing Level 1
Testing sequence
Level 2 Level 2 stubs
Level 3 stubs
Level 1
Level 2
Level 2
...
Level 2
Bottom-up testing Test drivers Level N
Test drivers
Level N
Level N–1
Level N
Level N–1
Level N
Level N
Level N–1
Testing sequence
Pendekatan Testing ! Architectural validation n
Top-down integration testing lebih baik digunakan dalam menemukan error dalam sistem arsitektur.
! System demonstration n
Top-down integration testing hanya membatasi pengujian pada awal tahap pengembangan system.
! Test implementation n
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 medeteksi fault terhadap kesalahan interface atau asumsi yg tidak valid terntang interface tsb. ! Sangat penting untuk pengujian terhadap pengembangan sistem dgn menggunakan pendekatan object-oriented yg didefinisikan oleh object-objectnya
Pengujian Validasi O Kajian Konfigurasi (audit) O Elemen dari proses validasi O M e m a s t i k a n
apakah semua elemen konfigurasi perangkat lunak telah dikembangkan dengan tepat
Pengujian Validasi O Pengujian Alpha dan Beta O Pengujian Alpha O Usability labs O Usability factors checklist
O Pengujian Beta
Pengujian Sistem O Pengujian Perbaikan O Pengujian Keamanan O Pengujian Stress O 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: n
Mengujikan proses antar server dan antar partisi hardisik pd 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. n
n
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) yg dapat mematikan aplikasi database.
Debugging
Eksekusi case of case
Test Case Pengujian Tambahan
Penyebab yang dicurigai
Pengujian regresi Koreksi
Penyebab yang diidentifikasi
Debugging
Hasil
