Strategi testing berorientasi obyek
8.2.3 Strategi testing berorientasi obyek
Strategi kla sik untuk testing software komputer dimulai dengan “testing kecil “ dan bekerja keluar menuju “testing besar “ dinyatakan dalam jargon mengenai testing software , kita mulai
dengan unit testin g , lalu bergerak menuju integration testing , dan berakhir pada validation testing dan syste m testing . Dalam aplikasi konvensional, unit testing berfokus pada satuan program terkecil y ang dap at di- compile – subprogram (misalnya subrutin, prosedur). Begitu masing-masing un it ini dites secara individual maka , unit diintegrasikan dengan suatu struktur program, sement ara sederetan regression testing dijalankan untuk mengungkap error
sehubungan dengan interfaci By Hendranet ng modul dan efek samping yang disebabkan oleh
penambahan unit -unit baru. Akhirnya, sistem secara keseluruh an dites untuk memastikan apakah error terun gkap.
Unit testing dalam konteks OO
Pada saat software OO diperhatikan, konsep mengenai unit jadi berubah. Enkapsulasi mengendalikan definisi kelas dan objek. Ini berarti bahwa masing-masing kelas dan bagian dari suatu kelas (obyek) mengemas (data) dan operasi (juga diketahui sebagai metode atau pelayanan) yang memanipulasi data-data tersebut. Selain modul individual, unit terkecil yang dapat dites me rupakan data atau ob yek enkapsulasi. Kelas dapat berisi sejumlah operasi yang berbeda, dan operasi khusus dapat muncul sebagai bagian dari kelas-kelas yang berbeda. Demikianla h, arti dari unit testing ber ubah secara dramatis. Kita tidak dapat le bih jauh lagi melakukan testing operasi tunggal terisolasi (pandangan konvensional meng enai unit tes ting ) tetapi lebih sebagai bagian dari suatu kelas. Untuk menggambarkannya , diperhatikan hirarki kela s di mana suatu X ditentukan untuk superkelas dan diwariskan oleh sejumlah subkelas. Masing-masing subkelas menggunakan operasi X, tetapi dia diaplikasikan di dalam konteks atribut dan operasi privat yang telah ditetapkan untuk m asing-masing subkelas. Karena konteks di mana operasi X digunakan secara bervariasi, maka perlu untuk melakukan testing operasi X dalam konteks masing-masing Pada saat software OO diperhatikan, konsep mengenai unit jadi berubah. Enkapsulasi mengendalikan definisi kelas dan objek. Ini berarti bahwa masing-masing kelas dan bagian dari suatu kelas (obyek) mengemas (data) dan operasi (juga diketahui sebagai metode atau pelayanan) yang memanipulasi data-data tersebut. Selain modul individual, unit terkecil yang dapat dites me rupakan data atau ob yek enkapsulasi. Kelas dapat berisi sejumlah operasi yang berbeda, dan operasi khusus dapat muncul sebagai bagian dari kelas-kelas yang berbeda. Demikianla h, arti dari unit testing ber ubah secara dramatis. Kita tidak dapat le bih jauh lagi melakukan testing operasi tunggal terisolasi (pandangan konvensional meng enai unit tes ting ) tetapi lebih sebagai bagian dari suatu kelas. Untuk menggambarkannya , diperhatikan hirarki kela s di mana suatu X ditentukan untuk superkelas dan diwariskan oleh sejumlah subkelas. Masing-masing subkelas menggunakan operasi X, tetapi dia diaplikasikan di dalam konteks atribut dan operasi privat yang telah ditetapkan untuk m asing-masing subkelas. Karena konteks di mana operasi X digunakan secara bervariasi, maka perlu untuk melakukan testing operasi X dalam konteks masing-masing
Integrati on testing dalam konteks OO
Karena software OO tidak memiliki struktur kendali hirarki, maka strategi integrasi top-down dan bottom -up menjadi kurang bera rti. Sebagai tambahan, mengintegrasikan operasi – satu operasi pa da satu waktu – ke da lam suatu kelas (pendekatan integrasi inkremental konvensional) sering tidak mungkin karena “interaksi langsung dan tidak langsung dari komponen yang membentuk kelas [BER93].” Ada dua strategi yang berbeda untuk integration testing dari sistem OO [BIN94a]. Pertama, pengujian thread based yang mengintegrasikan himpunan kelas yang dibutuhkan untuk merespon ke satu input atau bahkan untuk sistem. Masing-masing thread dii ntegrasikan dan dites secara individual. Regression testing diaplikasikan untuk memastikan bahwa tidak terjadi efek samping. Pendekatan integrasi kedua, use-based testing , memulai konstruksi sistem dengan melakukan testing kelas-kelas tersebut (disebut kelas independen) yang menggunakan sangat sedikit (atau kalau ada) kelas-kelas server. Setelah kelas-kelas independen dites, lapisan kelas selanjutnya dites, yaitu kelas dependen yang menggunakan kelas independen. Urutan lapisan testing kelas dependen ini berlanjut sampai keseluruhan By Hendranet sistem dibangun. Tidak seperti integrasi konvensional, penggunaan driver dan stub sebagai operasi pengganti akan dihindari bila mungkin. Cluster testing [MCG94] adalah satu langkah di dalam pengujian integrasi software OO. Di sini cluster kelas yang berkolaborasi (ditentukan dengan menguji CRC dan model hubungan obyek) untuk digunakan dengan mendisain test case yang berusaha mengungkapkan kesalahan di dalam kolaborasi.
Validation Testing dalam Konteks OO
Pada tingkat sistem atau validasi, detil sambungan kelas hilang. Seperti validasi konvensional, validasi software OO berfokus pada aksi yang dapat dilihat oleh pengguna dan keluaran yang dapat dikenali oleh pengguna sistem tersebut. Untuk membantu derivasi validation testing , tester harus menggunakan use case yang merupakan bagian dari model analisis. Use case menyediakan skenario yang kemungkinan besar mengungkap error di dalam persyaratan interaksi pengguna. Metode black box testing konvensional dapat digunakan untuk mengendalikan validation testing . Use case juga ditarik dari model tingkah laku obyek dan dari diagram aliran kejadian yang diciptakan sebagai bagian dari OOA.