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



TAMBAHAN MATERI


TRADITIONAL DEVELOPMENT & TESTING (WATERFALL LIFE CYCLE)

> Salah satu yang paling umum dan terkenal pengembangan perangkat lunak tradisional dan proses pengujian yang digunakan dalam industri adalah metode Waterfall Life Cycle.

> Metodologi ini terdiri dari tiga fase pembangunan utama yang terkait atau umumnya memiliki tiga tingkat pengujian utama yang simetris dengan tahap-tahap perkembangan sebagai berikut:
Persyaratan spesifikasi - Sistem pengujian,
Desain awal - Integrasi pengujian, dan
Rinci Desain - Unit pengujian.

> The Penekanan dalam metodologi pengembangan tradisional ini adalah pada dekomposisi fungsional dan struktur desain perangkat lunak. Biasanya sistem ini dirancang menggunakan beberapa bentuk struktur pohon hirarkis.


> Pengujian dilakukan pada tingkat tradisional 3 ini didasarkan pada berikut:


> System: pengujian kotak hitam dilakukan untuk memastikan bahwa perangkat lunak memenuhi semua persyaratan dalam persyaratan spesifikasi;
> Integrasi: pengujian ini dilakukan berdasarkan struktur desain awal, biasanya adalah beberapa bentuk dari atas ke bawah atau bawah ke atas pendekatan (atau kadang-kadang sangat populer tetapi sangat tidak efektif pendekatan big bang). Perhatikan bahwa pengujian Integrasi berdasarkan berat struktur, dan bagaimana unit cocok bersama untuk membentuk struktur. Metode ini baik untuk pengembang tapi tidak terlalu baik bagi penguji yang lebih berkaitan dengan perilaku software;
> Unit: adalah suatu struktur ditentukan oleh pengembang yang biasanya merangkum beberapa fungsionalitas. Biasanya fungsi ini atau kelompok fungsi.
Tes tes driver dan Rintisan bertopik digunakan.



OO DEVELOPMENT & TESTING

> OO desain adalah perilaku didasarkan dengan penekanan pada komposisi sebagai lawan dari dekomposisi fungsional metodologi tradisional. Desain biasanya dilakukan sepotong demi sepotong dan disusun bersama-sama untuk membentuk seluruh sistem.

> OO pendekatan pembangunan yang umumnya didasarkan pada prototipe yang cepat, biasanya dalam hubungannya dengan beberapa bentuk pendekatan inkremental.

> Sebagai hasilnya, tiga tingkat pengujian tradisional tidak secara jelas didefinisikan dalam OO desain dan perangkat lunak.


OBJECT ORIENTED TESTING

> SYSTEM LEVEL TESTING - pengujian tingkat ini umumnya sama tanpa proses pembangunan. Produk akhir masih harus diverifikasi terhadap persyaratan asli spesifikasi menggunakan masukan ke sistem (kotak hitam) dan menganalisis output.

> UNIT LEVEL TESTING - Unit pengujian perangkat lunak OO umumnya dilakukan dengan cara yang sama seperti unit testing perangkat lunak non OO. Satu-satunya perbedaan adalah apa definisi dari perangkat lunak OO unit dalam desain dan pengujian.
> Saat ini ada dua pendekatan arus utama: sebuah METODE, atau CLASS.
> Perbedaan utama antara dua pendekatan adalah tingkat granularity.
> Saya percaya reaksi awal dari kebanyakan perangkat lunak insinyur adalah bahwa seharusnya KELAS unit karena struktur sudah ditetapkan secara jelas dan dari perspektif tingkat tinggi mudah untuk mengelola. Namun setelah diperiksa lebih dekat menjadi jelas bahwa hal ini mungkin bukan pilihan terbaik. Slide berikutnya membandingkan dua struktur.



OO INTEGRATION TESTING

> Dalam perangkat lunak OO konsep program utama diminimalkan dan karenanya tidak ada struktur yang jelas yang menggambarkan aliran imperatif perangkat lunak yang dapat mengikuti penguji.
> Juga karena tidak ada struktur pohon dekomposisi yang jelas, seperti yang ada dalam pengembangan air terjun tradisional, tidak ada "peta jalan" untuk mengikuti
ketika mengintegrasikan unit perangkat lunak.
> Sebagai akibatnya pengujian integrasi yang paling rumit adalah bagian dari pengujian OO.
> Akibatnya, Integrasi pengujian dilakukan dalam pendekatan bottom up dan didasarkan pada perilaku dari software versus struktur. Metode dan kelas-kelas unit diuji dan kemudian disusun dengan kelas-kelas lain dan metode untuk melakukan pengujian integrasi.
> Salah satu pendekatan umum untuk integrasi pengujian adalah penggunaan cluster, yang hanya sekelompok Kelas dan metode mereka yang diperlukan untuk menjalankan beberapa operasi secara keseluruhan Common. Slide berikutnya juga adalah contoh sebuah cluster.
> Untuk melakukan pengujian integrasi tester perlu mengetahui hubungan-hubungan kelas dan metode hubungan dalam dan di antara kelas-kelas. Hal ini dapat dicapai dengan menggunakan Diagram Hubungan Objek (ORD), standar ini adalah desain OO diagram ketergantungan, dan Cabang Block Diagram (BBD) atau Sutradara Grafik yang menunjukkan metode dependensi dalam dan di antara kelas-kelas. Contoh dari grafik diarahkan ditampilkan dalam slide berikutnya.



OO CONCEPTS/EFFECTS ON TESTING

> Ada tiga karakteristik utama Berorientasi Objek desain yang memiliki efek pada pengujian. Oleh karena itu, penting bagi kita untuk memahami konsep-konsep ini untuk menjelaskan apa pengaruh mereka pada pengujian. Slide berikut ini akan menjelaskan setiap konsep dan apa efeknya terhadap pengujian.

a. enkapsulasi;
b. polimorfisme; dan
c. warisan.


ENCAPSULATION

> Dalam pemrograman berorientasi objek, data dan semua operasi yang dilakukan pada beberapa model data dan disimpan dalam satu struktur yang disebut kelas.

> Perilaku dan antarmuka (yang didefinisikan oleh kelas 'metode umum) dari sebuah kelas didefinisikan oleh metode yang beroperasi pada data contoh .. Dalam paradigma konvensional, yang model kedua aspek dilakukan secara terpisah.

> Encapsulation juga menyediakan cara yang efektif untuk informasi menegakkan bersembunyi, dengan menggunakan data pribadi dan metode.

> Namun, salah satu efek samping dari enkapsulasi adalah bahwa hal itu biasanya menghasilkan hubungan yang lebih kompleks terbelenggu ketergantungan di antara objek-objek.



ENCAPSULATION TESTING ISSUES

Keuntungan.
> Encapsulation meminimalkan efek riak membuat perubahan dan karena itu umumnya meminimalkan jumlah pengujian regresi diperlukan pada tingkat UNIT.

Kerugian.
> Encapsulation menghasilkan struktur yang sangat terdelokalisasi. Oleh karena itu mungkin diperlukan untuk memanggil beberapa metode dari beberapa kelas objek yang berbeda untuk mencapai fungsi yang dimaksud. Selain itu mungkin ada beberapa kemungkinan doa path. Penggunaan enkapsulasi memiliki efek samping menciptakan ketergantungan jauh lebih kompleks hubungan antara struktur encapsulation.
> Sebagai hasilnya, membuat perubahan dalam satu kelas dapat mengakibatkan sejumlah besar pengujian regresi pada tingkat INTEGRASI, karena secara teori setiap skenario yang menggunakan metode yang sudah diubah (s) atau data harus diuji ulang.

Lain
> Urutan di mana dilakukan pengujian dapat sangat penting dan dapat menghasilkan penghematan yang signifikan dalam waktu dan usaha. Hal ini dibahas lebih lanjut dalam slide berikutnya.



POLYMORPHISM

> Dalam paradigma berorientasi objek, dimungkinkan untuk mendefinisikan satu antarmuka umum untuk beberapa metode dengan nama yang sama yang melakukan operasi yang sama atau mirip. Hal ini membantu mengurangi kompleksitas dengan menggunakan atau Reusing antarmuka yang sama untuk menentukan tindakan kelas umum.

> Contoh ini adalah metode yang digunakan untuk menggambar grafik. Jika tiga dimensi yang berlalu, metode menggambar menciptakan sebuah segitiga, jika empat dimensi segi empat, lima pentagon dll Dalam hal ini terdapat tiga metode yang berbeda dengan nama yang sama tetapi mereka menerima jumlah yang berbeda dalam metode variabel panggilan.

> Secara umum pemilihan varian ditentukan pada saat run-time (dinamis mengikat) oleh kompilator didasarkan pada, misalnya, jenis atau jumlah argumen berlalu.


OO TESTING ISSUES

> Beberapa pertanyaan kunci muncul yang perlu dipertimbangkan sebelum pengujian:

> 1. Apakah Anda hanya perlu satu varian?
> 2. Apakah Anda menguji semua varian?
> 3. Jika semua, apakah Anda perlu untuk menguji semua di semua level?

> Tidak ada satu set jawaban untuk pertanyaan ini. Jawaban atas pertanyaan-pertanyaan ini akan tergantung pada penguji, kebijakan perusahaan dan lain-lain

> Dalam dunia yang sempurna anda akan menguji segalanya. Namun, dalam kenyataannya biasanya tidak mungkin untuk menguji segala sesuatu dalam proyek skala besar.

> Advantage. Kasus pengujian yang sama (Supir dan Rintisan) dapat digunakan untuk menguji setiap varian pada tingkat UNIT (test Reuse). Juga karena penggunaan kembali perangkat lunak, mungkin tidak perlu untuk menguji semua varian pada tingkat INTEGRASI jika masing-masing adalah sepenuhnya diuji pada tingkat UNIT. Apakah setiap varian akan diuji pada level sistem akan tergantung pada persyaratan spesifikasi.



INHERITANCE MODIFIERS

Modifikasi teknik yang ada dalam warisan adalah:


a. NONE. Tidak ada modifikasi.

b. ADD NEW. Para pengubah hanya menambahkan atribut baru (metode dan variabel) untuk kelas induk.

c. Redefine ORANGTUA'S ATRIBUT. Para pengubah mengubah beberapa atribut yang ada diwarisi dari kelas induknya. Sebagai contoh, sebuah metode yang didefinisikan dalam kelas induk berubah (ulang) di subclass. Keseluruhan fungsionalitas sama, namun pelaksanaannya berbeda.

d.VIRTUAL Atribut (ekstensi). Jenis meluas pengubah metode yang sudah ada atau kelas didefinisikan dalam kelas induk. Sebagai contoh, benang di JAWA. Jika tidak subclass memperpanjang metode maka itu tidak berubah. Jika tidak itu hanya ditambahkan pada, dalam rangka untuk menyelesaikan metode.


OO TESTING ISSUES

> Kemungkinan harus berurusan dengan warisan yang berbeda struktur dan kemungkinan tambahan berpotensi berurusan dengan berbagai bentuk warisan dapat menambah tingkat kerumitan yang lain untuk proses pengujian.

> Mengangkat isu-isu ini sejumlah pertanyaan:
1. Apakah Anda benar-benar menguji semua kelas BASE dan subclass mereka dan pada tingkat apa yang harus Anda uji?
2. Apakah Anda benar-benar menguji semua kelas dan hanya BASE perubahan atau modifikasi dalam subclass, dan jika demikian di mana tingkat?
3. Urutan di mana Anda menguji hirarki, atas ke bawah atau bawah ke atas?

> Untuk menjawab nomor 3 pertama, praktek yang diterima secara umum adalah untuk menguji atas ke bawah, dimulai dengan kelas BASE dan bekerja dengan cara Anda turun. Hal ini memungkinkan tester untuk menggunakan kembali uji kasus, dan hasil tes potensial dalam situasi tertentu.
> Yang tingkat untuk menguji di (unit, integrasi) akan dibahas dalam slide berikutnya.


by STIKOM SURABAYA STUDENT
s070319@si.stikom.edu