Heart Bleed (Debug Internet)
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:
Penyebab akan ditemukan, dikoreksi, dan
dihilangkan, atau
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 :
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.
Gejala dapat hilang (kadang-kadang) ketika
kesalahan yang lain dibetulkan.
Gejala dapat benar-benar disebabkan oleh
sesuatu yang tidak salah (misalnya pembulatan yang tidak akurat).
Simpton dapat disebabkan oleh kesalahan
manusia yang tidak dapat dengan mudah ditelusuri.
Gejala dapat merupakan hasil dari masalah
timing, dan bukan dari masalah pemrosesan.
Mungkin sulit untuk mereproduksi kondisi
input secara akurat (misalnya aplikasi real time dimana pengurutan input tidak
ditentukan).
Gejala dapat sebentar-sebentar. Hal ini
sangat umum pada system yang embedded yang merangkai perangkat lunak dan
perangkat keras yang tidak mungkin dilepaskan.
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. 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.
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.
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. 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.
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.
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/