teknik pengujian perangkat lunak
DESCRIPTION
Teknik Pengujian Perangkat Lunak sistem KOMPUTERTRANSCRIPT
TEKNIK PENGUJIAN PERANGKAT LUNAK
BAB II
PEMBAHASAN
1.1 Pengujian Perangkat Lunak
Pengujian perangkat lunak (bahasa Inggris: software testing) merupakan
suatu investigasi yang dilakukan untuk mendapatkan informasi mengenai kualitas
dari produk atau layanan yang sedang diuji (under test). Pengujian perangkat
lunak juga memberikan pandangan mengenai perangkat lunak secara obyektif dan
independen, yang bermanfaat dalam operasional bisnis untuk memahami tingkat
risiko pada implementasinya. Teknik-teknik pengujian mencakup, namun tidak
terbatas pada, proses mengeksekusi suatu bagian program atau keseluruhan
aplikasi dengan tujuan untuk menemukan bug perangkat lunak (kesalahan atau
cacat lainnya).
Pengujian perangkat lunak dapat dinyatakan sebagai proses validasi dan
verifikasi bahwa sebuah program / aplikasi / produk:
1. Memenuhi kebutuhan (requirement) yang mendasari perancangan dan
pengembangan perangkat lunak tersebut;
2. Berjalan sesuai dengan yang diharapkan;
3. Dapat diterapkan menggunakan karakteristik yang sama;
4. Memenuhi kebutuhan semua pihak yang berkepentingan.
Pengujian perangkat lunak tidak diragukan lagi merupakan konsumen
terbesar dari sumber daya jaminan kualitas perangkat lunak. Dalam sebuah survei
yang dilakukan pada bulan November 1994, Perry (1995) menemukan bahwa
rata-rata, 24% dari anggaran pembangunan proyek dialokasikan untuk pengujian.
Selain itu, 32% dari anggaran manajemen proyek direncanakan untuk kegiatan
pengujian. Sehubungan dengan sumber daya waktu, rata-rata 27% dari waktu
proyek adalah jadwal untuk pengujian. Peserta Survei juga mengindikasikan
bahwa mereka berencana untuk mengalokasikan waktu secara substansial lebih
(45% rata-rata) untuk percobaan tapi bahwa tekanan biasanya timbul menjelang
akhir dari proyek dan umumnya manajer proyek dipaksa untuk mengurangi
lamanya penjadwalan waktu pengujian.
Definisi
Definisi klasik menurut Myers (1979),
Pengujian adalah proses menjalankan program dengan maksud menemukan
kesalahan.
Definisi tersebut menyangkut kegiatan mulai dari cek kode yang dilakukan
oleh seorang pemimpin tim untuk menjalankan percobaan dari perangkat lunak
yang dilakukan oleh seorang rekan, serta tes yang dilakukan oleh suatu unit
pengujian, semua bisa dianggap kegiatan pengujian.
Definisi lain menurut IEEE
1. Proses mengoperasikan sistem atau komponen dalam kondisi tertentu,
mengamati atau merekam hasil, dan membuat evaluasi terhadap beberapa
aspek dari sistem atau komponen.
2. Proses analisis item perangkat lunak untuk mendeteksi perbedaan antara
yang ada dan kondisi yang diperlukan (yaitu bug) dan mengevaluasi fitur-
fitur dari item perangkat lunak
Definisi menurut Galin :
Pengujian perangkat lunak adalah proses formal yang dilakukan oleh tim khusus
pengujian di mana suatu unit perangkat lunak, beberapa unit perangkat lunak
yang terintegrasi atau paket perangkat lunak yang diperiksa secara keseluruhan
dengan menjalankan program pada komputer.
Semua pengujian yang berkaitan dilakukan menurut prosedur uji yang disetujui
pada kasus uji yang disetujui.
Karakteristik utama dari pengujian perangkat lunak :
Formal-Rencana uji perangkat lunak merupakan bagian dari
pengembangan proyek dan rencana mutu, dijadwalkan di muka dan item
sentral muncul dalam perjanjian pembuatan perangkat lunak yang
ditandatangani antara pelanggan dan pengembang. Dengan kata lain, pengujian
perangkat lunak secara ad hoc oleh rekan atau pemeriksaan berkala oleh
pemimpin tim pemrograman tidak dapat dianggap sebagai tes perangkat lunak.
Tim penguji khusus – Sebuah tim independen atau eksternal konsultan
yang mengkhususkan diri dalam pengujian ditugaskan untuk melaksanakan
tugas ini terutama dalam rangka untuk menghilangkan bias dan untuk menjamin
pengujian yang efektif oleh para profesional terlatih. Selain itu, secara umum
diterima bahwa tes yang dilakukan oleh pengembang sendiri akan menghasilkan
hasil yang buruk, sebagai individu yang mengembangkan produk asli akan
menemukan kesulitan untuk mengungkapkan kesalahan yang mereka tidak
diidentifikasikan lebih awal. Namun, unit test terus dilakukan oleh pengembang
di banyak organisasi.
Menjalankan program – Segala bentuk kegiatan jaminan kualitas yang
tidak melibatkan menjalankan perangkat lunak, untuk pemeriksaan contoh kode,
tidak dapat dianggap sebagai kegiatan ujian
Prosedur pengujian disetujui – Proses pengujian yang dilakukan
berdasarkan suatu rencana uji dan prosedur pengujian yang telah disetujui
sebagai sesuai dengan prosedur SQA diadopsi oleh organisasi yang berkembang
Uji kasus disetujui – kasus uji yang akan diperiksa didefinisikan secara
penuh oleh rencana uji. Tidak ada kelalaian atau penambahan diharapkan terjadi
selama pengujian. Dengan kata lain, sekali proses telah dimulai, Penguji tidak
diperkenankan untuk menerapkan kebijaksanaan dengan menghilangkan batu
ujian jika dianggap berlebihan atau dengan menambahkan ujian baru, meskipun
mungkin menjanjikan.
Tujuan Pengujian Perangkat Lunak
Tujuan Langsung :
Untuk mengidentifikasi dan mengungkapkan sebagai kesalahan sebanyak
mungkin dalam perangkat lunak yang diuji.
Untuk membawa perangkat lunak diuji, setelah memperbaiki kesalahan
yang diidentifikasi dan melakukan pengujian ulang, pada tingkat kualitas yang
memadai.
Untuk melakukan tes yang diperlukan secara efisien dan efektif, dalam
keterbatasan anggaran dan penjadwalan.
Tujuan Tidak Langsung :
Untuk menyusun catatan kesalahan perangkat lunak untuk digunakan
dalam pencegahan kesalahan (dengan tindakan perbaikan dan pencegahan).
Dalam banyak hal, disiplin tes bertindak sebagai penyedia layanan kepada disiplin
lain. Pengujian berfokus terutama pada evaluasi atau menilai kualitas produk,
menggunakan sejumlah praktek inti:
1. Menemukan dan dokumen kegagalan dalam produk perangkat lunak:
cacat, masalah
2. Menyarankan manajemen pada kualitas yang dirasakan pada perangkat
lunak
3. Mengevaluasi asumsi yang dibuat dalam spesifikasi rancangan dan
persyaratan melalui demonstrasi nyata
4. Memvalidasi bahwa produk perangkat lunak yang dibuat bekerja sesuai
rancangan
5. Memvalidasi bahwa persyaratan diterapkan secara tepat
Sebuah perbedaan menarik yang ada antara pengujian dan disiplin ilmu RUP lain :
Pada dasarnya disiplin Test bertugas menemukan dan mengekspos kelemahan
dalam produk perangkat lunak. Untuk mendapatkan manfaat terbesar, kita
memerlukan filosofi atau pola pikir yang berbeda dari yang digunakan dalam
disiplin Persyaratan, Analisis dan Desain, dan Implementasi. Sementara tiga
disiplin tersebut fokus pada kelengkapan, konsistensi, dan kebenaran, disiplin Test
berfokus pada apa yang hilang, salah, atau tidak konsisten.
Upaya pengujian yang baik didorong oleh pertanyaan seperti ini:
Bagaimana suatu perangkat lunak dapat gagal?
Dalam situasi apa yang mungkin ada sehingga perangkat lunak ini gagal
bekerja sesuai perkiraan?
Disiplin Test menantang asumsi, risiko, dan ketidakpastian yang melekat dalam
karya disiplin lain, dan mengalamatkan kekhawatiran mereka menggunakan
demonstrasi nyata dan evaluasi yang tidak memihak. Kita ingin menghindari dua
hal ekstrem potensial:
Pendekatan yang tidak sesuai atau secara efektif menantang perangkat
lunak dalam mengekspos kelemahan dan masalah yang melekat.
Pendekatan yang tidak tepat negatif atau merusak akan mengadopsi suatu
pendekatan negatif, kita merasa tidak mungkin untuk pernah
mempertimbangkan produk perangkat lunak dari kualitas yang dapat diterima.
Mengambil pendekatan seperti itu dapat menjauhkan upaya Test dari disiplin
lain.
Informasi yang disajikan dalam berbagai survei dan esai menyatakan bahwa
pengujian perangkat lunak menghabiskan 30% sampai 50% dari biaya
pengembangan perangkat lunak. Oleh karena itu, agak mengejutkan untuk dicatat
bahwa sebagian besar orang percaya bahwa perangkat lunak komputer belum diuji
dengan baik sebelum itu disampaikan. Kontradiksi ini berakar dalam beberapa isu
kunci:
1. Pengujian perangkat lunak sangat sulit. Bagaimana cara kita mengukur
berbagai kondisi dimana program yang diberikan dapat berhasil atau gagal?
2. Biasanya, pengujian dilakukan tanpa metodologi yang jelas, menciptakan
hasil yang bervariasi dari proyek untuk proyek dan dari organisasi ke
organisasi. Sukses bergantung terutama pada faktor kualitas dan keterampilan
individu dalam tim penguji.
3. Alat Produktivitas digunakan secara tidak efisien atau tidak sama sekali,
yang membuat aspek pengujian melelahkan dan tidak teratur. Selain
kurangnya pelaksanaan tes otomatis, banyak upaya pengujian dilakukan tanpa
alat yang memungkinkankita secara efektif mengelola luasnya Data Uji dan
Hasil Uji.
4. Fleksibilitas dari penggunaan dan kompleksitas perangkat lunak membuat
pengujian lengkap menjadi tujuan yang mustahil. Penggunaan strategi yang
disusun dan alat-alat yang tepat dapat meningkatkan produktivitas dan
efektivitas pengujian perangkat lunak.
Sumber: bagusalfiyanto.blogspot.com/2010/06/pengujian-perangkat-lunak.html
1.2 Desain Test Case
Sebuah test case, dalam rekayasa perangkat lunak, adalah seperangkat kondisi
atau variabel di mana tester akan menentukan apakah sebuah aplikasi , sistem
perangkat lunak atau salah satu dari fitur-fiturnya bekerja sebagaimana pada
awalnya didirikan untuk itu dapat dilakukan. Mekanisme untuk menentukan
apakah sebuah program perangkat lunak atau sistem telah lulus atau gagal
dalam ujian tersebut dikenal sebagai oracle tes . Dalam beberapa pengaturan,
sebuah oracle bisa menjadi persyaratan atau use case , sementara di lain itu
bisa menjadi heuristik . Mungkin butuh banyak kasus uji untuk menentukan
bahwa sebuah program perangkat lunak atau sistem dianggap cukup diteliti
untuk dirilis. Uji kasus yang sering disebut sebagai script tes , terutama ketika
ditulis - ketika mereka biasanya dikumpulkan dalam tes suite.
Sebuah test case biasanya satu langkah, atau kadang-kadang urutan langkah-
langkah, untuk menguji benar perilaku / fungsi, fitur aplikasi. Sebuah hasil
yang diharapkan atau hasil yang diharapkan biasanya diberikan. Informasi
tambahan yang mungkin termasuk:
1. kasus uji ID
2. deskripsi kasus uji
3. Uji langkah atau urutan nomor eksekusi
4. persyaratan terkait (s)
5. kedalaman
6. kategori uji
7. penulis
8. memeriksa kotak untuk apakah tes dapat atau telah otomatis
9. lulus / gagal
10. komentar
Uji kasus yang lebih besar juga mungkin mengandung negara prasyarat atau
langkah-langkah, dan deskripsi.
Sebuah kasus tes tertulis juga harus berisi tempat bagi hasil yang sebenarnya.
Langkah-langkah ini dapat disimpan dalam sebuah dokumen pengolah kata,
spreadsheet, database atau repositori umum lainnya.
Dalam sistem database, Anda juga dapat melihat hasil tes terakhir dan yang
dihasilkan hasil dan konfigurasi sistem yang digunakan untuk menghasilkan
hasil tersebut. Hasil ini masa lalu biasanya akan disimpan dalam tabel
terpisah. Suite uji sering juga mengandung
1. Ringkasan Uji
2. Konfigurasi
Selain deskripsi dari fungsi yang akan diuji, dan persiapan yang diperlukan
untuk memastikan bahwa tes dapat dilakukan, yang paling memakan waktu
bagian dalam kasus uji menciptakan tes dan memodifikasi mereka ketika
perubahan sistem.
Dalam keadaan khusus, mungkin ada kebutuhan untuk menjalankan tes, hasil,
dan kemudian tim ahli akan mengevaluasi apakah hasilnya dapat dianggap
sebagai pass. Hal ini sering terjadi pada produk-produk baru 'kinerja
penentuan nomor. Tes pertama diambil sebagai garis dasar untuk siklus rilis
test / produk berikutnya.
Tes penerimaan , yang menggunakan variasi dari kasus tes tertulis, biasanya
dilakukan oleh sekelompok pengguna akhir- atau klien dari sistem untuk
memastikan sistem yang dikembangkan memenuhi persyaratan yang
ditentukan atau kontrak. Tes penerimaan pengguna dibedakan dengan
dimasukkannya senang jalan atau uji kasus positif dengan mengesampingkan
hampir selesai kasus uji negatif
1.3 Pengujian Basis Path
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.
1. Cyclomatic Complexity
Cyclomatic Complexity adalah metrik perangkat lunak yang menyediakan
ukuran kuantitatif dari kekomplekan logika suatu program. Nilai yang
dihitung untuk cyclomatic complexity menentukan jumlahindependent
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.
2. 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.
3. Looping 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, :
1.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
2.Nested loop.
Teruskan sampai semua loop selesai diuji.
3.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.
4.Unstructured loop.
Apabila memungkinkan, kelas loop ini harus didesain lagi untuk
mencerminkan penggunaan konsepsi pemrograman terstruktur.
4. 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
2. 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.
3. 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.
4. Testing Stages
1) Sasaran utama desain test case
untuk mendapatkan serangkaian pengujian yang memiliki
kemungkinan tertinggi di dalam pengungkapan kesalahan pada
perangkat lunak.
2) Teknik yang digunakan
a. Pengujian white-box (white–box testing)
1. Berfokus pada struktur kontrol program.
2. Pengujian dilakukan untuk memastikan bahwa semua statemen
pada program telah dieksekusi paling tidak satu kali selama
pengujian dan semua kondisi telah diuji.
3. Pengujian basis path, teknik pengujian white-box,
menggunakan grafik program (matrik grafik) untuk melakukan
serangkaian pengujian yang independen secara linear yang
memastikan cakupan.
4. 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.
5. Implikasinya secara khusus diaplikasikan ke dalam komponen
program yang kecil (modul atau kelompok kecil dari modul).
b. Pengujian black-box (black-box testing)
1. Didesain untuk mengungkap kesalahan pada persyaratan
fungsional tanpa mengabaikan kerja internal dari suatu
program.
2. Berfokus pada domain informasi dari perangkat lunak.
3. Melakukan teste case dengan mempartisi domain input dan
output dari suatu program dengan cara yang memberikan
cakupan pengujian yang mendalam.
4. Partisi ekivalensi (Equivalence Class Partitioning) membagi
domain input kedalam kelas data yang mungkin untuk
melakukan fungsi perangkat lunak tertentu.
5. Analisis nilai terbatas (Boundary Value Analysis) memeriksa
kemampuan program untuk menangani data pada patas yang
dapat diterima.
6. 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 ndividual 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).
Merupakan tahap akhir proses pengujian sebelum sistem diterima
untuk penggunaan operasional.
Sistem diuji dengan data yang dipasok oleh pelanggan dan bukan
data uji simulasi.
Bisa menunjukkan kesalahan dan penghapusan definisi
persyaratan sistem karena data riil menjalankan sistem dengan
cara yang berbeda dari data uji.
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.
1.4 Pengujian Struktur Kontrol
A. Kondisi dengan If
Setiap bahasa pemrograman memiliki kemampuan untuk melakukan
pengujian kondisi agar program dapat berjalan dinamis dan interaktif. Untuk
menguji setiap kondisi, diperlukan pembanding yang bisa sama dengan, lebih
besar, lebih kecil, atau tidak sama dengan lainnya. Untuk mengujinya
dibutuhkan operator yang dapat menyatakan kondisi tersebut, yaitu dengan
operator :
1. if (kondisi) pernyataan
Format dasar penggunaan if di bawah ini menyatakan “jika kondisi benar,
maka akan dilakukan perintah sesuai dengan pernyataan”:
Contoh :
Menampilkan “Istimewa” jika nilai lebih besar dari 90.
if (nilai > 90) System.out.println(“Istimewa”);
Apabila dalam suatu pengujian terdapat dua atau lebih kondisi yang harus
diuji, diperlukan operator AND ( symbol: & ), OR ( symbol: | ), dan XOR
( symbol: ^ ).
Contoh listing program :
class pakai_if
{
public static void main(String args[])
{
int nilai; nilai=80;
System.out.println(“===============================”);
if (nilai>90 & nilai<=100)
< Lebih kecil
> Lebih besar
<= Lebih kecil & sama dengan
>= Lebih besar & sama dengan
== Sama dengan
!= Tidak sama dengan
System.out.println(“Istimewa”);
if (nilai>75 & nilai<=90)
System.out.println(“Bagus”);
if (nilai>60 & nilai<=75)
System.out.println(“Cukup”);
if (nilai>=0 & nilai<=60)
System.out.println(“Kurang”);
System.out.println(“===============================”);
}
}
2. Blok Pernyataan
Jika terdapat beberapa perintah pada suatu kondisi, maka dibutuhkan
sebuah blok pernyataan untuk menandai beberapa baris perintah menjadi satu
bagian. Format dasar penulisannya adalah sebagai berikut :
if (kondisi) {
Pernyataan-1;
Pernyataan-n;
}
Kurung kurawal { } menandai awal dan akhir dari satu blok pernyataan. Perlu
diingat, penulisan blok pernyataan bukan hanya digunakan oleh perintah if
saja, tetapi juga oleh perintah lain.
3. Nested If
Dalam kondisi yang sebenarnya, pemanfaatan IF sebagai alat pengujian
kondisi ternyata cukup kompleks. Pengujian kondisi bisa saja terjadi dua atau
tiga kali (bahkan lebih) dengan urutan bertingkat. Setelah kondisi pertama
cocok, dilakukan pengujian berikutnya. Format dasar yang dapat
menggambarkan hal tersebut:
if (kondisi-1) {
if (kondisi-2) {
- – ;
- – ;
}
}
if else
if (kondisi) {
Pernyataan-1 ;
}
else pernyataan-2 ;
if else if
if (kondisi) {
Pernyataan-1 ;
}
else if {
pernyataan-2 ;
}
else pernyataan-3 ;
B. Kondisi dengan Switch-Case
Switch-case untuk pengujian kondisi harus dilpastikan nilai yang diuji, dan
tidak dalam kisaran antara angka dengan angka yang lain. Penggunaan
switch-case hanya bermanfaat untuk jumlah kondisi yang tidak terlalu
banyak.
class pakai_swcs {
public static void main(String args[])
{
int nilai; nilai=7;
System.out.println(“===============================”);
switch(nilai) {
case 10:
System.out.println(“Istimewa”);
break;
case 7:
System.out.println(“Bagus”);
break;
case 6:
System.out.println(“Cukup”);
break;
default:
System.out.println(“Kurang”);
}
System.out.println(“===============================”);
}
}
Pada setiap pernyataan case, harus diakhiri dengan break, agar tidak
melanjutkan pengujian dengan case dibawahnya jika hasil pengujian benar.
C. Pengulangan Proses (Looping)
1. For
for (kondisi awal; kondisi akhir; perubahan kondisi) {
pernyataan-pernyataan ;
}
Perintah for melakukan pengulangan proses terhadap pernyataan-
pernyataan yang ada di dalam blok { }. Pengulangan proses dimulai dari
kondisi awal dan selesai pada kondisi akhir. Penambahan nilai pada
kondisi awal hingga kondisi akhir diatur dalam perubahan kondisi.
2. While
kondisi_awal = 0 ;
while (kondisi) {
pernyataan-pernyataan ;
perubahan_kondisi ;
}
while akan mengulang proses pada pernyataan-pernyataan sampai kondisi
tidak memenuhi syarat. Berbeda for yang telah diketahui batas awal dan
perubahan nilainya, pada while nilai awal harus Anda tentukan sendiri
beserta perubahan nilainya.
for (i=0; i<10; i++) {
pernyataan-pernyataan ;
}
sama dengan :
i=0 ;
while (i<10) {
pernyataan-pernyataan ;
i++ ;
}
Keduanya akan menghasilkan 0, 1, 2, …, 9. Pada penggunaan klausa
while, nilai awal (i=0) harus Anda tentukan sebelum proses berlangsung.
Perubahan nilai (i++) diletakkan di dalam proses, sehingga setiap kali
proses nilai i akan bertambah satu.
3. do-while
do {
pernyataan-pernyataan ;
} while (kondisi);
Perulangan pada do-while, pengujian kondisi dilakukan di bagian akhir
dari proses. Dengan demikian, setelah satu blok pernyataan dieksekusi,
pengujian baru dilakukan. Penggunaan do-while sering digunakan untuk
melewati pengujian pada nilai awal.
Contoh-contoh listing program looping :
class pakai_for
{
public static void main(String args[])
{
int n;
System.out.println(“Menampilkan angak 0,2,4,6,8,10:”);
for (n=0;n<10;n+=2)
System.out.println(“n=”+n);
System.out.println(“Menampilkan angak 10,8,6,4,2,0:”);
for (n=10;n>=0;n-=2)
System.out.println(“n=”+n);
}
}
class pakai_while