Testing dan Implementasi Sistem
1. SDLC
System Development Life Cycle disingkat dengan SDLC.
SDLC merupakan siklus pengembangan sistem. Pengembangan sistem teknik
(engineering system development). SDLC berfungsi untuk menggambarkan
tahapan-tahapan utama dan langkah-langkah dari setiap tahapan yang secara garis
besar terbagi dalam empat kegiatan utama, yaitu
initiation,
analysis,
design
implementation.
Setiap kegiatan dalam SDLC dapat dijelaskan melalui tujuan
(purpose) dan
hasil kegiatannya (deliverable). SDLC didefinisikan oleh
Departemen Kehakiman AS sebagai sebuah proses pengembangan software yang
digunakan oleh analyst system, untuk mengembangkan sebuah sistem informasi.
SDLC mencakup kebutuhan (requirement), validasi, pelatihan, kepemilikan (user
ownership) sebuah sistem informasi yang diperoleh melalui investigasi,
analisis, desain, implementasi, dan perawatan software. Software yang
dikembangkan berdasarkan SDLC akan menghasilkan sistem dengan kualitas yang
tinggi, memenuhi harapan penggunanya, tepat dalam waktu dan biaya, bekerja
dengan efektif dan efsien dalam infrastruktur teknologi informasi yang ada atau
yang direncanakan, serta murah dalam perawatan dan pengembangan lebih lanjut.
2. Teknik Pengujian Perangkat Lunak
Pengujian white box
Menggunakan metode desain test case yang menggunakan
struktur control desain procedural untuk memperoleh test case. Disebut juga
pengujian glassbox. Dengan pengujian whitebox, perekayasa dapat melakukan :
Memberikan jaminan bahwa semua jalur independen pada suatu
modul telah digunakan paling tidak satu kali.
Menggunakan semua keputusan logis pada sisi true and false.
Mengeksekusi semua loop pada batasan mereka dan pada batas
operasional mereka.
Menggunakan struktur data internal untuk menjamin
validitasnya.
Dengan meenggunakan metode white box, analis sistem akan
dapat memperoleh test case yang:
menjamin seluruh independent path di dalam modul yang
dikerjakan sekurang-kurangnya sekali.
mengerjakan seluruh keputusan logikal.
mengerjakan seluruh loop yang sesuai dengan batasannya.
mengerjakan seluruh struktur data internal yang menjamin
validitas.
Keunggulan dan Kekurangan White Box
Keunggulan
Kebenaran program dalam mendefinisikan algoritma dapat
diketahui secara langsung dengan pengolahan path.
Menentukan kualitas pekerjaan coding dan pengaruhnya untuk
standar coding.
Kekurangan
Jumlah biaya untuk white box testing lebih besar daripada
biaya yang dibutuhkan untuk black box, untuk ukuran software yang sama.
Belum mampu melakukan tes ketersediaan, kehandalan, daya
tahan beban dan testing – testing lain yang berhubungan dengan kebutuhan faktor
– faktor untuk operasi, revisi dan transisi.
Black box testing
Adalah metode pengujian perangkat lunak yang tes
fungsionalitas dari aplikasi yang bertentangan dengan struktur internal atau
kerja (lihat pengujian white-box).
Pengujian black box
Berfokus pada persyaratan fungsional perangkat lunak.
Disebut juga pengujian behavioral atau pengujian partisi. Pengujian black box
memungkinkan perekayasa perangkat lunak mendapatkan serangkaian input yang
sepenuhnya menggunakan semua persyaratan fungsional untuk suatu program.
Pengujian black box berusaha menemukan :
• Fungsi-fungsi yang tidak benar atau hilang
• Kesalahan interface
• Kesalahan dalam struktur data atau akses database
eksternal.
• Kesalahan kinerja
• Inisialisasi dan kesalahan terminasi.
• Kesalahan performansi
• Kesalahan inisialisasi dan tujuan akhir
Dengan mengaplikasikan teknik black box, maka kita menarik
serangkaian test case yang
memenuhi kriteria berikut :
• Test case yang mengurangi, dengan harga lebih dari satu,
jumlah test case tambahan yang harus didesain untuk mencapai pengujian
yang dapat
dipertanggungjawabkan.
•Test case yang member tahu kita sesuatu mengenai kehadiran
atau ketidakhadiran
kelas kesalahan, daripada member tahu kesalahan yang
berhubungan hanya
dengan pengujian spesifik.
Keunggulan dan Kekurangan Black Box:
Keunggulan
Black box testing dapat menguji keseluruhan fungsionalitas
perangkat lunak.
Black box testing dapat memilih subset test yang secara
efektif dan efisien dapat menemukan cacat. Dengan cara ini black box testing
dapat membantu memaksimalkan testing investment.
Kekurangan
Ketika tester melakukan black box testing, tester tidak akan
pernah yakin apakah perangkat lunak yang diuji telah benar-benar lolos
pengujian.
3. Faktor Penujian Perangkat Lunak
Pengujian Tahapan Analisis
Pengujian pada tahapan ini lebih menekankan pada validasi
terhadap kebutuhan perangkat lunak, untuk menjamin bahwa kebutuhan telah
dispesifikasikan dengan benar. Tujuan pengujian pada tahap ini adalah untuk
mendapatkan kebutuhan yang layak dan untuk memastikan apakah kebutuhan tersebut
sudah dirumuskan dengan baik. Faktor-faktor pengujian yang dilakukan meliputi :
Kebutuhan yang berkaitan dengan metodelogi
Pendefinisian spesifikasi fungsional
Penentuan spesifikasi kegunaan
Penentuan kebutuhan portabilitas
Pendefinisian antar muka sistem.
Pengujian Tahapan Desain
Pengujian pada tahapan ini bertujuan untuk menguji struktur
perangkat lunak yang diturunkan dari kebutuhan perangkat, kebutuhan yang
bersifat umum dirinci menjadi bentuk yang lebih spesifik. Faktor-faktor
pengujian yang dilakukan meliputi :
Perancangan yang berkaitan dengan kebutuhan
Kesesuaian perancangan dengan metodologi dan teori.
Portabilitas rancangan
Perancangan yang dirawat
Kebenaran rancangan berkaitan dengan fungsi dan aliran data.
Kelengkapan perancangan antar muka.
Pengujian Tahapan Implementasi
Merupakan pengujian unit-unit yang dibuat sebelum
diintegrasikan mejadi aplikasi secara keseluruhan. Faktor-faktor pengujian
tahap implementasi meliputi :
Kendali integritas data
Kebenaran program
kemudahan pemakaian
Sifat coupling
Pengembangan prosedur operasi.
Pengujian Tahapan Pengujian
Pengujian pada tahapan ini dilakukan untuk menilai apakah
spesifikasi program telah ditulis menjadi instruksi-instruksi yang dapat
dijalankan pada mesin/komputer. Selain itu, juga untuk menilai apakah instruksi
yang ditulis tersebut telah sesuai dengan spesifikasi program. Faktor-faktor
pengujian tahap ini meliputi :
Pengujian fungsional
Dukungan manual
Kemudahan operasi
4. Strategi Pengujian Perangkat Lunak
Dalam strategi pengujianperangkat lunak dapat digambarkan
dengan ilustrasi berikut: Sebuah perangkat lunak dimulai daripenentuan
kebutuhan perangkat lunak, kemudian prose dilanjutkan ke dalam bentukrancangan,
dan akhirnya ke pengkodean.
Strategi pengujian serupa dengan haltersebut, dimulai dengan unit testing di pusat spiral di mana masing-masingmodul/unit dari perangkat lunak yang diimplementasikan dalam source codemenjadi sasaran pengujian. Kemudian dilakukan integration testing dengan focuspengujian adalah desain dan kontruksi arsitektur perangkat lunak. Selanjutnyadilakukan validation testing dengan sasaran pengujian adalah kesesuaian dengankebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir padalingkaran terluar spiral sampai pada system testing, di mana perangkat lunakdan keseluruhan sistem diuji.
Strategi pengujian serupa dengan haltersebut, dimulai dengan unit testing di pusat spiral di mana masing-masingmodul/unit dari perangkat lunak yang diimplementasikan dalam source codemenjadi sasaran pengujian. Kemudian dilakukan integration testing dengan focuspengujian adalah desain dan kontruksi arsitektur perangkat lunak. Selanjutnyadilakukan validation testing dengan sasaran pengujian adalah kesesuaian dengankebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir padalingkaran terluar spiral sampai pada system testing, di mana perangkat lunakdan keseluruhan sistem diuji.
A. PendekatanStrategis ke Pengujian Perangkat lunak
Pengujianmerupakan rangkaian aktivitas yang dapat
direncanakan sebelumnya dan dilakukansecara sistematis. Strategi uji coba
perangkat lunak memudahkan para perancanguntuk menentukan keberhasilan system
yg telah dikerjakan. Hal yg harusdiperhatikan adalah langkah-langkah
perencanaan dan pelaksanaan harusdirencanakan dengan baik dan berapa lama
waktu, upaya dan sumber daya ygdiperlukan Strategi uji coba mempunyai
karakteristik sbb :
a. Pengujian mulai pada tingkat modul yg paling
bawah,dilanjutkan dgn modul di atasnya kemudian hasilnya dipadukan
b. Teknik pengujianyang berbeda mungkin menghasilakn
sedikit perbedaan (dalam hal waktu)
c. Pengujiandilakukan oleh pengembang perangkat lunak
dan (untuk proyek yang besar) suatukelompok pengujian yang independen.
d. Pengujian dandebugging merupakan aktivitas yang
berbeda, tetapi debugging termasuk dalamstrategi pengujian.
Validasi dan validasi
Verifikasi dan validasi merupakandua istilah yang sering
dikaitkan dengan tahapan pengujian perangkat lunak.Verifikasi mengacu pada
serangkaian aktivitas untuk memastikan bahwa perangkatlunak mengimplementasikan
fungsi tertentu secara benar, sedangkan validasimengacu pada serangkaian
aktivitas untuk memastikan bahwa perangkat lunak yangtelah dibuat sesuai denga
kebutuhan konsumen.
Definisi V&V mencakupserangkaian aktivitas dari
penjaminan kualitas perangkat lunak (SQA) yangmeliputi kajian teknis formal,
audit kualitas dan control, monitoring kinerja,simulasi, studi feasibilitas,
kajian dokumentasi, kajian basisdata, analisisalgoritma, pengujian
pengembangan, pengujian kualifikasi, dan pengujianinstalasi.
Pengorganisasian Pengujian Perangkat Lunak
Proses pengujian sebuah perangkat lunaksebaiknya melibatkan
pihak yang memang secara khusus bertanggung jawab untukmelakukan proses
pengujian secara independen. Untuk itulah diperlukanIndependent Test Group
(ITG).
Peran dari ITG adalah untuk menghilangkan“conflict of
interest” yang terjadi ketika pengembang perangkat lunak berusahauntuk menguji
produknya sendiri.
Walaupun seperti itu, sering terjadibeberapa kesalahan
pemahaman berkaitan dengan peran ITG, antara lain:
a. Pengembangtidak boleh melakukan pengujian sama sekali.
Pendapat ini tidak 100% benar,Karena dalam banyak kasus, pengembang juga
melakukan proses unit testing danintegration test.
b. Perangkatlunak dilempar begitu saja untuk diuji secara
sporadic. Hal tersebut adalahsalah karena pengemmbang dan ITG bekerja sama pada
kesalahan proyek untukmemastikan pengujian akan dilakukan. Sementara pengujian
dilakukan, pengembangharrus memperbaiki kesalahan yang ditemukan.
c. Pengujitidak terlibat pada proyek sampai tahap pengujian
dimulai. Hal tersebut salahkarena ITG merupakan bagian dari tim proyek
pengembangan perangkat lunak dimanaia terlihat selama spesifikasi proses dan
tetap terlinat pada keseluruhanproyek besar.
B. Masalah-Masalah Strategis
Masalah-masalah berikut harus diselesaikanbila pengujian
ingin berlangsung sukses:
1. Menspesifikasikan kebutuhan produkpada kelakuan yang
terukur sebelum pengujian dimulai. Strategi pengujian yangbaik tidak hanya
untuk menenmukan kesalahan, namun juga unutk menilai kualitasprogram.
2. Menspesifikasikan tujuan pengujiansecara
eksperangkat lunakisit. Sasaran spesifik dari pengujian harus dinyatakandalam
bentuk yang terukur
3. Mengidentifikasikan kategori useruntuk perangkat
lunak dan membuat profilnya masing-masing. Beberapa kasus yangmenggambarkan
scenario interaksi bagi masing-masing kategori dapat mengurangikerja pengujian
dengan memfokuskan pengujian pada penggunaan actual produk.
4. Membangun rencana pengujian yangmenegaskan rapid
cycle testing. Umpan balik yang muncul dari rapid cycletesting dapaat digunakan
untuk mengontrol kualitas dan strategi pengujian yangsesuai.
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
sebekum pengujian.Kajian teknis formal dapat mengungkap kesalahan seefektif
pengujian sehinggadapat mengurangi jumlah kerja pengujian.
7. Mengadakan tinjauan formal dapatmengungkap
inkonsistensi, penghapusan, dan kesalahan seketika dalam pendekatanpengujian.
8. Membangun pendekatan yang meningkatsecara
berkelanjutan untuk proses pengujian. Strategi pengujian harus terukur.Metric
yang terkumpul selama pengujian harus digunakan sebagai bagian daripendekatan
control proses statistical bagi pengujian perangkat lunak.
C. PengujianUnit
Unit testing (uji coba unit) fokusnya pada usahaverifikasi
pada unit terkecil dari desain perangkat lunak, yakni modul. Ujicoba unit
selalu berorientasi pada white box testing dan dapat dikerjakanparalel ayau
beruntun dengan modul lainnya.
PertimbanganPengujian Unit
Interface modul diuji untuk memastikan bahwa informasisecara
tepat mengalir masuk dan keluar dari inti program yang diuji. Strukturdata
local diuji untuk memastikan bahwa data yang tersimpan secara temporaldapat
tetap menjaga integritasnya selama semua langkah langkah di dalamsuatu
algoritma dieksekusi. Kondisi batas diuji untuk memastikan bahwa
modulberoperasi dengan tepat pada batas yang ditentukan untuk
membatasipemrosesan. Semua jalur independen(jalur dasar) yang melalui struktur
controldipakai sedikirnya satu kali. Dan akhirnya penanganan kesalan diuji.
Prosedur Pengujian Unit
sumber telah dikembangkan, ditunjang kembali dandiverifikasi
untuk sintaksnya, maka perancangan test case dimulai. Peninjauankembali
perancangan informasi akan menyediakan petunjuk untuk menentukan testcase.
Karena modul bukan program yg berdiri sendiri maka driver (pengendali)dan atau
stub perangkat lunaK harus dikembangkan untuk pengujian unit.
Driver adlprogram yg menerima data untuk test case dan
menyalurkan ke modul yg diuji danmencetak hasilnya.
Stub melayanipemindahan modul yg akan dipanggil untuk
diuji
D. Pengujian Integrasi
Pengujian terintegrasi adl teknik yg sistematis
untukpenyusunan struktur program, pada saat dikerjakan uji coba untuk
memeriksakesalahan yg nantinya digabungkan dengan interface. Metode pengujian:
1. Top down integration
Merupakan pendekatan inkrmental untuk penyusunanstruktur
program. Modul dipadukan dgn bergerak ke bawah melalui kontrol hirarkidimulai
dari modul utama. Modul subordinat ke modul kontrol utama digabungkanke dalam
struktur baik menurut depth first atau breadth first.
Proses integrasi:
a. Modul utama digunakan sebagai test driver danstub yg
menggantikan seluruh modul yg secara langsung berada di bawah modulkontrol
utama.
b. Tergantung pada pendekatan perpaduan yg
dipilih(depth / breadth)
c. Uji coba dilakukan selama masing-masing moduldipadukan
d. Pada penyelesaian masing-masing uji coba stub yglain
dipindahkan dgn 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 ygdimulai dan
diujicobakan dgn atomic modul (modul tingkat paling bawah pdstruktur program).
Karena modul dipadukan dari bawah ke atas, proses ygdiperlukan untuk modul
subordinat yg selalu diberikan harus ada dan diperlukanuntuk stub yg akan
dihilangkan.
Strategi pengujian
a. Modul tingkat bawah digabungkan ke dalam clusteryg
memperlihatkan subfungsi perangkat lunak
b. Driver (program kontrol pengujian) ditulisuntuk mengatur
input test case dan output
c. Clusterdiuji
d. Driver diganti dan cluster yg dikombinasikandipindahkan
ke atas pada struktur program
E. Pengujian Validasi
Setelah semua kesalahan diperbaiki maka langkahselanjutnya
adalah validasi terting. Pengujian validasi dikatakan berhasil bilafungsi yg
ada pada perangkat lunak sesuai dgn yg diharapkan pemakai. Validasiperangkat
lunak merupakan kumpulan seri uji coba black box yg menunjukkansesuai dgn yg
diperlukan.
Kemungkinan kondisi setelah pengujian:
1. Karakteristikperformansi fungsi sesuai dgn
spesifikasi dan dapat diterima
2. Penyimpangandari spesifikasi ditemukan dan dibuatkan
daftar penyimpangan.
Pengujian BETA dan ALPHA
Apabila PERANGKAT LUNAK dibuat untuk pelanggan makadapat
dilakukan aceeptance test sehingga memungkinkan pelanggan untukmemvalidasi
seluruh keperluan. Test ini dilakukan karena memungkinkan pelanggan menemukan
kesalahan yg 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 dgn pengembang “yg
memandang”melalui bahu pemakai dan merekam semua kesalahan dan masalah
pemakaian
Pengujian Beta
Dilakukan pada satu atau lebih pelanggan oleh pemakaiakhir
perangkat lunak dalam lingkungan yg sebenarnya, pengembang biasanya tidakada
pada pengujian ini. Pelanggan merekan semua masalah (real atau imajiner)
ygditemui selama pengujian dan melaporkan pada pengembang pada interval
waktutertentu.
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 ygberbeda-beda
dgn tujuan utama mengerjakan keseluruhan elemen system ygdikembangkan.
Recovery Testing
Adalah system testing yg memaksa PERANGKAT LUNAKmengalami
kegagalan dalam bermacam-macam cara dan apakah perbaikan dilakukandgn tepat.
Security Testing
Adalah pengujian yg akan melalukan verifikasi darimekanisme
perlindungan yg akan dibuat oleh system, melindungi dari hal-hal ygmungkin
terjadi.
Strees Testing
Dirancang untuk menghadapi situasi yg tidak normalpada saat
program diuji. Testing ini dilakukan oleh system untuk kondisi seperti
volume data yg tidak normal (melebihiatau kurang dari batasan) atau fekuensi.
G. Debugging
Debugging bukan merupakanpengujian, namun merupakan
konsekuensi dari pengujian yang berhasil. Jikasebuah kasus uji berhasil
menemukan kesalahan, maka proses debugging bertujuanuntuk menghilangkan
kesalahan tersebut.
Debugging merupakan proses yangsulit untuk dilakukan karena
adanya beberapa karakteristik bug seperti:
1. Gejala dan penyebab dari bug bisa sajasangat jauh,
gejala dapat muncul pada bagian tertentu dari program danpenyebabnya bisa saja
berada pada bagian lain yang sangat jauh dari tempatmunculnya gejala.
2. Gejala dapat hilang ketika kesalahanyang lain diperbaiki
3. Gejala dapat ditimbulkan oleh sesuatuyang tidak
salah(mis. Pembulatan yang tidak akurat).
4. Gejala dapat disebabkan oleh masalahtiming.
5. Kemungkinan sulit untuk memproduksikondisi onput
secara akurat.
6. Gejala dapat terjadi tiba-tiba.
7. Gejala dapat disebabkan oleh sesuatuyang
didistribusikan melewati sejumlah tugas yang bekerja pada prosesor
yangberbeda-beda.
Terdapat 3 jenis pendekatandebugging, antara lain:
a. Brute Force
Merupakan teknik yang paling seringdigunakan dan paling
tidak efisien dalam mengisolasi penyebab kesalahan. Denganprinsip “biarkan
computer menemukan kesalahan”, maka seluruh sumber dayacomputer digunakan
dengan tujuan untuk menemukan penyebab kesalahan
b. Backtracking
Merupakan pendekatan yang dimulaidari penemuan gejala
kemudian menelusuri balik hingga ke penyebab.
c. Cause Elimination
Dimanifestasikan oleh induksi ataudeduksi dan menggunakan
konsep partisi biner. Data yang berhubungan dengankesalahan yang muncul dikumpulkan
untuk mengisolasi penyebab. Kemudian dibuatsebuah hipotesis dan data digunakan
untuk membuktikan hipotesis tersebut.Daftar rangkaian penyebab yang mungkin
dibuat dan dilakukan pengujian untukmengeliminasi penyebab-penyebab tersebut.
Jika pengujian menunjukkan kebenaranhipotesis untuk suatu penyebab, maka data
diperbaiki untuk mengisolasi bug.Sekali bug ditemukan, bug harus diperbaiki
Comments
Post a Comment