Tes integrasi

INTEGRASI TESTING adalah tingkat pengujian perangkat lunak di mana

unit individu digabungkan dan diuji sebagai sebuah kelompok. Tujuan dari
tingkat pengujian ini adalah untuk mengekspos kesalahan dalam interaksi
antara unit terintegrasi. Driver penguji dan potongan uji digunakan untuk
membantu dalam Pengujian Integrasi.

Definisi oleh ISTQB

 pengujian integrasi: Pengujian dilakukan untuk mengekspos

kerusakan pada antarmuka dan 
interaksi antara komponen atau sistem terintegrasi. Lihat
juga pengujian integrasi komponen 
, pengujian integrasi sistem .
 pengujian integrasi komponen: Pengujian dilakukan untuk
mengekspos kerusakan pada antarmuka dan 
interaksi antara komponen terintegrasi.
 pengujian integrasi sistem: Menguji integrasi sistem dan
paket; menguji 
antarmuka ke organisasi eksternal (mis. Electronic Data Interchange,
Internet).

Analogi
Selama proses pembuatan bolpoin, tutup, badan, ekor dan klip, kartrid tinta
dan bolpoin diproduksi secara terpisah dan unit diuji secara terpisah. Ketika
dua atau lebih unit siap, mereka dirakit dan Pengujian Integrasi
dilakukan. Misalnya, apakah tutupnya pas dengan badan atau tidak.

metode
Setiap dari Black Box Testing , White Box Testing  dan Gray Box
Pengujian metode dapat digunakan. Biasanya, metode ini tergantung pada
definisi Anda tentang 'unit'.

Tugas
 Rencana Uji Integrasi
o Mempersiapkan
 o Ulasan
o Mengolah lagi
o Baseline
 Kasus / Skrip Uji Integrasi
o Mempersiapkan
o Ulasan
o Mengolah lagi
o Baseline
 Tes integrasi
o Melakukan

Kapan Pengujian Integrasi dilakukan?

Pengujian Integrasi adalah pengujian tingkat kedua yang dilakukan
setelah Unit Testing dan sebelum Pengujian Sistem .
Siapa yang melakukan Pengujian Integrasi?
Pengembang sendiri atau penguji independen melakukan Pengujian
Integrasi.

Pendekatan
 Big Bang adalah pendekatan Pengujian Integrasi di mana semua atau
sebagian besar unit digabungkan dan diuji sekaligus. Pendekatan ini
diambil ketika tim pengujian menerima seluruh perangkat lunak dalam
satu bundel. Jadi apa perbedaan antara Pengujian Integrasi Big Bang
dan Pengujian Sistem? Nah, yang pertama hanya menguji interaksi
antara unit sedangkan yang kedua menguji seluruh sistem.
 Top Down adalah pendekatan untuk Pengujian Integrasi di mana unit
tingkat atas diuji terlebih dahulu dan unit tingkat bawah diuji langkah
demi langkah setelah itu. Pendekatan ini diambil ketika pendekatan
pembangunan top-down diikuti. Rintisan Uji diperlukan untuk
mensimulasikan unit tingkat yang lebih rendah yang mungkin tidak
tersedia selama fase awal.
 Bottom Up adalah pendekatan untuk Pengujian Integrasi di mana unit
level bawah diuji terlebih dahulu dan unit level atas selangkah demi
selangkah setelah itu. Pendekatan ini diambil ketika pendekatan
pembangunan bottom-up diikuti. Driver Tes diperlukan untuk
mensimulasikan unit tingkat yang lebih tinggi yang mungkin tidak
tersedia selama fase awal.
 Sandwich / Hybrid adalah pendekatan untuk Pengujian Integrasi yang
merupakan kombinasi dari pendekatan Top Down dan Bottom Up.
Kiat
 Pastikan Anda memiliki dokumen Desain Detail yang tepat di mana
interaksi antara setiap unit didefinisikan dengan jelas. Bahkan, Anda
tidak akan dapat melakukan Pengujian Integrasi tanpa informasi ini.
 Pastikan Anda memiliki sistem Manajemen Konfigurasi Perangkat
Lunak yang kuat. Atau yang lain, Anda akan kesulitan melacak versi
yang tepat dari setiap unit, terutama jika jumlah unit yang akan
diintegrasikan sangat besar.
 Pastikan setiap unit diuji unit sebelum Anda memulai Pengujian
Integrasi.
 Sejauh mungkin, otomatisasi pengujian Anda, terutama ketika Anda
menggunakan pendekatan Top Down atau Bottom Up, karena
pengujian regresi adalah penting setiap kali Anda mengintegrasikan
unit, dan pengujian regresi manual dapat menjadi tidak efisien.

Kurangnya Tes Integrasi

Tes integrasi menentukan apakah unit perangkat lunak yang dikembangkan secara
independen bekerja dengan benar ketika mereka terhubung satu sama lain. Istilah
ini menjadi kabur bahkan oleh standar industri perangkat lunak yang tersebar, jadi
saya sudah waspada menggunakannya dalam tulisan saya. Secara khusus, banyak
orang menganggap tes integrasi memiliki cakupan yang luas, sementara mereka
dapat lebih efektif dilakukan dengan cakupan yang lebih sempit.
Seperti sering dengan hal-hal ini, yang terbaik adalah memulai dengan sedikit
sejarah. Ketika saya pertama kali belajar tentang pengujian integrasi, itu pada 1980-
an dan air terjun adalah pengaruh dominan pemikiran pengembangan perangkat
lunak. Dalam proyek yang lebih besar, kita akan memiliki fase desain yang akan
menentukan antarmuka dan perilaku berbagai modul dalam sistem. Modul
kemudian akan ditugaskan ke pengembang untuk diprogram. Bukan hal yang aneh
bagi seorang programmer untuk bertanggung jawab atas satu modul, tetapi ini
akan cukup besar sehingga dibutuhkan waktu berbulan-bulan untuk
membuatnya. Semua pekerjaan ini dilakukan secara terpisah, dan ketika
programmer percaya itu selesai mereka akan menyerahkannya kepada QA untuk
pengujian.
Bagian pertama dari pengujian adalah pengujian unit, yang akan menguji modul itu
sendiri, terhadap spesifikasi yang telah dilakukan pada tahap desain. Setelah itu
selesai, kami kemudian pindah ke pengujian integrasi, di mana berbagai modul
digabungkan bersama, baik ke dalam seluruh sistem, atau ke dalam sub-sistem
yang signifikan.
Maksud pengujian integrasi, seperti namanya, adalah untuk menguji apakah
banyak modul yang dikembangkan secara terpisah bekerja bersama seperti
yang diharapkan . Itu dilakukan dengan mengaktifkan banyak modul dan
menjalankan tes tingkat yang lebih tinggi terhadap semuanya untuk memastikan
mereka beroperasi bersama. Modul-modul ini dapat bagian-bagian yang dapat
dieksekusi tunggal, atau terpisah.
Melihat dari perspektif yang lebih 2010, ini menggabungkan dua hal yang berbeda:
 pengujian yang dikembangkan secara terpisah modul bekerja bersama
dengan benar
 menguji bahwa sistem beberapa modul berfungsi seperti yang diharapkan.
Kedua hal ini mudah untuk dikonfigurasikan, setelah semua bagaimana lagi Anda
akan menguji modul-modul frobile dan twibbler tanpa mengaktifkan keduanya
menjadi satu lingkungan tunggal dan menjalankan tes-tes yang menggunakan
kedua modul?
Perspektif 2010 menawarkan alternatif lain, yang jarang dipertimbangkan pada
1980-an. Sebagai alternatif, kami menguji integrasi modul frobile dan twibbler
dengan menggunakan bagian kode dalam frobile yang berinteraksi dengan
twibbler, mengeksekusinya terhadap TestDouble dari twibbler. Memberikan tes
ganda adalah twibber yang setia, kami kemudian dapat menguji semua perilaku
interaksi twibbler tanpa mengaktifkan instance twibbler penuh. Ini mungkin bukan
masalah besar jika mereka merupakan modul terpisah dari aplikasi monolitik,
tetapi merupakan masalah besar jika twibbler adalah layanan terpisah, yang
membutuhkan alat bangun sendiri, lingkungan, dan koneksi jaringan. Untuk
layanan, pengujian semacam itu dapat dijalankan terhadap uji ganda dalam-proses,
atau terhadap over-the-wire ganda, menggunakan sesuatu sepertibank mount
Tangkapan yang jelas dengan pengujian integrasi terhadap ganda adalah apakah
ganda itu benar-benar setia. Tetapi kita dapat mengujinya secara terpisah
menggunakan ContractTests .
Menggunakan kombinasi ini menggunakan tes integrasi sempit dan tes kontrak,
saya bisa yakin mengintegrasikan ke layanan eksternal tanpa pernah menjalankan
tes terhadap contoh nyata dari layanan itu, yang sangat memudahkan proses
pembangunan saya. Tim yang melakukan ini, mungkin masih melakukan beberapa
bentuk uji sistem ujung ke ujung dengan semua layanan nyata, tetapi jika demikian
itu hanya tes asap akhir dengan rentang jalur yang sangat terbatas yang diuji. Ini
juga membantu untuk memiliki QA yangmatang dalam kemampuan Produksi , dan
jika itu cukup matang, mungkin tidak ada pengujian sistem end-to-end yang
dilakukan sama sekali.
Masalahnya adalah bahwa kita memiliki (setidaknya) dua gagasan berbeda tentang
apa yang merupakan tes integrasi.
tes integrasi sempit
 gunakan hanya bagian kode dalam layanan saya yang berbicara ke layanan
terpisah
 menggunakan uji ganda dari layanan tersebut, baik dalam proses atau jarak
jauh
 dengan demikian terdiri dari banyak pengujian dengan cakupan sempit,
sering kali tidak lebih besar dalam cakupannya daripada tes unit (dan biasanya
dijalankan dengan kerangka uji yang sama yang digunakan untuk tes unit)
tes integrasi luas
 memerlukan versi langsung dari semua layanan, yang membutuhkan
lingkungan uji substansial dan akses jaringan
 latih jalur kode melalui semua layanan, bukan hanya kode yang bertanggung
jawab untuk interaksi
Dan ada sejumlah besar pengembang perangkat lunak untuk siapa "uji integrasi"
hanya berarti "tes integrasi luas", yang menyebabkan banyak kebingungan ketika
mereka bertemu dengan orang-orang yang menggunakan pendekatan sempit.
Jika satu-satunya tes integrasi Anda yang luas, Anda harus mempertimbangkan
menjelajahi gaya yang sempit, karena tes ini cenderung meningkatkan kecepatan
pengujian, kemudahan penggunaan, dan ketahanan Anda secara signifikan. Karena
tes integrasi yang sempit terbatas dalam ruang lingkup, maka tes ini sering berjalan
sangat cepat, sehingga dapat berjalan pada tahap awal dari DeploymentPipeline ,
memberikan umpan balik yang lebih cepat jika hasilnya memerah.
Semua ini sebabnya saya khawatir dengan "tes integrasi". Ketika saya
membacanya, saya mencari lebih banyak konteks sehingga saya tahu jenis yang
penulis maksud. [1] Jika saya berbicara tentang tes integrasi luas, saya lebih suka
menggunakan "tes sistem" atau "tes ujung ke ujung". Saya tidak memiliki nama
yang lebih baik untuk tes integrasi sempit, jadi saya menggunakannya (tetapi
dengan "sempit" untuk membantu memberi sinyal kepada pembaca sifat dari tes
ini).
Ucapan Terima Kasih
Apa itu Pengujian Integrasi?
Pengujian Integrasi didefinisikan sebagai jenis pengujian di mana modul perangkat
lunak diintegrasikan secara logis dan diuji sebagai suatu kelompok.

Proyek perangkat lunak tipikal terdiri dari beberapa modul perangkat lunak, yang
dikodekan oleh programmer yang berbeda. Pengujian Integrasi berfokus pada
pemeriksaan komunikasi data di antara modul-modul ini.

Oleh karena itu ia juga disebut sebagai  'I & T'  (Integrasi dan

Pengujian),  'Pengujian String'dan kadang-kadang 'Pengujian Thread'.

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
mengatakan '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 Tujuan Uji Kasus
Uji
Periksa tautan antarmuka
1 antara modul Login dan Kotak
Surat
Periksa tautan antarmuka
2 antara Kotak Surat dan Hapus
Modul Surat
Deskripsi Test Case Hasil yang diharapkan
Masukkan kredensial
Untuk diarahkan ke Kotak
masuk dan klik tombol
Surat
Login
Dari Kotak Surat pilih Email yang dipilih akan
email dan klik tombol muncul di folder Dihapus /
hapus Sampah

Pendekatan / Metodologi / Strategi Pengujian Integrasi:

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

  Pendekatan Big Bang:

  Pendekatan Tambahan: yang selanjutnya dibagi menjadi yang berikut
o  Pendekatan Top Down
o  Pendekatan dari Bawah ke Atas
o  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 diintegrasikan bersama sekaligus kemudian 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:

 Bawah ke Atas
 Top Down

Apa itu Stub and Driver?

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

Rintisan : Disebut oleh Modul yang sedang diuji.

Driver : Memanggil Modul yang akan diuji.

Integrasi dari bawah ke atas

Dalam strategi bottom-up, setiap modul di level 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 kritis (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 rintisan 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 Rintisan.

 Modul pada level 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 rintisan 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:

Ini termasuk atribut berikut:

 Metode / Pendekatan untuk pengujian (seperti dibahas di atas).

 Lingkup dan Keluar dari Lingkup 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.
 Tes Integrasi Rencana, uji kasus, skenario yang akan ditandatangani dan
didokumentasikan.
 Lingkungan Tes yang Diperlukan harus diatur 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 rinci.
 Setelah uji kasus, data uji yang memainkan peran penting.
 Selalu siapkan data tiruan, sebelum dieksekusi. Jangan memilih data uji saat
menjalankan kasus uji.

Mari kita periksa contoh di bawah ini :

Saya adalah pemilik perusahaan periklanan dan saya memposting iklan di situs web yang
berbeda. Pada akhir bulan, saya ingin melihat berapa banyak orang melihat iklan saya dan
berapa banyak orang mengklik iklan saya. Saya perlu laporan untuk iklan saya ditampilkan
dan saya menagih sesuai untuk klien saya.
Perangkat lunak GenNext mengembangkan produk ini untuk saya dan di bawah ini adalah
arsitekturnya:

UI - Modul Antarmuka Pengguna, yang dapat dilihat oleh pengguna akhir, tempat semua
input diberikan. 
BL - Adalah modul Logika Bisnis, yang memiliki semua perhitungan dan metode spesifik
bisnis. 
VAL - Adalah modul Validasi, yang memiliki semua validasi kebenaran input. 
CNT - Adalah modul konten yang memiliki semua konten statis, khusus untuk input yang
dimasukkan oleh pengguna. Konten ini ditampilkan dalam laporan. 
EN - Apakah modul Engine, modul ini membaca semua data yang berasal dari modul BL,
VAL dan CNT dan mengekstrak kueri SQL dan memicunya ke database. 
Penjadwal- Merupakan modul yang menjadwalkan semua laporan berdasarkan pilihan
pengguna (bulanan, triwulanan, semesteran & tahunan) 
DB - Adalah Basis Data.
Sekarang, setelah melihat arsitektur seluruh aplikasi web, sebagai satu unit, pengujian
Integrasi, dalam hal ini, akan fokus pada aliran data antar modul.
Pertanyaan di sini adalah:
1. Bagaimana BL, VAL dan modul CNT akan membaca dan menginterpretasikan data
yang dimasukkan dalam modul UI?
2. Apakah modul BL, VAL dan CNT menerima data yang benar dari UI?
 3. Dalam format apa data dari BL, VAL dan CNT ditransfer ke modul EQ?
4. Bagaimana EQ akan membaca data dan mengekstrak kueri?
5. Apakah kueri diekstraksi dengan benar?
6. Apakah Penjadwal mendapatkan data yang benar untuk laporan?
7. Apakah hasil yang ditetapkan diterima oleh EN, dari database sudah benar dan
seperti yang diharapkan?
8. Apakah EN dapat mengirim respons kembali ke modul BL, VAL dan CNT?
9. Apakah modul UI dapat membaca data dan menampilkannya dengan tepat ke
antarmuka?
Di dunia nyata, komunikasi data dilakukan dalam format XML. Jadi, apa pun data yang
dimasukkan pengguna di UI, itu akan dikonversi menjadi format XML.
Dalam skenario kami, data yang dimasukkan dalam modul UI akan dikonversi menjadi file
XML yang ditafsirkan oleh 3 modul BL, VAL dan CNT. Modul EN membaca file XML yang
dihasilkan yang dihasilkan oleh 3 modul dan mengekstrak SQL dari itu dan permintaan ke
dalam database. Modul EN juga menerima set hasil dan mengubahnya menjadi file XML
dan mengembalikannya ke modul UI yang mengubah hasil dalam bentuk yang dapat
dibaca pengguna dan menampilkannya.
Di tengah-tengah kita memiliki modul penjadwal yang menerima set hasil dari modul EN,
membuat dan menjadwalkan laporan.
Jadi di mana pengujian Integrasi tidak muncul?
Nah, pengujian apakah informasi / data mengalir dengan benar atau tidak akan menjadi
pengujian integrasi Anda, yang dalam hal ini akan memvalidasi file XML. Apakah file XML
dihasilkan dengan benar? Apakah mereka memiliki data yang benar? Apakah data sedang
ditransfer dengan benar dari satu modul ke modul lainnya? Semua hal ini akan diuji sebagai
bagian dari pengujian Integrasi.
Cobalah untuk membuat atau mendapatkan file XML dan memperbarui tag dan memeriksa
perilaku. Ini adalah sesuatu yang sangat berbeda dari pengujian yang biasa dilakukan
penguji, tetapi ini akan menambah nilai bagi pengetahuan penguji dan pemahaman tentang
aplikasi.
Beberapa kondisi uji sampel lainnya dapat sebagai berikut:
 Apakah opsi menu menghasilkan jendela yang benar?
 Apakah windows dapat mengaktifkan jendela yang sedang diuji?
 Untuk setiap jendela, identifikasi fungsi panggilan untuk jendela yang seharusnya
diizinkan oleh aplikasi.
 Identifikasi semua panggilan dari jendela ke fitur lain yang harus diizinkan oleh
aplikasi
 Identifikasi panggilan yang dapat dibatalkan: menutup jendela yang dipanggil harus
kembali ke jendela panggilan.
 Identifikasi panggilan yang tidak dapat dibatalkan: jendela panggilan ditutup sebelum
jendela yang dipanggil muncul.
 Uji berbagai cara melaksanakan panggilan ke jendela lain, misalnya - menu, tombol,
kata kunci.
Langkah-langkah untuk Memulai Tes Integrasi
1. Pahami arsitektur aplikasi Anda.
2. Identifikasi modul
3. Pahami apa yang dilakukan setiap modul
4. Memahami bagaimana data ditransfer dari satu modul ke modul lainnya.
 5. Memahami bagaimana data dimasukkan dan diterima ke dalam sistem (titik masuk
dan titik keluar dari aplikasi)
6. Pisahkan aplikasi sesuai dengan kebutuhan pengujian Anda.
7. Identifikasi dan buat kondisi pengujian
8. Ambil satu syarat pada satu waktu dan tuliskan kotak uji.
Kriteria Masuk / Keluar untuk Pengujian Integrasi
Kriteria Entri:
 Dokumen rencana uji integrasi ditandatangani dan disetujui.
 Kasus uji integrasi telah disiapkan.
 Data uji telah dibuat.
 Pengujian unit modul / Komponen yang dikembangkan selesai.
 Semua cacat Prioritas kritis dan tinggi ditutup.
 Lingkungan pengujian diatur untuk integrasi.
Kriteria Keluar:
 Semua kasus uji integrasi telah dieksekusi.
 Tidak ada cacat P1 & P2 yang kritis dan Prioritas dibuka.
 Laporan Uji telah disiapkan.
Kasus Uji Integrasi
Kasing uji integrasi berfokus terutama pada antarmuka antara modul, tautan terintegrasi,
transfer data antara modul sebagai modul / komponen yang sudah diuji unit yaitu fungsi
dan aspek pengujian lainnya telah dicakup.
Jadi, ide utamanya adalah menguji apakah mengintegrasikan dua modul kerja berfungsi
seperti yang diharapkan saat terintegrasi.
Misalnya, Contoh Uji Integrasi untuk aplikasi Linkedin akan mencakup:
 Memverifikasi tautan antarmuka antara halaman masuk dan beranda yaitu saat
pengguna memasukkan kredensial dan log, itu harus diarahkan ke beranda.
 Memverifikasi tautan antarmuka antara halaman beranda dan halaman profil yaitu
halaman profil harus terbuka.
 Verifikasi tautan antarmuka antara halaman jaringan dan halaman koneksi Anda,
yaitu mengklik tombol accept pada Undangan halaman jaringan akan menunjukkan
undangan yang diterima di halaman koneksi Anda setelah diklik.
 Verifikasi tautan antarmuka antara halaman Notifikasi dan ucapkan tombol ucapan
selamat yaitu mengklik tombol katakan ucapan selamat harus langsung menuju
jendela pesan baru.
Banyak kasus uji integrasi dapat ditulis untuk situs spesifik ini. Keempat poin di atas
hanyalah contoh untuk memahami kasus uji Integrasi apa yang termasuk dalam pengujian.
Apakah Integrasi Kotak Putih atau Teknik Kotak Hitam?
Teknik pengujian integrasi dapat dihitung dalam kotak hitam maupun teknik kotak
putih . Teknik black box adalah di mana tester tidak perlu memiliki pengetahuan internal
tentang sistem yaitu pengetahuan pengkodean tidak diperlukan sedangkan teknik white box
membutuhkan pengetahuan internal aplikasi.
Sekarang saat melakukan pengujian integrasi itu dapat mencakup pengujian dua layanan
web terintegrasi yang akan mengambil data dari database & menyediakan data
sebagaimana diperlukan yang berarti dapat diuji dengan menggunakan teknik pengujian
kotak putih sedangkan mengintegrasikan fitur baru di situs web dapat diuji menggunakan
teknik kotak hitam.
Jadi, tidak spesifik bahwa pengujian integrasi adalah teknik kotak hitam atau kotak putih.
Alat Pengujian Integrasi
Ada beberapa alat yang tersedia untuk pengujian ini.
Diberikan di bawah ini adalah daftar alat:
 Penguji Integrasi Rasional
 Busur derajat
 Uap
 TESSY
Untuk detail lebih lanjut tentang alat-alat di atas periksa tutorial ini:
Pengujian Integrasi Sistem
Uji Integrasi Sistem dilakukan untuk menguji sistem terintegrasi yang lengkap .
Modul atau komponen diuji secara individual dalam pengujian unit sebelum
mengintegrasikan komponen.
Setelah semua modul diuji, pengujian integrasi sistem dilakukan dengan mengintegrasikan
semua modul dan sistem secara keseluruhan diuji.
Perbedaan antara Pengujian Integrasi & Pengujian Sistem
Pengujian integrasi adalah pengujian di mana satu atau dua modul yang diuji unit
diintegrasikan untuk menguji dan verifikasi dilakukan untuk memverifikasi apakah modul
terintegrasi berfungsi seperti yang diharapkan atau tidak.
Pengujian sistem adalah pengujian di mana sistem secara keseluruhan diuji yaitu semua
modul / komponen terintegrasi bersama untuk memverifikasi apakah sistem bekerja seperti
yang diharapkan dan tidak ada masalah terjadi karena modul terintegrasi.
Kesimpulan
Ini semua tentang pengujian Integrasi dan implementasinya dalam teknik Kotak Putih dan
Kotak Hitam. Semoga kami jelaskan dengan contoh yang relevan.
Integrasi Tes adalah bagian penting dari siklus pengujian karena memudahkan untuk
menemukan cacat ketika dua atau lebih modul diintegrasikan untuk mengintegrasikan
semua modul bersama-sama pada langkah pertama itu sendiri.
Ini membantu dalam menemukan cacat pada tahap awal yang pada gilirannya menghemat
usaha dan biaya juga. Ini memastikan bahwa modul terintegrasi berfungsi sebagaimana
mestinya.

Integration testing
Tahapan berikutnya setelah unit test adalah menguji unit-unit
tersebut bekerja dalam satu kesatuan. Pengujian dilakukan untuk
melihat sebuah aplikasi dapat terkoneksi dan berfungsi dengan
aplikasi yang lain sesuai yang diharapkan. Jika aplikasi tersebut
memerlukan aplikasi lain seperti database atau 3rd party service,
maka koneksi antar aplikasi tersebut harus benar-benar dilakukan,
bukan lagi dari mock data. Pengujian yang dilakukan pada tahap ini
tidak boleh terlalu detail, karena tujuan dari test ini bukanlah
menguji ketepatan dari sebuah aplikasi. Hal lain yang harus
diperhatikan adalah data yang digunakan. Sebisa mungkin data yang
digunakan hanya digunakan untuk pengujian aplikasi tersebut (tidak
digunakan oleh aplikasi yang lain).

Skenario Test
April 19, 2012

Pendahuluan

Latar belakang

Untuk menghasilkan suatu sistem aplikasi atau sistem software

yang baik sesuai dengan kebutuhan user atau pengguna aplikasi
sudah merupakan kewajiban para sistem developer. Sistem
software dikatakan berkualitas apabila sesuai dengan harapan user,
sesuai dengan bisnis proses, mempermudah kerja user dan
memiliki sedikit bug bahkan tanpa bug sama sekali. Ini merupakan
suatu tantangan untuk para software developer untuk menghasilkan
software tersebut.

Testing (Pengujian Perangkat Lunak) adalah elemen kritis dari

jaminan kualitas perangkat lunak dan merepresentasikan kajian
pokok dari spesifikasi, desain, dan pengkodean.

Pentingnya pengujian perangkat lunak dan implikasinya yang

mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekan
karena melibatkan sederetan aktivitas produksi di mana peluang
terjadinya kesalahan manusia sangat besar dan arena
ketidakmampuan manusia untuk melakukan dan berkomunikasi
dengan sempurna maka pengembangan perangkat lunak diiringi
dengan aktivitas jaminan kualitas.
Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai
suatu elemen sistem dan “biaya” yang muncul akibat kegagalan
perangkat lunak, memotivasi dilakukannya perencanaan yang baik
melalui pengujian yang teliti. Pada dasarnya, pengujian merupakan
satu langkah dalam proses rekayasa perangkat lunak yang dapat
dianggap sebagai hal yang merusak daripada membangun.

Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada

perangkat lunak adalah:

1. Pengujian adalah proses eksekusi suatu program

dengan maksud menemukan kesalahan.
2. Test case yang baik adalah test case yang memiliki
probabilitas tinggi untuk menemukan kesalahan
yang belum pernah ditemukan sebelumnya.
3. Pengujian yang sukses adalah pengujian yang
mengungkap semua kesalahan yang belum pernah
ditemukan sebelumnya.
Sasaran utama desain test case adalah untuk mendapatkan
serangkaian pengujian yang memiliki kemungkinan tertinggi di
dalam pengungkapan kesalahan pada perangkat lunak. Untuk
mencapai sasaran tersebut, digunakan 4 kategori yang berbeda
dari tehnik desain test case: Pengujian white-box, pengujian black-
box, Integrasi Bottom-Up dan Integrasi Top-Down.

Tujuan
Tujuan pembuatan dokumen test case antara lain:

1. Memberikan panduan kepada tester untuk

melakukan pengujian aplikasi
2. Sebagai bahan masukan kepada tim pengembang
aplikasi
3. Menjadi dasar pengembangan bagi pengerjaan
proyek selanjutnya
 4. Sebagai salah satu dokumen pendukung
penyelesaian proyek IT
Keterangan Kode
Beberapa kode yang digunakan pada matrix skenario ini antara lain:

 V (Valid)               :           menunjukkan bahwa

komponen yang membentuk skenario
memiliki nilai yang benar atau valid, sehingga membuat sistem
sukses

 I (Invalid)              :           menunjukkan bahwa

komponen yang membentuk skenario
memiliki nilai yang salah atau invalid, sehingga membuat sistem
menjalankan skenario alternatifnya

 NA (Not Access)  :           menunjukkan bahwa

komponen yang membentuk skenario
tersebut tidak memiliki peranan atau tidak bisa diakses pada saat
tertentu di dalam skenario itu sendiri

Test Case :

Dalam tugas kali ini kami akan mencoba melakukan pengujian /

testing dengan menggunakan teknik test case berdasarkan
skenario test dengan pengujian aplikasi yang sudah digunakan di
sebuah Rumah Sakit.

1.      Use Case         :  User Login

Bacic path :

User berada pada halaman user login. User mengisikan nama serta
password pada textfield dan password pada passwordfield
kemudian menekan enter / klik ‘Login’. Sistem mencari user pada
database user berdasarkan username dan password yang telah di
input sebelumnya, jika benar kemudian sistem menampilkan
halaman ‘Registrasi Pasien UGD’

Alternate Path :

Alternate path 1 :

Jika textfield username dan password dikosongkan, dan user

langsung menekan ‘enter / tombol login’ maka sistem akan
menampilkan pesan ‘Tidak dapat koneksi ke Database’

Alternate path 2 :

Jika textfield username diisi dan password dikosongkan, kemudian

user menekan ‘enter / tombol login’ maka sistem akan menampilkan
pesan ‘Tidak dapat koneksi ke Database’

Alternate path 3 :

Jika textfield username dikosongkan dan textfield password diisi,

kemudian user menekan ‘enter / tombol login’ maka sistem akan
menampilkan pesan ‘Tidak dapat koneksi ke Database’

Alternate path 4 :

Jika textfield username diisi dan password diisi dengan

menggunakan huruf kapital, kemudian user menekan ‘enter / tombol
login’ maka sistem akan menampilkan pesan ‘Tidak dapat koneksi
ke Database’

Alternate path 5 :

Jika textfield username dan password diisi dengan benar namun

textfield unit dipilih dengan unit lain yang bukan otoritas user, dan
user menekan ‘enter / tombol login’ maka sistem akan menampilkan
pesan ‘Tidak dapat koneksi ke Database’

Skenario test case :

 Skenari Unit
Hal Password
o User- Tombol
Nama Skenario Hasil
IDfield Fiel Login
login field
ID d

STC-1.1 V V V V V Halaman Registrasi

Login sukses
Pasien
Pesan ‘Tidak dapat
Login gagal, 2 V I I V V
STC-1.2 koneksi ke
textfield kosong
Database’
Login gagal, Pesan ‘Tidak dapat
V I V V V
STC-1.3 username field koneksi ke
kosong Database’
Login gagal, Pesan ‘Tidak dapat
V V I V V
STC-1.4 password field koneksi ke
kosong Database’
Login gagal, Pesan ‘Tidak dapat
V V V V V
STC-1.5 password dengan koneksi ke
huruf  kapital Database’
Login gagal, unit Pesan ‘Tidak dapat
V V V I V
STC-1.6 tidak sesuai hak koneksi ke
user Database’
 
2.      Use Case : Menu Search

2.1              Mencari Nama Pasien

Basic path :

User berada di halaman pencarian pasien yang sudah di entry, dan

mencari nama pasien pada textfield ‘Nama Pasien. Sistem akan
menampilkan nama pasien yang dicari.

Alternate path :

Jika user mengisikan nama pasien dengan memberi spasi 1 sampai

dengan beberapa kali pada kolom textfield ‘nama pasien’. Sistem
masih bisa menampilkan nama pasien.
Skenario test case :

Skenari N.Pasie
Hal Alamat
o Nama No.RMfiel n Tombo
Hasil
Skenario d l Login
Search Field
ID field

STC–2.1 Mencari V – V – V Nama pasien

nama pasien ditampilkan
Nama diberi V – V – V Nama pasien
STC–2.2
spasi ditampilkan
 

2.2              Mencari No.RM Pasien

Basic path :

User berada di halaman pencarian pasien yang sudah di entry, dan

mencari No.RM pasien pada textfield ‘No.RM. Sistem akan
menampilkan No.RM pasien yang dicari.

Alternate path :

Jika user mengisikan No.RM dengan memberi spasi 1 sampai

dengan beberapa kali pada kolom textfield . Sistem akan
menampilkan pesan ‘No Data to Display’.

Skenario test case :

N.Pasie
Skenario Hal Alamat
Nama n Tombo
No.RMfield Hasil
Skenario l Login
ID Search Field
field

STC– No.RM
Mencari V V – – V
2.2.1 pasien
No.RM
ditampilkan
STC– Pesan ‘No
No.RM V V – – V
2.3.2 data to
diberi spasi
Display’
2.3              Mencari Nama Keluarga

Basic path :

User berada di halaman pencarian pasien yang sudah di entry, dan

mencari nama keluarga pasien pada textfield ‘Nama Keluarga.
Sistem akan menampilkan nama keluarga pasien yang dicari.

Alternate path :

Jika user mengisikan nama keluarga pasien dengan memberi spasi

1 sampai dengan beberapa kali pada kolom textfield ‘nama
keluarga’. Sistem masih bisa menampilkan nama keluarga.

Skenario test case :

Skenari Hal N.Pasie

Keluarga
o Nama n Tombol
No.RMfield Hasil
Skenario Searc Login
Field
ID h field

STC– Nama
Mencari nama V – – V V
2.3.1 keluarga
keluarga
ditampilkan
STC– Nama Nama
V – – V V
2.3.2 keluargadiberi keluarga
spasi ditampilkan
 

2.4              Mencari Alamat Pasien

Basic path :

User berada di halaman pencarian pasien yang sudah di entry, dan

mencari alamat pasien pada textfield ‘Alamat’. Sistem akan
menampilkan nama pasien berdasarkan alamat yang dicari.

Alternate path :
Jika user mengisikan alamat pasien dengan memberi spasi 1
sampai dengan beberapa kali pada kolom textfield ‘nama pasien’.
Sistem masih bisa menampilkan nama pasien berdasarkan alamat.

Skenario test case :

Hal Alama
Skenario N.Pasien
No.RMfiel t Tombol
Nama Skenario Hasil
Searc d Login
ID field
h Field

Nama pasien
STC– Mencari  pasien
V – – V V berdasarkan
2.4.1 berdasarkan
alamat
alamat
ditampilkan
Nama pasien
STC–
Alamat  diberi V – – – V berdasarkan
2.4.2
spasi alamat
ditampilkan
 

2.5              Mencari Pasien berdasarkan tanggal lahir

Basic path :

User berada di halaman pencarian pasien yang sudah di entry, dan

mencari pasien pada datefield ‘tgl lahir’ dengan mencentangnya
dan mengisikan tanggal lahir pasien yang dicari. Sistem akan
menampilkan data pasien yang dicari berdasarkan tanggal lahirnya.

Skenario test case :

Hal N.Pasie
Skenario Tgl.lahir
No.RMfiel n Tombo
Nama Skenario Hasil
Searc d l Login
ID Field
h field

Nama pasien
STC– Mencari  pasien
V – – V V berdasarkan
2.5.1 berdasarkan
alamat
alamat
ditampilka
 

2.6              Pencarian Tipe Pasien

Basic path :

User berada di halaman pencarian tipe pasien yang sudah di entry,

dan mencari tipe pasien pada textfield ‘Search’. Dengan menekan
tombol ‘Go’, maka Sistem akan menampilkan seluruh  tipe pasien
yang sudah diisi.

Alternate path :

Alternate path 1

Jika user mengisikan tipe pasien pada kolom textfield ‘search’.

Sistem menampilkan tipe pasien yang dimaksud.

Alternate path 2

Jika user mengisikan tipe pasien dengan memberi spasi 1 sampai

dengan beberapa kali pada kolom textfield ‘search’. Sistem masih
bisa menampilkan tipe pasien yang dimaksud.

Alternate path 3

Jika user mengisikan kode tipe pasien pada kolom textfield ‘search’.
Sistem menampilkan tipe pasien yang dimaksud.

Alternate path 4

Jika user mengisikan kode tipe pasien dengan memberi spasi 1

sampai dengan beberapa kali pada kolom textfield ‘search’. Sistem
masih bisa menampilkan tipe pasien yang dimaksud berdasarkan
kode tipe pasien

Alternate path 5
 Jika user memilih tombol ‘Choose’. Maka sistem tidak menampilkan
data tipe pasien.

Alternate path 6

Jika user memilih tombol ‘Cancel’. Maka sistem akan menuntup

halaman pencarian tipe pasien dan akan menampilkan pesan
‘Pencarian dibatalkan’

Alternate path 7

Jika user mengisikan textfield search dengan keyword sembarang,

maka sistem akan menampilkan pesan ‘No data to Display’.

Skenario test case :

Skenari Hal
Tombol Tombol
o Searchfiel
Nama Skenario Hasil
Searc d
Go Cancel
ID h

STC– V – V – Tipe pasien

Mencari Tipe Pasien
2.6.1 ditampilkan
STC– V V V – Tipe pasien
Mencari Tipe pasien
2.6.2 ditampilkan
STC- Mencari Tipe Pasien V V V – Tipe pasien
2.6.3 diberi spasi ditampilkan
STC– Mencari Kode Tipe V V V – Tipe pasien
2.6.4 Pasien ditampilkan
STC– Mencari Kode Tipe V V V – Tipe pasien
2.6.5 Pasien diberi spasi ditampilkan
STC- V – – V Pesan ‘Pencarian
Pilih tombol ‘Cancel’
2.6.6 Dibatalkan’
STC- Mencari Tipe Pasien V V V – Pesan ‘No data to
2.6.7 sembarang display’
 
3.      Use Case : Registrasi pasien

Basic path :

User berada di halaman utama registrasi pasien. User mengisi

textfield ‘No.RM / F2’ dengan Nomor RM yang dimaksud, maka
sistem akan mencari nomor RM tersebut dan bila ada sistem akan
menampilkan data pasien pada halaman search. User menekan
tombol ‘F2’ pada keyboard. Maka Sistem akan menampilkan
halaman ‘Search’ untuk mencari data .

Alternate path :

Alternate path 1

Jika user menekan tombol ‘F2’ pada keyboard. Maka Sistem akan
menampilkan halaman ‘Search’ untuk pencarian data pasien.

Alternate path 2

Jika user mengisikan nomor RM yang tidak ada pada database atau
mengisikan sembarang character, maka sistem akan menampilkan
halaman ‘search’ dan akan tampil pesan ‘No data to Display’.

Alternate path 3

Jika user meng-klik ‘Pasien Baru / Ctrl-N’ maka akan tampil pesan ‘
Apakah anda ingin memasukan pasien baru?

 Alternate path 4

Jika user meng-klik ‘Edit Pasien / Ctrl+E’ maka sistem akan

menampilkan pesan ‘Pasien belum dipilih’

Alternate path 5

Jika user meng-klik tombol ‘Save / Ctrl+S’ maka sistem akan

menampilkan pesan ‘Pasien belum dipilih’
 Alternate path 6

Jika user meng-klik tombol ‘Save & Print / Ctrl+R’ maka sistem akan
menampilkan pesan ‘Pasien belum dipilih’

Alternate path 7

Jika user meng-klik tombol ‘Tutup Window / Esc’ maka sistem akan
menutup halaman Registrasi pasien.

Skenario test case :

Skenari Save
Hal No.Rm Edit Tutup
o Nama Sav &
PasienBaru Hasil
Skenario e
Reg. Field Pasien Window
ID Print

STC–3.1 Registrasi V V – – – – – Data pasien

Pasien lama ditampilkan
Halaman
STC–3.2 Tombol F2 V – – – – – –
‘Search’
dipilih
tampil
Registrasi Pesan ‘No
STC-3.3 V V – – – – –
dengan data to
sembarang Display’
Pesan
Pilih ‘Apakah
STC–3.4 ‘Pasien V – V – – – – anda ingin
Baru / memasukan
Ctrl+N’ pasien
baru?’
Pesan
Pilih ‘Edit
STC–3.5 V – – V – – – ‘Pasien
Pasien /
belum
Ctrl+E’
dipilih’
Pesan
STC-3.6 Pilih ‘Save / V – – – V – – ‘Pasien
Ctrl+S’ belum
dipilih’
 Pesan
Pilih ‘Save
STC-3.7 V – – – – V – ‘Pasien
& Print /
belum
Ctrl+R
dipilih’
Pilih ‘Tutup Halaman
STC-3.8 V – – – – – V
Window / Registrasi
Esc’ ditutup
 

Penutup

Testing menggunakan metode pengujian Black box adalah salah

satu cara untuk mengetest sejauh mana sistem dapat digunakan
dengan baik sesuai dengan yang telah di rencanakan dan di disain
sebelumnya. Tahap testing juga diharapkan dapat memberikan
panduan kepada tester (penguji) untuk melakukan pengujian
aplikasi agar bugs dan errors dapat ditemukan dan diminimalisasi,
sebagai bahan masukan dan evaluasi, salah satu dokumen
pendukung dalam proyek IT, dan sebagai dasar untuk
pengembangan selanjutnya.

Daftar Pustaka :

http://www.google.co.id/url?sa=t&rct=j&q=skenario
%20test&source=web&cd=2&ved=0CCYQFjAB&url=http%3A
%2F%2Fo-nick.googlecode.com%2Ffiles
%2FKelompok_3_ONick_Test_Case%2520dan
%2520Screenshot
%2520JUnit.docx&ei=DfWOT6icJpHPrQeW2dy4CQ&usg=AFQj
CNHroxFQsxePM0rO2XLKJUcfdwyVbw&cad=rja

http://www.gangsir.com%2Fdownload%2F8-Langkah-
langkahPengujiandanEvaluasiPirantiLunak.pdf&ei=HZqLT_qILI
TmrAe7ttXWCw&usg=AFQjCNFsABAqzK73f3Otgr8yXtnNwl9NC
A&cad=rj