Mengevaluasi Debuging Pada Aplikasi

Sederhana
 2 years ago

A. Mengevaluasi Debuging Pada Aplikasi Sederhana

     

Debugger atau perkakas pendebug adalah program komputer yang digunakan

untuk menguji dan mendebug program lainnya (program target). Kode yang
diujikan dijalankan pada sebuah instruction set simulator (ISS). Beberapa
debugger menawarkan dua mode operasi, yaitu simulasi parsial atau penuh,
untuk membatasi dampak.Kerusakan terjadi jika program tidak bisa melanjutkan
secara normal karena adanya bug pemrograman. Misalnya: program mungkin
akan mencoba menggunakan instruksi yang tidak tersedia pada CPU versi
terbaru atau mencoba mengakses memori terproteksi. (WIKI, 2016)

B. 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. (REVOLUTIONER, 2009)

   C. Teknik Debugging Dalam Membuat

Program
    Istilah debugging dalam programming, artinya adalah mencari kesalahan
algoritma dalam program yang sedang dibuat. Lho… bagaimana kita tahu ada
algoritma yang salah? Algoritma yang salah ini akan mengakibatkan hasil atau
output yang salah atau tidak seperti yang diharapkan. Istilah kesalahan ini sering
disebut ‘algoritmic error’.
Contoh sederhana dari algoritmic error ini adalah, misalkan kita akan membuat
program untuk menjumlahkan dua buah bilangan bulat, katakanlah A dan B. Dan
program yang dibuat adalah sebagai berikut (dalam Pascal):
program jumlahkan;
var a, b, hasil : integer;
begin
  write('Masukkan nilai A : ');
  readln(a);
  write('Masukkan nilai B : ');
  readln(b);
  hasil := a - b;
  write('Hasil penjumlahannya adalah : ',hasil);
end.
Apabila kita jalankan program di atas atau kita compile, maka tidak akan ada
error yang muncul, dalam hal ini syntax error (error yang terkait dengan aturan
penulisan program). Namun ketika dijalankan, dan misalkan kita masukkan nilai
A = 5 dan B = 4, maka hasil yang muncul adalah 1 (bukannya 9). Nah… inilah
yang dimaksud dengan algoritmic error, atau error yang disebabkan kesalahan
dalam langkah penyelesaian masalah.
Contoh sederhana lain, tapi hal ini tidak ada kaitannya dengan program, yaitu
tentang algoritma merebus mie instan  wah jadi laper nih…
Misalkan, diberikan algoritma untuk merebus mie instan sbb:
1. Buka bungkus mie
2. Siapkan panci dan taruh panci di atas kompor
3. Masukkan mie ke dalam panci
4. Nyalakan api kompor kira-kira 3 menit
5. Masukkan air mentah 2 gelas
6. Matikan kompor
7. Taruh mie ke dalam mangkuk
Nah… bagaimana pendapat Anda tentang algoritma di atas? Ya… kita akan
tetap mendapatkan output dari proses merebus mie, tapi tidak sesuai yang
diharapkan, yaitu mienya gosong dan airnya masih mentah  Mengapa
demikian? ya… hal ini karena ada langkah yang salah dalam merebus mie. Inilah
contoh algoritmic error.
So… saya harap Anda sudah tahu maksud algoritmic error. Sekarang, bila Anda
mendapatkan program yang Anda buat mengalami algoritmic error, apa yang
harus dilakukan? Ya… langkah satu-satunya adalah mencari letak proses yang
salah dalam algoritmanya. Nah… proses pencarian ini dinamakan debugging.
Mengapa disebut debugging?  Konon istilah tersebut muncul karena si
penemu kata ini pada waktu itu juga sedang mencari kesalahan program, namun
saking jengkelnya karena gak ketemu-ketemu, trus dia menyebutnya si ‘kutu’
atau ‘bug’. Kemudian istilah mencari si kutu program ini, sering disebut
‘debugging’.
Kalau kita mendapati syntax error, maka dapat dengan mudah dan cepat kita
akan menemukannya. Hal ini karena biasanya akan muncul warning adanya
penulisan yang salah dan biasanya akan disertai dengan nomor baris yang salah
tersebut. Nah… kalau algoritmic error, proses pencariannya tidak mudah.
So… bagi para mahasiswaku atau pengunjung setia blog ini, bila program Anda
dicompile tidak ada error, jangan bersenang-senang dahulu, karena tujuan
proses compile itu hanya mencari ada tidaknya syntax error. Siapa tahu program
Anda menyimpan si kutu 
OK… kita kembali ke laptop, eh salah… kembali ke teknik debugging 
Trus… sekarang bagaimana langkah debugging, bila program sudah jadi namun
hasilnya salah? Ya… untuk proses ini, Anda harus mengeceknya step by step
sesuai alur algoritma program yang Anda buat. Bagaimana cara mengeceknya?
Kalau saya pribadi, atau yang sering saya lakukan adalah menampilkan output di
setiap proses. Sedangkan proses setelah bagian yang sedang saya cek tersebut,
saya nonaktifkan atau saya buat menjadi komentar.
Perhatikan contoh berikut ini. Contoh ini baru saja saya gunakan untuk
menjelaskan teknik debugging ketika perkuliahan.
program cariKombinasi;
var n, m : integer;
   kombinasi : real;

function faktorial(x : integer) : real;

var i : integer;
   hasil : real;
begin
  hasil := 1;
  for i:=1 to x do
  begin
    hasil := hasil * i;
  end;
  faktorial := hasil;
end;

begin
  n := 3;
  m := 2;
  kombinasi := faktorial(n)/faktorial(n-m)*faktorial(m);
  write(kombinasi);
end.
Program di atas dibuat dengan tujuan untuk mencari hasil dari kombinasi n, m
atau C(n, m). Dari contoh di atas, dipilih n = 3 dan m = 2. Menurut perhitungan
kita, hasil yang benar dari kombinasi tersebut adalah 3. Namun apa yang terjadi
bila program di atas dijalankan? Ya… dari sisi syntax error tidak ada, namun
hasilnya adalah 12. Tentu hal ini salah.
Lantas… bagaimana mengetahui letak kesalahannya? Ya… untuk melakukan hal
ini, kita harus mengecek terlebih dahulu apakah function faktorial() sudah
berfungsi dengan baik atau belum. Untuk mengeceknya, ya… kita tambahkan
saja perintah write(faktorial(n));
begin
  n := 3;
  m := 2;
  write(faktorial(n));
  { kombinasi := faktorial(n)/faktorial(n-m)*faktorial(m);
  write(kombinasi);}
end.
Oya… untuk baris perintah setelah write(faktorial(n)) ini hendaknya kita jadikan
komentar dahulu supaya tidak ada interfensi dalam proses. Apabila dijalankan,
maka akan muncul output 6. Ya… hasil ini benar karena kita menampilkan n!
atau dalam hal ini 3!. Sehingga function faktorial() tidak ada masalah dan
berfungsi dengan baik.
Selanjutnya akan kita cek untuk menghitung kombinasinya sendiri atau pada
baris
kombinasi := faktorial(n)/faktorial(n-m)*faktorial(m);
Satu-satunya kemungkinan salah adalah di sini, karena proses inilah yang
dilakukan tepat sebelum ditampilkan outputnya. Apabila kita perhatikan dengan
benar, maka ada bagian yang salah yaitu pada pembagian. Ingat rumus mencari
C(n, m). Rumus yang benar haruslah
kombinasi := faktorial(n)/(faktorial(n-m)*faktorial(m));
sehingga baris programnya menjadi
begin
  n := 3;
  m := 2;
  kombinasi := faktorial(n)/(faktorial(n-m)*faktorial(m));
  write(kombinasi);
end.
Nah… setelah diperbaiki, barulah program di atas akan menghasilkan output
yang benar yaitu 3.
Sehingga kesimpulan dari teknik debug ini adalah ceklah output untuk setiap
langkah proses dengan menampilkannya ke layar. Untuk menghindari interfensi
dari baris program yang lain, hendaknya baris program di bawahnya atau
selanjutnya, dibuat komentar (jangan dihapus) terlebih dahulu. Teknik ini bisa
diterapkan untuk bahasa pemrograman yang lain.
OK… selamat ber-ge debag – ge debug ria   (nienobagus, 2010)

DAFTAR PUSTAKA

Bibliography
nienobagus. (2010, 5). Teknik Debugging Dalam Membuat Program. Retrieved
from http://nienobagus.blogspot.co.id: http://nienobagus.blogspot.co.id/2010/05/te
knik-debugging-dalam-membuat-program.html
REVOLUTIONER. (2009, 8 7). Debugging (pengertian). Retrieved from
revoluthion.wordpress.com: https://revoluthion.wordpress.com/2009/10/07/debug
ging-pengertian/
WIKI. (2016, 8 5). Debugger. Retrieved from
wikipedia: https://id.wikipedia.org/wiki/Debugger