strategi pengujian perangkat lunak
STRATEGI PENGUJIAN PERANGKAT LUNAK
Dalam strategi pengujian perangkat lunak dapat digambarkan dengan ilustrasi berikut: Sebuah perangkat lunak dimulai dari penentuan kebutuhan perangkat lunak, kemudian proses dilanjutkan ke dalam bentuk rancangan, dan akhirnya ke pengkodean.
Strategi pengujian serupa dengan hal tersebut, dimulai dengan unit testing di pusat spiral di mana masing-masing modul/unit dari perangkat lunak yang diimplementasikan dalam source code menjadi sasaran pengujian. Kemudian dilakukan integration testing dengan focus pengujian adalah desain dan kontruksi arsitektur perangkat lunak. Selanjutnya dilakukan validation testing dengan sasaran pengujian adalah kesesuaian dengan kebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir pada lingkaran terluar spiral sampai pada system testing, di mana perangkat lunak dan keseluruhan sistem diuji.
Strategi pengujian serupa dengan hal tersebut, dimulai dengan unit testing di pusat spiral di mana masing-masing modul/unit dari perangkat lunak yang diimplementasikan dalam source code menjadi sasaran pengujian. Kemudian dilakukan integration testing dengan focus pengujian adalah desain dan kontruksi arsitektur perangkat lunak. Selanjutnya dilakukan validation testing dengan sasaran pengujian adalah kesesuaian dengan kebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir pada lingkaran terluar spiral sampai pada system testing, di mana perangkat lunak dan keseluruhan sistem diuji.
A. Pendekatan Strategis ke Pengujian Perangkat lunak
Pengujian merupakan rangkaian aktivitas yang dapat direncanakan sebelumnya dan dilakukan secara sistematis. Strategi uji coba perangkat lunak memudahkan para perancang untuk menentukan keberhasilan system yg telah dikerjakan. Hal yg harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yg diperlukan Strategi uji coba mempunyai karakteristik sbb :
a. Pengujian mulai pada tingkat modul yg paling bawah,dilanjutkan dengan modul di atasnya kemudian hasilnya dipadukan
b. Teknik pengujian yang berbeda mungkin menghasilakan sedikit perbedaan (dalam hal waktu)
c. Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatu kelompok pengujian yang independen.
d. Pengujian dan debugging merupakan aktivitas yang berbeda, tetapi debugging termasuk dalam strategi pengujian.
Validasi dan validasi
Verifikasi dan validasi merupakan dua istilah yang sering dikaitkan dengan tahapan pengujian perangkat lunak.Verifikasi mengacu pada serangkaian aktivitas untuk memastikan bahwa perangkat lunak mengimplementasikan fungsi tertentu secara benar, sedangkan validasi mengacu pada serangkaian aktivitas untuk memastikan bahwa perangkat lunak yang telah dibuat sesuai dengan kebutuhan konsumen.
Definisi V&V mencakup serangkaian aktivitas dari penjaminan kualitas perangkat lunak (SQA) yang meliputi kajian teknis formal, audit kualitas dan control, monitoring kinerja,simulasi, studi feasibilitas, kajian dokumentasi, kajian basis data, analisis algoritma, pengujian pengembangan, pengujian kualifikasi, dan pengujian instalasi.
Pengorganisasian Pengujian Perangkat Lunak
Proses pengujian sebuah perangkat lunak sebaiknya melibatkan pihak yang memang secara khusus bertanggung jawab untuk melakukan proses pengujian secara independen. Untuk itulah diperlukan Independent Test Group (ITG).
Peran dari ITG adalah untuk menghilangkan“conflict of interest” yang terjadi ketika pengembang perangkat lunak berusaha untuk menguji produknya sendiri.
Walaupun seperti itu, sering terjadi beberapa kesalahan pemahaman berkaitan dengan peran ITG, antara lain:
a. Pengembang tidak boleh melakukan pengujian sama sekali. Pendapat ini tidak 100% benar,Karena dalam banyak kasus, pengembang juga melakukan proses unit testing dan integration test.
b. Perangkat lunak dilempar begitu saja untuk diuji secara sporadic. Hal tersebut adalah salah karena pengemmbang dan ITG bekerja sama pada kesalahan proyek untuk memastikan pengujian akan dilakukan. Sementara pengujian dilakukan, pengembang harus memperbaiki kesalahan yang ditemukan.
c. Penguji tidak terlibat pada proyek sampai tahap pengujian dimulai. Hal tersebut salah karena ITG merupakan bagian dari tim proyek pengembangan perangkat lunak dimana ia terlihat selama spesifikasi proses dan tetap terlihat pada keseluruhan proyek besar.
B. Masalah-Masalah Strategis
Masalah-masalah berikut harus diselesaikan bila pengujian ingin berlangsung sukses:
1. Menspesifikasikan kebutuhan produk pada kelakuan yang terukur sebelum pengujian dimulai. Strategi pengujian yangbaik tidak hanya untuk menemukan kesalahan, namun juga unutk menilai kualitas program.
2. Menspesifikasikan tujuan pengujian secara eks perangkat lunak. Sasaran spesifik dari pengujian harus dinyatakan dalam bentuk yang terukur
3. Mengidentifikasikan kategori user untuk perangkat lunak dan membuat profilnya masing-masing. Beberapa kasus yang menggambarkan scenario interaksi bagi masing-masing kategori dapat mengurangi kerja pengujian dengan memfokuskan pengujian pada penggunaan actual produk.
4. Membangun rencana pengujian yang menegaskan rapid cycle testing. Umpan balik yang muncul dari rapid cycletesting dapat digunakan untuk mengontrol kualitas dan strategi pengujian yang sesuai.
5. Membangun perangkat lunak yang tangguhyang dirancang untuk menguji dirinya sendiri. Perangkat lunak dapatmendiagnosis jenis-jenis kesalahan tertentu dan mengakomodasi pengujianotomatis dan pengujian regresi.
6. Menggunakan tinjauan formal yang efektif sebagai filter sebelum pengujian. Kajian teknis formal dapat mengungkap kesalahan seefektif pengujian sehingga dapat mengurangi jumlah kerja pengujian.
7. Mengadakan tinjauan formal dapat mengungkap inkonsistensi, penghapusan, dan kesalahan seketika dalam pendekatan pengujian.
8. Membangun pendekatan yang meningkat secara berkelanjutan untuk proses pengujian. Strategi pengujian harus terukur.Metric yang terkumpul selama pengujian harus digunakan sebagai bagian dari pendekatan control proses statistical bagi pengujian perangkat lunak.
C. PengujianUnit
Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain perangkat lunak, yakni modul. Ujicoba unit selalu berorientasi pada white box testing dan dapat dikerjakan paralel atau beruntun dengan modul lainnya.
PertimbanganPengujian Unit
Interface modul diuji untuk memastikan bahwa informasi secara tepat mengalir masuk dan keluar dari inti program yang diuji. Struktur data local diuji untuk memastikan bahwa data yang tersimpan secara temporal dapat tetap menjaga integritasnya selama semua langkah langkah di dalam suatu algoritma dieksekusi. Kondisi batas diuji untuk memastikan bahwa modul beroperasi dengan tepat pada batas yang ditentukan untuk membatasi pemrosesan. Semua jalur independen(jalur dasar) yang melalui struktur control dipakai sedikirnya satu kali. Dan akhirnya penanganan kesalan diuji.
Prosedur Pengujian Unit
sumber telah dikembangkan, ditunjang kembali dan diverifikasi untuk sintaksnya, maka perancangan test case dimulai. Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul bukan program yang berdiri sendiri maka driver (pengendali)dan atau stub perangkat lunaK harus dikembangkan untuk pengujian unit.
Driver adalah program yg menerima data untuk test case dan menyalurkan ke modul yg diuji dan mencetak hasilnya.
Stub melayani pemindahan modul yg akan dipanggil untuk diuji
D. Pengujian Integrasi
Pengujian terintegrasi adl teknik yg sistematis untuk penyusunan struktur program, pada saat dikerjakan uji coba untuk memeriksa kesalahan yg nantinya digabungkan dengan interface. Metode pengujian:
1. Top down integration
Merupakan pendekatan inkrmental untuk penyusunan struktur program. Modul dipadukan dgn bergerak ke bawah melalui kontrol hirarki dimulai dari modul utama. Modul subordinat ke modul kontrol utama digabungkan ke dalam struktur baik menurut depth first atau breadth first.
Proses integrasi:
a. Modul utama digunakan sebagai test driver dan stub yg menggantikan seluruh modul yg secara langsung berada di bawah modul kontrol utama.
b. Tergantung pada pendekatan perpaduan yg dipilih (depth / breadth)
c. Uji coba dilakukan selama masing-masing modul dipadukan
d. Pada penyelesaian masing-masing uji coba stub yg lain dipindahkan dengan modul sebenarnya.
e. Uji coba regression yaitu pengulangan pengujianuntuk mencari kesalahan lain yg mungkin muncul.
2. Buttom up integration
Pengujian buttom up dinyatakan dgn penyusunan yang dimulai dan diujicobakan dengan atomic modul (modul tingkat paling bawah pada struktur program). Karena modul dipadukan dari bawah ke atas, proses yang diperlukan untuk modul subordinat yang selalu diberikan harus ada dan diperlukan untuk stub yang akan dihilangkan.
Strategi pengujian
a. Modul tingkat bawah digabungkan ke dalam cluster yang memperlihatkan sub fungsi perangkat lunak
b. Driver (program kontrol pengujian) ditulis untuk mengatur input test case dan output
c. Cluster diuji
d. Driver diganti dan cluster yg dikombinasikan dipindahkan ke atas pada struktur program
E. Pengujian Validasi
Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi tertinggi. Pengujian validasi dikatakan berhasil bila fungsi yg ada pada perangkat lunak sesuai dengan yg diharapkan pemakai. Validasi perangkat lunak merupakan kumpulan seri uji coba black box yg menunjukkan sesuai dengan yang diperlukan.
Kemungkinan kondisi setelah pengujian:
1. Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima
2. Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.
Pengujian BETA dan ALPHA
Apabila PERANGKAT LUNAK dibuat untuk pelanggan maka dapat dilakukan aceeptance test sehingga memungkinkan pelanggan untuk memvalidasi seluruh keperluan. Test ini dilakukan karena memungkinkan pelanggan menemukan kesalahan yang lebih rinci danmembiasakan pelanggan memahami PERANGKAT LUNAK yg telah dibuat.
Pengujian Alpha
Dilakukan pada sisi pengembang oleh seorang pelanggan.Perangkat Lunak digunakan pada setting yg natural dengan pengembang “yang memandang”melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian
Pengujian Beta
Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir perangkat lunak dalam lingkungan yg sebenarnya, pengembang biasanya tidak ada pada pengujian ini. Pelanggan merekan semua masalah (real atau imajiner) yg ditemui selama pengujian dan melaporkan pada pengembang pada interval waktu tertentu.
F. Pengujian Sistem.
Pada akhirnya PERANGKAT LUNAK digabungkan dgn elemensystem lainnya dan rentetan perpaduan system dan validasi tes dilakukan. Jikauji coba gagal atau di luar skope dari proses daur siklus pengembangan system,langkah yg diambil selama perancangan dan pengujian dapat diperbaiki.Keberhasilan perpaduan PERANGKAT LUNAK dan system yg besar merupakan kuncinya.
Sistem testing merupakan rentetan pengujian yg berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen system yang dikembangkan.
Recovery Testing
Adalah system testing yg memaksa PERANGKAT LUNAK mengalami kegagalan dalam bermacam-macam cara dan apakah perbaikan dilakukan dengan tepat.
Security Testing
Adalah pengujian yg akan melalukan verifikasi dari mekanisme perlindungan yg akan dibuat oleh system, melindungi dari hal-hal yang mungkin terjadi.
Strees Testing
Dirancang untuk menghadapi situasi yg tidak normal pada saat program diuji. Testing ini dilakukan oleh system untuk kondisi seperti volume data yg tidak normal (melebihi atau kurang dari batasan) atau fekuensi.
G. Debugging
Debugging bukan merupakan pengujian, namun merupakan konsekuensi dari pengujian yang berhasil. Jika sebuah kasus uji berhasil menemukan kesalahan, maka proses debugging bertujuan untuk menghilangkan kesalahan tersebut.
Debugging merupakan proses yang sulit untuk dilakukan karena adanya beberapa karakteristik bug seperti:
1. Gejala dan penyebab dari bug bisa saja sangat jauh, gejala dapat muncul pada bagian tertentu dari program dan penyebabnya bisa saja berada pada bagian lain yang sangat jauh dari tempat munculnya gejala.
2. Gejala dapat hilang ketika kesalahan yang lain diperbaiki
3. Gejala dapat ditimbulkan oleh sesuatu yang tidak salah(mis. Pembulatan yang tidak akurat).
4. Gejala dapat disebabkan oleh masalah timing.
5. Kemungkinan sulit untuk memproduksi kondisi output secara akurat.
6. Gejala dapat terjadi tiba-tiba.
7. Gejala dapat disebabkan oleh sesuatu yang didistribusikan melewati sejumlah tugas yang bekerja pada prosesor yang berbeda-beda.
Terdapat 3 jenis pendekatan debugging, antara lain:
a. Brute Force
Merupakan teknik yang paling sering digunakan dan paling tidak efisien dalam mengisolasi penyebab kesalahan. Dengan prinsip “biarkan computer menemukan kesalahan”, maka seluruh sumber daya komputer digunakan dengan tujuan untuk menemukan penyebab kesalahan
b. Backtracking
Merupakan pendekatan yang dimulai dari penemuan gejala kemudian menelusuri balik hingga ke penyebab.
c. Cause Elimination
Dimana infestasikan oleh induksi atau deduksi dan menggunakan konsep partisi biner. Data yang berhubungan dengan kesalahan yang muncul dikumpulkan untuk mengisolasi penyebab. Kemudian dibuat sebuah hipotesis dan data digunakan untuk membuktikan hipotesis tersebut.Daftar rangkaian penyebab yang mungkin dibuat dan dilakukan pengujian untuk mengeliminasi penyebab-penyebab tersebut. Jika pengujian menunjukkan kebenaran hipotesis untuk suatu penyebab, maka data diperbaiki untuk mengisolasi bug. Sekali bug ditemukan, bug harus diperbaiki. Namun, perbaikan pada bug dapat memunculkan kesalahan lain.
Komentar
Posting Komentar