Materi   Testing

Terminologi

Software : seluruh komponen pengolahan data yang dapat membantu memecahkan masalah diluar dari perangkat hardware yang meliputi system design, program dan prosedur.

Beberapa gambaran umum tentang perangkat lunak antara lain  :

1)       Perintah (program computer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan.

2)       Struktur data yang memungkinkan program memanipulasi informasi secara proporsional.

3)       Dokumen yang menggambarkan operasi dan kegunaan program.

Jenis-jenis software antara lain :

1. CP/M-80 (control program for Microprocecor 8080) di pakai pada komputer Appel / Intel 8080

2. CP/m-86 (control program for Microprocecor 8086) di pakai untuk intel 80863. PC-Dos (Personal Computer Disk Operating System) di buat oleh Microsoft

Corppration4. MS-DOS (Microsoft Disk Operating System) pengembangan dari PC-DOS5. MS-Windows dibuat oleh Microsoft Corporation, mulai dari Windows 3.1, Windows

NT, Windows 95, Windows 98, Windows 2000 Profesional, dan Windows XP yang merupakan  perbaikan dari   versi  sebelumnya,  komponen  strategisnya  antara lain :

Fleksibel dengan hardware yang ada saat ini Menggunakan konfigurasi hardware otomatis Prosedur instalasi mudah Fasilitas jaringan network Telah memperbaiki bug-bug pada versi sebelumnya.

1. Unix adalah sistem operasi yang dikembangkan oleh Dennis M. Ritche dan Ken Thompson, di tulis dalam pemrograman bahasa C.

2. Linux.3. Dll.

Ada dua tipe produk perangkat lunak  :

1. Produk generik

2. Produk pesanan (yang disesuaikan)

Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merespresentasikan kajian pokok dari spesifikasi, desain dan pengkodean. Meningkatnya visibilitas perangkat lunak sebagai suatu elemen sistem dan “biaya” yang muncul akibat

kegagalan perangkat lunak, memotivasi dilakukannya perencanaan yang baik melalui pengujian yang teliti.

Pengujian  termasuk dalam  teknik verifikasi  dan validasi  (V & V). Pengujian melibatkan pelatihan perangkat lunak dengan memakai data seperti data riil yang diolah oleh perangkat lunak.

Tujuan akhir dari proses verifikasi dan validasi adalah menanamkan kepercayaan bahwa system perangkat lunak “siap untuk tujuannya”.

Apakah yang dimaksud dengan pengujian perangkat lunak   ?

Pengujian adalah proses menjalankan sebuah program dengan maksud menemukan kesalahan-kesalahan (error).

Proses untuk menjalankan sebuah program komputer dan membandingkan tingkah laku yang sesungguhnya dengan yang diharapkan.

Yang dimaksud membandingkan adalah menemukan bentuk penyimpangan-penyimpangan (jika ada). Antara lain membandingkan tingkah laku yang sesungguhnya dengan yang diharapkan.

Layanan pengujian sebagai bentuk suatu rintangan untuk menyediakan produk yang berkualitas dalam mendapatkan pelanggan

Pada saat V & V perangkat lunak, kesalahan pada perangkat lunak biasanya ditemukan dan kemudian diubah untuk membetulkan kesalahan tersebut. Proses debug ini seringkali terintegrasi dengan kegiatan verifikasi dan validasi lain.  Bagaimanapun, pengujian (atau lebih umum verifikasi dan validasi) dan debug merupakan proses yang berbeda yang tidak harus diintegrasikan :

1. Verifikasi dan validasi adalah proses yang meyakinkan  adanya kesalahan pada sistem perangkat lunak.

2. Debug merupakan proses yang menemukan dan membetulkan  kesalahan tersebut.

Tipe pengujian yang dapat digunakan pada berbagai tahap proses perangkat lunak  :

1.Pengujian cacat (Defect Testing)

Menetapkan keberadaan cacat sistem. Tujuannya untuk menemukan ketidak konsistenan antara program dan spesifikasinya. Dirancang untuk mengungkapkan adanya cacat pada sistem dan bukan untuk

mensimulasi penggunaan operasionalnya. Bermanfaat bagi pemrogram dan menunjukkan cacat-cacat yang ada di kode

(program).

2.Pengujian statistik

Menguji kinerja dan keandalan program dan memeriksa bagaimana kerjanya pada kondisi operasional

Dirancang untuk menunjukkan input user yang sebenarnya dan frekuensinya. Kehandalan sistem dapat dilakukan dengan menghitung kegagalan sistem yang

diteliti.

Sasaran Pengujian

Glen Myers menyatakan bahwa sasaran dari pengujian perangkat lunak adalah  :

1.  Pengujian adalah proses menjalankan suatu program dengan maksud menemukan kesalahan.

2.  Pengujian yang baik adalah yang memiliki kemungkinan tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya.

3.  Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya.

Satu hal yang perlu diingat/diperhatikan dalam pengujian terhadap perangkat lunak bahwa :

“Pengujian tidak dapat memperlihatkan kerusakan sistem, tetapi hanya dapat memperlihatkan bahwa ada kesalahan perangkat lunak. “

Kaner, Falk dan Nguyen mengusulkan atribut-atribut dari

pengujian yang “baik” sebagai berikut  :

1.  Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.

2.  Pengujian yang baik tidak redundan.

3.  Pengujian yang baik seharusnya “jenis terbaik”

4.  Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks.

Tidak semua pengujian akan berhasil dengan baik. Masih ada beberapa kekurangan  yang  terdapat   pada  pengujian   suatu  perangkat lunak.

Kekurangan-kekurangan tersebut antara lain :1.Tidak pernah cukup melakukan banyak ujian yang layak.

2.Pengujian tidak akan menemukan semua kesalahan

3.Pengujian sulit dan menghabiskan banyak waktu

4.Pengujian sebagian besar masih merupakan tugas yang tidak  resmi.

Prinsip-prinsip Pengujian

Sebelum menetapkan metode pengujian, seorang ahli pada bidang software harus mengerti betul atau memahami prinsip dasar yang menuntun pengujian perangkat lunak. Prinsip-prinsip pengujian secara umum yang banyak dianut oleh para ahli perangkat lunak, antara lain  :

�

Seorang Programmer seharusnya tidak menguji programnya sendiri. Sebaiknya satu pengujian tidak hanya mengerjakan program yang dianggap benar,

tetapi tidak mengerjakan yang dianggap salah. Tujuan dari pengujian adalah untuk menemukan kesalahan, bukan untuk

menunjukkan bahwa program tersebut salah. Tidak ada sejumlah pengujian yang dapat menjamin bahwa program bebas dari

kesalahan. Bagian-bagian dari program di mana terdapat banyak kesalahan yang telah ditemukan

adalah suatu tempat yang baik untuk menemukan kesalahan yang lebih banyak. Tujuannya adalah bukan untuk mempermalukan programmer.

�

Selain pernyataan diatas, Roger S. Pressman mendefinisikan sendiri  mengenai prinsip-prinsip pengujian terhadap perangkat lunak  :

Pengujian harus sesuai dengan persyaratan konsumen. Para ahli harus betul-betul mengetahui spesifikasi dari  produk (software) yang

diinginkan konsumen. Pengujian harus direncanakan lama  sebelum pengujian itu di mulai. Prinsip Pareto berlaku untuk pengujian perangkat lunak. 80 % kesalahan yang ditemukan, hanya dapat ditelusuri  sampai 20 % dari semua

modul program. Pengujian harus dimulai dari yang kecil dan berkembang ke pengujian yang besar. Pengujian berfokus dalam usaha menemukan kesalahan  pada modul yang

terintegrasi, dan akhirnya pad asistem  secara keseluruhan. Pengujian yang sempurna tidak mungkin. Agar  efektif, pengujian  harus dilakukan  oleh pihak  ketiga yang independent (third

party). Pengujian yang memiliki probabilitas tinggi untuk  menemukan kesalahan. Pembuat sistem bukanlah orang yang paling tepat untuk  melakukan semua pengujian

bagi perangkat lunak.

Kegagalan dan Kesalahan

Kesalahan sistem tidak selalu mengakibatkan eror sistem, karena status salahnya mungkin bersifat sementara dan dapat diperbaiki sebelum terjadi perilaku yang merupakan eror.

Jenis kegagalan dan kesalahan pada sistem antara lain  :

Kegagalan sistem (system failure)

Peristiwa yang terjadi pada suatu waktu ketika sistem tidak memberikan layanan sebagaiman diharapkan oleh user.

Eror sistem (system eror)

Perilaku eror sistem dimana perilaku, sistem yang tidak sesuai dengan spesifikasinya

Kesalahan sistem (system fault)

Status sistem yang tidak benar, yaitu status sistem yang tidak diharapkan oleh perancang sistem.

Eror atau kesalahan manusia (human error)

Perilaku manusia yang mengakibatkan kesalahan sistem.

Bagaimana kesalahan tersebut mempengaruhi kita  ?

Telah diketahui bahwa salah satu tujuan dari pengujian terhadap perangkat lunak, adalah untuk menemukan suatu kesalahan. Kesalahan-kesalahan tersebut mempunyai tingkatan-tingkatan yang diukur dengan istilah yang dimengerti oleh manusia. Tingkatan-tingkatan kesalahan tersebut dikategorikan sebagai berikut

A. MILD (ringan)

Gejala dari kesalahan yang mengganggu kita secara estetis

Kesalahan pengejaan Kesalahan penempatan

B. MODERATE (sedang)

Kesalahan yang berpengaruh pada penampilan system Informasi yang menyesatkan

C. ANNOYING (menjengkelkan)

• Kesalahan dari system karena adanya suatu virus.

▫   Nama yang terpotong

▫   Tagihan untuk Rp. 0,00 di cetak / dikirim

D. DISTURBING (mengganggu)

Sistem menolak untuk menangani transaksi yang sah

▫   Kartu kredit yang dilaporkan tidak bisa digunakan

E. SERIOUS (serius)

• Perhitungan yang salah

▫   Hal ini menghilangkan hubungan pada proses transaksi

▫   Tidak mencetak setiap pembayaran

F. VERY SERIOUS (sangat serius)

Kesalahan yang menyebabkan system melakukan transaksi yang salah

▫   Sebuah system kredit dapat melakukan kesalahan perhitungan.

G. EXTREME (besar)

Masalah yang tidak terbatas pada beberapa transaksi Sering berubah-ubah atau masalah yang tidak lazim

H. INTOLERABLE (kurang tahan)

Pertimbangan yang serius diberikan untuk mematikan system.

I. CATASTROPHIC (bencana besar)

Sistem yang salah

Testability (Kemampuan Test)

Testabilitas perangkat lunak adalah seberapa mudah sebuah program komputer dapat diuji. Karena pengujian sangat sulit, maka perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi mudah. Kadang-kadang pemrogram bersedia melakukan hal-hal yang akan membantu proses pengujian, dan membuat checklist (daftar periksa) mengenai masalah-masalah desain yang mungkin, fitur dan lain sebagainya yang dijadikan sebagai pedoman dalam melakukan pengujian.

Beberapa checklist dibawah ini, akan membantu sebagai pedoman dalam kegiatan pengujian perangkat lunak  :

1.  OPERABILITY. (Mampu menjalankan/operasi.)

Semakin baik hal tersebut dijalankan, pengujian akan semakin efesien. Sistem memiliki sedikit kesalahan. Tidak ada kesalahan yang menghalangi jalannya pengujian. Produk berkembang dalam tahapan fungsional (memungkinkan pengembangan dan

pengujian secara simultan)

2.  OBSERVABILITY(Kemampuan untuk mengamati/meneliti) “Apa yang dilihat adalah apa yang diuji.”

Output yang berbeda dikeluarkan oleh masing-masing input. Tahap dan variabel sistem dapat dilihat atau diantrikan selama eksekusi. Sistem dan variabel yang lalu dapat dilihat atau diantrikan (misalnya, logaritma

transaksi) Semua faktor yang mempengaruhi output dapat dilihat. Output yang tidak benar dapat diidentifikasi dengan mudah. Kesalahan internal dideteksi secara otomatis melalui mekanisme pengujian itu sendiri. Kesalahan internal dilaporkan secara otomatis.

Kode sumber dapat diakses.

3.  CONTROLLABILITY(Kemampuan untuk mengawasi)

“ Semakin baik kita dapat mengontrol perangkat lunak, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan. “

Semua output yang baik, dapat diperoleh melalui beberapa kombinasi input. Semua kode dapat dijalankan melalui berbagai kombinasi input. Keadaan dan variabel perangkat lunak dan perangkat keras dapat dikontrol secara

langsung oleh penguji. Format input dan output konsisten dan terstruktur. Pengujian dapat dispesifikasi, dioptimasi, dan direproduksi dengan baik.

4.  DECOMPOSABILITY(Kemampuan untuk menyelesaikan).

Dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih halus.

Sistem perangkat lunak dibangun dari modul-modul yang independen. Modul-modul dapat diuji secara independen.

5.  SIMPLICITY (Kemampuan untuk menyederhanakan kerumitan).

Semakin sedikit  yang diuji, semakin cepat kita dapat mengujinya. Fungsi yang sederhana (kumpulan fitur adalah kebutuhan minimum untuk memenuhi

persyaratan). Struktur yang sederhana (arsitektur dimodularisasi untuk membatasi penyebaran

kesalahan). Kode yang sederhana (standar pengkodean diadopsi demi kemudahan inspeksi dan

pemeliharaan)

6.  STABILITY(Mampu menyeimbangkan ).

Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian. Perubahan perangkat lunak jarang terjadi. Perubahan perangkat lunak dapat dikontrol. Perubahan perangkat lunak memvalidasi pengujian yang sudah ada. Kegagalan perangkat lunak dapat diperbaiki dengan baik.

7.  UNDERSTANDBILITY (kemampuan untuk memahami/mengerti).

Semakin banyak informasi yang kita dapat, semakin mudah pengujian dilakukan. Rancangan dapat dipahami dengan baik. Ketergantungan antara komponen internal, eksternal, dan yang dipakai bersama,

dipahami dengan baik. Perubahan rancangan dibicarakan. Dokumentasi teknik dapat diakses dengan cepat. Dokumen teknik diorganisasikan dengan baik. Dokumentasi teknik spesifik dan detail. Dokumentasi teknik akurat.

� MENGAPA PROGRAM MENGALAMI KERUSAKAN ?

�  Ketika orang mengerjakan tugas-tugas yang kompleks, mereka membuat kesalahan yang tidak dapat dihindari.

�  Mereka lebih memperbaiki kerusakan-kerusakan selama pengujian.

�  Mereka harus memperbaiki banyak kesalahan sebelum program akan berjalan semuanya.

� MEMPERBAIKI KERUSAKAN ADALAH SESUATU YANG MAHAL

Dengan waktu sehari, pengujian perangkat lunak secara umum masih mempunyai banyak �kerusakan

Komputer akan menjalankan program yang tidak sempurna�

�  ketika menghadapi kerusakan, program tidak akan mengerjakan apa yang seharusnya dikerjakan.

�  Bahkan mungkin menyebabkan kerugian.

Semakin lama kerusakan tersisa, semakin buruk memperbaikinya�

�  membutuhkan biaya lebih untuk perbaikan

�  kerusakan yang tersisa akan menjadi penyebab gangguan

� REVIEW (Peninjauan)

Melakukan peninjauan adalah langkah yang terpenting, karena dapat mengembangkan �kualitas perangkat lunak.

Lebih awal mengenali dan mengatasi masalah, semakin mudah dan murah untuk �memperbaikinya.

� APA YANG PERLU DITINJAU ?

REQUIREMENT & ANALYSIS�   (pemahaman dan analisa)

DESIGN (rancangan)�

CODE (kode)�

DOCUMNTATION (dokumentasi)�

TEST PLAN & CASES (rencana ujian dan kasus)�

TESTING TECHNIQUE / Teknik Pengujian

Pengujian merupakan elemen yang paling kritis dari penilaian perangkat lunak yang telah dikerjakan.

Pembahasan :

Dasar-dasar pengujian perangkat lunak Perancangan permasalahan pengujian yang berfokus pada kumpulan teknik yang

digunakan untuk membuat pengujian sesuai dengan permasalahan dan juga disesuaikan dengan  tujuan pengujian secara keseluruhan.

Pengujian merupakan salah satu dari siklus pengembangan perangkat lunak yang jika ditinjau dari sudut pandang psikologi adalah penghancuran dibandingkan penyusunan.

Aliran Informasi Pengujian

Aliran informasi yang terdapat pada saat pengujian dilaksanakan dapat digambarkan sebagai berikut  :

Terdapat 2 (dua) tingkatan yang tersedia pada proses pengujian, yaitu  :

Konfigurasi perangkat lunak yang mencakup spesifikasi keperluan perangkat lunak, spesifikasi perancangan, test case, dan program sumber.

Konfigurasi pengujian yang mencakup rencana dan prosedur uji coba, test case dan hasil yang diharapkan.

Desain Test Case

Dengan melihat lagi sasaran pengujian, kita harus mendesain pengujian yang memiliki kemungkinan tertinggi dalam menemukan kesalahan dengan jumlah waktu dan usaha yang minimum.

Terdapat 2 (dua) macam test case  :

Pengetahuan fungsi yang spesifik dari produk yang telah dirancang untuk diperlihatkan, test dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan sebagaimana yang diharapkan.

Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya.

Terdapat dua pendekatan dalam teknik pengujian perangkat lunak  :

Black Box Testing

Dilakukan untuk testing pada interface perangkat lunak. Test  case ini bertujuan untuk menunjukkan fungsi perangkat lunak tentang cara beroperasinya, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah  informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya.

White Box Testing

Meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur logika) yang melewati perangkat lunak diuji dengannmemberikan test case yang menguji serangkaian kondisi  dan loop secara spesifik.

Secara sekilas dapat disimpulkan bahwa metoda White Box Testing merupakan petunjuk untuk mendapatkan program yang benar, karena semuanya dilakukan dengan mendefinisikan seluruh jalur logika, mengembangkan test case untuk mengerjakan program, dan mengevaluasi hasilnya, sehingga test case akan mengerjakan logika program secara mendalam.

WHITE BOX TESTING

Pengujian white box adalah metode perancangan test case yang menggunakan struktur kontrol dari perancangan prosedural untuk mendapatkan test case.

Pengujian White Box disebut juga :

Glass Box Testing (Pengujian kotak bening) Code Base Testing  (Source kodenya dimunculkan) Structural Testing (Struktur program ditampilkan)

Dengan menggunakan metoda White Box Testing, perekayasa sistem akan dapat melakukan test case yang   :

1. Menjamin bahwa seluruh independent path di dalam modul telah dikerjakan paling tidak satu kali.

2. Mengerjakan seluruh keputusan logika pada sisi true dan false3. Melaksanakan seluruh loop sesuai dengan batasannya4. Mengerjakan seluruh struktur data internal yang menjamin validitas

BASIS-PATH TESTING

Pengujian basis path adalah teknik pengujian white box yang diusulkan oleh Tom MacCabe.

Tujuannya memperoleh ukuran kekomplekan logikal dari perancangan prosedural dan menggunakannya sebagai petunjuk untuk menetapkan basis set dari jalur eksekusi.

Objek dari pengujian path adalah untuk meyakinkan bahwa penerapan masalah ujian untuk masing-masing path yang                melalui program dilaksanakan setidaknya sekali.

Point permulaan dari pengujian path adalah Folwgraph program yang menunjukkan keputusan program dan aliran kontrol.

Metode pengujian basis path dapat diaplikasikan pada desain prosedural atau kode sumber.

Cyclomatic Complexity

Adalah metrik perangkat lunak yang menyediakan ukuran kuantitatif dari kekomplekan logika suatu program.

Nilai yang dihitung untuk cyclomatic complexity menentukan jumlah independent path dalam basis set suatu program.

Memberikan batas atas bagi jumlah pengujian yang harus dilakukan untuk memastikan bahwa seluruh statemen telah dilaksanakan sedikitnya sekali.

Independet path adalah jalur yang melintasi atau melalui program dimana sekurang-kurangnya terdapat proses perintah yang baru atau kondisi yang baru.

Dalam flowgraph, independent path harus bergerak sekurang-kurangnya pada satu edge yang belum dilewati sebelum jalur tersebut didefinisikan.

Cyclomatic Complexity digunakan untuk mencari jumlah path dalam satu flowgraph. Dapat dicari dengan 3 (tiga) metode, yaitu  :

Cyclomatic comlpexity V untuk flowgraph dihitung dengan rumus :

V(G)  =  E – N + 2

dimana  E = jumlah Edge, dan N = jumlah Node

Cyclomatic comlpexity V untuk flowgraph dapat dicari dengan          rumus :

V(G) =  P + 1

dimana P = jumlah predikat node

Jumlah region dalam flowgraph mempunyai hubungan dengan cyclomatic complexity.

V(G)  =  R

Nilai cyclomatic complexity memberi batas untuk jumlah jalur independen yang membentuk basis set dan implikasinya, batas atas jumlah pengujian yang harus didesain dan dieksekusi untuk menjamin semua statemen program.

Graph metrik

Adalah matrik empat persegi yang mempunyai ukuran (jumlah baris dan kolom) yang sama dengan jumlah node pada flowgraph.

Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah ditentukan.

Pemasukan data matrik berhubungan dengan hubungan (edge) antarnode. dikembangkan untuk membantu pengujian basis path atau struktur data.

LOOP TESTING

Loop merupakan kendala yang sering muncul untuk menerapkan algoritma dengan cepat. Pengujian loop merupakan teknik pengujian white box yang berfokus pada validitas dari loop. Terdapat 4 kelas dari loop,  :

Simple loop. Nested loop.

Concanated loop. Unstructured loop.

Simple Loop

Diaplikasikan pada bentuk loop yang sederhana, dimana n adalah jumlah maksimum yang diijinkan untuk melalui loop.

lewati loop secara keseluruhan. hanya satu yang melalui loop m dapat melalui loop dimana m = n atau m < n

Nested loop

teruskan sampai semua loop selesai diuji.

Concanated Loop

Dapat diuji dengan menggunakan pendekatan simple loop bila masing-masing dari loop independent terhadap yang lain.

Bila dua loop dirangkai dan pencacah loop untuk  loop 1 digunakan sebagai harga awal untuk loop 2, kemudian loop tersebut menjadi tidak independen, maka pendekatan yang diaplikasikan ke loop tersebut direkomendasikan.

Unstructured Loop

Apabila memungkinkan, kelas loop ini harus didesain lagi untuk mencerminkan penggunaan konsepsi pemrograman terstruktur.

Black Box Testing

�  Metode pengujian black box berfokus pada keperluan fungsional dari perangkat lunak dan domain informasi.

�  Analis sistem memperoleh kumpulan kondisi dari input yang akan mengerjakan seluruh keperluan fungsional program.

�  Cenderung diaplikasikan selama tahap akhir pengujian. �  Disebut juga pengujian behavioral/pengujian partisi/pengujian interface. �  Memperhatikan dari sudut pandang Input data dan Output data.

Perangkat lunak ditinjau sebagai kotak hitam yang menyalurkan input kepada output berdasarkan rincian dimana perangkat lunak tersebut harus melakukannya.

Periksa kecocokan dari pengujian S/W yang membentuk tingkah laku. Mencari kesalahan-kesalahan yang dihasilkan oleh kesalahan Kesalahan perangkat lunak adalah bagian dari perangkat lunak yang tidak menurut �

pada penyedian definisi itu sendiri dalam dokumen pengembangan.

Tujuannya untuk mencari kesalahan-kesalahan pada  :

Fungsi yang salah atau hilang. Kesalahan pada interface. Kesalahan pada struktur data atau akses database.

Kesalahan performansi (kinerja). Kesalahan initialisasi dan tujuan akhir.

Type dari pengujian black box   :

1. Equivalence Class Partitioning. (pembagian kelas yang sama)

Metode pengujian black box yang memecah atau membagi domain input dari suatu program ke dalam kelas-kelas data.

Perancangan test case berdasarkan evaluasi kelas equivalence untuk kondisi input. Kelas equivalence menggambarkan kumpulan keadaan yang valid dan tidak valid

untuk kondisi input. Kondisi input dapat berupa nilai numerik, range dari nilai, kumpulan nilai yang

berhubungan atau kondidi boolean.

Kelas equivalence dapat ditentukan sesuai pedoman berikut ini  :

Bila kondisi input menentukan suatu range, maka kelas equivalence valid dan dua yang invalid ditentukan.

Bila kondisi input membutuhkan suatu harga khusus, maka satu kelas equivalence valid dan dua yang invalid ditentukan.

Bila kondisi input menentukan anggota suatu himpunan, maka satu kelas equivalence valid dan dua yang invalid ditentukan.

Bila kondisi input adalah boolean, maka satu kelas dan satu yang tidak valid ditentukan.

Contoh  :

Dalam persamaan matematika.

1 juta <= Gaji <= 5 juta

Valid        :               1 juta samapi 5 juta

Invalid     :               kurang dari 1 juta lebih dari 5 juta

1. Boundary Value Analysis.(analisa penilaian terbatas)

Untuk permasalahan yang tidak diketahui dengan jelas, akan cenderung menimbulkan kesalahan pada domain output-nya.

Pemilihan test case yang mengerjakan nilai-nilai yang telah ditentukan. Melengkapi equivalence class partitioning.

Petunjuk pemakaian BVA  :

Jika kondisi input berupa range yang dibatasi oleh nilai a dan b, test case harus dirancang dengan nilai a dan b.

Jika kondisi input ditentukan dengan sejumlah nilai, test case harus dikembangkan dengan mengerjakan sampai batas maksimal dari nilai tersebut.

Sesuai dengan 1 dan 2, untuk kondisi output harus dirancang test case sampai jumlah maksimal.

Untuk struktur data pada program juga harus dirancang sampai batas kemampuan.

1. Comparison Testing. (pengujian perbandingan)

Perangkat keras dan perangkat lunak yang berlebihan memungkinkan untuk digunakan.

Menggunakan team yang terpisah untuk mengembangkan versi-versi yang independent dari perangkat lunak dengan menggunakan spesifikasi yang sama.

Mencoba masing-masing versi dengan data yang sama untuk  memastikan bahwa semua versi memberikan output yang identik.

Semua versi dieksekusi secara paralel dengan perbandingan real time hasil untuk memastikan konsistensi.

Output dari masing-masing versi sama implementasi benar. Output berbeda masing-masing versi dari aplikasi diperiksa untuk menentukan cacat

pada suatu versi (perbedaan jelas) Spesifikasi semua fungsi yang dikembangkan mengandung kesalahan, maka semua

versi kemungkinan besar merefleksikan kesalahan. Masing-masing versi independen identik tetapi tidak benar, maka pengujian kondisi

akan gagal mendeteksi kesalahan.

TESTING STAGES

Sasaran utama desain test case

untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak.

Teknik yang digunakan

Pengujian white-box (white–box testing) Pengujian black-box (black-box testing)

Pengujian white-box

Berfokus pada struktur kontrol program. Pengujian dilakukan untuk memastikan bahwa semua statemen pada program telah

dieksekusi paling tidak satu kali selama pengujian    dan semua kondisi telah diuji. Pengujian basis path, teknik pengujian white-box, menggunakan grafik program

(matrik grafik) untuk melakukan serangkaian pengujian yang independen secara linear yang memastikan cakupan.

Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program, dan pengujian loop menyempurnakan teknik white box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi.

Implikasinya secara khusus diaplikasikan ke dalam komponen program yang kecil (modul atau kelompok kecil dari modul).

Pengujian black-box

Didesain untuk mengungkap kesalahan pada persyaratan fungsional                 tanpa mengabaikan kerja internal dari suatu program.

Berfokus pada domain informasi dari perangkat lunak. Melakukan teste case dengan  mempartisi domain input dan output dari suatu program

dengan cara yang memberikan cakupan pengujian yang mendalam. Partisi ekivalensi (Equivalence Class Partitioning) membagi domain input kedalam

kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai terbatas (Boundary Value Analysis) memeriksa kemampuan program

untuk menangani data pada patas yang dapat diterima. Pengujian perbandingan (Comparison Testing) mengembangkan perangkat lunak ke

dalam versi-versi yang independen dari suatu aplikasi dengan menggunakan spesifikasi yang sama. Setiap versi diuji dengan data uji yang sama untuk memastikan bahwa                 semua versi memberikan output yagn identik. Disebut juga     pengujian back to   back.

Pengembang perangkat lunak yang berpengalaman sering mengatakan, “Pengujian tidak akan pernah berakhir. Pengujian hanya berpindah dari Penguji ke pelanggan. Setiap pelanggan menggunakan program tersebut, berarti suatu pengujian dilakukan.”

Dengan mengaplikasikan desain test case, perekayasa perangkat lunak  dapat menapai pengujian yang lebih lengkap sehingga dapat mengungkap dan melakukan koreksi sebelum “pengujian pelanggan” dimulai.

TESTING STAGES (tingkatan pengujian

Validasi perangkat lunak (V & V) ditujukan untuk menunjukkan bahwa sistem sesuai dengan spesifikasinya dan bahwa sistem memenuhi harapan pelanggan yang membelinya. Validasi melibatkan proses pemeriksaan, seperti inspeksi dan peninjauan, pada setiap proses perangkat lunak dari definisi persyaratan user sampai pengembangan program.

Validasi perangkat lunak adalah proses pemeriksaan untuk menjamin agar sistem telah sesuai dengan spesifikasinya dan memenuhi kebutuhan sesungguhnya dari user sistem.

Namun demikian, mayoritas biaya validasi disediakan setelah implementasi sistem operasional diuji.

Untuk program-program kecil, sistem seharusnya tidak diuji sebagai sistem tunggal. Sistem besar dibangun dari subsistem yang dibangun dari model yang terbuat dari prosedur dan fungsi.

Proses demikian dengan demikian harus dilakukan bertahap, dimana pengujian dilakukan secara inkremental bersama dengan implementasi sistem.

Proses pengujian terdiri dari 3 (tiga) tahap dimana komponen-komponen sistem diuji, sistem yang terintegrasi diuji, dan akhirnya sistem diuji dengan data pelanggan.

Idealnya, kesalahan komponen ditemukan dini pada proses dan masalah interface ketika sistem diintegrasi.

Namun demikian, dengan ditemukannya kesalahan, program harus didebug. Hal ini menuntut tahap proses pengujian ulang. Error pada komponen program, bisa muncul pada saat pengujian itegrasi. Proses dengan demikian bersifat iteratif, dengan informasi diumpan balik dari bagian

akhir ke bagian awal proses.

Tahap-tahap pada proses pengujian  :

1.             Unit Testing (pengujian unit).

Komponen individual diuji untuk menjamin operasi yang     benar. Setiap komponen diuji secara independen, tanpa komponen sistem   yang lain.

2.             Modul Testing (pengujian modul).

Modul merupakan sekumpulan komponen yang berhubungan seperti kelas objek, atau sekumpulan prosedur dan fungsi. Sebuah modul merangkum komponen-komponen yang berhubungan, sehingga dapat diuji tanpa modul sistem yang lain.

3.             Sub-system Testing (pengujian subsistem).

♠      Melibatkan pengujian sekumpulan modul yang telah diintegrasikan menjadi subsistem.

♠      Masalah yang sering muncul pada sistem perangkat lunak besar adalah ketidaksesuaian interface.

♠      Proses pengujian subsistem dengan demikian harus terkonsentrasi pada deteksi kesalahan interface modul dengan menjalankan interface ini berkali-kali.

4.             System Testing (pengujian sistem).

Subsistem diintegrasikan untuk membentuk sistem. Proses ini berkenaan dengan penemuan kesalahan yang diakibatkan dari interaksi yang tidak diharapkan antara subsistem dan masalah interface subsistem.

Sistem pengujian secara keseluruhan dimana pengujian timbul karena sifat-sifat yang baru.

Pengujian atas penggabungan sistem perangkat lunak.

5.             Acceptance Testing (pengujian penerimaan).

v  Merupakan tahap akhir proses pengujian sebelum sistem diterima untuk penggunaan operasional.

v  Sistem diuji dengan data yang dipasok oleh pelanggan dan bukan data uji simulasi.

v  Bisa menunjukkan kesalahan dan penghapusan definisi persyaratan  sistem karena data riil menjalankan sistem dengan cara yang berbeda dari data uji.

v  Dapat mengungkap masalah persyaratan dimana fasilitas sistem tidak memenuhi keperluan user atau kinerja sistem tidak dapat diterima.

Pengujian unit dan pengujian modul biasanya merupakan tanggung jawab programmer yang mengembangkan komponen tersebut. Programer membuat data uji sendiri dan secara inkremental menguji kode pada saat dikembangkan. Pengujian ini sangat ekonomis karena programmer adalah orang yang paling mengetahui komponen tersebut dan merupakan orang terbaik untuk membuat data uji.

Tahap berikutnya mencakup integrasi dari sejumlah programmer dan harus direncanakan sebelumnya. Suatu tim penguji independent harus bekerja dari rencana uji pra-formulasi yang dikembangkan dari spesifikasi dan rancangan sistem.

Pengujian penerimaan kadang-kadang disebut pengujian alpha. Sistem yang diperlihatkan dikembangkan untuk satu klien. Proses pengujian alpha berlanjut sampai pengembang sistem dan pelanggan setuju bahwa sistem yang diserahkan merupakan implementasi yang dapat diterima dari persyaratan sistem.

STRATEGI PENGUJIAN PERANGKAT LUNAK

Strategi untuk pengujian perangkat lunak mengintegrasikan metode desain test case perangkat lunak ke dalam sederetan langkah yang direncanakan dengan baik, hasilnya adalah konstruksi perangkat lunak yang berhasil.

Strategi pengujian perangkat lunak memberikan sebuah peta jalan bagi pengambang perangkat lunak, organisasi jaminan kualitas, dan pelanggan.

Peta jalan menggambarkan langkah-langkah yang akan dilakukan sebagai bagian dari pengujian, kapan langkah-langkah itu direncanakan dan kemudian dijalankan, serta berapa banyak usaha, waktu, dan sumber daya yang dibutuhkan.

Strategi pengujian menggabungkan perencanan pengujian, desain test case, dan kumpulan data resultan (hasil) serta evaluasi.

Kesimpulan  :

Strategi pengujian perangkat lunak memudahkan para perancang untuk menentukan keberhasilan dari sistem yang telah dikerjakan.

Hal yang harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yang diperlukan.

Pendekatan Strategis ke pengujian perangkat lunak

Pengujian adalah serangkaian aktivitas yang dapat direncanakan sebelumnya dan dilakukan secara sistematis. Karena ituah harus ditentukan suatu template untuk desain perangkat lunak – serangkaian langkah yang di dalamnya kita dapat menempatkan metode desain test case yang spesifik – untuk proses rekayasa perangkat lunak.

Banyak strategi pengujian yang dapat digunakan, tetapi secara umum mempunyai karakteristik sebagai berikut  :

Pengujian dimulai pada tingkat modul yang palin bawah, dilanjutkan dengan modul di atasnya kemudian hasilnya dipadukan.

Teknik pengujian yang berbeda mungkin akan menghasilkan 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 suatu elemen dari topik yang sangat luas dimana dapat disebut sebagai verifikasi dan validasi (V & V).

Verifikasi adalah kumpulan aktivitas yang menjamin bahwa perangkat lunak benar-benar sesuai dengan fungsinya.

Validasi adalah  serangkain aktivitas yang berbeda yang memastikan bahwa perangkat lunak yang dibangun dapat sesuai dengan kepeluan pelanggan.

Strategi pengujian perangkat lunak

v  Proses rekayasa perangkat lunak dapat juga dipandang sebagai sebuah bentuk spiral.

v  Pada awalnya, rekayasa sistem menentukan peran perangkat lunak dan membawa kepada analis persyaratan di mana domain informasi, fungsi, tingkah laku dan kinerja validasi bagi perangkat lunak di bangun.

v  Dengan bergerak dalam sepanjang spiral, kita akan sampai ke desain dan akhirnya ke pengkodean.

Unit testing dimulai pada pusaran spiral dan terpusat pada masing-masing satuan perangkat lunak pada saat diimplementasikan di dalam kode sumber.

Pengujian berjalan dengan bergerak keluar sepanjang spiral ke integration testing di mana fokusnya adalah desain dan konstruksi arsitektur perangkat lunak.

Dengan mengambil urutan keluar lainnya di dalam spiral, akan sampai ke validation testing di mana persyaratan yang dibangun sebagai bagian dari analisis persyaratan perangkat lunak di validasi terhadap perangkat lunak yang telah dikonstruksi.

Akhirnya sampai pada system tesing di mana perangkat lunak dan elemen sistem yang lain diuji secara keseluruhan.

Dengan mempertimbangkan proses dari titik pandang prosedural, pengujian di dalam konteks rekayasa perangkat lunak secara aktual merupakan 4 (empat) langkah yang diimplementasi secara berurutan.

1. Pada awalnya, pengujian berfokus pada setiap modul secara individual, dengan memastikan bahwa modul berfungsi secara tepat sebagai suatu unit, karena itu dinamakan unit testing. Menggunakan metoda pengujian white-box. Selanjutnya modul diintegrasikan untuk membentuk paket perangkat lunak yang lengkap.

2. Integration testing menekankan pada masalah-masalah yang berhubungan dengan masalah-masalah verifikasi dan konstruksi program. Mengunakan teknik pengujian black-box.

3. Validation testing memberikan jaminan akhir di mana perangkat lunak harus memenuhi semua persyaratan fungsional, tingkah laku dan kinerja. Teknik pengujian black-box digunakan secara eksklusif selama validasi. Perangkat lunak, sekali divalidasi, harus dikombinasikan dengan elemen sistem yang lain (hardware, manusia, database).

4. Pengujian sistem membuktikan bahwa semua elemen sistem saling bertautan dengan tepat dan keseluruhan fungsi/kinerja sistem dapat dicapai.

UNIT TESTING (pengujian unit)

Pengujian berfokus pada usaha verifikasi pada unit terkecil dari desain perangkat lunak, yakni modul. Dengan menggunakan deskripsi desain terinci sebagai panduan, jalur kontrol

yang penting diuji untuk mengungkap kesalahan di dalam batas dari modul tersebut. Kompleksitas dari pengujian dan kesalahan ditentukan berdasarkan scope modul. Pengujian unit selalu berorientasi ke white-box testing dan dapat dikerjakan dengan paralel atau berurutan dengan modul-modul yang lainnya.

Unit Testing

Unit individu diuji secara terpisah. Unit mungkin menjadi fungsi-fungsi sendiri, prosedur atau program. Dikerjakan secara meningkat, biasanya oleh programmer sendiri yang memberikan

kodenya. Kebanyakan white-box testing cocok untuk tingkatan ini. Susunan data ujian lokal, kondisi boundary, path independent dan path penanganan

kesalahan. Tak resmi, rencana ujian tidak resmi, jelas dan tertulis. Interface diuji untuk menjamin informasi yang mengalir masuk dan keluar dari unit

program telah tepat atau sesuai dengan yang diharapkan. Struktur data lokal dikerjakan untuk menjamin penyimpanan data selalu muthakir. Kondisi batasan-batasan adalah pengujian untuk menjamin modul-modul

dioperasikan sesuai dengan batasannya. Independent path untuk menjamin seluruh perintah dalam modul telah bekerja dengan

baik. Penanganan kesalahan kesalahan merupakan langkah terakhir dalam tahap ini.

Prosedur pengujian unit.

Pengujian unit pada umumnya merupakan perkembangan dari langkah pengkodean. Setelah program sumber dikembangkan, ditinjau kembali dan diverifikasi untuk

sintaknya, maka perancangan test case di mulai. 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 tiap-tiap pengujian unit.

MODUL TESTING (pengujian modul)

Pengujian interaksi dari semua komponen yang berhubungan terhadap modul. Pengujian modul yang indpendent. Modul secara individu diuji secara terpisah. Modul berupa kumpulan fungsi, prosedure atau program-program. Tidak secara increment, biasanya dilakukan oleh seorang programmer yang membuat

program tersebut. Menggunakan stub dan driver. Pengujian whit-box cocok untuk tingkatan ini. Pengujian struktur data lokal, kondisi batasan, jalur independen, jalur penanganan

kesalahan. Formal : rencana pengujian dijelaskan dan tertulis. Modul bukanlah program yang berdiri sendiri, perangkat lunak driver dan atau stub

harus dikembangkan bagi masing-masing pengujian unit.

Pada sebagian besar aplikasi, driver tidak lebih dari sebuah “program utama”, yang menerima data test case.

Data sampai ke modul untuk diuji, dan kemudian mencetak hasil yang relevan. Stub berfungsi untuk menggantikan modul yang merupakan subordinat dari modul

yang akan diuji. Stub menggunakan interface modul subordinat untuk melakukan manipulasi data

minimal, mencetak , entri dan kembali.

INTEGRATION TESTING (pengujian integrasi)

♪      Pengujian integrasi adalah teknik yang sistematis untuk mengkonstruksi susunan program sambil melakukan pengujian  untuk memeriksa kesalahan yang nantinya digabungkan dengan interface.

♪      Sasarannya adalah untuk mengambil modul yang dikenai pengujian unit dan membangun struktur program yang telah ditentukan oleh desain.

♪      Kesulitannya adalah lokalisasi error yang sulit ditemukan pada saat proses.

♪      Terdapat interaksi yang rumit antara komponen sistem dan ketika ditemukan output yang menyimpang, mungkin sulit untuk menemukan sumber error tersebut.

Integrasi non-inkremental

Program diuji sebagai satu kesatuan. Serangkaian kesalahan akan terjadi. Koreksi sulit dilakukan karena isolasi penyebab diperumit oleh luasnya program keseluruhan. Sekali kesalahan tersebut dibetulkan, maka akan muncul lagi yang baru dan proses itu terus berlanjut dalam loop yang kelihatannya tidak akan pernah berhenti.

Integrasi inkremental

Program dibangun dan diuji di dalam segmen-segmen kecil, sehingga kesalahan lebih mudah diisolasi dan dibetulkan, interface lebih mungkin untuk diuji secara lengkap, dan pendekatan pengujian yang sistematis dapat diaplikasikan.

Top-down Integrasi

adalah pendekatan inkremental terhadap struktur program. Modul diintegrasikan dengan menggerakkan ke bawah melalui hirarki kontrol,

dimulai dengan modul kontrol utama (program utama). Memverifikasi kontrol utama dan keputusan pada saat awal proses pengujian. Pada struktur program yang dibuat dengan baik, keputusan akan dikerjakan pada

tingkat atas hirarki. Stub mengganti modul tingkat rendah pada awal pengujian top-down, sehingga tidak

ada data yang penting yang dapat mengalir ke atas di dalam struktur program.

Proses integrasi dilakukan dalam 5 (lima) langkah  :

1. Modul kontrol utama digunakan sebagai test driver, dan stub ditambahkan pada semua modul yang secara langsung subordinat terhadap modul kontrol utama.

2. Stub subordinat diganti pada suatu saat dengan modul aktual.3. Pengujian dilakukan pada saat masing-masing modul diintegrasi.4. Pada pelengkapan masing-masing rangkaian pengujian, stub yang lain diganti dengan

modul real.5. Pengujian regresi dapat dilakukan untuk memastikan bahwa kesalahan baru belum

dimunculkan.

Bottom-up Integrasi

Dapat dinyatakan dengan penyusunan yang dimulai dan diuji dengan atomic modul (modul tingkat paling bawah pada struktur program).

Modul diintegrasikan dari bawah ke atas sehingga pemrosesan yang diperlukan untuk modul subordinat yang selalu diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi.

Strategi bottom-up integration dapat diterapkan dengan urutan langkah-langkah sebagai berikut  :

1. Modul tingkat bawah digabungkan ke dalam cluster (sering disebut build) yang malakukan subfungsi perangkat lunak spesifik.

2. Driver (program kontrol untuk pengujian) ditulis untuk mengkoordinasi input dan output test case.

3. Cluster diuji.4. Driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam

struktur program.

Regression Testing ( pengujian regresi )

adalah aktivitas yang membantu memastikan bahwa perubahan (karena pengujian atau alasan lain) tidak menimbulkan tingkah laku yang tidak diharapkan atau kesalahan tambahan.

Merupakan eksekusi ulang dari beberapa subset yang telah dilakukan untuk memastikan bahwa perubahan tidak menimbulkan efek samping yang tidak diharapkan.

Pengujian yang berhasil akan menghasilkan kesalahan, dan setiap kesalahan harus dikoreksi.

Setiap kali perangkat lunak dikoreksi, maka banyak aspek konfigurasi perangkat lunak (program, dokumentasi atau data yang mendukung) akan diubah.

Pengujian regresi (subset dari pengujian yang akan dieksekusi) berisi tiga kelas test case yang berbeda, yaitu  :

Sampel respresentatif dari pengujian yang akan                menggunakan semua fungsi perangkat lunak.

Pengujian tambahan yang berfokus pada fungsi-fungsi perangkat lunak yang mungkin dipengaruhi oleh perubahan tersebut.

Pengujian yang berfokus pada komponen perangkat lunak yang telah diubah. Pemilihan strategi integrasi, tergantung pada karakteristik perangkat lunak dan

kadang-kadang juga pada jadwal proyek.

Secara umum, pendekatan yang digabungkan (sandwitch testing), yang menggunakan strategi top-down untuk tingkat yang lebih tinggi dari struktur program, dipasangkan dengan strategi bottom-up untuk tingkat subordinat.

Pada saat pengujian integrasi dilakukan, penguji  harus mengidentifikasi modul kritis. Modul kritis memiliki karakteristik sebagai berikut :

1. menekankan beberapa persyaratan perangkat lunak.2. memiliki tingkat kontrol yang tinggi.3. Kompleks (cyclomatic complexity dapat digunakan sebagai indikator).4. memiliki persyaratan kinerja yang terbatas.

Scope of Testing merangkum fungsi yang spesifik, kinerja dan karakteristik desain internal yang akan diuji. Pengujian dibatasi ; kriteria perlengkapan dari masing-masing fase pengujian digambarkan; dan batasan jadwal didokumentasikan.

Test Plan menggambarkan seluruh strategi integrasi. Pengujian dibagi ke dalam phases dan builds yang menekankan fungsional spesifik dan karakteristik tingkah laku dari perangkat lunak tersebut. Misalnya pengujian integrasi untuk sebuah sistem komputer yang berorientasi pada grafik dapat dibagi ke dalam fase-fase pengujian sebagai berikut  :

Interaksi pemakai (seleksi perintah, representasi tampilan, pemrosesan dan respresentasi kesalahan).

Manipulasi dan analisis data (pembuatan simbol, penentuan dimensi, rotasi, komputasi sifat fisis)

Pemrosesan dan pemunculan tampilan (tampilan dua dimensi, tampilan tiga dimensi, grafik dan bagan)

Manajemen database (akses, update, integritas, kinerja)

Kriteria dan pengujian yang sesuai diaplikasikan untuk semua fase pengujian  :

Integritas interface. Antar muka internal dan eksternal diuji pada saat masing-masing modul (kluster) ditambahkan ke dalam struktur.

Validitas fungsional. Pengujian yang didesain untuk mengungkap kesalahan fungsional yang dilakukan.

Isi informasi. Pengujian yang didesain untuk mengungkap kesalahan yang berhubungan dengan struktur data global atau lokal yang dilakukuan.

Kinerja. Pengujian yang didesain untuk memeriksa batasan kinerja yang dibangun selama desain perangkat lunak dilakukan.

VALIDATION TESTING (pengujian validasi)

Dilakukan setelah integration testing dilakukan serta kesalahan-kesalahan yang ditemukan telah diperbaiki.

Validasi berhasil jika fungsi-fungsi yang ada pada perangkat lunak telah sesuai dengan yang diharapkan oleh pemakai.

Merupakan kumpulan pengujian black-box yang memperlihatkan atau menunjukkan sesuai dengan yang diperlukan.

Garis besar rencana pengujian dikerjakan dan prosedur pengujian didefinisikan dengan test case yang spesifik untuk menunjukkan sesuai dengan yang diperlukan.

Rencana dan prosedur dirancang untuk menjamin seluruh keperluan fungsional telah terpenuhi, seluruh performansi dapat dicapai, dokumentasi dilakukan dengan benar.

Setelah pengujian dikerjakan, ada satu kemungkinan dari dua kondisi yang ada, yaitu  :

1. Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima.2. Penyimpangan dari spesifikasi ditemukan dan daftar penyimpangan dibuat.

Kajian Konfigurasi

Merupakan elemen penting dari proses validasi. Tujuannya untuk memastikan apakah semua elemen konfigurasi perangkat lunak telah

dikembangkan dengan tepat, dikatalog, dan memiliki detail yang perlu untuk mendukung fase pemeliharaan dari siklus hidup perangkat lunak.

Sering disebut audit.

ALPHA & BETA TESTING

Sangat tidak mungkin bagi pengembang perangkat lunak untuk meramalkan bagaimana pelanggan akan benar-benar menggunakan sebuah program.

Instruksi yang digunakan dapat disalah-interprestasikan, kombinasi data yang aneh dapat dipakai secara reguler, dan output yang kelihatannya sudah jelas bagi penguji tidak dapat dimengerti oleh pemakai di lapangan.

Bila perangkat lunak biasa dibangun bagi satu pelanggan, maka dapat acceptance test dapat dilakukan untuk memungkinkan pelanggan memvalidasi semua persyaratan.

Acceptance test dilakukan karena memungkinkan pelanggan untuk menemukan kesalahan yang lebih terinci dan membiasakan pelanggan memahami perangkat lunak yang telah dibuat.

Jika perangkat lunak dikembangkan atau dibuat untuk dipakai oleh banyak pelanggan, maka tidak praktis untuk melakukan pengujian satu per satu terhadap perangkat lunak tersebut.

Maka digunakan alpha dan beta testing. Alpha testing adalah tahap pengembangan, dimana perangkat lunak atau perangkat

keras yang telah dibuat dikirim ke kelompok pemakai atau pembeli yang potensial kemudian mereka akan menggunakan produk ini untuk melaporkan jika produk itu gagal ?

Pengujian aplha dilakukan pada sebuah lingkungan yang terkontrol. Pengujian beta dilakukan oleh pelanggan yang merupakan pemakai akhir perangkat

lunak. Pengujian beta merupakan sebuah aplikasi “live” dari perangkat lunak dalam suatu

lingkungan yang tidak dapat dikontrol oleh pengembang. Pelanggan merekam semua masalah yang ditemui selama pengujian beta dan

melaporkannya kepada pengembang. Pengembang melakukan modifikasi kemudian mempersiapkan pelepasan produk ke

seluruh pelanggan.

SYSTEM   TESTING

Perangkat lunak merupakan salah satu elemen dari sistem yang berbasis komputer yang sangat besar.

Perangkat lunak diintegrasi dengan elemen sistem lainnya (hardware, informasi) dan serangkaian integrasi sistem dan validasi test dilakukan.

Jika pengujian gagal atau diluar scope dari pengembangan sistem dan tidak hanya dikerjakan oleh programmer, maka langkah yang diambil selama perancangan dan pengujian dapat diperbaiki

Peran analis sistem antara lain  : o Menangani kesalahan yang muncul dari elemen-elemen perangkat lunako Mengerjakan serangkaian pengujiano Mencatat hasil pengujian.o Berpartisipasi dalam perencanaan dan merangcang pengujian sistem untuk

menjamin kualitas perangkat lunak.o System testing adalah sederetan pengujian yang berbeda-beda dengan tujuan

utama mengerjakan keseluruhan elemen dalam sistem yang telah dikembangkan.

Stress Testing ( pengujian stres )

Didesain untuk menghadapi situasi yang tidak normal pada saat program mengalami pengujian.

Dilakukan oleh sistem untuk kondisi-kondisi seperti volume data yang normal (melebihi atau kurang dari batasan), frekuensi dll.

Intinya penguji berusaha untuk merusak program.

Recovery Testing ( pengujian perbaikan )

Adalah pengujian sistem yang memaksa perangkat lunak untuk mengalami kegagalan dalam berbagai cara dan melakukan verifikasi sesuai dengan performansi yang tepat.

Banyak sistem yang berbasis komputer harus melindungi dari kesalahan dan melanjutkan prosesnya dalam waktu yang telah ditentukan.

Sistem harus toleran terhadap kesalahan. Kesalahan pemrosesan tidak boleh menyebabkan keseluruhan fungsi sistem berhenti.

Security Testing ( pengujian keamanan )

Adalah pengujian yang akan melakukan verifikasi dari mekanisme perlindungan yang akan dibuat oleh sistem, melindungi dari hal-hal yang mungkin terjadi.

Penguji memerankan individu yang akan menembus sistem. Pengujian untuk mencoba menembus tingkat keamanan sebuah perangkat lunak.

Strategi Sandwich Compromise, menguji perangkat lunak dengan melakukan pengujian mulai dari entry-point tertentu kemudian bergerak keatas ataupun kebawah.

Volume Testing, menguji perangkat lunak dengan memberi data yang berlebihan. Configuration Testing, menguji berbagai variasi perangkat lunak diberbagai

lingkungan perangkat lunak. Compatibility Testing, menguji kesesuaian sebuah perangkat lunak dengan sistem

yang sedang dimanfaatkan. Timing sistem, melakukan pengujian terhadap perangkat lunak untuk evaluasi

terhadap waktu tanggap dan waktu proses Yng dibutuhkan untuk menyelesaikan sebuah tugas.

Enviromental Testing, menguji toleransi perangkat lunak terhadap suhu, kelembaban, gerak dan perpindahan.

Human Factor Testing, menguji antarmuka perangkat lunak bersama-sama dengan pemakai.

Interface Testing ( pengujian interface )

Dilakukan ketika modul atau subsistem diintegrasi untuk membuat sistem yang lebih besar.

Setiap modul atau subsistem memiliki interface yang terdifinisi yang dipanggil oleh komponen program lain.

Tujuannya adalah untuk mendeteksi kesalahan yang mungkin telah masuk ke dalam sistem karena eror interface atau asumsi invalid mengenai interface.

Penting untuk pengembangan berorientasi objek

OBJECT ORIENTED TESTING (pengujian berorientasi objek)

Pengujian operasi individual yang berhubungan dengan objek. Merupakan fungsi atau prosedur dan dapat digunakan pendekatan black-box dan white-box.

Pengujian kelas objek individu. Prinsip pengujian black-box tidak berubah tetapi pengertian kelas ekuivalensi harus diperluas untuk mencakup rangkaian operasi yang berhubungan. Dengan cara yang sama, pengujian struktural membutuhkan jenis analisis yang berbeda.

Pengujian kelompok objek. Integrasi top-down dan bottom-up yang ketat tidak sesuai untuk membuat kumpulan objek yang berhubungan. Pengujian berdasar skenario yang digunakan.

Pengujian sistem berorientasi objek. Verifikasi dan validasi terhadap spesifikasi persyaratan sistem dilakukan dengan cara yang tepat sama sebagaimana untuk jenis sistem yang lain.

Object Integration (integrasi objek)

Pengujian use-case atau basis skenario. Mendeskripsikan satu model penggunaan sistem. Pengujian dapat didasarkan atas deskripsi skenario ini dan kelompok objek yang dibuat untuk mendukung use-case yang berhubungan dengan model penggunaan tersebut.

Pengujian thread. Berdasar pengujian respon sistem terhadap suatu input atau set event input tertentu. Sistem berorientasi objek seringkali dikendalikan event sehingga merupakan bentuk pengujian yang sesuai. Untuk memakai pendekatan ini, kita harus mengidentifikasi cara pemrosesan event menelusuri jalannya melalui sistem.

Pengujian interaksi objek. o Diusulkan oleh Jorgensen dan Erikson.o Tingkat menengah dari pengujian integrasi dapat didasarkan atas identifikasi

jalur.o Jalur melalui serangkaian interaksi objek yang berhenti ketika operasi objek

tidak memanggil           layanan objek lain.

Tiga hal yang harus dilakukan untuk menguji sistem OO  :

1. Definisi pengujian harus diperluas untuk mencakup teknik penemuan kesalahan yang diaplikasikan ke model OOA dan OOD.

2. Strategi untuk pengujian unit dan terintegrasi harus berubah secara signifikan.3. Desain test case harus bertanggung jawab terhadap karakteristik unik perangkat lunak

OO.

Model Pengujian OOA dan OOD

Model desain dan analisis tidak dapat diuji dalam arti yang konvensional, karena model tersebut tidak dapat dieksekusi.

Kajian teknis formal dapat digunakan untuk menguji kebenaran dan konsistensi model analisis maupun model desain.

Kebenaran Model OOA dan OOD

Notasi dan sintaks digunakan untuk merespresentasikan model analisis dan desain. Kebenaran sintaks dinilai pada penggunaan simbol yang teratur. Masinag-masig model dikaji untuk memastikan apakah konvensi pemodelan yang

tepat telah terjaga.

Konsistensi Model OOA dan OOD

mempertimbangkan hubungan antar entitas di dalam model tersebut. masing-masing kelas dan koneksinya ke kelas lain harus diuji. desain sistem dikaji dengan menguji model tingkah laku objek yang dikembangkan

selama OOA.

Metode Pengujian Berorientasi Objek

Pengujian sistem berorientasi objek umumnya dilakukan secara bottom-up dalam empat level  :

1. Pengujian level metode yang menguji metode individu di kelas.2. Metode-metode dan atribut-atribut yang menyusun kelas. Pengujian level kelas (intra

kelas) adalah pengujian terhadap interaksi-interaksi di antara komponen-komponen di satu kelas individu.

3. Kelas-kelas yang bekerja sama menyusun tandan kelas (class cluster). Pengujian tandan kelas menguji interaksi-interaksi di antara kelas-kelas.

4. Tandan-tandan kelas menyusun sistem. Pengujian level sistem berurusan dengan masukan dan               keluaran yang tampak bagi pemakai sistem.

Stratregi pengujian berorientasi objek

Strategi klasik pengujian perangkat lunak  :

Dimulai dari pengujian unit, bergerak menuju pengujian integrasi dan berakhir pada validasi dan               pengujian sistem.

Pengujian unit berfokus pada satuan program kecil yang dapat di-compile. Unit diintegrasikan dengan suatu struktur program.

Pengujian regresi dijalankan untuk mengungkap kesalahan sehubungan dengan interfacing modul dan efek samping yang disebabkan oleh penambahan unit-unit baru.

Sistem secara keseluruhan diuji untuk memastikan apakah kesalahan terungkap.

Perubahan strategi pengujian pada pendekatan berorientasi objek

Pengujian unit, monsep mengenai unit diperluas di sistem berorientasi objek. Pengujian integrasi, integrasi berfokus pada kelas-kelas dan eksekusinya pada satu

thread atau use case.

Pengujian validasi, menggunakan pengujian kotak hitam tradisional