Pengujian Berorientasi Objek Program

Pengujian Berorientasi Objek Program

Perangkat lunak berorientasi objek secara signifikan berbeda dari perangkat lunak prosedur tradisional dalam hal analisis, desain, struktur, dan teknik pengembangan, dukungan pengujian begitu spesifik juga diperlukan [FIRESMITH]. Fitur bahasa berorientasi objek dari encapsulation, polimorfisme, dan pewarisan memerlukan dukungan tes khusus, tetapi juga memberikan kesempatan bagi eksploitasi oleh strategi pengujian. Untuk menyesuaikan terstruktur pengujian untuk program berorientasi objek, pertimbangkan baik uji modul dan uji integrasi. pengujian terstruktur pada tingkat modul dapat langsung diterapkan program berorientasi obyek untuk, meskipun fakta bahwa tidak segera jelas. Pada tingkat integrasi, pengujian terstruktur tidak memerlukan modifikasi untuk mengatasi pengikatan dinamis metode berorientasi objek. Sisanya bagian ini membahas implikasi spesifik pemrograman berorientasi obyek untuk pengujian terstruktur. Sebagian dari informasi ini sebelumnya diterbitkan dalam [] MCCABE3 dan [MCCABE4].

Manfaat dan bahaya abstraksi

Bahasa berorientasi objek dan menggunakan teknik baru dan tingkat abstraksi yang lebih tinggi dari bahasa yang paling tradisional, terutama melalui mekanisme warisan. Ada baik manfaat dan bahaya untuk abstraksi ini. manfaat adalah bahwa pelaksanaan yang lebih dekat dengan desain logis, semakin mudah untuk memahami fungsi dimaksud kode. Bahayanya adalah bahwa pelaksanaan lebih lanjut dari perhitungan mesin, semakin sulit untuk memahami fungsi yang sebenarnya kode. Gambar 8-1 mengilustrasikan trade-off ini. Kekuatan abstraksi dari bahasa berorientasi objek biasanya memudahkan programmer untuk menulis kode menyesatkan. Informal, mudah untuk mengatakan kode apa yang harus dilakukannya, tetapi sulit untuk mengatakan apa yang sebenarnya. Oleh karena itu, dukungan otomatis untuk analisis dan pengujian sangat penting dalam lingkungan berorientasi objek.

Ketika abstraksi bekerja dengan baik, maka menyembunyikan detail yang tidak perlu diuji, sehingga pengujian menjadi lebih mudah. Ketika abstraksi karya buruk, maka menyembunyikan rincian yang perlu diuji, sehingga pengujian menjadi lebih keras (atau paling buruk, layak). Biasanya, pengujian harus terjadi pada beberapa tingkat kompromi abstraksi, mendapatkan leverage dari abstraksi yang memperjelas fungsi perangkat lunak, sementara menembus abstraksi yang tidak jelas itu. Seringkali, tingkat seorang pengembang perangkat lunak keakraban dengan teknik pengembangan berorientasi obyek merupakan faktor kunci dalam menentukan apakah abstraksi digunakan dengan cara yang positif atau negatif, yang pada gilirannya menentukan apakah pengujian dibantu atau dihalangi oleh fitur unik bahasa berorientasi obyek . Seperti dijelaskan dalam bagian 8-3, pengujian berorientasi obyek pendekatan terstruktur dasar dapat diadaptasi ke positif atau negatif situasi yang luar biasa. Metrik yang dirancang khusus untuk perangkat lunak berorientasi objek, seperti orang-orang [CHIDAMBER], dapat membantu menilai efektivitas yang paradigma berorientasi obyek digunakan. Jika metode kelas tidak kohesif dan ada kopling substansial antara objek, abstraksi dari bahasa pemrograman mungkin telah disalahgunakan dalam perangkat lunak. Hal ini pada gilirannya menunjukkan bahwa ekstra hati-hati harus diambil selama pengujian.


Berorientasi obyek modul pengujian

Metode berorientasi objek adalah serupa dalam banyak hal untuk fungsi biasa, pengujian sedemikian rupa (serta lain kriteria pengujian struktural) berlaku di tingkat modul tanpa modifikasi. Karena metode dalam bahasa berorientasi objek cenderung kurang kompleks daripada fungsi program prosedural tradisional, pengujian modul biasanya lebih mudah bagi-program berorientasi objek. Pewarisan dan polimorfisme fitur-bahasa berorientasi objek mungkin tampak rumit pengujian modul, karena aliran implisit kontrol yang terlibat dalam menyelesaikan doa metode dinamis. Sebagai contoh, jika sebuah referensi obyek dapat mengakibatkan salah satu dari beberapa alternatif metode yang dijalankan pada waktu berjalan, adalah mungkin untuk mewakili referensi sebagai keputusan multi-cara membangun ("kasus" pernyataan) pada grafik aliran yang berbeda metode resolusi mungkin untuk referensi obyek disebut dari masing-masing cabang. Karena ini representasi dari aliran kendali implisit akan meningkatkan kompleksitas siklomatik, juga akan meningkatkan jumlah tes yang dibutuhkan untuk melakukan pengujian terstruktur untuk modul yang berisi referensi. Gambar 8-2 menggambarkan aliran kendali implisit.


Meskipun kontrol aliran implisit memiliki implikasi signifikan untuk pengujian, ada alasan-alasan yang kuat untuk mengabaikan pada tingkat pengujian modul. Pertama, jumlah kemungkinan resolusi dari referensi objek tertentu tergantung pada hirarki kelas di mana referensi terjadi. Oleh karena itu, jika pengujian modul tergantung pada kontrol aliran implisit, hanya mungkin untuk melakukan pengujian modul dalam konteks hirarki kelas yang lengkap, suatu kebutuhan jelas tidak realistis. Selain itu, kompleksitas implisit melihat sebagai properti modul daripada sistem properti kekalahan salah satu motivasi utama untuk menggunakan bahasa berorientasi objek: untuk mengembangkan dengan mudah dapat digunakan kembali dan diperluas komponen. Untuk alasan ini, pertimbangan aliran kendali implisit ditangguhkan sampai tahap integrasi saat pengujian disusun untuk menerapkan program berorientasi objek.

Integrasi program pengujian berorientasi obyek

Aplikasi pengujian yang paling dasar terstruktur untuk integrasi program berorientasi objek pada dasarnya adalah aplikasi langsung dari teknik bagian 7. Hal ini sangat penting, namun, untuk mempertimbangkan doa metode implisit melalui referensi objek (tidak harus bingung dengan aliran kontrol implisit dinamis mengikat) ketika mengidentifikasi fungsi node panggilan untuk melakukan pengurangan desain. Metode doa ini mungkin tidak terlihat dari pemeriksaan kode sumber, sehingga alat otomatis sangat membantu. Sebagai contoh, jika variabel "a" dan "b" merupakan bilangan bulat, C + ekspresi + "a, b +" merupakan perhitungan sederhana. Namun, jika variabel tersebut adalah objek dari jenis kelas, ekspresi yang sama persis dapat panggilan ke metode kelas yang melalui mekanisme operator overloading C + +, yang membutuhkan pengujian integrasi dan karenanya harus dijaga oleh reduksi desain.
Sedangkan perlakuan metode implisit panggilan karena objek acuan yang jelas, situasi dengan kontrol aliran implisit lebih rumit. Dalam hal ini, beberapa pendekatan yang mungkin layak dipertimbangkan, tergantung pada sejauh mana abstraksi berorientasi obyek memiliki dampak positif atau negatif. Bagian ini menjelaskan tiga pendekatan: optimis, pesimis, dan seimbang. Masing-masing pendekatan teknik membangun pada bagian 7, membutuhkan bahwa setidaknya secara set tes melalui grafik desain-dikurangi setiap modul dilaksanakan dalam konteks integrasi, memperlakukan doa metode implisit karena objek referensi sebagai panggilan saat melakukan desain pengurangan . Pendekatan pesimistis dan seimbang juga membutuhkan tambahan tes berdasarkan aliran kendali implisit. Gambar 8-3 menunjukkan struktur dari bagian kecil dari sebuah program yang menggambarkan pendekatan masing-masing. Setiap modul "A", "B," dan "C" memanggil secara dinamis terikat "Draw" metode, yang dapat diselesaikan di waktu lari ke salah satu dari "Line:: Menggambar," "Polygon:: Draw," dan " Ellipse:: Draw. " Selama sisa bagian ini, metode yang dapat dijadikan sebagai hasil dari referensi obyek terikat secara dinamis akan disebut sebagai "resolusi."

Pendekatan optimis adalah pengujian pendekatan integrasi yang paling mudah. Dengan pendekatan ini, diharapkan bahwa abstraksi akan memiliki dampak positif, dan oleh karena itu pengujian akan terbatas pada level abstraksi dari kode sumber. Teknik-teknik pengujian integrasi dari bagian 7 berlaku secara langsung. Konsekuensi untuk aliran kontrol implisit adalah bahwa setiap situs panggilan latihan minimal satu resolusi, dan resolusi masing-masing dilaksanakan oleh setidaknya satu situs panggilan. Dengan asumsi bahwa tidak ada kesalahan yang ditemukan oleh orang-orang antarmuka pengujian, abstraksi berorientasi objek dipercaya untuk memperoleh keyakinan bahwa antarmuka lainnya juga benar. Gambar 8-4 menunjukkan serangkaian tes antarmuka yang cukup untuk memenuhi pendekatan optimis

Pesimistis Pendekatan lain adalah pendekatan langsung cukup. Dengan pendekatan ini, abstraksi diharapkan memiliki dampak yang negatif, dan karena itu diperlukan pengujian pada tingkat abstraksi dari mesin yang mendasari perhitungan kode sumber. Selain teknik-teknik integrasi pengujian bagian 7, aliran kontrol implisit diuji dengan mensyaratkan bahwa setiap resolusi diuji dari setiap situs panggilan. Dengan demikian, setiap antarmuka diuji secara langsung, dan tidak ada kepercayaan ditempatkan di abstraksi berorientasi objek. Kekurangannya adalah bahwa upaya pengujian dengan cepat dapat menjadi layak sebagai meningkatkan kerumitan.

Pendekatan yang seimbang adalah kompromi antara pendekatan optimis dan pesimis, dan lebih rumit daripada salah satu dari mereka. Idenya adalah untuk menguji pada tingkat abstraksi antara bahwa kode dan bahwa mekanik dasar. Abstraksi diharapkan untuk menyembunyikan beberapa detail yang memerlukan tes, tetapi juga untuk memberikan kerangka yang dapat dimanfaatkan untuk memfasilitasi pengujian. Selain teknik-teknik integrasi pengujian bagian 7, diperlukan bahwa beberapa situs panggilan latihan seluruh himpunan resolusi mungkin. Dampak dari persyaratan ini adalah untuk memberikan bukti bahwa himpunan resolusi mungkin dari suatu bentuk panggilan yang diberikan situs kelas "kesetaraan" dalam arti bahwa jika menjalankan salah satu resolusi dari situs panggilan baru bekerja dengan baik daripada melaksanakan resolusi kemungkinan lain juga kemungkinan untuk bekerja dengan baik. Properti ini diasumsikan dengan pendekatan optimis dan mendalam diuji dengan pendekatan pesimistis. Pendekatan yang seimbang menyediakan pengujian lebih menyeluruh dibandingkan dengan pendekatan optimis tanpa memerlukan sebanyak tes sebagai pendekatan pesimis, dan karena itu calon yang baik untuk digunakan dalam situasi khas. Juga, situs panggilan yang digunakan untuk menetapkan "kesetaraan kelas" bisa menjadi test driver dan bukan bagian dari aplikasi spesifik yang diuji, yang memberikan fleksibilitas ditambahkan.


Tertentu resolusi DNS dinamis untuk sering kepentingan. Sebagai contoh, sebagian besar penggunaan aplikasi gambar khas mungkin melibatkan poligon, atau fungsi poligon mungkin telah baru-baru ini dilaksanakan. Dalam hal ini, adalah tepat untuk mempertimbangkan pandangan sistem di mana semua bentuk diasumsikan poligon, misalnya menghubungkan semua "polimorfik Draw" panggilan langsung ke "Polygon:: Draw" dan menghapus alternatif seperti "Ellipse:: Draw "dari pertimbangan. Untuk seperti satu set resolusi, kompleksitas integrasi objek, OS1, didefinisikan sebagai kompleksitas integrasi (S1) dari sistem diselesaikan sesuai. Obyek kompleksitas integrasi sangat fleksibel, karena pengukuran didasarkan pada setiap set resolusi yang diinginkan. Mereka bisa ditentukan resolusi, baik untuk metode polimorfik spesifik, atau lebih umum untuk seluruh kelas.

Menghindari pengujian yang tidak perlu

Sistem berorientasi objek sering dibangun dari komponen yang stabil, seperti perpustakaan kelas komersial atau digunakan kembali kelas dari proyek yang sukses sebelumnya. Memang, menggunakan kembali komponen berbasis salah satu tujuan dasar pengembangan berorientasi obyek, sehingga teknik pengujian harus memungkinkan untuk itu. Stabil, perangkat lunak integritas tinggi dapat disebut sebagai "terpercaya." Konsep trustedness dapat mengajukan permohonan untuk modul individu, kelas, hierarki kelas, atau satu set resolusi potensi metode dinamis terikat, tetapi dalam setiap kasus, artinya adalah bahwa perangkat lunak dipercaya diasumsikan berfungsi dengan benar dan sesuai dengan berorientasi objek yang relevan abstraksi. Selain perangkat lunak komersial dan digunakan kembali dipercaya, software baru menjadi terpercaya setelah telah benar diuji. Dalam pengujian terstruktur, implementasi perangkat lunak terpercaya tidak diuji, meskipun integrasi dengan perangkat lunak lain yang diperlukan untuk diuji. Software Terpercaya diperlakukan sebagai komponen yang sudah terintegrasi dengan menggunakan teknik integrasi bagian tambahan 7-6.
Software terpercaya tidak harus diuji di tingkat modul sama sekali, dan panggilan internal ke komponen dipercaya tidak perlu diuji di tingkat integrasi. Penanganan modul terpercaya, kelas, dan kelas hierarki sangatlah mudah, dalam pengujian integrasi hanya perlu dilakukan, dan bahkan kemudian menerapkan teknik pengurangan berdasarkan desain hanya pada panggilan yang lintas batas dari trustedness. Untuk kasus yang terpercaya set resolusi potensi metode dinamis terikat, hanya satu resolusi perlu diuji dari setiap situs panggilan bahkan ketika menggunakan pendekatan pesimis untuk pengujian kode non-terpercaya. Ketika alat otomatis digunakan untuk menampilkan informasi trustedness, tes integrasi dapat dihentikan pada batas trustedness.