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 ! Must learn about the system,!
! ! but, will attempt to break it!
but, will test "gently"! !
!and, is driven by "delivery"! !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 terus-
menerus untuk proses pengujian.!
Unit Testing!

module!
to be!
tested!

results!

software!
engineer!
test cases!
 Pengujian  Unit  
O  Berfokuspada 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!
!interface !
!
local data structures!
!
Module! boundary
! conditions!
!
independent paths!
!
error handling paths!
!
stub! 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 B
T2
T2 B T3
T3
B C
T3 T4
C
T4
D T5

Test sequence Test sequence Test sequence

1 2 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
Testing
Level 1 Level 1 ...
sequence

Level 2 Level 2 Level 2 Level 2

Level 2
stubs

Level 3
stubs
 Bottom-up testing
Test
drivers

Testing
Level N Level N Level N Level N Level N
sequence

Test
drivers
Level N–1 Level N–1 Level N–1
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  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 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 Penyebab
Tambahan yang
dicurigai
Hasil
Pengujian regresi

Penyebab
Koreksi yang Debugging
diidentifikasi