Download - Metode Uji Program [Galih]

Transcript
  • Galih Nur Faturrachman201210225126

    Software Technical Testing

  • Overview Elemen kritis dari jaminan kualitas Software Merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodeanMeningkatnya visibilitas Software sbg suatu elemen sistem dan biaya yg muncul akibat kegagalan SoftwareSuatu hal yg wajar bagi suatu organisasi pengembang Software u/ meningkatkan 30 s/d 40 % usaha proyek total pd tahap pengujianTeknik pengujian Software a/ membahas dasar dan teknik pengujian Software u/ desain test case Software

  • Dasar dan teknik pengujian SoftwareDasar-dasar pengujian Software menentukan sasaran penolakan bagi pengujian SoftwareDesain test case berfokus pada serangkaian teknik u/ pembuatan test case yang memenuhi keselurahan sasaran pengujianStrategi mengenai pengujian dan debugging Software a/ dibahas pada chapter selanjutnya

  • Dasar dasar pengujian SoftwarePada 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 pengujianPrinsip pengujianTestabilitas

  • 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 kesalahanTest case yang baik adalah test case yang memiliki probabilitas tinggi u/ menemukan kesalahan yang belum pernah ditemukan sebelumnyaPengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya

  • Prinsip pengujianSebelum 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 pelangganPengujian harus direncanakan lama sebelum pengujian itu dimulaiPrinsip 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 programPengujian harus mulai dari yang kecil dan berkembang ke pengujian yang besarPengujian yang mendalam tidak mungkinu/ menjadi paling efektif, pengujian harus dilakukan o/ pihak ketiga

  • Testabilitas

    Seberapa mudah sebuah program komputer dapat diujiBeberapa checklist yang memberikan serangkaian karakteristik yang membawa kepada Software yang dapat diuji

    Operabilitas. semakin baik dia bekerja, semakin efisien dia dapat diujiObservabilitas. apa yang anda lihat adalah apa yang anda ujiKontrolabilitas. semakin baik kita dapat mengontrol Software, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkanDekomposabilitas. dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih halusKesederhanaan. semakin sedikit yang diuji, semakin cepat kita mengujinyaStabilitas. semakin sedikit perubahan, semakin sedikit gangguan dalam pengujianKemampuan u/ dapat dipahami. semakin banyak informasi yang kita miliki, semakin halus pengujian yang akan dilakukan

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

  • Pengujian white boxPengujian white box atau biasa disebut pengujian glass boxMetode desain test case yang menggunakan struktur kontrol desain prosedural u/ memperoleh test caseDengan white box engineer dapat melakukan test case yang:Memberikan jaminan bahwa semua jalur independen pada suatu modul telah digunakan paling tidak satu kaliMenggunakan semua keputusan logis pada sisi true dan falseMengeksekusi semua loop pada batasan mereka dan pada batas operasional merekaMenggunakan struktur data internal u/ menjamin validitas

  • Pengujian basis pathTeknik pengujian white box yang diusulkan pertama klai o/ Tom McCabeMetode basis path ini memungkinkan desainer test case mengukur kompleksitas logis dari desain prosedural dan menggunakannya sebagai pedoman u/ menetapkan basis set dari jalur eksekusiBeberapa 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 KontrolTeknik pengujian basis path yang sudah dibahas sebelumnya merupakan salah satu contoh pengujian struktur kontrolMeski pengujian basis path sederhana dan sangat efektif, tetapi kurang memadaiPengujian 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 programPengujian 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 SederhanaLoop TersarangLoop TerangkaiLoop Tidak Terstruktur

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

  • Pengujian black box berusaha menemukan kesalahan dalam kategori seperti:Fungsi-fungsi yang tidak benar / hilangKesalahan interfaceKesalahan dalam struktur data/ akses database eksternalKesalahan kinerjaInisialisasi dan kesalahan terminasi

  • Metode pengujian Graph-BasedLangkah pertama pada pengujian black box adalah memahami objek yang dimodel di dalam Software dan hubungan yang a/ menghubungkan objek tersebutLangkah selanjutnya menentukan sederetan pengujian yang membuktikan bahwa semua objek memiliki hubungan yang diharapkan satu dengan yang lainnyau/ 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 linkSimpul grafik program yang berisi instruksi (objek program) menandai representasi desain prosedural/ kode sumberDan link terarah menunjukkan aliran kontrol diantara objek-objek program ini.

  • Objek #1 = new file menu selectObjek #2 = document windowObjek #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 dimunculkanlink tak terarah membangun hubungan simetris di antara new file select menu dan document text

  • Partisi EkivalensiAdalah metode pengujian black box yang membagi domain input dari suatu program ke dalam kelas data dari mana test case dapat dilakukanDesain test case u partisi ekivalensi didasarkan pada evaluasi terhadap kelas ekivalensi u/ suatu kondisi inputSecara 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 digitPrefik tiga nomor digit tidak dimulai dengan 1 atau 0Sufik empat nomor digitPassword enam nilai digitPerintah 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 999Prefiks: range harga yang ditetapkan > 200 dengan tanpa digit 0Sufik: harga panjang empat digitPassword: boolean password ada / tidak ada harga antrian enam karakterPerintah: 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 kelasPengujian 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 khususSaat Software komputer menjadi kompleks, maka kebutuhan akan pendekatan pengujian yang khusus juga makin berkembangPada metode ini akan dibahas pedoman pengujian bagi lingkungan, arsitektur, dan aplikasi khusus yang umumnya ditemui oleh para Software engineering seperti:Pengujian GUIPengujian Arsitektur Client/ServerPengujian Dokumnetasi dan Fasilitas HelpPengujian Sistem Real Time

  • Pengujian GUIGUI menyajikan tantangan menarik bagi para engineerKarena komponen reusable berfungsi sebagai bagian dari lingkungan pengembangan GUI, pembuatan interface pemakai telah menjadi hemat waktu dan lebih telitiDi sisi lain saat kompleksitas GUI telah berkembang, menimbulkan kesulitan yang lebih besar di dalam desain dan eksekusi test caseKarena 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 kembaliApakah 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 mouseApakah 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 dataApakah 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/ServerSifat 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 HelpKegunaan program ditelusuri pada seluruh dokumenApakah 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 TimeUntuk aplikasi real time metode desain test case yang komprehensif harus berkembang. Empat strategi yang dapat diusulkan antara lain:Pengujian tugasPengujian tingkah lakuPengujian antar tugasPengujian sistemSifat asinkron dan tergantung waktu yang ada pada banyak aplikasi menambah elemen baru yang sulit dan potensial untuk bauran pengujian-waktuSebagian 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 Softwareu/ 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 programTest case dilakukan untuk memastikan bahwa semua statement pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diujiPengujian basis path, teknik pengujian white box, menggunakan grafik program (matrik grafik) untuk melakukan serangkaian pengujian yang independen secara linier yang akan memastikan cakupanPengujian 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 programTeknik 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 mendalamMetode pengujian graph based mengeksplorasi antara hubungan dan tingkah laku objek-objek programPartisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi Software tertentuAnalisis nilai batas memeriksa kemampuan program untuk menangani data pada batas yang dapat diterima

  • Required ReadingRoger S. Pressman, Ph.D, Software EngineeringOn web Software Technical Testing