software testing strategies

SOFTWARE TESTING STRATEGIES

Software validationValidasi 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 ?”

Sub-systemtesting

Moduletesting

Unittesting

Systemtesting

Acceptancetesting

Componenttesting

Integration testing Usertesting

The testing process

Relationship between system development and testing activities(Adams, Powers, Owles, 1985)

Ayuliana/Testing dan Implementasi/Feb2011

System Analysis

System Design

SoftwareDesign

Program Design

ModuleDesign

PROGRAMMING

AcceptanceTesting

System Testing

Function Testing

Integration Testing

Unit Testing

UserSpesification

SystemSpesification

SoftwareSpesification

ProgramSpesification

ModuleSpesification

1

Tahapan-Tahapan Ujicoba1. Unit Testing/Module Testing

Unit testing/Module Testing 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)

Ayuliana/Testing dan Implementasi/Feb2011 2

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 System Testing (Integration Testing)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 testing, modul dapat ditambahkan pada modul lainnya untuk ujicoba individual, biasanya berupa penulisan modul baru.

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

Terdapat dua metode untuk mengaplikasikan Incremental testing, yaitu :a. Top-down testing

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 depth-first 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


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 diintegrasikan4. Pada setiap akhir dari serangkaian ujicoba, stub lainnya digantikan dengan modul yang

sesungguhnya5. Regression testing, (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 :

Structure chart for program to be tested incrementally

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


A

B C D

HGFE I J

A

StubB StubC StubD StubB

A

StubC StubD

StubE StubF

Testing sequence

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 diujioba4. Driver dihapuskan dan cluster dikombinasikan mengarah keatas sesuai dengan struktur

program

perhatikan gambar berikut :

Possible testing pattern for bottom-up incremental testing

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. 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 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 Testing Methods

Tidak ada aturan baku yang menetapkan kapan digunakan ujicoba dengan pendekatan top-down 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.


DriverC

E

DriverB

E F

DriverA

E F

B

3. Function Testing 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 validasia. 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 KonfigurasiElemen 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 Betaa. 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 testing, 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.


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. System Testing 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 testing1. 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.


4. Jika recovery memerlukan intervensi manusia, waktu untuk perbaikan dievaluasi untuk memastikan apakah sesuai dengan limit yang ada

Stress Testing1. Stress test didesain untuk menghadapkan program pada situasi yang abnormal. Secara mendasar,

seseorang yang melakukan stress testing akan menanyakan : Seberapa jauh kita dapa menggunakan mesin ini sebelum mereka gagal ? (How high can we crank this up before it fails??)

2. Stress testing 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 testing merupakan teknik yang disebut sensitivity testing. 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 testing berussaha untuk menemukan kombinasi data dalam class data yang valid yang dapat menyebabkan ketidakstabilan atau proses yang tidak sesuai

Performance testing1. 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 testing didesain untuk menguji performa real time dari softwaredalam konteks integrated

system.3. Performance testing dilakukan dalam setiap tahapan dalam proses ujicoba, walaupun pada tahapan

unit/modul sudah terlaksana melalui white box testing4. Biasanya performance Testing dipasangkan dengan stress testing dan membutuhkan instrumen

hardware dan software.

5. 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 diharapkan.

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

Service Acceptancetest

Systemintegration test

Sub-systemintegration test

Testing Phases


Programming and DebuggingProgramming 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.

Locateerror

Designerror repair

Repairerror

Re-testprogram

Programming and Debugging Process

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

• 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 dihilangkan2. 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.


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

Debugging ApproachesTerdapat 3 kategori pendekatan dalam debuggingA. 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. Backtracking1. Merupakan metode debugging yang umum dan dapat digunakan pada program skala kecil2. Dimulai dari saat gejala kesalahan terjadi, kode program ditelusuri kebelakang secara manual sampai

saat kesalahan ditemukan3. 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 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.


software testing strategies

Documents