STRATEGI PENGUJIAN PERANGKAT LUNAK
Rabu, 04 Juli 2012
1
komentar
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 :
- Pengujian mulai pada tingkat modul yg paling bawah, dilanjutkan dgn modul di atasnya kemudian hasilnya dipadukan
- Teknik pengujian yang berbeda mungkin menghasilakn sedikit perbedaan (dalam hal waktu)
- Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatu kelompok pengujian yang independen.
- 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 denga 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 basisdata,
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:
Ø 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.
Ø 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 harrus memperbaiki kesalahan yang ditemukan.
Ø 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 terlinat
pada keseluruhan proyek besar.
B.
Masalah-Masalah Strategis
Masalah-masalah berikut harus diselesaikan bila pengujian ingin
berlangsung sukses:
- Menspesifikasikan kebutuhan produk pada kelakuan yang terukur sebelum pengujian dimulai. Strategi pengujian yang baik tidak hanya untuk menenmukan kesalahan, namun juga unutk menilai kualitas program.
- Menspesifikasikan tujuan pengujian secara eksperangkat lunakisit. Sasaran spesifik dari pengujian harus dinyatakan dalam bentuk yang terukur
- 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.
- Membangun rencana pengujian yang menegaskan rapid cycle testing. Umpan balik yang muncul dari rapid cycle testing dapaat digunakan untuk mengontrol kualitas dan strategi pengujian yang sesuai.
- Membangun perangkat lunak yang tangguh yang dirancang untuk menguji dirinya sendiri. Perangkat lunak dapat mendiagnosis jenis-jenis kesalahan tertentu dan mengakomodasi pengujian otomatis dan pengujian regresi.
- Menggunakan tinjauan formal yang efektif sebagai filter sebekum pengujian. Kajian teknis formal dapat mengungkap kesalahan seefektif pengujian sehingga dapat mengurangi jumlah kerja pengujian.
- Mengadakan tinjauan formal dapat mengungkap inkonsistensi, penghapusan, dan kesalahan seketika dalam pendekatan pengujian.
- 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.
Pengujian Unit
Unit testing (uji coba unit) fokusnya pada
usaha verifikasi pada unit terkecil dari desain perangkat lunak, yakni modul.
Uji coba unit selalu berorientasi pada white box testing dan dapat dikerjakan
paralel ayau beruntun dengan modul lainnya.
Pertimbangan
Pengujian 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 yg berdiri sendiri maka driver
(pengendali) dan atau stub perangkat lunaK harus dikembangkan untuk pengujian
unit.
Driver
adl 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:
Proses integrasi:
- modul utama digunakan sebagai test driver dan stub yg menggantikan seluruh modul yg secara langsung berada di bawah modul kontrol utama.
·
Tergantung pada
pendekatan perpaduan yg dipilih (depth / breadth)
· Uji coba dilakukan
selama masing-masing modul dipadukan
·
Pada penyelesaian
masing-masing uji coba stub yg lain dipindahkan dgn modul sebenarnya.
·
Uji coba
regression yaitu pengulangan pengujian untuk mencari kesalahan lain yg mungkin
muncul.
2.
Buttom up
integration
Pengujian buttom up dinyatakan dgn
penyusunan yg dimulai dan diujicobakan dgn atomic modul (modul tingkat paling
bawah pd struktur program). Karena modul dipadukan dari bawah ke atas, proses yg
diperlukan untuk modul subordinat yg selalu diberikan harus ada dan diperlukan
untuk stub yg akan dihilangkan.
Strategi pengujian:
Strategi pengujian:
·
Modul tingkat
bawah digabungkan ke dalam cluster yg memperlihatkan subfungsi perangkat lunak
· Driver (program
kontrol pengujian) ditulis untuk mengatur input test case dan output
·
Cluster diuji
·
Driver diganti dan
cluster yg dikombinasikan dipindahkan ke atas pada struktur program
E.
Pengujian Validasi
Setelah semua kesalahan diperbaiki maka
langkah selanjutnya adalah validasi terting. Pengujian validasi dikatakan
berhasil bila fungsi yg ada pada perangkat lunak sesuai dgn yg diharapkan
pemakai. Validasi perangkat lunak merupakan kumpulan seri uji coba black box yg
menunjukkan sesuai dgn yg diperlukan.
Kemungkinan kondisi setelah pengujian:
1.
Karakteristik
performansi fungsi sesuai dgn 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 yg lebih rinci dan membiasakan pelanggan memahami PERANGKAT LUNAK yg
telah dibuat.
Pengujian Alpha
Dilakukan pada sisi pengembang oleh seorang pelanggan. Perangkat
Lunak digunakan pada setting yg natural dgn pengembang “yg 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 elemen system lainnya dan rentetan perpaduan system dan validasi tes
dilakukan. Jika uji 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 dgn tujuan utama mengerjakan keseluruhan elemen system yg
dikembangkan.
Recovery Testing
Adalah system testing yg memaksa PERANGKAT
LUNAK mengalami kegagalan dalam bermacam-macam cara dan apakah perbaikan
dilakukan dgn tepat.
Security Testing
Adalah pengujian yg akan melalukan
verifikasi dari mekanisme perlindungan yg akan dibuat oleh system, melindungi
dari hal-hal yg 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:
Ø 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.
Ø Gejala dapat hilang ketika kesalahan yang lain diperbaiki
Ø Gejala dapat ditimbulkan oleh sesuatu yang tidak salah(mis.
Pembulatan yang tidak akurat).
Ø Gejala dapat disebabkan oleh masalah timing.
Ø Kemungkinan sulit untuk memproduksi kondisi onput secara akurat.
Ø Gejala dapat terjadi tiba-tiba.
Ø Gejala dapat disebabkan oleh sesuatu yang didistribusikan melewati
sejumlah tugas yang bekerja pada prosesor yang berbeda-beda.
Terdapat 3 jenis pendekatan debugging, antara lain:
1.
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 computer digunakan dengan tujuan untuk menemukan penyebab
kesalahan
2.
Backtracking
Merupakan
pendekatan yang dimulai dari penemuan gejala kemudian menelusuri balik hingga
ke penyebab.
3.
Cause Elimination
Dimanifestasikan
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, maka ada beberapa
pertimbangan sebelum bug dihilangkan antara lain:
Ø Apakah penyebab bug ada pada bagian lain dari program?
Ø Apakah “bug yang lain” mungkin terjadi pada saat perbaikan
dilakukan?
Ø Apakah yang telah dilakukan untuk mencegah bug pada tempat pertama?
1 komentar:
thanks infonya comment balik ya http://blog-arul.blogspot.com
Posting Komentar