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.
● 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
Seberapa baik sistem yang
sudah dibangun ?
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! !
! !
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
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 Mengembangkan rencana pengujian yang menekankan "pengujian siklus yang cepat."!
O Membangun ”robustt" perangkat lunak yang dirancang untuk menguji dirinya sendiri!
O Mengembangkan pendekatan perbaikan terus-menerus untuk proses pengujian.!
Unit Testing!
module! to be! tested! test cases! results! software! engineer!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
Lingkungan Pengujian Unit!
Module! stub! stub! driver! RESULTS! interface ! !local data structures! ! ! ! boundary conditions! ! ! ! independent paths! !! !
error handling paths!
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 Apakah atribut dari argumen yang 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?
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
Integration testing
!
Pengujian keseluruhan sistem atausub-sistem yang terdiri dr komponen yg terintegrasi.
!
Test integrasi menggunakan black-boxdengan test case ditentukan dari spesifikasi.
!
Kesulitannya adalah menemukan/melokasikan!
Penggunaan Incremental integration testingIncremental integration testing
T3 T2 T1 T4 T5 A B C D T2 T1 T3 T4 A B C T1 T2 T3 A B Test sequence 1 Test sequence 2 Test sequence 3Pendekatan integration testing
!
Top-down testingn 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 testingn Integrasi komponen di level hingga sistem lengkap
sudah teruji.
!
Pada prakteknya, kebanyakan test integrasimenggunakan kombinasi kedua strategi pengujian tsb.
Top-down testing
Level 2 Level 2
Level 2 Level 2
Level 1 Testing Level 1
sequence Level 2 stubs Level 3 stubs . . .
Bottom-up testing
Level N Level N Level N Level N Level N Level N–1 Level N–1 Level N–1 Testing sequence Test drivers Test driversPendekatan Testing
!
Architectural validationn Top-down integration testing lebih baik digunakan
dalam menemukan error dalam sistem arsitektur.
!
System demonstrationn Top-down integration testing hanya membatasi
pengujian pada awal tahap pengembangan system.
!
Test implementationn Seringkali lebih mudah dengan menggunakan
!
Dilakukan kalau module-module dansub-system terintegrasi dan membentuk sistem yang lebih besar
!
Tujuannya untuk medeteksi fault terhadapkesalahan interface atau asumsi yg tidak valid terntang interface tsb.
!
Sangat penting untuk pengujian terhadappengembangan 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 ka n a p a ka h s e m u a e l e m e n
ko n f i g u r a s i p e r a n g k a t l u n a k te l a h dikembangkan dengan tepat
Pengujian Validasi
O Pengujian Alpha dan Beta
O Pengujian Alpha
O Usability labs
O Usability factors checklist
Pengujian Sistem
O Pengujian Perbaikan O Pengujian Keamanan O Pengujian Stress
Pengujian Aplikasi Server
!
Volume Testing
!
Stress Testing
!
Performance Testing
!
Data Recovery Testing
!
Data Backup and Restore Testing
Volume Testing
!
Menemukan kelemahan sistem selamamelakukan pemrosesan data dalam jumlah yang besar dalam periode waktu yang
singkat.
!
Tujuan: meyakinkan bahwa sistem tetapmelakukan pemrosesan data anatar batasan fisik dan batasan logik.
!
Contoh:n Mengujikan proses antar server dan antar partisi
Stress Testing
!
Tujuan: mengetahui kemampuan sistemdalam 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 ketikasejumlah 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 Mis.: pd aplikasi Client-Server diujikan pd kondisi korporate
ataupun lingkungan sendiri (LAN vs. WAN, Laptop vs. Desktop)
n Menguji sistem dengan hubungannya sistem ke lain pada
server yg sama.
! Load Balancing Monitor ! Network Monitor
Data Recovery Testing
!
Investigasi dampak kehilangan data melaluiproses recovery ketika terjadi kegagalan proses.
!
Penting dilakukan karena data yg disimpan diserver dapat dikonfigurasi dengan berbagai cara.
!
Kehilangan Data terjadi akibat kegagalansistem, 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
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
Test Case
Eksekusi case of case
Pengujian
Tambahan Penyebab yang
dicurigai Debugging Penyebab yang diidentifikasi Koreksi Pengujian regresi Hasil
