Integration Testing

Integration testing adalah suatu teknik yang sistematis untuk pembangunan struktur program, dimana pada saat yang bersamaan melakukan testing untuk mendapatkan errors yang diasosiasikan dengan antar-muka.

Obyektifitasnya adalah untuk menindaklanjuti komponen-komponen yang telah melalui unit testing dan membangun suatu struktur program sesuai dengan disain yang telah dituliskan sebelumnya. Terdapat kecenderungan untuk melakukan integrasi yang tidak secara bertahap, yaitu dengan menggunakan suatu pendekatan “Big Bang”.

Pendekatan ini menggabungkan komponen komponen secara bersamaan hingga terbentuk suatu program. Testing dilakukan pada keseluruhan program secara bersamaan. Kekacauan cenderung terjadi, karena:

-          Sekumpulan errors akan diperoleh, dan perbaikan sulit dilakukan, karena terjadi komplikasi saat melakukan isolasi terhadap penyebab masalah.

-          Ditambah lagi dengan munculnya errors baru saat errors sebelumnya dibenahi, sehingga menciptakan suatu siklus yang tak ada hentinya.

-          Integrasi yang dilakukan secara bertahap merupakan lawan dari penggunaan strategi “Big Bang”.

-          Program dikonstruksi dan dites secara bertahap, meningkat sedikit demi sedikit, dimana bila terjadi errors dapat dengan mudah untuk diisolasi dan diperbaiki, antarmuka dapat dites secara komplit atau paling tidak mendekati komplit, serta pendekatan tes yang sistematis dapat digunakan.

1.      Top-Down Integration

Adalah pendekatan bertahap untuk menyusun struktur program. Modul-modul diintegrasikan dari atas ke bawah dalam suatu hirarki kendali, dimulai dari modul kendali utama (program utama).

Modul sub-ordinat dari modul kendali utama dihubungkan ke struktur yang paling dalam (depth-first integration) atau yang paling luas (breadth-first integration) dahulu.

Depth-first integration, akan mengintegrasikan semua komponenkomponen pada struktur jalur kendali mayor. Misal dipilih sisi kiri terlebih dahulu, maka komponen M1, M2, M5 akan diintegrasikan dahulu, baru kemudian M8 atau M6 akan diintegrasikan.

Breadth-first integration, akan mengintegrasikan semua komponen secara langsung ke tiap tingkat, bergerak secara horisontal. Contoh komponen M2, M3 dan M4 akan diintegrasikan dahulu, kemudian baru M5 dan M6 dan seterusnya.

Lima langkah proses integrasi:

-          Modul kendali utama digunakan sebagai driver tes dan stubs tes disubtitusikan bagi semua komponen yang secara langsung menjadi sub-ordinat modul kendali utama.

-          Tergantung pada pendekatan integrasi yang dipilih, stubs sub-ordinat digantikan dengan komponen sebenarnya.

-          Tes dilakukan saat tiap komponen diintegrasikan.

-          Saat pemenuhan tiap tes, stubs lainnya digantikan dengan komponen sebenarnya.

-          Testing regresi dilakukan untuk memastikan kesalahan baru tidak terjadi lagi.

Proses berlanjut dari langkah 2 sampai keseluruhan struktur program dilalui.

Strategi top-down integration melakukan verifikasi kendali mayor atau titik-titik keputusan di awal proses testing. Pada suatu struktur program yang difaktorkan dengan baik, pengambilan keputusan terjadi di tingkat atas dalam hirarki dan oleh sebab itu diperhitungkan terlebih dahulu. Jika kendali mayor bermasalah, dibutuhkan pengenalan awal. Jika depth-first integration dipilih, suatu fungsi komplit dari software akan diimplementasikan dan didemonstrasikan.

Pendekatan ini terlihat tidak komplek, namun pada kenyataannya, masalah logistik akan timbul, karena proses level bawah dari hirarki dibutuhkan untuk tes level di atasnya. Stubs menggantikan modul level bawah saat dimulainya top-down testing; karenanya tidak ada data yang mengalir ke atas dari struktur program.

Tester hanya mempunyai 3 pilihan:

-          Tunda kebanyakan tes sampai stubs digantikan dengan modul sebenarnya, hal ini menyebabkan hilangnya beberapa kendali yang berhubungan antar tes tertentu dan modul tertentu. Tentunya akan menyulitkan untuk menentukan penyebab errors dan kecenderungan terjadi pelanggaran terhadap batasan-batasan dari pendekatan topdown.

-          Kembangkan stubs yang mempunyai fungsi terbatas untuk mensimulasikan modul sebenarnya, mungkin dapat dilakukan, namun akan menambah biaya overhead dengan semakin kompleknya stubs.

-          Integrasikan software dari bawah ke atas dalam hirarki, disebut sebagai bottom-up integration.

2.      Bottom-Up Testing

Sesuai namanya, integrasi ini dimulai dari modul terkecil. Karena komponen-komponen diintegrasikan dari bawah ke atas, sub-ordinat untuk tingkat bersangkutan dari komponen selalu diperlukan untuk diproses, dan kebutuhan terhadap stubs dapat dihilangkan.

Langkah-langkah strategi ini adalah:

-          Komponen level bawah dikombinasikan dalam clusters (kadang disebut builds) yang mewakili sub-fungsi software tertentu.

-          Driver ditulis untuk koordinasi masukan dan keluaran test case.

-          Cluster dites.

-          Driver dihapus dan cluster dikombinasikan, bergerak ke atas di dalam struktur program.

Integrasi mengikuti pola sebagaimana diilustrasikan pada gambar 4.5. Komponen dikombinasi untuk membentuk cluster 1, 2 dan 3.

Tiap cluster dites dengan menggunakan driver. Komponen pada cluster 1 dan 2 adalah sub ordinat Ma. Driver D1 dan D2 dihilangkan dan cluster dihubungkan langsung ke Ma, demikian seterusnya.

Saat integrasi semakin bergerak ke atas, kebutuhan akan test drivers yang terpisah juga akan semakin sedikit. Pada kenyataannya, jika dua level atas dari struktur program diintegrasikan dari atas ke bawah, jumlah drivers akan banyak dikurangi, dan integrasi dari clusters akan sangat disederhanakan.

3.      Regression Testing

Bilamana suatu hasil tes (jenis apapun) berhasil dalam menemukan errors, dan errors harus dikoreksi. Saat software dikoreksi, beberapa aspek dari konfigurasi software (program, dokumentasi, atau data pendukung) diubah.

Regression testing adalah aktivitas yang membantu untuk memastikan bahwa perubahan-perubahan yang terjadi tealah benar dan tidak menimbulkan tingkah laku yang tidak diinginkan atau penambahan errors.

Regression testing dapat dilakukan secara manual, dengan mengeksekusi kembali suatu subset dari keseluruhan test cases atau menggunakan alat bantu otomasi capture / playback.

Alat bantu capture / playback memungkinkan teknisi software untuk merekam test cases dan hasil-hasilnya untuk keperluan dipakai kembali dan dibandingkan pada sub sekuen tertentu atau keseluruhan.

Sub set tes yang dieksekusi terdiri dari 3 kelas test case yang berbeda:

-          Representasi dari contoh tes yang akan memeriksa semua fungsi software.

-          Tes tambahan yang berfokus pada fungsi software yang mungkin dipengaruhi oleh perubahan.

-          Tes yang berfokus pada komponen software yang diubah.

Saat tes integrasi dilakukan, jumlah tes regresi akan meningkat menjadi cukup besar.

Oleh karena itu, tes regresi seharusnya didisain untuk mencakup hanya pada tes-tes yang sama atau beberapa kelas errors di dalam setiap fungsifungsi mayor program. Adalah tidak praktis dan tidak efisien untuk mengeksekusi kembali setiap tes untuk setiap fungsi program saat suatu perubahan terjadi.