Unit Testing

1. Unit Testing Software Quality Eko Prasetyo TeknikInformatika Univ. Pembangunan Nasional Veteran JawaTimur 2011

2. Hirarki Testing

3. Unit Testing • Level pertamadalam testing • Merupakanpengujian unit program secaraterpisah • Kadangdisebutfungsi, prosedur, method • Kelasdalam OOP, jugadianggap unit • Secarasintaksis, unit program adalahpotongankode, sepertifungsiatau method darikelas, yang dihubungkandariluar unit dandapatjugaberkaitandengan unit program yang lain. • Unit program diasumsikanmengimplementasikanfungsidenganbaik, memberikan level abstaksi yang pastidari level fungsi yang lebihtinggi. Sebuah unit program diujisecaraterisolasi (stand alone). • Alasanpengujian unit dalamkondisiterisolasi (stand-alone manner): • Pertama, error yang ditemukanselamapengujiandapatdikaitkanpada unit khusus yang dapatdenganmudahdiperbaiki. Selainitu, unit testing menghilangkanketergantunganpada unit program yang lain. • Kedua, selama unit testing, perlumenverifikasibahwasetiapeksekusi yang berbedadari program, memberikanhasilseperti yang diharapkan. • Programmer mempunyaiakseslangsungpadavektormasukandari unit denganmengeksekusi unit program terpisah.

4. Programmer perlumenguji unit sebagaiberikut: • Mengeksekusisetiapbariskode • Hal inidibutuhkan, karena programmer perlumengetahuiapa yang terjadiketikabariskodedieksekusi. • Tidakadanyapengamatanmendasar, akanmengejutkandibelakangbahwabiayaperbaikansangatmahal. • Mengeksekusisetiappredikatdalam unit untukmengevaluasi unit tersebutbenaratausalahsecaraterpisah. • Mengamatibahwa unit melakukan fungsi yang dimaksudkan dan memastikan bahwa tidak mengandung kesalahan diketahui

5. Programmer perlumenguji unit • Tidak ada jaminan bahwa unit yang teruji denganmemuaskan 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 dalamfase integration testingdan testing system • Meskipun tidak mungkin untuk menemukan semua kesalahan dalam unit program yang terpisah, • tetapmasih perlu untuk memastikan bahwa unit bekerja secara memuaskan sebelum digunakan oleh unit-unit program lain.

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

7. Static unit testing • Dalam static unit testing, kode ditinjau dengan menerapkan teknik umum • Disebutjugainspection 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. • Tujuannyaadalah untuk menilai kualitas dari software yang bersangkutan, bukan kualitas proses yang digunakan untuk mengembangkan produk

8. Steps in the code review process.

9. general guidelines forperforming 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, lintasanyang 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.

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

13. PencegahanCacat • Gunakan kontrol standar untuk mendeteksi kemungkinan kejadian kondisi kesalahan • Contoh deteksi kesalahan dalam kode adalah pembagiandengan 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 bahwapenanganan 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 kuadratkannilai output dan bandingkan hasilnya dengan input. • Ini mungkin diperlukan untuk mentolerir margin kesalahan dalam proses perbandingan.

14. Contohmencaricyclomatic complexity • Draw a control flow graph for the following sample code. Determine the cyclomaticcomplexity of the graph. • n = 8, e = 10, • v = e – n + 2 = 10-8+2 = 4

15. a b c d e f g h

16. Latihan x = [2 4 5 6] Jum = count(x) For i = 1 to Jum-1 pivot = x(i) For j = i+1 to Jum if x(j) < pivot then pivot = x(j) end if end for x(i) = pivot End for (j)Tampilkan x Buatlah diagram control flow ! HitungCyclomatic Complexity !

17. Latihan D = [2 4 5 6] X = ‘bilanganygdicari’ % misal 5 Jum = count(D) Idx = 1 Ketemu = false While Idx <= Jum and Ketemu == false (g) If D(Idx) == X (h) Ketemu = true else (i) Idx = Idx + 1 End if End for (j)TampilkanKetemu Buatlah diagram control flow ! HitungCyclomatic Complexity !