Teknik Pengujian Perangkat Lunak

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”);


System.out.println(“Bagus”);


System.out.println(“Cukup”);

if (nilai>=0 & nilai<=60)

System.out.println(“Kurang”);


}

}

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 {


{

int nilai; nilai=7;


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”);

}


}

}

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) {


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++) {


}

sama dengan :

i=0 ;

while (i<10) {


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 {


} 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

{


{

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);


for (n=10;n>=0;n-=2)

System.out.println(“n=”+n);

}

}

class pakai_while

{


{

int n;

System.out.println(“Menampilkan angak 0,1,2,…,10:”);

n=0;

while (n<=10) {

System.out.print(n+” “);

n++;

}

System.out.println();


n=0;

while (n<=10) {

System.out.print(n+” “);

n+=2;

}

}

}

Documents

Teknik Pengujian Perangkat Lunak