PENGUJIAN BERORIENTASI OBYEK

MAKALAH TESTING DAN IMPLEMENTASI SISTEM

“PENGUJIAN BERORIENTASI OBYEK”.

-Erika Pradita              13114606

-Irsyaad Izzudin           15114472

-Ludfi Satria                16114146

-Sherlianna Dewi         1A114225

4KA23

UNIVERSITAS GUNADARMA

FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMATIKA

TAHUN AJARAN 2017/2018

PEMBAHASAN

PENGUJIAN BERORIENTASI OBYEK

Þ    Pengertian Oop

Þ    Kelebihan Dan Kekurangan Pemrograman Berorientasi Objek

Þ    Object Oriented Testing

Þ    Disain Test Case Untuk Software Oo

Þ    Unit Testing Dalam Kontek Oo

Þ    Validation Testing Dalam Kontek Oo

Þ    Object-Oriented Analysis

Þ    Object-Oriented Design

Kata Pengantar

            Puji dan syukur penulis panjatkan kehadirat Tuhan Yang Maha Esa yang telah memberikan rahmat dan karunia-Nya sehingga kami dapat menyelesaiakan makalah dengan judulPENGUJIAN BERORIENTASI OBYEK. Makalah ini disusun dalam rangka memenuhi tugas kelompok dalam mata kuliahan TESTING DAN IMPLEMENTASI SISTEM

Tidak lupa kami juga mengucapkan banyak terimakasih atas bantuan dari pihak yang telah berkontribusi dengan memberikan sumbangan baik materi maupun pikirannya.

            Atas bimbingan bapak dosen dan saran dari teman-teman maka disusunlah makalah ini. Semoga dengan tersusunnya makalah ini diharapkan dapat berguna bagi kami semua dalam memenuhi salah satu syarat tugas kami di perkuliahan. Makalah ini diharapkan bisa bermanfaat dengan efisien dalam proses perkuliahan.

Karena keterbatasan pengetahuan maupun pengalaman kami, kami yakin masih banyak kekurangan dalam makalah ini, Oleh karena itu kami sangat mengharapkan saran dan kritik yang membangun dari pembaca demi kesempurnaan makalah ini.

Depok, 28 November  2017

Penyusun

A.    PENGERTIAN OOP

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.)

* 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.

kelebihan dan kekurangan pemrograman berorientasi objek

OOP memiliki beberapa keuntungan dalam pemrograman, di antaranya:

1.      OOP menyediakan struktur modular yang jelas untuk program sehingga OOP sangat bagus digunakan untuk mendefinisikan tipe data abstrak di mana detil implementasinya tersembunyi.

2.      OOP akan mempermudah dalam memaintain dan memodifikasi kode yang sudah ada. Objek yang baru dapat dibuat tanpa mengubah kode yang sudah ada.

 3.      OOP menyediakan framework untuk library kode di mana komponen software yang tersedia dapat dengan mudah diadaptasi dan dimodifikasi oleh programmer. Hal ini sangat berguna untuk mengembangkan GUI (Graphical User Interfaces).

                                                              
Sedangkan beberapa kelemahan OOP antara lain adalah sebagai berikut:

1.       Tidak memperbolehkan implementasi yang kuat pada reuse

2.    Properti software tidak terikat dalam satu unit fungsional, sehingga harus crosscut di antara komponennya.

3.     Crosscut tersebut mengakibatkan sulitnya pengembangan dan pemeliharaan.

B.     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).

Metode Pengujian Berorientasi Objek

Pengujian sistem berorientasi objek umumnya dilakukan secara bottom-up dalam empat level :

1. Pengujian level metode yang menguji metode individu di kelas.
2. Metode-metode dan atribut-atribut yang menyusun kelas. Pengujian level kelas (intra kelas) adalah pengujian terhadap interaksi-interaksi di antara komponen-komponen di satu kelas individu.
3. Kelas-kelas yang bekerja sama menyusun tandan kelas (class cluster). Pengujian tandan kelas menguji interaksi-interaksi di antara kelas-kelas.
4. Tandan-tandan kelas menyusun sistem. Pengujian level sistem berurusan dengan masukan dan keluaran yang tampak bagi pemakai sistem.

C.    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.

Strategi klasik pengujian perangkat lunak:

• Dimulai dari pengujian unit, bergerak menuju pengujian integrasi dan berakhir pada validasi dan pengujian sistem.
• Pengujian unit berfokus pada satuan program kecil yang dapat di-compile.
• Unit diintegrasikan dengan suatu struktur program.
• Pengujian regresi dijalankan untuk mengungkap kesalahan sehubungan dengan interfacing modul dan efek samping yang disebabkan oleh penambahan unit-unit baru.
• Sistem secara keseluruhan diuji untuk memastikan apakah kesalahan terungkap.

Perubahan strategi pengujian pada pendekatan berorientasi objek

• Pengujian unit, monsep mengenai unit diperluas di sistem berorientasi objek.
• Pengujian integrasi, integrasi berfokus pada kelas-kelas dan eksekusinya pada satu thread atau use case.

D.    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.

E.     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.

OOA DAN OOD

F.     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

G.    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

1.      Pendahuluan

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

2.      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

3.      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

4.      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

5.      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

identifikasikan operasi yang mungkin pada class

Definisikan batasan penggunaannya

Identifikasikan urutan ujicoba minimum

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 skenario

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 skenario

· 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

KESIMPULAN

 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.