Anda di halaman 1dari 46

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

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)
9

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

11

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

12

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

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
14

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
15

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 kegagalankegagalan tersebut diselidiki

Pengujian yang baik tidak redundan.


Waktu dan sumber daya yang tersedia untuk
pengujian

terbatas.

Tidak

ada

gunanya

melakukan pengujian dengan tujuan yang


sama

dengan

dilakukan

pengujian

sebelumnya.

yang

Setiap

telah

pengujian

harus memiliki tujuan yang berbeda


17

Pengujian yang baik seharusnya


jenis terbaik. Untuk pengujianpengujian 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
18

Pengujian yang baik tidak boleh terlalu


sederhana
Meskipun

atau

terlalu

kadang-kadang

kompleks.

mungkin

untuk

menggabungkan serangkaian pengujian ke


dalam satu kasus uji, namun secara umum
masing-masing kasus uji harus dieksekusi
secara terpisah
19

Proses Testing
System 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 Sub-system
Testing
Testing

Component Testing

System Acceptance
Testing
Testing

Integration Testing

User
Testing

The testing process


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 subsystem ataupun system
Dilakukan oleh tim penguji yang
independent
Pengujian berdasarkan spesifikasi sistem

Pendekatan Strategis ke
pengujian perangkat lunak
Pengujian
Pengujian
Pengujian
Pengujian

Unit
Integrasi
Validasi
Sistem

Pengujian Unit
Berfokus pada inti terkecil dari desain
perangkat lunak yaitu modul
Biasanya berorientasi pada white box
MODUL
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 subsystem 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
A

T1

T1

A
T1

T2

T2
T2

T3
T3

C
T4

T3
C

T4
T5

D
Test sequence
1

Test sequence
2

Test sequence
3

Pendekatan integration
testing
Top-down testing

Berawal dari level-atas system dan


terintegrasi dengan mengganti masingmasing 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
Level 1

Testing
sequence

Level 2
Le vel 2
stubs

Le vel 3
stubs

Level 1

Level 2

Le vel 2

. ..

Level 2

Bottom-up testing
Test
drivers
Level N

Test
drivers

Level N

Level N1

Le vel N

Level N1

Level N

Level N

Level N1

Testing
sequence

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

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

Perbaikan
Keamanan
Stress
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

Eksekusi case of case

Test Case
Pengujian
Tambahan

Penyebab
yang
dicurigai

Pengujian regresi
Koreksi

Penyebab
yang
diidentifikasi

Debugging

Hasil