Transcript Pengujian pada Perangkat Lunak

Lukman Hakim
Pengujian Validasi
 KajianKonfigurasi(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 Factor Checklist
 Pengujian Beta
Pengujian Sistem
 Pengujian Perbaikan
 Pengujian Keamanan
 Pengujian Stress
 Pengujian Kinerja
Pendekatan Strategis ke Pengujian
Perangkat Lunak
 Penguujian Unit
 Pengujian Integrasi
 Pengujian Validasi
 Pengujian sistem
Pengujian Unit
 Berfokus pada inti terkecil dari desain perangkat lunak
yaitu modul
 Biasanya berorientasi pada white box
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 kemodul
yang dipanggil sama dengan atribut parameter?
lanjutan
 Apakah atribut dari argumen yang ditransmisikan




kemodul yang dipanggil sama dengan atribut
parameter?
Apakah sistem unit dari argumen yang ditransmisikan
kemodul yang dipanggil sama dengan sistem satuan
parameter?
Apakah jumlah atribut dan urutan argumen kefungsifungsi built-in sudah benar?
Adakah referensi keparameter 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
 Tipedata yang tidak konsisten
 Underflow, overflow dan pengecualian pengalamatan
Integritas testing
 Pengujian keseluruhan system atau sub-system yang
terdiri dari 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 Integrasi Testing
Pendekatan Integrasi Testing
Top-down testing
 Berawal dari level-atas system dan terintegrasi dengan
mengganti masing-masing komponen secara topdown dengan suatu stub (program pendek yang
mengenerate input kesub-system yg diuji).
Bottom-up testing
 Integrasi components dilevel hingga sistem lengkap
sudah teruji.
Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi
kedua strategi pengujian tsb.
Top-Down Testing
Bottom Up Testing
PendekatanTesting
Architectural validation
 Top-down integration testing lebih baik digunakan
dalam menemukan error dalam sistem arsitektur.
System demonstration
 Top-down integration testing
hanyamembatasipengujianpadaawaltahappengembanga
nsystem.
Test implementation
 Sering kali 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 yang tidak valid tentang
interface tsb.
• Sangat
penting
untuk
pengujian
terhadap
pengembangan sistem dgn menggunakan pendekatan
object-oriented yg didefinisikan oleh object-objectnya
Pengujian Aplikasi Server
 Volume Testing
 Stress Testing
 Performance Testing
 Data Recovery Testing
 Data Backup dan Restore Testing
 Data security Tetsing
Volume Testing
 Menemukan kelemahan sistem selama melakukan
pemrosesan data dalam jumlah yang
besardalamperiode waktuyang singkat.
 Tujuan: meyakinkan bahwa sistem tetap melakukan
pemrosesan data anatar batasan fisik dan batasan
logik.
 Contoh:Mengujikan proses antar server dan antar
partisihardisik pd satu server
Strees 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 sistemdown.
 Contoh: Melakukan login ke server ketika sejumlah
besarworkstation melakukan proses menjalankan
perintah sql database
Soal Latihan
 Lakukan diskusi pada sistem yang kalian buat dengan
menentukan beberapa skenario pengujian pada
Volume dan strees testing.
 Buatlah Daftar List untuk Unit testing.
Lukman Hakim
Pendahuluan
 Proses V&V harus mendemonstrasikan bahwa sistem
memenuhi spesifikasinya dan bahwa layanan dan prilaku
sistem mendukung persyaratan klien
 Sehingga diperlukan penambahan analisis dan pengujian
normal, karena :
 Biaya kegagalan  jauh lebih besar dari pada sistem non-kritis
 Validasi atribut tingkat dependabilitas  meyakinkan user
 Lebih dari 50% biaya pengembangan total utk sistem PL
kritis  agar kegagalan sistem yg mahal terhindari
 Contoh : kegagalan sistem PL dalam hal misi pada roket
Ariane 5 th 1996, yg mengakibatkan beberapa satelit rusak.
 Kualitas sistem dipengaruhi oleh kualitas proses yg dipakai
untuk mengembangkan sistem
Validasi Sistem Kritis
 Validasi terhadap reliability (keandalan), safety (keselamatan)
dan security (keamanan) bagi sistem berbasis komputer.
Validation perspectives
 Validasi Reliability/keandalan
 Apakah keandalan sistem telah sesuai dengan spesifikasinya?
 Apakah keandalan sistem telah memberikan kepuasan pada user
pemakai sistem?
 Validasi Safety/keselamatan
 Menjamin bahwa kecelakaan tidak akan terjadi atau bahwa
konsekuensi kecelakaan akan minimal.
 Validasi Security/keamanan
 Apakah sistem dan datanya aman terhadap serangan external?
Tekhnik Validasi
 Static techniques
 Review terhadap disain /inspeksi program
 Dynamic techniques
 Pengujian Statistik
 Pengujian berbasis skenario
 Pemeriksaan Run-time
 Process validation
 Desain
proses pembangunan yang meminimalkan
kemungkinan kesalahan dari proses sesuai dgn
dependibilitas
sistem
(keandalan,
ketersediaan,
keselamatan dan keamanan)
Static validation techniques
 Static validation lebih fokus pada analisa dokumentasi
sistem(persyaratan, disain, kode dan data uji)
 Fokus pada penemuan eror sistem dan identifikasi
permasalahan yg berpotensi muncul saat exekusi.
 Beberapa dokumen (argumen terstruktur, pembuktian
secara matematis, dll) dapat disiapkan utk
mendukung validasi statik
Static techniques for safety validation
 Menunjukkan keselamatan sistem melalui sebuah
pengujian merupakan sesuatu yg sulit
 Karena pengujian bertujuan utk menunjukkan apa yg
dilakukan sistem saat situasi normal.
 Tidak mungkin dilakukan pengujian thd setiap
kondisi operasional
Safety reviews
1.
2.
3.
4.
5.
Peninjauan thd Review for kebenaran function
Peninjauan thd maintainable, understandable
structure
Peninjauan thd algorithma dan disain struktur data
berdasarkan spesifikasi
Peninjauan thd konsistensi kode dgn algorithma dan
disain struktur data
Peninjauan thd kelayakan sistem pengujian
Review guidance
Buatlah software sesederhana mungkin
2. Gunakan teknik yg sederhana dlm pencegahan error
seperti
menghindari pemakaian pointers and
recursion
3. Gunakan information hiding (penyembunyian inf)
agar inf yg dsembunyikan tidak dirusak oleh
komponen
program
yg
tidak
seharusnya
menggunakannya
4. Gunakan teknik toleransi kesalahan yg sesuai ,
namun jangan pernah berfikir bahwa hasilnya
benar-benar aman
1.
Hazard-driven analysis
Efektif atau tidaknya jaminan keselamatan
bergantung pada identifikasi bahaya
2. Keselamatan dapat dijamin melalui
1.
•
•
•
Menghindari bahaya sistem pemotongan yg menuntut
operator agar menekan 2 tombol terpisah
Deteksi dan membuang bahaya deteksi tekanan
berlebihan dan pembukaan katup sebelum meledak pd
pabrik kimia
Membatasi kerusakan  pemadam api otomatis
3. Safety
review
(ulasan
keselamatan)
harus
menunjukkan bahwa satu atau lebih teknik ini telah
diterapkan untuk semua bahaya yg telah
diidentifikasi
The system safety case
Saat ini praktek formal untuk keselamatan menjadi
hal yang diperlukan untuk keselamatan semua
sistem berbasis komputer, misalnya isyarat rel kereta
api, pengendalian lalu lintas udara, dan lain-lain
2. Kasus keselamatan menyajikan daftar argumen,
berdasarkan bahaya yg teridentifikasi
3. Mengapa ada penerimaan yg rendah thd
kemungkinan bahwa bahaya ini tidak akan
mengakibatkan kecelakaan
4. Argumen dapat didasarkan pada bukti formal,
desain dasar, keselamatan bukti, dll. Faktor Proses
mungkin juga dimasukkan
1.
Formal methods and critical systems
 Pengembangan sistem kritis adalah salah satu
'keberhasilan' dari metode formal
 Di Inggris digunakan untuk pengembangan beberapa
jenis perangkat lunak keamanan untuk aplikasi
pertahanan
 Saat ini tidak ada perjanjian umum tentang nilai metode
formal dalam pengembangan sistem