Rekayasa Perangkat Lunak Teknik Pengujian Perangkat Lunak By : Afijal. M.Kom
• 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 testcase yang memenuhi keseluruhuan sasaran pengujian.
Dasar-dasar Pengujian PL • Pengujian menyajikan anomali yang menarik bagi perekayasa PL. • Pada proses rekayasa PL, perekayasa pertamatama 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
