BAB 1 PENDAHULUAN
1.1.
Latar Belakang Kema Kemaju juan an tekn teknol olog ogii yang yang sang sangat at pesa pesatt dita ditand ndai ai deng dengan an sema semaki kin n
banyaknya perangkat-perangkat teknologi informasi yang digunakan oleh masy masyar arak akat at luas. luas. Seka Sekaran rang g ini ini bany banyak ak terd terdap apat at bebe bebera rapa pa para paradi digm gmaa yang yang digunakan dalam rekayasa software, diantaranya process-oriented methodologies, blended methodologies, object – oriented methodologies, Rapid development metho methodol dologi ogies, es, people people – orient oriented ed method methodolo ologie gies, s, dan framew framework orks. s. Semua 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 menggamba menggambarkan rkan satu bagian tersebut tersebut dalam satu objek. objek. Tidak seperti paradigma paradigma lainny lainnya, a, dimana dimana hanya hanya cocok cocok untuk untuk bebera beberapa pa kasus kasus dan bagian bagian dari dari seluruh seluruh kemu kemung ngki kina nan n ruan ruang g ling lingku kup p apli aplika kasi, si, khus khusus us untu untuk k objec object-o t-orie rient nted ed dapa dapatt diaplikasikan dalam seluruh ruang lingkup. Penguj Pengujian ian perang perangkat kat lunak lunak adalah adalah suatu suatu proses proses yang yang digun digunaka akan n untuk untuk mengidentifikasi ketepatan, kelengkapan dan mutu dari perangkat lunak dalam ilmu ilmu komput komputer er yang yang dikemb dikembang angkan kan.. Pada Pada dasarny dasarnya, a, penguj pengujian iann n tidak tidak pernah pernah dapa dapatt mene meneta tapk pkan an kebe kebena naran ran dari dari peran perangk gkat at luna lunak. k. Pent Pentin ingn gnya ya peng penguj ujian ian perangkat lunak dan implikasinya yang mengacu mengacu pada kualitas perangkat lunak itu sendiri. sendiri. Pengujian Pengujian perangkat perangkat lunak adalah elemen kritis kritis dari jaminan kualitas kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi,desain dan pengkodean.
~
1
~
1.2.
Batas tasan 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.
Penguj Pengujian ian berori berorient entasi asi obje objek, k, yang yang meli meliput puti: i: a.
Mode Modell pen pengu guji jian an OOA OOA dan dan OOD. OOD.
b.
Strategi pengujian berorientasi objek.
c.
Desain Desain test test case case untuk untuk perang perangkat kat lunak lunak bero berorien rientasi tasi obje objek. k.
d.
Metode Metode peng penguji ujian an yang yang diaplik diaplikasik asikan an pada pada tingkat tingkat kelas kelas..
e.
Desa Desain in test test cas casee int inter er – kela kelas. s.
2.
Strateg Strategii penguj pengujian ian peran perangka gkatt lunak, lunak, yang yang melipu meliputi: ti: a. Pendekatan Pendekatan strategis strategis terhadap terhadap pengujian pengujian perangkat perangkat lunak. lunak. b. Pengujian modul perangkat lunak. lunak. c. Penguj Pengujian ian terin terinteg tegrasi rasi.. d. Uji Uji val valid idas asi. i. e. Peng Penguj ujia ian n sistem sistem.. f. Seni Seni debu debugg ggin ing. g.
1.3.
Tujuan Pe Penulisan Pembuatan makalah ini memiliki beberapa bertujuan, diantaranya:
1) Agar Agar mahasisw mahasiswaa memahami memahami model model penguji pengujian an berorien berorientasi tasi objek objek.. 2) Agar Agar maha mahasi siswa swa mema memaha hami mi pent pentin ingn gnya ya verif verifik ikasi asi dan dan vali valida dasi si terha terhada dap p produk yang akan diuji, pengorganisasian pengujian perangkat lunak, strategi str ategi pengujian perangkat lunak dan kriteria penyelesaian sebuah pengujian. 3)
Agar mahasiswa mahasiswa memaham memahamii pertimban pertimbangan gan uji modul modul dan dan prosedu prosedurnya. rnya.
4)
Agar Agar mahas ahasis iswa wa mema memah hami ami stra strate tegi gi top top down down dan dan botto ottom m up dala dalam m 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 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
perangkat
adalah lunak
metoda
untuk
meng-arahkan
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.
~
9
~
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
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)
~
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
T1
T1
A T1
T2
A
B
T2 T2
B
T3 T3
B
C T4
T3 C
T4 T5
D Test sequence 1
Test sequence 2
Test sequence 3
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 2
Level 1
Level 2
Level 2
...
Level 2
Level 2 stubs
Level 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
Test drivers
Level N
Level N
Level N–1
Level N
Level N–1
Level N
Testing sequence
Level N–1
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,
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
~
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
~
