Perguruan Tinggi ASIA

Chapter 11

Software Testing Strategy

Overview Mengintegrasikan metode desain test case Software ke dalam sederetan langkah yang direncanakan dengan baik Salah satu cara untuk menghindari kesalahan program adalah dengan desain yang hati-hati dan keahlian memprogram Teknik desain modern [kajian teknis formal] sangat membantu untuk mengurangi jumlah kesalahan pada kode Strategi Software metode pengujian yang berbeda dalam beberapa pendekatan dan filosofi yang berbeda

Ruang lingkup Pendekatan strategis ke pengujian Software Masalah-masalah strategis Pengujian unit Pengujian integrasi Pengujian validasi Pengujian sistem Debugging

Pendekatan strategis ke pengujian Software 1. 2. 3. 4. Pengujian serangkaian aktivitas yang dapat direncanakan sebelumnya dan dilakukan secara sistematis Suatu template untuk desain Software yang semua memiliki karakteristik generik seperti: Pengujian mulai pada tingkat modul-modul dan kerja keluar ke arah integrasi dari sistem yang berbasis komputer Teknik pengujian yang berbeda sesuai pada titik waktu yang berbeda Pengujian dilakukan oleh pengembang Software dan [untuk proyek yang besar] suatu kelompok pengujian yang independen Pengujian dan debugging merupakan aktifitas yang berbeda, tapi debugging harus diakomodasi pada banyak strategi pengujian

Verifikasi dan validasi - Pengujian Software adalah salah satu elemen topik yang lebih luas yang sering diacu sebagai verifikasi dan validasi (V&V) - Verifikasi mengacu pada rangkaian aktifitas yang memastikan bahwa Software secara tepat mengimplemetasikan suatu fungsi tertentu - Validasi mengacu pada serangkaian aktifitas yang berbeda yang memastikan bahwa Software yang dibangun dapat ditelusuri ke persyaratan pelanggan Verifikasi apakah kita membangun hak produk Validasi apakah kita membangun produk yang benar

Pengorganisasian pengujian Software - Peran kelompok pengujian independen (ITG) untuk menghilangkan masalah yang melekat sehubungan dengan diperbolehkannya pengembang untuk menguji semua yang telah dibangun - Pengembang dan ITG bekerja erat pada keseluruhan proyek Software untuk memastikan bahwa pengujian akan dilakukan - ITG bagian dari tim proyek pengembang Software yang terlibat selama PSPEC [merencanakan dan menentukan prosedur pengujian] pada keseluruhan proyek - ITG melapor kepada organisasi jaminan kualitas, sehingga tercapai tingkat independensi

Strategi pengujian Software - Tes unit [modul berfungsi secara tepat sebagai suatu unit] - Kode - Desain - Tes integrasi [perakitan untuk membentuk paket Software yang lengkap] - Persyaratan - Tes validasi [jaminan akhir dimana Software harus memenuhi semua persyaratan fungsional, tingkah laku dan kinerja] - Rekayasa sistem - Tes sistem [semua elemen saling bertautan dengan tepat dan keseluruhan fungsi sistem dapat tercapai]

-

Kriteria kelengkapan pengujian Kapan kita akan menyelesaikan pengujian/ bagaimana kita tahu bahwa kita telah cukup melakukannya? Kita tidak boleh terlalu yakin kalau Software tidak akan pernah gagal Dengan menggunakan pemodelan statistik dan teori reabilitas Software, model kegagalan Software [selama pengujian] fungsi dari waktu eksekusi yang dapat dikembangkan Versi dari model kegagalan [logarithmic Poisson execution-time model]

f(t)=(1/p)ln(lopt-1)f(t)jumlah komulatif kegagalan yang diharapkan terjadi sekali Software diuji pada suatu jumlah waktu eksekusi t lo intensitas kegagalan Software awal (kegagalan per unit waktu) pada awal pengujian p reduksi eksponensial di dalam intensitas kegagalan karena kesalahan ditemukan dan perbaikan dilakukan Intensitas kegagalan sesaat l(t) mengambil dari derivatif f(t): l(t)=lo (lopt-1)

Masalah-masalah strategis Tentukan persyaratan produk dalam suatu cara yang dapat dikuantifikasi jauh sebelum pengujian dimulai [selain menemukan kesalahan juga kualitas lain seperti probabilitas, maintabilitas dll] Nyatakan sasaran pengujian secara eksplisit [keefektifan pengujian, biaya untuk menemukan dan perbaikan kesalahan dll] Pahami para pemakai Software dan kembangkan profil bagi masing-masing kategori pemakai [mengurangi kerja pengujian dengan berfokus pada penggunaan aktual produk] Kembangkan rencana pengujian yang menekankan pengujian siklus cepat [costumer useful untuk umpan balik] Bangun Software robust yang didesain untuk menguji dirinya sendiri [antibugging Software dapat mendiagnosis kelas-kelas kesalahan tertentu] Gunakan kajian teknis formal sebagai sebuah filter sebelum pengujian [SQA dll] Lakukan kajian teknis formal untuk memperkirakan strategi pengujian dan melakukan test case terhadap dirinya sendiri [mengungkap ketidakkonsistenan, penghapusan dan kesalahan seketika di dalam pendekatan pengujian] Kembangkan pendekatan pengembangan yang kontinu untuk proses pengujian [metrik pengujian]

Pengujian unit Berfokus pada usaha verifikasi pada inti terkecil dari desain Software modul Pengujian ini berorientasi pada white box, dan langkahnya dapat dilakukan secara pararel untuk modul bertingkat - Pertimbangan pengujian unit - Prosedur pengujian satuan

-

Pertimbangan pengujian unit Pengujian unit terjadi sebagai bagian dari unit: A. interface modul untuk memastikan bahwa informasi secara tepat mengalir masuk dan keluar dari inti program yang diuji B. struktur data lokal untuk memastikan bahwa data yang tersimpan secara temporal tetap terjaga integritasnya C. kondisi batas untuk memastikan bahwa modul beroperasi dengan tepat pada batas yang ditentukan untuk membatasi pemrosesan D. jalur independen jalur dasar yang melalui struktur kontrol E. pengujian penanganan kesalahan

Prosedur pengujian satuan Seperti pada pengujian unit, pada hasil test case modul bukanlah program yang berdiri sendiri, software driver dan stub dikembangkan bagi masing-masing pengujian unit. Driver program utama yang menerima data test case, melewatkan data tersebut ke modul Stub/subprogram subordinat dari modul yang diuji [menggunakan interface modul subordinat untuk manipulasi data minimal, verifikasi entri dll]

Pengujian integrasi Teknis sistematis untuk mengkonstruksi struktur program sambil melakukan pengujian untuk mengungkap kesalahan sehubungan dengan interfacing Sasaran untuk mengambil modul yang dikenai pengujian unit dan membangun struktur program yang telah ditentukan oleh desain

1. 2. 3. 4. 5.

Integrasi Top-Down Pendekatan inkremental terhadap struktur program Proses integrasi dilakukan dalam 5 langkah: Modul utama sebagai test driver, dan stub ditambahkan pada semua modul yang secara langsung subordinat terhadap modul kontrol utama Tergantung pada pendekatan integrasi yang dipilih (depth first/ breadth first), stub subordinat terhadap modul kontrol utama Pengujian dilakukan pada saat masing-masing modul diintegrasi Pada pelengkapan masing-masing rangkaian pengujian, stub yang lain diganti dengan modul real Pengujian regresi dapat dilakukan untuk memastikan bahwa error baru belum dimunculkan

1. 2. 3. 4.

Integrasi Bottom up Memulai konstruksi dan pengujian dengan modul atomik [modul pada tingkat paling rendah pada struktur program] Diimplementasikan dengan langkah-langkah: Modul tingkat rendah digabungkan ke dalam cluster (build) yang melakukan subfungsi software spesifik Driver (program kontrol untuk pengujian) ditulis untuk mengkoordinasi input dan output test case Cluster diuji Driver diganti dan cluster digabungkan dengan menggerakkan ke atas di dalam struktur program

-

Pengujian regresi Aktifitas yang membantu memastikan bahwa perubahan [sehubungan dengan pengujian/ alasan lain] tidak menimbulkan kesalahan tambahan - Merupakan eksekusi ulang dari beberapa subset yang telah dilakukan untuk memastikan bahwa perubahan tidak menimbulkan efek samping yang tidak diharapkan - Sederetan pengujian regresi berisi tiga kelas test case yang berbeda: 1. Sampel representatif dari pengujian yang akan menggunakan semua fungsi software 2. Pengujian tambahan yang berfokus pada fungsi-fungsi software yang mungkin dipengaruhi oleh perubahan tersebut 3. Pengujian yang berfokus pada komponen software yang telah diubah

Tanggapan mengenai pengujian integrasi (-) pendekatan top down kebutuhan akan stub dan sulitnya pengujian yang dapat berkaitan dengan stub (-) pendekatan bottom up program sebagai sebuah entitas tidak ada sampai modul terakhir ditambahkan Pemilihan strategi integrasi tergantung pada karakteristik software dan pada jadwal proyek. Metode gabungan (sandwitch testing) menggunakan strategi top down untuk tingkat yang lebih tinggi dari struktur program, dipasangkan dengan strategi bottom up untuk tingkat subordinat, dapat menjadi gabungan yang terbaik

Dokumentasi pengujian integrasi - Rencana keseluruhan software dan deskripsi pengujian spesifik didokumentasikan di dalam spesifikasi pengujian - Spesifikasi ini digunakan pada proses software engineering dan menjadi bagian dari konfigurasi software

Pengujian validasi Kriteria pengujian validasi; validasi software dicapai melalui sederetan pengujian black box yang memperlihatkan konfirmitas dengan persyaratan Kajian konfigurasi; merupakan elemen penting dari validasi, dengan tujuan untuk memastikan apakah semua elemen konfigurasi software telah dikembangkan secara tepat, dikatalog dan memiliki detail yang perlu untuk mendukung fase pemeliharaan dari siklus hidup software Pengujian alpha dan beta; untuk mengungkap kesalahan yang hanya dapat ditemukan oleh end user Pengujian alpha dilakukan pada sisi pengembang oleh seorang pelanggan Pengujian beta dilakukan pada satu / lebih pelanggan oleh end user software

Pengujian sistem 1. 2. 3. 4. Yang biasa terjadi dalam pengujian sistem finger pointing terjadi pada saat kesalahan terungkap Hal-hal yang perlu dilakukan agar tidak terjadi hal tersebut bisa melalui: Mendesain jalur penanganan kesalahan yang menguji semua informasi yang datang dari elemen lain Melakukan serangkaian yang mensimulasi data yang buruk atau kesalahan potensial pada interface software Merekam hasil pengujian untuk digunakan sebagai bukti Berpartisipasi dalam perencanaan dan perancangan pengujian sistem untuk memastikan bahwa perangkat lunak diuji dengan akurat

Pengujian perbaikan - Pengujian sistem yang memaksa software untuk gagal di dalam berbagai cara dan memeriksa apakah perbaikan dilakukan dengan tepat - Sistem harus toleran terhadap kesalahan; yaitu bahwa kesalahan pemrosesan tidak boleh menyebabkan keseluruhan fungsi sistem berhenti - Bila perbaikan otomatis (dilakukan oleh sistem itu sendiri) perbaikan data, restart - Bila perbaikan membutuhkan intervensi manusia, waktu rata-rata perbaikan dievaluasi untuk menentukan apakah berada pada batas waktu yang diterima

Pengujian keamanan - Untuk membuktikan apakah mekanisme perlindungan yang dibangun pada sebuah sistem benar-benar dapat terlindungi - Keamanan sistem harus diuji baik dari segi serangan frontal maupun yang terjadi sesekali - Selama pengujian keamanan, penguji memainkan peran individu yang ingin menembus sistem - Pengujian dapat dilakukan melalui: usaha untuk mendapatkan password melalui alat kasir eksternal sistem pertahanan hancur sistem tidak bisa melayani operasi terjadi error pada sistem key untuk entri ke sistem dst

Pengujian stress didesain untuk melawan program dalam keadaan abnormal [kecepatan input data untuk mengetahui respon fungsi input] Pengujian kinerja didesain untuk menguji kinerja runtime dari software di dalam konteks sistem yang terintegrasi - Pengujian kinerja sering dipasangkan dengan pengujian stress dan sering membutuhkan instrumentasi hardware dan software - Hal itu sering diperlukan untuk mengukur penggunaan sumber daya [siklus prosesor] dalam suatu cara yang tepat - Instrumen eksternal dapat memonitor interval eksekusi, event-event log (mis. iterupsi) pada saat event itu terjadi

Debugging Pengujian software adalah proses yang dapat direncanakan dan ditentukan secara sistematis Debugging terjadi sebagai akibat dari pengujian yang berhasil Jika test case untuk mencari kesalahan, maka debugging adalah proses yang menghasilkan penghilangan kesalahan

-

Proses debugging Debugging bukan merupakan pengujian, tetapi selalu terjadi sebagai bagian akibat dari pengujian - Proses debugging dimulai dengan eksekusi terhadap suatu test case - Hasilnya dinilai, dan ditemukan kurangnya hubungan antara harapan dan implementasi - Pada proses debugging bisa jadi: a. Penyebab akan ditemukan, dikoreksi dan dihilangkan b. Penyebab tidak akan ditemukan Hal inilah yang menyebabkan kenapa debugging sangat sulit dilakukan - Selama debugging, kita menemukan kesalahan-kesalahan mulai dari gangguan yang halus (mis.format output yang tidak betul) hingga katrostopis (mis. Kegagalan sistem yang menyebabkan kerusakan fisik/ekonomis)

Pendekatan-pendekatan debugging Kategori pendekatan yang bisa dipakai antara lain: Brute force paling umum dan metode yang paling efisien untuk mengisolasi penyebab error. dengan menggunakan filosofi biarkan komputer menemukan error, penelusuran runtime dan program dibebani dengan statemen WRITE Backtracking sangat umum dan dapat digunakan secara sukses di dalam program yang kecil start dimana suatu gejala diungkap, kode sumber ditelusuri balik sampai sisi penyebab ditemukan Cause elimination data yang berhubungan dengan kejadian error dikumpulkan untuk mengisolasi penyebab potensial

1. 2.

3.

Sekali bug ditemukan, bug harus ditemukan Koreksi terhadap suatu bug dapat memunculkan kesalahan lain sehingga lebih banyak merugikan daripada menguntungkan Pertanyaan yang diajukan kepada engineer sebelum melakukan koreksi yang menghilangkan penyebab suatu bug: Apakah penyebab bug direproduksi di dalam bagian lain program tersebut?, error program yang keliru biasanya disebabkan oleh logika yang keliru yang dapat dibuat ulang di tempat lain Apa bug selanjutnya yang akan dimunculkan oleh perbaikan yang akan dibuat?, sebelum koreksi dibuat kode sumber harus di evaluasi untuk memperkirakan pemasangan logika dan struktur data Apa yang dapat kita lakukan untuk menghindari bug ini di dalam tempat pertama?, bila kita mengkoreksi proses dan produk, bug akan dihilangkan dari program yang ada dan dapat dieliminasi dari semua program selanjutnya

Required Reading Roger S. Pressman, Ph.D, Software Engineering On web Software Testing Strategy