Transcript - JULIAN SUPARDI

JULIAN SUPARDI
 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 testcase 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:
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.
1.
 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 // akan
dilanjutkan 2 Maret 2012
 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 kuat
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 seberapa kuat
serangkaian pengujian tertentu akan mencakup
produk.
Cheklist
Checklist berikut ini memberikan serangkaian
karakteristik yang membawa kepada PL yang
dapat diuji.
Operabilitas:
semakin baik PL bekerja, semakin efisien PL
dapat diuji.
2. Observabilitas:
apa yang anda lihat adalah apa yang diuji.
1.
1.
Operabilitas:
Sistem memiliki beberapa bug (bug menambah
analisis dan biaya pelaporan ke proses
pengujian)
Tidak ada bug yag memblok eksekusi pengujian
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.
2.
3.
4.
Pengujian yang baik memiliki probabilitas yang
tinggi untuk menemukan kesalahan.
Pengujian yang baik tidak redundan.
Pengujian yang baik seharusnya jenis terbaik.
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