Apa itu SIT? Pengujian Integrasi Sistem dengan Contoh

Apa itu Pengujian Integrasi Sistem?

System Tes integrasi didefinisikan sebagai jenis pengujian perangkat lunak yang dilakukan dalam lingkungan perangkat keras dan perangkat lunak yang terintegrasi untuk memverifikasi perilaku sistem yang lengkap. Ini adalah pengujian yang dilakukan pada sistem yang lengkap dan terintegrasi untuk mengevaluasi kepatuhan sistem terhadap persyaratan yang ditentukan.

Pengujian Integrasi Sistem (System Integration Testing/SIT) dilakukan untuk memverifikasi interaksi antar modul dalam suatu sistem perangkat lunak. Pengujian ini berkaitan dengan verifikasi persyaratan perangkat lunak tingkat tinggi dan rendah yang ditentukan dalam Spesifikasi/Data Persyaratan Perangkat Lunak dan Dokumen Desain Perangkat Lunak.

SIT juga memverifikasi keberadaan sistem perangkat lunak secara bersamaan dengan sistem lain dan menguji antarmuka antar modul aplikasi perangkat lunak. Dalam jenis pengujian ini, modul-modul pertama kali diuji secara individual dan kemudian digabungkan untuk membentuk suatu sistem. Misalnya, komponen perangkat lunak dan/atau perangkat keras digabungkan dan diuji secara bertahap hingga seluruh sistem terintegrasi.

Diagram di atas menunjukkan tahapan yang mendefinisikan SIT: modul-modul yang diverifikasi secara terpisah digabungkan langkah demi langkah hingga tersisa satu sistem terintegrasi yang diuji.

Mengapa Pengujian Integrasi Sistem?

Dalam Rekayasa Perangkat Lunak, Pengujian Integrasi Sistem dilakukan karena,

• Ini membantu untuk mendeteksi Cacat awal
• Umpan balik sebelumnya mengenai penerimaan masing-masing modul akan tersedia
• Penjadwalan perbaikan Cacat bersifat fleksibel dan dapat tumpang tindih dengan pengembangan
• Aliran data yang benar
• Aliran kontrol yang benar
• Waktu yang tepat
• Penggunaan memori yang benar
• Benar dengan persyaratan perangkat lunak

Pengujian Integrasi Sistem vs Pengujian Sistem vs Pengujian Penerimaan Pengguna

Karena ketiga level ini berjalan berurutan, seringkali terjadi kebingungan di antara ketiganya. Pengujian Sistem memeriksa satu hasil pembangunan yang sudah jadi terhadap persyaratannya, SIT memeriksa celah antar pembangunan, dan Pengujian Penerimaan Pengguna Menganalisis kesesuaian bisnis dari sudut pandang pelanggan. Tabel di bawah ini memisahkan keduanya.

Parameter	Pengujian Integrasi Sistem	Pengujian Sistem	Pengujian Penerimaan Pengguna
Fokus utama	Antarmuka dan aliran data antar modul terintegrasi	Perilaku dari keseluruhan rakitan yang telah dibuat.	Kesesuaian bisnis untuk penggunaan nyata
Tingkat pengujian	Tingkat dua	Level tiga	Level terakhir sebelum peluncuran resmi
Teknik	Kotak hitam	Kotak hitam, kotak putih, atau kotak abu-abu	Kotak hitam
Dilakukan oleh	Penguji integrasi dan pengembang	Tim penguji independen	Pelanggan atau pengguna akhir
Cacat umum	Antarmuka, pengaturan waktu, memori, dan peta dataping kesalahan	Kesalahan sistem fungsional dan non-fungsional	Ketidaksesuaian antara kegunaan dan persyaratan
Berjalan saat	Setelah Pengujian Unit	Setelah SIT	Setelah Pengujian Sistem

Urutan itu penting. Modul lolos pengujian unit, SIT membuktikan antarmuka, Pengujian Sistem membuktikan produk yang dirakit, dan UAT mengkonfirmasi produk sesuai dengan harapan bisnis. Lewatiping SIT (System Integration Technician) mendorong cacat antarmuka ke UAT (User Acceptance Testing), di mana setiap perbaikan membutuhkan biaya yang jauh lebih besar.

Bagaimana melakukan Pengujian Integrasi Sistem

Ini adalah teknik sistematis untuk membangun struktur program sambil melakukan pengujian untuk mengungkap kesalahan yang terkait dengan antarmuka.

Semua modul diintegrasikan terlebih dahulu, dan seluruh program diuji secara keseluruhan. Namun selama proses ini, serangkaian kesalahan mungkin terjadi.

Koreksi kesalahan seperti itu sulit dilakukan karena penyebab isolasi dipersulit oleh perluasan keseluruhan program. Setelah kesalahan ini diperbaiki dan diperbaiki, kesalahan baru akan muncul, dan prosesnya berlanjut dengan mulus dalam putaran tanpa akhir. Untuk menghindari situasi ini, digunakan pendekatan lain, yaitu Integrasi Inkremental. Pendekatan inkremental dijelaskan secara rinci di bagian selanjutnya.

Ada beberapa metode tambahan seperti pengujian integrasi yang dilakukan pada sistem berdasarkan prosesor target. Metodologi yang digunakan adalah Black Box pengujian. Integrasi bottom-up atau top-down dapat digunakan.

Kasus uji ditentukan hanya dengan menggunakan persyaratan perangkat lunak tingkat tinggi.

Integrasi perangkat lunak juga dapat dicapai sebagian besar di lingkungan host, dengan unit-unit khusus untuk lingkungan target terus disimulasikan di host. Pengujian berulang di lingkungan target untuk konfirmasi akan diperlukan lagi.

Pengujian konfirmasi pada level ini akan mengidentifikasi masalah spesifik lingkungan, seperti kesalahan dalam alokasi dan de-alokasi memori. Kepraktisan melakukan integrasi perangkat lunak di lingkungan host akan bergantung pada seberapa banyak fungsionalitas spesifik target yang ada. Untuk beberapa sistem tertanam, keterkaitan dengan lingkungan target akan sangat kuat, sehingga tidak praktis untuk melakukan integrasi perangkat lunak di lingkungan host.

Pengembangan perangkat lunak berskala besar akan membagi integrasi perangkat lunak ke dalam beberapa tingkatan. Tingkat integrasi perangkat lunak yang lebih rendah dapat didasarkan terutama pada lingkungan host, sedangkan tingkat integrasi perangkat lunak selanjutnya akan lebih bergantung pada lingkungan target.

Catatan: Jika yang diuji hanya perangkat lunak maka disebut Software Software Integration Testing [SSIT] dan jika perangkat keras dan perangkat lunak yang diuji maka disebut Hardware Software Integration Testing [HSIT].

Pendekatan Tambahan

Karena mengintegrasikan semuanya sekaligus membuat cacat sulit diisolasi, sebagian besar tim mengikuti jalur bertahap seperti yang dijelaskan di sini.

Pengujian tambahan adalah cara pengujian integrasi. Dalam metode pengujian jenis ini, pertama-tama Anda menguji setiap modul perangkat lunak satu per satu dan kemudian melanjutkan pengujian dengan menambahkan modul lain ke dalamnya, lalu modul lainnya, dan seterusnya.

Integrasi bertahap merupakan kebalikan dari pendekatan big bang. Program ini dibangun dan diuji dalam segmen kecil, dimana kesalahan lebih mudah diisolasi dan diperbaiki. Antarmuka lebih mungkin untuk diuji sepenuhnya, dan pendekatan pengujian sistematis dapat diterapkan.

Ada dua jenis pengujian tambahan

• Pendekatan atas ke bawah
• Pendekatan dari bawah ke atas

Pendekatan atas ke bawah

Dalam jenis pendekatan ini, individu memulai dengan hanya menguji antarmuka pengguna, dengan fungsionalitas dasar yang disimulasikan oleh stub, lalu Anda bergerak ke bawah dengan mengintegrasikan lapisan bawah dan bawah seperti yang ditunjukkan pada gambar di bawah.

• Dimulai dengan modul kontrol utama, modul diintegrasikan dengan bergerak ke bawah melalui hierarki kontrol
• Sub-modul ke modul kontrol utama dimasukkan ke dalam struktur baik dengan cara yang mengutamakan luas atau yang mengutamakan kedalaman.
• Integrasi mendalam mengintegrasikan semua modul pada jalur kontrol utama struktur seperti yang ditampilkan dalam diagram berikut:

Proses integrasi modul dilakukan dengan cara berikut:

1. Modul kontrol utama digunakan sebagai test driver, dan stub menggantikan semua modul yang secara langsung berada di bawah modul kontrol utama.
2. Rintisan bertopik bawahan diganti satu per satu dengan modul sebenarnya tergantung pada pendekatan yang dipilih (keluasan terlebih dahulu atau kedalaman terlebih dahulu).
3. Pengujian dijalankan saat setiap modul terintegrasi.
4. Setelah menyelesaikan setiap rangkaian pengujian, stub lain diganti dengan modul nyata pada saat penyelesaian setiap rangkaian pengujian
5. Untuk memastikan bahwa kesalahan baru belum terjadi Pengujian Regresi dapat dilakukan.

Proses berlanjut dari langkah 2 hingga seluruh struktur program dibangun. Strategi top-down kedengarannya relatif tidak rumit, namun dalam praktiknya, timbul masalah logistik.

Masalah yang paling umum terjadi ketika pemrosesan pada tingkat rendah dalam hierarki diperlukan untuk menguji tingkat atas secara memadai.

Stub menggantikan modul tingkat rendah pada awal pengujian top-down dan, oleh karena itu, tidak ada data signifikan yang dapat mengalir ke atas dalam struktur program.

Tantangan yang mungkin dihadapi Penguji:

• Tunda banyak pengujian hingga stub diganti dengan modul sebenarnya.
• Kembangkan stub yang menjalankan fungsi terbatas yang mensimulasikan modul sebenarnya.
• Integrasikan perangkat lunak dari hierarki paling bawah ke atas.

Catatan: Pendekatan pertama menyebabkan kita kehilangan kendali atas korespondensi antara pengujian tertentu dan penggabungan modul tertentu. Hal ini dapat mengakibatkan kesulitan dalam menentukan penyebab kesalahan yang cenderung melanggar sifat pendekatan top-down yang sangat terbatas.

Pendekatan kedua bisa berhasil tetapi dapat menyebabkan overhead yang signifikan, karena rintisan menjadi semakin rumit.

Pendekatan Bottom-up

Integrasi bottom-up memulai konstruksi dan pengujian dengan modul di tingkat terendah dalam struktur program. Dalam proses ini, modul-modul diintegrasikan dari bawah ke atas.

Dalam pendekatan ini, pemrosesan yang diperlukan untuk modul-modul yang berada di bawah tingkat tertentu selalu tersedia dan kebutuhan akan stub dihilangkan.

Proses uji integrasi ini dilakukan dalam serangkaian empat langkah

1. Modul tingkat rendah digabungkan menjadi kluster yang menjalankan subfungsi perangkat lunak tertentu.
2. Sebuah driver ditulis untuk mengoordinasikan input dan output kasus uji.
3. Cluster atau build sedang diuji.
4. Driver dihilangkan, dan kluster digabungkan dengan bergerak ke atas dalam struktur program.

Seiring integrasi bergerak ke atas, kebutuhan akan pengemudi uji terpisah menjadi berkurang. Bahkan, jika dua tingkat teratas struktur program diintegrasikan dari atas ke bawah, jumlah pengemudi dapat dikurangi secara substansial, dan integrasi klaster menjadi jauh lebih sederhana. Integrasi mengikuti pola yang diilustrasikan di bawah ini.

Catatan: Jika dua tingkat teratas dari struktur program diintegrasikan secara Top-down, jumlah driver dapat dikurangi secara signifikan, dan integrasi build menjadi sangat disederhanakan.

Pendekatan Big Bang

Dalam pendekatan ini, semua modul tidak terintegrasi sampai semua modul siap. Setelah siap, semua modul diintegrasikan dan kemudian dieksekusi untuk mengetahui apakah semua modul yang terintegrasi berfungsi atau tidak.

Dalam pendekatan ini, sulit mengetahui akar penyebab kegagalan karena mengintegrasikan semuanya sekaligus.

Selain itu, kemungkinan besar terjadinya bug kritis di lingkungan produksi.

Pendekatan ini diadopsi hanya ketika pengujian integrasi harus dilakukan sekaligus.

Pengujian Integrasi Perangkat Lunak Perangkat Keras

Pengujian Integrasi Perangkat Lunak Perangkat Keras adalah proses pengujian Komponen Perangkat Lunak Komputer (CSC) untuk fungsionalitas tingkat tinggi pada lingkungan perangkat keras target. Tujuan pengujian integrasi perangkat keras/perangkat lunak adalah untuk menguji perilaku perangkat lunak yang dikembangkan terintegrasi pada komponen perangkat keras.

Pengujian Integrasi Perangkat Keras-Perangkat Lunak berdasarkan kebutuhan

Tujuan dari pengujian integrasi perangkat keras/perangkat lunak berbasis persyaratan adalah untuk memastikan bahwa perangkat lunak di komputer target akan memenuhi persyaratan tingkat tinggi. Kesalahan umum yang diungkapkan oleh metode pengujian ini meliputi:

• Kesalahan antarmuka perangkat keras/perangkat lunak
• Pelanggaran partisi perangkat lunak.
• Ketidakmampuan untuk mendeteksi kegagalan dengan pengujian bawaan
• Respons yang salah terhadap kegagalan perangkat keras
• Kesalahan karena pengurutan, beban masukan transien, dan transien daya masukan
• Umpan balik mengulang perilaku yang salah
• Kontrol perangkat keras manajemen memori yang salah atau tidak tepat
• Masalah pertikaian bus data
• Pengoperasian mekanisme yang salah untuk memverifikasi kompatibilitas dan kebenaran perangkat lunak yang dapat dimuat di lapangan

Integrasi Perangkat Lunak Perangkat Keras berkaitan dengan verifikasi persyaratan tingkat tinggi. Semua pengujian pada level ini dilakukan pada perangkat keras target.

• Pengujian kotak hitam adalah metodologi pengujian utama yang digunakan pada tingkat pengujian ini.
• Menetapkan kasus uji hanya dari persyaratan tingkat tinggi saja
• Pengujian harus dijalankan pada perangkat keras standar produksi (sesuai target)

Hal-hal yang perlu dipertimbangkan ketika merancang kasus uji untuk Integrasi HW/SW

• Akuisisi yang benar atas semua data oleh perangkat lunak
• Penskalaan dan jangkauan data seperti yang diharapkan dari perangkat keras hingga perangkat lunak
• Output data yang benar dari perangkat lunak ke perangkat keras
• Data dalam spesifikasi (kisaran normal)
• Data di luar spesifikasi (rentang tidak normal)
• Data batas
• Mengganggu pemrosesan
• Pemilihan waktu
• Penggunaan memori yang benar (pengalamatan, tumpang tindih, dll.)
• Transisi keadaan

Catatan: Untuk pengujian interupsi, semua interupsi akan diverifikasi secara independen mulai dari permintaan awal hingga layanan penuh hingga penyelesaian. Kasus uji akan dirancang khusus untuk menguji interupsi secara memadai.

Pengujian Integrasi Perangkat Lunak ke Perangkat Lunak

Ini adalah pengujian Komponen Perangkat Lunak Komputer yang beroperasi di dalam lingkungan komputer host/target, sambil mensimulasikan seluruh sistem [CSC lainnya], dan pada fungsionalitas tingkat tinggi.

Fokusnya adalah pada perilaku CSC dalam lingkungan host/target yang disimulasikan. Pendekatan yang digunakan untuk Integrasi Perangkat Lunak dapat berupa pendekatan inkremental (pendekatan top-down, bottom-up, atau kombinasi keduanya, yang juga disebut pendekatan sandwich atau hibrida).

Kriteria Masuk dan Keluar untuk Pengujian Integrasi

Setelah pendekatan dan dua varian integrasi disepakati, pertanyaan yang tersisa adalah kapan tim dapat memulai dan kapan dapat berhenti. Biasanya, saat melakukan Pengujian Integrasi, strategi ETVX (Kriteria Masuk, Tugas, Validasi, dan Kriteria Keluar) digunakan.

Kriteria Masuk:

• Penyelesaian dari Pengujian Unit

Input:

• Data Persyaratan Perangkat Lunak
• Dokumen Desain Perangkat Lunak
• Paket Verifikasi Perangkat Lunak
• Dokumen Integrasi Perangkat Lunak

Kegiatan:

• Berdasarkan persyaratan tingkat Tinggi dan Rendah, buat kasus uji dan prosedur
• Gabungkan build modul tingkat rendah yang mengimplementasikan fungsi umum
• Kembangkan alat uji
• Uji buildnya
• Setelah pengujian lulus, build tersebut digabungkan dengan build lain dan diuji hingga sistem terintegrasi secara keseluruhan.
• Jalankan kembali semua pengujian pada platform berbasis prosesor target, dan dapatkan hasilnya

Kriteria Keluar:

• Berhasil menyelesaikan integrasi modul Perangkat Lunak pada Perangkat Keras target
• Kinerja perangkat lunak yang benar sesuai dengan persyaratan yang ditentukan

Output

• Laporan pengujian integrasi
• Kasus dan Prosedur Uji Perangkat Lunak [SVCP].

Tantangan Umum dalam Pengujian Integrasi Sistem

Bahkan dengan pendekatan yang tepat dan kriteria keluar yang jelas, lingkungan terintegrasi dapat menimbulkan masalah yang tidak pernah muncul selama pengujian unit. Mengenali masalah tersebut sejak dini akan menjaga jadwal tetap realistis.

• Ketidaksesuaian lingkungan: yang terintegrasi lingkungan pengujian jarang mencerminkan proses produksi, sehingga kesalahan waktu dan konfigurasi baru terdeteksi pada tahap yang sangat terlambat.
• Kesiapan ketergantungan: Antarmuka pihak ketiga dan antarmuka lama seringkali belum selesai, memaksa penguji untuk mengandalkan stub dan simulator jauh lebih lama dari yang direncanakan.
• Ketidakkonsistenan data: Dua modul dapat merepresentasikan data yang sama secara berbeda, menghasilkan ketidaksesuaian yang tidak terdeteksi alih-alih kegagalan yang terlihat.
• Kepemilikan cacat: ketika suatu kegagalan melibatkan dua tim, analisis akar penyebab dan manajemen cacat melambat secara signifikan.
• Biaya regresi: setiap antarmuka baru memperbesar pengujian regresi suite, sehingga eksekusi ulang manual dengan cepat menjadi tidak berkelanjutan.

Sebagian besar risiko ini lebih berkaitan dengan jadwal daripada jalan buntu teknis. Menyetujui tanggal kesiapan antarmuka, ruang lingkup simulator, dan kepemilikan triase cacat sebelum build pertama diintegrasikan akan menghilangkan sebagian besar risiko tersebut. Untuk antarmuka yang dimiliki vendor, catat juga format pesan yang disepakati dan kontak eskalasi, karena pemilik yang hilang akan menunda perbaikan lebih lama daripada yang seharusnya.

Praktik Terbaik untuk Pengujian Integrasi Sistem

Siklus SIT yang dapat diulang lebih bergantung pada disiplin seputar antarmuka, data, dan bukti daripada pada perangkat lunak. Lima praktik di bawah ini cocok untuk pengembangan sistem tertanam skala kecil maupun lanskap multi-vendor yang besar, dan masing-masing mengurangi pengerjaan ulang hingga mencapai tingkat pengujian selanjutnya.

1. Petakan setiap antarmuka terlebih dahulu. Cantumkan setiap pertukaran data, arahnya, protokolnya, dan pemiliknya sebelum menulis satu pun kasus uji.
2. Prioritaskan berdasarkan risiko. Verifikasi antarmuka yang membawa uang, identitas, atau data yang diatur sebelum antarmuka yang bersifat kosmetik.
3. Rancang data uji yang realistis. Mencakup rentang normal, batas, dan abnormal sehingga kesalahan penskalaan dan pembulatan muncul lebih awal.
4. Otomatiskan jalur yang stabil. Antarmuka kabel memeriksa ke dalam integrasi berkelanjutan pipeline sehingga setiap build memverifikasinya kembali.
5. Simpan bukti tracmampu. Hubungkan setiap hasil dengan persyaratan melalui sebuah tracmatriks kelayakan sehingga kriteria keluar dapat dibuktikan, bukan hanya sekadar pernyataan.

⚠ Tip: Tetapkan spesifikasi antarmuka sebelum integrasi dimulai. Perubahan format pesan di menit-menit terakhir akan membatalkan kasus uji di kedua sisi antarmuka dan merupakan penyebab paling umum dari pengerjaan ulang SIT (System Integration Team).

Pertanyaan Umum Demo Slot