Rekayasa Perangkat Lunak
Teknik Pengujian Perangkat Lunak
• Pengembangan sistem perangkat lunak
melibatkan sederetan aktivitas produksi di mana peluang terjadinya kesalahan manusia sangat besar.
• Kesalahan dapat mulai terjadi pada permulaan proses di mana sasaran ditetapkan secara tidak sempurna, kemudian dalam disain dan tahapan pengembangan selanjutnya.
• Karena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan
sempurna, maka pengembangan perangkat lunak harus selalu diiringi dengan aktivitas jaminan kualitas.
• Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas PL, dan mempresentasikan kajian pokok dari spesifikasi, desain, dan
pengkodean.
• Dengan meningkatnya visibilitas
perangkat lunak sebagai suatu elemen sistem,dan
• Biaya yang muncul akibat kegagalan perangkata lunak, maka
• memotivasi dilakukakannya perencanaan
yang baik melalui pengujian yang teliti.
• Hal Wajar:
Organisasi pengembangan PL
meningkatkan 30 – 40 % usaha proyek pengembangan PL pada
TAHAP PENGUJIAN.
Test-Case PL
• Yang dibahas pada Kuliah:
Dasar dan teknik Perangkat Lunak untuk
disain test-case suatu PL.
• Dasar-dasar pengujian PL menentukan sasaran penolakan bagi pengujian PL.
• Disain Test-case berfokus pada
serangkain teknik untuk pembuatan test- case yang memenuhi keseluruhuan
sasaran pengujian.
Dasar-dasar Pengujian PL
• Pengujian menyajikan anomali yang menarik bagi perekayasa PL.
• Pada proses rekayasa PL, perekayasa pertama- tama berusaha membangun PL dari konsep
abstrak ke implementasi yang dapat dilihat, baru kemudian dilakukan pengujian.
• Perekayasa menciptkan sederetan test-case
yang dimaksudkan untuk membongkar PL yang sudah dibangun.
• Pada dasarnya,
pengujian merupakan satu langkah dalam proses
rekayasa PL yang dapat dianggap (secara psikologis) sebagai hal yang destruktif daripada konstruktif.
• Haruskah pengujian peninggalkan rasa bersalah pada pengembang PL?
• Apakah pengujian benar-benar bersifat merusak?
Jawaban untuk 2 pertanyaan tersebut adalah “TIDAK”.
SASARAN PENGUJIAN
• Glen Myers tahun 79, menyatakan sejumlah aturan yang berfungsi sebagai sasaran pengujian:
1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan.
2. Test-case yang baik adalah test-case yang memiliki probabilitas untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya.
3. Pengujian yang sukses adalah pengujian yang
mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya.
• Sasaran Pengujian tersebut mengimplikasikan adanya perubahan titik pandang yang dramatis.
• Sasaran berlawanan dengan pandangan yang biasanya dipegang: bahwa pengujian yang berhasil adalah adalah pengujian yang tidak ada kesalahan yang ditemukan.
• Sasaran kita adalah mendisain pengujian yang secara sistematis mengungkap kelas kesalahan yang berbeda dan melakukannya dengan jumlah waktu dan usaha minimum.
• Bila pengujian dilakukan secara sukses (sesuai dengan sasaran), maka akan ditemukan kesalahan di dalam
perangkat lunak.
• Sebagai keuntungan sekunder, pengujian menunjukkan bahwa fungsi perangkat lunak bekerja sesuai dengan
spesifikasi dan bahwa persyaratan kinerja telah dipenuhi.
• Sebagai tambahan, data yang dikumpulkan pada saat pengujian dilakukan, memberikan indikasi yang baik mengenai reliabilitas perangkat lunak dan beberapa menunjukkan kualitas perangkat lunak secara
keseluruhan.
• Tetapi ada satu hal yang tidak dapat dilakukan oleh pengujian, yaitu:
• Pengujian tidak dapat memperlihatkan tidak adanya cacat.
• Pengujian hanya dapat memperlihatkan bahwa ada kesalahan Perangkat Lunak.
Prinsip Pengujian
• Sebelum mengaplikasikan metode untuk mendisain test-case yang efektif,
perekayasa PL harus memahami prinsip dasar yang menuntun pengujian PL.
• Davis, tahun 1995, mengusulkan
serangkaian prinsip pengujian yang telah
diadaptasi untuk digunakan pada kuliah
ini, yaitu:
Prinsip Pengujian (1)
Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.
• Sebagaimana telah diketahui, sasaran pengujian PL adalah untuk mengungkap kesalahan.
• Hal ini memenuhi kriteria bahwa cacat yang paling fatal (dari titik pandang pelanggan) adalah cacat yang menyebabkan program gagal memenuhi persyaratannya.
Prinsip Pengujian (2)
Pengujian harus direncanakan lama sebelum pengujian itu mulai.
• Perencanaan pengujian dapat mulai segera setelah model persyaratan dilengkapi.
• Definisi detil mengenai test-case dapat dimulai segera setelah model disain diteguhkan. Dengan demikian semua pengujian dapat direncanakan dan dirancang sebelum semua kode dibangkitkan.
Prinsip Pengujian (3)
Pengujian harus mulai dari yang kecil dan berkembang ke pengujian yang besar.
• Pengujian pertama yang direncanakan dan dieksekusi biasanya berfokus pada modul program individual.
• Selagi pengujian berlangsung maju, pengujian mengubah fokus dalam usaha menemukan
kesalahan pada cluster model yang terintegrasi, dan akhirnya pada sistem secara keseluruhan.
Prinsip Pengujian (4)
Pengujian yang mendalam tidaklah mungkin.
• Jumlah jalur permutasi untuk program yang
berukuran menengahpun sangat besar. Karena itulah maka tidak mungkin mengeksekusi setiap kombinasi jalur skema pengujian.
• Tetapi dimungkinkan untuk secara adekuat mencakup logika program dan memastikan
bahwa semua kondisi dalam disain prosedural telah diuji.
Prinsip Pengujian (5)
• Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independen.
• Yang dimaksudkan dengan kata yang paling efektif adalah pengujian yang memiliki
probabilitas tertinggi di dalam menemukan kesalahan (sasaran utama pengujian).
• Perekayasa perangkat lunak yang membuat sistem bukanlah orang yang paling tepat untuk melakukan semua pengujian bagi perangkat lunak.
Testabilitas
Dalam lingkungan yang ideal, perekayasa PL mendesain suatu program komputer, sebuah sistem, atau suatu produk dengan
“testabilitas” di dalam pikirannya.
Hal ini memungkinkan individu yang
berurusan dengan pengujian mendisain
test-case yang efektif secara lebih mudah.
Tetapi apakah testabilitas itu?
James Bach menggambarkan testabilitas dengan cara berikut:
Testabilitas PL secara sederhana adalah seberapa mudah sebuah program
komputer dapat diuji.
Karena pengujian sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya
menjadi mudah.
Kadang2 pemrogram bersedia melakukan hal-hal yang yang akan membantu proses pengujian, dan checklist mengenai masalah2 disain yang mungkin, fitur, dlsb, dapat menjadi berguna
dalam bernegosiasi dengan mereka.
Ada metrik yang dapat digunakan untuk mengukur testabilitas di dalam sebagian besar aspeknya.
Testabilitas digunakan untuk melihat melihat
seberapa adekuat serangkaian pengujian
tertentu akan mencakup produk.
Cheklist
Checklist berikut ini memberikan serangkaian
karakteristik yang membawa kepada PL yang dapat diuji.
1. Operabilitas:
semakin baik PL bekerja, semakin efisien PL dapat diuji.
2. Observabilitas:
apa yang anda lihat adalah apa yang diuji.
1. Operabilitas:
Sistem memiliki beberapa bug (bug menambah analisis dan biaya pelaporan ke proses
pengujian)
Tidak ada bug yag memblok eksekusi pengajian
Produk berkembang di dalam tahapan
funsgional (memungkinkan pengembangan dan pengujian secara simultan).
2. Observabilitas:
-Output yang berbeda dikeluarkan oleh masing-masing input.
-Tahap dan variabel sistem dapat dilihat atau diartikan selama eksekusi.
-Sistem dan variable yang lalu dapat dilihat atau diartikan (misalnya, log transaksi)
-Semua faktor yang mempengaruhi output dapat dilihat.
-Output yang tidak benar dapat diidentifikasikan sengan mudah.
-Kesalahan internal dideteksi secara otomatis melalui mekanisme self-testing.
-Kesalahan internal dilaporkan secara otomatis.
-Kode sumber dapat diakses.
Checklist
3. Kotrolabilitas:
semakin baik kita dapat mengontrol PL, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan.
4. Dekomposabilitas:
dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi
masalah dan melakukan pengujian kembali secara lebih halus.
3. Kontrobilitas:
-Semua output yang mungkin dapat dimunculkan melalui beberapa kombinasi output.
-Semua kode dapat dieksekusi melalui berbagai kombinasi input.
-Keadaan dan variable perangkat lunak dan perangkat keras dapat dikontrol secara langsung oleh perekayasa pengujian.
-Format input dan output konsisten dan terstruktur.
-Pengujian dapat dispesifikasi, dioptimasi, dan direproduksi dengan baik.
4. Dekomposabilitas:
-Sistem perangkat lunak dibangun dari modul-modul independen.
-Modul-modul perangkat lunak dapat diuji
secara independen.
Checklist
5. Kesederhanaan:
semakin sedikit yang diuji, semakin cepat kita dapat mengujinya.
6. Stabilitas:
semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian.
7. Kemampuan untuk dapat dipahami:
semakin banyak informasi yang kita miliki,
semakin halus pengujian yang akan dilakukan.
5. Kesederhanaan:
-Kesederhanaan fungsional (seperti, kumpulan fitur adalah kebutuhan minimum untuk
memenuhi persyaratan)
-Kesederhanaan struktural (seperti, arsitektur dimodularisasi untuk membatasi penyebaran kesalaha)
-Kesederhanaan kode (seperti, standar
pengkodean diadopsi demi kemudahan inspeksi dan pemeliharaan)
6. Stabilitas:
-Perubahan ke PL tidak sering.
-Perubahan ke PL terkontrol.
-Perubahan ke PL memvalidasi pengujian yang sudah ada.
-Kegagalan PL dapat diperbaiki dengan
baik.
7. Kemampuan untuk dapat dipahami.
-Disain dipahami dengan baik
-Ketergantungan di antara komponen internal,
eksternal, dan yang dipakai bersama, dipahami dengan baik.
-Perubahan ke disain dikomunikasikan.
-Dokumentasi teknik dapat diakses dengan cepat.
-Dokumentasi teknis diorganisasikan dengan baik.
-Dokumentasi teknis spesifik dan detil.
-Dokumentasi teknis akurat.
• Atribut-atribut yang disusulkan James Bach tersebut dapat digunakan oleh
perekayasa PL untuk mengembangkan
suatu konfigurasi PL (yakni program, data, dokumen, dll) yang dapat
dipertanggungjawabkan pada pengujian.
Bagaimana dengan pengujian itu sendiri?
1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan
kesalahan.
2. Pengujian yang baik tidak redundan.
3. Pengujian yang baik seharusnya jenis terbaik.
4. Pengujian yang baik tidak boleh terlalu
sederhana atau terlalu kompleks.
Bagaimana dengan pengujian itu sendiri?
Kaner tahun 1993 mengusulkan atribut2 dari pengujian yang baik sbb:
1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.
Untuk mencapai hal ini, penguji harus memahami PL dan berusaha mengembangkan gambaran mental mengenai bagaimana PL dapat gagal. Idealnya kelas-kelas
kegagalan itu diselidiki.
Sebagai contoh, kelas kegagalan potensial pada GUI adalah kegagalan untuk mengenali posisi mouse yang sesuai. Serangkaian pengujian akan dirancang untuk
menguji mouse untuk memperlihatkan kesalahan di dalam pengenalan posisi mouse.
2. Pengujian yang baik tidak redundan.
Waktu pengujian dan sumber daya terbatas. Tidak ada
manfaatnya melakukan pengujian dengan tujuan yang sama dengan pengujian lainnya. Setiap pengujian harus memiliki
tujuan yang berbeda (bahkan meskipun benar-benar berbeda).
Sebagai contoh, modul PL Safe-Home didisain untuk mengenali password pemakai untuk mengaktifkan dan mendeaktifkan
sistem. Dalam usaha mengungkap kesalahan pada input password, penguji mendisain serangkaian pengujian yang
memasukkan serangkaian password. Password yang berlaku dan tidak berlaku (empat urutan numeris) diinputkan sebagai pengujian yang berbeda. Tetapi masing-masing password
valid/invalid harus memeriksa mode kegagalan yang berbeda.
Sebagai contoh, password invalid 1234 tidak boleh diterima oleh sistem yang diprogram untuk mengenali 8080 sebagai password yang valid. Bila 1234 diterima, maka kesalahan muncul.
Pengujian yang lain, katakanlah 1235, akan memiliki tujuan yang sama dengan 1234 sehingga redundan. Tetapi input invalid 8081 atau 8180 memiliki perbedaan yang jelas, yang bersusaha
memperlihatkan bahwa suatu kesalahan akan muncul untuk password yang dekat tetapi tidak sama dengan password valid.
3. Pengujian yang baik seharusnya jenis terbaik.
Dalam suatu kelompok pengujian yang memiliki tujuan yang serupa, batasan waktu dan sumber daya dapat menghalangi eksekusi hanya
kelompok kecil dari pengujian tersebut. Pada kasus semacam ini maka pengujian yang
memiliki kemungkinan paling besar untuk mengungkap seluruh kelas kesalahan yang tinggi yang harus digunakan.
4. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks.
Meskipun kadang-kadang mungkin untuk menggabungkan serangkaian pengujian ke dalam satu test-case, secara umum
masing-masing test-case harus dieksekusi
secara terpisah.
• Pengujian perangkat lunak merupakan
– proses eksekusi suatu program dengan maksud menemukan kesalahan
– elemen kritis dalam jaminan kualitas perangkat lunak
– aktifitas yang mempresentasikan kajian pokok dari spesifikasi, disain dan
pengkodean
