BAB 1 PENDAHULUAN

1.1.

Latar Belakang
Kemajuan teknologi yang sangat pesat ditandai dengan semakin

banyaknya perangkat-perangkat teknologi informasi yang digunakan oleh masyarakat luas. Sekarang ini banyak terdapat beberapa paradigma yang digunakan dalam rekayasa software, diantaranya process-oriented methodologies, blended methodologies, object oriented methodologies, Rapid development methodologies, people oriented methodologies, dan frameworks. Semua metodologi tersebut berkembang dan digunakan sesuai dengan kebutuhan dari penggunanya. Metodologi yang digunakan dalam pengembangan sistem informasi adalah Object Oriented. Saat ini Object Oriented merupakan metodologi yang baik dalam rekayasa software. Object Oriented memandang software bagian per bagian dan menggambarkan satu bagian tersebut dalam satu objek. Tidak seperti paradigma lainnya, dimana hanya cocok untuk beberapa kasus dan bagian dari seluruh kemungkinan ruang lingkup aplikasi, khusus untuk object-oriented dapat diaplikasikan dalam seluruh ruang lingkup. Pengujian perangkat lunak adalah suatu proses yang digunakan untuk mengidentifikasi ketepatan, kelengkapan dan mutu dari perangkat lunak dalam ilmu komputer yang dikembangkan. Pada dasarnya, pengujiann tidak pernah dapat menetapkan kebenaran dari perangkat lunak. Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak itu sendiri. Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi,desain dan pengkodean.

1.2.

Batasan Masalah
Dalam pembuatan tugas makalah ini, terdapat 2 kategori yang menjadi

batasan masalah sekaligus menjadi batasan materi yang dibahas di dalam makalah ini, yaitu : 1. Pengujian berorientasi objek, yang meliputi: a. b. c. d. e. 2. Model pengujian OOA dan OOD. Strategi pengujian berorientasi objek. Desain test case untuk perangkat lunak berorientasi objek. Metode pengujian yang diaplikasikan pada tingkat kelas. Desain test case inter kelas.

Strategi pengujian perangkat lunak, yang meliputi: a. Pendekatan strategis terhadap pengujian perangkat lunak. b. Pengujian modul perangkat lunak. c. Pengujian terintegrasi. d. Uji validasi. e. Pengujian sistem. f. Seni debugging.

1.3.

Tujuan Penulisan
Pembuatan makalah ini memiliki beberapa bertujuan, diantaranya:

1) Agar mahasiswa memahami model pengujian berorientasi objek. 2) Agar mahasiswa memahami pentingnya verifikasi dan validasi terhadap produk yang akan diuji, pengorganisasian pengujian perangkat lunak, strategi pengujian perangkat lunak dan kriteria penyelesaian sebuah pengujian. 3) Agar mahasiswa memahami pertimbangan uji modul dan prosedurnya. 4) Agar mahasiswa memahami strategi top down dan bottom up dalam pengujian terintegrasi, pandangan terhadap pengujian terintegrasi dan dokumentasinya.

5) Agar mahasiswa memahami pengertian, kriteria, ulasan konfigurasinya, serta proses uji alfa dan beta dalam proses uji validasi. 6) Agar mahasiswa memahami aspek aspek pengujian sistem seperti: uji pemulihan, uji keamanan, uji stress dan uji kinerja. 7) Agar mahasiswa memahami proses debugging pertimbangan psikologi dan pendekatan debugging.

1.4.

Metode Penulisan
Metode penulisan dilakukan dengan dua tahap yang dijabarkan sebagai

berikut: a. Identifikasi Materi Pada tahap ini, penulis merumuskan latar belakang permasalahan dari materi yang dibahas di dalam makalah dengan tujuan tujuan dan batasan masalah terdapat pada materi makalah. b. Studi Literatur Membaca buku serta artikel yang berkaitan dengan tujuan penulisan.

1.5. Sistematika Penulisan

Sistematika penulisan ilmiah ini disajikan secara ringkas untuk menerangkan penjelasan masing masing bab yang terdapat dalam penulisan ilmiah ini. Berikut adalah sistematika penulisannya : BAB I PENDAHULUAN Bab ini menjelaskan tentang garis besar isi penulisan ilmiah ini yang terdiri dari Latar Belakang Masalah, Ruang Lingkup, Tujuan Penulisan, Metode Penulisan dan Sistematika Penulisan.

BAB II

PEMBAHASAN MATERI Bab ini menjelaskan materi yang akan dibahas. Pembahasan materi tersebut dapat berupa pengertian, definisi definisi dan lain lain.

BAB III

PENUTUP Bab ini akan terbagi menjadi dua bagian, yaitu kesimpulan dan saran. Kesimpulan merupakan hasil akhir dari penulisan dan jawaban penyelesaian masalah. Untuk sub bab saran akan ditujukan kepada pihak pihak yang terkait seperti penulis sehubungan dengan pengembangan atau perbaikan penulisan makalah ini.

BAB 2 PEMBAHASAN MATERI

2.1.

Pengujian Berorientasi Obyek

Pengujian merupakan suatu pengeksekusian program yang bertujuan untuk

menemukan bug (kesalahan-kesalahan) pada sistem atau perangkat lunak sebelum diberikan kepada pengguna/ user. Pada pengujian berorientasi obyek, komponen yang akan diuji adalah class object. Lebih besar dibandingkan pengujian suatu function sehingga pendekatan white-box testing perlu diperluas. Pengujian sebaiknya menemukan kesalahan yang tidak disengaja dan pengujian dinyatakan sukses jika berhasil memperbaiki kesalahan tersebut. Selain itu, pengujian juga bertujuan untuk menunjukkan kesesuaian fungsi-fungsi perangkat lunak dengan spesifikasinya. Pengujian dapat dikategorikan atas : 1) Pengujian terhadap proses pengembangan sistem dan dokumen dokumen pendukung. Proses berarti sejumlah aktivitas yang didukung oleh dokumen yang mendeskripsikan aktivitas-aktivitas. 2) Pengujian terhadap analisis dan model perancangan. Dalam sistem berorientasi objek, pengujian model analisis dan perancangan adalah hal yang sangat penting. 3) Pengujian secara statik dan dinamik untuk implementasi. Tujuannya adalah mencari kesalahan sedini mungkin dalam proses, tetapi kesalahan dalam kode untuk sistem yang besar dan kompleks tidak dapat dihindarkan. Pengujian statik merupakan inspeksi kode untuk menemukan kesalahan logic. Pengujian dinamik merupakan eksekusi dengan data uji untuk menemukan kesalahan dalam kode.

Metode pengujian berorientasi objek, diantaranya : Testing levels terdiri dari : Testing operations pada objects. Testing object classes. Testing clusters cooperating objects. Testing OO system secara lengkap. Pengujian Class Menguji terhadap semua operation yg ada dan perubahan atribut-atributnya. Cluster Testing (Pengujian gugus) Cluster testing digunakan untuk test integrasi terhadap kooperatif object. Identifikasi clusters menggunakan knowledge operation objects dan system features yang diimplementasikan oleh cluster tersebut. Object-Interaction Testing. Tests barisan interaksi object yang berhenti ketika suatu operation object tidak memanggil service dari object lain. Object class testing. Complete test yang menguji class melibatkan. Testing semua operations suatu object. Setting dan interrogating semua attribute object. Menguji object untuk semua state(keadaan) yg mungkin. Inheritance akan mengakibatkan sulitnya perancangan object class tests seperti information yg diuji sulit dilokalisasi. Integrasi Object. Levels integrasi sedikit berbeda untuk sistem yang berorientasi object. Cluster testing digunakan untuk test integrasi and testing clusters terhadap cooperating objects.

 Identifikasi clusters menggunakan knowledge dari operation objects dan system features yang diimplementasikan oleh cluster tersebut. Approaches cluster testing (Pendekatan pengujian gugus) Use-case atau scenario testing Testing berdasarkan pada interaksi user dengan sistem. Keuntungannya diujikan oleh user yg berpengalaman. Object interaction testing Tests barisan interaksi objectyang berhenti ketika suatu operation object tidak memanggil service dari object lain. Scenario-based testing Identifikasi scenarios dari use-cases danmenambahkannya dengan diagram interaksi yang menunjukkan object-object yang terlibat dalam scenario. Weather station testing Thread pengeksekusian methode CommsController:request WeatherData:summarise. Inputs dan outputs Input report request dengan acknowledge yg sesuai serta output report akhir. Dapat diujikan dengan membuat raw data dan meyakinkan bahwa dapat menghasilkan kesimpulan yg sesuai. Gunakan raw data yg sama untuk menguji object WeatherData. WeatherStation:report

2.1.1. Pengujian Model Object Oriented Analysis (OOA) dan Object Oriented Design (OOD)
a) Object Oriented Analysis (OOA) Object-oriented analysis adalah suatu metoda analisis yang memeriksa syarat-syarat dari sudut pandang kelas-kelas dan objekobjek yang ditemui pada ruang lingkup permasalahan. Mendefinisikan kebutuhan-kebutuhan sistem melalui skenario atau penggunaan kasus-kasus. Kemudian, membuat suatu model obyek dengan kemampuan memenuhi kebutuhan-kebutuhan. Tujuan dari OOA adalah untuk memahami domain masalah dan meningkatkan ketelitian, konsistensi, kelengkapan b) Object Oriented Design (OOD) Object-oriented arsitektur design adalah lunak metoda untuk meng-arahkan

perangkat

yang didasarkan pada manipulasi

objek-objek sistem atau subsistem. Model kebutuhan-kebutuhan yang dibuat pada fase analisis diperkaya dalan fase perancangan. Tujuan dari OO Design adalah mengoptimalkan maintainability, reusability, enhancebility dan reliability c) Model Pengujian OOA dan OOD Model desain dan analisis tidak dapat diuji dalam arti yang konvensional karena model ini tidak dapat dieksekusi, maka kajian teknis formal dapat digunakan untuk menguji kebenaran dan konsistensi model analisis dan model desain.

Kebenaran dari model OOA dan OOD Kebenaran dari sintaks : Penggunaan simbol dan aturan pemodelan yang tepat. Kebenaran dari sematik Model yang mewakili dunia nyata, dibutuhkan seorang ahli dalam domain persoalan. Hubungan antar kelas.

Kekonsistenan dari model OOA dan OOD Hubungan antar entitas dalam model. Dapat digunakan model CRC dan object-relationship diagram

Langkah langkah yang digunakan adalah sebagai berikut : 1) Lakukan pemeriksaan silang antara model CRC dengan model object-relationship untuk memastikan semua kolaborasi yang dinyatakan dalam OOA direfleksikan dengan tepat dalam kedua model. 2) Periksa deskripsi dari setiap CRC index card untuk menentukan apakah suatu tanggung jawab merupakan bagian dari definisi collaborator. 3) Periksa hubungan balik untuk memastikan bahwa setiap

collaboratormenerima permintaan dari sumber yang tepat. 4) Periksa hubungan balik untuk memastikan apakah kelas lain diperlukan sebagai collaborator. 5) Tentukan apakah beberapa tanggung jawab dapat digabungkan menjadi tanggung jawab.

Ke lima langkah di atas diterapkan untuk setiap kelas dan setiap evolusi dari model OOA

2.1.2. Strategi Pengujian Berorientasi Objek (Object-Oriented Testing Strategies)

1) Unit testing (Pengujian unit) Unit terkecil yang diujikan adalah enkapsulasi class atau objek. Hampir serupa dengan ujicoba sistem pada software konvensional. Tidak menguji operasi dalam isolasinya dengan operasi yang lain. Dijalankan oleh operasi class dan perilaku Ujicoba lengkap keseluruhan class meliputi : Menguji seluruh operasi yang berhubungan dengan objek. Mengatur dan interogasi semua atribut obyek. Melatih objek dalam semua kemungkinan Mendesain ujicoba untuk class dengan menggunakan metode yang benar meliputi : Ujicoba berbasis kesalahan (fault-based testing). Ujicoba acak (random testing). Ujicoba partisi (partition testing) Setiap metode-metode ini akan melatih operasi yang dienkapsulapsi oleh class. Urutan ujicoba didesain untuk memastikan bahwa operasi yang relevan telah diujicobakan. Posisi tetap suatu class (Nilai atributnya) di uji untuk menentukan apakah terdapat kesalahan. 2) Integration testing (Pengujian Integrasi) tetap, bukan detail algoritmik dan aliran data yang melintasi antar interface modul.

10

 Difokuskan pada kelompok-kelompok kelas yang berkolaborasi atau berkomunikasi dalam beberapa cara. Integrasi operasi satu per satu ke dalam kelas sering sia-sia. Ujicoba berbasis thread (uji semua kelas yang dibutuhkan untuk merespon ke satu masukan atau event sistem). Pengujian berbasis Kegunaan (dimulai dengan uji independen oleh kelas pertama dan kelas-kelas yang tergantung yang menggunakannya). Pengujian cluster (kerjasama kelompok kelas yang diuji untuk interaksi kesalahan). Pengujian regresi adalah penting karena setiap thread, cluster, atau subsistem yang ditambahkan pada sistem. Tingkat integrasi yang lebih sedikit berbeda dalam sistem berorientasi objek. 3) Validation testing (Pengujian Validasi) Berfokus pada tindakan pengguna yang terlihat dan pengguna dapat mengenali output dari sistem. Tes validasi didasarkan pada skenario use-case, model perilaku objek, dan diagram alur event dibuat dalam model OOA. Pengujian Black box konvensional dapat digunakan untuk mendorong tes validasi. 4) Pengujian system Metode pengujian yang dipakai pada pengujian sistem adalah black box testing. Black blox testing atau test fungsional adalah pengujian yang dilakukan oleh pengembang (programmer) dengan memberikan input tertentu dan melihat hasil yang didapatkan dari input tersebut.

11

2.1.3. Desain Test Case Untuk Perangkat Lunak Berorientasi Obyek

Metode Desain Case, terdiri dari : 1) Setiap kasus uji harus dapat diidentifikassikan secara unik dan secara eksplisit dihubungkan dengan class yang akan diujikan. 2) Tetapkan kegunaan dari setiap ujicoba. 3) Tuliskan langkah-langkah ujicoba untuk setiap ujicoba yang disertakan, diantaranya: Tuliskan tahapan ujicoba untuk setiap objek yang disertakan dalam ujicoba. Tuliskan pesan-pesan dan operasi yang dijalankan sebagai konsekuensi dari ujicoba ini. Tuliskan eksepsi yang muncul ketika suatu objek di ujicoba. Tuliskan kondisi eksternal yang memerlukan perubahan untuk ujicoba tersebut. Informasi tambahan lainnya yang diperlukan untuk memahami atau mengimplementasikan ujicoba tersebut. 4) Ujicoba Struktur permukaan dan Struktur Dalam (Testing Surface Structure and Deep Structure) Ujicoba struktur permukaan (Testing surface structure) yaitu melatih struktur yang tampak oleh pengguna akhir, sering kali melibatkan pengamatan dan mewawancarai pengguna karena mereka memanipulasi objek sistem.

12

Ujicoba struktur dalam (Testing deep structure) yaitu melatih struktur program internal, seperti ketergantungan, perilaku, dan mekanisme komunikasi yang ada sebagai bagian dari sistem dan desain objek.

Implikasi Konsep Berorientasi Objek Enkapsulasi menyebabkan informasi dari status objek yang sedang diuji sulit diperoleh. Inheritance menyebabkan perlu dilakukannya pengujian setiap reuse (jika subclass digunakan dalam konteks yang berbeda dengan superclass-nya). Multi inheritance menyebabkan penambahan konteks yang harus diuji. Applicability Metoda Perancangan Kasus Uji Konvensional White Box digunakan untuk pengujian operasi. basis path, loop testing , atau data flow digunakan untuk memastikan bahwa setiap pernyataan dalam operasi telah diuji. Black Box digunakan untuk menguji sistem. Use case digunakan untuk membuat input dalam perancangan black box dan pengujian state-based. Pengaruh OOP pada Pengujian Beberapa jenis kesalahan menjadi kurang masuk akal. Beberapa jenis kesalahan menjadi lebih masuk akal. Muncul beberapa tipe kesalahan yang baru.

13

2.1.4. Metode Testing yang Dapat diaplikasikan pada Tingkatan Class (Testing Methods Applicable at The Class Level)
A) Random testing memerlukan sejumlah besar permutasi dan kombinasi data, dan dapat menjadi tidak efisien. Identifikasikan operasi yang mungkin pada class. Definisikan batasan penggunaannya. Identifikasikan urutan ujicoba minimum. Buatlah beberapa variasi urutan ujicoba random B) Partition testing Menghilangkan sejumlah kasus uji yang dibutuhkan untuk menguji sebuah class State-based partitioning ujicoba didesain dalam suatu cara sehingga operasi yang menyebabkan perubahan state diujikan secara terpisah dari yang tidak. Attribute-based partitioning untuk setiap atribut class, operasi diklasifikasikan berdasarkan pengguna atribut tersebut, yang memodifikasi atribut dan yang tidak menggunakan atau memodifikasi atribut. category-based partitioning operasi dikategorikan

berdasarkan fungsi yang dilakukannya, seperti : inisialisasi, komputassi, query, terminasi. C) Fault-based testing Terbaik untuk operasi dan tingkatan class. Menggunakan struktur pewarisan.

14

 Pengujian

memeriksa

model

OOA

dan

menghipotesis

sekumpulan kerusakan yang dipahami yang mungkin terjadi dalam pemanggilan operasi dan sambungan pesan, dan membangun kasus uji yang sesuai. Menemukan spesifikasi yang tidak tepat dan kesalahan dalam interaksi subsistem.

2.1.5. Inter - Class Test Case Design

1. Desain kasus uji menjadi lebih rumit seperti halnya integrasi dari dimulainya sistem Object Oriented menguji kolaborasi antar class. 2. Ujicoba class yang beragam, seperti : Untuk setiap class client menggunakan daftar operator classs untuk men-generate urutan ujicoba random yang mengirimkan pesan ke server class yang lain. Untuk setiap pesan yang di-generate, tentukan class kolaborator dan operator server object yang ditunjuk. Untuk setiap operator server class (dimohon oleh pesan dari client object) tentukan pesan yang dikirimkan. Untuk setiap pesan, tentukan tingkatan operator berikutkan yang memohon dan menggabungkannya kedalam urutan ujicoba. 3. Ujicoba yang dihasilkan dari model perilaku : Menggunakan state transition diagram (STD) sebagai model yang merepresentasikan perilaku dinamis dari suatu class. Kasus uji harus mencakkup seluruh tahapan STD.

15

 Breadth first traversal dari state model dapat digunakan (uji satu transisi dalam satu waktu dan hanya membuat kegunaan daari transisi yang diujikan sebelumnya ketika mengujikan transisi yang baru). Kasus uji juga dapat dihasilkan untuk memastikan bahwa seluruh perilaku untuk class telah diujikan dengan benar.

2.2.

Strategi Pengujian Perangkat Lunak

Pada awalnya pengujian berfokus pada setiap modul program secara

individual dengan memastikan bahwa modul program berfungsi secara tepat sebagai suatu unit, karena itu pengujian ini dinamakan tes unit ( unit test ). Tes unit menggunakan pengujian White-Box. Selanjutnya modul harus dirakit/diintegrasikan untuk membentuk suatu paket perangkat lunak yang lengkap. Tes integrasi ( integration test ) menekankan pd masalah-masalah yang berhubungan dengan masalah verifikasi (pembuktian) dan konstruksi (pembangunan/penyusunan). Tes integrasi ini menggunakan pengujian Black-Box (sebagian White-Box dapat dipakai di sini). Setelah perangkat lunak diintegrasi ( dikonstruksi ), serangkaian highorder test dilakukan. Kriteria validasi ( dibangun selama analisis persyaratan ) harus diuji. Tes validasi ( Validation Test ) memberikan jaminan akhir dimana perangkat lunak harus memenuhi semua persyaratan fungsional, tingkah laku dan kinerja yang sesuai dengan keinginan user. Metode/teknik pengujian black-box digunakan secara eksklusif selama validasi. Langkah pengujian high-order yang terakhir ada diluar batas rekayasa perangkat lunak dan masuk dalam konteks rekayasa sistem yang lebih luas. Perangkat lunak harus dikombinasikan dengan elemen sistem yang lain (misal: perangkat.keras, database, sistem operasi, manusia, kontrol, dll). Tes sistem

16

(System Test) membuktikan bahwa semua elemen sistem saling bertautan dengan tepat dan keseluruhan fungsi/kinerja sistem dapat dicapai.

2.2.1. Pendekatan Strategis Terhadap Pengujian Perangkat Lunak

Pendekatan strategi terhadap pengujian perangkat lunak terbagi menjadi 4, yaitu : a. Pengujian unit atau modul perangkat lunak Pengujian unit atau modul fokus terhadap inti terkecil dari desain perangkat lunak yaitu modul. b. Pengujian integrasi Merupakan teknik sistematis untuk mengkonstruksi struktur program sambil melakukan pengujian untuk mengungkap kesalahan sehubungan dengan interfacing. c. Pengujian validasi Pengujian yang baru dimulai apabila pada tahap integrasi tidak ditemukan kesalahan. d. Pengujian Sistem Pengujian yang dilakukan sepenuhnya pada yang sistem berbasis komputer.

2.2.2. Pengujian Modul Perangkat Lunak

Pengujian modul perangkat lunak fokus pada inti terkecil dari desain perangkat lunak yaitu modul. Biasanya berorientasi pada white box. Dilaksanakan

17

dengan menggunakan driver dan stub. Driver adalah suatu program utama yang berfungsi mengirim atau menerima data kasus uji dan mencetak hasil dari modul yang diuji. Stub adalah modul yang menggantikan modul sub-ordinat dari modul yang diuji.

Gambar 1. Struktur pengujian modul

Interface Interface modul diuji untuk memastikan bahwa informasi secara tepat mengalir masuk dan keluar dari modul yang diuji. Cara mengujinya dapat dilakukan dengan menggunakan checklist pengujian interface, yaitu : 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?

18

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 ? Apakah batasan yang dilalui merupakan argumen?

Struktur data lokal Struktur data lokal diuji untuk memastikan bahwa data yang tersimpan secara temporal dapat tetap menjaga integritasnya selama semua langkah di dalam suatu algoritma di eksekusi.

Kondisi batas Kondisi batas diuji untuk memastikan bahwa modul beroperasi dengan tepat pada batas yang ditentukan untuk membatasi pemrosesan.

Jalur independen Semua jalur independen yang ada pad modul diuji.

Jalur penanganan kesalahan Desain program yang bagus menunjukan bahwa kondisi kesalahan diantisipasi dan jalur penanganan kesalahan dipasang untuk merutekan kembali atau dengan jelas menghentikan pemrosesan pada saat suatu kesalahan benar-benar terjadi. Jalur penanganan kesalahan yang ada pada modul, diuji apakah sudah berfungsi dengan baik.

Test Case

19

Test case harus didesain untuk mengungkap kesalahan dalam kategori ; Pengetikan yang tidak teratur dan tidak konsisten Inisialisasi yang salah atau nilai-nilai default Nama variabel yang tidak benar Tipe data yang tidak konsisten Underflow, overflow dan pengecualian pengalamatan

2.2.3. Pengujian Terintegrasi

Merupakan teknik sistematis untuk mengkonstruksi struktur program sambil melakukan pengujian untuk mengungkap kesalahan sehubungan dengan interfacing. Dapat juga dikatakan sebagai pengujian keseluruhan system atau subsystem yang terdiri dari komponen yang terintegrasi. Test integrasi terdiri dari 2 cara, yaitu : Integrasi non-inkremental Integrasi ini dilakukan dengan cara semua modul digabung seluruhnya. Setelah itu barulah dilakukan pengujian. Integrasi inkremental Integrasi ini dilakukan untuk membangun dan menguji interface program dalam segmen-segmen kecil, sehingga kesalahan lebih mudah diisolasi dan dibetulkan. Interface lebih mungkin untuk diuji dengan lengkap. Test integrasi menggunakan black-box dengan test case ditentukan dari spesifikasi. Kesulitannya adalah menemukan/melokasikan. Penggunaan Incremental integration testing dapat mengurangi masalah tersebut.

20

A A T1 A T2 B T3 C T4 D Test sequence 1 Test sequence 2 Test sequence 3 B T3 C T2 B T1

T1

T2

T3 T4

T5

Gambar 2. Incremental integration testing Pendekatan Pengujian Integrasi a) Top-Down Testing Berawal dari level-atas system dan terintegrasi dengan mengganti masing-masing komponen secara top-down dengan suatu stub (program pendek yg mengenerate input ke sub-system yg diuji).
Level 1 Testing sequence Level 1 . ..

Level 2 Le vel 2 stubs

Level 2

Le vel 2

Level 2

Le vel 3 stubs

Gambar 3. Top-Down Testing

b) Bottom-Up Testing Integrasi components di level hingga sistem lengkap sudah teruji.

21

Test drivers Level N Level N Le vel N Level N Level N Testing sequence

Test drivers

Level N1

Level N1

Level N1

Gambar 4. Bottom-Up Testing Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi kedua strategi pengujian tersebut (sandwitch 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. Test implementation Seringkali lebih mudah dengan menggunakan bottom-up integration testing

Interface testing

22

Dilakukan kalau module-module dan sub-system terintegrasi dan membentuk sistem yang lebih besar. Tujuannya untuk medeteksi fault terhadap kesalahan interface atau asumsi yg tidak valid terntang interface tsb. Sangat penting untuk pengujian terhadap pengembangan sistem dgn menggunakan pendekatan object-oriented yg didefinisikan oleh objectobjectnya.

2.2.4. Uji Validasi

Pengujian ini dimulai jika pada tahap integrasi tidak ditemukan kesalahan. Bertujuan untuk memastikan apakah semua elemen konfigurasi perangkat lunak telah dikembangkan dengan tepat. Suatu validasi dikatakan sukses jika perangkat lunak berfungsi pada cara yang diharapkan oleh pemakai.

Kajian Konfigurasi (audit) Elemen dari proses validasi. Memastikan apakah semua elemen konfigurasi perangkat lunak telah dikembangkan dengan tepat. Pengujian Alpha dan Beta Pengujian Alpha Tujuannya untuk identifikasi dan menghilangkan sebanyak mungkin masalah sebelum akhirnya sampai ke user, dilakukan setelah software jadi oleh orang-orang yang tidak terlibat dalam pengembangan dan memang ahli dibidangnya. Terdapat formulir resmi evaluasi. Usability labs Usability factors checklist

23

 Pengujian Beta Evaluasi sepenuhnya oleh pengguna. Pengguna dipilih 3 orang yang dibagi menjadi : potensial, average, dan slow learner. Mereka diberitahukan prosedur evaluasi, diamati proses penggunaannya, diwawancarai lalu dinilai dan dilakukan revisi.

2.2.5. Pengujian System

Pengujian yang dilakukan sepenuhnya pada sistem berbasis komputer. Jenis-jenis pengujian sistem terdiri dari : Pengujian Perbaikan (Recovery Testing) Pengujian dilakukan dimana sistem diusahakan untuk gagal, kemudian diuji kenormalannya.

Pengujian Keamanan (Security Testing) Dilakukan untuk menguji mekanisme proteksi. Pengujian Stress (Stress Testing) Pengujian yang dirancang untuk menghadapkan suatu perangkat lunak kepada situasi yang tidak normal. Pengujian Kinerja (Performance Testing) Pengujian dilakukan untuk mengetahui kinerja run-time dari sistem.

2.2.6. Seni Debugging

24

Debugging merupakan sebuah metode yang dilakukan oleh para pemrogram dan pengembang perangkat lunak untuk mencari atau pun mengurangi bug (kesalahn desain) di dalam perangkat keras atau perangkat lunak (program komputer), sehingga perangkat tersebut dapat bekerja sesuai harapan. Debugging sendiri cenderung lebih rumit ketika beberapa subsistem lainnya terikat ketat dengannya, mengingat sebuah perubahan disatu sisi, mungkin dapat menyebabkan munculnya bug lain di dalam subsistem lainnya. Debugging dilakukan jika pengujian berhasil menemukan kesalahan. Jika testing bertujuan untuk mencari kesalahan, maka debugging bertujuan untuk menghilangkan kesalahan. Jadi, bukan merupakan pengujian, tetapi selalu terjadi sebagai bagian akibat dari pengujian. Debugging sendiri merupakan proses yang berurutan. Proses debugging dimulai dengan eksekusi terhadap suatu test case. Hasilnya dinilai, dan ditemukan kurangnya hubungan antara harapan dan hasil yang sesungguhnya. Dalam banyak kasus, data yang tidak berkaitan merupakan gejala dari suatu penyebab pokok tetapi masih tersembunyi, sehingga perlu ada koreksi kesalahan. Proses dari debugging akan selalu memiliki salah satu dari dua hasil akhir berikut, yaitu : Penyebab akan ditemukan, dikoreksi, dan dihilangkan atau, Penyebab tidak akan ditemukan. Bug yang terdapat pada perangkat keras atau lunak, biasanya memliki beberapa karakteristik, yaitu : Gejala dan penyebab dapat jauh secara geografis, dimana gejala dapat muncul didalam satu bagian dari suatu program, sementara penyebab terdapat pada sisi lain yang jauh. Gejala dapat hilang (kadang-kadang) ketika kesalahan yang lain dibetulkan.

25

 Gejala dapat benar-benar disebabkan oleh sesuatu yang tidak salah, misalnya pembulatan nilai yang tidak tepat. Gejala dapat merupakan hasil dari masalah timing, dan bukan dari masalah pemrosesan. Gejala muncul sementara. Hal ini sangat umum pada system embedded yang merangkai perangkat lunak dan perangkat keras yang tidak mungkin dilepaskan.

BAB 3 PENUTUP 3.1. Kesimpulan

Dalam pengujian berorientasi objek, komponen yang diuji akan dipandang sebagai sebuah object class. Dengan pengertian bahwa objek merupakan abstraksi dari sesuatu yang mewakili dunia nyata, seperti benda, karakteristik yang sama. Pengujian OOA (Object-oriented analysis) adalah suatu metoda analisis yang memeriksa syarat-syarat dari sudut pandang kelas-kelas dan objek-objek manusia dan lain sebagainya. Kelas sendiri merupakan kumpulan dari objek objek dengan

26

yang ditemui pada ruang lingkup permasalahan. Pengujian OOD (Object-oriented design) adalah metoda untuk meng-arahkan arsitektur perangkat lunak yang didasarkan pada manipulasi objek-objek sistem atau subsistem. Dalam melakukan pengujian suatu perangkat lunak dapat digunakan empat buah pendekatan yang saling berhubungan satu sama lain secara berurutan, yaitu Pengujian modul atau unit perangkat lunak, pengujian terintegrasi, pengujian validasi dan pengujian sistem. Debugging sendiri melengkapi pengujian suatu perangkat lunak untuk menilai kinerja dari perangkat lunak tersebut, apakah telah memenuhi harapan atau tidak.

3.2.

Saran
Penulis menyarankan kepada pembaca untuk mencari contoh kasus yang

mengimplementasikan strategi pengujian perangkat lunak secara lebih rinci lagi dikarenakan contoh kasus yang digunakan pada makalah ini dirasa masih kurang lengkap dalam memberikan gambaran implementasi strategi pengujian suatu perangkat lunak secara keseluruhan.

DAFTAR PUSTAKA

1. indryz.lecture.ub.ac.id/.../Pengujian-Validasi.docx 2. liapsa.staff.gunadarma.ac.id/.../files/.../BAB+4.pdf 3. pasca.uns.ac.id/~saptono/testing/OOTesting.pdf 4. http://parno.staff.gunadarma.ac.id/Downloads/files/18801/Testi

ng_06_OO_Testing.ppt

27

5. http://parno.staff.gunadarma.ac.id/Downloads/files/18800/Testi

ng_07_SW_Strategic_Testing.ppt
6. http://parno.staff.gunadarma.ac.id/Downloads/files/18802/Testi

ng_08_SW_Strategic_Testing.ppt
7. http://suryagsc.files.wordpress.com/2011/05/meeting-12.ppt

8. http://revoluthion.wordpress.com/2009/10/07/debuggingpengertian/ 9. http://ayuliana_st.staff.gunadarma.ac.id/Downloads/files/26376 /Pertemuan+06+-+(Object+Oriented+Testing).pdf

28