- Strategi uji coba Perangkat Lunak memudahkan para perancang untuk menentukan keberhasilan sistem 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.
Pengujian Perangkat
Lunak adalah satu elemen dari topik yang lebih luas yang sering diacu sebagai verifikasi dan validasi (V& V).
- Verifikasi : Kumpulan aktifitas yg menjamin penerapan Perangkat Lunak benar-benar sesuai dgn fungsinya.
- Validasi : Kumpulan aktivitas yang berbeda yang memastikan bahwa Perangkat Lunak yang dibangun
dapat memenuhi keperluan pelanggan. Dengan kata lain :
- Verifikasi : “ Apakah kita membuat produk dgn benar?”
- Validasi : “ Apakah kita membuat benar-benar suatu produk?”
- Definisi dari V&V meliputi berbagai aktivitas yang kita rujuk sebagai jaminan kualias Perangkat Lunak (SQA).
- Pengujian merupakan salah satu tugas yg ada dlm arus siklus pengembangan system yg dapat digambarkan dalam bentuk spiral :
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 atau beruntun dengan modul lainnya.
Pertimbangan
Pengujian Unit
- Interface diuji cobakan untuk menjamin informasi yg masuk atau yg ke luar dari unit program telah tepat atau sesuai dgn yg diharapkan.
- Yang pertama diuji coba adalah interface karena diperlukan untuk jalannya informasi atau data antar modul.
Myers mengusulkan checklist
untuk pengujian interface:
- Apakahjumlah parameter input sama dengan jumlah argumen?
- Apakah antara atribut dan parameter argumen sudah cocok?
- Apakah antara sistem satuan parameter dan argument sudah cocok?
- Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan jumlah parameter?
Apakah atribut dari
argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut
parameter?
- Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter?
- Apakah jumlah atribut dari urutan argumen ke fungsi-fungsi built-in sudah benar?
- Adakah referensi ke parameter yang tidak sesuai dengan pain entri yang ada?
- Apakah argumen input-only diubah?
- Apakah definisi variabel global konsisten dengan modul?
- Apakah batasan yang dilalui merupakan argumen?
Bila sebuah modul
melakukan I/O ekstemal, maka pengujian interface tambahan harus dilakukan:
- Atribut file sudah benar?
- Pemyataan OPEN/CLOSE sudah benar?
- Spesifikasi format sudah cocok dengan pernyataan I/O?
- Ukuran buffer sudah cocok dengan ukuran rekaman?
- File dibuka sebelum penggunaan?
- Apakah kondisi End-of-File ditangani?
- Kesalahan I/O ditangani?
- Adakah kesalahan tekstual di dalam informasi output?
Kesalahan yang umum di
dalam komputasi adalah:
- Kesalah-pahaman atau prosedur aritmatik yang tidak benar
- Operasi mode yang tercampur
- Inisialisasi yang tidak benar
- Inakurasi ketelitian
- Representasi simbolis yang tidak benar dari sebuah persamaan.
Test case harus
mengungkap kesalahan seperti :
- Perbandingan tipe data yang berbeda
- Preseden atau operator logika yang tidak benar
- Pengharapan akan persamaan bila precision error membuat persamaan yang tidak mungkin
- Perbandingan atau variabel yang tidak benar
- Penghentian loop yang tidak ada atau tidak teratur
- Kegagalan untuk keluar pada saat terjadi iterasi divergen
- Variabel loop yang dimodifikasi secara tidak teratur.
Tidak ada komentar:
Posting Komentar