Upload
lynhu
View
230
Download
0
Embed Size (px)
Citation preview
Teknik Informatika S1
Testing
Rekayasa Perangkat Lunak
1
Software Testing Objectives
Pengujian?
2
Software Testing Objectives
Pengujian adalah proses eksekusi program dengan
maksud menemukan kesalahan.
Sebuah test case yang baik adalah dengan probabilitas
tinggi untuk menemukan suatu yang belum ditemukan
kesalahan.
Sebuah tes yang sukses adalah menemukan kesalahan
yang belum ditemukan.
3
Strategic Approach to Software Testing
Pengujian dimulai pada tingkat komponen dan bekerja ke luar
menuju integrasi seluruh sistem yang berbasis komputer.
Teknik pengujian yang berbeda sesuai pada berbagai titik
dalam waktu tertentu.
Pengembang perangkat lunak melakukan pengujian dan dapat
dibantu oleh kelompok uji independen (ITG) untuk proyek-
proyek besar.
Pengujian dan debugging merupakan aktivitas yang berbeda.
* Debugging harus diakomodasi dalam strategi pengujian.
4
Verification and Validation
Verifikasi (are we building the product right?)
Validasi (are we building the right product?)
Pengujian Software adalah hanya salah satu unsur
Software Quality Assurance (SQA)
Kualitas harus dibangun untuk proses pembangunan,
Anda tidak dapat menggunakan pengujian untuk
menambah kualitas setelah fakta yang ada
5
Organizing for Software Testing
Peran Uji Kelompok Independen (ITG) adalah untuk menghilangkan konflik kepentingan yang melekat ketika pembangun sedang menguji produk sendiri.
Kesalahpahaman mengenai penggunaan tim pengujian independen o Pengembang harus melakukan pengujian yang tidak ada sama
sekali o Software dilempar "over the wall" kepada orang-orang untuk
menguji tanpa ampun o Penguji tidak terlibat dengan proyek ini sampai saatnya untuk
itu harus diuji
Para pengembang dan ITGC harus bekerja sama di seluruh proyek perangkat lunak untuk memastikan bahwa tes menyeluruh akan dilakukan
6
Software Testing Strategy for
Traditional Software Architectures
Unit Testing
Menitikberatkan pada penggunaan teknik pengujian aliran
kontrol tertentu untuk mendeteksi kesalahan dalam setiap komponen
perangkat lunak individual
Integration Testing
Berfokus pada isu-isu yang terkait dengan verifikasi dan
konstruksi program sebagai komponen yang berinteraksi satu sama
lain
7
Software Testing Strategy for
Traditional Software Architectures
Validation Testing
Memberikan jaminan bahwa kriteria validasi perangkat lunak
(selama analisis kebutuhan) memenuhi semua persyaratan fungsional,
perilaku, dan kinerja
System Testing
Memverifikasi bahwa semua elemen sistem berjalan dengan
benar dan bahwa fungsi sistem secara keseluruhan dan kinerja yang
telah dicapai
8
Strategic Testing Issues
Tentukan persyaratan produk secara kuantitatif sebelum
pengujian dimulai.
Tentukan tujuan pengujian secara eksplisit.
Mengidentifikasi kategori pengguna untuk perangkat
lunak dan mengembangkan profil untuk masing-masing.
Mengembangkan rencana tes yang menekankan pengujian
siklus yang cepat.
9
Strategic Testing Issues
Membangun perangkat lunak yang kuat yang dirancang
untuk menguji dirinya sendiri.
Gunakan bahasa formil efektif sebagai filter sebelum
pengujian.
Melakukan tinjauan teknis formal untuk menilai strategi
tes dan uji kasus.
Mengembangkan pendekatan perbaikan terus-menerus
untuk proses pengujian.
10
Unit Testing
Interface modul diuji untuk aliran informasi yang tepat.
Data lokal diperiksa untuk memastikan bahwa integritas
dipertahankan.
Kondisi batas diuji.
Dasar (independen) jalur diuji.
Semua jalur penanganan kesalahan harus diuji.
11
Integration Testing
Pengujian integrasi Top-down
Main control modul yang digunakan sebagai test driver dan stub
merupakan pengganti untuk komponen langsung bawahan untuk itu.
Rintisan bertopik bawahan diganti satu per satu dengan komponen
yang nyata (setelah depth-first atau breadth-first approach).
Pengujian dilakukan karena setiap komponen terintegrasi.
Setelah menyelesaikan setiap rangkaian tes dan rintisan lainnya
diganti dengan komponen nyata, pengujian regresi dapat digunakan
untuk memastikan bahwa kesalahan baru tidak diperkenalkan.
12
Integration Testing
Pengujian integrasi Bottom-up
Komponen tingkat rendah digabungkan ke dalam kelompok yang
melakukan fungsi perangkat lunak tertentu.
Program kontrol ditulis untuk mengkoordinasikan masukan kasus uji
dan output.
Cluster ini diuji.
Driver dihapus dan cluster dikombinasikan bergerak ke atas dalam
struktur program.
13
Integration Testing (2)
Pengujian regresi
Digunakan untuk memeriksa cacat disebarkan ke modul lain dengan
perubahan yang dibuat untuk program yang ada
Sampel yang representatif dari kasus uji yang ada digunakan untuk
melaksanakan semua fungsi perangkat lunak.
Kasus uji tambahan memfokuskan fungsi perangkat lunak mungkin
akan terpengaruh oleh perubahan itu.
Tes kasus yang berfokus pada komponen perangkat lunak berubah.
(baik top-down atau bottom integrasi dapat digunakan).
14
Integration Testing (2)
Smoke Testing
Komponen perangkat lunak yang sudah diterjemahkan ke dalam
kode diintegrasikan ke dalam untuk membangun.
Serangkaian tes yang dirancang untuk mengekspos kesalahan dari
fungsi yang diciptakan.
Pembangunan ini terintegrasi dengan yang lain.
15
General Software Test Criteria
Interface integrity
Interface modul internal dan eksternal diuji karena setiap
modul atau cluster ditambahkan ke perangkat lunak
Validitas fungsional
Tes untuk mengungkap cacat fungsional dalam perangkat lunak
Information content
Tes untuk kesalahan dalam struktur data lokal atau global
Performance
Batas kinerja tertentu diuji
16
Acceptance Testing
Memastikan perangkat lunak tersebut bekerja dengan
benar untuk pengguna dimaksudkan dalam lingkungan
kerja yang normal.
Pengujian Alpha - Versi perangkat lunak lengkap diuji
oleh pelanggan di bawah pengawasan pengembang di
situs pengembang
Pengujian beta - Versi perangkat lunak yang lengkap
diuji oleh pelanggan pada situs-nya sendiri tanpa
pengembang yang hadir
17
System Testing
Recovery testing
o Memeriksa kemampuan sistem untuk pulih dari kegagalan
Security testing
o Memverifikasi bahwa mekanisme perlindungan sistem mencegah
penetrasi yang tidak tepat atau terjadi perubahan data
18
System Testing
Stress testing
o Program diperiksa untuk melihat seberapa baik berkaitan dengan
tuntutan sumber daya yang abnormal (yaitu, jumlah, frekuensi,
atau volume)
Performance testing
o Dirancang untuk menguji kinerja run-time perangkat lunak,
khususnya perangkat lunak real-time
19
Debugging
Debugging (penghapusan cacat) terjadi sebagai
konsekuensi dari pengujian yang berhasil.
Beberapa orang lebih baik dalam debugging daripada
yang lain.
Pendekatan umum:
Brute force - dump memori dan jejak run-time diperiksa untuk
petunjuk penyebab kesalahan
Backtracking - kode sumber diperiksa dengan melihat mundur dari
gejala untuk potensi penyebab kesalahan
Cause elimination - menggunakan partisi biner untuk mengurangi
jumlah lokasi yang potensial (di mana kesalahan bisa eksis) 20
Pertimbangan Bug Removal
• Apakah penyebab bug direproduksi di bagian lain dari
program ini?
• Apa "bug berikutnya" mungkin diperkenalkan oleh
perbaikan yang diusulkan?
• Apa yang bisa dilakukan untuk mencegah bug ini di
tempat pertama?
21
Software Testability Checklist
Operability
Semakin baik kerja software semakin efisien untuk diuji
Observabilty
Apa yang Anda lihat adalah apa yang anda uji
Controllability
Perangkat lunak lebih baik dapat dikontrol lebih sehingga pengujian
dapat diotomatisasi dan dioptimalkan
Decomposability
Dengan mengontrol ruang lingkup pengujian, semakin cepat masalah
dapat diisolasi dan diuji ulang dengan cerdas
22
Software Testability Checklist
Simplicity
Semakin sederhana perangkat lunak, semakin cepat kita menguji
Stability
Semakin sedikit perubahan, semakin sedikit gangguan pengujian
Understandability
Semakin banyak informasi diketahui, semakin cerdas pengujian
23
Good Test Attributes
Sebuah tes yang baik memiliki probabilitas tinggi untuk
menemukan kesalahan.
Sebuah tes yang baik adalah tidak berlebihan.
Sebuah tes yang baik harus berkembang.
Sebuah tes yang baik tidak boleh terlalu sederhana
atau terlalu rumit.
24
Test Case Design Strategies
Black-box or behavioral testing
Mengetahui fungsi tertentu produk adalah untuk melakukan dan menunjukkan
operasi yang benar hanya berdasarkan spesifikasi tanpa memperhatikan logika
internal
White-box or glass-box testing
Mengetahui kerja internal suatu produk, tes dilakukan untuk memeriksa kerja dari
semua kemungkinan jalur logika
25
Test Case Design Strategies
White-box or glass-box testing (Struktural)
White box testing adalah pengujian yang didasarkan pada pengecekan
terhadap detail perancangan, menggunakan struktur kontrol dari desain
program secara procedural untuk membagi pengujian ke dalam beberapa
kasus pengujian. Secara sekilas dapat diambil kesimpulan white box testing
merupakan petunjuk untuk mendapatkan program yang benar secara 100%.
26
Test Case Design Strategies
Kelebihan White Box Testing
i. Kesalahan logika. Digunakan pada sintaks ‘if’ dan pengulangan. Dimana White Box Testing akan mendeteksi kondisi-kondisi yang tidak sesuai dan mendeteksi kapan proses pengulangan akan berhenti.
ii. Ketidaksesuaian asumsi. Menampilkan asumsi yang tidak sesuai dengan kenyataan, untuk di analisa dan diperbaiki.
iii. Kesalahan ketik. Mendeteksi bahasa pemrograman yang bersifat case sensitive.
Kelemahan White Box Testing Untuk perangkat lunak yang tergolong besar, White Box Testing dianggap sebagai strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar untuk melakukannya.
27
Test Case Design Strategies
Black-box or behavioral testing
Black box testing adalah pengujian yang dilakukan hanya mengamati hasil
eksekusi melalui data uji dan memeriksa fungsional dari perangkat lunak.
Jadi dianalogikan seperti kita melihat suatu kotak hitam, kita hanya bisa
melihat penampilan luarnya saja, tanpa tau ada apa dibalik bungkus hitam
nya. Sama seperti pengujian black box, mengevaluasi hanya dari tampilan
luarnya (interfacenya), fungsionalitasnya tanpa mengetahui apa
sesungguhnya yang terjadi dalam proses detilnya (hanya mengetahui input
dan output). 28
Test Case Design Strategies
Kelebihan Black-box or behavioral testing
i. Dapat memilih subset test secara efektif dan efisien
ii. Dapat menemukan cacat
iii. Memaksimalkan testing investment
Kelemahan Black-box or behavioral testing
Tester tidak pernah yakin apakah PL tersebut benar – benar lulus uji.
29
TERIMA KASIH
30