bab i,2,3 kelompok 4 w
Post on 05-Dec-2014
325 Views
Preview:
TRANSCRIPT
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 ~
top related