CONTOH PAPER SISTEM TESTING DAN IMPLEMEN

1

TUGAS PAPER MATAKULIAH
SISTEM TESTING DAN IMPLEMENTASI
https://www.4shared.com/zip/YuMrNxJHba/TUGAS_PAPER_SISTEM_TESTING_DAN.html

Oleh :

Nama

: IM RAN JAYADI

Stambuk

: 12.1401.075

Kelas

: BK-12

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS ILMU KOMPUTER
UNIVERSITAS INDONESIA TIMUR MAKASSAR
2015/2016

2

A.

SDLC

SDLC (Software Development Life Cycle) berarti sebuah siklus hidup
pemngembangan perangkat lunak yang terdiri dari beberapa tahapan-tahapan yang
sangat

penting

dalam

keberadaan

perangkat

lunak

yang dilihat

dari

segi

pengembangannya, tahapan-tahapan pekerjaan yang dilakukan oleh analis sistem dan
programmer dalam membangun sistem informasi. Langkah yang digunakan meliputi :
1. Melakukan survei dan menilai kelayakan proyek pengembangan sistem informasi
2. Mempelajari dan menganalisis sistem informasi yang sedan

g berjalan

3. Menentukan permintaan pemakai sistem informasi
4. Memilih solusi atau pemecahan masalah yang paling baik
5. Menentukan perangkat keras (hardware) dan perangkat lunak (software)

6. Merancang sistem informasi baru
7. Membangun sistem informasi baru
8. Mengkomunikasikan dan mengimplementasikan sistem informasi baru
9. Memelihara dan melakukan perbaikan/peningkatan sistem informasi baru bila
diperlukan

3

System Development Lyfe Cycle (SDLC) adalah keseluruhan proses dalam
membangun sistem melalui beberapa langkah. Ada beberapa model SDLC. Model yang
cukup populer dan banyak digunakan adalah waterfall. Beberapa model lain SDLC
misalnya fountain, spiral, rapid, prototyping, incremental, build & fix, dan synchronize
& stabilize.
Dengan siklus SDLC, proses membangun sistem dibagi menjadi beberapa langkah
dan pada sistem yang besar, masing-masing langkah dikerjakan oleh tim yang berbeda.
o Kegunaan SDLC
Adapun kegunaan utama dari SDLC adalah mengakomodasi beberapa kebutuhan.
Kebutuhan-kebutuhan itu biasanya berasal dari kebutuhan pengguna akhir dan juga
pengadaan perbaikan sejumlah masalah yang terkait dengan pengembangan perangkat
lunak. Kesemua itu dirangkum pada proses SDLC yang dapat berupa penambahan fitur

baru (baca : kemampuan penggunaan) baik itu secara modular (baca : instalasi parsial
atau update dan upgrade perangkat lunak) maupun dengan proses instalasi baru (baca :
penggantian perangkat lunak menyeluruh atau software replacement). Dari proses
SDLC juga berapa lama umur sebuah perangkat lunak dapat diperkirakan untuk
dipergunakan yang dapat diukur atau disesuaikan dengan kebijakan dukungan (baca :
software support) dari pengembang perangkat lunak terkait.

o Implementasi SDLC
Secara sederhana proses implementasi SDLC dapat dilihat dari penamaan sebuah
perangkat lunak - sebagai contoh berikut :

 Sebuah aplikasi contoh “ABCDE” versi 1.0 {alpha|beta|STABLE|i386|x64},
dapat diartikan bahwa aplikasi contoh “ABCDE” tersebut dipublikasikan
dalam tahap awal yang ditandai dengan label versi 1.0 atau biasanya disingkat
dengan huruf v1.0. Bila dikemudian waktu label versi menjadi versi 1.2 atau
v1.2 maka hal tersebut menandakan bahwa perangkat lunak tersebut telah
mengalami revisi (baca : perbaikan) dari versi sebelumnya.

4

o Kebutuhan SDLC
Penerapan SDLC yang baik dan benar pada prinsipnya juga membutuhkan biaya
baik itu finansial dan non-finansial, baik itu teknis maupun non-teknis yang tidak
sedikit. Kesemua hal tersebut wajib diperhitungkan secara cermat agar proses
pengembangan perangkat lunak itu sendiri (yang menjadi inti utama dari SDLC) tidak
terhambat atau bahkan terbengkalai.

o Limitasi SDLC
Kadangkala, perkembangan dan penggunaan teknologi antara perangkat keras dan
perangkat lunak, dan sesama perangkat lunak tidak sejalan (lebih cepat atau lebih
lambat antara satu dengan lainnya, antara mendukung dan tidak mendukung satu dengan
lainnya) - sehingga terkadang hasil proses SDLC yang membutuhkan aplikasi
pendukung lainnya (software dependencies) maupun perangkat keras (hardware) yang
benar-benar mendukung (perangkat keras baru) agak kesulitan dalam proses
penyesuaian (serapan) sehingga dapat menyebabkan proses implementasi SDLC
“terkesan” stagnan.

B. SIKLUS PENGEMBANGAN PERANGKAT LUNAK (SWDLC)
Pengembangan sistem (sistem development) dapat berarti menyusun sistem yang
baru untuk menggantikan sistem yang lama secara keseluruhan atau memperbaiki

sistem yang sudah ada. Sistem yang lama perlu diperbaiki atau diganti disebabkan
karena beberapa hal, yaitu sebagai berikut :
1. Adanya permasalahan-permasalahan (problems) yang timbul di sistem yang
lama. Permasalahan yang timbul dapat berupa :

 Ketidakberesan dalam sistem yang lama yang menyebabkan sistem yang lama
tidak dapat beroperasi sesuai dengan yang diharapkan.

 Pertumbuhan organisasi, yang menyebabkan harus disusunnya sistem yang
baru.

2. Untuk meraih kesempatan-kesempatan (opportunities), teknologi informasi
telah berkembang dengan cepatnya. Perangkat keras komputer, perangkat
lunak dan teknologi komunikasi telah begitu cepat berkembang.

5

3. Adanya instruksi-instruksi (directives), penyusunan sistem yang baru dapat
juga terjadi karena adanya instruksi-instruksi dari atas pimpinan ataupun dari
luar organisasi. Karena adanya permasalahan, kesempatan atau instruksi, maka

sistem yang baru perlu dikembangkan untuk emecahkan permasalahanpermasalahan yang timbul, meraih kesempatan-kesempatan yang ada atau
memenuhi instruksi yang diberikan.

Gambar 1. Pengembangan Sistem Informasi

Sistem yang baik adalah sistem yang selalu menyesuaikan dengan perubahan
lingkungan yang terjadi disekitarnya atau sistem tersebut harus dinamis menuju pada
keadaan

yang

lebih

baik.

6

Gambar 2. Tahapan Perancangan Sistem Informasi

Tahap awal, yaitu tahap perencanaan, menyangkut studi kebutuhan user, studi

kelayakan baik secara teknis maupun teknologi serta penjadwalan pengembangan suatu
proyek sistem informasi.

Tahap berikutnya adalah tahap analisis, yaitu tahap dimana kita berusaha
mengenali segenap permasalahan yang muncul pada pengguna, mengenali komponenkomponen sistem, obyek-obyek, hubungan antar obyek dan sebagainya.

Kemudian tahap ketiga adalah tahap perancangan, yaitu tahap dimana kita
mencoba mencari solusi permasalahan yang didapat dari tahap analisis.

Tahap keempat adalah tahap implementasi dimana kita mengimplementasikan
perancangan sistem ke situasi yang nyata. Pada tahap ini. Kita mulai dengan pemilihan
perangkat keras, penyusunan perangkat lunak aplikasi (pengkodean/coding) apakah
sistem yang dibuat sudah sesuai dengan kebutuhan user atau belum.. Jika belum, proses
selanjutnya adalah iteratif, yaitu kembali ke tahap-tahap sebelumnya. Disinilah

7

keuntungan metodologi berorientasi obyek mulai terlihat, dimana mulai dari tahap
analisis hingga tahap implementasi, kita bisa menggunakan tool yang sama sehingga
proses iteratif itu dapat berjalan dengan lebih efektif serta efisien ditinjau dari segi uang

dan waktu.
Kemudian tahap yang terakhir adalah tahap pemeliharaan / perawatan, dimana
kita bisa mulai melakukan pengoperasian sistem dan jika diperlukan dapat melakukan
perbaikan-perbaikan kecil. Kemudian jika waktu penggunaan sistem habis, maka kita
akan masuk lagi pada tahap perencanaan.

Mengorganisasi Proyek Pengembangan Perangkat Lumak
Perancang dan analis sistem terlibat dalam tim pengembangan perangkat lunak
dan harus mengetahui bagaimana program ini dikode dan bagaimana hasil akhirnya.
Untuk

itu

diperlukan

keterampilan

pengorganisasian

dalam

tim

proyek.

Pengorganisasian proyek pengembangan perangkat lunak memerlukan komunikasi,
integrasi dan koordinasi yang baik. Pengorganisasian tim pemrograman menggunakan
pendekatan organisasional.

Pendekatan Organisasional
Tiga cara untuk mengorganisasi tim pemrograman, yaitu :

 Tim Pengembangan Program ( Program development team)
 Tim programmer kepala (chief programmer team)

 Tim pemrograman bersama (Egoless programming team)
1. Tim Pengembangan Program ( Program development team)
Tim pengembangan program dikelola oleh manajer tim atau seseorang yang
terlibat dalam SDLC dari awal, dan didukung oleh perancang, pengkode, dan penguji
(Gb.1.4 hal.14 Diktat kuliah) Jika perusahaan menggunakan aturan 40-20-40 (lihat

gb.1.5 hal.15 Buku Diktat Pengantar Implementasi) maka orang-orang yang memiliki
keterampilan lebih tinggi harus ditugaskan untuk perancangan dan pengujian. Bila
rancangan lengkap, jelas dan akurat maka tugas pengkodean akan menjadi proses yang
sederhana yang dapat dijalankan oleh setiap orang yang telah kenal dengan sintaks
bahasa pemrograman. Konsep ini mendukung terciptanya teknologi CASE.

8

2. Tim programmer kepala (chief programmer team)
Tim ini dibentuk dari programmer kepala atau senior yang banyak pengalaman
dan pengetahuan pemrograman. Programmer kepala dapat berkomunikasi secara efektif
dengan analis dan perancang sistem, pemakai, dan berbagai teknisi.
Programmer kepala didukung oleh asisten utama yang bertugas sebagai
komunikator dengan orang lain pada tim atau penyampai informasi dari gagasan
programmer kepala. Kedua orang tersebut didukung oleh Programmer pendukung/
yunior bertugas membantu programmer kepala dan asisten utama untuk proyek besar
yang tidak dapat ditangani sendiri. Para programmer pendukung biasanya mengkode
modul-modul tingkat rendah. Tim ini juga didukung oleh pustakawan, administrator,
editor, dan klerk program.

3. Tim pemrograman bersama (Egoless programming team)
Tim ini terbentuk dari seluruh rekan yang bersama-sama bertanggung jawab atas
pengembangan perangkat lunak tanpa supervisi langsung/pimpinan.

Perbedaan pendekatan-pendekatan tersebut :



Tim pengembangan program mengembangkan aturan 40-20-40 yaitu
menekankan pada perancangan dan pengujian.
Tim programmer kepala dan tim pemrograman bersama menekankan pada
fungsi pengkodean.

Jumlah interface dan lintasan komunikasi dari pendekatan di atas :


Tim pengembangan program tersusun atas 2 perancang, 1 pengkode, 2
penguji. Interface dan lintasan komunikasi berada antara perancang dan
pengkode, pengkode dan penguji, perancang dan penguji. Interface dan
lintasan komunikasi ke manajer tim hanya memberikan rekapitulasi dan
informasi kinerja karena manajer tidak terlibat langsung dalam pekerjaan
yang sebenarnya. Jadi total interface dan lintasan komunikasi ada lima, dan
satu interface manajemen.

9

 Tim programmer kepala terdiri dari lima programmer pendukung mempunyai
lima interface dan lintasan komunikasi, dan lebih mungkin memenuhi deadline
yang ketat.

 Tim pemrograman bersama terdiri dari lima programmer. Jumlah interface dan
lintasan komunikasi = n(n-1)/2= 5(5-1)/2=10

10

Biasanya untuk komunikasi membutuhkan waktu dan mengurangi produktivitas.
Segala jenis pekerjaan pengembangan biasanya waktu restart (mulai lagi) setelah setiap
interupsi besarnya 30 menit sehingga peluang pemrograman yang bisa dilakukan
waktunya sedikit.

Oleh karena itu apabila terdapat lebih dari tiga programmer yang terlibat maka
sebaiknya ditetapkan seorang supervisor atau pimpinan.

Didalam dunia perangkat lunak, penggunaan berulang merupakan hal yang biasa.
Contohnya ide dan formula yang hampir sama digunakan berulang oleh programmer
yang berbeda untuk mengembangkan aplikasi keuangan yang khusus diadaptasikan
sesuai kebutuhan dan permintaan masing-masing klien. Oleh karena itu penggunaan
berulang suatu obyek
merupakan hal yang seharusnya bisa dilakukan. Suatu obyek bisa diambil untuk
dimodifikasi berupa penambahan atau pengulangan untuk memecahkan suatu masalah
baru.
Ada empat prinsip dasar dari pemrograman berorientasi obyek, yaitu :abstraksi,
enkapsulasi, modularitas dan hirarki.

Abstraksi :
Memfokuskan perhatian pada karakteristik obyek yang paling penting dan paling
dominan yang bisa digunakan untuk membedakan obyek tersebut dari obyek lainnya.
Dengan abstraksi ini developer bisa menerapkan konsep KIS (Keep It Simple) pada
obyek didunia nyata yang memiliki tingkat kerumitan yang tinggi.

Enkapsulasi:
Menyembunyikan banyak hal yang terdapat dalam obyek yang tidak
perludiketahui oleh obyek lain. Dalam praktek pemrograman enkapsulasi diwujudkan
dengan membuat suatu kelas interface yang akan dipanggil oleh obyek lain, sementara
didalam obyek yang dipanggil terdapat kelas lain yang mengimplementasikan apa yang
terdapat dalam kelas interface. Obyek lain hanya tahu dia perlu memanggil kelas
interface tanpa perlu tahu proses apa saja yang dilakukan didalam kelas

11

implementasinya dan untuk menuntaskan proses tersebut perlu berhubungan dengan
obyek mana saja. Dengan demikian bila terjadi proses perubahan pada proses
implementasi maka obyek pemanggil tidak akan terpengaruhi secara langsung.

Modularitas :
Membagi sistem yang rumit menjadi bagian-bagian yang lebih kecil yang bisa
mempermudah developer memahami dan mengelola obyek tersebut. Contohnya
adalah sistem akademis yang bisa dibagi menjdi kemahasiswaan, daftar mata kuliah,
pembayaran uang kuliah, dan lain-lain.

Hirarki :
Hirarki berhubungan dengan abstraksi dan modularitas, yaitu pembagian
berdasarkan urutan dan pengelompokkan tertentu. Misalnya untuk menentukan obyek
mana yang berada pada kelompok yang sama, obyek mana yang merupakan komponen
dari obyek yang memiliki hirarki lebih tinggi. Semakin rendah hirarki obyek berarti
semakin jauh abstraksi dilakukan terhadap suatu obyek. Ke empat prinsip dasar ini
merupakan hal yang mendasari teknologi obyek yang perlu ditanamkan dalam cara
berpikir developer berorientasi obyek.

C. PENGUJIAN PERANGKAT LUNAK
Pengujian Perangkat Lunak adalah elemen kritis dari jaminan kualitas perangkat
lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean.

Dasar-dasar Pengujian Perangkat Lunak
Pengembang perangkat lunak sesuai dengan sifatnya dasar, mereka adalah manusia
pembangun. Pengujian mengharuskan pengembang membuang pemikiran-pemikiran
sebelumnya mengenai “kebenaran” perangkat lunak yang baru saja dikembangkan
dan mengatasi konflik minat yang terjadi pada saat kesalahan ditemukan.

Sasaran Pengujian
1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan
kesalahan.

12

2. Pengujian yang sukses adalah pengujian yang memiliki probabilitas tinggi untuk
menemukan dan mengungkapkan semua kesalahan yang belum pernah ditemukan
atau diduga sebelumnya.
Prinsip Pengujian
1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.
2. Pengujian harus direncanakan lama sebelum pengujian itu mulai.
3. Pengujian harus mulai “dari yang kecil” dan berkembang menjadi pengujian “yang
besar”.
Karakteristik yang Membawa Perangkat Lunak Dapat Diuji
1. Operabilitas, yaitu : Semakin baik Dia bekerja, semakin efisien Dia dapat diuji.
2. Obsaikervabilitas, yaitu : “Apa yang Anda lihat adalah apa yang Anda uji”.
3. Kontralabilitas, yaitu : “Semakin baik kita dapat mengontrol perangkat lunak,
semakin banyak pengujian yang dapat diotomasisasi dan dioptimalkan”.
4. Dekomposabilitas, yaitu : “Dengan mengontrol ruang lingkup pengujian, kita dapat
dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara
lebih halus”.
5. Kesederhanaan, yaitu : “Semakin sedikit yang kita uji, semakin cepat kita dapat
mengujinya’.
6. Stabilitas, yaitu : “Semakin sedikit perubahan, semakin sedikit pula gangguan dalam
pengujian’.
7. Kemampuan untuk dapat dipahami, yaitu : “Semakin banyak informasi yang kita
miliki, semakin halus pengujian yang akan dilakukan’.

Atribut--atribut pengujian yang baik :
1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.
2. Pengujian yang baik tidak redudan.
3. Pengujian yang baik seharusnya “jenis terbaik”,
4. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks.

Tujuan Pengujian :

 Menjalankan program untuk menemukan error yang tersembunyi atau yang

sebelumnya tidak terduga.

13

Fase Pengujian
Ada 2 tingkat yang tersedia pada proses pegujian, yaitu :
1. Konfigurasi perangkat lunak yang mencakup spesifikasi keperluan perangkat lunak,
spesifikaasi perancangan, test case dan program sumber
2. Konfigurasi uji coba yang mencakup rencana dan prosedur uji coba, test case dan
hasil yang diharapkan

Condition Testing
Pengujian yang menjalankan kondisi logis yang terdapat pada modul program.

Data Flow Testing
Pengujian dengan metode yang menyeleksi jalur uji program menurut lokasi
pendefinisian dan menggunakan variable-variabel program

Loop Testing
Pengujian yang berfokus pada validitas dari bentuk loop
1.

simple loop

2.

concatenated loop

3.

nested loop

4.

unstructured loop

D. STRATEGI DAN RENCANA PENGUJIAN
Isu-isu utama yang akan diangkat berkaitan dengan pelaksanaan pengujian adalah
efektivitas dan efisiensi pengujian. Dengan kata lain, usaha yang terus menerus untuk
diarahkan dalam pengurangan persentase kesalahan tidak terdeteksi yang tersisa di
perangkat lunak atau sistem yang diuji pada satu sisi, dan untuk kinerja pengujian
dengan mnghabiskan sumber daya lebih sedikit di sisi lain.

Perencanaan, perancangan dan pelaksanaan pengujian dilakukan selama proses
pengembangan perangkat lunak. Kegiatan ini dibagi secara bertahap, dimulai pada tahap
desain dan berakhir ketika perangkat lunak diinstal di lokasi pelanggan.

14

Isu utama bahwa metodologi pengujian harus bersaing adalah:
 Standar kualitas perangkat lunak yang diperlukan,
 Strategi pengujian perangkat lunak.

Keputusan tentang kedua isu ini sangat mendasar dan harus dilakukan sebelum
perencanaan dimulai.

Perencanaan pengujian
Pengujian yang akan direncanakan meliputi:
 Unit pengujian

 Integrasi pengujian
 Sistem pengujian

Sementara menghadapi tes unit dengan unit kecil dari perangkat lunak atau modul,
integrasi menghadapi tes dengan beberapa unit yang menggabungkan ke dalam
sistem. Sistem tes merujuk ke paket perangkat lunak seluruh / sistem. Adalah tugas
perencana untuk mempertimbangkan hal-hal berikut sebelum memulai rencana tes
khusus:

 Apa yang akan diuji?

 Sumber-sumber apa yang digunakan untuk uji kasus?
 Siapa yang melakukan pengujian?

 Dimana tempat melakukan pengujian?
 Kapan harus mengakhiri pengujian?
Apa yang akan diuji?
Pendekatan langsung untuk pengujian yang sempurna akan merekomendasikan rencana
pengujian perangkat lunak lengkap dan komprehensif yang melakukan uji unit untuk
semua unit individu, uji integrasi untuk semua integrasi unit, dan uji sistem untuk
menguji paket perangkat lunak secara keseluruhan. Menerapkan rencana secara
“langsung” memang memastikan kualitas perangkat lunak yang tinggi tetapi juga
memerlukan investasi sumber daya yang luas dan jadwal yang panjang.

Berkaitan dengan itu , pertanyaan-pertanyaan tertentu yang umum akan muncul :

15

Situasi yang berkaitan dengan manfaat dari pendekatan semacam itu. Sebagai contoh:
 Apakah dibenarkan untuk melakukan pengujian unit

untuk sebuah modul yang

terdiri dari 98% perangkat lunak yang reuse ?

 Apakah pengujian unit wajib dilakukan pada modul sederhana yang menampilkan
modul versi 12 dari modul dasar yang digunakan berulang kali oleh tim pengembang
selama tiga tahun terakhir?

Hanya dalam kasus yang jarang itu dibenarkan untuk menguji “segalanya”. Biasanya,
kelayakan pengujian “segalanya” sangat terbatas. Terlepas dari kinerja dari daftar tes
yang ditentukan dalam kontrak atau diperlukan oleh prosedur pengembang (misalnya
beban tes untuk sistem secara keseluruhan), beberapa pertimbangan untuk tes yang
akan diterapkan, antara lain :
 Unit modul mana yang harus diuji?
 Integrasi mana yang harus diuji?

 Prioritas menentukan pengalokasian sumber daya pengujian kepada sistem aplikasi
perangkat lunak individu. Akibatnya,aplikasi yang mendapat prioritas rendah diuji
dengan hanya beberapa jenis tes atau tidak termasuk dalam pengujian sistem sama
sekali.

Dalam menentukan apa yang harus dimasukkan dan apa yang dikecualikan dari uji
sistem, uji unit dan uji integrasi yang sudah direncanakan harus dipertimbangkan.
Untuk kualitas perangkat lunak dari aplikasi dan modul yang tidak dicakup oleh uji
unit, integrasi dan sistem, kami mengandalkan cek kode yang dilakukan oleh
programmer dan pemimpin timnya serta inspeksi kode dan walkthrough diprakarsai
oleh tim pengembangan.

Siapa yang melakukan pengujian?
Siapa yang akan melakukan berbagai tes ditentukan pada tahap perencanaan :
 Uji integrasi ,

terutama uji unit, umumnya dilakukan oleh tim pengembangan

perangkat lunak. Dalam beberapa kasus itu adalah unit pengujian yang melakukan
pengujian.

16

 Uji sistem biasanya dilakukan oleh tim uji independen (pengujian tim internal atau
pengujian tim konsultan eksternal).

 Dalam kasus sistem perangkat lunak yang lebih besar, lebih dari satu tim pengujian
dapat digunakan untuk melakukan pengujian sistem. Keputusan prasyarat yang akan
dibuat pada kasus yang harus dipertimbangkan adalah alokasi tes sistem antara
internal dan tim pengujian eksternal.

17

E. PENGUJIAN WHITE BOX DAN METODENYA
White Box Testing
Merupakan 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 logikal

 Mengerjakan seluruh loop yang sesuai dengan batasannya

 Mengerjakan seluruh struktur data internal yang menjamin validitas

A. Uji Coba Basis Path
Merupakan teknik uji coba white box yang diusulkan Tom McCabe. Metode ini
memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari
perancangan prosedural dan menggunakan ukuran ini sebagai petunjuk untuk
mendefinisikan basis set dari jalur pengerjaan. Test case yang didapat digunakan
untuk mengerjakan basis set yang menjamin pengerjaan setiap perintah minimal satu
kali selama uji coba.

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

18

daerah diluar grafik alir. Contoh menterjemahkan pseudo code ke grafik alir

Nomor pada pseudo code berhubungan dengan nomor node. Apabila ditemukan kondisi
majemuk (compound condition) pada pseudo code pembuatan grafik alir menjadi
rumit. Kondisi majemuk mungkin terjadi pada operator Boolean (AND, OR, NAND,
NOR) yang dipakai pada perintah if. Contoh :

19

Node dibuat terpisah untuk masing-masing kondisi A dan B dari pernyataan IF A OR B.
Masing-masing node berisi kondisi yang disebut pridicate node dan mempunyai
karakteristik dua atau lebih edge darinya.

Cyclomatic Complexity
Cyclomatic complexity adalah metrik software 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 independent adalah jalur yang melintasi atau
melalui program dimana sekurang-kurangnya terdapat proses perintah yang baru atau
kondisi yang baru.

20

Dari gambar:
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 diatas merupakan basis set untuk diagram alir.

Cyclomatic complexity digunakan untuk mencari jumlah path dalam satu flowgraph.
Dapat dipergunakan rumusan sebagai berikut :
1. Jumlah region grafik alir sesuai dengan cyclomatic complexity.
2. 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
3. Cyclomatix complexity V(G) juga dapat dihitung dengan rumus:
V(G) = P + 1
Dimana P = jumlah predicate node pada grafik alir

Pada Gambar dapat dihitung cyclomatic complexity:
1. Flowgraph mempunyai 4 region
2. V(G) = 11 edge - 9 node + 2 = 4

21

3. V(G) = 3 predicate node + 1 = 4
Jadi cyclomatic complexity untuk flowgraph adalah 4

Melakukan Test Case
Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci
atau program sumber. Prosedur rata-rata pada bagian berikut akan digunakan sebagai
contoh dalam pembuatan test case.

Langkah-Iangkah pembuatan test case:
1. Dengan mempergunakan perancangan prosedural atau program sumber sebagai
dasar, digambarkan diagram alirnya.

2. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat:
V(G) = 6 region

22

V(G) = 17 edge - 13 node + 2 = 6
V(G) = 5 predicate node + 1 = 6
3. 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-...
4. 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.

Graph Metrik
Graph metrik merupakan software yang dikembangkan untuk membantu uji coba
basis path atau struktur data. Graph metrik adalah matrik empat persegi yang
mempunyai ukuran 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.

Contoh sederhana pemakaian graph metrik dapat digambarkan sebagai
berikut :

23

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
B. Pengujian 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 : loop sederhana, loop tersarang, loop
terangkai, loop tidak terstruktur.