Chapter 10
Overview
Elemen kritis dari jaminan kualitas Software Merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean Meningkatnya visibilitas Software sbg suatu elemen sistem dan biaya yg muncul akibat kegagalan Software Suatu hal yg wajar bagi suatu organisasi pengembang Software u/ meningkatkan 30 s/d 40 % usaha proyek total pd tahap pengujian Teknik pengujian Software a/ membahas dasar dan teknik pengujian Software u/ desain test case Software
Dasar dan teknik pengujian Software Dasar-dasar pengujian Software menentukan sasaran penolakan bagi pengujian Software Desain test case berfokus pada serangkaian teknik u/ pembuatan test case yang memenuhi keselurahan sasaran pengujian Strategi mengenai pengujian dan debugging Software a/ dibahas pada chapter selanjutnya
Perekayasa menciptakan sederetan test case yang dimaksudkan u/ membongkar Software yang sudah dibangun
Sasaran-sasaran pengujian Prinsip pengujian Testabilitas
Sasaran-sasaran pengujian
Dalam buku klasiknya mengenai pengujian Software, Glen Myers menyatakan sejumlah aturan yg berfungsi sebagai sasaran pengujian: Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan Test case yang baik adalah test case yang memiliki probabilitas tinggi u/ menemukan kesalahan yang belum pernah ditemukan sebelumnya Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya
1.
2.
3.
Prinsip pengujian
Sebelum mengaplikasikan metode u/ mendesain test case yang efektif, perekayasa Software harus memahami prinsip dasar yang menuntun pengujian Software. Davis mengusulkan serangkaian prinsip pengujian yang telah diadaptasi u/ digunakan dalam buku ini: Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan Pengujian harus direncanakan lama sebelum pengujian itu dimulai Prinsip pareto berlaku u/ pengujian Software. Prinsip pareto mengimplikasikan bahwa 80 % dari semua kesalahan yang ditemukan selama pengujian sepertinya akan dapat ditelusuri sampai 20 persen dari semua modul program Pengujian harus mulai dari yang kecil dan berkembang ke pengujian yang besar Pengujian yang mendalam tidak mungkin u/ menjadi paling efektif, pengujian harus dilakukan o/ pihak ketiga
Testabilitas
Seberapa mudah sebuah program komputer dapat diuji Beberapa checklist yang memberikan serangkaian karakteristik yang membawa kepada Software yang dapat diuji Operabilitas. semakin baik dia bekerja, semakin efisien dia dapat diuji Observabilitas. apa yang anda lihat adalah apa yang anda uji Kontrolabilitas. semakin baik kita dapat mengontrol Software, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan Dekomposabilitas. dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih halus Kesederhanaan. semakin sedikit yang diuji, semakin cepat kita mengujinya Stabilitas. semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian Kemampuan u/ dapat dipahami. semakin banyak informasi yang kita miliki, semakin halus pengujian yang akan dilakukan
1.
2.
3.
4.
1.
2. 3. 4.
Teknik pengujian white box yang diusulkan pertama klai o/ Tom McCabe Metode basis path ini memungkinkan desainer test case mengukur kompleksitas logis dari desain prosedural dan menggunakannya sebagai pedoman u/ menetapkan basis set dari jalur eksekusi Beberapa metode basis path yang biasa digunakan u/ pengujian basis path antara lain: Notasi Diagram Alir/ Grafik program [aliran kontrol logika yang menggunakan notasi] Kompleksitas Siklomatis [metriks Software yang memberikan pengukuran kuantitatif terhadap kompleksitas logis suatu program] Melakukan test case [lebih kepada desain prosedural/ kode sumber] Matrik grafik [stuktur data yang diumpamakan sebagai matrik grafis]
1. 2. 3. 4. 5.
Pengujian black box berusaha menemukan kesalahan dalam kategori seperti: Fungsi-fungsi yang tidak benar / hilang Kesalahan interface Kesalahan dalam struktur data/ akses database eksternal Kesalahan kinerja Inisialisasi dan kesalahan terminasi
Objek #1 = new file menu select Objek #2 = document window Objek #3 = document text seperti pada gambar, pemilihan menu New File menghasilkan Document Window. Node weight dari document window memberikan daftar atribut window tersebut yang akan diharapkan pada saat window dimunculkan link tak terarah membangun hubungan simetris di antara new file select menu dan document text
Partisi Ekivalensi
Adalah metode pengujian black box yang membagi domain input dari suatu program ke dalam kelas data dari mana test case dapat dilakukan Desain test case u partisi ekivalensi didasarkan pada evaluasi terhadap kelas ekivalensi u/ suatu kondisi input Secara khusus, suatu kondisi input dapat berupa harga numeris, suatu rentang harga, atau serangkaian harga terkait, atau sebuah kondisi boolean
Studi kasus Software yang dipasok u/ aplikasi perbankan menerima data dalam bentuk:
Kode area kosong / tiga nomor digit Prefik tiga nomor digit tidak dimulai dengan 1 atau 0 Sufik empat nomor digit Password enam nilai digit Perintah cek, deposit dll
Kondisi input yang sesuai dengan masing-masing elemen data u/ aplikasi perbankan dapat ditentukan sebagai: Kode area: boolean kode area mungkin / tidak mungkin range nilai yang ditentukan antara 200 dan 999 Prefiks: range harga yang ditetapkan > 200 dengan tanpa digit 0 Sufik: harga panjang empat digit Password: boolean password ada / tidak ada harga antrian enam karakter Perintah: himpunan berisi perintah yang sudah ditulis di atas
1. 2. 3. 4.
Saat Software komputer menjadi kompleks, maka kebutuhan akan pendekatan pengujian yang khusus juga makin berkembang Pada metode ini akan dibahas pedoman pengujian bagi lingkungan, arsitektur, dan aplikasi khusus yang umumnya ditemui oleh para Software engineering seperti: Pengujian GUI Pengujian Arsitektur Client/Server Pengujian Dokumnetasi dan Fasilitas Help Pengujian Sistem Real Time
Pengujian GUI
GUI menyajikan tantangan menarik bagi para engineer Karena komponen reusable berfungsi sebagai bagian dari lingkungan pengembangan GUI, pembuatan interface pemakai telah menjadi hemat waktu dan lebih teliti Di sisi lain saat kompleksitas GUI telah berkembang, menimbulkan kesulitan yang lebih besar di dalam desain dan eksekusi test case Karena GUI modern memiliki bentuk dan cita rasa sama, maka dapat dilakukan sederetan pengujian standar
Pertanyaan-pertanyaan yang dapat berfungsi sebagai panduan untuk serangkaian pengujian generik untuk GUI:
Untuk Windows: Apakah window akan membuka secara tepat berdasarkan tipe yang sesuai / perintah berbasis menu? Dapatkah window di resize, moving / scrolling? Apakah semua isi data yang diisikan pada window dapat dituju dengan tepat dengan sebuah mouse, function keys, anak panah penunjuk dan keyboard? Apakah window dengan cepat muncul kembali bila window lain dibuka dan kemudian dipanggil kembali Apakah semua fungsi yang berhubungan dengan window dapat diperoleh bila diperlukan? Apakah semua fungsi yang berhubungan dengan window operasional? Apakah semua menu pull-down, tool bar, scroll bar, kotak dialog, tombol, ikon, dan kontrol yang lain dapat diperoleh dan dengan tepat ditampilkan untuk window tersebut? Pada saat window bertingkat ditampilkan, apakah nama window tersebut direpresentasikan secara tepat? Apakah window yang aktif disorot secara tepat? Bila multitasking digunakan, apakah semua window diperbaruhi pada waktu yang sesuai? Apakah pemilihan mouse bertingkat / tidak benar di dalam window menyebabkan efek samping yang tidak diharapkan? Apakah audio prompt dan atau color prompt ada di dalam window atau sebagai konsekuensi dari operasi window disajikan menurut spesifikasi? Apakah window akan menutup secara tepat?
Untuk menu pull-down dan operasi mouse Apakah menu bar yang sesuai ditampilkan di dalam konteks yang sesuai? Apakah menu bar aplikasi menampilkan fitur-fitur yang terkait dengan sistem (misalnya tampilan jam)? Apakah operasi menu pull-down bekerja secara tepat? Apakah menu breakway, palette, dan tool bar bekerja secara tepat? Apakah semua fungsi menu dan subfungsi pull-down didaftar secara tepat? Apakah semua fungsi menu dapat dituju secara tepat oleh mouse? Apakah typeface, ukuran dan format teks benar? Mungkinkah memanggil masing-masing fungsi menu dengan menggunakan perintah berbasis teks alternatif? Apakah fungsi menu disorot (atau ada warna lain) berdasarkan konteks operasi yang sedang berlangsung di dalam suatu window? Apakah semua menu function bekerja seperti yang diiklankan? Apakah nama-nama menu function bersifat self-explanatory? Apakah help dapat diperoleh untuk masing-masing item menu, apakah dia sensitif terhadap konteks? Apakah operasi mouse dikenali dengan baik pada seluruh konteks iteratif? Bila klik ganda diperlukan, apakah operasi dikenali didalam konteks? Jika mouse mempunyai tombol ganda, apakah tombol itu dikenali sesuai konteks? Apakah cursor, indikator pemrosesan (misalnya, sebuah jam / hour glass), dan pointer secara tepat berubah pada saat operasi yang berbeda dipanggil?
Entri data - Apakah entri data selain alfanumeric dipantulkan dan diinput ke sistem? - Apakah mode grafik dari entri data (seperti slide bar) bekerja dengan baik? - Apakah data invalid dikenali dengan baik? - Apakah pesan input data cukup smart?
Conclusion
Sasaran utama desain test case adalah u/ mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam mencari error di dalam Software u/ mencapai sasaran tersebut, digunakan dua kategori yang berbeda dari teknik desain test case yaitu pengujian white box dan pengujian black box
Pengujian white box berfokus pada struktur kontrol program Test case dilakukan untuk memastikan bahwa semua statement pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji Pengujian basis path, teknik pengujian white box, menggunakan grafik program (matrik grafik) untuk melakukan serangkaian pengujian yang independen secara linier yang akan memastikan cakupan Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program, dan pengujian loop menyempurnakan teknik white box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi
Pengujian black box didesain untuk mencari error pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program Teknik pengujian black box berfokus pada domain informasi dari Software, dengan melakukan test case dengan mempartisi domain input dan output dari suatu program dengan cara memberikan cakupan pengujian yang mendalam Metode pengujian graph based mengeksplorasi antara hubungan dan tingkah laku objek-objek program Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi Software tertentu Analisis nilai batas memeriksa kemampuan program untuk menangani data pada batas yang dapat diterima
Required Reading
Roger S. Pressman, Ph.D, Software Engineering On web Software Technical Testing