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

!!

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

Test Case

Lingkungan Pengujian Unit!

Module!

stub! stub!

driver!

RESULTS!

interface !!local data structures!!

!!

boundary conditions!!

!!independent paths!!!!error handling paths!

test cases!

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 atr ibut dar i 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?

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

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Test sequence1

Test sequence2

Test sequence3

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

Level 2Level 2Level 2Level 2

Level 1 Level 1Testingsequence

Level 2stubs

Level 3stubs

. . .

Bottom-up testing

Level NLevel NLevel NLevel NLevel N

Level N–1 Level N–1Level N–1

Testingsequence

Testdrivers

Testdrivers

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

! 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

Pengujian  Validasi  O  Kajian Konfigurasi (audit)

O Elemen dari proses validasi O Memast ikan apakah semua e lemen

kon f i gu ras i pe rangka t l unak te lah 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  

Test Case

Eksekusi case of case

Pengujian Tambahan

Penyebab yang dicurigai

Debugging Penyebab yang diidentifikasi

Koreksi

Pengujian regresi Hasil