Pengujian Integrasi: Apa itu, Jenis, Contoh Top Down & Bottom Up

Pengujian Integrasi: Apa itu, Jenis, Contoh Top Down & Bottom Up

Apa itu Pengujian Integrasi?

PENGUJIAN INTEGRASI didefinisikan sebagai jenis pengujian di mana modul perangkat lunak diintegrasikan secara logis dan diuji sebagai kelompok. Proyek perangkat lunak tipikal terdiri dari beberapa modul perangkat lunak, yang dikodekan oleh pemrogram yang berbeda. Tujuan dari tingkat pengujian ini adalah untuk mengekspos kerusakan dalam interaksi antara modul-modul perangkat lunak ini ketika mereka terintegrasi

 Pengujian Integrasi berfokus pada memeriksa komunikasi data di antara modul-modul ini. Oleh karena itu juga disebut sebagai  ‘I & T’  (Integration and Testing),  ‘String Testing‘ dan kadang-kadang ‘Thread Testing‘ .

Mengapa Pengujian Integrasi?

Meskipun setiap modul perangkat lunak diuji unit, cacat tetap ada karena berbagai alasan seperti

• Modul, secara umum, dirancang oleh pengembang perangkat lunak individual yang pemahaman dan logika pemrogramannya mungkin berbeda dari programmer lain. Pengujian Integrasi menjadi perlu untuk memverifikasi modul perangkat lunak bekerja dalam kesatuan
• Pada saat pengembangan modul, ada kemungkinan besar perubahan dalam persyaratan oleh klien. Persyaratan baru ini mungkin tidak diuji unit dan karenanya Pengujian integrasi sistem menjadi perlu.
• Antarmuka modul perangkat lunak dengan database bisa keliru
• Antarmuka perangkat keras eksternal, jika ada, bisa keliru
• Penanganan pengecualian yang tidak memadai dapat menyebabkan masalah.

Contoh Kasus Uji Integrasi

Integration Test Case berbeda dari test case lain dalam arti berfokus terutama pada antarmuka & aliran data / informasi antar modul . Di sini prioritas diberikan untuk tautan pengintegrasian daripada fungsi unit yang sudah diuji.

Contoh Kasus Uji Integrasi untuk skenario berikut: Aplikasi memiliki 3 modul yaitu ‘Halaman Masuk’, ‘Kotak Surat’ dan ‘Hapus email’ dan masing-masing terintegrasi secara logis.

Di sini tidak banyak berkonsentrasi pada pengujian Halaman Login karena sudah dilakukan di Unit Testing . Tetapi periksa bagaimana tautannya ke Halaman Kotak Surat.

Demikian pula Kotak Surat: Periksa integrasinya ke Modul Hapus Surat.

ID Kasus Uji	Tujuan Uji Kasus	Deskripsi Test Case	Hasil yang diharapkan
1	Periksa tautan antarmuka antara modul Login dan Kotak Surat	Masukkan kredensial masuk dan klik tombol Login	Untuk diarahkan ke Kotak Surat
2	Periksa tautan antarmuka antara Kotak Surat dan Hapus Modul Surat	Dari Kotak Surat pilih email dan klik tombol hapus	Email yang dipilih akan muncul di folder Dihapus / Sampah

Pendekatan, Strategi, Metodologi Pengujian Integrasi

Rekayasa Perangkat Lunak mendefinisikan berbagai strategi untuk melaksanakan pengujian Integrasi, yaitu.

•  Pendekatan Big Bang:
•  Pendekatan Tambahan: yang selanjutnya dibagi menjadi sebagai berikut:
  •  Pendekatan atas ke bawah (Top Down)
  •  Pendekatan dari Bawah ke Atas (Bottom Up)
  •  Sandwich Approach – Kombinasi Top Down dan Bottom Up

Di bawah ini adalah strategi yang berbeda, cara mereka dieksekusi dan keterbatasannya serta keuntungannya.

Pendekatan Big Bang:

Di sini semua komponen terintegrasi bersamaan sekaligus diuji.

Keuntungan:

• Nyaman untuk sistem kecil.

Kekurangan:

• Lokalisasi kesalahan sulit.
• Mengingat banyaknya antarmuka yang perlu diuji dalam pendekatan ini, beberapa tautan antarmuka yang akan diuji dapat dilewatkan dengan mudah.
• Karena pengujian Integrasi dapat dimulai hanya setelah “semua” modul dirancang, tim pengujian akan memiliki waktu lebih sedikit untuk dieksekusi dalam fase pengujian.
• Karena semua modul diuji sekaligus, modul kritis berisiko tinggi tidak diisolasi dan diuji berdasarkan prioritas. Modul periferal yang berurusan dengan antarmuka pengguna juga tidak diisolasi dan diuji berdasarkan prioritas.

Pendekatan Tambahan

Dalam pendekatan ini, pengujian dilakukan dengan menggabungkan dua atau lebih modul yang terkait secara logis . Kemudian modul terkait lainnya ditambahkan dan diuji untuk berfungsi dengan benar. Proses berlanjut hingga semua modul bergabung dan diuji dengan sukses.

Pendekatan inkremental, pada gilirannya, dilakukan oleh dua Metode berbeda:

• Bottom Up
• Top Down

Apa itu Stubs and Driver?

Pendekatan inkremental dilakukan dengan menggunakan program dummy yang disebut Stubs and Drivers . Stubs dan Driver tidak menerapkan seluruh logika pemrograman modul perangkat lunak tetapi hanya mensimulasikan komunikasi data dengan modul panggilan.

Stubs : Disebut oleh Modul yang sedang diuji.

Driver : Memanggil Modul yang akan diuji.

Integrasi Bottom Up

Dalam strategi bottom-up, setiap modul di tingkat bawah diuji dengan modul yang lebih tinggi hingga semua modul diuji. Dibutuhkan bantuan Driver untuk pengujian

Representasi Diagram :

Keuntungan:

• Lokalisasi kesalahan lebih mudah.
• Tidak ada waktu yang terbuang untuk menunggu semua modul dikembangkan tidak seperti pendekatan Big Bang

Kekurangan:

• Modul penting (pada tingkat atas arsitektur perangkat lunak) yang mengontrol aliran aplikasi diuji terakhir dan mungkin rentan terhadap cacat.
• Prototipe awal tidak dimungkinkan

Integrasi Top-down:

Dalam pendekatan Top to down, pengujian dilakukan dari atas ke bawah mengikuti aliran kontrol sistem perangkat lunak.

Membutuhkan bantuan stubs untuk pengujian.

Representasi Diagram:

Keuntungan:

• Lokalisasi kesalahan lebih mudah.
• Kemungkinan untuk mendapatkan prototipe awal.
• Modul Kritis diuji berdasarkan prioritas; cacat desain utama dapat ditemukan dan diperbaiki terlebih dahulu.

Kekurangan:

• Membutuhkan banyak Stubs.
• Modul pada tingkat yang lebih rendah diuji secara tidak memadai.

Integrasi Hybrid / Sandwich

Dalam strategi sandwich / hybrid adalah kombinasi dari pendekatan Top Down dan Bottom up. Di sini, modul teratas diuji dengan modul yang lebih rendah pada saat yang sama modul yang lebih rendah diintegrasikan dengan modul atas dan diuji. Strategi ini memanfaatkan stubs serta driver.

Bagaimana cara melakukan Pengujian Integrasi?

Prosedur pengujian Integrasi terlepas dari strategi pengujian Perangkat Lunak (dibahas di atas):

1. Mempersiapkan Rencana Tes Integrasi
2. Desain Skenario, Kasus, dan Skrip Uji.
3. Melaksanakan uji Kasus diikuti dengan melaporkan cacat.
4. Melacak & menguji ulang cacat.
5. Langkah 3 dan 4 diulangi sampai penyelesaian Integrasi berhasil.

Deskripsi Singkat Rencana Tes Integrasi:

Terdiri beberapa hal berikut:

• Metode / Pendekatan untuk pengujian (seperti dibahas di atas).
• Cakupan dan luar cakupan Item Pengujian Integrasi.
• Peran dan Tanggung Jawab.
• Prasyarat untuk pengujian Integrasi.
• Lingkungan pengujian.
• Rencana Risiko dan Mitigasi.

Kriteria Masuk dan Keluar dari Pengujian Integrasi

Kriteria Masuk dan Keluar ke fase pengujian Integrasi dalam model pengembangan perangkat lunak apa pun

Kriteria Entri:

• Komponen / Modul Yang Diuji Unit
• Semua bug yang diprioritaskan Tinggi diperbaiki dan ditutup
• Semua Modul menjadi kode yang diselesaikan dan diintegrasikan dengan sukses.
• Rencana Tes Integrasi, uji kasus, skenario yang akan ditandatangani dan didokumentasikan.
• Lingkungan Uji yang Diperlukan harus disiapkan untuk pengujian Integrasi

Kriteria Keluar:

• Pengujian Aplikasi Terintegrasi yang berhasil.
• Kasus Uji yang dieksekusi didokumentasikan
• Semua bug yang diprioritaskan Tinggi diperbaiki dan ditutup
• Dokumen teknis yang akan dikirim diikuti oleh Notes rilis.

Praktik / Pedoman Terbaik untuk Pengujian Integrasi

• Pertama, tentukan Strategi Uji Integrasi yang dapat diadopsi dan kemudian menyiapkan kasus uji dan data uji yang sesuai.
• Pelajari desain Arsitektur Aplikasi dan identifikasi Modul Kritis. Ini perlu diuji berdasarkan prioritas.
• Dapatkan desain antarmuka dari tim Arsitektur dan buat kasus uji untuk memverifikasi semua antarmuka secara detail. Antarmuka ke basis data / aplikasi perangkat keras / perangkat lunak eksternal harus diuji secara terperinci.
• Setelah uji kasus, data uji yang memainkan peran penting.
• Selalu siapkan data tiruan, sebelum dieksekusi. Jangan memilih data uji saat menjalankan kasus uji.

Tutorial Pengujian Unit: Apa itu, Jenis, Alat, Contoh

Tutorial Pengujian Unit: Apa itu, Jenis, Alat, Contoh

Apa itu Unit Testing?

UNIT TESTING adalah jenis pengujian perangkat lunak di mana masing-masing unit atau komponen suatu perangkat lunak diuji. Tujuannya adalah untuk memvalidasi bahwa setiap unit kode perangkat lunak melakukan seperti yang diharapkan. Unit Testing dilakukan selama pengembangan (fase pengkodean) aplikasi oleh pengembang. Unit testing mengisolasi bagian kode dan memverifikasi kebenarannya. Unit dapat berupa fungsi, metode, prosedur, modul, atau objek individual.

Dalam SDLC, STLC, V Model, pengujian unit adalah pengujian tingkat pertama yang dilakukan sebelum pengujian integrasi. Unit testing adalah teknik pengujian WhiteBox yang biasanya dilakukan oleh pengembang. Padahal, dalam dunia yang praktis karena krisis waktu atau keengganan pengembang untuk menguji, insinyur QA juga melakukan pengujian unit.

Mengapa Unit Testing?

Terkadang pengembang perangkat lunak berupaya menghemat waktu dengan melakukan pengujian unit minimal. Ini adalah mitos karena melewatkan pengujian unit mengarah ke biaya perbaikan cacat yang lebih tinggi selama pengujian sistem, pengujian Integrasi dan bahkan Pengujian Beta setelah aplikasi selesai. Pengujian unit yang tepat dilakukan pada tahap pengembangan menghemat waktu dan uang pada akhirnya. Di sini, adalah alasan utama untuk melakukan pengujian unit.

Tingkat Pengujian Unit

1. Tes unit membantu untuk memperbaiki bug di awal siklus pengembangan dan menghemat biaya.
2. Ini membantu pengembang untuk memahami basis kode dan memungkinkan mereka untuk membuat perubahan dengan cepat
3. Tes unit yang baik berfungsi sebagai dokumentasi proyek
4. Tes unit membantu penggunaan kembali kode. Migrasikan kode Anda  dan tes Anda ke proyek baru Anda. Tweak kode hingga tes berjalan lagi.

Cara melakukan Pengujian Unit

Unit Testing terdiri dari dua jenis

• Manual
• Otomatis

Pengujian unit umumnya otomatis tetapi masih dapat dilakukan secara manual. Rekayasa Perangkat Lunak tidak mendukung satu sama lain tetapi otomatisasi lebih disukai. Pendekatan manual untuk pengujian unit dapat menggunakan dokumen petunjuk langkah demi langkah.

Di bawah pendekatan otomatis-

• Pengembang menulis bagian kode dalam aplikasi hanya untuk menguji fungsinya. Mereka nantinya akan berkomentar dan akhirnya menghapus kode tes ketika aplikasi siap digunakan.
• Pengembang juga dapat mengisolasi fungsi untuk mengujinya dengan lebih ketat. Ini adalah praktik pengujian unit yang lebih menyeluruh yang melibatkan salin dan tempel kode ke lingkungan pengujiannya sendiri daripada lingkungan alaminya. Mengisolasi kode membantu mengungkapkan ketergantungan yang tidak perlu antara kode yang sedang diuji dan unit atau ruang data lain dalam produk. Ketergantungan ini kemudian dapat dihilangkan.
• Seorang coder umumnya menggunakan Kerangka UnitTest untuk mengembangkan kasus uji otomatis. Menggunakan kerangka kerja otomatisasi, pengembang kode membuat kriteria ke dalam tes untuk memverifikasi kebenaran kode. Selama pelaksanaan kasus uji, kerangka kerja mencatat kasus uji. Banyak kerangka kerja juga akan secara otomatis menandai dan melaporkan, secara ringkas, kasus pengujian yang gagal ini. Tergantung pada tingkat keparahan kegagalan, kerangka kerja dapat menghentikan pengujian selanjutnya.
• Alur kerja Unit Testing adalah 1) Buat Kasus Uji 2) Review / Pengerjaan Ulang 3) Baseline 4) Jalankan Uji Kasus.

Teknik Pengujian Unit

Teknik cakupan kode yang digunakan dalam pengujian terpadu tercantum di bawah ini:

• Cakupan Pernyataan
• Cakupan Keputusan
• Cakupan Cabang
• Cakupan Kondisi
• Cakupan Mesin Finite State

Contoh Pengujian Unit: Objek Mock

Pengujian unit bergantung pada objek tiruan yang dibuat untuk menguji bagian kode yang belum menjadi bagian dari aplikasi lengkap. Benda-benda tiruan mengisi bagian-bagian yang hilang dari program.

Misalnya, Anda mungkin memiliki fungsi yang memerlukan variabel atau objek yang belum dibuat. Dalam pengujian unit, itu akan diperhitungkan dalam bentuk objek tiruan yang dibuat semata-mata untuk tujuan pengujian unit yang dilakukan pada bagian kode tersebut.

Alat Uji Unit

Ada beberapa alat otomatis yang tersedia untuk membantu pengujian unit. Kami akan memberikan beberapa contoh di bawah ini:

1. Junit : Junit adalah alat pengujian gratis yang digunakan untuk bahasa pemrograman Java. Ini memberikan pernyataan untuk mengidentifikasi metode pengujian. Alat ini menguji data terlebih dahulu dan kemudian disisipkan dalam potongan kode.
2. NUnit : NUnit banyak digunakan kerangka kerja unit-testing digunakan untuk semua bahasa .net. Ini adalah alat open source yang memungkinkan penulisan skrip secara manual. Ini mendukung tes berbasis data yang dapat berjalan secara paralel.
3. JMockit : JMockit adalah alat pengujian Unit open source. Ini adalah alat cakupan kode dengan metrik garis dan jalur. Ini memungkinkan mengejek API dengan sintaks perekaman dan verifikasi. Alat ini menawarkan Cakupan garis, Cakupan Jalur, dan Cakupan Data.
4. EMMA : EMMA adalah toolkit open-source untuk menganalisis dan melaporkan kode yang ditulis dalam bahasa Jawa. Emma mendukung jenis cakupan seperti metode, garis, blok dasar. Ini berbasis Java sehingga tanpa dependensi pustaka eksternal dan dapat mengakses kode sumber.
5. PHPUnit : PHPUnit adalah alat pengujian unit untuk programmer PHP. Dibutuhkan bagian kecil dari kode yang disebut unit dan menguji masing-masing secara terpisah. Alat ini juga memungkinkan pengembang untuk menggunakan metode penegasan yang telah ditentukan sebelumnya untuk menyatakan bahwa suatu sistem berperilaku dengan cara tertentu. 

Itu hanya beberapa alat pengujian unit yang tersedia. Ada banyak lagi, terutama untuk bahasa C dan Java, tetapi Anda yakin untuk menemukan alat pengujian unit untuk kebutuhan pemrograman Anda terlepas dari bahasa yang Anda gunakan.

Test Driven Development (TDD) & Unit Testing

Pengujian unit dalam TDD melibatkan penggunaan kerangka pengujian yang luas. Kerangka uji unit digunakan untuk membuat tes unit otomatis. Kerangka kerja pengujian unit tidak unik untuk TDD, tetapi mereka penting untuk itu. Di bawah ini kita melihat beberapa hal yang dibawa TDD ke dunia pengujian unit:

• Tes ditulis sebelum kode
• Bergantung pada kerangka pengujian
• Semua kelas dalam aplikasi diuji
• Integrasi yang cepat dan mudah dimungkinkan

Mitos Pengujian Unit

Mitos: Itu membutuhkan waktu, dan saya selalu dijadwal ulang.
Kode saya solid! Saya tidak perlu tes unit.

Mitos pada dasarnya adalah asumsi yang salah. Asumsi-asumsi ini menyebabkan siklus setan sebagai berikut –

Kebenarannya adalah pengujian Unit meningkatkan kecepatan pengembangan.

Pemrogram berpikir bahwa Pengujian Integrasi akan menangkap semua kesalahan dan tidak menjalankan pengujian unit. Setelah unit terintegrasi, kesalahan yang sangat sederhana yang dapat dengan mudah ditemukan dan diperbaiki dalam unit yang diuji membutuhkan waktu yang sangat lama untuk dilacak dan diperbaiki.

Keuntungan Pengujian Unit

• Pengembang yang ingin mempelajari fungsionalitas apa yang disediakan oleh unit dan bagaimana menggunakannya dapat melihat tes unit untuk mendapatkan pemahaman dasar tentang API unit.
• Unit testing memungkinkan programmer untuk memperbaiki kode di kemudian hari, dan memastikan modul masih bekerja dengan benar (yaitu pengujian Regresi). Prosedurnya adalah menulis kasus uji untuk semua fungsi dan metode sehingga setiap kali perubahan menyebabkan kesalahan, ia dapat dengan cepat diidentifikasi dan diperbaiki.
• Karena sifat modular dari pengujian unit, kami dapat menguji bagian-bagian proyek tanpa menunggu yang lain diselesaikan.

Kerugian Pengujian Unit

• Pengujian unit tidak dapat diharapkan untuk menangkap setiap kesalahan dalam suatu program. Tidak mungkin untuk mengevaluasi semua jalur eksekusi bahkan dalam program yang paling sepele
• Pengujian unit pada dasarnya berfokus pada unit kode. Oleh karena itu tidak dapat menangkap kesalahan integrasi atau kesalahan tingkat sistem yang luas.

Dianjurkan pengujian unit digunakan bersamaan dengan aktivitas pengujian lainnya.

Unit Menguji Praktik Terbaik

• Kasus Unit Test harus independen. Dalam hal ada peningkatan atau perubahan dalam persyaratan, kasus uji unit tidak boleh terpengaruh.
• Uji hanya satu kode pada satu waktu.
• Ikuti konvensi penamaan yang jelas dan konsisten untuk pengujian unit Anda
• Dalam hal terjadi perubahan kode dalam modul apa pun, pastikan ada Unit Uji Kasus yang sesuai untuk modul tersebut, dan modul tersebut lulus tes sebelum mengubah implementasi
• Bug yang diidentifikasi selama pengujian unit harus diperbaiki sebelum melanjutkan ke fase berikutnya dalam SDLC
• Gunakan pendekatan “test as your code”. Semakin banyak kode yang Anda tulis tanpa pengujian, semakin banyak jalur yang harus Anda periksa untuk kesalahan.

Ringkasan

• PENGUJIAN UNIT didefinisikan sebagai jenis pengujian perangkat lunak di mana masing-masing unit atau komponen perangkat lunak diuji.
• Seperti yang Anda lihat, mungkin ada banyak yang terlibat dalam pengujian unit. Ini bisa rumit atau agak sederhana tergantung pada aplikasi yang sedang diuji dan strategi pengujian, alat dan filosofi yang digunakan. Pengujian unit selalu diperlukan pada tingkat tertentu. Itu suatu kepastian.