Debugging

Bug
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.
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.

1. Beberapa karakteristik kunci bug :
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.

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 atau proses yang dilakukan untuk memeriksa, mendiagnosa, dan memindahkan error. 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.
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.
1. 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, mendesain suatu test case untuk membantu kecurigaannya, dan bekerja untuk koreksi kesalahan dengan gaya yang iterative.
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.
2. 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.

Debugger
1. Fault Injection
Pada Fault Injection, program yang diteliti dipanggil dengan parameter yang ekstrim dan tidak biasanya dan/atau ditempati oleh variabel environment pada value yang ada. Jika program itu berisi satu titik lemah buffer overflow, akan muncul reaksi tak terbayangkan pada input-nya, umumnya berupa satu crash. Namun, sebaliknya jika program berjalan lagi secara normal, maka tidak akan ditemukan buffer overflow yang bisa dimanfaatkan melalui parameter yang telah disebutkan, atau bisa juga diakibatkan parameter yang tersedia dahulu belum cukup besar.
Pada satu sisi, suatu program bisa dipanggil secara manual dengan paarameter tertentu, dan di sisi lainnya terdapat test program spesial untuk itu. Di sini dibedakan antara host-based dan network-based programs.
Host-based programs contohnya adalah BFBTester dan Sharefuzz. BFBTester (Brute Force Binary Tester) ternyata bisa memanipulasi parameter single dan jamak atau variabel Environment. Sharefuzz berfungsi tanpa melakukan search ke titik lemah buffer overflow pada processing variabel environment.
Network-based programs contohnya adalah Hailstorm atau Spike. Hailstorm melakukan search titik lemah dalam web application. Selain melakukan pencarian terhadap buffer overflow, program itu juga mencari weak point Cross Site Scripting dan SQL Injection. Sedang Spike melayani penelitian protokol network dan program yang terhubung dengannya.
2. Dynamic Analisys.
Saru Tracer melakukan log peredaran suatu program. Protokol yang dibuat diuji coba selanjutnya pada kasus tertentu seperti buffer yang belum diuni coba. Ini juga memungkinkan perekonstruksian penggunaan dari variabel, yang kelak melakukan uji coba dengan bantuan Fault Injection sesuai tujuannya.
Satu Debugger tidak bisa melakukan log peredaran tersebut seperti satu Tracer, namun justru manipulasinya. Manipulasi yang mungkin terjadi tercapai dari pengalihan Instruction Pointer hingga ke perubahan variabel dan instruksi. Contoh untuk Debugger adalah Gnu Debugger gdb dan SoftICE.
3. Reverse Engineering
Pada Reverse Engineering, source code dikembangkan untuk satu program yang ada. Untuk itu program tersebut dirangkai atau didekompilasi. Satu program yang sering digunakan untuk itu, adalah interaktive Dissassembler IDA-Pro. Interactive dalam hal ini maksudnya adalah bahwa developer selama perangkaian memutuskan sendiri apakah data diinterpretasikan sebagai data atau code. Sebagai hasilnya, didapatkan source code Binary dalam Assembler. Di dalamnyaseperti tertulis pada Sourcecode Audit, dapat dicari fungsi panggilan yang menjadi penyebab. BugScam, satu development untuk IDA Pro, juga membantu.
MPLAB ICD 3 telah meningkatkan kecepatan dibandingkan dengan MPLAB ICD 2 dan mendukung paling microchip PIC dsPIC dan perangkat.
Fitur-fitur
• Real-time Debugging - MPLAB ICD-3 Dalam Circuit Debugger dirancang untuk mendukung kecepatan tinggi prosesor berjalan pada kecepatan maksimum, sehingga tertanam teknisi untuk men-debug aplikasi pada perangkat keras mereka sendiri secara real time.
• Antarmuka Ruggedized Probe - Perlindungan circuitries ditambahkan ke probe driver untuk menjaga pemeriksaan kit dari kuasa surges dari target. Vdd dan memonitor tegangan Vpp melindungi terhadap tegangan kondisi, dan semua baris yang berlebihan saat ini perlindungan. Unit dapat memberikan kuasa untuk target (hingga 100 ma).
• Microchip Standar Konektivitas - MPLAB ICD-3 Dalam Circuit Debugger mempekerjakan standar microchip debug Konektor (RJ-11).
• Portable, dan USB-powered-RoHS Compliant - Housed di kecil (3,7 "x.8") dan menarik kandang, yang MPLAB ICD-3 Dalam Circuit Debugger adalah didukung oleh port USB, jadi adaptor daya eksternal tidak diperlukan . MPLAB ICD-3 Dalam Circuit Debugger adalah TM dan RoHS-compliant.
• High Speed Pemrograman - Cepat pemrograman memungkinkan keduanya cepat firmware ulang untuk debugging dan cepat untuk di-sirkuit kembali pemrograman. Pemrograman waktu ditingkatkan hingga 15x lebih MPLAB ICD 2.
• Voltase rendah Emulation - MPLAB ICD 3 mendukung target pasokan tegangan 2,0-5,5 volts.
• Tes Antarmuka Modul - disertakan dengan setiap MPLAB ICD 3 merupakan ujian untuk menguji modul I / O saluran untuk mengkonfirmasi unit berfungsi sebagaimana mestinya.
• Kemudahan dari pemeliharaan dan Fitur Upgrade - Menambahkan dukungan perangkat baru dan fitur-fitur canggih untuk MPLAB ICD-3 Dalam Circuit Debugger adalah yang sederhana seperti menginstal versi yang lebih baru MPLAB IDE, download gratis. MPLAB ICD-3 Dalam Circuit Debugger adalah bidang firmware upgradeable melalui download dari MPLAB IDE.
• Biaya rendah - MPLAB ICD-3 Dalam Circuit Debugger istirahat harga hambatan bagi yang lengkap dan canggih dalam circuit-debugger, menawarkan cara-cara baru untuk berinteraksi dengan aplikasi debug dan di sebagian kecil dari biaya emulator sistem tradisional.
• Powerfull Debugging - High powered debug dengan MPLAB IDE mendukung beberapa breakpoints, Stopwatch, kode sumber file debug di MPLAB s editor cepat untuk program modifikasi / debug.

Prinsip-Prinsip Pemrograman
Kesulitan terbesar dalam menulis program komputer yang besar bukan dalam menentukan tujuan pemrograman, atau dalam mencari cara menemukan metode yang tepat untuk memenuhi tujuan tersebut. Masalah pertama dalam menyelesaikan program besar adalah menentukan apa masalah sesungguhnya. Tujuan Yang samar, pertanyaan yang saling bertentangan, atau keinginan lain, harus diterjemahkan dalam formulasi yang tepat. Karena itu, pendekatan harus meliputi tujuan menyeluruh dan tepat, kemudian membaginya sehingga mencapai tujuan yang mudah diatur.
1. Desain program.
Prinsip “pertama-tama buat program yang bisa bekerja, kemudian baru dipercantik,” mungkin efektif untuk program kecil, tapi tidak untuk program besar. Setiap bagian dari program besar harus teratur, tertulis dengan jelas, dan tidak bisa lagi dihubungkan dengan bagian lain dari proyek.
2. Struktur data.
Dalam program-program besar, kesulitan biasanya bukan timbul karena ketidak-mampuan untuk menemukan pemecahan, tapi tapi karena ada begitu banyak metode dan algoritma yang berbeda, hingga sulit untuk menentukan mana yang terbaik. Variasi desain algoritma biasanya terjadi karena cara penyimpanan data program, khususnya menyangkut hal-hal sebagai berikut:
• Bagaimana data itu disusun.
• Data mana yang disimpan dalam memori.
• Data mana yang digunakan pada saat tertentu.
• Data yang tetap dalam file, dan bagaimana file itu disusun.
3. Pengujian dan verifikasi
Kesulitan dalam melacak kesalahan (debugging) akan meningkat dari ukurannya. Karenanya, program program yang mempunya ukuran dua kali dari program lain, bukannya akan memakan waktu dua kali lebih lama, tapi mungkin justru empat kali. Pada beberapa program yang sangat besar, pada saat digunakan masih menyimpan banyak bug yang tidak bisa ditemukan programer.
4. Kebenaran program
Kadang program yang sudah menghabiskan waktu bertahun-tahun dalam pengerjaannya, harus dibuang karena tidak diketahui kenapa tidak bisa bekerja. Untuk menghindari hal itu, maka kita gunakan metode antara lain untuk:
• mengurangi jumlah bug, memudahka melihat yang masih tertinggal,
• memungkinkan memeriksa apakah algoritma yang digunakan sudah benar, dan
• memungkinkan pengujian ulang.
5. Pemeliharaan.
Pengamatan menunjukan, sekali suatu program selesai di debug dan siap digunakan, maka kurang dari separuh kerja telah selesai. Pemeliharaan program, yaitu modifikasi yang digunakanuntuk memenuhu permintaan dan lingkungan operasi baru, memakan lebih dari separuhkerja. Oleh karena itu, proyek besar mestinya ditulis untuk memudahkan pemahaman dan modifikasi.

Cara Melakukan Debugging
Cara-cara melakukan debugging
• memeriksa keberadaan debugger sistem menggunakan informasi
• periksa untuk melihat apakah pengecualian yang mengganggu
• memeriksa apakah proses dan thread blok telah dimanipulasi
• memeriksa kode modifikasi yang dilakukan oleh perangkat lunak penanganan debugger breakpoints
• Hardware-dan mendaftarkan-based: cek hardware breakpoints dan CPU register
• mengecek waktu yang dibutuhkan untuk melaksanakan instruksi

Read More (Baca Slengkapnya)---->