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

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

Gambar 2.3 Proses Defect Testing

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

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

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 sub-
system 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 testing hanya
membatasi pengujian pada awal tahap
pengembangan system.

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

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

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

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

41
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,

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

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

46