Pengujian Object Oriented
Untuk melakukan Testing sistem OO (Object Oriented) yang mencukupi, harus dilakukan tiga hal berikut:
a. definisi testing harus diperluas untuk mencakup teknik penemuan error yang diaplikasikan ke dalam model OOA dan OOD.
b. strategi unit testing akan menjadi kurang berarti dan strategi integrasi harus berubah secara signifikan.
c. disain test case harus bertanggung jawab terhadap karakteristik unik software OO.
Kebenaran Model OOA (Object Oriented Analys) dan OOD (Object Oriented Design)
Notasi dan sintaksis digunakan untuk menggambarkan model analisa dan disain akan sangat terkait dengan metode analisa dan disain tertentu yang digunakan pada proyek.
Karenanya kebenaran sintaksis dinilai berdasarkan pada ketepatan penggunaan simbologi, dan tiap model direview untuk memastikan ketepatan konvensi pemodelan yang akan dirawat.
Selama analisa dan disain, kebenaran simantik harus dinilai berdasarkan pada pemenuhan model terhadap domain masalah yang sebenarnya.
Konsistensi Model OOA dan OOD
Konsistensi model OOA dan OOD dinilai dengan memperhatikan hubungan antar entitas dalam model.
Untuk menilai konnsistensi, tiap class dan koneksinya dengan class lain harus diperiksa.
Model Class-Responsibility-Colaboration dan diagram hubungan obyek dapat digunakan untuk membantu aktivitas ini.
Model CRC berupa kartu berindex, yang tersusun dari nama class, tipe class, karakteristik class, tanggung jawab class (operasi yang ada), dan kolaborator-nya (class-class lain yang mengirim pesan dan yang bergantung pada pemenuhan tanggung jawabnya)
Disain Test Case untuk Software OO
Ada beberapa pendekatan menurut Berard :
- Setiap test case harus secara unik diidentifikasikan dan harus secara explisit diasosiasikan dengan class yang akan ditest.
- Tujuan dari test case harus telah ditentukan.
Daftar langkah – langkah test harus dibangun dan berisi:
-Daftar dari status object yang akan ditest.
-Daftar dari message dan operasi yang akan diperiksa sebagai konsekuensi dari test case.
-Daftar perkecualian yang mungkin terjadi dari obyek yang dites.
-Daftar kondisi external (perubahan yang terjadi pada lingkungan external yang harus ada pada software agar dapat dites)
-Informasi pendukung yang akan digunakan untuk membantu pemahaman atau pengimplemenntasian dari tes.
Unit Testing dalam Kontek OO
Enkapsulasi menentukan definisi dari class dan obyek.
Unit testing tidak melakukan tes pada tiap modul secara individual, namun unit terkecil yang dites adalah class atau obyek yang di-enkapsulasi.
Dalam OO kita tak dapat melakukan tes operasi tunggal dalam suatu isolasi, tapi harus dalam bagian dari class.
Testing class untuk software OO sama dengan unit testing untuk software konvensional
Tak seperti testing software konvensional, yang cenderung berfokus pada detil algoritma dari modul dan aliran data sepanjang interface modul, testing class untuk software OO ditentukan oleh operasi dari class yang dienkapsulasi dan tingkah laku dari class.
Integration Testing dalam Kontek OO
Karena software OO tidak mempunyai struktur kendali dalam bentuk hirarkhi, strategi integrasi konvennsional (top-down / bottom-up integration) menjadi tak berarti.
Ada 2 strategi untuk testing integrasi dari sistem OO, yaitu:
-Thread-based Testing, mengintegrasikan sekumpulan class yang dibutuhkan dalam merespon satu input atau event terhadap sistem. Tiap thread diintegrasikan dan dites secara individual.
-Used-based Testing, memulai konstruksi dari sistem dengan melakukan testing class-class (disebut independent class) yang menggunakan sangat sedikit (jika ada) class server. Setelah itu dilanjutkan dengan melakukan testing terhadap dependent class yang menggunakan independent class yang telah dites. Proses testing berlanjut terus hingga keseluruhan sistem selesai dikonstruksikan.
Cluster Testing adalah suatu langkah dalam testing integrasi dalam software OO. Disini, suatu kluster mengkolaborasi class (ditentukan oleh CRC dan model hubungan obyek) diperiksa dengan mendisain test cases yang dapat untuk menemukan error dalam kolaborasi.
Validation Testing dalam Kontek OO
Seperti pada validasi software konvensional, validasi software OO berfokus pada aksi user dan output dari sistem.
Test cases dapat diturunkan dari model tingkah laku obyek dan dari diagram alur kejadian (event) yang dibuat sebagai bagian dari OOA.
Re- testing on Inheritance (Regression testing of Classes)
Dalam teori testing ulang, suatu fungsi yang tidak diubah setelah diturunkan, adalah tidak perlu.
Fitur class yang sudah ditest perlu ditest ulang pada class yang menurunkannya.
Dalam hal ini karakteristik yang sudah ditest sebelumnya kemudian di modifikasi pada turunannya memerlukan test case yang berbeda.
Berapa banyak re- test diperlukan? Jawaban tergantung pada spesifik risk vs economic tradeoff dari subclass yang menurunkan object.
Beberapa superclass mungkin tidak dipengaruhi oleh perubahan dalam class yang diturunkannya
Random testing
-Identifikasi operasi yang dapat digunakan pada class
-Definisikan constrain yang mungkin terjadi
-Identifikasi minimum test sequence, sequence yang mungkin terjadi definisikan secara minimum dalam sejarahnya
-Jalankan berbagai macam test sequence secara random, terutama class instance yang mempunyai sejarah yang kompleks
Partitioning testing
Menghemat banyak test case yang dibutuhkan oleh class yang banyaknya sama partitioning dalam konvensional software
State based testing
Kategori dan operasi test yang berjalan tergantung pada kemampuan dari class untuk berubah
Masalah yang mungkin terjadi:
-Testing harus dapat memberikan semua report yang ada dan dapat diakses oleh internal state dari object itu sendiri
-Informasi hiding : keadaan ini secara tidak langsung dapat diakses, tetapi dapat diakses jika class itu sudah di public
Konsep Dasar Pemrograman Berorientasi Objek
Untuk melakukan Testing sistem OO (Object Oriented) yang mencukupi, harus dilakukan tiga hal berikut:
a. definisi testing harus diperluas untuk mencakup teknik penemuan error yang diaplikasikan ke dalam model OOA dan OOD.
b. strategi unit testing akan menjadi kurang berarti dan strategi integrasi harus berubah secara signifikan.
c. disain test case harus bertanggung jawab terhadap karakteristik unik software OO.
Kebenaran Model OOA (Object Oriented Analys) dan OOD (Object Oriented Design)
Notasi dan sintaksis digunakan untuk menggambarkan model analisa dan disain akan sangat terkait dengan metode analisa dan disain tertentu yang digunakan pada proyek.
Karenanya kebenaran sintaksis dinilai berdasarkan pada ketepatan penggunaan simbologi, dan tiap model direview untuk memastikan ketepatan konvensi pemodelan yang akan dirawat.
Selama analisa dan disain, kebenaran simantik harus dinilai berdasarkan pada pemenuhan model terhadap domain masalah yang sebenarnya.
Konsistensi Model OOA dan OOD
Konsistensi model OOA dan OOD dinilai dengan memperhatikan hubungan antar entitas dalam model.
Untuk menilai konnsistensi, tiap class dan koneksinya dengan class lain harus diperiksa.
Model Class-Responsibility-Colaboration dan diagram hubungan obyek dapat digunakan untuk membantu aktivitas ini.
Model CRC berupa kartu berindex, yang tersusun dari nama class, tipe class, karakteristik class, tanggung jawab class (operasi yang ada), dan kolaborator-nya (class-class lain yang mengirim pesan dan yang bergantung pada pemenuhan tanggung jawabnya)
Disain Test Case untuk Software OO
Ada beberapa pendekatan menurut Berard :
- Setiap test case harus secara unik diidentifikasikan dan harus secara explisit diasosiasikan dengan class yang akan ditest.
- Tujuan dari test case harus telah ditentukan.
Daftar langkah – langkah test harus dibangun dan berisi:
-Daftar dari status object yang akan ditest.
-Daftar dari message dan operasi yang akan diperiksa sebagai konsekuensi dari test case.
-Daftar perkecualian yang mungkin terjadi dari obyek yang dites.
-Daftar kondisi external (perubahan yang terjadi pada lingkungan external yang harus ada pada software agar dapat dites)
-Informasi pendukung yang akan digunakan untuk membantu pemahaman atau pengimplemenntasian dari tes.
Unit Testing dalam Kontek OO
Enkapsulasi menentukan definisi dari class dan obyek.
Unit testing tidak melakukan tes pada tiap modul secara individual, namun unit terkecil yang dites adalah class atau obyek yang di-enkapsulasi.
Dalam OO kita tak dapat melakukan tes operasi tunggal dalam suatu isolasi, tapi harus dalam bagian dari class.
Testing class untuk software OO sama dengan unit testing untuk software konvensional
Tak seperti testing software konvensional, yang cenderung berfokus pada detil algoritma dari modul dan aliran data sepanjang interface modul, testing class untuk software OO ditentukan oleh operasi dari class yang dienkapsulasi dan tingkah laku dari class.
Integration Testing dalam Kontek OO
Karena software OO tidak mempunyai struktur kendali dalam bentuk hirarkhi, strategi integrasi konvennsional (top-down / bottom-up integration) menjadi tak berarti.
Ada 2 strategi untuk testing integrasi dari sistem OO, yaitu:
-Thread-based Testing, mengintegrasikan sekumpulan class yang dibutuhkan dalam merespon satu input atau event terhadap sistem. Tiap thread diintegrasikan dan dites secara individual.
-Used-based Testing, memulai konstruksi dari sistem dengan melakukan testing class-class (disebut independent class) yang menggunakan sangat sedikit (jika ada) class server. Setelah itu dilanjutkan dengan melakukan testing terhadap dependent class yang menggunakan independent class yang telah dites. Proses testing berlanjut terus hingga keseluruhan sistem selesai dikonstruksikan.
Cluster Testing adalah suatu langkah dalam testing integrasi dalam software OO. Disini, suatu kluster mengkolaborasi class (ditentukan oleh CRC dan model hubungan obyek) diperiksa dengan mendisain test cases yang dapat untuk menemukan error dalam kolaborasi.
Validation Testing dalam Kontek OO
Seperti pada validasi software konvensional, validasi software OO berfokus pada aksi user dan output dari sistem.
Test cases dapat diturunkan dari model tingkah laku obyek dan dari diagram alur kejadian (event) yang dibuat sebagai bagian dari OOA.
Re- testing on Inheritance (Regression testing of Classes)
Dalam teori testing ulang, suatu fungsi yang tidak diubah setelah diturunkan, adalah tidak perlu.
Fitur class yang sudah ditest perlu ditest ulang pada class yang menurunkannya.
Dalam hal ini karakteristik yang sudah ditest sebelumnya kemudian di modifikasi pada turunannya memerlukan test case yang berbeda.
Berapa banyak re- test diperlukan? Jawaban tergantung pada spesifik risk vs economic tradeoff dari subclass yang menurunkan object.
Beberapa superclass mungkin tidak dipengaruhi oleh perubahan dalam class yang diturunkannya
Random testing
-Identifikasi operasi yang dapat digunakan pada class
-Definisikan constrain yang mungkin terjadi
-Identifikasi minimum test sequence, sequence yang mungkin terjadi definisikan secara minimum dalam sejarahnya
-Jalankan berbagai macam test sequence secara random, terutama class instance yang mempunyai sejarah yang kompleks
Partitioning testing
Menghemat banyak test case yang dibutuhkan oleh class yang banyaknya sama partitioning dalam konvensional software
State based testing
Kategori dan operasi test yang berjalan tergantung pada kemampuan dari class untuk berubah
Masalah yang mungkin terjadi:
-Testing harus dapat memberikan semua report yang ada dan dapat diakses oleh internal state dari object itu sendiri
-Informasi hiding : keadaan ini secara tidak langsung dapat diakses, tetapi dapat diakses jika class itu sudah di public
Konsep Dasar Pemrograman Berorientasi Objek
Terdapat Konsep dasar dari Pemrograman Berorientasi Objek :
1. Kelas :
- Definisi class: merupakan template untuk membuat obyek.
- Definisi class: merupakan prototipe / blue prints yang mendefinisikan variabel – variabel dan method – method secara umum.
- Obyek merupakan hasil instansiasi dari suatu kelas.
- Proses pembentukan obyek dari suatu class disebut dengan instantiation.
- Obyek disebut juga instances.
1. Kelas :
- Definisi class: merupakan template untuk membuat obyek.
- Definisi class: merupakan prototipe / blue prints yang mendefinisikan variabel – variabel dan method – method secara umum.
- Obyek merupakan hasil instansiasi dari suatu kelas.
- Proses pembentukan obyek dari suatu class disebut dengan instantiation.
- Obyek disebut juga instances.
2. Object :
Membungkus data dan fungsi bersama menjadi suatu unit dalam program computer sebuah object merupakan dasar dari modularitas dan struktur dalam sebuah program komputer berorientasi objek.
Membungkus data dan fungsi bersama menjadi suatu unit dalam program computer sebuah object merupakan dasar dari modularitas dan struktur dalam sebuah program komputer berorientasi objek.
3. Abstraksi :
Kemampuan untuk memfokus pada inti.
Kemampuan untuk memfokus pada inti.
4. Enkapsulasi : Pembungkusan
5. Polimorfism :
Melalui pengiriman pesan. Tidak bergantung kepada pemanggilan subrutin, bahasa orientasi objek dapat mengirim pesan; metode tertentu yang berhubungan dengan sebuah pengiriman pesan tergantung kepada objek tertentu di mana pesa tersebut dikirim.
Melalui pengiriman pesan. Tidak bergantung kepada pemanggilan subrutin, bahasa orientasi objek dapat mengirim pesan; metode tertentu yang berhubungan dengan sebuah pengiriman pesan tergantung kepada objek tertentu di mana pesa tersebut dikirim.
6. Inheriten :
Mengatur polimorfisme dan enkapsulasi dengan mengijinkan objek didefinisikan dan diciptakan dengan jenis khusus dari objek yang sudah ada – objek-objek ini dapat membagi (dan memperluas) perilaku mereka tanpa haru mengimplementasi ulang perilaku
Mengatur polimorfisme dan enkapsulasi dengan mengijinkan objek didefinisikan dan diciptakan dengan jenis khusus dari objek yang sudah ada – objek-objek ini dapat membagi (dan memperluas) perilaku mereka tanpa haru mengimplementasi ulang perilaku
Refrensi :
http://364ground.blogspot.com/2009/12/object-oriented-testing.html
http://364ground.blogspot.com/2009/12/object-oriented-testing.html
