STRATEGI PENGUJIAN

PERANGKAT LUNAK
RIMA MAWARNI, M.KOM

INSTITUT TEKNOLOGI DAN BAHASA DIAN CIPTA CENDIKIA

FAKULTAS ILMU KOMPUTER - PROGRAM STUDI SISTEM INFORMASI
Strategi Pengujian PR

• Pengujian / Testing.
• Sasaran Pengujian
• Prinsip Pengujian PL
• Testabilitas
Pengujian / Testing

• Pengujian PL adalah proses eksekusi suatu program

dengan maksud menemukan kesalahanPengujian 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 kesalahanKasus uji yang baik adalah
yang memiliki tingkat kemungkinan tinggi untuk menemukan
kesalahan yang belum ditemukanPengujian 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 Perangkat Lunak

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
Testabilitas

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 bernegosiasi dengan
pemrogram.
Checklist Pengujian PL

• Operabilitas
• Observabilitas
• Kontrolabilitas
• Dekomposabilitas
• Kesederhanaan
• Stabilitas
• Mudah dipahami
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 programProduk berubah pada tahapan
fungsional (memungkinkan pengembangan dan
pengujian secara simultan)
2. Observabilitas
(apa yang adan 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
3. 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
4. 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 independenModul-modul perangkat
lunak dapat diuji secara independen
5. 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
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
Mudah dipahami

“Semakin banyak informasi yang dimiliki, semakin

baik pengujiannya”

 Rancangan dapat dipahami dengan baikKetergantungan

antara komponen internal, eksternal, dan yang dipakai
bersama dapat dipahami dengan baikPerubahan
terhadap rancangan dikomunikasikan
 Dokumen teknis dapat diakses secara cepat
 Dokumen teknis diorganisasikan dengan baik
 Dokumen teknis bersifat spesifik dan detail
 Dokumen teknis bersifat akurat
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 kegagalan-kegagalan
tersebut diselidiki
Pengujian yang baik, tidak redudansi.

Pengujian yang baik tidak redundan. Waktu dan sumber daya yang tersedia untuk
pengujian terbatas. Tidak ada gunanya melakukan pengujian dengan tujuan yang
sama dengan pengujian yang telah dilakukan sebelumnya. Setiap pengujian harus
memiliki tujuan yang berbeda

Pengujian yang baik seharusnya “jenis terbaik”.

Untuk pengujian-pengujian 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

Pengujian yang baik tidak boleh terlalu sederhana atau terlalu

kompleks.

Meskipun kadang-kadang mungkin untuk menggabungkan serangkaian pengujian

ke dalam satu kasus uji, namun secara umum masing-masing kasus uji harus
dieksekusi secara terpisah
Proses Testing System Testing Acceptance
Testing
Proses Testing Unit Testing Module Testing Sub-
system Testing System

• Acceptance Testing

• Component Testing

• Integration Testing

• User Testing
The testing process Component testing
Integration 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 independentPengujian

berdasarkan spesifikasi sistem
Pendekatan Strategis ke pengujian perangkat
lunak

• Pengujian Unit

• Pengujian Integrasi

• Pengujian Validasi

• Pengujian Sistem
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
 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?
 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?
Lanjutan…..
 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:

1. Apakah implementasi sudah sesuai dengan spesifikasi ?

2. 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 sub-system 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.
Pendekatan Integration Testing

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

2. Bottom-Up Testing
Bottom-up testingIntegrasi components di level hingga
sistem lengkap sudah teruji.Pada prakteknya, kebanyakan
test integrasi menggunakan kombinasi kedua strategi
pengujian tersebut
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
1. Pengujian Validasi Kajian Konfigurasi (Audit)
Elemen dari proses validasiMemastikan apakah semua elemen
konfigurasi perangkat lunak telah dikembangkan dengan tepat

2. Pengujian Validasi Alpha dan Beta

Usability labsUsability factors checklist Pengujian Beta

3. Pengujian sistem Perbaikan dan Keamaan

Pengujian StressPengujian Kinerja

4. Pengujian aplikasi Server

Volume Testing, Stress Testing, Performance Testing, Data Recovery
Testing, Data Backup and Restore Testing, Data Security Testing
Lanjutan 4 ( Pengujian aplikasi Server)

1. 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 MonitorNetwork Monito
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 dan 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 Scurity 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 Test Case Hasil Eksekusi case of case
Pengujian Tambahan

 Penyebab yang dicurigai

 DebuggingPenyebab yang diidentifikasi
 KoreksiPengujian regresi
 Hasil
TERIMAKASIH