TESTING AND IMPLEMENTATION SYSTEM “Strategi Pengujian Perangkat Lunak dan Membangun Test Case”
DOSEN PEMBIMBING : Agus Aan Jiwa Permana, S.Kom., M.Cs.
DISUSUN OLEH : Kelompok
: IV (Empat)
Nama Anggota Kelompok : Christoper Bintang Sangjaya
(13101120)
Ester Melinda
(13101129)
I Gusti Ngurah Wira Partha
(13101158)
I Gusti Putu Adithya Pratama
(13101224)
Yohanes Fiser Phima
(13101274)
Kelas
: N
PROGRAM STUDI TEKNIK INFORMATIKA STMIK STIKOM INDONESIA DENPASAR 2015/2016
KATA PENGANTAR
Puji dan syukur kami panjatkan kehadirat Tuhan Yang Maha Esa yang telah memberikan rahmat dan hidayah-Nya,
sehingga
kami
dapat
menyelesaikan
pembuatan tugas kelompok ini guna memenuhi tugas mata kuliah Testing and Implementation System. Dalam pembuatan tugas ini kami mengalami beberapa kesulitan, namun berkat bimbingan dan bantuan dari semua pihak akhirnya tugas ini dapat terselesaikan tepat
pada
waktunya.
Oleh
karena
itu,
kami
mengucapkan terima kasih kepada semua pihak yang telah membantu dalam penyusunan tugas ini. Terima kasih juga tak lupa kami haturkan kepada Bapak Agus Aan Jiwa Permana, S.Kom., M.Cs. selaku dosen mata kuliah Testing and Implementation System yang telah memberikan kami tugas ini. Semoga tugas ini dapat bermanfaat bagi kita semua. Tak ada gading yang tak retak. Begitu pula dengan tugas yang kami buat ini yang masih jauh dari kesempurnaan. Oleh karena itu kami memohon maaf apabila ada kekurangan ataupun kesalahan. Kritik dan ii
saran sangat diharapkan agar tugas ini menjadi lebih baik serta berdaya guna dimasa yang akan datang.
Denpasar, Juni 2016 Perwakilan Kelompok 4
(Ester Melinda)
iii
DAFTAR ISI
KATA PENGANTAR .............................................
ii
DAFTAR ISI ............................................................
iv
BAB I PENDAHULUAN ........................................
1
1.1 Latar Belakang ..........................................
1
1.2 Rumusan Masalah ....................................
3
1.3 Tujuan .......................................................
3
1.4 Manfaat .....................................................
4
BAB II PEMBAHASAN .........................................
5
2.1 Strategi Pengujian Perangkat Lunak ........
5
2.1.1 Rencana Pengujian Perangkat Lunak 6 2.1.2 Failure and Faults .........................
7
2.1.3 Prioritas Testing .............................
8
2.1.4 Test Data dan Test Case ................
8
2.1.5 Pendekatan Strategis Pengujian Perangkat Lunak ............................
9
2.2 Test Case .................................................. 21 2.2.1 Perancangan Test Case .................. 21 BAB III PENUTUP ................................................. 43 3.1 Kesimpulan .............................................. 43 DAFTAR PUSTAKA .............................................. 45 iv
BAB I PENDAHULUAN
1.1 Latar Belakang Pengujian perangkat lunak memegang peranan penting dalam menjaga kualitas perangkat lunak. Menurut Galin (2004) pengujian perangkat lunak atau software testing diartikan sebagai proses formal dimana suatu perangkat lunak diuji dengan cara menjalankan perangkat
lunak
tersebut
dalam
komputer
dan
menjalankan prosedur serta kasus tertentu. Dalam pengembangan perangkat lunak, tekanan untuk menyelesaikan perangkat lunak dengan cepat sering ditemui. Selain itu, perangkat lunak yang dikembangkan di era modern memiliki kompleksitas yang tinggi, sehingga meningkatkan tingkat kesulitan dalam melakukan pengujian. Hal-hal tersebut seringkali menyebabkan mengurangi
manajer aktivitas
proyek ataupun
memutuskan sumber
daya
untuk yang
diperlukan untuk melakukan pengujian perangkat lunak (Konka, 2011). Pengujian perangkat lunak yang dilaksanakan dengan tidak sempurna tentu akan membawa pengaruh 1
yang kurang baik terhadap kualitas perangkat lunak yang dihasilkan. Pengujian perangkat lunak yang tidak efektif dan tidak lengkap dapat mengakibatkan berbagai masalah ketika perangkat lunak tersebut digunakan oleh end-user (Catelani dkk., 2011). Dalam teori pengujian perangkat lunak terdapat berbagai metode yang bisa digunakan untuk melakukan pengujian, misalnya metode white-box testing dan metode black-box testing. Sistem penguji perangkat lunak tentunya harus mampu menguji berbagai aspek dalam perangkat lunak sehingga penggunaan lebih dari satu metode pengujian sangat diharapkan (Galin, 2004). Di dalam merancang dan membangun sebuah perangkat lunak berbasis proyek, semua kebutuhan pengguna harus bisa diakomodir oleh perangkat lunak yang dibuat. Untuk itu, salah satu cara memastikan kesesuaian antara kebutuhan dan output yang dihasilkan, adalah dengan membuat use case. Use case menjadi elemen dasar dan terpenting dalam tahap desain perangkat
lunak,
pembuatan
diagram
robustness,
sequence bahkan hingga class diagram didasarkan pada skenario yang dijabarkan pada usecase.
2
Sebuah perangkat lunak yang baik, idealnya adalah yang telah memenuhi semua kebutuhan penggunanya. Cara yang paling lazim digunakan untuk mengetahui apakah perangkat lunak yang dibuat telah sesuai dengan use case-nya, adalah cara test case. Berdasarkan skenario basic dan alternate path pada use case, dikembangkan seperangkat skenario testing. Selain itu, setiap skenario testing akan diberikan serangkaian data dummy yang akan dilakukan sebagai perangkat testing. Hasil dari testing ini akan menunjukkan sejauh mana kesesuaian antara use case dengan perangkat lunak.
1.2 Rumusan Masalah Dari latar belakang di atas dapat diambil rumusan masalah sebagai berikut : 1. Apa itu strategi pengujian perangkat lunak ? 2. Bagaimana cara membangun test case ? 1.3 Tujuan Tujuan kami membuat makalah ini adalah : 1. Mengetahui tentang strategi pengujian perangkat lunak. 2. Mengetahui cara membangun test case.
3
1.4 Manfaat Manfaat yang didapatkan dari makalah ini adalah sebagai berikut : 1. Mampu menerapkan srategi – strategi yang digunakan dalam pengujian perangkat lunak. 2. Mampu menerapkan test case dalam pengujian perangkat lunak.
4
BAB II PEMBAHASAN
2.1 Strategi Pengujian Perangkat Lunak Pengujian perangkat lunak adalah proses yang harus mengikuti suatu pola dan rencana yang telah ditetapkan secara baik. Proses pengujian seringkali dijalankan oleh kelompok penjamin kualitas yang independen, yang juga disebut tim uji (team test). Strategi uji coba perangkat lunak dilakukan untuk memudahkan
para
perancang
untuk
menentukan
keberhasilan system yang telah dikerjakan.
Gambar 2.1 Proses Testing 1. Unit Testing Pengujian masing – masing unit komponen program untuk meyakinkan bahwa sudah beroperasi secara benar.
5
2. Module Testing Pengujian terhadap koleksi unit-unit komponen yang saling berhubungan. 3. Sub-system Testing Pengujian terhadap koleksi module-module yang membentuk suatu sub-system (aplikasi). 4. System Testing Pengujian
terhadap
integrasi
sub-system,
yaitu
keterhubungan antar sub-system. 5. Acceptance Testing 1. Pengujian terakhir sebelum sistem dipakai oleh user. 2. Melibatkan pengujian dengan data dari pengguna sistem. 3. Biasa dikenal sebagai “alpha test” (“beta test” untuk
software komersial,
dimana pengujian
dilakukan oleh potensial customer).
2.1.1 Rencana Pengujian Perangkat Lunak Adapun Rencana Pengujian Perangkat Lunak, yaitu: 1. Proses testing Deskripsi fase-fase utama dalam pengujian. 6
2. Pelacakan kebutuhan Semua kebutuhan user diuji secara individu. 3. Item yang diuji Menspesifikasikan komponen sistem yang diuji. 4. Jadual testing 5. Prosedur pencatatan hasil dan prosedur 6. Kebutuhan akan hardware dan software 7. Kendala-kendala Misalnya : kekurangan staff, alat, waktu, dan lainlain.
2.1.2 Failure and Faults Failure output yang tidak benar / tidak sesuai ketika sistem dijalankan. Fault kesalahan dalam source code yang mungkin menimbulkan failure ketika code yang fault tersebut dijalankan.
Gambar 2.2 Failure Class 7
2.1.3 Prioritas Testing Hanya test yang lengkap yang dapat meyakinkan sistem terbebas dari kesalahan, tetapi hal ini sangat sulit dilakukan. Prioritas dilakukan terhadap pengujian kemampuan sistem, bukan masing-masing komponennya. Pengujian untuk situasi yang tipikal lebih penting dibandingkan pengujian terhadap nilai batas.
2.1.4 Test Data dan Test Cases 1. Test Data Input yang direncanakan digunakan oleh sistem. 2. Test Cases Input yang digunakan untuk menguji sistem dan memprediksi
output
dari
input
jika
beroperasi sesuai dengan spesifikasi.
Gambar 2.3 Proses Defect Testing
8
sistem
2.1.5 Pendekatan Strategis Pengujian Perangkat Lunak Berikut ini adalah pendekatan strategis pengujian perangkat lunak : 1. Pengujian Unit Berfokus pada inti terkecil dari desain perangkat lunak yaitu modul. Uji coba unit selalu berorientasi pada white box testing. Dapat dikerjakan paralel atau beruntun dengan modul lainnya.
Gambar 2.4 Pengujian Unit
9
Apakah jumlah parameter input sama dengan jumlah argumen? Apakah antara atribut dan parameter argumen sudah cocok? Apakah antara sistem satuan parameter dan argumen sudah cocok? Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter? Apakah
atribut
dari
argumen
yang
ditransmisikan ke modul yang dipanggil sama dengan atribut parameter? Apakah
sistem
unit
dari
argumen
yang
ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter? Apakah jumlah atribut dan urutan argumen ke fungsi-fungsi built-in sudah benar? Adakah referensi ke parameter yang tidak sesuai dengan poin entri yang ada? Apakah argumen input only diubah? Apakah definisi
variabel
dengan modul ?
10
global konsisten
Apakah
batasan
yang
dilalui
merupakan
argumen? Test case harus didesain untuk mengungkap kesalahan dalam kategori : 1. Pengetikkan yang tidak teratur dan tidak konsisten, inisialisasi yang salah atau nilainilai default. 2. Nama variabel yang tidak benar. 3. Tipe data yang tidak konsisten. 4. Underflow, overflow dan pengecualian pengalamatan.
Seberapa baik sistem yang sudah di bangun : Dua aspek yang dipertimbangkan : Apakah implementasi sudah sesuai dengan spesifikasi ? Apakah spesifikasi sesuai dengan kebutuhan user ? Validasi Apakah sistem yang dikembangkan sudah benar?
11
Pengujian dimana sistem ketika diimplementasikan sesuai dengan yang diharapkan. Verifikasi Apakah sistem dikembangkan dengan cara yang benar ? Pengujian apakah sistem sudah sesuai dengan spesifikasi ?
2. Pengujian Integrasi Pengujian keseluruhan system atau sub-system yang terdiri dari komponen yang terintegrasi. Test integrasi menggunakan black-box dengan test case, ditentukan dari spesifikasi. Kesulitannya adalah menemukan/melokasikan. Penggunaan Incremental integration testing dapat mengurangi masalah tersebut.
12
Gambar 2.5 Pengujian Integrasi
Pendekatan Pengujian Integrasi : Top-down Testing Berawal
dari
level-atas
system
dan
terintegrasi dengan mengganti masing-masing komponen secara top-down dengan suatu stub (program pendek yg men-generate input ke subsystem yang diuji).
Gambar 2.6 Top-down Testing 13
Bottom-up Testing Integrasi components di level hingga sistem lengkap sudah teruji. Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi kedua strategi pengujian tersebut.
Gambar 2.7 Bottom-up Testing Pendekatan Testing : Architectural Validation Top-down integration testing lebih baik digunakan dalam menemukan error dalam sistem arsitektur. System Demonstration Top-down
integration
membatasi
pengujian
pengembangan system. 14
testing pada
awal
hanya tahap
Test Implementation Seringkali lebih mudah dengan menggunakan bottom-up integration testing.
3. Pengujian Validasi Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi testing. Pengujian validasi dikatakan berhasil bila fungsi yang ada pada PL sesuai dengan yang diharapkan pemakai. Validasi PL merupakan kumpulan seri uji coba black box yang menunjukkan sesuai dengan yang diperlukan. Pengujian Alpha dan Beta Pengujian Alpha Dilakukan
pada
sisi
pengembang
oleh
seorang pelanggan. PL digunakan pada setting yang natural dengan pengembang “yang memandang” melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian. Pengujian Beta Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir PL dalam lingkungan 15
yang sebenarnya, pengembang biasanya tidak ada pada pengujian ini. Pelanggan merekam semua masalah (real atau imajiner) yang ditemui selama pengujian dan melaporkan pada
pengembang pada
interval
waktu
tertentu.
4. Pengujian Sistem Sistem testing merupakan rentetan pengujian yg berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen sistem yg dikembangkan.
Pengujian Aplikasi Server a) Volume Testing Menemukan
kelemahan
sistem
selama
melakukan pemrosesan data dalam jumlah yang besar dalam periode waktu yang singkat. Tujuan : meyakinkan bahwa sistem tetap melakukan pemrosesan data antar batasan fisik dan batasan logik. Contoh : Mengujikan proses antar server dan antar partisi harddisk pada satu server. 16
b) Stress Testing Dirancang untuk menghadapi situasi yang tidak normal pada saat program diuji. Testing ini dilakukan oleh sistem untuk kondisi seperti volume data yg tidak normal (melebihi atau kurang dari batasan) atau frekuensi. Tujuan : mengetahui kemampuan sistem dalam melakukan transaksi selama periode waktu puncak proses. Contoh periode puncak : ketika penolakan proses login on-line setelah sistem down atau pada kasus batch, pengiriman batch proses dalam jumlah yang besar dilakukan setelah sistem down. Contoh : Melakukan login ke server ketika sejumlah besar workstation melakukan proses menjalankan perintah sql database.
c) Performance Testing Dilakukan secara paralel dengan Volume dan Stress testing untuk mengetahui unjuk kerja sistem (waktu respon, throughput rate) pada beberapa kondisi proses dan konfigurasi. 17
Dilakukan pada semua konfigurasi sistem perangkat keras dan lunak. Misal : pada aplikasi Client-Server diujikan pada kondisi corporate ataupun lingkungan sendiri (LAN vs. WAN, Laptop vs. Desktop) Menguji sistem dengan hubungannya ke sistem yang lain pada server yang sama. Load Balancing Monitor Network Monitor
d) Data Recovery Testing Adalah system testing yg memaksa PL mengalami
kegagalan
dalam bermacam-
macam cara dan memeriksa apakah perbaikan dilakukan dgn tepat. Investigasi dampak kehilangan data melalui proses recovery ketika terjadi kegagalan proses. Penting dilakukan karena data yg disimpan di server dapat dikonfigurasi dengan berbagai cara.
18
Kehilangan Data terjadi akibat kegagalan sistem, harddisk rusak, peghapusan yang tidak sengaja, kecelakaan, virus dan pencuri.
e) Data Backup dan Restore Testing Dilakukan untuk melihat prosedur back-up dan recovery. Dilakukan dengan mensimulasikan beberapa kesalahan untuk menguji proses backup dan recovery. Pengujian backup:
dilakukan frekuensi,
mekanisme personal,
backup Berapa
terhadap
strategi
medium,
waktu,
(manual/otomatis),
lama
backup
akan
disimpan? Switching antara live dan backup server ketika terjadi kerusakan (load log transaction pada
back-up
kemudian
melakukan
recovery).
f) Data Security Testing Adalah pengujian yang akan melalukan verifikasi dari mekanisme perlindungan yang 19
akan dibuat oleh sistem, melindungi dari halhal yang mungkin terjadi. Privilege access terhadap database, diujikan pada beberapa user yang tidak memiliki privilege access ke database. Shutdown database engine melalui operating system (dengan beberapa perintah OS) yang dapat mematikan aplikasi database.
Gambar 2.8 Debugging
20
2.2 Test Case Test case merupakan suatu tes yang dilakukan berdasarkan pada suatu inisialisasi, masukan, kondisi ataupun hasil yang telah ditentukan sebelumnya.
2.2.1 Perancangan Test Case Terdapat dua (2) macam test case : 1. Pengetahuan fungsi yang spesifik dari produk yang telah dirancang untuk diperlihatkan, test dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan sebagaimana yg diharapkan. 2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya.
Dua metode pendekatan perancangan test case, yaitu : 1. Black Box Testing Test case ini bertujuan untuk menunjukkan fungsi PL tentang cara beroperasinya, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya.
21
2. White Box Testing Adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya logical path (jalur logika) perangkat lunak akan di-test 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%.
UJI COBA WHITE BOX Uji coba white box adalah metode perancangan test case
yang
menggunakan
struktur
kontrol
dari
perancangan prosedural untuk mendapatkan test case. Dengan menggunakan 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 logical. Mengerjakan seluruh loop yang sesuai dengan batasannya. Mengerjakan seluruh struktur data internal yang menjamin validitas. 22
a) 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
sebagai
petunjuk
untuk
mendefinisikan basis set dari jalur pengerjaan. Test case yang didapat digunakan untuk mengerjakan basis set yg menjamin pengerjaan setiap perintah minimal satu kali selama uji coba.
1) Notasi diagram alir
Gambar 2.9 Notasi Diagram Alir
Untuk menggambarkan pemakaian diagram alir diberikan contoh perancangan prosedural dalam bentuk flowchart.
23
1
2
3
6
4
7
8
5
9 10 11
Gambar 2.10 Diagram Alir
Selanjutnya diagram alir diatas dipetakan ke grafik alir
node
Gambar 2.11 Grafik Alir
24
Lingkaran/node : Menggambarkan satu/lebih perintah prosedural. Urutan proses dan keputusan dapat dipetakan dalam satu node. Tanda panah/edge : Menggambarkan aliran kontrol. Setiap node harus mempunyai tujuan node. Region : adalah daerah yang dibatasi oleh edge dan node. Termasuk daerah diluar grafik alir.
Contoh menterjemahkan pseudocode ke grafik alir 1: do while record masih ada baca record 2: if record ke 1 = 0 3: then proses record simpan di buffer naikkan counter 4: else if record ke 2 = 0 5 then reset kounter 6 proses record simpan pada file 7a: endif endif 7b: enddo 8 : end
25
Gambar 2.12 Menerjemahkan Pseudocode ke grafik Alir
Nomor pada pseudocode berhubungan dengan nomor node. Apabila diketemukan kondisi majemuk (compound
condition)
pada
pseudocode,
maka
pembuatan grafik alir menjadi rumit. Kondisi majemuk mungkin terjadi pada operator boolean (AND, OR, NAND, NOR) yg dipakai pada perintah if.
26
Contoh :
if a or b then procedure x else procedure y endif Gambar 2.13 Logika Gabungan
Node dibuat terpisah untuk masing-masing kondisi A dan B dari pernyataan IF a OR b. Masing-masing node berisi kondisi yg disebut pridicate node dan mempunyai karakteristik dua atau lebih edge darinya.
27
2) Cyclomatic Complexity Cyclomatic complexity adalah metrik PL yang menyediakan ukuran kuantitatif dari kekompleksan logikal program. Apabila digunakan dalam konteks metode uji coba basis path, nilai yang dihitung untuk cyclomatic
complexity
menentukan
jumlah
jalur
independen dalam basis set suatu program dan memberi batas atas untuk jumlah uji coba yang harus dikerjakan untuk menjamin bahwa seluruh perintah sekurangkurangnya telah dikerjakan sekali. Jalur independen adalah jalur yang melintasi atau melalui program dimana sekurang-kurangnya terdapat proses perintah yang baru atau kondisi yang baru.
Dari gambar 2.11 : Path 1 : 1 - 11 Path 2 : 1 - 2 - 3 - 4 - 5 - 10 - 1 - 11 Path 3 : 1 - 2 - 3 - 6 - 8 - 9 ...: 10 - 1 - 11 Path 4 : 1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11 Path 1,2,3,4 yang telah didefinisikan di atas merupakan basis set untuk diagram alir.
28
Cyclomatic complexity digunakan untuk mencari jumlah path dalam satu flowgraph. Dapat dipergunakan rumusan sebagai berikut : Jumlah region grafik alir sesuai dengan cyclomatic complexity. Cyclomatix complexity V(G) untuk grafik alir dihitung dengan rumus : V(G) = E - N + 2 Dimana : E = jumlah edge pada grafik alir N = jumlah node pada grafik alir Cyclomatix complexity V(G) juga dapat dihitung dengan rumus : V(G) = P + 1 Dimana, P = jumlah predicate node pada grafik alir
Pada Gambar 2.11 dapat dihitung cyclomatic complexity: 1. Flowgraph mempunyai 4 region 2. V(G) = 11 edge - 9 node + 2 = 4 3. V(G) = 3 predicate node + 1 = 4 Jadi, cyclomatic complexity untuk flowgraph Gambar 2.11 adalah 4.
29
3) Melakukan Test Case Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci atau program sumber. Pada bagian ini akan dijelaskan langkah-langkah uji coba basis path. Prosedur rata-rata pada bagian berikut akan digunakan sebagai contoh dalam pembuatan test case. PROCEDURE RATA-RATA INTERFACE RESULT rata, total, input, total.valid INTERFACE RESULT nilai, minim, max TYPE NILAl (1:100) IS SCALAR ARRAY; TYPE rata, total. input, total.valid, max.minim, jumlah IS SCALAR; TYPE I IS INTEGER; I = 1; total. input = total. valid = 0; jumlah = 0; DO WHILE nilai(i) <> -999 .and. total.input < 100 tambahkan total.input dengan 1; IF nilai(i) >= minimum .and. nilai(i} <=max; THEN tambahkan total.valid dengan I; jumlah=jumlah + nilai(i); ELSE skip; END IF tambahkan i dengan 1; ENDDO IF total. valid> 0 THEN rata =jumlah/total. valid; ELSE rata = -999; ENDIF END
30
Langkah-Iangkah pembuatan test case : i. Dengan mempergunakan perancangan prosedural atau program sumber sebagai dasar, digambarkan diagram alirnya.
Gambar 2.14 Diagram Alir Prosedur Rata
ii. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat : V(G) = 6 region. V(G) = 17 edge - 13 node + 2 = 6 V(G) = 5 predicate node + 1 = 6
31
iii. Tentukan independent path pada flowgraph Dari hasil perhitungan cyclomatic complexity terdapat 6 independent path yaitu : path 1 : 1-2-10-11-13 path 2 : 1-2-10-12-13 path 3 : 1-2-3-10-11-13 path 4 : 1-2-3-4-5-8-9-2-.. path 5 : 1-2-3-4-5-6-8-9-2-.. path 6 : 1-2-3-4-5-6-7-8-9-2-... iv. Buat test case yang akan mengerjakan masingmasing path pada basis set. Data yang dipilih harus tepat sehingga setiap kondisi dari predicate node dikerjakan semua.
4) Graph Metrik Graph metrik merupakan PL yang dikembangkan untuk membantu uji coba basis path atau struktur data. Graph metrik adalah matrik empat persegi yang mempunyai ukuran (sejumlah baris dan kolom) yang sama dengan jumlah node pada flowgraph. Masingmasing baris dan kolom mempunyai hubungan dengan node yang telah ditentukan dan pemasukan data matrik berhubungan dengan hubungan (edge) antar node. 32
Contoh sederhana pemakaian graph matrik dapat digambarkan sebagai berikut :
Gambar 2.15 Graph matrik
Pada gambar flowgraph masing-masing node ditandai dengan angka clan edge dengan huruf kecil, kemudian diterjemahkan ke graph matrik. Contoh 33
hubungan node 3 dengan node 4 pada graph ditandai dengan huruf b. Hubungan bobot menyediakan tambahan informasi tentang aliran kontrol. Secara simpel hubungan bobot dapat diberi nilai 1 jika ada hubungan antara node atau nilai 0 jika tidak ada hubungan. Dapat juga hubungan bobot diberi tanda dengan : Kemungkinan link (edge) dikerjakan. Waktu yang digunakan untuk proses selama traversal dari link. Memori yang diperlukan selama traversal link. Sumber daya yang diperlukan selama traversal link.
Gambar 2.16 Hubungan bobot
34
b) UJI COBA LOOP Loop merupakan kendala yang sering muncul untuk menerapkan algoritma dengan tepat. Uji coba loop merupakan teknik pengujian white box yang fokusnya pada validitas dari loop. Kelas loop yaitu : a. Loop Sederhana, pengujian loop sederhana dilakukan dengan mudah, dimana n jumlah maksimum yang diijinkan melewati loop tersebut. 1. Lewati loop secara keseluruhan. 2. Hanya satu yang dapat melewati loop. 3. m dapat melewati loop dimana m< n . b. Loop Tersarang, pengujian loop ini menggunakan pendekatan loop sederhana. Petunjuk pengujian loop tersarang : 1. Dimulai dari loop paling dalam. Atur semua loop ke nilai minimum. 2. Kerjakan dengan prinsip loop sederhana untuk loop yg paling dalam sementara tahan loop yang di luar pada parameter terkecil (nilai counter terkecil). 3. Kemudian lanjutkan untuk loop yg diatasnya. 4. Teruskan sampai semua loop selesai di uji. 35
c. Loop Terangkai, pengujian loop ini menggunakan pendekatan loop sederhana bila masing-masing loop independen, tetapi bila dua loop dirangkai dan pencacah loop 1 digunakan sebagai harga awal loop 2 maka loop tersebut jadi tidak independen, maka pendekatan yang diaplikasikan ke loop tersarang direkomendasikan. d. Loop Tidak Terstruktur, Kapan saja memungkinkan, loop ini didisain kembali agar mencerminkan penggunaan komsepsi pemrograman terstruktur.
Loop sederhana
Loop tersarang Loop terangkai
Loop tidak terstruktur
Gambar 2.17 Macam-macam Loop
36
UJI COBA BLACK-BOX Pengujian black-box berfokus pada persyaratan fungsional PL. Pengujian ini memungkinkan analis sistem memperoleh kumpulan kondisi input yang akan mengerjakan seluruh keperluan fungsional program. Tujuan metode ini mencari kesalahan pada:
Fungsi yg salah atau hilang.
Kesalahan pada interface.
Kesalahan pada struktur data atau akses database.
Kesalahan performansi.
Kesalahan inisialisasi dan tujuan akhir.
Metode ini tidak terfokus pada struktur kontrol seperti pengujian white-box tetapi pada domain informasi.
Pengujian dirancang untuk menjawab pertanyaan sebagai berikut :
Bagaimana validitas fungsional diuji?
Apa kelas input yang terbaik untuk uji coba yang baik?
Apakah sistem sangat peka terhadap nilai input tertentu? 37
Bagaimana
jika
kelas
data
yang
terbatas
dipisahkan?
Bagaimana volume data yang dapat ditoleransi oleh sistem?
Bagaimana pengaruh kombinasi data terhadap pengoperasian sistem?
a) EQUIVALENCE PARTITIONING Equivalence partitioning adalah metode pengujian black-box yang 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 yang menggambarkan kumpulan keadaan yang valid atau tidak. Kondisi input dapat berupa nilai numeric, range nilai, kumpulan nilai yg berhubungan atau kondisi boolean.
Contoh 1 : Pemeliharaan data untuk aplikasi bank yang sudah diotomatisasikan. Pemakai dapat memutar nomor telepon bank dengan menggunakan mikro komputer yang 38
terhubung dengan password yang 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 alfa numerik
Perintah
: check, deposit, dan lain-lain
Selanjutnya kondisi input digabungkan dengan masing-masing data elemen dapat ditentukan sebagai berikut : 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 – password mungkin diperlukan atau tidak. kondisi input nilai dengan 6 karakter string.
39
Perintah
: kondisi input set berisi perintah-perintah yang telah didefinisikan.
Contoh 2 :
Gambar 2.18 Contoh Pengujian Black Box Equivalence Partitioning
b) BOUNDARY VALUE ANALYSIS Untuk permasalahan yang tidak diketahui dengan jelas, cenderung menimbulkan kesalahan pada domain outputnya. BVA merupakan pilihan test case yang 40
mengerjakan nilai yg telah ditentukan, dengan teknik perancangan test case melengkapi test case equivalence partitioning yang fokusnya pada domain input. BVA fokusnya pada domain output. Petunjuk pengujian BVA : 1. Jika kondisi input berupa range yang dibatasi nilai a dan b, test case harus dirancang dengan nilai a dan b. 2. Jika kondisi input ditentukan dengan sejumlah nilai, test case harus dikembangkan dengan mengerjakan
sampai
batas
maksimal
nilai
tersebut. 3. Sesuai petunjuk 1 dan 2 untuk kondisi output dirancang test case sampai jumlah maksimal. 4. Untuk
struktur
data
pada
program
dirancang sampai batas kemampuan.
41
harus
HALAMAN INI SENGAJA DIKOSONGKAN
42
BAB III PENUTUP
3.1 Kesimpulan Strategi pengujian perangkat lunak dilakukan untuk memudahkan
para
perancang
dalam
menentukan
keberhasilan system yang telah dikerjakan. Test case merupakan suatu tes yang dilakukan berdasarkan pada suatu inisialisasi, masukan, kondisi ataupun hasil yang telah ditentukan sebelumnya. Segala produk perekayasaan, termasuk perangkat lunak, dapat diuji dengan dua cara, yaitu pengujian white box dan black box.
43
HALAMAN INI SENGAJA DIKOSONGKAN
44
DAFTAR PUSTAKA
NN.
2014.
Dokumen
Test
Case,
diakses pada tanggal 24 Mei 2016.
NN. Tanpa Tahun. Strategi Pengujian Perangkat Lunak, diakses pada tanggal 24 Mei 2016. NN.
Tanpa
Tahun.
Pengantar
Pemeliharaan
Implementasi
Sistem
dan
Informasi,
diakses
pada
tanggal 20 Mei 2016.
NN.
Tanpa
Tahun.
Pengujian
Perangkat
Lunak,
45
files/2842/RPL09b.doc> diakses pada tanggal 20 Mei 2016. NN. 2015. Perancangan dengan Pendekatan Sistem Multi Agen untuk Pengujian Perangkat Lunak Otomatis
Menggunakan
Pengujian
Beberapa
Perangkat
Metode Lunak,
diakses pada tanggal 20 Mei 2016.
46
