Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Unit Testing Software Quality Eko Prasetyo Teknik Informatika Univ. Pembangunan Nasional Veteran Jawa Timur 2011 1.

Presentasi serupa


Presentasi berjudul: "Unit Testing Software Quality Eko Prasetyo Teknik Informatika Univ. Pembangunan Nasional Veteran Jawa Timur 2011 1."— Transcript presentasi:

1 Unit Testing Software Quality Eko Prasetyo Teknik Informatika Univ. Pembangunan Nasional Veteran Jawa Timur

2 Hirarki Testing 2

3 Unit Testing Level pertama dalam testing Merupakan pengujian unit program secara terpisah ◦ Kadang disebut fungsi, prosedur, method ◦ Kelas dalam OOP, juga dianggap unit Secara sintaksis, unit program adalah potongan kode, seperti fungsi atau method dari kelas, yang dihubungkan dari luar unit dan dapat juga berkaitan dengan unit program yang lain. Unit program diasumsikan mengimplementasikan fungsi dengan baik, memberikan level abstaksi yang pasti dari level fungsi yang lebih tinggi. Sebuah unit program diuji secara terisolasi (stand alone). Alasan pengujian unit dalam kondisi terisolasi (stand-alone manner): ◦ Pertama, error yang ditemukan selama pengujian dapat dikaitkan pada unit khusus yang dapat dengan mudah diperbaiki. Selain itu, unit testing menghilangkan ketergantungan pada unit program yang lain. ◦ Kedua, selama unit testing, perlu menverifikasi bahwa setiap eksekusi yang berbeda dari program, memberikan hasil seperti yang diharapkan. Programmer mempunyai akses langsung pada vektor masukan dari unit dengan mengeksekusi unit program terpisah. 3

4 Programmer perlu menguji unit sebagai berikut: Mengeksekusi setiap baris kode ◦ Hal ini dibutuhkan, karena programmer perlu mengetahui apa yang terjadi ketika baris kode dieksekusi. ◦ Tidak adanya pengamatan mendasar, akan mengejutkan dibelakang bahwa biaya perbaikan sangat mahal. Mengeksekusi setiap predikat dalam unit untuk mengevaluasi unit tersebut benar atau salah secara terpisah. Mengamati bahwa unit melakukan fungsi yang dimaksudkan dan memastikan bahwa tidak mengandung kesalahan diketahui 4

5 Programmer perlu menguji unit Tidak ada jaminan bahwa unit yang teruji dengan memuaskan secara fungsional benar dari perspektif keseluruhan sistem Tidak semuanya yang berkaitan dengan unit dapat diuji secara terpisah karena keterbatasan pengujian dalam isolasi. ◦ Ini berarti bahwa beberapa kesalahan dalam unit program hanya dapat ditemukan kemudian, ketika unit ini terintegrasi dengan unit lain dalam fase integration testing dan testing system Meskipun tidak mungkin untuk menemukan semua kesalahan dalam unit program yang terpisah, ◦ tetap masih perlu untuk memastikan bahwa unit bekerja secara memuaskan sebelum digunakan oleh unit-unit program lain. 5

6 Ada 2 fase unit testing Static unit testing ◦ Programmer tidak mengeksekusi unit, melainkan kode tersebut diperiksa atas segala kemungkinan perilaku yang mungkin timbul selama run time. ◦ non-execution-based unit testing, Dynamic unit testing ◦ execution-based unit testing 6

7 Static unit testing Dalam static unit testing, kode ditinjau dengan menerapkan teknik umum Disebut juga inspection and walkthrough. ◦ Inspection: Merupakan langkah-demi-langkah tinjauan peer group suatu hasil kerja, dengan setiap langkah diperiksa terhadap kriteria yang telah ditentukan. ◦ Walkthrough: Merupakan sebuah tinjauan di mana author memimpin tim melalui eksekusi manual atau simulasi produk menggunakan skenario yang telah ditetapkan. Tujuannya adalah untuk menilai kualitas dari software yang bersangkutan, bukan kualitas proses yang digunakan untuk mengembangkan produk 7

8 Steps in the code review process. 8

9 general guidelines for performing code review Readiness. Author unit memastikan bahwa unit yang sedang diuji siap untuk ditinjau : Completeness, Minimal Functionality, Readability, Complexity. Preparation. Sebelum pertemuan, secara hati-hati setiap reviewer meninjau work package. Diharapkan bahwa peninjau membaca kode dan memahami organisasi dan operasi sebelum pertemuan tinjauan. Examination Proses pemeriksaan terdiri dari kegiatan berikut: ◦ Author membuat presentasi dari logika prosedural yang digunakan dalam kode, lintasan yang menunjukkan komputasi utama, dan ketergantungan unit yang sedang diperiksa di unit lain. ◦ Presenter membaca kode baris per baris. Para peninjau dapat memunculkan pertanyaan jika kode ini terlihat memiliki cacat. ◦ Recordkeeper mendokumentasikan permintaan perubahan dan saran untuk memperbaiki masalah, jika ada. Rework Validation CR secara independen disahkan oleh moderator atau orang lain yang ditunjuk untuk tujuan ini. ◦ Proses validasi termasuk mengecek kode yang diubah seperti yang didokumentasikan di CR dan memastikan bahwa saran perbaikan telah dilaksanakan dengan benar. Exit Ringkasan proses review, dikatakan selesai jika semua tindakan berikut telah dilakukan : ◦ Setiap baris kode dalam unit telah diperiksa. Jika terlalu banyak cacat ditemukan dalam modul, modul sekali lagi ditinjau setelah koreksi yang diterapkan oleh author. 9

10 10

11 11

12 Code Review Metrics Number of lines of code (LOC) reviewed per hour Number of CRs generated per thousand lines of code (KLOC) Number of CRs generated per hour Total number of CRs generated per project Total number of hours spent on code review per project 12

13 Pencegahan Cacat Gunakan kontrol standar untuk mendeteksi kemungkinan kejadian kondisi kesalahan ◦ Contoh deteksi kesalahan dalam kode adalah pembagian dengan nol dan indeks array keluar batas. Pastikan semua kode tersebut ada nilai kembali, beberapa di antaranya mungkin tidak valid. ◦ Tindakan tindak lanjut yang tepat perlu diambil untuk menangani kembali nilai-nilai yang tidak valid. Pastikan bahwa penanganan field data dan buffer overflow dan underflow secara tepat ditangani. Memberikan pesan kesalahan dan teks bantuan dari sumber umum sehingga perubahan dalam teks tidak menyebabkan inkonsistensi. ◦ Pesan kesalahan yang baik mengidentifikasi akar penyebab masalah dan membantu pengguna dalam menyelesaikan masalah Validasi data masukan, seperti argumen yang dilewatkan ke fungsi. Gunakan penegasan (assertion) untuk mendeteksi kondisi yang tidak mungkin, penggunaan data yang tidak terdefinisi, dan perilaku program yang tidak dikehendaki. ◦ Assertion adalah pernyataan Boolean yang tidak boleh salah atau dapat salah hanya jika kesalahan telah terjadi. ◦ Dengan kata lain, assertion adalah sebuah pemeriksaan pada kondisi yang dianggap benar, tetapi dapat menyebabkan masalah jika tidak benar. Dokumentasikan assertions sepenuhnya yang muncul tidak jelas. Setelah setiap komputasi utama, hitung balik input (s) dari hasil dalam kode itu sendiri. Kemudian bandingkan hasilnya dengan masukan yang sebenarnya untuk pembenaran ◦ Contoh, anggaplah bahwa potongan kode yang menghitung akar kuadrat suatu bilangan positif. Kemudian kuadratkan nilai output dan bandingkan hasilnya dengan input. ◦ Ini mungkin diperlukan untuk mentolerir margin kesalahan dalam proses perbandingan. 13

14 Contoh mencari cyclomatic complexity Draw a control flow graph for the following sample code. Determine the cyclomatic complexity of the graph. n = 8, e = 10, v = e – n + 2 = = 4 14

15 15 b c d h a e f g

16 16 (a)x = [ ] (b)Jum = count(x) (c)For i = 1 to Jum-1 (d) pivot = x(i) (e) For j = i+1 to Jum (f) if x(j) < pivot then (g) pivot = x(j) end if end for (h) x(i) = pivot End for (j)Tampilkan x Latihan Buatlah diagram control flow ! Hitung Cyclomatic Complexity !

17 17 (a)D = [ ] (b)X = ‘bilangan yg dicari’ % misal 5 (c)Jum = count(D) (d)Idx = 1 (e)Ketemu = false (f)While Idx <= Jum and Ketemu == false (g) If D(Idx) == X (h) Ketemu = true else (i) Idx = Idx + 1 End if End for (j)Tampilkan Ketemu Latihan Buatlah diagram control flow ! Hitung Cyclomatic Complexity !


Download ppt "Unit Testing Software Quality Eko Prasetyo Teknik Informatika Univ. Pembangunan Nasional Veteran Jawa Timur 2011 1."

Presentasi serupa


Iklan oleh Google