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. 2.1.4.1 Unit Testing Gambar II-1 Tingkatan pengujian perangkat lunak beserta proses pengujiannya[pez08] 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 CUnit CppUnit JSUnit Smalltalk C C++ 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 people_list (person*)> <!ELEMENT person (name, birthdate?, gender?, socialsecuritynumber?)> <!ELEMENT name (#PCDATA)> <!ELEMENT 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>