DEBUGGING
Debugging adalah sebuah metode yang dilakukan oleh para pemrogram dan pengembang
perangkat lunak untuk mencari dan mengurangi bug,
atau kerusakan di dalam sebuah program komputer atau perangkat keras sehingga perangkat tersebut
bekerja sesuai dengan harapan. Debugging cenderung lebih rumit
ketika beberapa subsistem lainnya terikat dengan ketat dengannya, mengingat
sebuah perubahan di satu sisi, mungkin dapat menyebabkan munculnya bug lain
di dalam subsistem lainnya.
Kenapa dinamakan bug?
Tahun 1945 sewaktu
ukuran komputer masih sebesar kamar, pihak militer Amerika Serikat menggunakan komputer yang
bernama “Mark 1″. Suatu hari komputer ini tidak berfungsi dengan semestinya,
setelah komputer itu diperiksa ternyata ada suatu bagian perangkat keras di
mana terdapat serangga yang tersangkut. Setelah serangga itu diangkat dari
perangkat keras, komputer dapat berfungsi dengan baik. Maka sejak saat itu
kata bug lekat dengan masalah-masalah pada komputer. Debugging adalah proses
menghilangkan bug dari suatu program.
Pengujian
perangkat lunak adalah proses yang dapat direncanakan dan ditentukan secara
sistematis. Desain test case dapat dilakukan, strategi dapat ditentukan, dan
hasil dapat dievaluasi berdasarkan harapan-harapan yang ditentukan sebelumnya.
Debugging terjadi sebagai akibat dari pengujian yang berhasil.
Jika test case mengungkap kesalahan, maka debugging adalah proses yang
menghasilkan penghilangan kesalahan. Perekayasa perangkat lunak yang
mengevaluasi hasil suatu pengujian sering dihadapkan pada indikasi “simtomatis”
dari suatu masalah pernagkat lunak, yaitu bahwa manisfestasi eksternaldari
kesalahan dan penyebab internal kesalahan dapat tidak memiliki hubungan yang
jelas satu dengan lainnya. Proses mental yang dipahami secara buruk yang
menghubungkan sebuah symptom dengan suatu penyebab disebut debugging.
Proses
Debugging
Debugging
bukan merupakan pengujian, tetapi selalu terjadi sebagai bagian akibat dari
pengujian. Proses debungging dimulai dengan eksekusi terhadap suatu test case.
Hasilnya dinilai, dan ditemukan kurangnya hubungan antara harapan dan yang
sesungguhnya. Dalam banyak kasus, data yang tidak berkaitan merupakan gejala
dari suatu penyebab pokok tetapi masih tersembunyi, sehingga perlu ada koreksi
kesalahan.
Proses
debugging akan selalu memiliki salah satu dari dua
hasil akhir berikut:
1.
Penyebab akan ditemukan, dikoreksi, dan
dihilangkan, atau
2.
Penyebab tidak akan ditemukan.
Dalam
kasus yang terakhir, orang yang melakukan debugging mungkin mencurigai suatu
penyebab, mendesainsuatu test case untuk membantu kecurigaannya, dan bekerja
untuk koreksi kesalahan dengan gaya yang iterative.
Beberapa karakteristik
bug memberi kunci :
1.
Gejala dan penyebab dapat jauh secara
geografis, dimana gejala dapat muncul didalam satu bagian dari suatu program,
sementara penyebab dapat ditempatkan pada suatu sisi yang terlepas jauh.
2.
Gejala dapat hilang (kadang-kadang) ketika
kesalahan yang lain dibetulkan.
3.
Gejala dapat benar-benar disebabkan oleh
sesuatu yang tidak salah (misalnya pembulatan yang tidak akurat).
4.
Simpton dapat disebabkan oleh kesalahan manusia
yang tidak dapat dengan mudah ditelusuri.
5.
Gejala dapat merupakan hasil dari masalah
timing, dan bukan dari masalah pemrosesan.
6.
Mungkin sulit untuk mereproduksi kondisi input
secara akurat (misalnya aplikasi real time dimana pengurutan input tidak
ditentukan).
7.
Gejala dapat sebentar-sebentar. Hal ini sangat
umum pada system yang embedded yang merangkai perangkat lunak dan perangkat
keras yang tidak mungkin dilepaskan.
8.
Gejala dapat berhubungan dengan penyebab yang
didistribusikan melewati sejumlah tugas yang bekerja pada prosesor yang berbeda.
Selama
debugging, kita menemukan kesalahan-kesalahan mulai dari gangguan yang halus
(missal format output yang tidak betul) sampai katrastropis (misalnya kegagalan
system yang menyebabkan kerusakan fisik atau ekonomis).
Sebagai
akibat dari peningkatan keslahan, jumlah tekanan untuk menemukan kesalahan juga
bertambah. Sering kali tekanan memaksa seorang pengembang perangkat lunak untuk
membetulkan keslahan dan pada saat yang sama memunculkan lagi dua kesalahan
baru.
Pertimbangan
Psikologis
Sayangnya
muncul banyak bukti bahwa kekuatan debugging adalah sifat bawaan manusia.
Banyak orang yang cakap dalam hal ini, sementara banyak juga yang tidak.
Menanggapi aspek manusia dari debugging. Shneiderman [SHN80] menyatakan :
Debugging
merupakan salah satu dari berbagai bagian pemrograman yang membuat lebih
frustasi. Debugging memiliki elemen pemecahan masalah atau pengganggu otak,
yang bersama dengan penghindaran kesadaran bahwa Anda melakukan suatu
kesalahan. Kekhawatiran yang meningkat dan keengganan untuk menerima, kesalahan
akan meningkatkan kesulitan tugas. Sayangnya, ada keluhan yang sangat mendalam
mengenai pembebasan dan pengurangan ketegangan ketika pada akhirnya bug ………
dikoreksi.
Meskipun
mungkin sulit untuk mempelajari debugging, sejumlah pendekatan terhadap masalah
tersebut dapat diusulkan. Kita akan melihat dalam sub bab selanjutnya.
Pendekatan-pendekatan
Debugging
Tanpa
memperhatikan pendekatan yang diambil, debugging memiliki satu sasaran yang
diabaikan, untuk menemukan dan mengkoreksi penyebab kesalahan perangkat lunak.
Sasaran tersebut direalisasi dengan suatu kombinasi evaluasi yang sistematis,
intuisi, dan keberuntungan.
Bradley
(BRA85) menggambarkan pendekatan Debugging dengan cara berikut :
Debugging
adalah sebuah aplikasi langsung dari metodekeilmuan yang telah dikembangkan
selama 2500 tahun. Dasar dari debugging adalah meletakkan sumber-sumber masalah
(penyebab) dengan partisi biner melalui hipotesis kerja yang memperkirakan
nilai-nilai baru yang akan diuji.
Ambillah contoh
non-perangkat lunak sederhana, yaitu :
Lampu
dirumah saya tidak bekerja. Bila tidak ada yang bekerja didalam rumah itu,
penyebabnya tentu pada pemutus rangkaian utama atau sebab dari luar. Saya
melihat sekeliling untuk melihat apakah lampu para tetangga juga mati. Saya memasukkan
lampu yang dicurigai kedalam soket yang bekerja dan menyelidiki lampu rangkaian
yang dicurigai. Begitulah berbagai pilihan hipotesa dan pengujian.
Secara
umum, tiga kategoti pendekatan debugging dapat diusulkan (MYE79) :
1.
1. Gaya
yang kasar (Brute force)
Kategori
debugging brute force mungkin merupakan yang paling umum dan
metode yang paling efisien untuk mengisolasi penyebab kesalahan perangkat
lunak. Kita mengaplikasikan metode debugging brute force bila
semua yang lain telah gagal. Dengan menggunakan filosofi ”biarkan komputer
menemukan kesalahan”, tempat sampah memori dipakai, penelusuran runtime
dilakukan, dan program dibebani dengan statemen WRITE. Kita mengharapkan bahwa
dimanapun didalam rawa informasi yang diproduksi, kita akan menemukan suatu
kunci yang akan membawa kita kepada penyebab kesalahan. Meskipun banyaknya
informasi yang dihasilkan pada akhirnya akan membawa kita meraih sukses, lebih
sering dia menyebabkan kita menghambur-hamburkan usaha dan waktu. Kita harus
memikirkannya terlebih dahulu.
1.
2. Penelusuran balik (backtracking)
Backtracking adalah pendekatan debugging yang sangat umum yang dapat
digunakan secara sukses didalam program yang kecil. Mulai pada sisi dimana
suatu gejala diungkap, kode sumber ditelusuri balik (secara manual) samapai
sisi penyebab ditemukan. Sayangnya, bila jumlah baris sumber bertambah, maka
jumlah jalur balik potensial dapat sangat banyak.
1.
3. Eliminasi
penyebab
Cause
elimination dimanisfestasikan oleh induksi atau
deduksi serta mengawali konsep partisi biner. Data yang berhubungan
dengan kejadian kesalahan dikumpulkan untuk mengisolasi penyebab potensial.
Hipotesis penyebab dibuat dan data digunakan untuk membuktikan penolakan hipotesis
tersebut. Sebagai alternatif, daftar semua penyebab yang mungkin dikembangkan
dan dilakukan pengujian untuk mengeliminasi masing-masing kesalahan. Jika
pengujian awal menunjukkan bahwa suatu hipotesis penyebab memberikan gambaran
hasil yang jelas, maka data itu disaring sebagai usaha untuk mengisolasi bug.
Masing-masing
pendekatan debugging tersebut dapat ditambah dengan piranti debugging. Kita
dapat mengaplikasikan berbagai kompiler debugging yang luas, bantuan debugging
yang dinamis (tracer), generator test case, ruang sisa memori dan peta
cross-reference. Namun piranti bukanlah pengganti bagi evaluasi yang
berhati-hati yang didasarkan atas dokumen desain perangkat lunak yang lengkap
dan kode sumber yang jelas.
Sekali
bug ditemukan, bug harus dibetulkan. Tetapi seperti telah kita catat, koreksi
terhadap suatu bug dapat memunculkan kesalahan lain sehingga lebih banyak
merugikan daripada menguntungkan.
Van
Vleck (FAN89) mengusulkan tiga pertanyaan sederhana yang harus diajukan kepada
perekayasa perangkat lunak sebelum melakukan koreksi yang menghilangkan
penyebab suatu bug, yaitu :
1.
1. Apakah
penyebab bug direproduksi didalam bagian lain program tersebut?
Dalam
berbagai situasi, kesalahan program disebabkan oleh sebuah contoh logika yang
keliru yang dapat dibuat ulang ditempat lain. Pertimbangan eksplisit dari
contoh logika tersebut akan menghasilkan penemuan kesalahan yang lain.
1.
2. Apa
”bug selanjutnya,” yang akan dimunculkan oleh perbaikan yang akan dibuat?
Sebelum
koreksi dibuat, kode sumber (atau lebih baik,desain) harus dievaluasi untuk
memperkirakan pemasangan logika dan struktur data. Bila koreksi akan dilakukan
pada bagian program yang akan dirangkai, maka harus ada perhatian khusus bila
banyak perubahan dilakukan.
1.
3. Apa
yang dapat kita lakukan untuk menghindari bug ini didalam tempat pertama?
Pertanyaan ini merupakan langkah pertama untuk
membangun pendekatan jaminan kualitas perangkat lunak statistik. Bila kita
mengkoreksi proses dan produk, bug akan dihilangkan dari program yang ada dan
dapat dieliminasi dari semua program selanjutnya.
(Sumber : http://revoluthion.wordpress.com/2009/10/07/debugging-pengertian/
)
