REKAYASA PERANGKAT LUNAK 2
PEMBUATAN RENCANA UJI COBA & MEMBUAT STUDI KASUS
TEKNIK UJI COBA BLACK BOX DAN WHITE BOX
KELAS : 4IA08
NAMA ANGGOTA :
DEVI TRIWULANDARI NURDIN (50407255) KARINA ADRIANI (50407487)
NUR ENDAH SARI (50407632) VIRKA LIRAWATY RUFAIDA (50407881)
UNIVERSITAS GUNADARMA
2011
UJI COBA PERANGKAT LUNAK
Ujicoba software merupakan elemen yang kritis dari SQA (Software Quality Assurance) dan merepresentasikan tinjauan ulang yang menyeluruh terhadap spesifikasi, desain dan pengkodean. Ujicoba merepresentasikan ketidaknormalan yang terjadi pada pengembangan software. Selama definisi awal dan fase pembangunan, pengembang berusaha untuk membangun software dari konsep yang abstrak sampai dengan implementasi yang memungkinkan.
Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produksi dimana peluang terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna maka pengembangan perangkat lunak diiringi dengan aktivitas jaminan kualitas.
Dalam melakukan uji coba ada 2 masalah penting yang akan dibahas, yaitu : A. Teknik uji coba perangkat lunak
B. Strategi uji coba perangkat lunak
TEKNIK UJI COBA PERANGKAT LUNAK
Para pengembang membuat serangkaian uji kasus yang bertujuan untuk ”membongkar” software yang mereka bangun. Kenyataannya, ujicoba merupakan salah satu tahapan dalam proses pengembangan software yang dapat dilihat (secara psikologi) sebagai destruktif, dari pada sebagai konstruktif. Pengembang software secara alami merupakan orang konstruktif. Ujicoba yang diperlukan oleh pengembang adalah untuk melihat kebenaran dari software yang dibuat dan konflik yang akan terjadi bila kesalahan tidak ditemukan.
Dari sebuah buku, Glen Myers menetapkan beberapa aturan yang dapat dilihat sebagai tujuan dari ujicoba :
1. Ujicoba merupakan proses eksekusi program dengan tujuan untuk menemukan kesalahan. 2. Sebuah ujicoba kasus yang baik adalah yang memiliki probabilitas yang tinggi dalam
menemukan kesalahan-kesalahan yang belum terungkap.
Sehingga tujuan dari ujicoba ini adalah mendesain serangkaian tes yang secara sistematis mengungkap beberapa jenis kesalahan yang berbeda dan melakukannya dalam waktu dan usaha yang minimum.
Jika pengujian diselenggarakan dengan sukses, maka akan membongkar kesalahan yang ada didalam perangkat lunak, manfaat lain dari pengujian adalah menunjukkan bahwa fungsi perangkat lunak telah bekerja sesuai dengan spesifikasi, dan kebutuhan fungsi telah tercapai. Sebagai tambahan, data yang dikumpulkan pada saat pengujian dilaksanakan akan menyediakan suatu indikasi keandalan perangkat lunak yang baik dan beberapa indikasi mutu perangkat lunak secara keseluruhan.
Alur Informasi Uji Coba
Alur informasi untuk ujicoba mengikuti pola seperti gambar diatas. Dua kategori input yang disediakan untuk proses ujicoba adalah :
1. Software configuration yang terdiri dari spesifikasi kebutuhan software, spesifikasi desain dan kode sumber.
2. Test configuration yang terdiri dari rencana dan prosedur ujicoba, Tools ujicoba apapun yang dapat digunakan, dan kasus ujicoba termasuk hasil yang diharapkan. Pada kenyataannya, konfigurasi ujicoba merupakan subset dari konfigurasi software.
Setiap lingkaran merepresentasikan transformasi yang lebih kompleks. Ujicoba dilakukan dan hasilnya dievaluasi, kemudian hasil ujicoba dibandingkan dengan hasil yang diharapkan . Ketika ditemukan data yang keliru, maka error ditemukan dan debug dimulai. Ketika hasil
ujicoba dikumpulkan dan dievaluasi, indikasi kualitatif dari kualitas dan reliabilitas software mulai terlihat. Jika terjadi kesalahan fatal dan memerlukan modifikasi desain ditemukan secara reguler, maka kualitas dan reliabilitas software akan dipertanyakan dan diperlukan ujicoba lanjutan.
Sebaliknya jika fungsi software bekerja sebagaimana mestinya dan kesalahan yang terjadi dapat diatasi dengan mudah maka, dapat diambil 1 dari 2 kesimpulan dapat dibuat, yaitu :
(1) Kualitas dan reliabilitas software dapat diterima, atau
(2) Ujicoba tidak cukup untuk menemukan kesalahan yang fatal.
Akhirnya, jika ujicoba tidak menghasilkan kesalahan, maka harus terjadi keraguan bahwa konfigurasi ujicoba tersebut tidak berhasil dan masih terjadi kesalahan dalam software. Hal ini, akan dibuktikan oleh user dan akan diperbaiki oleh pengembang dalam fase pemeliharaan. Hasil-hasil yang dikumpulkan selama ujicoba dapat dievaluasi dengan cara formal.
Kelengkapan dan efektivitas ujicoba secara dramatis dapat meningkatkan dengan menilai rencana uji dan prosedur yang akan dilakukan.
Pada rencana ujicoba :
a. Apakah tahapan ujicoba utama telah diidentifikasikan dan diurutkan ?
b. Apakah kemampuan penelusuran kriteria validasi telah dibuat sebagai bagian dari analisis kebutuhan software ?
c. Apakah rencana ujicoba konsisten dengan rencana proyek keseluruhan d. Apakah jadwal ujicoba telah didefinisikan secara eksplisit ?
e. Apakah mekanisme penyimpanan catatan ujicoba telah disediakan ?
Pada prosedur ujicoba :
a. Apakah ujicoba white box dan black box telah dispesifikasikan ? b. Apakah seluruh jalur logika yang independen telah diuji ? c. Apakah penanganan kesalahan telah diuji ?
d. Apakah batasan-batasan nilai telah diuji ? e. Apakah respon waktu performa telah diperiksa ?
Rencana Uji Coba
Rencana Pengujian di bagi dalam beberapa hal yaitu : Proses testing
Deskripsi fase-fase utama dalam pengujian Pelacakan Kebutuhan
Semua kebutuhan user diuji secara individu Item yg diuji
Menspesifikasi komponen sistem yang diuji Jadual Testing
Prosedur Pencatatan Hasil dan Prosedur Kebutuhan akan Hardware dan Software Kendala-kendala
Mis: kekurangan staff, alat, waktu dll.
Karakteristik Umum Pengujian
Testing dimulai pada level modul dan bekerja keluar kearah integrasi pada sistem berbasiskan komputer
Teknik testing yang berbeda sesuai dengan poin-poin yang berbeda pada waktunya Testing diadakan oleh software developer dan untuk proyek yang besar oleh group testing
yang independent
Testing dan Debugging adalah aktivitas yang berbeda tetapi debugging harus diakomodasikan pada setiap strategi testing
TESTABILITAS
Testabilitas perangkat lunak adalah seberapa mudah sebuah program komputer dapat diuji. Karena pengujian sangat sulit, perlu diketahui apa yg dapat dilakukan untuk membuatnya menjadi mudah.
Karakteristik Pperangkat lunak yg diuji :
OPERABILITAS, semakin baik dia bekerja semakin efisien dia dapat diuji. OBSERVABILITAS, apa yg anda lihat adalah apa yg anda uji.
KONTROLABILITAS, semakin baik kita dapat mengontrol perangkat lunak semakin banyak pengujian yg ada dapat diotomatisasi dan dioptimalkan.
DEKOMPOSABILITAS, dengan mengontrol ruang lingkup pengujian kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali.
KESEDERHANAAN, semakin sedikit yg diuji semakin cepat pengujian. STABILITAS, semakin sedikit perubahan semakin sedikit gangguan pengujian.
KEMAMPUAN DIPAHAMI, semakin banyak informasi yg dimiliki semakin detail pengujiannya.
Atribut Pengujian Yg Baik :
Memiliki probabilitas yg tinggi menemukan kesalahan. Tidak redundan.
Harusnya ‘jenis terbaik’.
Tidak boleh terlalu sederhana atau terlalu kompleks.
DESAIN KASUS UJICOBA (TEST CASE DESIGN)
Desain ujicoba untuk software atau produk teknik lainnya sama sulitnya dengan desain inisial dari produk itu sendiri. Dengan tujuan dari ujicoba itu sendiri yaitu, mendesain ujicoba yang tingkat kemungkinan penemuan kesalahan yang tinggi dengan jumlah waktu dan usaha yang sedikit.
Selama beberapa dekade, metode desain ujicoba kasus telah dikembangkan. Metode ini menyediakan pendekatan sistematik untuk ujicoba. Hal yang lebih penting yaitu, metode-metode ini menyediakan mekanisme yang dapat membantu memastikan kelengkapan ujicoba dan menyediakan tingkat kemungkinan yang tinggi dalam penemuan kesalahan pada software.
Semua produk yang dikembangkan (engineered) dapat diujicoba dengan salah satu cara dari 2 cara berikut :
1. Mengetahui fungsi-fungsi yang dispesifikasikan pada produk yang didesain untuk melakukannya, ujicoba dapat dilakukan dengan mendemonstrasikan setiap fungsi secara menyeluruh;
2. Mengetahui cara kerja internal dari produk, ujicoba dapat dilakukan untuk memastikan bahwa seluruh operasi internal dari produk dilaksanakan berdasarkan pada spesifikasi dan komponen internal telah digunakan secara tepat.
Pendekatan pertama adalah black box testing dan yang kedua adalah white box testing. Black box testing menyinggung ujicoba yang dilakukan pada interface software. Walaupun didesain untuk menemukan kesalahan, ujicoba blackbox digunakan untuk mendemonstrasikan
fungsi software yang dioperasikan; apakah input diterima dengan benar, dan ouput yang dihasilkan benar; apakah integritas informasi eksternal terpelihara.
Ujicoba blackbox memeriksa beberapa aspek sistem, tetapi memeriksa sedikit mengenai struktur logikal internal software. White box testing didasarkan pada pemeriksaan detail prosedural. Alur logikal suatu software diujicoba dengan menyediakan kasus ujicoba yang melakukan sekumpulan kondisi dan/atau perulangan tertentu. Status dari program dapat diperiksa pada beberapa titik yang bervariasi untuk menentukan apakah status yang diharapkan atau ditegaskan sesuai dengan status sesungguhnya.
Sepintas seolah-olah white box testing akan menghasilkan program yang 100% benar, yang diperlukan hanyalah mendefinisikan alur logikal, membangun kasus uji untuk memeriksa software tersebut dan mengevaluasi hasil yang diperoleh. Sayangnya, ujicoba yang menyeluruh ini menghadirkan masalah logical tertentu. Untuk sebuah program sederhana sekalipun, terdapat banyak alur logikal yang memungkinkan.
Sehingga white box testing sebaiknya hanya dilakukan pada alur logikal yang penting. Struktur data-struktur data yang penting dapat diujikan dengan uji validitas. Atribut dari black box testing dan white box testing dapat dikombinasikan untuk digunakan bersama.
Berikut ini akan dibahas mengenai dua pendekatan uji coba yang telah kita bahas sebelumnya, yaitu:
1. BLACK BOX TESTING
Test case ini bertujuan untuk menunjukkan fungsi perangkat lunak tentang cara beroperasinya, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah inf ormasi yang disimpan secara eksternal selalu dijaga kemutakhirannya. Tehnik pengujian black-box berfokus pada domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.
Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku objekobjek program. Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas memeriksa kemampuan program untuk menangani data pada batas yang dapat diterima. Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area
aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan system real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.
Pengujian Black Box :
Digunakan untuk menguji fungsi-fungsi khusus dari perangkat lunak yang dirancang. Kebenaran perangkat lunak yang diuji hanya dilihat berdasarkan keluaran yang
dihasilkan dari data atau kondisi masukan yang diberikan untuk fungsi yang ada tanpa melihat bagaimana proses untuk mendapatkan keluaran tersebut.
Dari keluaran yang dihasilkan, kemampuan program dalam memenuhi kebutuhan pemakai dapat diukur sekaligus dapat diiketahui kesalahan-kesalahannya
Metode BLACK BOX berusaha menemukan kesalahan yang termasuk kategori di bawah ini:
Fungsi-fungsi yg hilang atau tidak benar Kesalahan pada antarmuka
Kesalahan pada struktur data atau pengaksesan database ekternal Kesalahan pada performance
Kesalahan pada inisialisasi dan terminasi
Tidak seperti metode whitebox yang dilaksanakan diawal proses, ujicoba blackbox diaplikasikan dibeberapa tahapan berikutnya. Karena ujicoba blackbox dengan sengaja mengabaikan struktur kontrol, sehingga perhatiannya difokuskan pada informasi domain.
Ujicoba didesain untuk dapat menjawab pertanyaan-pertanyaan berikut :
1. Bagaimana validitas fungsionalnya diuji?
2. Jenis input seperti apa yang akan menghasilkan kasus uji yang baik ? 3. Apakah sistem secara khusus sensitif terhadap nilai input tertentu ? 4. Bagaimana batasan-batasan kelas data diisolasi?
5. Berapa rasio data dan jumlah data yang dapat ditoleransi oleh sistem?
6. Apa akibat yang akan timbul dari kombinasi spesifik data pada operasi sistem?
Dengan mengaplikasikan ujicoba blackbox, diharapkan dapat menghasilkan sekumpulan kasus uji yang memenuhi kriteria berikut :
1. Kasus uji yang berkurang, jika jumlahnya lebih dari 1, maka jumlah dari ujikasus tambahan harus didesain untuk mencapai ujicoba yang cukup beralasan
2. Kasus uji yang memberitahukan sesuatu tentang keberadaan atau tidaknya suatu jenis kesalahan, daripada kesalahan yang terhubung hanya dengan suatu ujicoba yang spesifik Berikut ini adalah teknik khas uji coba Black Box.
A. EQUIVALENCE PARTITIONING
Equivalence partitioning adalah metode pengujian black-box yg memecah atau membagi domain input dari program ke dalam kelas-kelas data sehingga test case dapat diperoleh. Perancangan test case equivalence partitioning berdasarkan evaluasi kelas equivalence untuk kondisi input yg menggambarkan kumpulan keadaan yg valid atau tidak. Kondisi input dapat berupa nilai numeric, range nilai, kumpulan nilai yg berhubungan atau kondisi Boolean.
Contoh :
Pemeliharaan data untuk aplikasi bank yg sudah diotomatisasikan. Pemakai dapat memutar nomor telepon bank dengan menggunakan mikro computer yg terhubung dengan password yg telah ditentukan dan diikuti dengan perintah-perintah. Data yg diterima adalah :
Kode area : kosong atau 3 digit
Prefix : 3 digit atau tidak diawali 0 atau 1 Suffix : 4 digit
Password : 6 digit alfanumerik Perintah : check, deposit, dll
Selanjutnya kondisi input digabungkan dengan masing-masing data elemen dapat ditentukan sbb :
Kode area : kondisi input, Boolean – kode area mungkin ada atau tidak kondisi input, range – nilai ditentukan antara 200 dan 999
Prefix : kondisi input range > 200 atau tidak diawali 0 atau 1 Suffix : kondisi input nilai 4 digit
Password : kondisi input boolean – pw mungkin diperlukan atau tidak kondisi input nilai dengan 6 karakter string
B. BOUNDARY VALUE ANALYSIS
Untuk permasalahan yg tidak diketahui dg jelas cenderung menimbulkan kesalahan pada domain outputnya. BVA merupakan pilihan test case yg mengerjakan nilai yg telah ditentukan, dgn teknik perancangan test case melengkapi test case equivalence partitioning yg fokusnya pada domain input. BVA fokusnya pada domain output.
Petunjuk pengujian BVA :
1. Jika kondisi input berupa range yg dibatasi nilai a dan b, test case harus dirancang dgn nilai a dan b.
2. Jika kondisi input ditentukan dgn sejumlah nilai, test case harus dikembangkan dengan mengerjakan sampai batas maksimal nilai tsb.
3. Sesuai petunjuk 1 dan 2 untuk kondisi output dirancang test case sampai jumlah maksimal.
4. Untuk struktur data pada program harus dirancang sampai batas kemampuan.
2. WHITE BOX TESTING
Disebut juga glass-box testing. Sebuah metode perancangan kasus tes yang menggunakan struktur control dari perancangan prosedural untuk menghasilkan kasus test. Dapat dihasilkan kasus test yang menjamin bahwa semua alur dalam sebuah modul sudah dicoba paling tidak sekali mencoba semua keputusan logika baik di sisi true maupun false mengeksekusi semua loop dan mengeksekusi struktur data internal untuk menjamin validitasnya. Meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur logika) perangkat lunak akan ditest dengan menyediakan test case yang akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%.
Pengujian white-box berfokus pada struktur control program. Test case dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear 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 mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.
Pengujian White Box :
Digunakan untuk mengetahui cara kerja suatu perangkat lunak secara internal.
Pengujian dilakukan untuk menjamin operasi-operasi internal sesuai dengan spesifikasi yang telah ditetapkan dengan menggunakan struktur kendali dari prosedur yang dirancang.
Dengan rnenggunakan metode white box, analis sistem akan dapat memperoleh test case yang:
menjamin seluruh independent path di dalam modul yang dikerjakan sekurang-kurangnya sekali
mengerjakan seluruh keputusan logikal
mengerjakan seluruh loop yang sesuai dengan batasannya
mengerjakan seluruh struktur data internal yang menjamin validitas Berikut ini beberapa teknik dalam uji coba white box:
UJI COBA BASIS PATH
Uji coba basis path adalah teknik uji coba white box yg diusulkan Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan menggunkan ukuran ini sbg petunjuk untuk mendefinisikan basis set dari jalur pengerjaan. Test case yg didapat digunakan untuk mengerjakan basis set yg menjamin pengerjaan setiap perintah minimal satu kali selama uji coba.
2. Cyclometic Complexity
merupakan pengukuran per.lunak yang menyediakan pengukuran kuantitatif dari kompleksitas logis suatu program. Nilai cyclomatic complexity mendefinisikan jumlah jalur bebas pada basis program.
3. Independent Path
merupakan jalur pada program yg menunjukkan setidaknya satu kumpulan pernyataan pemrosesan baru atau kondisi baru.
4. Graph Matrix
merupakan matriks persegi 4 dimana sisi2nya sama dengan jumlah node pada flow graph
Contoh lain dari White Box Testing atau Control Structure Testing adalah
1. Condition Testing, menjalankan kondisi logis yang terdapat pada modul program 2. Data Flow Testing, metode yg menyeleksi jalur test program menurut lokasi
pendefinisian & menggunakan variabel2 program
3. Loop Testing, berfokus pada validitas dari bentuk loop (simple loop, concatenated loop, nested loop, unstructured loop)sesuai spesif ikasi dan semua komponen telah dicoba white-boxtesting.
STUDI KASUS
Pengujian
Pengujian ini dilakukan pada Aplikasi Sistem Informasi Pengadaan Bahan Perlengkapan, Obat– Obatan, Dan Alat – Alat Kedokteran Gigi Di Holistic Dental Clinic Specialist. Pengujian perangkat lunak ini menggunakan metode pengujian black box. Pengujian black box berfokus pada persyaratan fungsional perangkat lunak yang dibuat.
Rencana Pengujian
Pengujian aplikasi pengolahan data pengadaan berikut menggunakan data uji berupa pengolahan data, pengolahan proses dan pengolahan laporan serta informasi kelengkapannya.
Tabel 1 Rencana Aplikasi Sistem Informasi Pengadaan
Kasus dan Hasil Pengujian
Dalam melakukan pengujian, Tentu saja ada objek yang harus diuji dimana setelah itu akan didapat hasil dari pengujian tersebut.
Pengujian login adalah sebagai berikut :
Tabel 2 Pengujian Login
2. Pengujian Pengisian Data Barang
Tabel 3 Pengujian Data Barang
3. Pengujian pengolahan data
Tabel 4 Pengujian Permintaan Barang
Pengujian pengolahan penerimaan barang
Tabel 5 Pengujian Penerimaan Barang
Pengujian pengolahan pengeluaran barang
4. Pengujian laporan
Pengujian laporan data barang
Tabel 7 Pengujian Laporan Data Barang
Pengujian laporan data barang habis
Tabel 8 Pengujian Laporan Data Barang Habis
Pengujian laporan permintaan
Tabel 9 Pengujian Laporan Permintaan
Pengujian laporan penerimaan
Pengujian laporan pengeluaran
Tabel 11 Pengujian Laporan Pengeluaran
5. Kesimpulan hasil pengujian
Berdasarkan hasil pengujian dengan kasus black box dapat ditarik kesimpulan bahwa perangkat lunak dapat mengetahui fungsi-fungsi yang tidak benar atau hilang, kesalahan interface, kesalahan dalam struktur data atau akses database eksternal, kesalahan kinerja, inisialisasi, kesalahan terminasi dan secara fungsional mengeluarkan hasil yangs sesuai dengan yang diharapkan.
