DRAFT BUKU LAPORAN

BAB II
TINJAUAN PUSTAKA
2.1 Software Testing
2.1.1 Pengertian
Software testing atau pengujian perangkat lunak dapat didefinisikan sebagai sebuah proses
atau rangkaian proses yang dirancang untuk memastikan bahwa kode program akan bekerja
sesuai dengan rancangan serta memastikan bahwa program tidak melakukan hal yang tidak
diharapkan [MYE04]. Menemukan error atau kesalahan merupakan hal utama dalam
software testing. Menemukan kesalahan dan memperbaikinya lebih awal akan meminimalkan
cost atau usaha yang diperlukan untuk memperbaiki kesalahan pada tahapan selanjutnya.
2.1.2 Tujuan Software Testing
Software testing dilakukan untuk berbagai tujuan antara lain [PAN99]:
a. Meningkatkan kualitas
Komputer dan perangkat lunak makin memiliki peran besar dalam beberapa aplikasi yang
penting sehingga munculnya bug (kesalahan dalam program) dapat menjadi hal yang fatal.
Munculnya bug dapat menyebabkan kerugian yang besar. Dalam dunia yang sangat
bergantung pada kinerja komputer, kualitas dan reliabilitas dari sebuah perangkat lunak
merupakan persoalan penting.
Perangkat lunak dibangun karena adanya kebutuhan dari user dan diharapkan mampu
mengakomodasi semua kebutuhan user. Perangkat lunak dikatakan berkualitas jika
mampu bekerja sesuai dengan semua kebutuhan yang diinginkan user. Pengujian
dilakukan untuk menjamin bahwa fungsionalitas perangkat lunak sudah sesuai dengan
kebutuhan user, serta menjamin bahwa perangkat lunak terbebas dari error sehingga
menghasilkan perangkat lunak berkualitas tinggi.
b. Berasosiasi dengan proses Verifikasi dan Validasi (V & V)
Verifikasi adalah proses pengecekan atau pengujian terhadap sebuah perangkat lunak
apakah sudah memenuhi spesifikasi yang ditetapkan oleh tim pengembang. Sedangkan
validasi adalah sebuah proses pengujian terhadap perangkat lunak apakah sudah
memenuhi kebutuhan yang disyaratkan oleh pengguna (end users) [PAT05].
II-1
II-2
Proses verifikasi dan validasi dalam lingkup perangkat lunak dapat dilakukan dalam
bentuk software testing. Proses unit testing, integration testing, dan system testing
bertujuan untuk verifikasi sedangkan proses paling akhir yaitu acceptance testing yang
berfungsi sebagai proses validasi karena berhubungan langsung dengan penerimaan
pengguna.
c. Estimasi reliabilitas perangkat lunak
Reliabilitas adalah sebuah ukuran probabilitas atau kemungkinan fungsi yang berjalan
tepat pada penggunaan perangkat lunak, baik penggunaan satu kali maupun penggunaan
pada suatu periode waktu [PEZ08].
Software testing dapat berfungsi sebagai metode untuk mengukur reliabilitas perangkat
lunak, dilihat dari sisi ketepatan program. Pengujian yang dilakukan akan mampu
menghasilkan data statistik dari performansi perangkat lunak sehingga dapat digunakan
untuk estimasi reliabilitas perangkat lunak.
2.1.3 Metode Pengujian Perangkat Lunak
Metode melakukan pengujian perangkat lunak dapat dibagi menjadi dua cara yaitu black box
testing dan white box testing. Kedua metode pengujian ini membedakan sudut pandang
terhadap perangkat lunak saat merancang kasus uji.
a. Black-box Testing
Black-box testing adalah metode pengujian di mana data uji diturunkan dari spesifikasi
tanpa mempertimbangkan struktur internal dari program yang diuji [MYE04]. Perhatian
utama dalam black-box testing adalah fungsionalitas program. Karena itu black-box testing
sering juga disebut sebagai functional testing, yaitu sebuah metode pengujian yang fokus
pada eksekusi fungsi dalam program dan mengamati data input dan output [HOW87].
Dalam melakukan black-box testing, penguji hanya akan memperhatikan data masukan
untuk pengujian dan data keluaran sebagai hasil eksekusi program tanpa melihat perilaku
program dalam mengeksekusi data uji. Data keluaran program akan diperiksa
kesesuaiannya dengan spesifikasi. Untuk mendapatkan tingkat kepercayaan akan kualitas
perangkat lunak yang tinggi maka pada pendekatan black-box sebaiknya digunakan data
uji yang bersifat menyeluruh, mampu mewakili setiap kasus yang mungkin terjadi.
b. White-box Testing
White-box testing adalah metode pengujian yang memeriksa struktur internal dari sebuah
program. Kasus uji diturunkan dari hasil pemeriksaan terhadap logic program [MYE04].
Kasus uji yang dirancang dalam white-box testing memiliki tujuan antara lain [WHI08]:
II-3
1. Menjamin bahwa setiap path (alur jalannya program) dalam sebuah modul telah diuji
minimal satu kali
2. Menguji semua aspek kondisional, baik dari kondisi true maupun false
3. Mengeksekusi semua pengulangan, baik pada batasan yang masih memenuhi kondisi
pengulangan maupun batasan yang sudah termasuk terminasi pengulangan
4. Menguji semua struktur data internal pada program
Dalam melakukan white-box testing diperlukan kemampuan pemrograman untuk mampu
mengamati semua aspek internal program sehingga mampu menghasilkan kasus uji yang
baik dan dapat menguji program secara menyeluruh.
2.1.4 Proses Pengujian Perangkat Lunak
Proses pengujian perangkat lunak dilakukan di setiap tingkatan pengembangan perangkat
lunak, mulai dari tingkat paling awal yaitu unit sampai pada tingkat sistem yang sudah
terintegrasi. Proses pengujian perangkat lunak antara lain: unit testing, integration testing,
system testing, dan user acceptance testing.
Gambar II-1 Tingkatan pengujian perangkat lunak beserta proses
pengujiannya[PEZ08]
2.1.4.1 Unit Testing
2.1.4.1.1
Pengertian
Unit testing adalah sebuah proses untuk menguji sebuah bagian atau komponen tertentu
dalam kode program untuk menentukan apakah komponen tersebut berfungsi dengan benar
[DUS03]. Komponen program yang diuji pada tingkat unit testing adalah subprograms,
subroutines, atau prosedur [MYE04]. Sebuah komponen atau bagian kecil dari kode program
dinyatakan belum lengkap atau sempurna apabila belum dilakukan unit testing. Unit testing
II-4
yang dilakukan dengan benar akan mampu membantu keberhasilan pengujian di tingkat
selanjutnya.
2.1.4.1.2
Tujuan Unit Testing
Beberapa tujuan yang dapat dicapai dengan unit testing antara lain [HUN03]:
a. Menjaga ketepatan jalannya program
Unit testing membantu meyakinkan programmer bahwa kode program yang ditulisnya
adalah kode program yang bisa bekerja sesuai dengan apa yang diinginkan programmer.
b. Memastikan program berjalan dalam tiap kondisi
Pengujian yang dilakukan satu kali dan kode program mampu lolos terhadap kasus uji
tersebut belum merupakan jaminan bahwa program sudah mampu bekerja dengan
sempurna. Berbagai kondisi dalam dunia nyata tidak selalu dapat diasumsikan
mendukung keberjalanan program. Sebagai contoh: munculnya exceptions, media
penyimpanan penuh, jalur komunikasi jaringan yang bermasalah, buffers overflow, dan
adanya bug dalam program.
Berbagai kemungkinan terburuk harus dipertimbangkan dan diatasi lebih dini oleh
programmer. Sama seperti tujuan sebelumnya, selain memastikan bahwa program
berjalan dengan tepat, harus dipastikan juga bahwa ketepatan program akan berjalan
sepanjang waktu dalam kondisi apapun.
c. Menguji batasan program
Setiap perangkat lunak yang dibangun memiliki keterbatasan masing-masing dalam
menangani kasus-kasus tertentu. Programmer sebaiknya mengetahui letak kelebihan
serta keterbatasan kode program yang dibangunnya. Salah satu cara untuk mengetahui
kelebihan dan keterbatasan program adalah dengan melakukan unit testing.
Dengan melakukan unit testing terhadap kode program, ketika programmer menemukan
sebuah kasus yang gagal ditangani oleh programnya maka programmer sudah mampu
mengetahui keterbatasan kode programnya dalam menangani kasus tersebut.
Selanjutnya, programmer dapat mendokumentasikan keterbatasan dari kode program
tersebut dan dapat membuat sebuah penanganan kesalahan untuk kasus-kasus khusus
yang gagal ditangani secara normal oleh program.
II-5
d. Sebagai dokumentasi program
Salah satu keuntungan unit testing adalah bahwa unit testing mampu membantu
programmer dalam mengkomunikasikan maksud penggunaan kode program. Sebuah
unit test mampu berlaku sebagai sebuah dokumentasi executable yang menunjukkan
cara program bekerja pada beberapa kondisi tertentu. Hasil unit testing dapat digunakan
sebagai panduan bagi programmer lain untuk mengetahui cara menggunakan program
tersebut.
Hasil unit testing didapatkan langsung dari eksekusi sebuah kasus uji terhadap kode
program tertentu. Oleh karena itu, dapat dipastikan bahwa hasil unit testing ini akan
selalu benar, tidak jauh menyimpang, sesuai dengan kondisi kode program yang
sebenarnya.
2.1.4.1.3
Test-Case Design
Diperlukan dua jenis informasi untuk merancang test case atau kasus uji untuk unit test yaitu:
spesifikasi modul dan kode program dari modul atau komponen yang akan diuji [MYE04].
Spesifikasi dari sebuah modul biasanya mendefinisikan parameter input dan output, serta
fungsi modul.
Unit testing sebagian besar menggunakan metode white-box testing. Namun dalam membuat
kasus uji digunakan juga metode black-box. Langkah dalam menulis kasus uji untuk unit
testing adalah pertama melakukan analisis terhadap logic atau alur kerja dari program
menggunakan
metode
white-box,
kemudian
kasus
uji
dilengkapi
dengan
cara
mengaplikasikan metode black-box terhadap spesifikasi modul yang akan diuji [MYE04].
Aplikasi metode black-box ini diperlukan karena pengujian akan dilakukan terhadap sebuah
entitas yang besar yaitu keseluruhan program sehingga white-box testing akan semakin sulit
digunakan. Selain itu, proses pengujian lebih berorientasi pada pencarian berbagai macam
errors (kesalahan) pada program.
2.1.4.2 Integration Testing
Integration testing merupakan proses pengujian yang dilakukan setelah unit testing.
Integration testing dilakukan agar tim pengembang mampu mengontrol dan mengamati
kelakuan sekumpulan modul yang diintegrasi [PEZ08].
Dalam tahapan ini, beberapa modul individual perangkat lunak mulai disatukan dan diuji
sebagai sebuah kesatuan. Masukan integration testing adalah beberapa modul yang sudah
melalui proses unit testing, kemudian modul tersebut disatukan dan dilakukan pengujian
II-6
berdasarkan apa yang sudah direncanakan. Sebaiknya pengujian ini dimulai dengan
sekelompok kecil modul yang disatukan untuk mengurangi kompleksitas pengujian [PEZ08].
Sekumpulan modul akan diuji melalui interface-nya dengan menggunakan metode black-box
testing. Penggunaan data secara bersama-sama serta komunikasi antar proses juga diuji.
Kasus uji pada integration testing dirancang agar mampu menguji semua komponen yang
diintegrasikan untuk dapat saling berinteraksi dengan tepat sesuai dengan spesifikasi. Sebagai
contoh adalah interaksi untuk pemanggilan prosedur lintas modul atau interaksi untuk
mengaktifkan sebuah proses.
2.1.4.3 System Testing
System testing adalah pengujian yang dilakukan pada sebuah sistem yang sudah terintegrasi
dengan tujuan untuk mengevaluasi kemampuan sistem dalam memenuhi requirement
[MYE04].
System testing dilakukan dengan metode black-box testing sehingga untuk melaksanakannya
tidak diperlukan pengetahuan mendalam tentang kode program. Semua komponen sistem
yang telah diuji pada integration testing kemudian disatukan menjadi satu kesatuan sistem
dan kemudian dilakukan system testing.
Kasus uji pada system testing dibuat berdasarkan requirement perangkat lunak karena fokus
pada system testing adalah menguji kemampuan sistem dalam memenuhi requirement tanpa
memperhatikan kode program [PEZ08]. Selain itu pada system testing juga diuji beberapa
aspek umum performansi sistem misalnya kecepatan respond sistem. Untuk mendukung hal
ini maka dapat dilakukan simulasi eksekusi sistem pada lingkungan yang menyerupai
lingkungan operasionalnya.
2.1.4.4 User Acceptance Testing
User acceptance testing adalah sebuah proses pengujian yang membandingkan perangkat
lunak dengan requirement awal dan kebutuhan end users [MYE04]. Tujuan utama user
acceptance testing adalah sebagai panduan pengambilan keputusan apakah produk perangkat
lunak sudah dapat dirilis [PEZ08].
User acceptance testing dilaksanakan oleh customer dengan bantuan dari tim programmer.
Pengujian ini merupakan proses pengujian paling akhir dan dilaksanakan sebelum serah
terima perangkat lunak kepada customer. Customer melaksanakan pengujian ini berdasarkan
perencanaan pengujian yang sudah disusun oleh tim pengembang yang diturunkan dari
kontrak awal pembangunan perangkat lunak atau dari user requirements spesification. Hasil
II-7
dari pengujian ini akan memberikan tingkat kepercayaan yang tinggi di customer bahwa
perangkat lunak memiliki performansi yang baik ketika digunakan.
2.2 xUnit Framework
Istilah xUnit mengacu pada kumpulan kelompok Test Automation Frameworks yang
dirancang untuk mengotomatisasi proses pengujian oleh programmer dan memiliki
sekumpulan fitur yang sama [MES07]. Pembangunan xUnit framework didasarkan pada
rancangan Kent Beck yang mengimplementasi SUnit untuk bahasa Smalltalk [MES07]. Total
jumlah xUnit Framework yang sudah ada saat ini mencapai delapan puluh frameworks untuk
lebih dari enam puluh bahasa pemrograman [TES08].
Beberapa contoh anggota kelompok xUnit Frameworks terdapat pada Tabel II-1.
Tabel II-1 Contoh Anggota xUnit Framework
xUnit Framework
Bahasa Pemrograman
JUnit
Java
SUnit
Smalltalk
CUnit
C
CppUnit
C++
JSUnit
JavaScript
NUnit
C#
2.2.1 Tujuan
xUnit Framework dirancang untuk memenuhi beberapa tujuan antara lain [MES07]:
a. Memudahkan tim pengembang untuk menuliskan pengujian tanpa harus mempelajari
bahasa pemrograman baru karena xUnit Framework tersedia dalam berbagai macam
bahasa pemrograman yang sudah banyak digunakan.
b. Memudahkan tim pengembang untuk menguji kelas atau objek secara tersendiri tanpa
harus terlebih dahulu menyelesaikan keseluruhan perangkat lunak.
c. Memudahkan untuk menjalankan satu atau lebih pengujian dengan satu aksi karena dalam
xUnit framework terdapat konsep test suite, yaitu konsep untuk menyatukan beberapa
kasus uji dalam sebuah wadah yang disebut suite. Dalam sebuah test suite dapat berisi
beberapa kasus uji maupun test suite lain.
II-8
2.2.2 Fitur Utama
Anggota kelompok xUnit Framework mengimplementasikan beberapa kumpulan fitur dasar
yang sama. Fitur tersebut memungkinkan untuk dilakukannya beberapa aksi dasar dalam
pengujian misalnya [MES07]:
a. Menspesifikasikan sebuah pengujian sebagai sebuah test method.
Test method
adalah sebuah method atau prosedur yang fungsinya untuk melakukan
pengujian, pada test method terdapat pemanggilan method assertion (dijelaskan pada poin
di bawah).
b. Menspesifikasikan hasil yang diharapkan selama pengujian sebagai bentuk dari
pemanggilan method Assertion.
Assertion adalah method yang bertujuan untuk menentukan berhasil atau tidaknya sebuah
pengujian. Penentuan keberhasilan pengujian ini dilakukan dengan melakukan
perbandingan antara sebuah nilai yang diharapkan akan muncul dengan nilai aktual yang
muncul sebagai hasil program [WEB06].
c. Melakukan agregasi beberapa pengujian ke dalam sebuah test suite yang dapat dijalankan
dalam satu kali eksekusi
d. Menjalankan satu atau lebih pengujian serta mendapatkan report hasil pengujian
2.2.3 Struktur Dasar Pengujian
Sebuah kasus uji pada xUnit Framework tersusun atas empat fase berurutan yaitu [MES07]:
a. Set up
Set up merupakan tahapan awal yang dilakukan sebelum pengujian dijalankan. Set up
dilakukan dengan tujuan untuk menyiapkan lingkungan pengujian sesuai dengan
kebutuhan penguji. Sebagai contoh adalah inisialisasi variabel yang dibutuhkan saat
pengujian.
b. Melakukan pengujian dengan melakukan pemanggilan terhadap method atau prosedur
yang akan diuji
c. Melakukan pengecekan hasil pengujian yang dapat dilakukan dengan method assertion
d. Tear down
Tear down merupakan tahapan terakhir yang dilakukan setelah pengujian selesai.
Berlawanan dengan set up, tear down bertujuan untuk me-reset lingkungan pengujian
yang sebelumnya sudah dibangun pada fase set up sehingga semua kembali sama seperti
keadaan semula.
II-9
2.3 XML
Extensible Markup Language (XML) adalah sebuah standar keluaran World Wide Web
Consortium (W3C) untuk melakukan markup terhadap dokumen [HAR02]. Melakukan
markup artinya menambahkan kode atau penanda tertentu ke dalam dokumen yang bertujuan
untuk menjelaskan bagaimana menginterpretasikan data dalam dokumen tersebut [HOL03].
Dalam sebuah dokumen XML terdapat berbagai tag yang dapat didefinisikan sendiri oleh
pembuat dokumen XML tersebut. Oleh karena itu, XML diklasifikasikan sebagai extensible
language, maksudnya adalah bahasa ini bebas untuk diperluas atau disesuaikan dengan
berbagai keperluan pengguna [HAR02].
Ada dua aturan dalam memodelkan dokumen XML [RAY01] :
a. Well-formed. Sebuah dokumen dikatakan well-formed jika sudah sesuai dengan aturan
penulisan sintaks XML yang dikeluarkan oleh W3C.
b. Valid. Sebuah dokumen dikatakan valid jika sudah sesuai dengan beberapa aturan
semantik XML.
2.3.1 Dokumen Well-Formed
Setiap dokumen XML tanpa terkecuali harus memenuhi syarat well-formed. Beberapa
syaratnya antara lain [HAR02]:
a. Setiap elemen tidak kosong harus memiliki tag pembuka (start tag) harus disertai dengan
tag penutup (end tag) yang sesuai.
Contoh dari dokumen XML yang well-formed adalah sebagai berikut:
<book>Ini adalah sebuah buku...</book>
Sedangkan untuk elemen kosong harus diakhiri dengan tanda slash (/). Elemen kosong
adalah elemen yang tidak memiliki content atau isi. Contoh elemen kosong: <book
title = “Judul buku” />
b. Penyusunan
beberapa elemen XML dalam satu dokumen dilakukan secara nested
(bersarang) dengan benar. Elemen tidak dibolehkan saling mendahului (overlap), harus
ditutup dalam urutan yang benar yaitu berlawanan dengan urutan dibukanya setiap elemen.
Contoh dari penyusunan elemen yang salah:
<title>Book On Logic<author>Aristotle</title></author>
Penulisan yang benar untuk informasi yang sama adalah sebagai berikut:
II-10
<title>Book On Logic</title> <author>Aristotle</author>
c. Dalam satu dokumen wajib terdapat satu elemen root yang bisa beranggotakan berapapun
jumlah elemen XML. Contoh dokumen dengan satu elemen root yaitu document yang
terdiri atas dua elemen employee:
<document>
<employee>
.
</employee>
<employee>
.
</employee>
</document>
d. Nilai atribut harus diapit dengan tanda quote atau tanda petik (“). Contoh:
<document><heading text = “Hello” /></document>
Pada contoh di atas, atribut text memiliki nilai “Hello”.
e. Sebuah elemen tidak diperbolehkan memiliki dua atribut dengan nama yang sama. Contoh
dokumen yang salah:
<message text= “ Hi There!” text=”Hello”>
Untuk informasi yang sama dapat dibuat nama atribut berbeda seperti berikut:
<message Text=”Hi There!” text=”Hello!”>
Hal tersebut diperbolehkan karena XML bersifat case sensitive.
2.3.2 Dokumen Valid
Dokumen XML yang valid adalah dokumen yang mengikuti tata cara penulisan XML schema
(skema XML) yang ada [HOL03]. Terdapat beberapa XML schema misalnya Document Type
Definition (DTD) dan XML Schema yang dikeluarkan oleh W3C. Skema adalah aturan
formal yang mengatur bagaimana content atau data harus ditampilkan dalam dokumen XML
[DYK05]. Dokumen harus mengikuti aturan umum XML untuk memastikan bahwa semua
perangkat lunak yang bersifat XML-aware (mampu memproses XML) akan mampu membaca
dan mengerti pengaturan data dalam dokumen XML.
XML schema mengandung aturan sintaks dengan beberapa constraint (batasan) di dalamnya.
XML schema akan membatasi elemen, nama atribut elemen dan hirarki elemen yang
dibolehkan. Misalnya XML schema hanya memperbolehkan elemen dengan nama “person”
memiliki satu elemen dengan nama “name” . Sebagai contoh dari DTD adalah sebagai
berikut:
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
people_list (person*)>
person (name, birthdate?, gender?, socialsecuritynumber?)>
name (#PCDATA)>
birthdate (#PCDATA)>
II-11
<!ELEMENT gender (#PCDATA)>
<!ELEMENT socialsecuritynumber (#PCDATA)>
Dari skema di atas dapat diartikan sebagai berikut:
a. people_list adalah sebuah nama elemen yang valid, people_list berisi elemen
person dan penanda * berarti boleh ada 0 atau lebih elemen person dalam elemen
people_list
b. person adalah sebuah nama elemen yang valid, person berisi elemen name,
birthdate
(optional),
gender
(optional),
dan
socialsecuritynumber
(optional). Penanda ? berarti sebuah elemen bersifat optional.
c. name adalah sebuah nama elemen yang valid, dan name berisi “parsed character
data” (#PCDATA)
d. birthdate adalah sebuah nama elemen yang valid, dan birthdate berisi “parsed
character data” (#PCDATA)
e. gender adalah sebuah nama elemen yang valid, dan gender berisi “parsed
character data” (#PCDATA)
f.
socialsecuritynumber adalah sebuah nama elemen yang valid, dan berisi
“parsed character data” (#PCDATA)
Dari skema di atas, dokumen XML yang bersesuaian dengan skema tersebut adalah sebagai
berikut:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE people_list SYSTEM "example.dtd">
<people_list>
<person>
<name>Fred Bloggs</name>
<birthdate>27/11/2008</birthdate>
<gender>Male</gender>
</person>
</people_list>