Debugging

Debugging adalah proses metodis menemukan dan mengurangi jumlah bug , atau cacat, dalam sebuah program komputer atau sepotong perangkat keras elektronik , sehingga membuatnya berperilaku seperti yang diharapkan. Debugging cenderung lebih sulit ketika berbagai subsistem yang erat , karena perubahan dalam satu dapat menyebabkan bug muncul di tempat lain. Banyak buku telah ditulis tentang debugging (lihat di bawah: Bacaan lebih lanjut ), karena melibatkan banyak aspek, termasuk interaktif debugging, aliran kontrol , pengujian integrasi , file log , monitoring ( aplikasi , sistem ), dump memori , profiling , Statistical Process Control , dan taktik desain khusus untuk meningkatkan deteksi sementara menyederhanakan perubahan.

Istilah "bug" dan "debugging" keduanya populer dikaitkan dengan Admiral Grace Hopper pada 1940-an. Sementara ia bekerja pada Mark II Komputer di Harvard University, rekan-rekannya menemukan ngengat terjebak dalam sebuah relay dan dengan demikian menghambat operasi , dimana ia mengatakan bahwa mereka "debug" sistem. Namun istilah "bug" dalam arti kesalahan teknis tanggal kembali setidaknya ke 1878 dan Thomas Edison (lihat bug software untuk pembahasan lengkap), dan "debugging" tampaknya telah digunakan sebagai istilah di aeronautika sebelum memasuki dunia komputer. Memang, dalam sebuah wawancara Grace Hopper mengatakan bahwa dia tidak coining istilah. Ngengat sesuai dengan terminologi yang sudah ada, jadi itu disimpan.

The Oxford English Dictionary entri untuk "debug" mengutip istilah "debugging" digunakan dalam referensi untuk pengujian mesin pesawat dalam sebuah artikel 1945 di Journal of Royal Aeronautical Society. Sebuah artikel di "Airforce" (Juni 1945 p. 50) juga mengacu pada debugging, kali ini kamera pesawat. Hopper bug ditemukan pada tanggal 9 September 1947. Istilah ini tidak diadopsi oleh pemrogram komputer sampai awal 1950-an. Artikel mani oleh Gill pada tahun 1951 adalah awal pembahasan kesalahan pemrograman yang mendalam, tetapi tidak menggunakan istilah "bug" atau "debugging". Dalam ACM perpustakaan digital 's, istilah "debugging" pertama kali digunakan dalam tiga makalah dari 1.952 ACM Rapat Nasional. Dua dari tiga menggunakan istilah dalam tanda kutip. Tahun 1963, "debugging" adalah istilah yang cukup umum untuk disebutkan secara sepintas tanpa penjelasan di halaman 1 dari CTSS manual.

Lingkup

Sebagai perangkat lunak dan sistem elektronik telah menjadi umumnya lebih kompleks, berbagai teknik debugging umum telah diperluas dengan metode yang lebih untuk mendeteksi anomali, menilai dampak, dan jadwal patch software atau update penuh ke sistem. Kata-kata "anomali" dan "perbedaan" dapat digunakan, sebagai istilah yang lebih netral, untuk menghindari kata-kata "kesalahan" dan "cacat" atau "bug" di mana mungkin ada implikasi bahwa semua yang disebut kesalahan, cacat atau bug harus diperbaiki (di semua biaya). Sebaliknya, sebuah penilaian dampak dapat dibuat untuk menentukan apakah perubahan untuk menghapus anomali (atau perbedaan) akan biaya-efektif untuk sistem, atau mungkin rilis baru dijadwalkan mungkin membuat perubahan yang tidak perlu. Tidak semua masalah adalah kehidupan yang kritis atau misi-kritis dalam suatu sistem. Juga, penting untuk menghindari situasi di mana perubahan mungkin akan lebih menjengkelkan bagi pengguna, jangka panjang, daripada hidup dengan masalah yang dikenal (di mana "penyembuhan akan lebih buruk daripada penyakit"). Mendasarkan keputusan penerimaan beberapa anomali dapat menghindari budaya "nol-cacat" mandat, di mana orang mungkin tergoda untuk menyangkal keberadaan masalah sehingga hasilnya akan muncul sebagai nol cacat. Mengingat masalah agunan, seperti penilaian dampak biaya-versus-manfaat, maka teknik debugging yang lebih luas akan memperluas untuk menentukan frekuensi anomali (seberapa sering sama "bug" terjadi) untuk membantu menilai dampaknya terhadap sistem secara keseluruhan.

Peralatan

Debugging rentang, dalam kompleksitas, dari memperbaiki kesalahan sederhana untuk melakukan tugas-tugas yang panjang dan melelahkan dari pengumpulan data, analisis, dan penjadwalan update. Keterampilan debugging dari programmer bisa menjadi faktor utama dalam kemampuan untuk debug masalah, tetapi kesulitan debugging software sangat bervariasi dengan kompleksitas sistem, dan juga tergantung, sampai batas tertentu, pada bahasa pemrograman yang digunakan dan alat yang tersedia, seperti debugger . Debugger adalah perangkat lunak yang memungkinkan programmer untuk memantau pelaksanaan program, menghentikannya, restart, mengatur breakpoints , dan mengubah nilai-nilai dalam memori. The debugger istilah juga dapat merujuk kepada orang yang melakukan debugging.

Umumnya, bahasa pemrograman tingkat tinggi , seperti Java , membuat debug lebih mudah, karena mereka memiliki fitur seperti penanganan eksepsi yang membuat sumber-sumber nyata dari perilaku tak menentu lebih mudah untuk spot. Dalam bahasa pemrograman seperti C atau perakitan , bug dapat menyebabkan masalah diam seperti korupsi memori , dan seringkali sulit untuk melihat di mana masalah awal terjadi. Dalam kasus tersebut, debugger memori alat mungkin diperlukan.

Dalam situasi tertentu, perangkat lunak tujuan umum yang bahasa tertentu di alam dapat sangat berguna. Ini mengambil bentuk alat analisis kode statis . Alat ini mencari satu set yang sangat spesifik dari masalah yang diketahui, beberapa umum dan beberapa langka, dalam kode sumber. Semua isu tersebut terdeteksi oleh alat ini akan jarang dijemput oleh kompilator atau interpreter, sehingga mereka tidak catur sintaks, tetapi catur lebih semantik. Beberapa alat mengklaim dapat mendeteksi 300 + masalah yang unik. Kedua alat komersial dan bebas ada dalam berbagai bahasa. Alat-alat ini dapat sangat berguna ketika memeriksa pohon-pohon sumber yang sangat besar, di mana tidak praktis untuk melakukan penelusuran kode. Sebuah contoh khas dari masalah yang terdeteksi akan menjadi dereference variabel yang terjadi sebelum variabel diberikan nilai. Contoh lain akan melakukan memeriksa jenis kuat ketika bahasa tidak memerlukan tersebut. Dengan demikian, mereka lebih baik di lokasi kemungkinan kesalahan, dibandingkan kesalahan yang sebenarnya. Akibatnya, alat ini memiliki reputasi positif palsu. The Unix tua serat Program adalah contoh awal.

Untuk debugging hardware elektronik (misalnya, perangkat keras komputer ) serta perangkat lunak tingkat rendah (misalnya, BIOS , driver perangkat ) dan firmware , instrumen seperti osiloskop , analisa logika atau in-circuit emulator (ICES) yang sering digunakan, sendiri atau dalam kombinasi. Sebuah ICE dapat melakukan banyak tugas perangkat lunak debugger khas pada tingkat rendah perangkat lunak dan firmware .

Proses debugging

Biasanya langkah pertama dalam debugging adalah untuk mencoba untuk mereproduksi masalah. Ini bisa menjadi tugas non-sepele, misalnya seperti proses paralel atau beberapa bug perangkat lunak yang tidak biasa . Juga, lingkungan pengguna spesifik dan sejarah penggunaan dapat membuat sulit untuk mereproduksi masalah.

Setelah bug tersebut direproduksi, input program mungkin perlu disederhanakan untuk membuatnya lebih mudah untuk debug. Sebagai contoh, sebuah bug dalam kompilator dapat membuat kecelakaan ketika parsing beberapa file sumber besar. Namun, setelah penyederhanaan kasus tes, hanya beberapa baris dari file sumber asli dapat cukup untuk mereproduksi kecelakaan yang sama. Penyederhanaan tersebut dapat dibuat secara manual, menggunakan membagi-dan-menaklukkan pendekatan. Programmer akan mencoba untuk menghapus beberapa bagian dari kasus uji asli dan memeriksa apakah masalahnya masih ada. Ketika debugging masalah dalam GUI , pemrogram dapat mencoba untuk melewati beberapa interaksi pengguna dari deskripsi masalah asli dan memeriksa apakah tindakan yang tersisa cukup untuk bug muncul.

Setelah kasus uji cukup sederhana, seorang programmer dapat menggunakan debugger alat untuk memeriksa negara Program (nilai-nilai variabel, ditambah panggilan stack ) dan melacak asal-usul masalah. Atau, tracing dapat digunakan. Dalam kasus sederhana, tracing hanya pernyataan mencetak beberapa, yang output nilai variabel pada titik-titik tertentu dari eksekusi program.

Teknik

Cetak debugging (atau melacak) adalah tindakan menonton (hidup atau direkam) jejak laporan, atau laporan cetak, yang menunjukkan aliran eksekusi dari sebuah proses. Ini kadang-kadang disebut printf debugging, karena penggunaan printf pernyataan dalam C. Jenis debugging dihidupkan oleh perintah TRON dalam versi asli dari pemula berorientasi BASIC bahasa pemrograman. TRON berdiri, "Jejak On." TRON menyebabkan nomor baris setiap baris perintah BASIC untuk mencetak sebagai program berlari.

Jauh debugging adalah proses debugging program berjalan pada sistem yang berbeda dari debugger. Untuk memulai remote debugging, debugger terhubung ke sistem remote melalui jaringan. Debugger kemudian dapat mengontrol eksekusi program pada sistem remote dan mengambil informasi tentang negaranya.

Post-mortem debugging debugging program setelah itu sudah jatuh . Teknik terkait sering termasuk berbagai teknik tracin dan / atau analisis dump memori (atau core dump ) dari proses jatuh. Dump proses dapat diperoleh secara otomatis oleh sistem (misalnya, ketika proses telah dihentikan karena unhandled pengecualian), atau dengan instruksi programmer-dimasukkan, atau secara manual oleh pengguna interaktif. 

"Serigala pagar" Algoritma: Edward Gauss dijelaskan algoritma sederhana namun sangat berguna dan sekarang terkenal ini dalam sebuah artikel 1982 untuk komunikasi dari ACM sebagai berikut: "Ada satu serigala Alaska, bagaimana Anda menemukannya Pertama membangun pagar di tengah? negara, menunggu serigala melolong, menentukan sisi pagar yang aktif. Ulangi proses di sisi saja, sampai Anda mendapatkan ke titik di mana Anda dapat melihat serigala. " ini dilaksanakan misalnya dalam the Git sistem kontrol versi sebagai perintah git membagi dua, yang menggunakan algoritma di atas untuk menentukan komit memperkenalkan bug tertentu.

Delta Debugging - teknik mengotomatisasi uji kasus penyederhanaan.

Squeeze Saff -. Teknik mengisolasi kegagalan dalam tes menggunakan inlining progresif bagian dari tes gaga