Pengujian Perangkat Lunak Berorientasi Objek

Pemrograman berorientasi objek (object-oriented programming disingkat OOP) merupakan paradigma pemrograman yang berorientasikan kepada objek. Semua data dan fungsi di dalam paradigma ini dibungkus dalam kelas-kelas atau objek-objek. Bandingkan dengan logika pemrograman terstruktur. Setiap objek dapat menerima pesan, memproses data, dan mengirim pesan ke objek lainnya.

Model data berorientasi objek dikatakan dapat memberi fleksibilitas yang lebih, kemudahan mengubah program, dan digunakan luas dalam teknik piranti lunak skala besar. Lebih jauh lagi, pendukung OOP mengklaim bahwa OOP lebih mudah dipelajari bagi pemula dibanding dengan pendekatan sebelumnya, dan pendekatan OOP lebih mudah dikembangkan dan dirawat.

Pemrograman orientasi-objek menekankan konsep berikut:

* kelas — kumpulan atas definisi data dan fungsi-fungsi dalam suatu unit untuk suatu tujuan tertentu. Sebagai contoh ‘class of dog’ adalah suatu unit yang terdiri atas definisi-definisi data dan fungsi-fungsi yang menunjuk pada berbagai macam perilaku/turunan dari anjing. Sebuah class adalah dasar dari modularitas dan struktur dalam pemrograman berorientasi object. Sebuah class secara tipikal sebaiknya dapat dikenali oleh seorang non-programmer sekalipun terkait dengan domain permasalahan yang ada, dan kode yang terdapat dalam sebuah class sebaiknya (relatif) bersifat mandiri dan independen (sebagaimana kode tersebut digunakan jika tidak menggunakan OOP). Dengan modularitas, struktur dari sebuah program akan terkait dengan aspek-aspek dalam masalah yang akan diselesaikan melalui program tersebut. Cara seperti ini akan menyederhanakan pemetaan dari masalah ke sebuah program ataupun sebaliknya.

* Objek – membungkus data dan fungsi bersama menjadi suatu unit dalam sebuah program komputer; objek merupakan dasar dari modularitas dan struktur dalam sebuah program komputer berorientasi objek.

* Abstraksi – Kemampuan sebuah program untuk melewati aspek informasi yang diproses olehnya, yaitu kemampuan untuk memfokus pada inti. Setiap objek dalam sistem melayani sebagai model dari “pelaku” abstrak yang dapat melakukan kerja, laporan dan perubahan keadaannya, dan berkomunikasi dengan objek lainnya dalam sistem, tanpa mengungkapkan bagaimana kelebihan ini diterapkan. Proses, fungsi atau metode dapat juga dibuat abstrak, dan beberapa teknik digunakan untuk mengembangkan sebuah pengabstrakan.

* Enkapsulasi – Memastikan pengguna sebuah objek tidak dapat mengganti keadaan dalam dari sebuah objek dengan cara yang tidak layak; hanya metode dalam objek tersebut yang diberi ijin untuk mengakses keadaannya. Setiap objek mengakses interface yang menyebutkan bagaimana objek lainnya dapat berinteraksi dengannya. Objek lainnya tidak akan mengetahui dan tergantung kepada representasi dalam objek tersebut.

* Polimorfisme 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. Contohnya, bila sebuah burung menerima pesan “gerak cepat”, dia akan menggerakan sayapnya dan terbang. Bila seekor singa menerima pesan yang sama, dia akan menggerakkan kakinya dan berlari. Keduanya menjawab sebuah pesan yang sama, namun yang sesuai dengan kemampuan hewan tersebut. Ini disebut polimorfisme karena sebuah variabel tungal dalam program dapat memegang berbagai jenis objek yang berbeda selagi program berjalan, dan teks program yang sama dapat memanggil beberapa metode yang berbeda di saat yang berbeda dalam pemanggilan yang sama. Hal ini berlawanan dengan bahasa fungsional yang mencapai polimorfisme melalui penggunaan fungsi kelas-pertama.

* Inheritas- 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 tersebut (bahasa berbasis-objek tidak selalu memiliki inheritas.)



REPORT THIS AD

* Dengan menggunakan OOP maka dalam melakukan pemecahan suatu masalah kita tidak melihat bagaimana cara menyelesaikan suatu masalah tersebut (terstruktur) tetapi objek-objek apa yang dapat melakukan pemecahan masalah tersebut. Sebagai contoh anggap kita memiliki sebuah departemen yang memiliki manager, sekretaris, petugas administrasi data dan lainnya. Misal manager tersebut ingin memperoleh data dari bag administrasi maka manager tersebut tidak harus mengambilnya langsung tetapi dapat menyuruh petugas bag administrasi untuk mengambilnya. Pada kasus tersebut seorang manager tidak harus mengetahui bagaimana cara mengambil data tersebut tetapi manager bisa mendapatkan data tersebut melalui objek petugas adminiistrasi. Jadi untuk menyelesaikan suatu masalah dengan kolaborasi antar objek-objek yang ada karena setiap objek memiliki deskripsi tugasnya sendiri.

1. Unit Testing

Pada konteks pengujian (testing) perangkat lunak berorientasi objek, unit terkecil yang dapat diuji adalah encapsulation dari class atau object, bukannya modul per modul. Sebuah class dapat mengandung sejumlah operasi yang berbeda-beda, dan operasi khusus yang mungkin melibatkan sejumlah class lainnya. Dengan demikian class testing untuk perangkat lunak berorientasi objek ini setara dengan unit testing untuk perangkat lunak konvensional, dimana class testing ini dikendalikan oleh encapsulation operasi-operasi dari class dan prilaku keadaan (state behavior) dari class.

2. Integration Testing

Seperti halnya unit testing, integration testing untuk perangkat lunak berorientasi objek berbeda dengan perangkat lunak konvensional. Ada dua macam strategi untuk pengujian dari sistem berorientasi objek (OO systems), yakni thread-based testing dan use-based testing.
Thread-based testing mengintegrasikan sekumpulan class yang dibutuhkan untuk merespon sebuah input atau event yang diberikan kepada sistem. Setiap thread diintegrasikan dan diuji secara individual. Regression testing digunakan untuk memastikan tidak ada efek samping yang muncul.
Use-based testing dimulai dengan membangun sistem dengan menguji class-class (yang disebut independent classes) yang menggunakan beberapa server class. Setelah independent classes diuji, lapisan (layer) berikutnya dari class-class tersebut (yang disebut dependent classes) yang menggunakan independent classes diuji.Rangkaian lapisan (layer) pengujian dari dependent classes ini diuji sampai keseluruhan sistem dibangun. Tidak seperti integrasi konvensional, selama memungkinkan, penggunaan driver dan stubs sebagai operasi pengganti diabaikan.

3. Validation Testing

Pada validasi atau level sistem, detail dari hubungan class tidak ditampakkan. Seperti halnya validasi pada perangkat lunak berorientasi objek, validasi difokuskan pada aksi user yang tampak dan output dari sistem yang dapat dibaca user. Metoda black-box testing dapat digunakan untuk mengendalikan pengujian validasi.

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.