Debugging (pengertian)

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.

Bug dengan terjemahan langsung ke bahasa Indonesia adalah serangga atau kutu. Bug
merupakan suatu kesalahan desain pada suatu perangkat keras komputer atau perangkat lunak
komputer yang menyebabkan peralatan atau program itu tidak berfungsi semestinya. Bug
umumnya lebih umum dalam dunia perangkat lunak dibandingkan dengan perangkat keras.

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.

Kegunaan Debug – Cara Mengenali dan Memperbaiki Bug

Banyak manfaat yang bisa diraih dengan melakukan debug pada blog wordpress Anda.
Disamping meningkatkan performa blog juga dapat menjaga kestabilan engine wordpress
tetap up to date. Tidak perlu harus memiliki pengetahuan khusus sebenarnya untuk
memperbaiki bug wordpress, yang penting mengerti bahasa inggris, atau jika tidakpun
cukup pegang kamus saja. Kenapa demikian? Kalau saya bilang sih, debug itu gampang-
gampang susah (lebih banyak gampangnya ya ). Karena sebetulnya wordpress sendiri

memiliki fitur debugging dan saran (rekomendasi) untuk memperbaikinya. Fitur ini tersimpan
pada file wp-includes/functions.php
Artikel ini adalah lanjutan dari artikel sebelumnya mengenal semua tentang debug yang
merupakan uraian mendasar dan singkat namun cukup lengkap mengenai debug. Dari mulai
mengenal apa itu bug, debug, fungsi dan tujuannya serta bagaimana cara aman melakukan
debug. Bagi yang sudah membacanya mari lanjutkan ke tahap selanjutnya untuk mengenali
dan memperbaiki bug wordpress.

Kegunaan Debug – Cara Mengenali dan Memperbaiki Bug

Kegunaan dan Manfaat Debug

Untuk semakin memahami arti pentingnya membersihkan wordpress dari bug (debugging),
berikut beberapa kegunaan dan manfaat yang bisa kita dapatkan:

 Dengan debug dapat menghindari kesalahan penulisan kode seperti kode belum
ditutup, fungsi yang salah dan lain-lain.

 Mengetahui fungsi yang tidak terpakai (deprecated) atau mengalami perubahan pada
sistem terbaru.

 Menyesuaikan addon tambahan seperti plugin dan theme dengan sistem core terbaru.

 Debug berguna untuk menyeleraskan CMS yang dipakai (mis. wordpress) dengan
environtment-nya (php, mysql, server dll.).

 Menjaga dan meningkatkan keamanan sistem.

Cara Debug WordPress

Perlu diketahui, selain bug muncul dari wordpress core, faktor dominan penyebab bug
adalah plugin dan theme (template). Hal ini disebabkan karena memang plugin dan tema
bersumber dari pengembang yang berbeda. Sehingga jika terjadi perubahan atau upgrade pada
mesin utama wordpress, maka tidaklah demikian halnya dengan plugin atau tema. Jika para
developer tidak menyesuaikannya mau tidak mau kita harus memperbaikinya sendiri. Adapun
tahapan-tahapan yang bisa kita tempuh untuk debug wordpress ini diantaranya:

1. Gunakan cara aman debug, hanya admin yang boleh mengetahui error dan tidak
diketahui umum. Ikuti langkahnya pada 2 Cara Aman debug.

2. Prioritaskan memperbaiki bugs pada tema template yang digunakan.

3. Nonaktifkan plugin satu persatu untuk mengetahui dari plugin mana bug muncul.

4. Ketahui jenis bug, kode yang tidak terpakai (obsolete), deprecated dan lainnya.

5. Contoh: wp_specialchars berubah menjadi esc_html clean_url berubah menjadi

esc_urlb get_the_author_email berubah menjadi get_the_author_meta('email')
register_sidebar_widget berubah menjadi wp_register_sidebar_widget
register_widget_control berubah menjadi wp_register_widget_control
dan seterusnya… lihat lebih detail di sini

6. Perhatikan pesan error yang ditampilkan dan ikuti saran memperbaikinya.

WordPress sudah dilengkapi dengan fitur untuk mengetahui kode yang deprecated dan
memberikan alternatif penggantinya (wp-includes/functions.php). Contoh jika muncul
pesan error seperti ini:

PHP Notice: wp_specialchars is deprecated since version 2.8! Use esc_html() instead.
in /home/akunku/public_html/wp-includes/functions.php on line 2824

Artinya: kode “wp_specialchars” sudah deprecated dan tidak seharusnya dipakai, tapi
ganti kode itu dengan esc_html. Jika sudah dirubah kemudian pesan tersebut hilang itu

artinya bug sudah diperbaiki dan Anda boleh senyum karenanya

7. Lakukan langkah yang sama sampai semua pesan error hilang, dan setelah itu jangan
lupa untuk menghapus file error_log pada folder utama blog Anda untuk menghindari
 usilnya tangan-tangan jahil yang mungkin mencari informasi kelemahan blog Anda.
error_log ini dibuat otomatis oleh php setiap kali terjadi kesalahan pada sistem

Perlu diketahui pula, pada setiap pesan error selalu terdapat notifikasi letak baris kode error
tersebut (on line xxx). Untuk error yang terjadi pada file spesifik, misalkan terjadi pada
/home/akunku/public_html/wp-content/plugins/plugin-x.php on line xxx, maka Anda dapat
langsung memperbaiki error tersebut sesuai dengan notifikasi itu. Namun seringkali muncul
pesan error “menyalahkan” file wp-includes/functions.php (seperti langkah 5 di atas). Nah,
jika demikian jangan “selalu percaya” dengan pesan error tersebut. Bukan berarti kesalahan
ada pada file wp-includes/functions.php. Untuk memperbaiki dan menemukan errornya, lihat
di mana pesan error itu berada, kadang kesalahan tidak terlihat pada browser namun
“ngumpet”, maka cari juga pesan error pada source html-nya. Dan jangan lupa untuk
menonaktifkan plugin dan mengaktifkannya lagi, dari situ akan terlihat penyebab errornya.
Demikian, ulasan saya kali ini yang terinspirasi dari pengalaman saya sendiri dalam
memperbaiki plugin pertama saya 4 in 1 plugin. Semoga dapat membantu dan bermanfaat.