Dokumen tersebut membahas strategi pengujian perangkat lunak meliputi pentingnya pengujian sistem, konsep kecocokan aplikasi, proses pengujian berbagai tingkatan seperti unit testing, integration testing, dan pendekatan strategis pengujian perangkat lunak.

1. Strategi Pengujian Perangkat
Lunak
Pertemuan 7

2. Pentingnya pengujian sistem
Pengujian perangkat lunak dilakukan untuk
menentukan keberadaan, kualitas, dan
kemurnian dari atribut-atribut sistem aplikasi.
Pengujian dilakukan dengan memanfaatkan
tool dan teknik.
Semakin baik struktur dari proses pengujian,
semakin baik pula hasil pengujiannya

3. Konsep kecocokan aplikasi
Keefektifan dari aplikasi komputer dalam lingkungan
bisnis ditentukan dari tingkat kecocokan aplikasi
tersebut dalam lingkungan operasinya.
Kecocokan (fit) merupakan suatu konsep yang
menekankan pada bagaimana tingkat kegunaan
(usable), pembantuan (helpful) dan manfaat dari
unjuk kerja aplikasi dalam membantu tugas-tugas
pemakai.
Semakin baik tingkat bantuan aplikasi kepada
pemakai, semakin baik tingkat "kecocokannya "

4. Konsep kecocokan ini penting dalam aspek
desain maupun pengujian.
Desain harus bertujuan untuk membangun
aplikasi yang "cocok" dengan proses bisnis
pemakai dan proses pengujian harus dapat
meyakinkan tingkat kecocokan yang
dikehendaki dipenuhi.
Pengujian yang berkonsentrasi pada struktur
dan kebutuhan (requirement) dapat gagal
memenuhi aspek kecocokan.

5. Aspek Kecocokan
1. Data: data yang andal, timelines (tepat waktu),
konsisten dan banyak berguna (useful) terkendali
dalam aplikasi yang diotomatisasi bagi pemakai.
2. Orang-orang: keahlian, training, kemampuan belajar
dan kesenangan untuk menggunakan dan
berinteraksi dengan aplikasi yang diotomatisasi.
3. Struktur: pembangunan yang tepat dari sistem
aplikasi untuk mengoptimalkan tcknologi dan
memenuhi kebutuhan.
4. Aturan-aturan: prosedur-prosedur yang harus
dipatuhi dalam pemrosesan data.

6. Testing Strategies
Tools pengujian perangkat lunak dikelompokkan
menjadi :
a) Top-Down
b) Bottom-Up
c) Big Bang
d) Sandwich

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

8. Unit testing
 Pengujian masing-masing unit komponen program
untuk meyakinkan bhw sudah beroperasi secara
benar
Module Testing
 Pengujian terhadap koleksi unit-unit komponen
yang saling berhubungan.
Sub-system Testing
 Pengujian terhadap koleksi module-module yang
membentuk suatu sub-system (aplikasi)
8
Proses Testing

9. System Testing
 Pengujian terhadap integrasi sub-system, yaitu
keterhubungan 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)
9
Proses Testing

10. Component 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
10
Proses Testing

11. 11
Hubungan antara rencana pengujian dan
proses pengembangan sistem
Spesifikasi
Kebutuhan
Spesifikasi
Sistem
Perancangan
Sistem
Detail
Perancangan
Acceptance
Test plan
System
Integration
Test plan
Sub-System
Integration
Test plan
Module and
Unit code and
test
Acceptance
test
System
Integration
test
Sub-System
Integration
test
Service

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

13. 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

14. 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?

15. 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?

16. 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

17.  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
Seberapa baik sistem yang
sudah dibangun ?

18. Integration testing
Pengujian keseluruhan system atau sub-
system 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.

19. Incremental 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
3

20. 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 tsb.

21. Top-down testing
Level 2
Level 2
Level 2
Level 2
Level 1 Level 1
Testing
sequence
Level 2
stubs
Level 3
stubs
. . .

22. 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
drivers

23. Pendekatan Testing
Architectural validation
 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

24. 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
Interface testing

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

26. Pengujian Validasi
Pengujian Alpha dan Beta
 Pengujian Alpha
 Usability labs
 Usability factors checklist
 Pengujian Beta

27. Pertemuan 8

28. Pengujian Sistem
 Pengujian Perbaikan
 Pengujian Keamanan
 Pengujian Stress
 Pengujian Kinerja

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

30. 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 pd satu server.

31. 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.

32. 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

33. Performance testing tools
Below is the comprehensive list of most
widely used performance testing tools for
measuring web application performance and
load stress capacity. These load testing tools
will ensure your application performance in
peak traffic and extreme stress conditions.
33

34. 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.

35. 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).

36. 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.

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