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

Transkripsi

1 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 ( ) Ester Melinda ( ) I Gusti Ngurah Wira Partha ( ) I Gusti Putu Adithya Pratama ( ) Yohanes Fiser Phima ( ) Kelas : N PROGRAM STUDI TEKNIK INFORMATIKA STMIK STIKOM INDONESIA DENPASAR 2015/2016

2 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

3 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

4 DAFTAR ISI KATA PENGANTAR... ii DAFTAR ISI... iv BAB I PENDAHULUAN Latar Belakang Rumusan Masalah Tujuan Manfaat... 4 BAB II PEMBAHASAN Strategi Pengujian Perangkat Lunak Rencana Pengujian Perangkat Lunak Failure and Faults Prioritas Testing Test Data dan Test Case Pendekatan Strategis Pengujian Perangkat Lunak Test Case Perancangan Test Case BAB III PENUTUP Kesimpulan DAFTAR PUSTAKA iv

5 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 1

6 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

7 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

8 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

9 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

10 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) Rencana Pengujian Perangkat Lunak Adapun Rencana Pengujian Perangkat Lunak, yaitu: 1. Proses testing Deskripsi fase-fase utama dalam pengujian. 6

11 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 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

12 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 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. Gambar 2.3 Proses Defect Testing 8

13 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

14 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? 10

15 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

16 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

17 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

18 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. 14

19 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

20 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

21 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

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

23 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 19

24 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

25 2.2 Test Case Test case merupakan suatu tes yang dilakukan berdasarkan pada suatu inisialisasi, masukan, kondisi ataupun hasil yang telah ditentukan sebelumnya 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

26 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

27 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

28 Gambar 2.10 Diagram Alir Selanjutnya diagram alir diatas dipetakan ke grafik alir node Gambar 2.11 Grafik Alir 24

29 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

30 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

31 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

32 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 : Path 3 : : Path 4 : Path 1,2,3,4 yang telah didefinisikan di atas merupakan basis set untuk diagram alir. 28

33 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

34 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

35 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

36 iii. Tentukan independent path pada flowgraph Dari hasil perhitungan cyclomatic complexity terdapat 6 independent path yaitu : path 1 : path 2 : path 3 : path 4 : path 5 : path 6 : 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

37 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

38 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

39 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

40 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 Gambar 2.17 Macam-macam Loop Loop tidak terstruktur 36

41 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

42 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

43 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

44 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

45 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 dirancang sampai batas kemampuan. 41

46 HALAMAN INI SENGAJA DIKOSONGKAN 42

47 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

48 HALAMAN INI SENGAJA DIKOSONGKAN 44

49 DAFTAR PUSTAKA NN. Tanpa Tahun. Strategi Pengujian Perangkat Lunak, <URL: ds/files/2204/strategi+pengujian+perangkat+luna k+mg+ke+8.pdf> diakses pada tanggal 24 Mei NN Dokumen Test Case, <URL: elompok_3_onick_test_case-dan-screenshot- JUnit.docx> diakses pada tanggal 24 Mei NN. Tanpa Tahun. Pengantar Implementasi dan Pemeliharaan Sistem Informasi, <URL: peng_implementasi_pmliharaan_si/bab4- pengujian_perangkat_lunak.pdf> diakses pada tanggal 20 Mei NN. Tanpa Tahun. Pengujian Perangkat Lunak, <URL: 45

50 files/2842/rpl09b.doc> diakses pada tanggal 20 Mei NN Perancangan dengan Pendekatan Sistem Multi Agen untuk Pengujian Perangkat Lunak Otomatis Menggunakan Beberapa Metode Pengujian Perangkat Lunak, <URL: od=download&sub=downloadfile&act=view&typ =html&id=78726&ftyp=potongan&potongan=s chapter1.pdf> diakses pada tanggal 20 Mei