Software Testing Strategies

Mata Kuliah Testing & Implementasi Sistem Program Studi Sistem Informasi 2013/2014 STMIK Dumai -- Materi 9 --- Pertemuan 12 & 13 --

Software Testing Strategies This presentation is revised by Hazlinda A., STMIK, 2013

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] 2

Software Testing • Testing adalah proses percobaan penggunaan program dengan menguji segala kemungkinan error untuk mendapatkan software yang diterima oleh pengguna.

3

Siapa yang Melakukan Testing?

developer Mengerti sistem, Namun akan melakukan testing sepengetahuannya, sesuai unit per fungsi sistem

independent tester Harus belajar tentang sistemnya, Akan banyak mencoba-coba Dan memperhatikan kualitas

4

Apa yang diperlihatkan saat Testing Errors

Kecocokan requirements Performance sistem

Indikasi kualitas

5

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. • Dilakukan oleh pihak ketiga yang independen.

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. Understandability: mudah dipahami.

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

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 perencanaan yang logis. 9

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

10

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?” 11

Verifikasi vs. Validasi …(2) • 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. 13

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

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

Strategi Testing

16

Tahapan Testing

17

Unit Testing

18

Unit Testing Modul 1

Modul 2

Unit Testing Modul 1

…

Modul #n

Unit Testing Modul 2

Kumpulan Test case

19

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

Unit Testing

Modul yang akan ditest

results software engineer

test cases

21

Tes 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 • Semua jalur penanganan kesalahan (error) dites. 22

Unit Testing Modul yang akan ditest interface struktur data lokal batasan kondisi bagian yang independent bagian penanganan error

test cases 23

Lingkungan Unit Test driver interface struktur data lokal

Module

batasan kondisi bagian yang independent bagian penanganan error

Stub

Stub

test cases

HASIL AKHIR 24

Perlu diperhatikan pada Unit Testing • 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.

25

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

Perlu diperhatikan pada Unit Testing • 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.

27

Cakupan Test Case • 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.

28

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 29

Driver & Stub • 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. 30

Prosedur-prosedur unit test • 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).

31

Prosedur-prosedur unit test • 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 modulmodul yang kritis dan yang mempunyai kompleksitas tinggi, untuk unit testing. 32

Integration Testing

33

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 antar modul dalam program aplikasi.

34

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

Integration Testing Strategies Options: • Pendekatan “big bang” • Strategi konstruksi yang incremental

36

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

37

Top-Down Integration A

B

F

Modul teratas dites per sub modul

G

Tes satu sub modul, dan tes sub-sub modul yang ada di dalamnya C

Lakukan hingga hirarki terbawah D

E

38

Top-Down Integration Urutannya: •M1 •M2 •M5 •M8 •M6 •M3 •M7 •M4

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

Bottom-Up Integration A

B

F

G

drivers digunakan sekali dalam satu waktu, jalur depth didahulukan C

D

E

Modul-modul ini digrup terlebih dahulu, untuk kemudian dites secara integrasi

cluster 41

Bottom-Up Integration

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 mengarah keatas sesuai dengan struktur program 43

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

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

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 komponen yang digunakan ulang. 46

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 kebalikannya untuk pendekatan bottom-up 47

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

Sandwich Testing A

B

F

Top modules are tested with stubs

G

C Worker modules are grouped into builds and integrated

D

E cluster 49

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.

High Order Testing

51

Review …

52

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 • Fokus pada performa dari keseluruhan sistem

53

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

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

Configuration Review

(Pressman, 1992)

56

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

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

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 prosedur sudah cocok/sesuai dan dapat digabungkan. 60

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

Security Testing • Melakukan verifikasi terhadap proteksi sistem, • Proteksi login-logout • Proteksi pada tiap tipe user (apakah admin, user biasa atau yang lainnya) • Proteksi fungsi dan fitur-fitur lainnya (jika ada)

63

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

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

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

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 masalahmasalah kebutuhan ketika fasilitas sistem tidak sesuai dengan kebutuhan user atau performa sistem tidak seperti yang diharapkan. 67

Tahapan Testing

Unit Testing

Top-Down

Integrasi Testing

Bottom-Up

Kombinasi (Sandwich)

Recovery Testing

High Order Testing

Validasi Testing

Security Testing

Alpha/Beta Testing

Stress Testing

System Testing

Performance Testing

Acceptance Testing 68

Debugging

69

Debugging: Sebuah proses Diagnosa

70

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

The Debugging Process

73

Gejala & Penyebab 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

gejala (symptom)

penyebab (cause)

Ada gejala error yang terjadi hanya sesekali saja

74

Konsekuensi Bugs Infeksi Tingkat Kerusakan Bencana Ekstrim Serius Menjengkelkan (disturbing) Mengganggu (annoying) Ringan

Tipe Bug Bug Categories: function-related bugs, system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards violations, etc. 75

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

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 kecurigaannya dan mengerjakan perbaikan secara iterative

77

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 menentukan urutan proses dari suatu program.

78

Pendekatan Debugging 3.

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

79

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 banyak 80

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

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

Kesimpulan • Pengujian software adalah elemen kritis dari jaminan kualitas software dan merupakan review puncak terhadap spesifikasi, desain dan pembuatan program. • Pengujian software menghabiskan upaya 30-40% dari total pekerjaan proyek. • Untuk proyek yang membahayakan nyawa manusia, biaya pengujian bisa 3-5 X proyek biasa. • Test case yang bagus adalah yang memiliki kemungkinan terbesar untuk menemukan error yang tersembunyi. • Pengujian yang sukses adalah yang berhasil menemukan error yang tersembunyi.

Next week …

Teknik Testing

84