KELOMPOK II
PENGUJIAN BERORIENTASI OBJEK
4 IA12 REKAYASA PERANGKAT LUNAK 2 Nama Anggota :
Amanah Burhania Rizky
( 50406898 )
Di Ajeng Pambayun
( 50406195 )
Margaretta
( 50406821 )
Nicko Dwi Prasetya
( 50406897 )
Nike Sri Handayani
( 50406912 )
UNIVERSITAS GUNADARMA 2009 / 2010
PENGUJIAN BERORIENTASI OBJEK
Pengujian merupakan langkah terakhir setelah dilakukannya proses implementasi berorientasi objek. Pengujian pada dasarnya adalah suatu pengeksekusian program yang bertujuan untuk menemukan ’bug’ (kesalahan-kesalahan) pada sistem atau perangkat lunak sebelum diberikan kepada pengguna. Kesalahan-kesalahan itu dapat diakibatkan oleh beberapa hal utama, antara lain kesalahan saat penentuan spesifikasi sistem/perangkat lunak, kesalahan saat melakukan analisis permasalahan, kesalahan saat perancangan, serta kesalahan saat implementasi. Pengujian dikatakan berhasil bila dapat memunculkan kesalahan yang belum diketahui. Jadi, tujuan utama dari pengujian yang baik adalah bukan untuk memastikan tidak adanya kesalahan tetapi untuk mencari sebanyak mungkin kesalahan yang ada pada program.
Pengujian Perangkat Lunak Dalam pengembangan perangkat lunak, tahapan pengujian (testing) merupakan proses yang
penting dalam menentukan tingkat kebenaran perangkat lunak. Pengujian perangkat lunak merupakan aktifitas yang sangat mahal dan dapat menghabiskan waktu. Jika proses pengujian dapat dilakukan secara otomatis, maka efisiensi pengujian akan meningkat dan biaya pengembangan perangkat lunak dapat dikurangi. Oleh karena itu pengujian otomatis harus dirancang dengan baik agar dapat menemukan klasifikasi kesalahan secara sistematis dan dapat diperbaiki dalam waktu dan usaha yang minimal. Pihak yang berhubungan dengan pengujian : •
Customer, tim yang mengontrak pengembang untuk mengembangkan perangkat lunak.
•
Pengguna, kelompok yang akan menggunakan perangkat lunak
•
Pengembang perangkat lunak, tim yang membangun perangkat lunak
•
Tim Pengujian perangkat lunak, tim khusus yang bertugas untuk menguji fungsi-fungsi pada perangkat lunak. Prinsip Pengujian :
•
Semua pengujian harus dapat diurutkan sampai kepada spesifikasi kebutuhan perangkat lunak.
2
•
Pengujian harus dimulai dari lingkup yang kecil ke lingkup yang besar.
•
Supaya efektif (memiliki probabilitas yang tinggi dalam menemukan kesalahan), pengujian harus dilakukan oleh pihak lain yang independen
•
Pengujian harus direncanakan jauh sebelum dilakukan. Pengujian dapat dikategorikan atas : 1.
Pengujian
pendukung.
terhadap
Proses
berarti
proses
pengembangan
sejumlah
aktivitas
sistem
dan
dokumen-dokumen
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. Kualitas Pengujian yang baik •
Mencakup semua kemungkinan skenario pengoperasian perangkat lunak
•
Mencakup sebanyak mungkin jalur yang dibentuk dari struktur program
•
Tidak terlalu sederhana dan tidak terlalu rumit
Pengujian perangkat lunak seharusnya menghabiskan waktu 30% – 40% dari total biaya pembangunan perangkat lunak. Pengujian merupakan bagian dari
salah satu tugas software
verification dan validation, yang merupakan bagian dari software quality assurance . Ruang Lingkup pengujian perangkat lunak : Strategi Strategi merupakan proses mengintegrasikan metode perancangan kasus uji dalam sekumpulan langkah yang direncanakan. Strategi pengujian perangkat lunak : •
Big bang testing : menguji perangkat lunak keseluruhan, sekali untuk semua
package yang ada 3
•
Incremental testing : menguji perangkat lunak per bagian dalam modul (unit
testing), dilanjutkan dengan menguji integrasi tiap modul (integration test), selanjutnya seluruh package diuji (system testing) Incremental testing : Dibentuk dari dua dasar strategi : o
Top-down
Modul pertama yang diuji : modul utama (tertinggi)
Modul terakhir yang diuji : modul pada level paling rendah
Keuntungan : memperlihatkan keseluruhan fungsi program (semua modul
lengkap)
Kerugian : sulit menyiapkan potongan program dan menganalisis hasil tes
o Bottom-up
Kebalikan top-down, yaitu menguji modul dari level terendah hingga modul
utama.
Keuntungan : relatif mendorong performance
Kerugian : menghambat program sebagai suatu keseluruhan modul
Gambar 1. Buttom Up Integration •
Keduanya menganggap package perangkat lunak dibangun berdasarkan hirarki
modul perangkat lunak
4
Metode pengujian Metode pengujian mencakup perancangan kasus uji dengan menggunakan metode White Box atau Black Box . •
Black box testing
o Pendekatan pengujian dimana program dianggap sebagai suatu ‘black box’ (kotak hitam). o Program test case berbasiskan spesifikasi. o Test planning dapat dimulai sejak awal proses pengembangan sistem. o Metode Black Box memungkinkan perekayasa perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnya menggunakan semua persyaratan fungsional untuk suatu program. o Pengujian ini dilakukan untuk mengevaluasi pemenuhan sistem dengan kebutuhan fungsional tertentu agar dapat menemukan kesalahan dalam kategori berikut :
•
•
Fungsi-fungsi yang tidak benar atau hilang
•
Kesalahan interface
•
Kesalahan dalam struktur data atau akses basis data eksternal
•
Inisialisasi dan kesalahan terminasi
•
Validitas fungsional
•
Kesensitifan sistem terhadap nilai input tertentu
•
Batasan dari suatu data
White box testing
o Pengujian yang memegang perhitungan mekanisme internal sistem atau komponen untuk menguji struktural program. o Dengan menggunakan white box akan didapatkan kasus uji yang : -
menjamin seluruh jalur independen di dalam modul yang dieksekusi
sekurang-kurangnya sekali
o
-
menguji semua keputusan logikal
-
menguji seluruh Loop yang sesuai dengan batasannya
-
menguji seluruh struktur data internal yang menjamin validitas Basis Path adalah teknik uji coba white box (Tom Mc Cabe). Basis Path
digunakan untuk mendapatkan kompleksitas lojik dari suatu prosedur dan menggunakan ukuran ini sebagai petunjuk untuk mendefinisikan himpunan jalur 5
yang akan diuji. Basis Path menggunakan notasi graph untuk menggambarkan aliran kontrolnya. Gambar dibawah ini menunjukkan notasi graph untuk menggambarkan skema dasar pemrograman.
Gambar 2. Notasi Graph untuk Skema Dasar Pemrograman o
Cyclomatic Complexity adalah ukuran yang menunjukkan kompleksitas lojik
suatu program. Cyclomatic Complexity V(G) dapat diperoleh dengan menghitung daerah yang dapat dibentuk oleh graph, dapat pula dihitung dengan : V (G) = E – N + 2 dimana : E = jumlah edge pada flowgraph N = Jumlah Node pada flowgraph Cyclomatic Complexity juga dapat dihitung dengan rumus : V (G) = P + 1 dimana : P = jumlah predikat Node pada flow graph Jalur independen adalah jalur yang melintasi atau melalui program dimana sekurangkurangnya dieksekusi satu kali. Jalur independen sama dengan jumlah Cyclomatic Complexity-nya.
Pengujian Perangkat Lunak Berorientasi Objek Teknologi perangkat lunak berorientasi objek telah meningkat dengan cepat dalam hal
perancangan dan pemrograman. Saat ini banyak penelitian dalam teknologi informasi dalam rangka pengembangan perangkat lunak terfokus pada tahapan pengujian. Dalam pengujian berorientasi objek, unit terkecil adalah objek dan class, sistem merupakan sekumpulan komunikasi-komunikasi antar objek. Class sering dirancang untuk
6
menerima urutan pesan-pesan tertentu yang mengakibatkan respon class terhadap pesanpesan tersebut menjadi berbeda-beda. Tujuan pengujian perangkat lunak berorientasi objek yaitu untuk menemukan kesalahan dalam selang waktu yang realistik. Ada tiga hal yang harus diperhatikan dalam pengujian ini, yaitu: •
Definisi pengujian harus diperluas agar mencakup teknik untuk menemukan kesalahan pada model OOA dan OOD
•
Strategi pengujian unit dan integrasi berubah
•
Perancangan pengujian harus memperhatikan karakteristik dari perangkat lunak berorientasi objek Kesalahan pendefinisian atribut kelas yang ditemukan pada tahap analisis akan
menghilangkan pengaruh yang dapat muncul. Contoh : Sebuah kelas dengan sejumlah atribut didefinisikan pada tahap analisis. Sebuah atribut yang tidak berhubungan dan dua operasi yang memanipulasi atribut tersebut terdefinisi. •
Jika atribut yang tidak berhubungan dihilangkan pada tahap analisis, dapat mengurangi
beberapa masalah dan usaha sbb : o
Pembuatan subclass yang khusus untuk mengakomodasi atribut tersebut
o
Pembuatan relasi antar kelas yang salah
o
Kelakuan dari sistem dapat menjadi tidak tepat
•
Jika kesalahan tidak ditemukan, masalah yang dapat muncul pada tahap
perancangan : o
Penempatan kelas yang tidak tepat pada subsistem
o
Perancangan kerja yang tidak perlu
o
Model messaging (message connection) yang tidak tepat
•
Jika kesalahan tetap ada sampai pada tahap pengkodean akan
menghabiskan banyak waktu dan usaha untuk : o
Membuat kode dari atribut dan dua operasi yang tidak diperlukan
o
Membuat message untuk komunikasi antar objek
7
Pengujian Model Object Oriented Analysis (OOA) dan Object Oriented Design (OOD) •
Object Oriented Analysis (OOA) o 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. o Mendefinisikan kebutuhan-kebutuhan sistem melalui skenario atau penggunaan kasus-kasus. o Kemudian, membuat suatu model obyek dengan kemampuan memenuhi kebutuhankebutuhan. o Tujuan
dari
OOA
adalah
untuk
memahami
domain
masalah
dan
meningkatkan ketelitian, konsistensi, kelengkapan •
Object Oriented Design (OOD) o Object-oriented
design
adalah
metoda
untuk
meng-arahkan
arsitektur
perangkat lunak yang didasarkan pada manipulasi objek-objek sistem atau subsistem. o Model kebutuhan-kebutuhan yang dibuat pada fase analisis diperkaya dalan fase perancangan. o Tujuan dari OO Design adalah mengoptimalkan maintainability, reusability, enhancebility dan reliability •
Model Pengujian OOA dan OOD
Model desain dan analisis tidak dapat diuji dalam arti yang konvensional karena model ini tidak dapat dieksekusi, maka kajian teknis formal dapat digunakan untuk menguji kebenaran dan konsistensi model analisis dan model desain •
Kebenaran dari model OOA dan OOD Kebenaran dari sintaks :
o
Penggunaan simbol dan aturan pemodelan yang tepat
Kebenaran dari sematik
o
Model yang mewakili dunia nyata, dibutuhkan seorang ahli dalam domain
persoalan.
Hubungan antar kelas
8
•
Kekonsistenan dari model OOA dan OOD o Hubungan antar entitas dalam model o Dapat digunakan model CRC dan object-relationship diagram
•
Langkah : Lakukan pemeriksaan silang antara model CRC dengan model object-
o
relationship untuk memastikan semua kolaborasi yang dinyatakan dalam OOA direfleksikan dengan tepat dalam kedua model Periksa deskripsi dari setiap CRC index card untuk menentukan
o
apakah suatu tanggung jawab merupakan bagian dari definisi collaborator Periksa
o
hubungan
balik
untuk
memastikan
bahwa
setiap
collaboratormenerima permintaan dari sumber yang tepat. Periksa hubungan balik untuk memastikan apakah kelas lain
o
diperlukan sebagai collaborator Tentukan apakah beberapa tanggung jawab dapat digabungkan
o
menjadi tanggung jawab Ke lima langkah di atas diterapkan untuk setiap kelas dan setiap
o
evolusi dari model OOA Strategi Pengujian Berorientasi Objek (Object-Oriented Testing Strategies) •
Unit testing (Pengujian unit) o
Unit terkecil yang diujikan adalah enkapsulasi class atau objek
o
Hampir serupa dengan ujicoba sistem pada software konvensional
o
Tidak menguji operasi dalam isolasinya dengan operasi yang lain
o
Dijalankan oleh operasi class dan perilaku tetap, bukan detail algoritmik dan
aliran data yang melintasi antar interface modul Ujicoba lengkap keseluruhan class meliputi :
o
o
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
9
Ujicoba berbasis kesalahan (fault-based testing)
Ujicoba acak (random testing)
Ujicoba partisi (partition testing)
o
Setiap metode-metode ini akan melatih operasi yang dienkapsulapsi oleh class
o
Urutan ujicoba didesain untuk memastikan bahwa operasi yang relevan telah
diujicobakan. o
Posisi
tetap suatu class (Nilai atributnya) di uji untuk menentukan apakah
terdapat kesalahan •
Integration testing (Pengujian Integrasi) o
Difokuskan
pada
kelompok-kelompok
kelas
yang
berkolaborasi
atau
berkomunikasi dalam beberapa cara. o
Integrasi operasi satu per satu ke dalam kelas sering sia-sia
o
Ujicoba berbasis thread (uji semua kelas yang dibutuhkan untuk merespon ke
satu masukan atau event sistem) o
Pengujian berbasis Kegunaan (dimulai dengan uji independen oleh kelas pertama
dan kelas-kelas yang tergantung yang menggunakannya) o
Pengujian cluster (kerjasama kelompok kelas yang diuji untuk interaksi
kesalahan) o
Pengujian
regresi adalah
penting
karena
setiap
thread,
cluster,
atau
subsistem yang ditambahkan pada sistem o •
Tingkat integrasi yang lebih sedikit berbeda dalam sistem berorientasi objek
Validation testing (Pengujian Validasi) o
Berfokus pada tindakan pengguna yang terlihat dan pengguna dapat mengenali
output dari sistem o
Tes validasi didasarkan pada skenario use-case, model perilaku objek, dan
diagram alur event dibuat dalam model OOA o
Pengujian Black box konvensional dapat digunakan untuk mendorong tes
validasi
10
