STRATEGI PENGUJIAN PERANGKAT LUNAK

Posted by pendidikan yang sesungguhnya 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:

  •            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:
         ·         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:

Unknown mengatakan...

thanks infonya comment balik ya http://blog-arul.blogspot.com

Posting Komentar

Total Tayangan Halaman