Definisi
Uji integrasi,
- menurut wikipedia, adalah aktivitas pengujian software dalam
mana modul-modul software dikombinasikan dan diuji sebagai satu kesatuan.
- menurut Roger S. Pressman adalah teknik sistematis untuk
membangun arsitektur software sambil pada saat yang sama menjalankan
pengujian untuk menemukan error terkait dengan interfacing, komunikasi
antar modul. Uji integrasi setelah uji unit sebelum uji sistem.
Tujuan Uji Integrasi
pemeriksaan fungsional, kinerja dan kehandalan
dari struktur program yang telah dirancang. Kelompok-kelompok modul, data
bersama, komunikasi antar proses diperiksa melalui antarmukanya
menggunakan uji black box. Sukses atau gagal disimulasikan melalui uji
parameter dan masukan data. Kasus-kasus pengujian dibangun untuk menguji
interaksi di antara seluruh komponen dalam kumpulan modul, melalui
pemanggilan prosedur atau aktivasi proses.
Pendekatan Big bang
Ada kecenderungan orang untuk melakukan uji integrasi ini dengan cara tidak
bertahap, pendekatan “big bang”. Seluruh komponen dikombinasikan
bertahap. Keseluruhan program diuji sebagai satu kesatuan. Dan biasanya
dihasilkan chaos. Sekumpulan error ditemukan. Koreksi sulit dilakukan karena
sulitnya mengisolasi penyebab kesalahan. Satu kesalahan dapat diatasi,
kesalahan yang lain muncul dan proses berlanjut seolah tanpa henti.
Salah satu tipe pendekatan “big bang” adalah pengujian model penggunaan,
usage model testing. Pengujian dilakukan dengan mengambil kasus-kasus beban
kerja mirip pengguna dalam lingkungan kerja akhir yang terintegrasi.
Lingkungan diuji, komponen individu diuji secara tidak langsung melalui Uji Integrasi
penggunaan mereka. Beban kerja mirip pengguna perlu didefinisikan dengan
hati-hati untuk membuat skenario yang realistis dalam memeriksa lingkungan.
Pendekatan Incremental
Berlawanan dengan pendekatan “big bang”, program dibangun dan diuji
bertahap sedikit demi sedikit. Kesalahan akan mudah diisolasi dan diperbaiki,
antarmuka dapat diuji lengkap, dan pendekatan pengujian sistematis dapat
diterapkan. Pengujian dilakukan mungkin secara top down, bottom up,
regression testing atau smoke testing.
Dalam metode ini, modul-modul diintegrasikan dengan perjalanan turun
melalui hirarki kendali, mulai dari modul utama kemudian ke modul-modul
subordinat. Modul-modul subordinat dapat digabungkan ke dalam struktur
program dengan pola depth-first atau breadth-first.
- Pola depth-first, modul diintegrasikan satu demi satu melalui struktur
kendali utama program.
2. pola breadth-first, seluruh komponen subordinat langsung di setiap
level, menelusuri struktur secara horisontal.
Integrasi Bottom up
Dalam metode ini komponen level paling bawah diuji pertama kali. Pengujian
ini tidak memerlukan modul stub. Proses diulang sampai komponen puncak
hirarki diuji. Pendekatan ini sangat membantu ketika seluruh atau kebanyakan
modul dari level pengeembangan yang sama sudah siap. Metode ini juga
membantu menentukan level pengembangan software yang memudahkan
pelaporan kemajuan pembuatan software dalam bentuk persentase.
Tahap-tahap untuk melakukan integrasi bottom up adalah sebagai berikut:
1. Komponen-komponen level bawah dikombinasikan ke dalam cluster
yang menjalankan subfungsi software khusus,
2. Driver ditulis untuk mengkoordinasikan kasus pengujian masukan dan
keluaran,
3. Cluster diuji,
4. Driver dihapus dan cluster dikombinasikan ke atas menelusuri
struktur program.
Contoh lihat Gambar 7.3.
Oleh karena integrasi dilakukan dalam arah ke atas, kebutuhan test driver yang
berbeda muncul. Dalam praktek, jika dua level puncak struktur program
diintegrasikan top down, jumlah driver dapat dikurangi, integrasi cluster dapat
disederhanakan. Menggabungkan pengujian bottom up dengan top down ini
sebagian orang menyebutnya pengujian sandwich.
Pengujian Regressi
Pengujian regressi adalah menjalankan kembali beberapa subset pengujian yang
telah dilakukan untuk meyakinkan bahwa perubahan tidak punya efek samping
yang tidak diharapkan. Perlu dilakukan mengingat setiap kali modul baru
diintegrasikan, software berubah. Ada aliran data yang baru, atau I/O baru,
atau logika kendali yang baru. Perubahan ini boleh jadi punya efek samping
yang tidak diharapkan. Kesalahan harus diperbaiki. Ketika dikoreksi, data atau program atau
dokumentasi berubah. Dengan pengujian regressi diharapkan perubahan ini
tidak menimbulkan kesalahan lain.
Menguji kembali setiap modul pada setiap kali modul baru ditambahkan adalah
tidak praktis dan tidak efisien. Seiring berlangsungnya uji integrasi, jumlah uji
regresi dapat meningkat dalam jumlah besar. Sekumpulan uji yang perlu
diulang perlu dirancang untuk menyertakan hanya modul berikut :
• sampel uji representatif yang memeriksa seluruh fungsi software.
• uji tambahan yang fokus pada fungsi-fungsi software yang
kemungkinan besar dipengaruhi perubahan.
• pengujian yang fokus pada komponen-komponen software yang telah
berubah.
Modul kritis, critical module, adalah modul yang memiliki karakterisitik:
• memenuhi beberapa kebutuhan software
• memiliki level kendali yang tinggi
• kompleks atau mudah salah
• memiliki kebutuhan kinerja yang definitif
Modul kritis sebaiknya diuji seawal mungkin. Uji regresi sebaiknya fokus pada
fungsi modul kritis.
Pengujian regresi dapat dijalankan secara manual atau menggunakan tool
capture/playback otomatis. Tool ini memungkinkan capture kasus-kasus
pengujian dan urutan hasil-hasil playback sebagai bahan perbandingan.
