1. Kenapa perlu dilakukan pengujian terhadap perangkat lunak yang dikembangkan?

2. Buatlah contoh pengujian pada perangkat lunak berorientasi objek!

3. Berikan contoh penggunaan ulang perangkat lunak dalam mengembangkan aplikasi sistem informasi
akademik

1. Untuk memastikan bahwa software yang di hasilkan sesuai dengan kebutuhan (requirement) yang
sebelumnya di tentukan.
Serta 3 alasan lainnya, yaitu :
-Apapun bisa terjadi. Sebelum Anda memeriksa atau melakukan testing pada software atau aplikasi
yang telah dibuat, ingatlah bahwa kesalahan atau kekurangan dapat saja terjadi.
-Aplikasi baik saja tidak cukup, aplikasi Anda harus yang terbaik. Ingat juga bahwa bisnis yang
selalu menghadirkan produk dalam hal ini aplikasi atau software, yang terbaik itu selalu dicapai setelah
perjalanan yang panjang dengan berbagai macam pengujian.
-Kepuasan end user adalah segalanya. Tentu Anda tidak pernah tahu bagaimana pengguna akan
mencoba untuk melihat dan menggunakan software atau aplikasi Anda. Pengujian yang Anda lakukan
dapat membantu meyakinkan Anda dan tentu saja akan memberi kepuasan terhadap pengguna software
Anda bahwa yang mereka gunakan itu sesuai dengan harapan.

2. Pengujian Perangkat Lunak Berorientasi Objek

Tim RPL Teknik Informatika

Pengujian 
• Pengujian adalah proses menganalisa suatu entitas software untuk mendeteksi perbedaan antara
kondisi yang ada dengan kondisi yang tidak diinginkan (defect/errors/bugs) dan mengevaluasi fitur-
fitur dari entitas software (standar ANSI/IEEE 1059)

Tujuan
 • Menemukan sebanyak mungkin masalah (error)
 • Tujuan dari menemukan masalah adalah memperbaikinya
 • Sebuah pengujian yang sukses adalah menemukan kesalahan yang belum ditemukan.

Akktivitas Pengembangan PL
Aktivitas Pengujian
Peran tiap Proses Pengujian
Testing vs. Debugging
 • Pengujian (testing) berbeda dengan debugging – Debugging dilakukan bila sudah ditemukan suatu
kesalahan, dan tujuannya mencari sumber kesalahan (fault atau defect) – Debugging tetap menjadi
bagian dari strategi pengujian Failure, Error, Fault and Defect
 • Error – Error adalah status dari sistem – Status error ini bisa menyebabkan kegagalan jika tidak ada
perbaikan • Fault – Fault adalah sumber dari error 
• Defect – Sinonim dengan Fault – Sering disebut juga bug
 • Failure – Kegagalan (failure) terjadi kalau ada perilaku dari sistem yang tidak sesuai dengan
permintaan di spesifikasi sistem
Kriteria Pengujian yang Baik 
• Memiliki kemungkinan tinggi untuk menemukan error
 • Tidak redundan (duplikasi yang tidak perlu) 
• Pilih teknik yang terbaik – Atau tepat sesuai dengan karakteristik software yang diuji 
• Tidak terlalu sederhana juga tidak terlalu kompleks

Strategi Pengujian PL untuk arsitektur OO

 • ‘testing-in-the-small’ hingga ‘testing-in-the-large’ – Fokus pada pengujian tiap kelas termasuk atribut
dan operasi – Dilanjutkan pengujian komunikasi / kolaborasi antar kelas
 • Unit Testing 
• Integration testing 
• Validation testing
 • System Testing
Unit Testing 
• Unit terkecil yang diujikan adalah enkapsulasi class atau objek, bukan modul
 • Ujicoba lengkap keseluruhan class meliputi : – Menguji seluruh operasi yang berhubungan dengan
objek – Mengevaluasi semua atribut objek – Melatih objek dalam semua kemungkinan
• Metode Unit Testing – Ujicoba berbasis kesalahan (fault-based testing) – Ujicoba acak (random
testing) – Ujicoba Partisi (partition testing)

Integration Testing
 • Software OO tidak mempunyai struktur kendali hirarkhi, strategi integrasi konvensional (top-down /
bottom-up integration) tidak bisa dilakukan. 
• Fokus pada kelompok class yang berkolaborasi atau berkomunikasi dalam beberapa cara.
 • Strategi Integration Testing: – Thread-based Testing: mengintegrasikan sekumpulan class yang
dibutuhkan dalam merespon satu masukan atau event terhadap sistem. – Used-based Testing: dimulai
dengan uji independen, setelah itu dilanjutkan dengan melakukan testing terhadap dependent class yang
menggunakan independent class yang telah dites
Validation Testing 
• Fokus pada masukan / tindakan pengguna yang terlihat dan pengguna dapat mengenali output dari
sistem
 • Pengujian validasi didasarkan pada skenario use-case, model perilaku objek, dan diagram alur event
dibuat dalam model OOA
 • Pengujian Black box konvensional dapat digunakan untuk pengujian validasi

System Testing 
• Fokus pada integrasi sistem secara keseluruhan 
• Pengujian alpha / Beta: Fokus pada pengguna (bagaimana mereka menggunakan) 
• Recovery Testing: Software dibuat 'gagal' dan dilihat apakah proses pemulihan sudah dapat
dilakukan. Contoh: software yang memanfaatkan internet melihat perilaku pemulihan ketika internet
tiba-tiba turun. 
• Pengujian keamanan: Pastikan apakah mekanisme perlindungan sudah melindungi 'penetrasi‘ 
• Stress testing: Sistem diuji bagaimana ketika dihadapkan dengan permintaan penggunaan sumber
daya yang melebihi jumlah normal, atau frekuensi atau volume yang normal 
• Pengujian kinerja: Menguji kinerja software ketika dijalankan pada konteks tertentu

3. PENERAPAN REKAYASA ULANG ITERATIF PADA SISTEM INFORMASI AKADEMIK FTIF

ITS SURABAYA
Tujuan penelitian ini adalah menerapkan model Rekayasa Ulang Iteratif pada studi kasus Sistem
Informasi Akademik FTIF ITS Surabaya. Penelitian ini menerapkan proses rekayasa ulang pada
domain aplikasi sistem warisan. Proses rekayasa ulang ini dilakukan secara iteratif, bertahap dengan
sedikit fungsi atau prosedur pada setiap waktunya dan
sesingkat mungkin. Sedangkan manfaat dari Rekayasa Ulang Iteratif adalah perubahan sistem warisan
ke sistem yang baru (tujuan) tidak mengganggu pengguna sistem dalam melakukan proses bisnis.
Dalam penelitian ini, permasalahan yang dibahas adalah:
1. bagaimana melakukan proses rekayasa ulang dengan metode Iteratif pada studi kasus Sistem
Informasi Akademik FTIF ITS Surabaya; dan
2. bagaimana menganalisis proses Rekayasa Ulang Iteratif dimana sistem tetap berjalan walaupun
proses rekayasa ulang masih berlangsung.