Integrasi Top-Down

Pengujian integrasi top-down

1.      Validasi arsitektural. Pengujian Top-Down lebih mungkin menemukan eror pada arsitektur sistem dan perancangan tingkat tinggi pada tahap awal proses pengembangan. Karena eror ini biasanya merupakan eror strukural, deteksi awal berarti eror tersebut dapat diperbaiki tanpa biaya tidak layak.

2.      Demonstrasi sistem. Dengan pengembangan Top-Down, sistem yang dapat dipakai dan terbatas tersedia pada tahap awal pengembangan. Ini merupakan dorongan psikologi yang penting bagi yang terlibat dalam pengembangan sistem. Validasi sistem dapat dimulai secara dini pada proses pengujian karena sistem yang dapat didemonstrasikan dapat disediakan bagi user.

3.      Implementasi uji. Pengujian Top-Down yang ketat sulit diimplementasi karena stub program ini mungkin berupa versi sederhana komponen yang dibutuhkan atau dapat meminta penguji untuk memasukkan nilai yang sesuai atau untuk mensimulasi kerja komponen.

4.      Pengamatan uji. Baik baik pengujian bottom-up maupun top-down dapat memiliki masalah dengan pengamatan uji. Pada banyak sistem, tingkat-tingkat sistem yang lebih tinggi yang diimplementasikan pada awal proses top-down tidak menghasilkan hasil uji.

Sesungguhnya sistem biasanya dikembangkan dan diuji dengan menggunakan campuran pendekatan Top-Down dan button-up, jadwal pengembangan yang berbeda untuk bagian sistem yang berbeda berarti bahwa tim integrasi dan pengujian harus bekerja dengan komponen apapun yang tersedia. Dengan demikian, campuran stub dan test driver pada akhirnya harus dikembangkan pada saat proses pengujian integrasi.
Pengujian Top-down merupakan pendekatan incremental untuk penyusunan struktur program. Modul program dipadukan dengan bergerak ke bawah melalui control hierarkinya dimulai dengan modul utama.
Modul subordinat ke modul control utama digabungkan ke dalam struktur baik menurut dept first atau breadth first. Pada gambar berikut memadukan depth first interface yang memadukan seluruh modul pada control path yang utama pada struktur.

Pilihan path (jalur) utama dapat secara acak dan tergantung spesifikasi aplikasi.
Pada contoh dipilih path sebelah kanan yaitu modul M1, M2, M5 yang akan dipadukan pertama. Berikutnya M8 (jika diperlukan M2 juga dapat) atau M6 yang akan dipadukan. Selanjutnya path pusat dan sebelah kiri dikerjakan. Breadth first integration akan memadukan seluruh modul yang sejajar. Dari contoh diatas modul M3, M4 (yang digantikan dengan S4) yang akan dipadukan, berikutnya M1, M5, M6, dan seterusnya,
1. Modul utama digunakan sebagai test driver dan stub yang menggantikan seluruh modul yang secara langsung berada di bawah control modul.
2. Tergantung kepada perpaduan yang dipilih (dept atau breadth) subordinat stub diganti atau dipindahkan dengan modul yang sebenarnya.
3. Uji coba dilakukan selama masing-masing modul dipadukan.
4. Pada penyelesaian masing-masing uji coba stub yang lain dipindahkan dengan modul sebenarnya.
5. Uji coba regression yaitu pengulangan uji coba untuk mencari kesalahan-kesalahan lain yang mungkin timbul.

Proses yang dimulai dari langkah nomor 2 akan berulang hingga seluruh struktur program selesai dibuat. Diaumsikan pendekatan depth first yang dipergunakan dan sebagian melengkapi struktur s7 yang berikut akan digantikan dengan modul yang berhubungan m7. M7 sendiri menpunyai stub yang akan digantikan dengan modul yang berhubungan. Yang paling penting setiap terjadi pergantian, uji coba harus dikerjakan untuk menperifikasi interface. Strategi top down intergration akan menverifikasi control utama dan keputusan pada saat proses uji coba. Pada struktur program yang dibuat dengan baik keputusan akan dikerjakan pada tingkat atas hierarki. Jika pendekatan dept first integration dipilih fungsi-fungsi yang melengkapi perangkat lunak harus dilengkapi dan dipertunjukkan. Fungsi stub adalah untuk menggantukan modul pada tingkat yang paling bawah yang diujicobakan.