Testing & Implementasi Sistem

Dasar-Dasar Testing (2) White Box Testing (1)

Testabilitas
Idealnya, perekayasa software mendisain program komputer, sistem ataupun produk dengan menempatkan testabilitas dalam benaknya. Hal ini akan memungkinkan untuk membantu testing dalam mendisain test case yang efektif dan lebih mudah. Secara sederhana, menurut James Bach, testabilitas software adalah seberapa mudah (suatu program komputer) dapat dites. Kadang-kadang programer mau membantu proses testing dan suatu daftar item disain yang mungkin, fitur, dan lain-lain, akan sangat membantu jika dapat bekerja sama dengan mereka.

Atribut-Atribut Testabilitas
Operability Observability Controllability Decomposability Simplicity Stability Understandability

Atribut-Atribut Testabilitas (Cont.)

Operability Semakin baik Software berkerja, akan membuat software dites dengan lebih efisien.
Sistem mempunyai bug baru (bug menambahkan biaya tak langsung pada proses testing, dengan adanya analisa dan pelaporan) Tidak ada bug yang menghentikan eksekusi tes Produk berubah dalam tahap fungsional (memungkinkan pengembangan dan testing yang simultan)

Atribut-Atribut Testabilitas (Cont.)

Observability Apa yang Anda lihat, adalah apa yang Anda tes.
Hasil dari setiap keluaran harus menunjukkan hasil dari masukan. Kondisi sistem dan variabel dapat dilihat atau diquery selama eksekusi berlangsung. Kondisi dan variabel sistem lama juga dapat dilihat atau diquery. Semua faktor yang mempengaruhi keluaran dapat dilihat. Keluaran yang salah dapat dengan mudah diidentifikasikan Kesalahan internal dapat secara otomatis dideteksi oleh mekanisme tes yang menyeluruh. Kesalahan internal secara otomatis dilaporkan. Source code dapat diakses.

Atribut-Atribut Testabilitas (Cont.)

Controllability
Dengan semakin baik kita dapat mengendalikan software,
semakin banyak dioptimalisasi. testing dapat diotomatisasi dan

Semua kemungkinan keluaran dihasilkan dari berbagai kombinasi masukan Semua kode dieksekusi dari beberapa kombinasi masukan Kondisi hardware dan software dan variabel dapat dikontrol secara langsung oleh test engineer. Format masukan dan keluaran harus konsisten dan terstruktur. Testing dapat dengan mudah dispesifikasikan, otomasi, dan dibuat ulang.

Atribut-Atribut Testabilitas (Cont.)

Decomposability Dengan pengendalian batasan testing, kita dapat lebih cepat dalam mengisolasi masalah dan melakukan testing ulang yang lebih baik.
Sistem software dibangun dari modulmodul yang independen. Modul software dapat di tes secara independen (sendiri-sendiri).

Atribut-Atribut Testabilitas (Cont.)

Simplicity Semakin sedikit yang dites, semakin cepat kita melakukannya.
Kesederhanaan fungsi (fitur yang ada di buat seminimal mungkin untuk memenuhi kebutuhan yang ada). Kesederhanaan struktur (arsitektur dibuat sesederhana mungkin untuk menghindari kesalahan). Kesederhanaan kode (standar dari kode dibuat agar dengan mudah diinspeksi dan dirawat).

Atribut-Atribut Testabilitas (Cont.)

Stability Semakin sedikit perubahan, semakin sedikit masalah / gangguan testing.
Perubahan dari software terjadi kadangkadang. Perubahan dari software tidak terkendali. Perubahan dari software tidak dapat divalidasi pada tes yang ada. Software dapat melakukan perbaikan untuk kembali berjalan dengan baik (recovery) dari kegagalan proses.

Atribut-Atribut Testabilitas (Cont.)

Understandability Semakin banyak informasi yang kita miliki, kita akan dapat melakukan tes lebih baik.
Disain mudah dimengerti dan dipahami dengan baik. Keterkaitan antara internal, eksternal dan share komponen dipahami dengan baik. Perubahan disain dikomunikasikan. Dokumentasi teknis dapat dengan mudah diakses. Dokumentasi teknis diorganisasi dengan baik . Dokumentasi teknis berisi spesifikasi dan detil. Dokumentasi teknis yang akurat.

Atribut-Atribut Testabilitas
Atribut-atribut di testabilitas yang disarankan oleh Bach dapat digunakan oleh perekayasa software untuk mengembangkan suatu konfigurasi software (seperti program, data dan dokumen) yang akan dapat membantu testing.

Atribut-Atribut Testing (Cont.)

Suatu testing yang baik mempunyai kemungkinan yang tinggi dalam menentukan error. Untuk mencapai tujuan ini, tester harus mengerti software dan berusaha untuk mengembangkan gambaran dalam benaknya tentang bagaimana kirakira software akan dapat gagal (fail). Idealnya, kelas-kelas dari failure dicari.

Atribut-Atribut Testing (Cont.)

Suatu tes yang baik tidak tumpang tindih (redundant). Waktu dan sumber daya testing terbatas. Tak ada satupun titik dalam pelaksanaan testing yang mempunyai tujuan yang sama dengan testing yang lain. Tiap testing harus mempunyai tujuan yang berbeda.

Atribut-Atribut Testing (Cont.)

Suatu tes yang baik harus memberikan hasil yang terbaik [KAN93]. Dalam suatu grup tes yang mempunyai batasan intensi, waktu, sumber daya yang sama, akan melakukan eksekusi hanya pada subset dari tes ini. Dalam kasus tertentu, tes yang mempunyai kemungkinan tertinggi dalam memperoleh kelas error seharusnya digunakan.

Atribut-Atribut Testing
Suatu tes yang baik harusnya tidak terlalu sederhana namun juga tidak terlalu komplek. Walau kadang kala memungkinkan untuk mengkombinasikan serangkaian tes ke dalam satu test case, efek samping yang mungkin diasosiasikan dengan pendekatan ini adalah adanya error yang tidak terdeteksi. Umumnya, tiap tes harus dieksekusi secara terpisah.

Pengertian Defect dari Software

Menurut Kaner, Falk, dan Nguyen [KAM93A], ada 13 kategori utama defect dari software, yaitu :
User interface errors - sistem memberikan suatu tampilan yang berbeda dari spesifikasi. Error handling pengenalan dan perlakuan terhadap error bila terjadi. Boundary related errors - perlakuan terhadap nilai batasan dari jangkauan mereka yang mungkin tidak benar. Calculation errors - perhitungan arimatika dan logika yang mungkin tidak benar. Initial and later states - fungsi gagal pada saat pertama digunakan atau sesudah itu.

Pengertian Defect dari Software

(Cont.)

Control flow errors - pilihan terhadap apa yang akan dilakukan berikutnya tidak sesuai untuk status saat ini. Errors in handling or interpreting data melewatkan dan mengkonversi data antar sistem (dan mungkin komponen yang terpisah dari sistem) dapat menimbulkan error. Race conditions - bila dua event diproses akan maka salah satu akan diterima berdasarkan prioritas sampai pekerjaan selesai dengan baik, baru pekerjaan berikutnya. Bagaimanapun juga kadang-kadang event lain akan diproses terlebih dahulu dan dapat menghasilkan sesuatu yang tidak diharapkan atau tidak benar.

Pengertian Defect dari Software

(Cont.)

Load conditions - saat sistem dipaksa pada batas maksimum, masalah akan mulai muncul, seperti arrays, overflow, diskfull. Hardware - antar muka dengan suatu device mungkin tidak dapat beroperasi dengan benar pada suatu kondisi tertentu seperti device unavailable. Source and Version Control - program yang telah kadaluwarsa mungkin akan dapat digunakan lagi bila ada revisi untuk memperbaikinya. Documentation - pengguna tak dapat melihat operasi yang telah dideskripsikan dalam dokumen panduan. Testing errors - tester membuat kesalahan selama testing dan berpikir bahwa sistem berkelakuan tak benar.

Biaya-biaya testing

Kebanyakan atribut biaya testing menghabiskan sekitar 25 % dari pengembangan. Beberapa proyek bahkan dapat mencapai sekitar 80% dari dana pengembangan.

Biaya-biaya defects (Cont.)

Kesiapan dukungan teknisi. Persiapan buku panduan FAQ. Investigasi komplain pelanggan. Ganti rugi dan mengambil kembali produk. Coding atau testing dari pembenahan bugs. Pengiriman dari produk yang telah diperbaiki. Penambahan biaya terhadap dukungan berbagai versi dari produk yang telah di release. Tugas Public Relation untuk menjelaskan review dari defects. Hilangnya pangsa jual. Hilangnya kepercayaan pelanggan. Pemberian potongan harga pada penjual agar mereka tetap menjual produk. Garansi. Kewajiban. Investigasi pemerintah. Pinalti. Dan biaya lain yang berkaitan dengan hukum.

Biaya-biaya defects (Cont.)

Biaya-biaya defects

Penyeimbangan Biaya (Cont.)

Feigenbaum (1991) mengestimasi biaya tiap kualitas untuk pencegahan (prevention) pada perusahaan umumnya menghabiskan biaya $0.05 sampai $0.1, sedangkan untuk evaluasi penilaian (appraisal) sebesar $0.2 samapa $0.25 dan sisanya $0.65 sampai $0.75 untuk biaya dari failure internal dan eksternal. Kebutuhan untuk menyeimbangkan biaya, sehingga besar pengeluaran tidak berada pada failure internal atau eksternal sangat dibutuhkan. Caranya dengan membandingkan biaya menghilangkan dalam kaitannya dengan perbaikan defect pada sistem secara keseluruhan.

Penyeimbangan Biaya
Akan sangat mahal untuk melakukan tes defect daripada mengkoreksinya, karenanya testing perlu di sederhanakan. Defect diasumsikan selalu berkaitan dengan adanya biaya perbaikan, karenanya total biaya perbaikan defect meningkat secara linier terhadap jumlah defect yang ada pada sistem. Sedangkan usaha testing akan meningkat secara eksponensial sesuai dengan meningkatnya proporsi defect yang diperbaiki. Hal ini menguatkan pandangan bahwa menghilangkan defect secara seratus persen adalah tidak mungkin, sehingga testing komplit juga tidak bisa dilakukan.

Siklus Hidup Software secara Umum

Metodologi merupakan sekumpulan tahap atau tugas. Kebanyakan organisasi menggunakan suatu standar untuk pengembangan software yang mendefinisikan suatu model siklus hidup (life cycle model), dan dibutuhkan tahap-tahap atau metodologi dalam pelaksanaannya. Ide pembagian dalam bentuk fase / tahapan digunakan pada semua metodologi software, dimana tiap fase mempunyai produk akhir yang merupakan serahan dan menjadi pertanda penyelesaian proses di tiap fase tersebut.

Siklus Hidup Testing secara Umum

Aktifitas Testing secara Umum

Perencanaan (Planning)
Rencana pendekatan umum Menentukan obyektivitas testing Memperjelas rencana umum

Akusisi
Disain tes Menerapkan tes Pengukuran

Eksekusi tes (Execution Test)

Cek terminasi Evaluasi hasil

Tiga Tingkatan Testing secara Umum

Unit testing Testing penulisan kode-kode program dalam satuan unit terkecil secara individual. System Testing Proses testing pada sistem terintegrasi untuk melakukan verifikasi bahwa sistem telah sesuai spesifikasi. Acceptance Testing Testing formal yang dilakukan untuk menentukan apakah sistem telah memenuhi kriteria penerimaan dan memberdayakan pelanggan untuk menentukan apakah sistem dapat diterima atau tidak.

Praktik unit testing secara umum

Tujuan Konfirmasi bahwa modul telah dikode dengan benar. Pelaku Biasanya programer. Apa yang dites Fungsi (Black Box). Kode (White Box). Kondisi ekstrim dan batasan-batasan. Kapan selesai Biasanya saat programer telah merasa puas dan tidak diketahui lagi kesalahan. Alat bantu Tidak biasa digunakan. Data Biasanya tidak didata.

Praktik system testing secara umum

Tujuan Merakit modul menjadi suatu sistem yang bekerja. Dan menentukan kesiapan untuk melakukan Acceptance Test. Pelaku Pemimpin tim atau grup tes. Apa yang dites Kebutuhan dan fungsi sistem. Antarmuka sistem. Kapan selesai Biasanya bila mayoritas kebutuhan telah sesuai dan tidak ada kesalahan mayor yang ditemukan. Alat bantu Sistem pustaka dan pustaka test case. Generator, komparator dan simulator data testing. Data Data kesalahan yang ditemukan. Test case.

Praktik acceptance testing secara umum

Tujuan Mengevaluasi kesiapan untuk digunakan. Pelaku Pengguna akhir atau agen. Apa yang dites Fungsi mayor. Dokumentasi. Prosedur. Kapan selesai Biasanya bila pengguna telah merasa puas atau tes berjalan dengan lancar / sukses. Alat bantu Komparator (pembanding). Data Formalitas dokumen.

Disain Test Case

Pendahuluan
Tiap produk hasil rekayasa dapat di tes dalam dua cara:
Dengan berdasarkan pada fungsi yang dispesifikasikan dari produk, tes dapat dilakukan dengan mendemonstrasikan tiap fungsi telah beroperasi secara penuh sesuai dengan yang diharapkan, dan sementara itu, pada saat yang bersamaan, dilakukan pencarian error pada tiap fungsi. Dengan mengetahui operasi internal dari produk, tes dapat dilakukan untuk memastikan semua komponen berjalan sebagaimana mestinya, operasi internal berlaku berdasarkan pada spesifikasi dan semua komponen internal telah cukup diperiksa.

Pendekatan cara pertama biasa disebut dengan black box testing, dan pendekatan cara kedua disebut white box testing.

Definisi Test Case (Cont.)

Test case merupakan suatu tes yang dilakukan berdasarkan pada suatu inisialisasi, masukan, kondisi ataupun hasil yang telah ditentukan sebelumnya. Adapun kegunaan dari test case ini, adalah sebagai berikut:
Untuk melakukan testing kesesuaian suatu komponen terhadap spesifikasi Black Box Testing. Untuk melakukan testing kesesuaian suatu komponen terhadap disain White Box Testing.

Definisi Test Case

Hal yang perlu diingat bahwa testing tidak dapat membuktikan kebenaran semua kemungkinan eksekusi dari suatu program. Namun dapat didekati dengan melakukan perencanaan dan disain tes case yang baik sehingga dapat memberikan jaminan efektifitas dari software sampai pada tingkat tertentu sesuai dengan yang diharapkan.

White Box Testing

Kadang disebut juga glass box testing atau clear box testing, adalah suatu metode disain test case yang menggunakan struktur kendali dari disain prosedural. Metode disain test case ini dapat menjamin:
Semua jalur (path) yang independen / terpisah dapat dites setidaknya sekali tes. Semua logika keputusan dapat dites dengan jalur yang salah dan atau jalur yang benar. Semua loop dapat dites terhadap batasannya dan ikatan operasionalnya. Semua struktur internal data dapat dites untuk memastikan validitasnya.

White Box Testing

Seringkali white box testing diasosiasikan dengan pengukuran cakupan tes (test coverage metrics), yang mengukur persentase jalur-jalur dari tipe yang diplih untuk dieksekusi oleh test cases. Mengapa melakukan white box testing bilamana black box testing berfungsi untuk testing pemenuhan terhadap kebutuhan / spesifikasi?
Kesalahan logika dan asumsi yang tidak benar kebanyakan dilakukan ketika coding untuk kasus tertentu. Dibutuhkan kepastian bahwa eksekusi jalur ini telah dites. Asumsi bahwa adanya kemungkinan terhadap eksekusi jalur yang tidak benar. Dengan white box testing dapat ditemukan kesalahan ini Kesalahan penulisan yang acak. Seperti berada pada jalur logika yang membingungkan pada jalur normal.

White Box Testing

Cakupan pernyataan, cabang & jalur Cakupan pernyataan, cabang dan jalur adalah suatu teknik white box testing yang menggunakan alur logika dari program untuk membuat test cases. Yang dimaksud dengan alur logika adalah cara dimana suatu bagian dari program tertentu dieksekusi saat menjalankan program.

White Box Testing Cakupan pernyataan, cabang dan jalur (Cont.)

Alur logika suatu program dapat direpresentasikan dengan flow graph, yang akan dibahas lebih lanjut pada sub bab berikutnya (basis path testing). Sebagai contoh dapat dilihat pada gambar di bawah ini.
A B D H K E F I C G

If A Then If B Then D else E End if; H Else if C Then F else G End if; I End If B D H E

C
F G

Cakupan pernyataan, cabang dan jalur

(Cont.)
Suatu flow graph terbentuk dari:
Nodes (titik), mewakili pernyataan (atau sub program) yang akan ditinjau saat eksekusi program. Edges (anak panah), mewakili jalur alur logika program untuk menghubungkan satu pernyataan (atau sub program) dengan yang lainnya. Branch nodes (titik cabang), titik-titik yang mempunyai lebih dari satu anak panah keluaran. Branch edges (anak panah cabang), anak panah yang keluar dari suatu cabang Paths (jalur), jalur yang mungkin untuk bergerak dari satu titik ke lainnya sejalan dengan keberadaan arah anak panah.

Cakupan pernyataan, cabang dan jalur

Eksekusi suatu test case menyebabkan program untuk mengeksekusi pernyataan-pernyaan tertentu, yang berkaitan dengan jalur tertentu, sebagaimana tergambar pada flow graph. Cakupan cabang, pernyataan dan jalur dibentuk dari eksekusi jalur program yang berkaitan dengan peninjauan titik, anak panah, dan jalur dalam flow graph.

Cakupan pernyataan (Cont.)

Cakupan pernyataan ditentukan dengan menilai proporsi dari pernyataanpernyataan yang ditinjau oleh sekumpulan test cases yang ditentukan. Cakupan pernyataan 100 % adalah bila tiap pernyataan pada program ditinjau setidaknya minimal sekali tes. Cakupan pernyataan berkaitan dengan tinjauan terhadap titik (node) pada flow graph. Cakupan 100 % terjadi bilamana semua titik dikunjungi oleh jalur-jalur yang dilalui oleh test cases.

Cakupan pernyataan

Pada contoh gambar flow graph di atas terdapat 10 titik. Misal suatu jalur eksekusi program melewati titik-titik A, B, D, H, K. Berarti ada 5 titik dari 10 titik yang dikunjungi, maka cakupan pernyataan sebesar 50 %. Karena satu titik pada flow graph dapat merupakan kelompok dari beberapa pernyataan, oleh karena itu tingkat cakupan pernyataan yang sebenarnya berbeda dengan tingkat cakupan titik (nodes), tergantung dari cara pendefinisian flow graph.

Cakupan cabang (Cont.)

Cakupan cabang ditentukan dengan menilai proporsi dari cabang keputusan yang diuji oleh sekumpulan test cases yang telah ditentukan. Cakupan cabang 100 % adalah bilamana tiap cabang keputusan pada program ditinjau setidaknya minimal sekali tes. Cakupan cabang berkaitan dengan peninjauan anak panah cabang (branch edges) dari flow graph. Cakupan 100 % adalah bilamana semua anak panah cabang ditinjau oleh jalur-jalur yang dilalui oleh test cases.

Cakupan cabang

Berdasarkan pada contoh gambar flow graph di atas, terdapat 6 anak panah cabang. Misal suatu jalur eksekusi program melawati titik-titik A, B, D, H, K, maka jalur tersebut meninjau 2 dari 6 anak panah cabang yang ada, jadi cakupannya sebesar 33 %.

Cakupan jalur (Cont.)

Cakupan jalur ditentukan dengan menilai proporsi eksekusi jalur program yang diuji oleh sekumpulan test cases yang telah ditentukan. Cakupan jalur 100 % adalah bilamana tiap jalur pada program dikunjungi setidaknya minimal sekali tes. Cakupan jalur berkaitan dengan peninjauan jalur sepanjang flow graph. Cakupan 100 % adalah bilamana semua jalur dilalui oleh test cases.

Cakupan jalur

Berdasarkan contoh flow graph di atas, terdapat 4 jalur. Bila suatu eksekusi jalur pada program melalui titik-titik A, B, D, H, K, maka eksekusi tersebut meninjau 1 dari 4 jalur yang ada, jadi cakupannya sebesar 25 %.

Perbedaan antara cakupan pernyataan, cabang dan jalur (Cont.)

Perbedaan antara cakupan pernyataan, cabang dan jalur (Cont.)

Perbedaan antara cakupan pernyataan, cabang dan jalur

Dari contoh, dapat dilihat bahwa hanya dibutuhkan 2 jalur untuk mengunjungi semua anak panah cabang, dari 4 jalur yang ada pada flow graph. Jadi bila cakupan jalur sebesar 100 %, maka secara otomatis cakupan cabang sebesar 100 % pula. Demikian pula bila cakupan cabang sebesar 100 %, maka secara otomatis cakupan pernyataan sebesar 100 %.

Disain cakupan tes

Untuk mendisain cakupan dari tes, perlu diketahui tahap-tahap sebagai berikut:
1. Menganalisa source code untuk membuat flow graph. 2. Mengidentifikasi jalur tes untuk mencapai pemenuhan tes berdasarkan pada flow graph. 3. Mengevaluasi kondisi tes yang akan dicapai dalam tiap tes. 4. Memberikan nilai masukan dan keluaran berdasarkan pada kondisi.

Terimakasih