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 )
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.
• 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 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.
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
• 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
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
- menguji semua keputusan logikal
- menguji seluruh Loop yang sesuai dengan batasannya
- menguji seluruh struktur data internal yang menjamin validitas
o 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
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 sekurang-kurangnya 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
menerima urutan pesan tertentu yang mengakibatkan respon class terhadap pesan-pesan 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
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 kebutuhan-kebutuhan.
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
o Kebenaran dari sintaks :
Penggunaan simbol dan aturan pemodelan yang tepat
o Kebenaran dari sematik
Model yang mewakili dunia nyata, dibutuhkan seorang ahli dalam domain persoalan.
• Kekonsistenan dari model OOA dan OOD
o Hubungan antar entitas dalam model
o Dapat digunakan model CRC dan object-relationship diagram
• Langkah :
o Lakukan pemeriksaan silang antara model CRC dengan model object-relationship untuk memastikan semua kolaborasi yang dinyatakan dalam OOA direfleksikan dengan tepat dalam kedua model
o Periksa deskripsi dari setiap CRC index card untuk menentukan apakah suatu tanggung jawab merupakan bagian dari definisi collaborator
o Periksa hubungan balik untuk memastikan bahwa setiap collaboratormenerima permintaan dari sumber yang tepat.
o Periksa hubungan balik untuk memastikan apakah kelas lain diperlukan sebagai collaborator
o Tentukan apakah beberapa tanggung jawab dapat digabungkan menjadi tanggung jawab
o Ke lima langkah di atas diterapkan untuk setiap kelas dan setiap 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
o Ujicoba lengkap keseluruhan class meliputi :
Menguji seluruh operasi yang berhubungan dengan objek
Mengatur dan interogasi semua atribut obyek
Melatih objek dalam semua kemungkinan
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
