TESTING DAN DEBUGGING

Pada Dasarnya ada 2 istilah untuk menyebut pengujian pada program yaitu testing dan
debugging.
Testing adalah proses mengeksekusi program secara intensif untuk menemukan kesalahan
,
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 digabungkan, seperti perubahan dalam satu dapat
menyebabkan bug muncul di negara lain.. Karena melibatkan berbagai aspek, termasuk:
interaktif debugging, control flow, integrasi pengujian, log file, pemantauan, memori
dumps, Statistical Process ontrol, dan taktik untuk desain khusus meningkatkan deteksi
sementara menyederhanakan perubahan.
Tipe kesalahan
Syntax Error
Kesalahan yang paling sering ditemukan pada saat membuat program adalah
kesalahan sintaks atau Synta! "rror, dimana perintah atau statemen yang diketikkan
menyalahi aturan pengkodean yang dimiliki oleh bahasa pemrograman yang #nda
gunakan.
Sebuah bahasa pemrograman memiliki aturan pengkodean tersendiri yang harus
dipatuhi, sebagai contoh pada bahasa pemrograman Pascal$Delphi, setiap statemen
diwajibkan diakhiri dengan tanda titik koma %&'. (ika #nda tidak menuliskannya, program
akan menampilkan pesan Synta! "rror pada saat dijalankan.
Setiap bahasa pemrograman memiliki keyword, yaitu perintah)perintah baku yang
digunakan. Sebagai contoh, keyword yang umum adalah kondisi if, perulangan for atau
while, penulisan fungsi dan lambang aritmatika seperti modulus, pangkat, dan lain)lain.
Kesalahan penulisan keyword juga merupakan Synta! "rror.
Kesalahan penulisan parameter pada sebuah function$procedure juga termasuk
dalam kategori Synta! "rror, misalnya jika function yang #nda gunakan memerlukan
parameter sementara #nda lupa menuliskan parameter tersebut.
Synta! "rror merupakan jenis kesalahan yang paling sering ditemui, tetapi juga
pada umumnya paling mudah untuk ditanggulangi. Synta! "rror cukup mudah diketahui
dan diperbaiki jika bahasa pemrograman yang #nda gunakan menunjukkan baris
kesalahan dengan tepat, dan menampilkan pesan kesalahan yang benar.
Pada beberapa bahasa pemrograman, disediakan fasilitas #uto Synta! heck,
dimana muncul sebuah pesan peringatan ketika #nda mengetikkan sintaks yang salah.
Run-time Error
(enis kesalahan *un)time "rror terjadi ketika kode program melakukan sesuatu
yang tidak dimungkinkan. ontohnya pada saat sebuah aplikasi mencoba mengakses file
yang tidak ada, atau terjadi kesalahan alokasi memory.
+erkadang *un)time "rror terjadi karena berbagai aspek dan tidak selalu karena
kesalahan pemrograman, sebagai contoh jika #nda sengaja menghapus beberapa file
penting yang digunakan oleh suatu aplikasi, maka terdapat kemungkinan akan terjadi
*un)time "rror pada saat aplikasi tersebut dijalankan.
,alaupun demikian, pencegahan semaksimal mungkin dengan memberikan
-alidasi dan pesan yang user)friendly saat terjadi kesalahan pada aplikasi, akan sangat
membantu untuk mengetahui mengapa aplikasi tidak berjalan dengan semestinya.
Logial Error
.ogical "rror merupakan jenis kesalahan yang cukup sulit untuk ditemukan
penyebabnya. Karena aplikasi yang mengandung .ogical "rror berjalan tanpa pesan
kesalahan, tetapi mengeluarkan hasil yang tidak diharapkan, misalnya jika aplikasi #nda
menghasilkan perhitungan yang salah.
.ogical "rror baru dapat diketahui setelah #nda melakukan testing dan meninjau
hasilnya. .ogical "rror dapat diperbaiki dengan memeriksa alur program dan nilai
-ariabel yang dihasilkan.
!rogramer
Sebuah error pada aplikasi disebut dengan istilah bug, atau dalam /ahasa 0nggris
berarti kutu atau binatang kecil. Konon istilah bug muncul karena ditemukannya binatang
kecil yang menyebabkan kerusakan pada sebuah komputer tabung pada tahun 1234.
/ug aplikasi terdapat pada kode program, yang dapat mengganggu kenyamanan
pengguna aplikasi #nda. Pada tingkat tertentu, keberadaan bug cukup memberikan efek
yang besar.
#nda mungkin belum melupakan saat dimana orang ramai membicarakan 562K
/ug7 atau bug tahun 2888, atau munculnya istilah 5/lue screen of Death7 pada sistem
operasi ,indows, atau 5Kernel Panic7 pada sistem operasi .inu!, semua contoh tersebut
menunjukkan sebuah bug serius dapat mengakibatkan dampak negatif yang cukup besar.
Proses mencari penyebab bug disebut dengan debug, yang juga merupakan tugas
programer setelah menerima laporan bug. ,alaupun demikian, jangan menjadikan
pekerjaan #nda sebagai pencari bug, 9ntuk itu hanya ada satu cara, minimalkan bug pada
aplikasi yang #nda buat.
#pa yang harus #nda lakukan untuk menghindari jenis)jenis kesalahan yang telah
disebutkan di atas: /isa jadi tidak ada program yang sempurna, tetapi selalu ada cara
untuk mengatasi atau menghindari kesalahan semaksimal mungkin.
Desain Algoritma "an Representasi
Setelah kita mengetahui dengan baik dan jelas mengenai permasalahan yang ingin
diselesaikan, langkah selanjutnya yaitu membuat rumusan algoritma untuk
menyelesaikan permasalahan. Dalam pemrograman komputer penyelesaian masalah
didefinisikan dalam langkah demi langkah.
#lgoritma adalah urutan langkah ; langkah logis penyelesaian masalah yang
disusun secara sistematis dan logis. .ogis merupakan kunci dari sebuah algoritma.
.angkah)langkah dalam algoritma harus logis dan bernilai benar atau salah.
#lgoritma dapat diekpresikan dalam bahasa manusia, menggunakan presentasi
grafik melalui sebuah <lowhart %diagram alir' ataupun melalui Pseudoode yang
menjembatani antara bahasa manusia dengan bahasa pemrograman.
/erdasarkan permasalahan yang terjadi pada bagian sebelumnya, bagaimanakah
kita dapat memberikan solusi penyelesaian secara umum dalam sebuah alur yang dapat
dengan mudah dimengerti:
ara penyelesaian melalui #lo$%hart &
Sym'ol (lo$hart
<lowchart adalah representasi grafis dari langkah ; langkah yang harus diikuti
dalam menyelesaikan suatu permasalahan yang terdiri atas sekumpulan simbol, dimana
masing ; masing simbol merepresentasikan kegiatan tertentu. <lowchart diawali dengan
penerimaan input dan diakhiri dengan penampilan output. Sebuah flowchart pada
umumnya tidak menampilkan instruksi bahasa pemrograman, namun menetapkan konsep
solusi dalam bahasa manusia ataupun notasi matematis. /erikut ini akan dibahas tentang
simbol;simbol yang digunakan dalam menyusun flowchart, kegiatan yang diwakili serta
aturan yang diterapkan dalam penggunaan
simbol tersebut :
SI)B*L NA)A !ENGERTIAN
Sim'ol !roses
Simbol ini digunakan untuk melambangkan
kegiatan pemprosesan input. Dalam simbol ini,
kita
dapat menuliskan operasi)operasi yang
dikenakan
pada input, maupun operasi lainnya. Sama
seperti
aturan pada simbol input, penulisan dapat
dilakukan secara satu per satu maupun secara
keseluruhan.
Sim'ol Input +
*utput ,I*-
=erepresentasikan fungsi 0$> yang membuat
sebuah data dapat diproses %input' atau
ditampilkan %output' setelah mengalami
eksekusi
informasi.
Sim'ol Garis Alir
Simbol ini digunakan untuk menghubungkan
setiap
langkah dalam flowchart dan menunjukkan
kemana
arah aliran diagram. #nak panah ini harus
mempunyai arah dari kiri ke kanan atau dari
atas
ke bawah. #nak panah ini juga dapat diberi
label,
khususnya jika keluar dari symbol
percabangan.
Sim'ol Anotasi
=erepresentasikan informasi deskriptif
tambahan,
komentar atau catatan penjelasan. Dalam
simbol
ini, kita dapat menuliskan komentar apapun
dan
sebanyak apapun, hal ini berguna untuk
memperjelas langkah)langkah dalam
flowchart.
?aris -ertical dan garis putus;putus dapat
ditempatkan pada sisi kanan maupun kiri.
Sim'ol
!era'angan
Simbol ini digunakan untuk melambangkan
percabangan, yaitu pemeriksaan terhadap suatu
kondisi. Dalam simbol ini, kita menuliskan
keadaan
yang harus dipenuhi. @asil dari pemeriksaan
dalam
simbol ini adalah 6"S atau A>. (ika
pemeriksaan
menghasilkan keadaan benar, maka jalur yang
harus dipilih adalah jalur yang berlabel 6es,
sedangkan jika pemeriksaan menghasilkan
keadaan salah, maka jalur yang harus dipilih
adalah jalur yang berlabel Ao.
Sim'ol Terminator
+erminator berfungsi untuk menandai awal dan
akhir dari suatu flowchart. Simbol ini biasanya
diberi label S+#*+ untuk menandai awal dari
flowchart, dan label S+>P untuk menandai
akhir
dari flowchart. (adi dalam sebuah flowchart
pasti
terdapat sepasang terminator yaitu terminator
start dan stop.
Sim'ol .onektor
Simbol konektor digunakan pada waktu
menghubungkan suatu langkah dengan
langkah
lain dalam sebuah flowchart dengan keadaan
on
page atau off page. Konektor on page
digunakan
untuk menghubungkan suatu langkah dengan
langkah lain dari flowchart dalam satu
halaman,
sedangkan konektor off page digunakan untuk
menghubungkan suatu langkah dengan
langkah
lain dari flowchart dalam halaman yang
berbeda.
Konektor ini biasanya dipakai saat media yang
kita
gunakan untuk menggambar flowchart tidak
cukup
luas untuk memuat gambar secara utuh, jadi
perlu
dipisah)pisahkan. Dalam sepasang konektor
biasanya diberi label tertentu yang
Sim'ol !rose"ur
Simbol ini berperan sebagai blok pembangun
dari
suatu program. Prosedur memiliki suatu
flowchart
yang berdiri sendiri diluar flowchart utama.
(adi
dalam simbol ini, kita cukup menuliskan nama
prosedurnya saja, jadi sama seperti jika kita
melakukan pemanggilan suatu prosedur pada
program utama %main program'. Sama dengan
aturan pada simbol percabangan, penulisan
nama
prosedur dilakukan secara satu per satu.
Mengekspresikan solusi melalui Pseudocode :
listAama B Daftar Aama
keyAama B Aama yang dicari
hitung B 8
9ntuk setiap nama pada Daftar Aama lakukan :
(ika nama BB keyAama
@itung B @itung C 1
+ampilkan @itung
!engu/ian program
DESAIN TEST %ASE
+erdapat bermacam)macam rancangan metode test case yg dapat digunakan, semua
menyediakan pendekatan sistematis untuk uji coba, yg terpenting metode menyediakan
kemungkinan yg cukup tinggi menemukan kesalahan. +erdapat 2 macam test case:
1. Pengetahuan fungsi yg spesifik dari produk yg telah dirancang untuk
diperlihatkan, test dapat dilakukan untuk menilai masing)masing fungsi apakah
telah berjalan sebagaimana yg diharapkan.
2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk
memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya.
Dua macam pendekatan test yaitu :
1. Black Box Testing
+est case ini bertujuan untuk menunjukkan fungsi perangkat lunak tentang cara
beroperasinya, apakah pemasukan data keluaran telah berjalan sebagaimana yang
diharapkan dan apakah informasi yang disimpan secara eksternal selalu
dijaga kemutakhirannya. +ehnik pengujian black)bo! berfokus pada domain
informasi dari perangkat lunak, dengan melakukan test case
dengan menpartisi domain input dari suatu program dengan cara yang
memberikan cakupan pengujian yang mendalam. =etode pengujian graph)based
mengeksplorasi hubungan antara dan tingkah laku objek)objek program. Partisi
eki-alensi membagi domain input ke dalam kelas data yang mungkin untuk
melakukan fungsi perangkat lunak tertentu. #nalisis nilai batas memeriksaa
kemampuan program untuk menangani data pada batas yang dapat diterima.
=etode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan
perangkat lunak dan area aplikasi. ?90, arsitektur client$ ser-er, dokumentasi dan
fasilitas help dan sistem real time masing)masing membutuhkan pedoman dan
tehnik khusus untuk pengujian perangkat lunak.
2. White Box Testing
#dalah meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal
path %jalur logika' perangkat lunak akan ditest dengan menyediakan test case yang
akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara
sekilas dapat diambil kesimpulan white bo! testing merupakan petunjuk untuk
mendapatkan program yang benar secara 188D. Pengujian white)bo! berfokus
pada struktur control program. +est case dilakukan untuk memastikan bahwa
semua statemen pada program telah dieksekusi paling tidak satu kali selama
pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik
pengujian white)bo!, menggunakan grafik %matriks grafiks' untuk melakukan
serangkaian pengujian yang independent secara linear yang akan memastikan
cakupan. Pengujian aliran data dan kondisi lebih lanjut menggunakan logika
program dan pengujian loop menyempurnakan tehnik white)bo! yang lain dengan
memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang
ber-ariasi. Pengujian black)bo! didesain untuk mengungkap kesalahan pada
persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.
STRATEGI U0I %*BA !ERANG.AT LUNA.
Strategi uji coba perangkat lunak memudahkan para perancang untuk menentukan
keberhasilan system yg telah dikerjakan. @al yang harus diperhatikan adalah langkah)
langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama
waktu, upaya dan sumber daya yg diperlukan. Strategi uji coba mempunyai karakteristik
sbb :
1. Pengujian mulai pada tingkat modul yg paling bawah, dilanjutkan dgn modul di
atasnya kemudian hasilnya dipadukan.
2. +eknik pengujian yang berbeda mungkin menghasilakn sedikit perbedaan %dalam
hal waktu'
E. Pengujian dilakukan oleh pengembang perangkat lunak dan %untuk proyek yang
besar' suatu kelompok pengujian yang independen.
3. Pengujian dan debugging merupakan akti-itas yang berbeda, tetapi debugging
termasuk dalam strategi pengujian.
Pengujian perangkat lunak adalah satu elemen dari topik yang lebih luas yang
sering diacu sebagai -erifikasi dan -alidasi
%FG F'.
Verifikasi : Kumpulan aktifitas yg menjamin penerapan perangkat lunak benar)benar
sesuai dgn fungsinya.
Validasi : Kumpulan akti-itas yang berbeda yang memastikan bahwa perangkat lunak
yang dibangun dapat memenuhi keperluan pelanggan.
!ENGU0IAN UNIT
9nit testing %uji coba unit' fokusnya pada usaha -erifikasi pada unit terkecil dari
desain perangkat lunak, yakni modul. 9ji coba unit selalu berorientasi pada white bo!
testing dan dapat dikerjakan paralel atau beruntun dengan modul lainnya.
!ENGU0IAN INTEGRASI
Pengujian terintegrasi adl teknik yg sistematis untuk penyusunan struktur
program, pada saat bersamaan dikerjakan uji coba untuk memeriksa kesalahan yg
nantinya digabungkan dengan interface.
=etode pengujian
a) top don integration
+op down integration adalah pendekatan incremental dengan menggerakkan ke
bawah melalui hirarki control, dimulai dengan control utama. Strategi intergrasi top)
down memeriksa control mayor atau keputusan pada saat awal di dalam proses
pengujian. Pada struktur program yang difaktorkan dengan baik, penarikan keputusan
terjadi pada tingkat hirarki yang lebih tinggi sehingga terjadi lebih dulu.
Strategi top)down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak
menimbulkan masalah logistic. /iasanya masalah ini terjadi jika dibutuhkan pemrosesan
di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih
tinggi.
!) !uttom up integration
/ottom up integration memulai konstruksi dan pengujian dengan modul atomic %modul
pada tingkat paling rendah pada struktur program'. Karena modul diintegrasikan dari
bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu
tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi.
Strategi integrasi bottom)up dapat diimplementasi dengan langkah)langkah:
modul tingkat rendah digabung ke dalam cluster %build' yang melakukan
subfungsi perangkat lunak spesifik.
Dri-er %program control untuk pengujian' ditulis untuk mengkoordinasi input dan
output test case
cluster diuji
dri-er diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam
struktur program.
DEBUGGING
!roses De'ugging
Debugging bukan merupakan pengujian, tetapi selalu terjadi sebagai bagian akibat
dari pengujian. Proses debungging dimulai dengan eksekusi terhadap suatu test case.
@asilnya 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 iterati-e.
/eberapa karakteristik bug memberi kunci :
?ejala 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.
?ejala dapat hilang %kadang)kadang' ketika kesalahan yang lain dibetulkan.
?ejala 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.
?ejala dapat merupakan hasil dari masalah timing, dan bukan dari masalah
pemrosesan. =ungkin sulit untuk mereproduksi kondisi input secara akurat
%misalnya aplikasi real time dimana pengurutan input tidak ditentukan'.
?ejala dapat sebentar)sebentar. @al ini sangat umum pada system yang embedded
yang merangkai perangkat lunak dan perangkat keras yang tidak mungkin
dilepaskan.
?ejala 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.
!ertim'angan !sikologis
Sayangnya muncul banyak bukti bahwa kekuatan debugging adalah sifat bawaan
manusia. /anyak orang yang cakap dalam hal ini, sementara banyak juga yang tidak.
=enanggapi aspek manusia dari debugging. Shneiderman HS@AI8J 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 #nda 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
KKK dikoreksi.
=eskipun mungkin sulit untuk mempelajari debugging, sejumlah pendekatan
terhadap masalah tersebut dapat diusulkan. Kita akan melihat dalam sub bab selanjutnya.
!en"ekatan-pen"ekatan De'ugging
+anpa memperhatikan pendekatan yang diambil, debugging memiliki satu sasaran
yang diabaikan, untuk menemukan dan mengkoreksi penyebab kesalahan perangkat
lunak. Sasaran tersebut direalisasi dengan suatu kombinasi e-aluasi yang sistematis,
intuisi, dan keberuntungan.
/radley %/*#I4' 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.
#mbillah contoh non)perangkat lunak sederhana, yaitu :
ampu dirumah saya tidak bekerja. !ila tidak ada yang bekerja didalam rumah itu"
penyebabnya tentu pada pemutus rangkaian utama atau sebab dari luar. #aya melihat
sekeliling untuk melihat apakah lampu para tetangga juga mati. #aya memasukkan
lampu yang di$urigai kedalam soket yang bekerja dan menyelidiki lampu rangkaian
yang di$urigai. !egitulah berbagai pilihan hipotesa dan pengujian.
Secara umum, tiga kategoti pendekatan debugging dapat diusulkan %=6"L2' :
1. ?aya yang kasar %/rute 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 7biarkan komputer menemukan
kesalahan7, tempat sampah memori dipakai, penelusuran runtime dilakukan, dan
program dibebani dengan statemen ,*0+". Kita mengharapkan bahwa
dimanapun didalam rawa informasi yang diproduksi, kita akan menemukan suatu
kunci yang akan membawa kita kepada penyebab kesalahan. =eskipun
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'
/acktracking adalah pendekatan debugging yang sangat umum yang dapat
digunakan secara sukses didalam program yang kecil. =ulai 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.
E. "liminasi penyebab
ause elimination dimanisfestasikan oleh induksi atau deduksi serta mengawali
konsep partisi biner. Data yang berhubungan dengan kejadian kesalahan dikumpulkan
untuk mengisolasi penyebab potensial. @ipotesis 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. (ika pengujian awal menunjukkan bahwa suatu hipotesis
penyebab memberikan gambaran hasil yang jelas, maka data itu disaring sebagai usaha
untuk mengisolasi bug.
=asing)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. Aamun piranti bukanlah pengganti bagi e-aluasi yang berhati)hati yang
didasarkan atas dokumen desain perangkat lunak yang lengkap dan kode sumber yang
jelas.
!EN%ATATAN DAN E1ALUASI
Gunakan Log #ile
0nformasi proses yang dijalankan aplikasi dan tersimpan pada sebuah log file
%dapat berupa file te!t atau table' dapat menjadi informasi yang sangat berguna untuk
menganalisa bug yang mungkin terjadi. +erutama informasi yang menjelaskan apa yang
terjadi sebelum, selama, dan sesudah bug terjadi.
9ntuk menghindari log file yang terlalu besar, #nda dapat memisahkan log file
terbagi menjadi log untuk komponen)komponen utama pada aplikasi. (angan lupa untuk
selalu mencatat waktu %timestamp' pada setiap record. #nda dapat menghapus atau
melakukan backup pada log file secara periodik.
1ali"asi
+idak semua orang mematuhi aturan yang #nda terapkan pada aplikasi, karena itu
#nda harus melakukan -alidasi untuk data yang dimasukkan oleh pengguna. =isalnya
pada suatu form pendaftaran, #nda sebaiknya melakukan -alidasi untuk input yang tidak
boleh kosong %mandatory$reMuired fields', melakukan pembatasan karakter, dan -alidasi
huruf$angka yang diperlukan.
)engenal En2ironment
Saat #nda mengetikkan kode program, menjalankannya, atau melakukan debug
pada program, #nda berada pada en-ironment yang berbeda)beda. +erdapat E
en-ironment yang umum dikenal, yaitu:
1. Design +ime.
#plikasi yang #nda kerjakan dilakukan pada saat design time.
2. *un +ime.
Saat menjalankan aplikasi.
E. /reak =ode.
"n-ironment saat #nda melakukan proses debug atau melihat kode program saat program
tersebut dijalankan, #nda dapat melihat alur program dan perubahan nilai pada -ariabel,
sehingga #nda dapat menelusuri kesalahan yang terjadi. /reak =ode terletak diantara
Design +ime dan *un +ime.