BAB I,2,3 Kelompok 4 w

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 ~

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. Model pengujian OOA dan OOD.

b. Strategi pengujian berorientasi objek.

c. Desain test case untuk perangkat lunak berorientasi objek.

d. Metode pengujian yang diaplikasikan pada tingkat kelas.

e. Desain test case inter – kelas.

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

~ 2 ~

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.

~ 3 ~

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.

~ 4 ~

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.

~ 5 ~

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.

~ 6 ~

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 WeatherStation:report

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.

~ 7 ~

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

objek 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 design adalah metoda untuk meng-arahkan

arsitektur perangkat lunak 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.

~ 8 ~

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

~ 9 ~

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 tetap, bukan detail

algoritmik dan aliran data yang melintasi antar interface modul.

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)

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

~ 10 ~

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.

2.1.3. Desain Test Case Untuk Perangkat Lunak Berorientasi

Obyek

Metode Desain Case, terdiri dari :

~ 11 ~

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.

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

~ 12 ~

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.

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.

~ 13 ~

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.

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.

~ 14 ~

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.

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.

~ 15 ~

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

order 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

(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

~ 16 ~

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

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.

~ 17 ~

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?

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 ?

~ 18 ~

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

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

~ 19 ~

Merupakan teknik sistematis untuk mengkonstruksi struktur program

sambil melakukan pengujian untuk mengungkap kesalahan sehubungan dengan

interfacing. Dapat juga dikatakan sebagai pengujian keseluruhan system atau sub-

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

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Test sequence1

Test sequence2

Test sequence3

Gambar 2. Incremental integration testing

Pendekatan Pengujian Integrasi

a) Top- D own T esting

~ 20 ~

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

Level 1 Level 1Testing

sequence

Level 2stubs

Level 3stubs

. . .

Gambar 3. Top-Down Testing

b) Bottom- U p T esting

Integrasi components di level hingga sistem lengkap sudah teruji.

Level NLevel NLevel NLevel NLevel N

Level N–1 Level N–1Level N–1

Testingsequence

Testdrivers

Testdrivers

Gambar 4. Bottom-Up Testing

Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi

kedua strategi pengujian tersebut (sandwitch testing).

Pendekatan Testing

Architectural validation

~ 21 ~

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

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

objectnya.

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.

~ 22 ~

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

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)

~ 23 ~

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

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 :

~ 24 ~

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.

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

~ 25 ~

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, manusia dan lain

sebagainya. Kelas sendiri merupakan kumpulan dari objek – objek dengan

karakteristik yang sama.

Pengujian OOA (Object-oriented analysis) adalah suatu metoda analisis

yang memeriksa syarat-syarat dari sudut pandang kelas-kelas dan objek-objek

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

~ 26 ~

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/   

Testing_06_OO_Testing.ppt

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

Testing_07_SW_Strategic_Testing.ppt

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

Testing_08_SW_Strategic_Testing.ppt

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

8. http://revoluthion.wordpress.com/2009/10/07/debugging-pengertian/   

9. http://ayuliana_st.staff.gunadarma.ac.id/Downloads/files/26376/   

Pertemuan+06+-+(Object+Oriented+Testing).pdf

~ 27 ~