Setyorinihestiningtyas's Blog

Just another WordPress.com weblog

V-Class Pengujian Object Oriented

Dalam pengujian berorientasi objek, unit terkecil adalah objek dan class, sistem merupakan sekumpulan komunikasi-komunikasi antar objek. Class sering dirancang untuk menerima urutan pesan-pesan tertentu yang mengakibatkan respon class terhadap pesan-pesan tersebut menjadi berbeda-beda Hal ini selanjutnya disebut dengan perilaku (behavior) class. Perilaku tersebut dapat dikendalikan dengan nilai yang ter-enkapsulasi, urutan pesan atau keduanya.

Pengujian Perangkat Lunak Berorientasi Objek

Pengujian adalah suatu proses pengeksekusian program yang bertujuan untuk menemukan kesalahan (Berard, 1994). Pengujian sebaiknya menemukan kesalahan yang tidak disengaja dan pengujian dinyatakan sukses jika berhasil memperbaiki kesalahan tersebut. Selain itu, pengujian juga bertujuan untuk menunjukkan kesesuaian fungsi-fungsi perangkat lunak dengan spesifikasinya.

Pengujian dapat dikategorikan atas :

  1. Pengujian terhadap proses pengembangan sistem dan dokumendokumen 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.

Perangkat lunak berorientasi objek berbeda dari perangkat lunak procedural (konvensional) dalam hal analisis, perancangan, struktur dan teknik-teknik pengembangannya. Bahasa pemrograman berorientasi objek mempunyai ciri-ciri adanya pembungkusan (encapsulation), keanekaragaman (polymorphism), dan pewarisan (inheritance) yang membutuhkan dukungan pengujian tertentu. Fokus pengujian perangkat lunak berorientasi objek dimulai pada hasil analisisnya, dilanjutkan pada hasil perancangannya, dan diakhir pada hasil pemrogramannya (Rochimah, 1997). Model yang dihasilkan pada analisis dan perancangan harus diperiksa terutama dalam hal :

  1. Semantic correctness, yaitu kesesuaian model dengan domain permasalahan di dunia nyata. Jika model merefleksikan dunia nyata secara akurat, berarti model tersebut benar secara semantik, dan
  2. Consistency, yaitu kesesuaian kelas dengan objek turunannya maupun kesesuaian asosiasi kelas dengan kelas lainnya.

Model Uji (Test Model)

Berbagai model pengujian perangkat lunak berorientasi objek diusulkan oleh para peneliti. Setiap model mempunyai konstruksi atau aturan yang menjadi dasar dalam langkah-langkah pengujian.

State-Transition Model

Transisi dalam pengujian method (operasi) suatu class menunjukkan konsep perilaku class. Setiap method dalam class mengekspresikan beberapa elemen dari keseluruhan perilaku class. Dalam beberapa metoda perancangan berorientasi objek menggunakan model State-Transition untuk merepresentasikan perilaku class. State (Status) suatu objek adalah kombinasi dari semua nilai atribut. Pada saat tertentu, status bersifat statik.

Untuk model dinamik objek, perlu ditambahkan transisi dari satu status ke status lainnya dan terjadilah suatu aksi. Model ‘transisi-status’ digambarkan dengan grafik, dimana simpul menyatakan status dan busur menyatakan transisi.

Boris Beizer memberikan beberapa aturan untuk pengecekan model “Transisi-status”, yaitu :

  1. Verifikasi bahwa status telah merepresentasikan himpunan satus dengan benar;
  2. Cel model untuk semua kemungkinan event suatu class, yaitu transisi dari setiap status untuk setiap method dalam class dan cek spesifikasi perancangannya;
  3. Cek terhadap ketetapan satu tansisi untuk setiap kombinasi “eventstate”. Lakukan pengecekan, misal dengan representasi matriks sebagai kombinasi kemungkinan status dan event;
  4. Cek status yang tidak terjangkau dan status mati, dimana pada status tersebut tidak ada lintasan atau transisi;
  5. Cek aksi yang tidak benar(invalid), termasuk method (operasi) yang tidak ada atau method yang tidak sesuai dengan kebutuhan selama transisi.

Model “transisi-status” dapat mencakup keseluruhan perilaku class, sehingga lebih produktif dibanding dengan model lainnya, namun mempunyai beberapa kelemahan yaitu :

  1. Karena model dibentuk dari spesifikasi kebutuhan, bukan dari kode, mudah menyebabkan kesalahan sehingga perlu menguji model seperti halnya menguji kode;
  2. Karena model mencakup seluruh perilaku class dan superclass-nya, maka model menjadi kompleks. Namun pemakaian “transisi-status” secara hirarki dapat mengurangi kompleksitas tersebut
  3. Model perilaku dapat mengakibatkan hilangnya kendali dan data yang salah. Oleh karena itu perlu adanya asumsi yang sama tentang perilaku class yang didasarkan pada kebutuhan dengan asumsi yang dibuat oleh pemrogram.

Object Oriented Analysis (OOA) dan Object Oriented Design (OOD)

Object-Oriented Analysis

  • 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.
  • Mendefinisikan kebutuhan-kebutuhan sistem melalui skenario atau penggunaan kasus-kasus.
  • Kemudian, membuat suatu model obyek dengan kemampuan memenuhi kebutuhan-kebutuhan.
  • Output: Model kebutuhan-kebutuhan, biasanya menggunakan CRC Cards.
  • Memberikan gambaran rinci dari suatu sistem.
  • Mengidentifikasi “WHAT” kebutuhan fungsional (Use Cases)
  • Identifikasi: objects, classes, operations
  • Identifikasi: object relationships, object interations
  • Bangun model-model di dunia nyata menggunakan tampilan OO
  • Tujuan dari OOA adalah untuk memahami domain masalah dan meningkatkan ketelitian, konsistensi, kelengkapan

Object-Oriented Design

  • Object-oriented design adalah metoda untuk meng-arahkan arsitektur perangkat lunak yang didasarkan pada manipulasi objek-objek sistem atau subsistem.
  • Model kebutuhan-kebutuhan yang dibuat pada fase analisis diperkaya dalan fase perancangan.
  • Kadang-kadang ditambahkan lebih banyak lagi atribut dan pelayanan.
  • Ditambahkan antarmuka obyek-obyek.
  • Memberikan blueprint untuk implementasi
  • Menspesifikasi “HOW”
  • Menspesifikasi: class definitions, class categories
  • Menspesifikasi: subsystems, system architectures
  • OOA + Rincian Implementasi
  • Tujuan dari OO Design adalah mengoptimalkan maintainability, reusability, enhancebility dan reliability

Object-Oriented Testing

  • Proses ujicoba sistem yang berorientasi objek (object-oriented system) dimulai dengan meninjau ulang analisis dan model desain berorientasi obyeknya (object-oriented analysis and design models).Ketika sebuah program telah dituliskan, object-oriented testing (OOT) dimulai dengan menguji “in the small” dengan class testing (class operations dan collaborations). Ketika class-class tersebut diintegrasikan menjadi sebuah subsistem, maka masalah kolaborasi class akan diketahui. Terakhir, use-cases dari model OOA digunakan untuk menemukan kesalahan validasi software.
  • OOT hampir mirip dengan ujicoba software konvensional dalam hal kasus uji yang akan dibangun untuk melatih class-class yang ada dan kolaborasi antar class-nya juga prilakunya.
  • OOT berbeda dari ujicoba software konvensional dalam hal penekanan terhadap konsistensi dan kelengkapan penaksiran dari model OOA dan OOD yang telah dibangun.
  • OOT cenderung lebih fokus kepada masalah integrasi dari pada unit testing.

Object-Oriented Testing Activities

  • Meninjau ulang model OOA dan OOD
  • Ujicoba Class setelah penulisan program sumber
  • Ujicoba Integrasi dalam subsistems
  • Ujicoba Integrasi subsistem yang telah ditambahkan kedalam sistem
  • Ujicoba validasi berdasarkan OOA use-cases

Ujicoba Model OOA dan OOD

  • OOA dan OOD tidak dapat diujikan tetapi dapat ditinjau ulang untuk ketepatan dan konsistensinya
  • Ketepatan dari model OOA dan OOD
  • Consistency of OOA and OOD Models
  • Menilai model CRC (class- responsibility-collaborator) dan diagram hubungan antar obyek.
  • Meninjau desain sistem (memeriksa model perilaku objek untuk memeriksa pemetaan perilaku sistem ke subsystems, meninjau konkuresi dan alokasi tugas, menggunakan skenario use-case untuk memeriksa desain antarmuka pengguna)
  • Model Obyek test terhadap jaringan relasi objek untuk memastikan bahwa semua desain objek berisi atribut dan operasi yang diperlukan untuk melaksanakan kolaborasi yang ditetapkan untuk setiap kartu CRC.
  • Periksa rincian spesifikasi algoritma yang digunakan untuk melaksanakan operasi konvensional menggunakan teknik inspeksi

Strategi Ujicoba Berorientasi Objek (Object-Oriented Testing Strategies)

  • Unit testing dalam konteks OO
    • Unit terkecil yang diujikan adalah enkapsulasi class atau objek
    • Hampir serupa dengan ujicoba sistem pada software konvensional
    • Tidak menguji operasi dalam isolasinya dengan operasi yang lain
    • Dijalankan oleh operasi class dan perilaku tetap, bukan detail algoritmik dan aliran data yang melintasi antar interface modul
    • Ujicoba lengkap keseluruhan class meliputi :

– 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

– Ujicoba berbasis kesalahan (fault-based testing)

– Ujicoba acak (random testing)

–  Ujicoba Partisi (partition testing)

  • Setiap metode-metode ini akan melatih operasi yang dienkapsulapsi oleh class
  • Urutan ujicoba didesain untuk memastikan bahwa operasi yang relevan telah diujicobakan
  • Posisi tetap suatu class (Nilai atributnya) di uji untuk menentukan apakah terdapat kesalahan

Integration testing dalam konteks OO

  • difokuskan pada kelompok-kelompok kelas yang berkolaborasi atau berkomunikasi dalam beberapa cara.
  • Integrasi operasi satu per satu ke dalam kelas sering sia-sia
  • Ujicoba berbasis thread (uji semua kelas yang dibutuhkan untuk merespon ke satu masukan atau event sistem)
  • Pengujian berbasis Kegunaan (dimulai dengan uji independen oleh kelas pertama dan kelaskelas yang tergantung yang menggunakannya)
  • Pengujian cluster (kerjasama kelompok kelas yang diuji untuk interaksi kesalahan)
  • Pengujian regresi adalah penting karena setiap thread, cluster, atau subsistem yang ditambahkan pada sistem
  • Tingkat integrasi yang lebih sedikit berbeda dalam sistem berorientasi objek

Validation testing dalam konteks OO

  • Berfokus pada tindakan pengguna yang terlihat dan pengguna dapat mengenali output dari sistem
  • tes validasi didasarkan pada skenario use-case, model perilaku objek, dan diagram alur event dibuat dalam model OOA
  • Pengujian Black box konvensional dapat digunakan untuk mendorong tes validasi

Test Case Design untuk software OO

 Setiap kasus uji harus dapat diidentifikassikan secara unik dan secara eksplisit dihubungkan dengan class yang akan diujikan

 Tetapkan kegunaan dari setiap ujicoba

 Tuliskan langkah-langkah ujicoba untuk setiap ujicoba yang disertakan, diantaranya:

  • Tuliskan tahapan ujicoba untuk setiap objek yang disertakan dalam ujicoba
  • Tuliskan pesan-pesan dan operasi yang dijalankan sebagai konsekuensi dari ujicoba ini
  • Tuliskan eksepsi yang muncul ketika suatu objek di ujicoba
  • Tuliskan kondisi eksternal yang memerlukan perubahan untuk ujicoba tersebut
  • Informasi tambahan lainnya yang diperlukan untuk memahami atau mengimplementasikan ujicoba tersebut.

 Ujicoba Struktur permukaan dan Struktur Dalam (Testing Surface Structure and Deep Structure)

  • Ujicoba struktur permukaan (Testing surface structure) yaitu melatih struktur yang tampak oleh pengguna akhir, sering kali melibatkan pengamatan dan mewawancarai pengguna karena mereka memanipulasi objek sistem
  • Ujicoba struktur dalam (Testing deep structure) yaitu melatih struktur program internal, seperti ketergantungan, perilaku, dan mekanisme komunikasi yang ada sebagai bagian dari sistem dan desain objek.

Metode Testing yang Dapat diaplikasikan pada Tingkatan Class (Testing Methods Applicable at The Class Level)

 Random testing – memerlukan sejumlah besar permutasi dan kombinasi data, dan dapat menjadi tidak efisien

o Identifikasikan operasi yang mungkin pada class

o Definisikan batasan penggunaannya

o Identifikasikan urutan ujicoba minimum

o Buatlah beberapa variasi urutan ujicoba random

 Partition testing – Menghilangkan sejumlah kasus uji yang dibutuhkan untuk menguji sebuah

class

  • state-based partitioning – ujicoba didesain dalam suatu cara sehingga operasi yang menyebabkan perubahan state diujikan secara terpisah dari yang tidak.
  • attribute-based partitioning – untuk setiap atribut class, operasi diklasifikasikan berdasarkan pengguna atribut tersebut, yang memodifikasi atribut dan yang tidak menggunakan atau memodifikasi atribut
  • category-based partitioning – operasi dikategorikan berdasarkan fungsi yang dilakukannya, seperti : inisialisasi, komputassi, query, terminasi

 Fault-based testing

  • Terbaik untuk operasi dan tingkatan class
  • Menggunakan struktur pewarisan
  • Pengujian memeriksa model OOA dan menghipotesis sekumpulan kerusakan yang dipahami yang mungkin terjadi dalam pemanggilan operasi dan sambungan pesan, dan membangun kasus uji yang sesuai
  • Menemukan spesifikasi yang tidak tepat dan kesalahan dalam interaksi subsistem

Inter-Class Test Case Design

  • Desain kasus uji menjadi lebih rumit seperti halnya integrasi dari dimulainya sistem OO – menguji kolaborasi antar class
  • Ujicoba class yang beragam, seperti :

–          Untuk setiap class client menggunakan daftar operator classs untuk men-generate urutan ujicoba random yang mengirimkan pesan ke server class yang lain

–           Untuk setiap pesan yang di-generate, tentukan class kolaborator dan operator server object yang ditunjuk

–          Untuk setiap operator server class (dimohon oleh pesan dari client object) tentukan pesan yang dikirimkan

–          Untuk setiap pesan, tentukan tingkatan operator berikutkan yang memohon dan menggabungkannya kedalam urutan ujicoba

  • Ujicoba yang dihasilkan dari model perilaku

–          gunakan state transition diagram (STD) sebagai model yang merepresentasikan perilaku dinamis dari suatu class.

–           Kasus uji harus mencakkup seluruh tahapan STD

–           breadth first traversal dari state model dapat digunakan (uji satu transisi dalam satu waktu dan hanya membuat kegunaan daari transisi yang diujikan sebelumnya ketika mengujikan transisi yang baru)

–           Kassus uji juga dapat dihasilkan untuk memastikan bahwa seluruh perilaku untuk class telah diujikan dengan benar

Testing Methods Applicable at Inter-Class Level

 Cluster Testing

  • Menitikberatkan pada pengintegrasian dan menguji kelompok objek yang bekerja sama
  • Mengidentifikasi kelompok dengan menggunakan pengetahuan tentang pengoperasian objek dan memiliki sistem yang diterapkan oleh kelompok ini.
  • Pendekatan Cluster Testing

–          Use-case atau ujicoba scenario

  • Ujicoba berdasarkan pada interaksi user dengan sistem
  • Mempunyai keuntungan bahwa fitur ujicoba sistem seperti yang dialami pengguna.

–          Thread testing – menguji respon sistem terhadap event sebagai pemrosesan thread melalui sistem

–          Object interaction testing – menguji urutan interaksi objek yang berhenti ketika operasi objek tidak memanggil layanan dari objek lainnya

 Use Case / Scenario-based Testing

  • Berdasarkan pada

–          use cases

–          corresponding sequence diagrams

  • Identifikassi skenario dari use-case dan menambahkan hal ini dengan diagram interaksi yang menampilkan objek-objek yang termasuk dalam scenario
  • Konsentrasi pada kebutuhan (fungsional) :

–          Setiap use case

–          Setiap perluasan kombinasi perpanjangan penuh(<<extend>>)

–          Setiap perluasan kombinasi penggunaan penuh(<<uses>>)

–          Ujicoba normal seperti perilaku

  • Sebuah skenario adalah sebuah alur/path melalui diagram urutan
  • Banyak skenario yang berbeda dapat dihubungkan dengan sebuah diagram urutan
  • Mengggunakan tugas pengguna yang dideskripsikan dalan use-cases dan membangun kasus uji dari tugas-tugas tersebut dan variasinya
  • Menemukan kesalahan yang muncul ketika pengguna berinteraksi dengan software OO
  • Konsentrasi pada apa yang dilakukan oleh fungsinya, bukan apa yang dilakukan oleh produknya
  • Dapat memperoleh nilai kembali yang lebih besar atas usaha dan waktu lebih yang dikeluarkan dalam meninjau ulang use-cases semenjak mereka dibuat, dari pada membuang waktu untuk uji coba use-case

OO Test Design Issues

 Metode White-box testing dapat diaplikasikan pada ujicoba kegunaan program untuk

mengimplementasi operasi class tetapi tidak untuk lainnya

 Metode Black-box testing method sangat tepat untuk ujicoba sistem OO

 Object-oriented programming menyebabkan kebutuhan tambahan untuk ujicoba, berupa :

  • class dapat mengandung operasi yang diturunkan dari super classes
  • subclass dapat mengandung operasi yang didefinisikan ulang daripada diturunkan
  • seluruh class dihasilkan dari ujicoba class dasar sebelumnya memerlukan ujicoba lanjutan

sumber tulisan ini :

http://ayuliana_st.staff.gunadarma.ac.id/Downloads/folder/0.1

Jurnal Universitas Paramadina, Vol. 2 No. 2, Januari 2003 oleh Retno Hendrowati,dengan judul Pengujian Perangkat Lunak Berorientasi Obyek

No comments yet»

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: