Anda di halaman 1dari 13

LAPORAN PENGUJIAN SETELAH UTS

Disusun Oleh :

1. Adrianus Ardi (201901001)

2. Maria Lusia Bengang (201901009)

3. Mathias B. Boliona (201901018)

Dosen Pengampuh :

Endang Setyawati, M.Kom

SISTEM INFORMASI

STIKOM YOS SUDARSO PURWOKERTO

2022
A. Pengujian Integrasi

1.1 Pengertian
Pengujian Integrasi adalah sebuah teknis yang sistematik untuk mengonstruksi
struktur program seiring dengan mengabungkan fungsi program dengan
antarmukanya. Pengujian terintegrasi bertujuan untuk mempergunakan komponen
unit program yang sudah diuji dan membangun struktur seperti yang telah didesain
sebelumnya.
Pengujian integrasi sebaiknya dilakukan dengan cara bertahap, tidak dilakukan secara
satu tahap langsung diakhiri untuk menghindari kesulitan penelusuran jika terjadi
kesalahan (error). pengujian integrasi lebih pada pengujian penggabungan dari dua
atau lebih unit pada perangkat lunak. Setelah pengujian integrasi maka dilakukan
pengujian sistem dimana unit-unit proses yang sudah dintegrasi diuji dengan
antarmuka yang sudah dibuat sehingga pengujian ini dimaksudkan untuk menguji
sistem perangkat lunak secara keseluruhan dan diuji secara satu sistem (tidak terpisah-
pisah lagi).
Integrasi secara bertahap (incremental integration) merupakan kebalikan dari
pendekatan “big bang”. Progam di konstruksi dan diuji secara bertahap sehingga
kesalahan (error) yang terjadi lebih mudah diketahui letak kesalahannya dan di
perbaiki. Antarmuka juga harus diuji secara lengkap sehingga diperlukan sebuah
pengujian yang sistematis untuk menguji antarmuka beserta fungsi-fungsinya.

 Integrasi non-incremental:Membangun program dengan mendekatan “big-


bang”. Yaitu semua modul program digabung menjadi program utama
kemudian diuji.
 Integrasi incremental :Membangun program dengan cara menguji per modul
kecil / per segmen, kemudian digabung menjadi menu utama

1.2 Tujuan
Tujuan Integration Testing
 Memeriksa apakah aplikasi berfungsi sesuai yang dengan apa diharapkan
 Memeriksa kinerja dari aplikasi yang dihasilkan
 Mengetes kehandalan dari struktur program yang sudah dirancang sebelumnya

Disini menggunakan integrasi incremental yaitu membangun program dengan cara


menguji per modul kecil atau per segmen, kemudian digabung menjadi menu utama.
Pada pengujian integrasi ini terdapat beberapa jenis atau macam yaitu :
a. Pengujian Big Bang
Pengujian Big Bang Integrasi merupakan strategi pengujian integrasi
dimana semua unit terkait sekaligus, sehingga sistem yang lengkap. Saat
ini jenis strategi pengujian diadopsi, sulit untuk mengisolasi ditemukannya

kesalahan, karena tidak ada perhatian untuk memverifikasi interface di


masing-masing unit.

b. TOP DOWN Integration


Adalah pengujian yang menggunakan pendekatan inkremental terhadap
Struktur program. Pengujian berlangsung dari atas ke bawah, mengikuti
aliran kontrol atau struktur arsitektur.

Keterangan :
Setelah user berhasil login terdapat menu utama/halaman utama
Beranda/Dashboard, home dan profil.
1. Profil User , berisi keterangan identitas diri dan foto.
2. Halaman Beranda , Merupakan halaman awal yang ditampilkan ketika
user telah berhasil masuk kedalam sistem / telah berhasil login.

c. BOTTOM UP Integration

Pengujian integrasi dari bawah keatas (bottom-up integration) memulai


pengujian dari modul yang paling kecil kemodul yang lebih besar. Pengujian
dari bawah keatas sering dilakukan untuk pengembangan perangkat lunak
yang tidak menggunakan alur prototipe sehingga perangkat lunak dibangun
dari modul-modul yang kecil ke modul-modul yang besar sesuai dengan
hirarki pemakainya.
Integrasi Bottom-Up, dimulai dengan pengujian modul atomik yaitu modul
program pada tingkat paling rendah pada struktur program. Karena
diintegrasikan dari bawah ke atas maka pemrosesan yang diperlukan selalu
ada dan kebutuhan script dapat dieliminasi.

Hasil Yang Diperoleh Berdasarkan pengujian yang telah dilakukan


ditemukan kesalalahan sistem yang ada pada sistem yakni Kepala Sekolah
tidak dapat melihat surat yang diarsipkan pada menu galeri surat.

d. Regresion Integrasi
Pengujian regresi merupakan eksekusi ulang untuk memastikan bahwa
perubahan tidak menimbulkan efek samping. Setiap modul baru
ditambahkan sebagai bagaian dari integrasi maka kondisi perangkat lunak
menjadi berubah. Hal ini mungkin saja menyebabkan masalah pada
fungsionalitas yang sudah diuji sebelumnya.

Pengujian regresi lebih sesuai menggunakan tiga kelompok kasus


pengujian sebagai berikut :
1. Kelas kasus uji yang berisi contoh kasus pengujian yang dapat menguji
semua fungsi perangkat lunak.
2. Kelas kasus uji yang berisi kasus tambahan yang fokus pada tambahan
modul baru untuk diuji.
3. Kelas kasus uji yang berisi kasus yang foks pada komponen atau modul
baru atau yang mengalami perubahan.

Tujuan Integration Testing


1. Memeriksa apakah aplikasi berfungsi sesuai yang dengan apa diharapkan.
2. Memeriksa kinerja dari aplikasi yang dihasilkan.
3. Mengetes kehandalan dari struktur program yang sudah dirancang
sebelumnya.

Tidak ada efek samping pada sistem jika kita menambahkan suatu modul baru
kedalam sistem.

e. Pengujian Smoke

Smoke Testing adalah jenis sofware testing yang dilakukan setelah software di
build/dibangun untuk memastikan bahwa fungsi penting dari program bekerja
dengan baik. Tujuannya adalah untuk reject aplikasi yang sudah rusak sejak
awal development, sehingga tim QA tidak membuang-buang waktu
menginstal dan menguji aplikasi perangkat lunak.

Secara mendasar, pendekatan smoke testing terdiri dari aktifitas-aktivitas


berikut:

Komponen software yang telah ditranslasikan ke kode, diintegrasikan ke


“build”, yang terdiri dari semua file data, pustaka, modul yang digunakan lagi,
dan komponen yang dikembangkan yang dibutuhkan untuk menerapkan satu
atau lebih fungsi produk.Serangkaian tes didisain untuk menghasilkan
kesalahan yang akan membuat “build” tetap berfungsi sebagaimana mestinya.
Intensi harus mencakup “show stopper” kesalahan yang mempunyai
kemungkinan terbesar membuat proyek software mengalami keterlambatan
dari jadual.“Build” diintegrasikan dengan “build” lainnya dan keseluruhan
produk yang dilakukan smoke tes harian. Pendekatan integrasi dapat top-down
atau bottom-up.

 Smoke testing dapat dikarakteristikan sebagai suatu strategi integrasi


yang berputar.
Software dibangun ulang (dengan komponen-komponen baru yang
ditambahkan) dan diperiksa setiap hari.Smoke testing menyediakan
sejumlah keuntungan bila digunakan pada suatu proyek rekayasa yang
mempunyai waktu kritis dan komplek.
 Smoke testing dapat dikarakteristikan sebagai suatu strategi integrasi
yang berputar sebagai berikut :
Meminimalkan resiko integrasi. Karena dilakukan per hari,
ketidakcocokan dan “show stopper” errors lainnya dapat dilihat per
hari, sehingga terjadinya perubahan jadual akibat erjadinya errors
serius dapat dikurangi.Meningkatnya kualitas produk akhir. Karena
pendekatan berorientasi integrasi, smoke tes melingkupi kesalahan
fungsional dan arsitektural dan kesalahan disain tingkat komponen.
Kesalahan ini dapat dibenahi secepatnya, kualitas yang lebih baik
didapatkan.
 Smoke testing dapat dikarakteristikan sebagai suatu strategi integrasi
yang berputar.
Diagnosa kesalahan dan koreksi disederhanakan. Seperti halnya semua
pendekatan integration testing, kesalahan yang ditemukan selama
smoke testing diasosiasikan dengan “peningkatan software baru”,
dimana software telah ditambahkan “build” yang mungkin
menyebabkan ditemukannya kesalahan baruPenilaian proses kerja
lebih mudah. Dengan lewatnya hari, lebih banyak software telah
diintegrasi dan lebih banyak yang telah didemonstrasikan bekerja. Hal
ini meningkatkan moral tim dan memberi manajer indikasi bagus
bahwa proses kerja telah dilaksanakan.

Hasil uji dari fungsi mencetak laporan tidak ditemukan kesalahan.

B. Pengujian Sistem
1.1 Pengertian
Pengujian sistem adalah pengujian berdasar spesifikasi / kebutuhan perangkat lunak.
Pengujian ini biasanya dilakukan berdasarkan spesifikasi yang dianalisa secara
informal dan manual. Pengujian ini tidak memiliki metode dan kriteria formal
sehingga hasil pengujiannya bisa menjadi tidak konsisten dan rancu.
Berikut adalah pengujiannya :
a. Pengujian White Box
White box testing atau yang dapat diartikan menjadi “pengujian kotak
putih” adalah pengujian yang dilakukan untuk menguji perangkat lunak
dengan cara menganalisa dan meneliti struktur internal dan kode dari
perangkat lunak. Lain halnya dengan black box testing yang hanya melihat
hasil input dan output dari perangkat lunak, pengujian white box testing
berfokus pada aliran input dan output dari perangkat lunak.

b. Basis Path Testing: Flow Graph


 Basic Path Testing merupakan uji coba yang diusulkan oleh Tom
McCabe
 Digunakan untuk mengukur kompleksitas logis dari desain procedural
dan menggunakannya sebagai pedoman untuk menetapkan himpunan
basis dari semua jalur eksekusi.
 Test case yang dapat digunakan untuk mengerjakan basis set yang
menjmin pengerjaan setiap perintah min 1x selma uji oba.
 Tujuannya meyakinkan bahwa himpunan test case akan menguji setiap
path pada program paling sedikit satu kali.
 Titik awal untuk path tetinh adalah suatu program flow graph yang
menunjukan node-node yang menyatakan alur kontrol.

Flow Graph merupakan grafik yang digunakan untuk menggambarkan


aliran kontrol dari sebuah program. Berbeda dengan flowchart, grafik pada
flow graph tidak menggambarkan secara detail proses yang terjadi pada
setiap blok notasi. Jenis notasi pada flowchart digambarkan secara berbeda
(diamond, persegi panjang, jajar genjang, dst) untuk menggambarkan
proses yang berbeda, sedangkan notasi pada flow graph hanya diwakili
oleh sebuah notasi lingkaran.
Program flow Graphs
 Mengambarkan alur kontrol setiap cabang ditujukan oleh path yang
terpisah dan loop kondisi node.
 Digunakan sebagai basis untuk menghitung cyclomatic complexity
 Cyclomatic complexity-jumlah cdges-jumlah node +2
 Cyclomatic compexity menyatakan jumlah test untuk menguji
control statments.
1. Pengujian Basic Path
2. Flowgraph Fungsi Login
Keterangan : REGION = R1, R2, R3
PREDIKAT = P1, P2

3. Cyclomatic Complexity

Berdasarkan gambar flowgraph sebelumnya maka dapat dihitung kompleksitas


cyclomatic proses dengan menggunakan rumus:

 V (G) = E – N + 2
 V (G) : cyclomatic complexity
 E : total jumlah edge atau jumlah busur
 N : total jumlah node atau jumlah simpul
 Dapat dihitung sebagai berikut :
 V (G) = 8 – 7 + 2
 V (G) = 3

Dari hasil perhitungan cyclomatic complexity di atas menunjukan jumlah pengujian yang
harus dijalankan dengan path sebagai berikut :

 Path 1 : 1 – 2 – 3– 5 – 7
 Path 2 : 1 – 2 – 3 – 4 – 1
 Path 3 : 1 – 2 – 3 – 5 – 6 – 1

Anda mungkin juga menyukai