Kamis, 30 Januari 2014

Bug VS Debug

  • Apa itu Bug ?
           Bug dalam bahasa Indonesia artinya serangga pengganggu. Dalam dunia script, bug juga bisa diartikan "lubang-lubang error yang terdapat di dalam komputer dan disebabkan karena ketidaksempurnaan desain pada program yang menyebabkan program itu tidak berfungsi semestinya". Tapi kesalahan ini sangat kecil sehingga dinamakan bug atau si kecil yang mengganggu.
  • 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.

  • Apa itu Debugging ?
          Debugging adalah sebuah metode yang dilakukan oleh para pemrogram dan pengembang perangkat lunak untuk meng-analisa alur kerja program, 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.

  • 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.
  • Karakteristik bug
       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 kesalahan, jumlah tekanan untuk menemukan kesalahan juga bertambah. Sering kali tekanan memaksa seorang pengembang perangkat lunak untuk membetulkan kesalahan dan pada saat yang sama memunculkan lagi dua kesalahan baru.

  • Kategori Pendekatan debugging 
             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. 

        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) sampai sisi penyebab ditemukan. Sayangnya, bila jumlah baris sumber bertambah, maka jumlah jalur balik potensial dapat sangat banyak.

        3. Eliminasi penyebab (Cause elimination)
           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. 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.

Sumber :
Buku : "Debug It!", 2009, Paul Butcher, The Pragmatic Programmers
 
 

Tidak ada komentar:

Posting Komentar