Object Oriented Testing

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

Sumber:

aimyaya.com/…/testing-pengujian-berorientasi-objek-pada-gls-tsp

http://364ground.blogspot.com/2009/12/object-oriented-testing.html

http://www.jevuska.com/topic/konsep+object+oriented+programming+oop+dalam+pemrograman+visual.html