Software Testing Strategies
Mata Kuliah Testing & Implementasi Sistem Program Studi Sistem Informasi 2013/2014 STMIK Dumai Materi 9 Pertemuan 12 & 13
--Acknowledgement
• Materi dari Chapter 17 – “Software Testing
Strategies.”
• Materi dalam slide ini sebagian besar diambil
dari slide buku [Pressman, 2010], mohon tidak
digunakan untuk keperluan lain selain kuliah
TIS.
• Sumber lain:
– Materi Testing dan Implementasi [Ayuliana, 2011]
– Teknik Pengujian Perangkat Lunak [Nur Cahyo]
Software Testing
• Testing adalah proses percobaan
penggunaan program dengan menguji
segala kemungkinan error untuk
mendapatkan software yang diterima oleh
pengguna.
Siapa yang Melakukan Testing?
developer independent tester
Mengerti sistem,
Namun akan melakukan testing sepengetahuannya, sesuai unit per fungsi sistem
Harus belajar tentang sistemnya, Akan banyak mencoba-coba
Apa yang diperlihatkan saat Testing
Errors
Kecocokan requirements
Performance sistem
Prinsip Pengujian
• Harus bisa dilacak hingga sampai ke
kebutuhan customer.
• Harus direncanakan sejak model dibuat.
• Prinsip Pareto: 80% error uncovered.
• Dari lingkup kecil menuju yang besar.
• Tidak bisa semua kemungkinan diuji.
Software yang Mudah Diuji
• Karakteristiknya:
– Operability: mudah digunakan.
– Observability: mudah diamati.
– Controlability: mudah dikendalikan.
– Decomposability: mudah diuraikan.
– Simplicity: lingkup kecil, semakin mudah diuji.
– Stability: jarang berubah.
Strategi Testing
• Strategi testing software mengintegrasikan
metode-metode disain test cases ke dalam
suatu rangkaian tahapan yang terencana
dengan baik sehingga pengembangan
software dapat berhasil.
• Strategi menyediakan peta yang menjelaskan
tahap-tahap yang harus dilakukan sebagai
bagian dari testing, dan membutuhkan usaha,
waktu, serta sumber daya untuk tahap-tahap
ini dilaksanakan.
Strategi Testing …(2)
• Strategi testing menjadi satu kesatuan dengan:
– perencanaan tes,
– disain test case,
– ekesekusi tes,
– pengumpulan serta evaluasi data hasil testing.
• Strategi testing software harus fleksibel untuk
mengakomodasi kustomisasi testing.
• Pada saat yang bersamaan, juga harus
konsisten dan tegas agar dapat melakukan
Karakteristik Kerangka Testing
• Karekteristik umum kerangka testing:
– Testing dimulai dari tingkat komponen terkecil sampai pada integrasi antar komponen pada keseluruhan
sistem komputer tercapai.
– Teknik testing berbeda-beda sesuai dengan waktu penggunaannya.
– Testing dilakukan oleh pengembang software dan
(untuk proyek besar) dilakukan oleh suatu grup tes yang independen.
– Testing dan debugging adalah aktivitas yang berlainan, tapi debugging harus diakomodasi disetiap strategi
Verifikasi vs. Validasi
• Testing software sering dikaitkan dengan verifikasi dan validasi (V&V).
• Verifikasi merupakan sekumpulan aktivitas yang
memastikan software telah melakukan fungsi tertentu dengan benar.
• Validasi merupakan sekumpulan aktivitas yang memastikan bahwa software yang dibangun dapat dilacak terhadap
kebutuhan/permintaan pelanggan. • Menurut Boehm:
– Verifikasi “Are we building the product right?” – Validasi “Are we building the right product?”
• Verifikasi:
– “Apakah kita membangun produk dengan
benar?”
– Software seharusnya sesuai dengan
spesifikasinya. Gunakan proses software yang
bagus.
• Validasi:
– “Apakah kita membangun produk yang benar?”
– Software seharusnya melakukan apa yang
pengguna benar-benar butuhkan
Tentang Testing
• Testing merupakan basis (fase) terakhir dimana
kualitas dapat dinilai dan error dapat diidentifikasi.
• Tapi testing tidak boleh dipandang sebagai jaring
pengamanan.
• “Anda tidak dapat melakukan tes terhadap kualitas.
Jika kualitas tidak ada sebelum Anda memulai testing,
maka kualitas juga tidak akan ada saat Anda selesai
melakukan testing.”
• Kualitas dibangun ke dalam software sepanjang proses
rekayasa software.
Tentang Testing
• Penerapan metode dan alat bantu, manajemen dan
pengukuran yang solid, akan mengarah pada kualitas
yang ditetapkan pada saat testing berlangsung.
• Dari Miller:
“Motivasi yang patut digaris bawahi dari testing adalah
untuk memberikan dukungan kualitas software
dengan metode-metode yang dapat diaplikasikan
secara ekonomis dan efektif baik pada sistem berskala
besar atau sistem berskala kecil.”
Pengorganisasian Testing
Software
• Tujuannya:
Untuk mengurangi resiko terjadinya konflik, dan mempersiapkan diri apabila konflik tetap terjadi.
• Ada sejumlah konsep yang salah tentang testing, antara lain:
– Pengembang software tidak perlu melakukan testing sama sekali.
– Software diberikan pada orang lain (yang tak dikenal
kredibilitasnya), yang akan melakukan tes pada software tersebut tanpa pemahaman dan salah arah.
– Tester baru bekerja atau ikut serta ke dalam proyek, hanya apabila tahap testing pada proyek tersebut
Unit Testing
Modul 1
Kumpulan Test case
Modul #n
Unit Testing Modul 1
Modul 2
Unit Testing Modul 2
Unit Testing
• Unit testing berfokus pada usaha verifikasi pada unit terkecil dari disain software komponen atau modul software.
• Penggunaan diskripsi disain tingkat komponen sebagai
tuntunan, jalur kendali yang penting dites untuk menemukan
errors, terbatas hanya pada modul tersebut.
• Kompleksitas relatif terhadap tes dan errors yang dibatasi oleh cakupan yang telah ditetapkan pada unit testing.
• Unit testing berorientasi pada testing white box, dan tahapan dapat dilakukan secara paralel pada banyak komponen.
Unit Testing
Modul yang akan ditest test cases results software engineerTes yang Terdapat di Unit Testing
• Modul antar muka dites untuk memastikan aliran informasi, apakah telah berjalan seperti yang diharapkan (masuk dan
keluar dari unit program yang dites)
• Struktur data lokal diperiksa untuk memastikan apakah
penyimpanan data telah merawat integritasnya secara temporal selama tahap eksekusi algoritma
• Batasan kondisi dites untuk memastikan modul beroperasi dengan benar pada batasan yang telah ditetapkan untuk limitasi atau batasan pemrosesan
• Semua jalur independen (basis paths) pada struktur kendali diperiksa untuk memastikan apakah semua pernyataan dalam modul telah dieksekusi minimal sekali
Unit Testing
interface
struktur data lokal batasan kondisi
bagian yang independent bagian penanganan error
Modul yang akan ditest
Lingkungan Unit Test
Module Stub driver HASIL AKHIR test cases interfacestruktur data lokal batasan kondisi
bagian yang independent bagian penanganan error
• Tes aliran data antar modul dibutuhkan sebelum
inisialisasi tes lainnya.
– Jika data tidak masuk dan keluar dengan benar, semua tes lainnya akan beresiko gagal.
– Sebagai tambahan, struktur data lokal harus diperiksa dan akibat pada keseluruhan data ditentukan (jika
memungkinkan) selama unit testing.
Perlu diperhatikan pada Unit Testing
• Pemilihan jalur eksekusi testing adalah tugas yang
esensial selama unit test.
• Test cases harus didisain untuk melihat:
– kesalahan dari komputasi yang salah, – komparasi yang tidak benar,
– alur kendali yang tak tepat.
• Basis path dan loop testing adalah teknik yang efektif
untuk hal ini.
• Kesalahan komputasi yang umum terjadi:
– Kesalahan prioritas aritmetik. – Mode operasi campuran.
– Ketidakakuratan presisi.
– Kesalahan representasi simbolik dari ekspresi.
• Komparasi dan alur kendali merupakan satu
kesatuan. Biasanya perubahan alur kendali
terjadi setelah komparasi.
• Test case harus mencakup kesalahan:
– Komparasi tipe data berbeda
– Operator logika dan prioritas yang tak benar – Terminasi loop yang tidak konsisten atau tidak
semestinya.
– Kegagalan apabila konflik iterasi terjadi.
Kesalahan Umum Testing
• Kesalahan potensial yang harus dites saat evaluasi
penanganan kesalahan:
– Diskripsi kesalahan tidak jelas.
– Catatan kesalahan tidak berfungsi untuk
menghitung kesalahan.
– Diskripsi kesalahan tidak menyediakan informasi
yang cukup untuk mengarahkan penyebab
kesalahan.
– Tidak adanya prioritas kesalahan
– Kesalahan data, kesalahan sistem, atau yang lainnya
tidak dipilah dengan benar
• Pada kebanyakan aplikasi, drivers tidak lebih dari
“program utama” yang menerima data test case,
memasukkan data ke komponen yang dites, dan
mencetak hasil yang bersangkutan.
• Stubs berlaku untuk menggantikan modul-modul
yang merupakan subordinat (dipanggil oleh)
komponen yang dites. Stub atau “dummy
subprogram” menggunakan antar muka modul
subordinat, mungkin melakukan manipulasi data
minimal, mencetak masukan verifikasi, dan
mengembalikan kendali ke modul yang sedang dites.
• Drivers dan stubs menimbulkan biaya lebih. Karena
software harus ada penambahan kode (biasanya
tidak berdasarkan disain formal), yang tidak
diikutsertakan saat produk software dirilis.
• Pada kasus-kasus tertentu, testing dapat ditunda
penyelesaiannya (kondisi komplit) sampai tahap
integration test (dimana drivers atau stubs juga
digunakan).
• Unit testing disederhanakan bila suatu
komponen didisain dengan kompleksitas
tinggi.
• Ada beberapa situasi dimana sumber daya
tidak mencukupi untuk melakukan unit testing
secara komplit.
• Untuk itu perlu melakukan pemilihan
modul-modul yang kritis dan yang mempunyai
kompleksitas tinggi, untuk unit testing.
Integration Testing
• Integrasi testing meliputi prosedur-prosedur yang disertakan untuk menghubungkan modul-modul menjadi subsistem
maupun sistem lengkap.
• Ujicoba integrasi dibangun dari spesifikasi sistem, yaitu ujicoba terhadap hubungan antar program-program untuk
menentukan kemungkinan pelaksanaan dan kekuatannya. • Ujicoba diaplikasikan dan diutamakan pada ujicoba interface
Integration Testing
• Terdapat dua pendekatan yang dapat dilaksanakan:
– Incremental testing, modul dapat ditambahkan pada
modul lainnya untuk ujicoba individual, biasanya berupa
penulisan modul baru.
– Nonincremental testing, 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.
Integration Testing Strategies
Options:
• Pendekatan “big bang”
Incremantal Testing
• Terdapat beberapa metode untuk
mengaplikasikan Incremental testing, yaitu :
a. Top-down testing
b. Bottom-up testing
c. Kombinasi (Sandwich Testing)
d. Regression & Smoke Testing
Top-Down Integration
Modul teratas dites per sub modul
Tes satu sub modul, dan tes sub-sub modul yang ada di dalamnya
Lakukan hingga hirarki terbawah
A
B
C
D E
Top-Down Integration
Urutannya: •M1 •M2 •M5 •M8 •M6 •M3 •M7 •M4Top Down Integration
• 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 adalah A,
• B, C, D akan diintegrasikan lebih dulu, kemudian mengarah ke jalur tengah dan kanan
• Integrasi breadth-first akan mengintegrasikan secara langsung seluruh modul subordinate.
Bottom-Up Integration
drivers digunakan sekali dalam
satu waktu, jalur depth didahulukan
Modul-modul ini digrup terlebih dahulu, untuk kemudian dites secara integrasi
A B C D E F G cluster
Bottom-Up Integration
• 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
Bottom-Up Integration
• 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 merupakan modul ujicoba, atau rutin program yang membangkitkan 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
Bottom-Up Integration
• 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.
Top-Down vs 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. System 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
Top-Down vs Bottom-Up
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
Metode Testing Kombinasi
Ciri-cirinya:
• Tidak ada aturan baku yang menetapkan kapan
digunakan ujicoba dengan pendekatan topdown
atau bottom-up dilaksanakan.
• Untuk keefektifan dilakukan dikombinasikan
keduanya.
• Pada dasarnya sama-sama menggunakan metode
modul per modul.
Sandwich Testing
Top modules are tested with stubs
Worker modules are grouped into builds and integrated
A B C D E F G cluster
Regression Testing
• Regression testing: dilakukan pengujian setiap
kali ada modul baru yang diintegrasikan atau
ada modul yang berubah.
• Smoke testing: test daily, untuk proyek jenis
kritis-waktu.
Higher Order Testing
• Validation testing
– Fokus pada requirement sistem • Alpha/Beta testing
– Fokus pada penggunaan kustomer • System testing
– Recovery testing
• Verifikasi kemampuan recovery sistem – Security testing
• Fokus pada proteksi sistem – Stress testing
• Tes sistem pada kondisi yang abnormal – Performance Testing
Validasi Testing
• Kriteria yang diuji pada saat validasi testing antara lain:
– Format input – Format output – Organisasi file – Akses file
– Interface
• Ujicoba ini mengaplikasikan teknik black-box dalam mencari kesalahan atau kegagalan dalam paket software lengkap. • Pada dasarnya validasi mengikuti ujicoba modul dan ujicoba
integrasi.
• Sangat tidak mungkin menguji seluruh sistem sebelum seluruh modul diujicoba dan dibuat penyesuaian.
Validasi Testing
• Fungsi program dites untuk memastikan kesesuaian
dengan 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.
Alpha & Beta Testing
• Biasanya proses yang disebut alpha and beta
testing, digunakan untuk menemukan kesalahan
yang hanya bisa ditemukan oleh end user.
• Ketika ujicoba alpha dilakukan, maka software
dipergunakan sebagaimana mestinya, dengan
pengembang software yang tetap mengawasi
apabila terjadi kesalahan. Atau dengan kata lain
ujicoba alpha dilakukan dalam lingkungan yang
terkontrol.
Alpha & Beta Testing
• 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 dilakukan dalam lingkungan yang tidak terkontrol oleh pengembang.
• Para pengguna akan mencatat semua kesalahan yang terjadi dan melaporkannya kepada pihak pengembang dalam interval waktu tertentu.
• Sebagai hasilnya, pihak pengembang akan melakukan
modifikasi dan melakukan persiapan untuk mengeluarkan produknya ke seluruh pengguna.
Alpha & Beta Testing
• Disebut sukses jika fungsi P/L dapat diterima oleh
kustomer (berdasarkan dokumen SKPL).
Kesimpulannya …
• Alpha test: dilakukan di tempat developer oleh
customer pada lingkungan yang terkendali.
• Beta test: dilakukan di tempat customer tanpa
melibatkan developer pada lingkungan yang tak
terkendali.
System Testing
• Mengujicoba keseluruhan sistem dengan lingkungannya. • Tidak hanya menguji program tetapi juga mengujicoba
kemampuan keseluruhan sistem.
• Program dapat berfungsi dengan baik ketika dibandingkan dengan spesifikasi.
• Ujicoba sistem dilakukan pada program setelah melalui testing 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
System Testing
• Meguji sistem berbasis komputer secara
menyeluruh, termasuk juga hubungannya dengan
sistem yang lain.
• Diantaranya:
– Recovery testing, jika system failure. – Security testing, jika terjadi serangan.
– Stress testing, terhadap jumlah, frekuensi dan volume pekerjaan.
– Performance testing, untuk mengukur pemakaian sumber daya.
Recovery testing
• Beberapa sistem berbasis komputer harus mampu me-recover jika terjadi kesalahan, dan mengulang proses dengan waktu yang telah ditentukan sebelumnya.
• Ujicoba recovery merupakan ujicoba sistem yang memaksa
software menjadi gagal dengan berbagai cara dan memverifikasi apakah recovery dilaksanakan secara tepat.
• Jika recovery dilaksanakan secara otomatis, maka lakukan
pengecekan inisialisasi ulang, mekanisme checkpointing, recovery data, dan restart.
• Jika recovery memerlukan bantuan manusia, waktu untuk
perbaikan dievaluasi untuk memastikan apakah sesuai dengan limit/batas waktu yang ada.
Security Testing
• Melakukan verifikasi terhadap proteksi sistem,
• Proteksi login-logout
• Proteksi pada tiap tipe user (apakah admin, user biasa atau yang lainnya)
Stress Testing
• Stress test didesain untuk menghadapkan program pada situasi yang abnormal.
• Secara mendasar, seseorang yang melakukan stress testing akan menanyakan: Seberapa jauh kita dapat menggunakan mesin ini sebelum mereka gagal?
• Stress testing mengeksekusi sistem dalam perilaku yang membutuhkan sumberdaya dalam jumlah, frekuensi dan volume yang abnormal.
• Contoh: Tes jika 100 user melakukan edit profil dalam waktu bersamaan, bagaimana fungsi input akan bereaksi.
• Intinya, kasus uji yang memerlukan memory maksimum atau sumber daya lain untuk dieksekusi.
Stress Testing
• Variasi dari stress testing merupakan teknik
yang disebut sensitivity testing.
• Dalam beberapa situasi (kebanyakan dalam
algoritma matematika) sejumlah range data
yang valid dalam suatu batasan tertentu
dapat menyebabkan proses yang tidak lazim
atau penurunan performa.
Performance Testing
• Untuk sistem realtime atau embedded, software yang menyediakan fungsi yang dibutuhkan tetapi tidak sesuai dengan kebutuhan performanya, maka software tersebut tidak dapat diterima.
• Performance testing didesain untuk menguji performa real time dari software dalam konteks integrasi sistem.
• Performance testing dilakukan dalam setiap tahapan testing, walaupun pada tahapan unit/modul sudah terlaksana melalui white box testing
• Biasanya performance testing dipasangkan dengan stress testing dan membutuhkan instrumen hardware dan
Acceptance Testing
• 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 testing dapat mengungkapkan kesalahan dan
penghilangan definisi kebutuhan sistem karena data
sesungguhnya akan melatih sistem dengan cara yang berbeda dibandingkan data ujicoba.
• Acceptance testing juga dapat mengungkapkan
masalah-masalah kebutuhan ketika fasilitas sistem tidak sesuai dengan kebutuhan user atau performa sistem tidak seperti yang
Tahapan Testing
High Order Testing Integrasi Testing Unit Testing Top-Down Kombinasi (Sandwich) Bottom-Up Validasi Testing Alpha/Beta Testing System Testing Recovery Testing Performance Testing Security Testing Stress Testing Acceptance Testing
Debugging
• Memperbaiki error yang ditemukan pada saat
testing (yang sukses).
• Kaidah dasar sebelum debug:
– Apakah penyebab bug dihasilkan kembali oleh
bagian program yang lain?
– Apakah ada bug selanjutnya yang mungkin
muncul jika suatu bug diperbaiki?
– Apa yang bisa dilakukan untuk mencegah bug
terjadi untuk pertama kalinya?
Debugging
• Debugging terjadi sebagai konsekuensi dari
keberhasilan ujicoba/testing, 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.
Gejala & Penyebab
gejala
(symptom) penyebab (cause)
Gejala dan penyebab suatu error bisa terjadi di tempat berbeda
Gejala error bisa terjadi saat error yang lain baru saja diperbaiki
Penyebab error bisa terjadi akibat dari kesalahan kompilasi
Penyebab error dapat terjadi dari asumsi semua orang
Ada gejala error yang terjadi hanya sesekali saja
Konsekuensi Bugs
Tingkat Kerusakan
RinganMengganggu (annoying)
Menjengkelkan (disturbing) Serius Ekstrim Bencana Infeksi Tipe Bug
Bug Categories: function-related bugs,
system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards
Proses
Debugging
Proses Debugging:
Locate error Desain perbaikan error Perbaiki Error Re-test program
• Proses debugging dimulai dari eksekusi uji, hasilnya
diperkirakan dan kurangnya keterhubungan antara hasil yang diharapkan dengan hasil yang sesungguhnya akan ditemui.
Proses
Debugging
• 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
Pendekatan Debugging
Beberapa pendekatan untuk membantu identifikasi antara lain:
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.
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
Pendekatan Debugging
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 testing, 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.
Teknik Debugging
Terdapat 3 kategori pendekatan dalam debugging:
• A. Brute force
– 1. Mengaplikasikan metode ini dengan menggunakan filosofi ”let the computer find the error”
– 2. 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.
– 3. Walaupun informasi yang dihasilkan sering sukses, tetapi memerlukan usaha dan waktu yang lebih
Teknik Debugging
• B. Backtracking
– 1. Merupakan metode yang umum 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.
Teknik Debugging
• C. Cause elimination
– 1. Data yang terkait dengan kesalahan diorganisasikan untuk mengisolasi penyebab potensial.
– 2. Hypothesis testing, 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.
