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

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

(Ester Melinda)

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

DAFTAR PUSTAKA .............................................. 45

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.

2. Mengetahui cara membangun test case.

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

perangkat lunak.

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

Deskripsi fase-fase utama dalam pengujian.

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.

Gambar 2.2 Failure Class

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.

Gambar 2.3 Proses Defect Testing

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.

Gambar 2.4 Pengujian Unit

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

dapat mengurangi masalah tersebut.

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

Gambar 2.6 Top-down Testing

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.

Gambar 2.8 Debugging

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

910

11

Gambar 2.10 Diagram Alir

Selanjutnya diagram alir diatas dipetakan ke grafik alir

node

Gambar 2.11 Grafik Alir

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.

Gambar 2.16 Hubungan bobot

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

Gambar 2.17 Macam-macam Loop

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.

kondisi input nilai dengan 6 karakter string.

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

dirancang sampai batas kemampuan.

42

HALAMAN INI SENGAJA DIKOSONGKAN

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

HALAMAN INI SENGAJA DIKOSONGKAN

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.