TESTING AND IMPLEMENTATION SYSTEM Strategi Pengujian Perangkat Lunak dan Membangun Test Case

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

ii

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

iii

saran sangat diharapkan agar tugas ini menjadi lebih baik serta berdaya guna dimasa yang akan datang.

Denpasar, Juni 2016 Perwakilan Kelompok 4

iv 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

1

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 manajer proyek memutuskan untuk mengurangi aktivitas ataupun sumber daya yang diperlukan untuk melakukan pengujian perangkat lunak (Konka, 2011).

Pengujian perangkat lunak yang dilaksanakan dengan tidak sempurna tentu akan membawa pengaruh

2

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.

3

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.

4

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

5

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.

6 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

7 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 lain-lain.

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.

8

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 sistem beroperasi sesuai dengan spesifikasi.

9

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.

10

 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 global konsisten dengan modul ?

11

 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 nilai-nilai 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?

12

 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

13

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 sub-system yang diuji).

14  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 testing hanya

membatasi pengujian pada awal tahap pengembangan system.

15  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

16

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.

17 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.

18

 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.

19

 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 dilakukan terhadap strategi

backup: frekuensi, medium, waktu,

mekanisme backup (manual/otomatis), personal, Berapa 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

20

akan dibuat oleh sistem, melindungi dari hal-hal 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.

21

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.

22 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.

23

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.

24 1 6 3 7 8 5 4 2 9 10 11

Gambar 2.10 Diagram Alir

Selanjutnya diagram alir diatas dipetakan ke grafik alir

node

25 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

26

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.

27 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.

28

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 sekurang-kurangnya 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.

29

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.

30

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

31

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

32

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 masing-masing 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. Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah ditentukan dan pemasukan data matrik berhubungan dengan hubungan (edge) antar node.

33

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

34

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.

35

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.

36

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 tidak terstruktur Loop terangkai Loop tersarang Loop sederhana

37

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?

38

 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

39

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.

40

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

41

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 harus

42

43

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.

44

45

DAFTAR PUSTAKA

NN. 2014. Dokumen Test Case, <URL:http://power.lecture.ub.ac.id/files/2014/11/K elompok_3_ONick_Test_Case-dan-Screenshot-JUnit.docx> diakses pada tanggal 24 Mei 2016.

NN. Tanpa Tahun. Strategi Pengujian Perangkat Lunak, <URL:http://wsilfi.staff.gunadarma.ac.id/Downloa ds/files/2204/Strategi+Pengujian+Perangkat+Luna k+mg+ke+8.pdf> diakses pada tanggal 24 Mei 2016.

NN. Tanpa Tahun. Pengantar Implementasi dan

Pemeliharaan Sistem Informasi,

<URL:http://elearning.gunadarma.ac.id/docmodul/

peng_implementasi_pmliharaan_si/bab4-pengujian_perangkat_lunak.pdf> diakses pada tanggal 20 Mei 2016.

NN. Tanpa Tahun. Pengujian Perangkat Lunak, <URL:http://lulu.staff.gunadarma.ac.id/Downloads/

46

files/2842/RPL09b.doc> diakses pada tanggal 20 Mei 2016.

NN. 2015. Perancangan dengan Pendekatan Sistem Multi Agen untuk Pengujian Perangkat Lunak

Otomatis Menggunakan Beberapa Metode

Pengujian Perangkat Lunak,

<URL:http://etd.repository.ugm.ac.id/index.php?m od=download&sub=DownloadFile&act=view&typ =html&id=78726&ftyp=potongan&potongan=S2-2015-336408-chapter1.pdf> diakses pada tanggal 20 Mei 2016.