Perguruan Tinggi ASIA

Chapter 10

Software Technical Testing

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

Dasar dasar pengujian Software

Pada dasarnya, pengujian merupakan salah satu langkah pada proses Software yg dapat dianggap sbg hal yang destruktif daripada konstruktif

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

Desain test case

Metode desain test case yang telah berkembang u/ Software yaitu black box dan white box Metode-metode tersebut memberikan kepada pengembang sebuah pendekatan yang sistematik ke pengujian Yang lebih utama metode itu memberikan mekanisme yang dapat membantu memastikan kelengkapan pengujian dan memberikan kemungkinan tertinggi u/ mengungkap kesalahan pada Software

Pengujian white box

Pengujian white box atau biasa disebut pengujian glass box Metode desain test case yang menggunakan struktur kontrol desain prosedural u/ memperoleh test case Dengan white box engineer dapat melakukan test case yang: Memberikan jaminan bahwa semua jalur independen pada suatu modul telah digunakan paling tidak satu kali Menggunakan semua keputusan logis pada sisi true dan false Mengeksekusi semua loop pada batasan mereka dan pada batas operasional mereka Menggunakan struktur data internal u/ menjamin validitas

1.
2.

3.
4.

Pengujian basis path

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]

Pengujian Struktur Kontrol

Teknik pengujian basis path yang sudah dibahas sebelumnya merupakan salah satu contoh pengujian struktur kontrol Meski pengujian basis path sederhana dan sangat efektif, tetapi kurang memadai Pengujian struktur kontrol ini diharapkan bisa meningkatkan kualitas pengujian white box

Beberapa pengujian struktur kontrol yang bisa digunakan antara lain:

Pengujian kondisi sebuah metode desain test case yang menggunakan kondisi logis yang ada pada suatu program Pengujian aliran data metode ini memilih jalur pengujian dari suatu program sesuai dengan lokasi definisi dan menggunakan variabel-variabel pada program Pengujian Loop first stone u/ mayoritas algoritma yang diimplementasikan pada Software. Pengujian Loop merupakan teknik pengujian white box yang secara eksklusif berfokus pada validitas konstruksi loop

Definisi dari empat kelas loop yang berbeda:

Loop Sederhana Loop Tersarang Loop Terangkai Loop Tidak Terstruktur

Pengujian Black Box

Pengujian ini berfokus pada persyaratan fungsional Software Pengujian Black Box memungkinkan Software engineer mendapatkan serangkaian kondisi input yang sepenuhnya menggunakan semua persyaratan fungsional u/ suatu program Pendekatan komplementer yang memungkinkan besar mampu mengungkap kesalahan dari metode white box Tidak seperti pengujian white box yang dilakukan pada saat awal proses pengujian, pengujian black box cenderung diaplikaskan selama tahap akhir pengujian


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

Metode pengujian Graph-Based

Langkah pertama pada pengujian black box adalah memahami objek yang dimodel di dalam Software dan hubungan yang a/ menghubungkan objek tersebut Langkah selanjutnya menentukan sederetan pengujian yang membuktikan bahwa semua objek memiliki hubungan yang diharapkan satu dengan yang lainnya u/ melakukan langkah tersebut engineer memulainya dengan membuat suatu grafik- sekumpulan simpul yang merepresentasikan objek; link yang merepresentasikan hubungan antar objek; node weight yang menggambarkan properti dari suatu simpul (mis. Nilai data tertentu/ tingkah laku keadaan), dan weight yang menggambarkan beberapa karakteristik suatu link Simpul grafik program yang berisi instruksi (objek program) menandai representasi desain prosedural/ kode sumber Dan link terarah menunjukkan aliran kontrol diantara objek-objek program ini.

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

Metode pengujian Black box yang lain:

Analisis Nilai Batas/ Boundary Value Analysis: Teknik desain proses yang melengkapi partisi ekivalensi. BVA lebih mengarah kepada pemilihan test case edge dari kelas Pengujian Perbandingan/ pengujian back to back: setiap versi dapat diuji dengan data uji yang sama untuk memastikan bahwa semua versi memberikan output yang identik

Pengujian untuk aplikasi dan lingkungan khusus

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?

Pengujian Arsitektur Client/Server

Sifat terdistribusi dari lingkungan Client/Server? Masalah kinerja yang berhubungan dengan pemrosesan transaksi? Penambahan sejumlah platform perangkat keras yang berbeda? Kompleksitas komunikasi jaringan? Kebutuhan akan layanan client multipel dari suatu database terpusat? Persyaratan koordinasi yang dibebankan pada server?

Pengujian Dokumentasi dan Help

Kegunaan program ditelusuri pada seluruh dokumen Apakah dokumen tersebut secara akurat menggambarkan bagaimana menyelesaikan masing-masing mode penggunaan? Apakah deskripsi dari masing-masing urutan interaksi akurat? Apakah contoh-contoh akurat? Apakah terminologi, gambaran menu dan respon sistem konsisten dengan program aktual? Apakah relatif mudah untuk menempatkan panduan di dalam dokumentasi? Dapatkah trouble shooting dilakukan dengan mudah melalui dokumentasi? Apakah tabel dokumen dari isi dan indeks akurat dan lengkap? Apakah desain dokumen (layout, typeface, dll) kondusif untuk pemahaman dan asimilasi cepat terhadap informasi? Apakah semua pesan kesalahan ditampilan bagi pemakai dan digambarkan secara lebih detail di dalam dokumen? Bila link hiperteks digunakan, apakah mereka akurat dan lengkap?

Pengujian Sistem Real Time

1. 2. 3. 4. Untuk aplikasi real time metode desain test case yang komprehensif harus berkembang. Empat strategi yang dapat diusulkan antara lain: Pengujian tugas Pengujian tingkah laku Pengujian antar tugas Pengujian sistem Sifat asinkron dan tergantung waktu yang ada pada banyak aplikasi menambah elemen baru yang sulit dan potensial untuk bauran pengujian-waktu Sebagian besar sistem real time memproses interupsi, karena itu pengujian penanganan terhadap kejadian-kejadian boolean ini merupakan hal penting. Kemudian pengujian didesain untuk menilai karakteristik sistem berikut ini: Apakah prioritas interupsi ditetapkan dan ditangani secara tepat? Apakah pemrosesan untuk masing-masing interupsi ditangani dengan tepat? Apakah kinerja (misal waktu proses) dari masing-masing prosedur penanganan interupsi sesuai dengan persyaratan? Apakah volume interupsi yang tinggi yang terjadi pada waktu kritis menimbulkan masalah di dalam fungsi / kinerja?

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