User. Spesification. System Design. System Spesification. Software Spesification. Program Spesification. Spesification PROGRAMMING

Transkripsi

1 SOFTWARE TESTING STRATEGIES Software validation Validasi software atau sering disebut verification and Validation. Verification mengacu kepada sekumpulan aktifitas yang memastikan bahwa sistem telah mengimplementasikan fungsi yang sesuai dengan spesifikasi. Validation mengacu kepada sekumpulan aktifitas yang berbeda yang memastikan bahwa software telah dikembangkan dapat memenuhi ekspektasi/harapan pengguna sistem. Melibatkan checking dan review proses serta ujicoba sistem. Ujicoba sistem meliputi pengeksekusian sistem dengan skenario uji yang diturunkan dari spesifikasi data real untuk diproses oleh sistem. Verification : Are we building the product right? Validation : Are we building the right product? Unit Module Sub-system Acceptance Component Integration The process User Analysis User Spesification Acceptance Design Spesification Software Design Software Spesification Function Program Design Program Spesification Integration Module Design Module Spesification Unit PROGRAMMING Relationship between system development and activities (Adams, Powers, Owles, 1985) 1

2 Tahapan-Tahapan Ujicoba 1. Unit /Module Unit /Module dilaksanakan untuk mengetahui kesalahan dalam logika atau fungsi setiap unit terkecil dari software, yaitu module. Diujikan pada komponen-komponen yang saling terhubung dan saling bergantung satu dengan yang lainnya. Tipe-tipe kesalahan yang mungkin terjadi, diantaranya : a. Kesalahan Tampilan (Interface errors) 1. Ujicoba jenis ini diaplikasikan pada bagian program dimana data dan kontrol dilemparkan dari satu modul ke modul lainnya. 2. Contoh yang paling umum menyertakan pemindahan kontrol proses dari modul ke subrutin atau subprogram. 3. Objek dari ujicoba adalah untuk menentukan bahwa argumen yang dilemparkan ke subrutin sesuai dengan parameter yang diterima. 4. Ujicoba diaplikasikan untuk memastikan kesesuaian jumlah field data, atribut (ukuran dan tipe) field data, dan perintah pemindahan dan penerimaan. b. Kesalahan Masukan/Keluaran(Input/output errors) 1. Ujicoba jenis ini diaplikasikan untuk memastikan bahwa seluruh record (file eksternal akan dibaca atau dituliskan) telah dipindahkan dan diterima seperti yang diharapkan. 2. Ujicoba diaplikasikan pada atribut record, termasuk jumlah field, ukuran field, dan tipe data yang terdapat dalam field. 3. Sebagai tambahan, kesalahan juga terlihat pada format record, organisasi file, dan penggunaan kunci. Idenya adalah untuk memastikan bahwa kunci yang digunakan sesuai dengan record dan file yang disusun dan direferensikan sesuai dengan kunci. 4. Ujicoba juga mencakup prosedur pembukaan dan penutupan file yang digunakan dan penanganan kesalahan pada input dan output. Memeriksa kesalahan dalam flagging pada kondisi end-of-file dan proses yang sesuai jika terjadi file null atau empty. 5. Dengan akses langsung pada file, ujicoba diaplikasikan untuk kesalahan yang terjasi jika record yang sesuai dengan kunci ditemukan, atau tidak. 6. Kegunaan ujicoba kesalahan input-output yang paling akhir adalah menemukan kesalahan output sistem, dimana prosedur ujicobanya adalah menghasilkan atau menampilkan output yang seharusnya. 7. Output ini kemudian diperiksa/disesuaikan dengan spesifikasi modul untuk memastikan bahwa proses yang akurat telah dilaksanakan terhadap data dan hasil yang diharapkan telah diberikan sesuai dengan format output. c. Kesalahan Struktur Data (Data structure errors) 1. Ujicoba ini mencari kesalahan dalam penanganan atau pembentukan elemen data yang didefinisikan dan dibangun dalam modul proses. 2. Contoh dapat menyertakan tabel-tabel atau record sementara yang digunakan untuk pemindahan data. Ujicoba diaplikasikan untuk perbaikan format dan atribut. 3. Ujicoba lainnya dapat berkenaan dengan definisi tabel, termasuk prosedur-prosedur utama dan ukuran tabel. 4. Pemerikasaan lainnya dilakukan untuk konsistensi pemakaian nama, untuk penginisialisasian counter dan akumulator dan untuk melengkapi spesifikasi data item. d. Kesalahan Aritmatika (Arithmetic errors) 1. Hasil dari instruksi perhitungandalam modul diujicobakan untuk menemukan kesalahan termasuk kesalahan pendefinisian sebagaimana mestinya seluruh data item yang ditermasuk dalam instruksi aritmatika. 2. Untuk setiap data item, ujicoba diaplikasikan untuk memastikan bahwa data berada dalam keadaan yang semestinya untuk eksekusi instruksi, bahwa ukuran dari hasil sementara dan hasil akhir sudah cukup besar untuk mengakomodasikan hasil perhitungan (eliminasi kesalahan potensial disebabkan pemotongan), bahwa, perhitungan dilaksanakan dengan perintah yang tepat untuk menghasilkan hasil yang telah dispesifikasikan sebelumnya, dan bahwa nilai nol tidak dapat digunakan sebagai pembagi. (Jika ditemukan dibagi dengan Nol, maka program harus dapat menangani kondisi ini) 2

3 e. Kesalahan Perbandingan (Comparison errors) 1. Ujicoba ini mencari kesalahan yang meliputi presentasi data item yang berbeda tipe atau bentuknya untuk fungsi-fungsi perbandingan. 2. Tujuannya adalah untuk memastikan bahwa program atau modul tidak akan mengizinkan operasi perbandingan antara field alphabetik dengan field numerik atau antara field numerik dengan bentuk yang berbeda. 3. Sama seperti fungsi ujicoba kesalahan lainnya, idenya adalah untuk menyajikan kondisi-kondisi seperti tersebut ke sistem dan memastikan bahwa sistem dapat menangani dan me-recovernya. 4. Ujicoba akan menjadi sulit untuk menetapkan fungsi-fungsi seperti operasi perbandingan jamak bersarang (multiple nested comparison) ditambilkan dengan perintah tertentu. f. Kesalahan Logika Kendali proses (Control Logic errors) 1. Computer merupakan mesin sekuensial. Karena itu tidak diperlukan ujicoba khusus untuk fungsi kontrol sekuensial. Tetapi ujicoba diaplikasikan untuk pemilihan dan pengulangan. 2. Ujicoba pemilihan untuk menetapkan apakah jalur eksekusi yang benar yang dilaksanakan untuk seluruh kondisi yang diujicobakan dan untuk semua nilai dari data item yang diujicoba. Juga terhadap seluruh titik percabangan dalam fungsi pemilihan diberi label yang tepat dan memiliki titik exit untuk semua jalur terbuka 3. Untuk struktur kontrol pengulangan, ujicoba diaplikasikan untuk memastikan bahwa index pengulangan telah diinisialisasikan dengan benar dan bahwa nilainya akan meningkat pada setiap iterasinya. ujicoba juga termasuk penetapan, pengujicobaan, dan pengimplementasian batas akhir loop untuk menghindari situasi loop berakhir karena hung-up. Prinsip pengaplikasian ujicoba pada modul yaitu : Ujicoba semua perintah sedikitnya satu kali Ujicoba semua kemungkinan kombinasi ekseskusi atau jalur logika Ujicoba seluruh pengulangan meliputi keseluruhan range dari indeks atau subscript-nya Ujicoba semua titik masukan dan keluaran untuk setiap modul 2. Sub (Integration ) Integrasi program meliputi prosedur-prosedur yang disertakan untuk menghubungkan modul-modul menjadi subsistem maupun sistem lengkap. Ujicoba integrasi dibangun dari spesifikasi sistem, meliputi ujicoba terhadap hubungan antar program-program untuk menentukan kemungkinan pelaksanaan dan kekuatannya. Ujicoba diaplikasikan dan diutamakan pada ujicoba interface antar modul dalam program aplikasi. Terdapat dua pendekatan yang dapat dilaksanakan : a. Incremental, modul dapat ditambahkan pada modul lainnya untuk ujicoba individual, biasanya berupa penulisan modul baru. b. Nonincremental, seluruh modul dalam program dapat dibangun terlebih dahulu, kemudian digabungkan dan diujicobakan sebagai satu entitas, sehingga seluruh interface dalam modul diujicoba dalam satu waktu untuk keseluruhan program. Terdapat dua metode untuk mengaplikasikan Incremental, yaitu : a. Top-down Diaplikasikan pada modul berbasis top-down/mengarah ke bawah berdasarkan kontrol hirarki., atau diproses dari modul level atas diturunkan sampai modul detail. Komponen-komponen high level dari sistem diintegrasikan dan diujicoba sebelum rancangan dan implementasinya lengkap. Penggabungan modul subordinate dengan modul utama dapat dilakukan dengan struktur depthfirst atau breadth-first. Integrasi depth-first akan mengintegrasikan modul dijalur utama, misal dari gambar dibawah A, B, E akan diintegrasikan lebih dulu, kemudian mengarah ke jalur tengah dan kanan Integrasi breadth-first akan mengintegrasikan secara langsung seluruh modul subordinate, misal B, C, D (stub D) akan diintegrasikan lebih dulu baru level dibawahnya Proses integrasi dilakukan dalam 5 tahapan : 1. Modul kontrol utama digunakan sebagai test driver dan stub disubtitusikan untuk seluruh modul yang secara langsung merupakan subordinate dari modul kontrol utama 3

4 2. Berdasarkan dari pendekatan integrasi yang dipilih, stub subordinat digantikan dengan modul yang sesungguhnya pada saat yang bersamaan. 3. Ujicoba dilaksanakan pada setiap modul yangtelah diintegrasikan 4. Pada setiap akhir dari serangkaian ujicoba, stub lainnya digantikan dengan modul yang sesungguhnya 5. Regression, (melaksanakan sebagian atau seluruhnya ujicoba sebelumnya) dapat dilaksanakan untuk memastikan apakah terdapat kesalahan baru. Proses akan berulang mulai dari langkah ke-2 sampai seluruh struktur program terbangun. Keterhubungan dibuat dari modul teratas ke modul dilevel bawahnya yang belum diimplementasikan. Untuk itu, bagian dari modul yang akan menangani interface disediakan dan digunakan dalam ujicoba eksekusi yang diaplikasikan ke hubungan modul high level dengan menggunakan modul subordinat. Rutin ujicoba seperti ini disebut program Stubs. Rutin ini mensimulasikan proses yang akan dijalankan ketika modul dikodekan. Selama ujicoba, stubs menyediakan target untuk pemanggilan subprogram sehingga modul superordinat dapat melatih fungsi kontrol mereka. Stubs juga dapat melemparkan data ke superordinat untuk menguji interface. Ujicoba dengan pendekatan top-down memberikan verifikasi awal dari interface utama dan juga keseluruhan logika kontrol, yang harus berasal dari tingkat teratas struktur program. Karena dimulai dari level atas kebawah, maka menjadi sangat mungkin untuk mendemonstrasikan fungsi program secara lengkap dan keseluruhan pada titik awal dari prosedur ujicoba. Perhatikan gambar berikut : A B C D E F G H I J Structure chart for program to be tested incrementally A sequence A StubB StubC StubD StubB StubC StubD StubE StubF b. Bottom-Up Ujicoba dimulai dari level terendah dari struktur program dan bergerak keatas sebagai sebuah modul yang diintegrasikan dan diujicoba. Prinsip yang hampir sama dengan top-down juga dilakukan diujicoba bottom-up, dimulai dari bagian input lalu bagian output sebagai strategi ujicoba keseluruhan. Sebuah driver dibangun untuk ujicoba modul pada low-level. Driver sama seperti Stubs tetapi kebalikannya. Driver merupakan modul ujicoba, atau rutin program yang membangkitkan 4

5 pemanggilan terhadap modul pada low-level dan melemparkan data melalui interface.driver mensimulasikan aksi dari grup yang belum dibangun dari superordinat ke modul yang diujicoba Keuntungan dari pendekatan bottom-up untuk mengujicoba identifikasi lebih dulu alur proses detail yang mungkin terjadi antar interface low-level dan melatih lebih dulu kasus input/output. Kekurangannya adalah pendekatan ini menunda kemampuan untuk menampilkan keseluruhan, kerangka program sampai seluruh modul telah diujicoba dan ditempatkan.strategi integrasi bottom-up dapat diimplementasikan dengan langkah-langkah berikut : 1. Modul low-level dikombinasikan kedalam cluster (kadang disebut builds) yang menampilkan subfungsi software khusus 2. Sebuah driver (program kontrol untuk ujicoba) dibuat untuk mengkoordinasikan kasus uji input dan output 3. Cluster diujioba 4. Driver dihapuskan dan cluster dikombinasikan mengarah keatas sesuai dengan struktur program perhatikan gambar berikut : DriverC DriverB DriverA E E F B E F Possible pattern for bottom-up incremental Terdapat 4 hal utama yang membedakan top-down dengan bottom up : 1. Architecture validation, ujicoba top-down mencari kesalahan pada arsitektur sistem dan level teratas didesain pada tahap awal proses pembentukan. Biasanya berupa kesalahan struktural, sehingga semakin cepat terdetesi akan mengurangi biaya. Sedangkan ujicoba bottom-up, desain level teratas tidak divalidasi sampai tahapan terakhir diproses. 2. demonstration, dengan ujicoba top-down demonstrasi sistem yang sudah dapat berjalan dapat dilakukan pada awal proses. Sedangkan dengan ujicoba bottom up, demonstrasi sistem dapat dilakukan bila yang dilakukan jika sistem dibangun dari komponen yang digunakan ulang. 3. Test implementation, ujicoba topdown sulit untuk diimplementasikan karena simulasi stubs program lower level dari sistem harus dibuat. Ketika digunakan ujicoba botom-up, harus menuliskan driver ujicoba untuk melatih komponen lower level. Ujicoba driver ini mensimulasikan komponen lingkungan dan pemanggilan komponen yang akan diujicoba. 4. Test observation, baik ujicoba top-down maupun bottom-up mempunyai masalah dengan ujicoba observasi. Pada top-down, level atas dari sistem yang telah diimplementasikan lebih dulu tidak dapat menghasilkan output, untuk mengujicoba level ini maka dibuat agar dapat menghasilkan output. begitu pula kebalikannya untuk pendekatan bottom-up c. Combined Methods Tidak ada aturan baku yang menetapkan kapan digunakan ujicoba dengan pendekatan topdown atau bottom-up dilaksanakan. Untuk keefektifan dapat juga dikombinasikan keduanya. Pada dasarnya semua pendekatan berbasis modul per modul, sehingga penting untuk menemukan perencanaan untuk ujicoba integrasi incremental dari hubungan dan interface yang ada dalam seluruh modul di sistem. 5

6 3. Function Ujicoba fungsi mengaplikasikan teknik black-box dalam mencari kesalahan atau kegagalan dalam paket software lengkap. Pada dasarnya ujicoba fungsi mengikuti ujicoba modul dan ujicoba integrasi. Sangat tidak mungkin menguji seluruh sistem sebelum seluruh modul diujicoba dan dibuat penyesuaian. Kemudian modul harus diintegrasi secara individual atau sekelompok kecil. Aturan khusus pada ujicoba fungsi adalah untuk melatih/mengamati keseluruhan program dengan tujuan untuk memastikan bahwa spesifikasi user eksternal untuk input dan output telah terpenuhi. Kriteria yang diaplikasikan pada ujicoba fungsi meliputi pengukuran atas komponen-komponen seperti: Format input Format output Organisasi file Akses file Interface manusia-komputer Fungsi program dilakukan untuk memastikan bahwa software beroperasi sesuai desain. Record input direpresentasikan untuk ujicoba fungsi yang menyertakan field data yang benar dan tidak. Termasuk situasi dimana nilai data alphanumerik lebih panjang daripada field yang telah didesain, atau penempatan nilai yang salah seperti nilai data numerik diberikan pada field alphanumerik. Parameter input dan output diperiksa untuk nilai elemen data yang benar dan salah untuk menetapkan kemampuan program dalam mengatasinya. Kriteria ujicoba validasi a. Validasi software diperoleh melalui serangkaian ujicoba black box yang mendemonstrasikan kesesuaian dengan permintaan/kebutuhan. b. Setelah setiap ujicoba fungsi/validasi dilakukan, terdapat 2 kondisi yang mungkin terjadi : (1.) Karakteristik fungsi atau performa sesuai dengan spesifikasi dan diterima, atau (2. ) ditemukannya penyimpangan dari spesifikasi dan menyebabkan defisiensi. Review Konfigurasi Elemen penting dalam proses validasi adalah configuration review seperti digambarkan dibawah ini. Review konfigurasi ini bertujuan untuk memastikan bahwa seluruh elemen konfigurasi software yang dibangun secara tepat dikatalogkan dan memiliki detail penting untuk dukungan pada fase pemeliharaan dalam software lifecycle. Ujicoba Alpha dan Beta a. Untuk pengembang software, hampir tidak mungkin mengetahui bagaimana customer menggunakan program. Instruksi yang diberikan mungkin akan diinterpretasikan secara salah. b. Ketika penyesuaian software dilakukan untuk seorang customer, maka serangkaian acceptance test harus dilakukan untuk memungkinkan customer memvalidasi kebutuhannya. c. Fungsi program dilakukan untuk memastikan bahwa software beroperasi sesuai desain. Record input direpresentasikan untuk ujicoba fungsi yang menyertakan field data yang benar dan tidak. d. Termasuk situasi dimana nilai data alphanumerik terlalu lebih panjang daripada field yang telah didesain, atau penempatan nilai yang salah seperti nilai data numerik diberikan pada field alphanumerik. e. Parameter input dan output diperiksa untuk nilai elemen data yang benar dan salah untuk menetapkan kemampuan program dalam mengatasinya. f. Jika software dibangun sebagai produk yang digunakan oleh beberapa customer, maka akan sangat tidak prakstis untuk melakukan acceptance test formal satu-persatu. g. Biasanya digunakan proses yang disebut alpha and beta, untuk menemukan kesalahan yang hanya bias ditemukan oleh end user. h. Ketika ujicoba alpha dilakukan, maka software dipergunakan sebagaimana mestinya, dengan pengembang software yang tetap mengawasi apa bila terjadi kesalahan. Atau dengan kata lain ujicoba alpha dilakukan dalam lingkungan yang terkontrol. i. Ujicoba beta dilakukan dari sisi end user, baik seorang maupun beberapa orang, dimana pihak pengembang tidak berada bersama para end user tersebut. Atau dengan kata lain, ujicoba beta j. dilakukan dalam lingkungan yang tidak terkontrol oleh pengembang. 6

7 k. Para pengguna akhir akan mencatat semua kesalahan yang terjadi dan melaporkannya kepada pihak pengembang dalam interval waktu tertentu. l. Dan sebagai hasilnya, pihak pengembang akan melakukan modifikasi dan melakukan persiapan untuk mengeluarkan produknya keseluruh pengguna. Configuration review(pressman, 1992) 4. Mengujicoba keseluruhan sistem dan properti yang ada. Aktivitas ujicoba sistem meliputi ujicoba sistem dan fungsi ujicoba penerimaan. Ketika dilaksanakan ujicoba sistem dan user terlibat didalamnya, maka tidak hanya menguji program tetapi mengujicoba kemampuan keseluruhan sistem. Program dapat berfungsi dengan baik ketika dibandingkan dengan spesifikasi. Ujicoba sistem dilakukan pada program setelah melalui ujicoba unit, integrasi dan fungsi. Ujicoba meliputi evaluasi kemampuan sistem untuk berfungsi dalam koordinasi-integrasi manual, off-line, mesin dan proses komputer untuk memastikan bahwa seluruh prosedur sudah cocok/sesuai dan dapat digabungkan. Hal lain yang terkait adalah mengujicoba kecukupan/kelayakan referensi manual bagi pengguna untuk memastikan ketepatan dan kecukupannya untuk memandu pengguna melaksanakan operasi hariannya dengan menggunakan sistem yang baru. Salah satu tujuannya adalah untuk menetapkan seberapa baiknya sistem dapat dioperasikan oleh orang-orang yang tidak terbiasa dengannya. Unit atau fungsi yang diujicoba harus menampilkan semirip mungkin dengan input, proses dan output yang sesungguhnya yang aka diberikan oleh sistem. Pada titik-titik tertentu dalan ujicoba sistem, komputer harus menangani sejumlah transaksi dan pemrosesan yang melebihi batas spesifikasi. Tujuannya adalah untuk mengetahui seberapa baiknya sistem menangani kelebihan beban. Selain itu untuk mengujicoba respon dan waktu pengiriman. Untuk sistem on-line, harus terdapat spesifikasi mengenai waktu yang dibutuhkan oleh sistem untuk menerima transaksi, melengkapi proses dan mengembalikan respon ke pengguna. Recovery 1. Beberapa system berbasis computer harus me-recover jika terjadi kesalahan dan mengulang proses dengan waktu yang telah ditentukan sebelumnya. 2. Ujicoba recovery merupakan ujicoba system yang memaksa software menjadi gagal dengan berbagai cara dan mem-verifikasi apakah recovery dilaksanakan secara tepat. 3. Jika recovery dilaksanakan secara otomatis, inisialisasi ulang, mekanisme checkpointing, recovery data, dan restart dievaluasi untuk perbaikan. 7

8 4. Jika recovery memerlukan intervensi manusia, waktu untuk perbaikan dievaluasi untuk memastikan apakah sesuai dengan limit yang ada Stress 1. Stress test didesain untuk menghadapkan program pada situasi yang abnormal. Secara mendasar, seseorang yang melakukan stress akan menanyakan : Seberapa jauh kita dapa menggunakan mesin ini sebelum mereka gagal? (How high can we crank this up before it fails??) 2. Stress mengeksekusi system dalam perilaku yang membutuhkan sumberdaya dalam jumlah, frekuensi dan volume yang abnormal. Contohnya : Tes khusus yang didesain untuk menghasilkan 10 interupsi/detik, dimana 1 atau 2 interupsi adalah rata-rata Range data masukan diperbesar untuk melihat bagaimana fungsi input akan bereaksi Kasus uji yang memerlukan memory maksimum atau sumber daya lain untuk dieksekusi Variasi dari stress merupakan teknik yang disebut sensitivity. Dalam beberapa situasi (kebanyakan dalan algoritma matematika) sejumlah kecil range dari data yang valid dalam suatu batasan tertentu dapat menyebabkan proses yang ektrin atau tidak lazim atau penurunan performa. Sensitivity berussaha untuk menemukan kombinasi data dalam class data yang valid yang dapat menyebabkan ketidakstabilan atau proses yang tidak sesuai Performance 1. Untuk sistem realtime atau embedded, software yang menyediakan fungsi yang dibutuhkan tetapi tidak sesuai dengan kebutuhan performanya, maka software tersebut tidak dapat diterima. 2. Performance didesain untuk menguji performa real time dari softwaredalam konteks integrated system. 3. Performance dilakukan dalam setiap tahapan dalam proses ujicoba, walaupun pada tahapan unit/modul sudah terlaksana melalui white box 4. Biasanya performance dipasangkan dengan stress dan membutuhkan instrumen hardware dan software. 5. Acceptance Ujicoba ini merupakan tahapan akhir dalam proses ujicoba sebelum sistem diterima untuk penggunaan operasional. Sistem diujicoba dengan data yang diberikan oleh pengguna (bukan data simulasi) untuk dinilai penerimaan/kelayakannya. Acceptance dapat mengungkapkan kesalahan dan penghilangan definisi kebutuhan sistem karena data sesungguhnya akan melatih sistem dengan cara yang berbeda dibandingkan data ujicoba. Acceptance juga dapat mengungkapkan masalah-masalah kebutuhan ketika fasilitas sistem tidak sesuai dengan kebutuhan user atau performa sistem tidak seperti yang diharapkan. Requirements specification specification design Detailed design Acceptance test plan integration test plan Sub-system integration test plan Module and unit code and tess Service Acceptance test integration test Sub-system integration test Phases 8

9 Programming and Debugging Programming and Debugging yaitu proses yang merubah desain kedalam program dan menghilangkan error yang ditimbulkan dari program. Programming merupakan aktivitas personal dan tidak terdapat proses generic programming. Seorang pemrogram hanya dapat melakukan beberapa ujicoba program untuk mencari kesalahan dan menghilangkan kesalahan ini dalam proses debugging. Locate eror Design eror repair Repair eror Re-test program Programming and Debugging Process Debugging terjadi sebagai konsekuensi dari keberhasilan ujicoba/, yaitu ketika uji kasus berhasil menemukan kesalahan, debugging merupakan proses yang memberi hasil dalam menghilangkan kesalahan-kesalahan tersebut. Debugging merupakan hasil dari ujicoba-ujicoba sebelumnya yang akan menempatkan dan memperbaiki kesalahan yang terjadi. Perhatikan gambar berikut : Debugging Proses debugging dimulai dari eksekusi uji, hasilnya diperkirakan dan kurangnya keterhubungan antara hasil yang diharapkan dengan hasil yang sesungguhnya akan ditemui. Dalam banyak kasus, data yang tidak salin gterhubung merupakan gejala yang merupakan penyebab dasar yang masih tersembunyi Prose debugging berusaha untuk menyesuaikan gejala dengan sebab yang akan mengarahkan pada perbaikan kesalahan Proses debugging akan selalu mempunyai salah satu dari 2 output yang mungkin : 1. Sebab akan ditemukan, diperbaiki dan dihilangkan 2. Sebab tidak ditemukan. Dalam kasus selanjutnya orang yang melaksanakan debugging akan memperkirakan penyebabnya, mendesain kasus uji untuk membantu mem-validasi kecurigaannya dan mengerjakan perbaikan secara iterative Beberapa pendekatan untuk membantu identifikasi dan menempatkan kesalahan, termasuk : 1. Memory dumps, tampilan sederhana yang menampilkan status dari memory pada saat itu, biasanya pada saat kesalahan(error) terdeteksi. Memory dumps memungkinkan untuk mencari data tertentu yang diproses secara salah. 9

10 2. Execution trace, menyebabkan komputer mencetak catatan dari urutan eksekusi program. Penelusuran pada umumnya akan mendaftar nama-nama modul yang dieksekusi. Penelusuran eksekusi disajikan sebagai tool untuk menentukan urutan proses dari suatu program. Jika program digagalkan karena suatu kesalahan, maka akan dapat ditemukan modul terakhir yang dieksekusi dan dititik ini perbaikan akan dilaksanakan. 3. Program desk checking, dilakukan melalui pemeriksaan detail dari source code yang mengakibatkan pengeksekusian logika dalam pikiran pemeriksa. Seorang programer yang berpengalaman dapat menelusuri logika dan perosesan data dengan me-review source code-nya. 4. Hypothesis, melihat program melalui metode analisis. Berlaku ketika programer mengaplikasikan teknik penanganan dan perbaikan masalah. Ketika satu kesalahan teridentifikasi, analisis dilakukan untuk menentukan jenis kesalahan pemrograman yang mungkin menghasilkan hasil tertentu. Hipotesis berisikan tentang dimana kemungkinan terjadi kesalahan dalam program dan jenis kesalahan apa yang menyebabkan deteksi kesalahan. Debugging Approaches Terdapat 3 kategori pendekatan dalam debugging A. Brute force 1. Merupakan metode yang paling umum dan efisien untuk mengisolasi kesalahan software. 2. Mengaplikasikan metode ini dengan menggunakan filosofi let the computer find the error 3. Menggunakan Memory dumps, tampilan sederhana yang menampilkan status dari memory pada saat itu, biasanya pada saat kesalahan(error) terdeteksi. Memory dumps memungkinkan untuk mencari data tertentu yang diproses secara salah. 4. Walaupun informasi yang dihasilkan sering sukses, tetapi memerlukan usaha dan waktu yang lebih banyak B. Backtracking 1. Merupakan metode debugging yang umum dan dapat digunakan pada program skala kecil 2. Dimulai dari saat gejala kesalahan terjadi, kode program ditelusuri kebelakang secara manual sampai saat kesalahan ditemukan 3. Execution trace, menyebabkan komputer mencetak catatan dari urutan eksekusi program. Penelusuran pada umumnya akan mendaftar nama-nama modul yang dieksekusi. Penelusuran eksekusi disajikan sebagai tool untuk menentukan urutan proses dari suatu program. Jika program digagalkan karena suatu kesalahan, maka akan dapat ditemukan modul terakhir yang dieksekusi dan dititik ini perbaikan akan dilaksanakan. 4. Program desk checking, dilakukan melalui pemeriksaan detail dari source code yang mengakibatkan pengeksekusian logika dalam pikiran pemeriksa. Seorang programer yang berpengalaman dapat menelusuri logika dan perosesan data dengan me-review source code-nya. 5. Sayangnya semakin banyak baris kode yang ditelususi maka proses akan semakin lama. C. Cause elimination 1. Data yang terkait dengan kesalahan diorganisasikan untuk mengisolasi penyebab potensial. 2. Hypothesis, melihat program melalui metode analisis. Berlaku ketika programer mengaplikasikan teknik penanganan dan perbaikan masalah. Ketika satu kesalahan teridentifikasi, analisis dilakukan untuk menentukan jenis kesalahan pemrograman yang mungkin menghasilkan hasil tertentu. Hipotesis berisikan tentang dimana kemungkinan terjadi kesalahan dalam program dan jenis kesalahan apa yang menyebabkan deteksi kesalahan. 1