kata pengantar
Puji dan syukur kehadirat Tuhan
Yang Maha Kuasa atas segala rahmat yang diberikan-Nya sehingga tugas paper yang
berjudul “TEKNIK PENGUJIAN PERANGKAT LUNAK” ini dapat penulis selesaikan. paper
ini penulis buat sebagai kewajiban untuk memenuhi tugas dari matakuliah Testing
dan Implementasi Sistem Informasi..
Tak lupa pula penulis sampaikan banyak terima kasih kepada semua pihak yang
turut berpartisipasi dalam proses penyusunan tugas makalah ini, karena penulis
sadar sebagai makhluk sosial penulis tidak bisa berbuat banyak tanpa ada
interaksi dengan orang lain dan tanpa adanya bimbingan, serta rahmat dan
karunia dari -Nya.
Akhirnya walaupun telah berusaha
dengan secermat mungkin. Namun sebagai manusia biasa yang tak mungkin luput
dari salah dan lupa. Untuk itu penulis mengharapkan koreksi dan sarannya semoga
kita selalu berada dalam lindungan-Nya.
Padang, Oktober 2015
Penulis
BAB 1
PENDAHULUAN
Dalam dunia teknologi
sekarang pengembangan dalam bidang informatikan telah mengalami perkembangan
yang sangat pesat. Dengan perkembangan ini, dalam bidang informatika tidak
hanya menghasilkan hanya dalam pengembangan program perangkat lunak saja,
melainkan pengambangan dalam bidang suatu permodelan yang bersifat komplek.
Dalam pembuatan sebuah
perangkat lunak yang haruslah memiliki Teknik analisa kebutuhan dan teknik
permodelan yang baik, supaya terwujudnya suatu perangkat lunak yang baik.
Dengan hal tersebut maka perlulah suatu pengenalan mengenai permodelan dalam
suatu pembangunan suatu Perangkat Lunak (Software). Terdapat teknik yang
digunaka dalam pengujian perangkat lunak
Berdasarkan penjelasan yang
terdapat pada latar belakang masalah diatas, kami dihadapkan untuk menganalisa
mengenai teknik dalam pengujian perangkat lunak
Memenuhi tugas Matakuliah Sistem Informasi
Manajemen pada Semester 4
Selain itu agar Mahasiswa mampu :
a.
Menjelaskan
konsep dalam pengujian perangkat lunak
b.
Menjelaskan beberapa indikator adanya permasalahan,
peluang dan kesempatan yang dapat diraih
jika memerlukan pengembangan pengujian perangka lunak
BAB 11
PEMBAHASAN
1.
GAMBARAN PENGUJIAN
Siapakah yang melakukan pengujian ? Hal ini tergantung pada proses dan
para pemangku kepentingan terkait proyek. Dalam industri TI, perusahaan besar
memiliki tim yang bertanggung jawab untuk mengevaluasi perangkat lunak yang
dikembangkan dalam konteks persyaratan yang diberikan. Selain itu, pengembang
juga melakukan pengujian yang disebut Unit Testing. Dalam banyak kasus,
profesional berikut yang terlibat dalam pengujian sistem dalam kapasitas
masing-masing ;
·
Software
Tester
·
Software
Developer
·
Pimpinan
Proyek / Manajer
·
Pengguna
Akhir
1.1.Kapan
memulai pengujian
Pada awalnya pengujian mengurangi biaya, waktu untuk mengolah dan
kesalahan perangkat lunak bebas yang dikirimkan ke klien. Namun di Software
Development Life Cycle (SDLC) pengujian dapat dimulai dari fase Persyaratan
Mengumpulkan dan berlangsung sampai penyebaran perangkat lunak. Namun hal ini
juga tergantung pada model pembangunan yang sedang digunakan. Misalnya dalam
Air Model jatuh pengujian formal dilakukan dalam fase Testing, tetapi dalam
model inkremental, pengujian dilakukan pada akhir setiap kenaikan / iterasi dan
pada akhirnya seluruh aplikasi yang diuji.
1.2.Kapan Berhenti Pengujian
Berbeda saat untuk memulai pengujian sangat sulit untuk menentukan kapan
harus berhenti pengujian, seperti pengujian adalah proses yang tidak pernah berakhir
dan tidak ada yang dapat mengatakan bahwa perangkat lunak adalah 100% dapat
diuji. Berikut ini adalah aspek yang harus dipertimbangkan untuk menghentikan
pengujian:
·
Pengujian
Batas Waktu.
·
Penyempurnaan
pelaksanaan uji kasus.
·
Penyelesaian
cakupan Fungsional dan kode ke suatu titik tertentu.
·
Tingkat
Bug turun di bawah tingkat tertentu dan tidak ada bug prioritas tinggi
diidentifikasi.
·
Keputusan
Manajemen.
1.3.Perbedaan
antara Verifikasi & Validation
Verifikasi :
·
Apakah
Anda membangun dengan benar?
·
Pastikan
bahwa sistem perangkat lunak memenuhi semua fungsi tersebut.
·
Verifikasi
berlangsung pertama dan termasuk pemeriksaan untuk dokumentasi, kode dll
·
Dilakukan
oleh pengembang
·
Memiliki
kegiatan statis karena mencakup review, walkthrough, dan inspeksi untuk memastikan
perangkat lunak yang benar atau tidak.
·
Ini
adalah proses yang obyektif dan tidak ada keputusan subjektif harus diperlukan
untuk memverifikasi Perangkat Lunak.
Validasi :
·
Apakah
Anda membangun hal yang benar?
·
Pastikan
bahwa fungsi memenuhi perilaku yang diinginkan.
·
Validasi
terjadi setelah verifikasi dan terutama melibatkan pengecekan produk secara
keseluruhan.
·
Dilakukan
oleh penguji.
·
Memiliki
kegiatan dinamis karena mencakup mengeksekusi perangkat lunak terhadap
persyaratan.
·
Ini
adalah proses subjektif dan melibatkan keputusan subjektif pada seberapa baik
Software bekerja.
1.4.Perbedaan
antara Testing
dan Debugging
·
Testing: Ini melibatkan identifikasi bug / error / cacat dalam
perangkat lunak tanpa pengoreksian. Biasanya dengan latar belakang Quality
Assurance terlibat dalam identifikasi bug. Pengujian dilakukan dalam tahap
pengujian.
·
Debugging: Ini terlibat dalam mengidentifikasi, mengisolasi dan
memperbaiki masalah / bug. Debugging adalah bagian dari kotak putih atau Unit
Testing. Debugging dapat dilakukan dalam tahap pengembangan saat melakukan Unit
Testing atau fase sementara memperbaiki bug yang dilaporkan. Pengujian Mitos
Pengujian.
2. TEKNIK
PENGUJIAN PERANGKAT LUNAK
Pengujian perangkat lunak adalah elemen kritis dari
jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari
spesifikasi, desain dan pengkodean. Pengujian menyajikan anomali yang menarik
bagi perekayasa perangkat lunak. Pada proses perangkat lunak, perekayasa pertama-tama
berusaha membangun perangkat lunak dari konsep abstrak ke implementasi yang dapat
dilihat, baru dilakukan pengujian. Perekayasa menciptakan sederetan test case yang dimaksudkan
untuk “membongkar” perangkat lunak yang sudah dibangun. Pada dasarnya,
pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang
dapat dianggap (paling tidak secara psikologis) sebagai hal yang destruktif
daripada konstruktif.
2.1.Sasaran-sasaran
pengujian
Beberapa
sasaran pengujian diantaranya :
a. Pengujian
adalah proses eksekusi suatu program dengan maksud menemukan kesalahan
b. Test
case yang baik adalah test case yang memiliki probabilitas tinggi untuk
menemukan kesalahan yang belum pernah ditemukan sebelumnya
c. Pengujian
yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah
ditemukan sebelumnya.
Sasaran tersebut mengimplikasikan adanya perubahan
titik pandang yang dramatis. Sasaran itu berlawanan dengan pandangan yang
biasanya dipegang yang menyatakan bahwa pengujian yang berhasil adalah
pengujian yang tidak ada kesalahan yang ditemukan. Bila pengujian dilakukan secara sukses (sesuai
dengan sasaran tersebut), maka akan ditemukan kesalahan di dalam perangkat
lunak. Sebagai keuntungan sekunder, pengujian menunjukkan bahwa fungsi
perangkat lunak bekerja sesuai dengan spesifikasi dan bahwa persyaratan kinerja
telah dipenuhi.
2.2.Prinsip
Pengujian
Prinsip
Pengujian meliputi :
a. Semua pengujian harus dapat ditelusuri sampai ke
persyaratan pelanggan. Sebagaimana telah kita ketahui,
sasaran pengujian perangkat lunak adalah untuk mengungkapkan kesalahan. Hal ini
memenuhi kriteria bahwa cacat yang paling fatal (dari titik pandang pelanggan)
adalah cacat yang menyebabkan program gagal memenuhi persyaratannya.
b. Pengujian harus direncanakan lama sebelum pengujian
itu mulai. Perencanaan pengjuian dapat dimulai segera setelah
model pernyaratan dilengkapi. Definisi detail mengeani test case dapat dimulai
segera setelah model desain diteguhkan. Dengan demikian, semua pengujian dapat
direncanakan dan dirancang sebelum semua kode dibangkitkan.
c. Prinsip Pareto berlaku untuk pengujian perangkat
lunak. Secara singkat prinsip Pareto mengimplikasikan bahwa
80 persen dari semua kesalahan yang ditemukan selama pengujian sepertinya akan
dapat ditelusuri sampai 20 persen dari semua modul program. Masalahnya,bagaimana
mengisolasi modul yang dicurigai dan mengujinya dengan teliti. Pengujian harus mulai “dari yang kecil” dan
berkembang ke pengujian “yang besar”.Pengujian pertama yang direncanakan
dan dieksekusi biasanya berfokus pada modul program individual. Selagi
pengujian berlangsung maju, pengujian mengubah fokus dalam usaha menemukan kesalahan pada
cluster modul yang terintegrasi dan akhirnya pada sistem secara keseluruhan.
d. Pengujian yang mendalam
tidak mungkin. Jumlah jalur
permutasi untuk program yang berukuran menengah-pun sangat besar. Karean itulah
tidak mungkin untuk mengeksekusi setiap kombinasi jalus skema pengujian. Tetapi
dimungkinkan untuk secara tepat mencakup logika program dan memastikan bahwa
semua kondisi dalam desai prosedural telah diuji.
e. Untuk menjadi paling
efektif, pengujian harus dilakukan oleh pihak ketiga yang independent.Yang dimaksud dengan kata “yang paling efektif”
adalah pengujian yang memiliki probabilitas tertinggi di dalam menemukan
kesalahan (sasaran utama pengujian). Karena perekayasa perangkat lunak yang
membuat sistem tersebut bukanlah orang yang paling tepat untuk melakukan semua
pengujian bagi perangkat lunak.
2.3.Testabilitas
Testabilitas perangkat lunak adalah seberapa mudah
sebuah program komputer dapat diuji.Karena pengujian sangat sulit, perlu
diketahui apa yang dapat dilakukan untuk membuatnya menjadi mudah.
Kadang-kadang pemrogram beresedia melakukan hal-hal yang akan membantu proses
pengujian dan checklist mengenai masalah-masalah desai yang mudah, fitur dan
lain sebagainya yang berguna dalam bernegosiasi dengan mereka.
Checklist berikut memberikan serangkaian
karakteristik yang membawa kepada perangkat lunak yang dapat diuji :
a. Operabilitas.
“Semakin baik dia bekerja, semakin efisien dia dapat diuji”
·
Sistem memiliki
beberapa bug (bug menambah analisis dan biaya pelaporan ke proses pengujian).
·
Tidak ada bug
yang memblok eksekusi pengujian
·
Produk
berkembang di dalam tahapan fungsional (memungkinkan pengembangan dan pengujian
secara simultan)
b.
Observabilitas. “Apa yang Anda lihat adalah apa yang Anda uji”
·
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 (misal : log transaksi) secara
otomatis
·
Kode sumber
dapat diakses
c.
Kontrolabilitas.
“Semakin baik kita dapat mengontrol
perangkat lunak, semakin banyak pengujian yang dapat diotomatisasi dan
dioptimalkan”
·
Semua output
yang mungkin dapat dimnculkan melalui beberapa kombinasi input
·
Semua kode dapat
dieksekusi melalui berbagai kombinasi input
·
Keadaan dan
varibale perangkat lunak dan perangkat keras dapat dikontrol secara langsung
oleh perekayasa pengujian
·
Format input dan
output konsistem dan terstruktur
·
Pengujian dapat dispesifikasi, dioptimasi dan
direproduksi dengan baik
d.
Dekomposabilitas. “Dengan mengontrol ruang lingkup pengujian, kita
dapat dengan lebih cepat mengisolasi masalah dan melakuakn pengujian kembali
secara lebih halus”
·
Sistem perangkat
luank dibangun dari modul-modul independen
·
Modul-modul
perangkat lunak dapat diuji secara independen
e.
Dekomposabilitas. “Dengan mengontrol ruang lingkup pengujian, kita
dapat dengan lebih cepat mengisolasi masalah dan melakuakn pengujian kembali
secara lebih halus”
·
Sistem perangkat
luank dibangun dari modul-modul independen
·
Modul-modul
perangkat lunak dapat diuji secara independen Kesederhanaan struktural
(seperti, arsitektur dimodularisasi untuk membatasi penyebaran kesalahan)
·
Kesederhanaan kode (seperti, standar
pengkodean diadopsi demi kemduahan
·
inspeksi dan
pemeliharaan)
f.
Stabilitas. “Semakin sedikti perubahan, semakin sedikit
ganggunan dalam pengujian”
·
Pengujian ke
perangkat lunak tidak sering
·
Perubahan ke
perangkat lunak terkontrol
·
Perubahan ke
perangkat lunak memvalidasi pengujian yang sudah ada
·
Kegagalan
perangkat lunak dapat diperbaiki dengan baik
g.
Kemampuan untuk
dapat dipahami. “Semakin banyak
informasi yang kita miliki, semakin halus pengujian yang akan dilakukan”
Desain dipahami
dengan baik
·
Ketergantungan
di antara komponen internal, eksternal dan yang dipakai bersama dipahami dengan
baik.
·
Perubahan ke
desai dikomunikasikan
·
Dokumentasi teknik dapat diakses dengan cepat
·
Dokumentasi
teknis diorganisasikan dengan baik
·
Dokumentasi
teknis spesifik dan detail
·
Dokumentasi
teknis akurat
2.4.Desain
Test Case
Lebih dari dua dekade terakhir telah berkembang
berbagai metode desai test case untuk perangkat lunak. Metode-metode tersebut
memebrikan kepada pengembang sebuah pendekatan yang sistematik ke pengujian.
Yang lebih penting, metode itu memberikan mekanisme yang dapat membantu
memastikan kelengkapan pengujian dan memberikan kemungkinan tertinggi untuk
mengungkap kesalahan pada perangkat lunak. Semua produk yang direkayasa dapat
diuji dengan satu atau dua cara : (
a. denganmengetahui
fungsi yang ditentukan dimana produk dirancang untuk melakukannya, pengujian
dapat dilakukan untuk memperlihatkan bahwa masing-masing fungsi beroperasi
sepenuhnya, pada waktu yang sama mencari kesalahan pada setiap fungsi.
b. mengetahui
kerja internal suatu produk, maka pengujian dapat dilakukan untuk memastikan
bahwa “semua roda gigi berhubungan”, yaitu operasi internal bekerja sesuai
dnegan spesifikasi dan semua komponen ineternal telah diamati dengan
baik.Pendekatan pengujian pertama disebut pengujian black box dan yang kedua disebut white box.
2.5.Pengujian
White-Box
Pengujian
white box, kadang-kadang disebut pengujian glass box, adalah metode
desaintest case yang menggunakan struktur kontrol desain prosedural untuk
memperoleh test case. Dengan menggunakan metode pengujian white box, perekayasa
sistem dapat melakukan test case yang :
a. memberikan
jaminan bahwa semua jalur independen pada suatu modal telah digunakan,paling
tidak satu kali.
b. Menggunakan semua keputusan logis pada sisi true dan false
c. Mengeksekusi semua loop pada batasan mereka
dan baas operasional mereka
d. Menggunakan struktur data internal untuk
menjamin validitasnya
2.5.1. Pengujian
Basis-Path
Pengujian basis path adalah teknik pengujian white
box yang diusulkan pertama kali oleh Tom McCabe. Metode basis ini memungkinkan
desainer test case mengukur kompleksitas logis dari desai prosedural dan
menggunakannya sebagai pedoman untuk menetapkan basis set dari jalur eksekusi.
Test case yang dilakukan untuk menggunakan basis set tersebut dijamin
menggunakan setiap statment di dalam program paling tidak sekali selama
pengujian.
a. Notasi
Diagram Alir
Diagram Alir atau grafik program
menggambarkan aliran control logika.
b. Kompleksitas
Siklomatis
Kompleksitas Siklomatis adalah metric
perangkat lunak yang memberikan pengukuran kuantitaif terhadap kompleksitas
logis suatu program.Kompleksitas Siklomatis menentukan jumlah jalur independen
dalam basis set suatu program dan memberikan batas atas bagi jumlah pengujian
yang harus dilakukan untuk memastikan bahwa semua statemen telah dieksekusi
sedikitnya satu kali. Jalur independen adalah jalur yang melalui program yang
mengintroduksi sedikitnya saturangkaian statemen proses baru atau suatu kondisi
baru.
c. Melakukan
Test Case
·
Dengan menggunakan desain atau kode
sebagai dasar, gambarkan sebuah grafik alir yang sesuai.
·
Tentukan kompleksitas siklomatis dari
grafik alir resultan.
·
Tentukan sebuah basis set dari jalur
independen secara linier.
·
Siapkan test case yang akan memaksa
adanya eksekusi setiap basis set.
d. Matrik
Grafis
·
Matrik grafis adalah matriks bujur
sangkar yang ukurannya sama dengan jumlah simpul pada grafik alir.
·
Masingmasing baris dan kolom sesuai
dengan yang diidentifikasi kan, dan entri matriks sesuai dengan edge di antara
simpul.
2.5.2. Pengujian
struktural kontrol
·
Pengujian Kondisi
·
Pengujian Aliran Data
·
Pengujian Loop
2.6.Pengujian
black box
·
Pengujian blackbox berfokus pada
persyaratan fungsional pe rangkat lunak.
·
Disebut juga pengujian behavioral atau
pengujian partisi.
·
Pengujian blackbox memungkinkan perekayasa
perangkat lunak mendapatkan serangkaian input yang sepenuhnya menggunakan semua
persyaratan fungsional untuk suatu program.
·
Pengujian blackbox berusaha menemukan :
-
Fungsi fungsi yang tidak benar atau
hilang
-
Kesalahan interface
-
Kesalahan dalam struktur data atau akses
database eksternal.
-
Kesalahan kinerja
-
Inisialisasi dan kesalahan terminasi.
·
Dengan mengaplikasikan teknik blackbox
maka kita menarik serangkaian test case yang memenuhi criteria beirkut :
-
Test case yang mengurangi, dengan harga
lebih dari satu, jumlah test case tambahan yang harus di desain untuk mencapai
pengujian yang dapat dipertanggungjawabkan.\
-
Test case yang member tahu kita sesuatu
mengenai kehadiran atau ketidakhadiran kelas kesalahan, daripada member tahu
kesalahan yang berhubungan hanyadengan pengujian spesifik.
Tidak seperti pengujian
white box yang dilakukan pada awal proses pengujian, pengujian black box
cenderung diaplikasikan selama tahap akhir pengujian. Karena pengujianblack box
memperhatikan struktur kontrol, maka perhatian berfokus pada domain informasi.
Pengujian didesain untuk menjawab pertanyaan-pertanyaan berikut :
·
Bagaimana
validitas fungsional diuji ?
·
Kelas input apa
yang akan membuat test cse menjadi baik ?
·
Apakah sistem sangat sensitif terhadap harga
input tertentu ?
·
Bagaimana
batasan dari suatu data diisolasi ?
·
Kecepatan data apa dan volume data apa yang
dapat ditolerir oleh sistem ?
·
Apa pengaruh
kombinasi tertentu dari data terdahap operasi sistem ?
2.6.1.
Metode Pengujian
Graph-based
Langkah pertama pada pengujian black box adalah
“memahami objek” yang dimodelkan didalam perangkat lunak dan hubungan yang akan
menghubungkan objek tersebut. Setelah hal itu dilakukan maka langkah selanjutnya
adalah menentukan sederaetan pengujian yang membuktikan bahwa “semua objek
memiliki hubungan yang diharapakan satu dengan yang lainnya”. Dengan kata lain,
pengujian perangkat lunak dimulai dnegan membuat grafik dari objek-objek yang
penting dan hubungan objek-objek serta kemudian memikirkan sedereetan pengujian
yang akan mencakup
grafik tersebut sehingga masing-masing objek dan
hubungan digunakan dan kesalahan ditemukan.Untuk melakuka langkah-langkah
tersebut, perekayasa perangkat lunak memulianya denganmembuat suatu grafik,
sekkumpulan simpul yangmerepresentasikan objek; link yang merepresentasikan
hubungan antar objek; node weight yang menggambarkan properti dari suatu simpul
(misal : nilai data tertentu atau tingkah laku keadaan) dan links weight yang menggambarkan
beberapa karakteristik suatu link.
direpresentasikan
sebagai lingkaran yang dihubungkan oleh link yang memakai sejumlah bentukyang
berbeda. Link terarah (direpresentasikan oleh sebuah anak panah) menunjukkan
bahwa hubungan bergerak hanya dalam satu arah. Link dua arah yang disebut link
simetris, mengimplikasikan bahwa hubungan tersebut berlaku dalam dua arah. Link
paralel digunakan pada saat sejumlah hubungan yang berbeda dibangun di antara
simpul-simpul grafik.
2.6.2.
Partisi
Ekivalensi
Partisi ekivalensi
adalah metode pengujian black-box yangmembagai domain input dari sautu program
ke dalam kelas data dari mana test case dapat dialkukan. Test case yang ideal mengungkap
kelas kesalahan (misal, pemrosesan yang tidak benar terhadap semua data karakter)
yang akan memerlukan banyak kasus untuk dieksekusi sebelum kesalaha umum
diamati.
Partisi ekivalensi
berusaha menentukan sebuah test case yang mengungkap kelas-kelas kesalahan,
sehingga mengurangi jumlah total test case yang harus dikembangkan.Desain test
case untuk partisi ekivalensi didasarkan pada evaluasi terhdap kelas ekivalensi
untuk suatu kondisi input. Dengan menggunakan konsep yan telah dijelaskan pada
bagian sebelumnya, bila serangkaian objek dapat di-link oleh hubungan yan
gsimetris, transitif dan refleksif, maka ada kelas ekivalensi. Kelas ekivalensi
merepresentasikan serangkaian keadaan valid atau invalid untuk kondisi input.
Secara khusus, suatu kondisi input dapat berupa harga numeris, suatu rentang
harga atau serangkaian haraga terkait atau sebuah kondisi Boolean. Kelas
ekivalensi dapat ditentukan sesuai pedoman berikut ini :
a.
Bila kondisi
input menentukan suatu range, maka satu kelas ekivalensi valid dan dua yang
invalid ditentukan
b.
Bila suatu kondisi input membutuhkan suatu
harga khusus, maka satu kelas ekivalensi vaild dan uda yang invalid ditentukan
c.
Bila suatu
kondisi menentukan anggota suatu himpunan, maka satu kelas ekivalensi valid
atau dua yang invalid ditentukan.
d.
Bila suatu
kondisi input adalah Boolean, maka satu kelas valid dan satu yang invalid
ditentukan.
2.6.3.
Analisis Nilai
Batas
Karena alasan yang
tidak jelas, jumlah kesalahan yang lebih besar terjadi pada batas domain input
daripada di pusat. Karena itulah analisis nilai batas/boundary value analysis
(BVA)telah dikembangkan sebgai teknik pengujian. Analisis nilai batas
memunculkan pemilihan test case yang menggunakan nilai batas.
Analisis nilai batas
adalah teknik desain proses yang melengkapi partisi ekivalensi. Daripada memilih
sembarang elemen kelas ekivalensi, BVA lebih mengarah kepada pemilih test case
pada “edge” dari kelas. Daripada hanya berfokus pada kondisi input, BVA
melakukan test case dari domain output.
Dalam banyak hal, pedoman untuk BVA sama dengan yang
diberikan untuk partisi ekivalensi:
a.
Bila suatu
kondisi input mengkhususkan suatu range dibatasi oleh nilai a dan b,maka test
case harus didesain dengan nilai a dan b, persis di atas dan di bawah a dan b
secara berkesesuaian.
b.
Bila suatu
kondisi input mengkhususkan sejumlah nilai, maka test case harus dikembangkan
dengan menggunakan jumlah minimum dan maksimum. Nilai tepat di atas dan di
bawah minimum dan maksimum juga diuji.
c.
Pedoman 1 dan 2 diaplikasikan ke kondisi
output. Contohnya anggap bahwa suhu vs.tabel tekanan diperlukan sebagai output
dari program analisis rekayasa. Test case harus didesain untuk menciptakan
laporan output yang menghasilkan jumlah minimum (dan maksimum) entri tabel yang
diijinkan.
d.
Bila struktur
data program telah memesan batasan (misal, suatu array memiliki suatu batas
yang ditentukan dari 100 entri), pastikan untuk mendesain test case yang
menggunakan struktur data pada batasannya.
2.6.4.
Pengujian
Perbandingan
Ada banyak situasi
(seperti avionik pesawat udara) dimana reliabilitas perangkat lunaknya sangat
kritis. Dalam aplikasi semacam itu, perangkat lunak dan perangkat keras
redundan sering digunakan untuk meminimalkan kemungkinan kesalahan. Pada saat
perangkat lunak redundan dikembangkan, tim rekayasa perangkat lunak yang
terpisah mengembangkan versi-versi independen dari suatu aplikasi dengan
menggunakan spesifikasi yang sama. Dalam situasi semacam itu, setiap versi
dapat diuji dengan data uji yang sama untuk memastikan bahwa semua versi
memberikan output yang identik. Kemudian semua versi dieksekusi secara paralel
dnegan perbandingan real time hasil untuk memastikan konsistensi.
Dengan pelajaran
mengenai sistem redundan, para peneliti mengusulkan agar versi perangkat lunak
independen dikembangkanbagi aplikasi kritis, bahkan bila hanya sebuah versi tunggal
saja yang akan digunakan pada sistem berbasis komputer yang disampaikan. Versi independen
membentuk basis teknik pengujian black box yang disebut pengujian perbandingan
atau pengujian back to back.
Bila implementasi
bertingkat dari spesifikasi yang sama telah dihasilkan, maka test case yang didesain
dengan menggunakan teknik black box yang lain (misal partisi ekivalensi)
diberikan sebagai input untuk masing-masing versi perangkat lunak tersebut.
Bila output dari masing-masing versi sama, maka diasumsikan bahwa
implementasinya benar. Bila outputnya berbeda, maka masingmasing dari aplikasi
itu diperiksa untuk menentukan cacat pada suatu versi atau agar perbedaan itudapat
lebih jelas. Pada sebagian besar kasus, perbandingan output dapat dilakukan
dengan suatu peranti yang diotomatisasi.
Pengujian perbandingan
tidaklah mudah. Bila spesifikasi dari mana semua fungsi telah dikembangkan
mengandung kesalahan, maka semua versi kemungkinan besar merefleksikan kesalahan.
Lagi pula jika masing-masing versi independen identik tetapi tidak benar, maka
pengujian kondisi akan gagal mendeteksi kesalahan.
2.7.Pengujian
Untuk Aplikasi dan Lingkungan Khusus
Pada saat perangkat lunak komputer menjadi semakin
kompleks,maka kebutuhan akan pendekatan pengujian yang khusus juga makin
berkembanga. Metode pengujian black-box dan white box yang dibicarakan
sebelumnya dapat diaplikasikan pada semua lingkungan, arsitektur dan aplikasi,
tetapi kadang-kadang dalam pengujian diperlukan pedoman dan pendekatan yang
unik. Pada bagian ini akan dibahas pedoman pengujian bagi lingkungan arsitektur
dan aplikasi khusus yang umumnya ditemui oleh para perekayasa perangkat lunak.
2.7.1.
Pengujian GUI
Graphical User
Interfaces (GUI) menyajikan tantangan yang menarik bagi para perekayasa. Karena
komponen reusable berfungsi sebagai bagian dari lingkungan pengembangan GUI, pembuatan
interface pemakai telah menjadi hemat waktu dan lebi teliti. Pada saat yang
sama, kompleksitas GUI telah berkembanga, menimbulkan kesulitan yang lebih
besar di dalam desain dan eksekusi test case.
Karena GUI modern memiliki
bentuk dan cita rasa yang sama maka dapat dilakukan sederetan pengujian
standar. Pertanyaan berikut dapat berfungsi sebagai panduan untuk serangkaian
pengujian generik untuk GUI :
a.
Untuk windows :
·
Apakah window
akan membuka secara tepat berdasarkan tipe yang sesuai atau perintahberbasis
menu ?
·
Dapatkah window
di-resize, digerakkan atau digulung ?
·
Apakah semua isi
data yang diisikan pada window dapat dituju dengan tepat dengansebuah mouse,
function keys, anak panah penunjuk dan keyboard ?
·
Apakah window
dengan cepat muncul kembali bila dia ditindih dan kemudian dipanggil lagi ?
·
Apakah semua
fungsi yang berhubungan dengan window dapat diperoleh bila diperlukan ?
·
Apakah semua
fungsi yang berhubungan dengan window operasional ?
·
Apakah semua
menu pull down, tool bar,scroll bar, kotak dialog, tombol ikon dan kontrol yang
laina dapat diperoleh dan dengan tepat ditampilkan untu window tersebut ?
·
Pada saat window
bertingkat ditampilkan, apakah nama window tersebut direpresentasikan secara
tepat ?
·
Apakah window
yang aktif disorot secara tepat ?
·
Bila
multitasking digunakan, apakah semua window diperbarui pada waktu yang sesuai ?
·
Apakah pemilihan
mouse bertingkat atau tidak benar di dalam window menyebabkan efek samping yang
tidak diharapkan ?
·
Apkaha audio prompt
dan atau color prompt ada di dala window atau sebagai konsekuensi dari operasi
windoe disaajikan menurut spesifikasi ?
·
Apakah window akan menutup secara tepat ?
b.
Untuk menu pull down dan operasi mouse :
·
Apakah menu bar
yang sesuai ditampilkan di dalam konteks yang sesuai ?
·
Apakah menu bar
aplikasi menampilkan fitur-fitur yang terkait dengan sistem (misal tampilan jam
) ?
·
Apakah operasi
menu pull down bekerja secara tepat ?
·
Apakah menu
breakway, palette dan tool bar bekerja secara tepat ?
·
Apakah semua fungsi
menu dan subfungsi pulldown didaftar secara tepat ?
·
Apakah semua
fungsi menu dapat dituju secara tepat oleh mouse ?
·
teks alternatif
?
·
Apakah fungsi
menu disorot berdasarkan konteks operasi ang sedang berlangsung di dalam suatu
window ?
·
Apakah semua menu
function bekerja seperti diiklankan ?
·
Apakah nama-nama
menu funvtion bersifat self explanatory ?
c.
Entri Data :
·
Apakah entri
data alfanumeris dipantulkan dan diinput ke sistem ?
·
Apakah mode
grafik dari entri (misal, slide bar) bekerja dengan baik ?
·
Apakah data
invalid dikenali dengan baik ?
·
Apakah pesan
input data sangat pintar ?
2.7.2.
Pengujian
Arsitektur Client Server
Arsitektur
client/server (C/S) menghadirkan tantangan yang berarti bagi para
pengujiperangkat lunakan. Sifat terdistribusi dari lingkungan client/server,
masalah kinerja yang berhubungan dengan pemrosesan transaksi, kehadiran
potensial dari sejumlah platform perangkat keras yang berbeda, kompleksitas
komunikasi jaringan,kebutuahn aka layanan client multipel dari suatu database
terpusat dan persyaratan koordinasi yang dibebabkan pada server, semua secara
bersama-sama membuat pengujian terhadap arsitektur C/S dan perangkat lunak yang
ada didalamnya menjadi jauh lebih sulit daripada pengujian aplikasi yang
berdiri sendiri. Kenyataannya studi industri terakhir menunjukkan pertambahan
berarti di dalam waktu pengujian dan biaya ketika lingkungan C/S dikembangkan
2.7.3.
Pengujian
Dokumentasi dan Fasilitas Help
Istilah
“pengujianperangkat lunak” memunculkan citra terhdapa sejumlah besar test caseyang
disiapkan untuk menggunakan program komputer dan data yang dimanipulasi oleh
program.Dengan melihat kembali definisi perangkat lunak yang disajikan di awal,
penting untuk dicatat bahwa pengujian harus berkembang ke elemen ketiga dari
konfigurasi perangkat lunak, yaitu“dokumentasi”.Kesalahan dala dokumentasi
dapat menghancurkan penerimaan program seperti halnya kesalahan pada data atu
kode sumber. Tidak ada yang lebih membuat frustasi dibanding mengikuti tuntuan
pemakai secara tepat dan mendapatkan hasil atau tingkah laku yang tidak sesuai
dengan yang diprediksi oleh dokumen.
Karena itulah
pengujian dokumentasi harus menjadi suatu bagian yang berarti dari setiap
rencana pengujian perangkat lunak.Pengujian dokumentasi dapat didekati dalam
dua fase. Fase pertama, kajian teknis formal yang menguji kejelasan editorial
dokumen. Fase kedua, live test, menggunakan dokumentasi dalam kaitannya dengan
penggunaan program aktual. Live test untuk dokumentasi dapat didekati dengan
menggunaka teknik yang analog dneganberbagai metode pengujian black box.
Pengujian graph-based ddapat digunakan untuk menggambarkan penggunaan program
tersebut; partisi ekivalensi dan analisis nilai batas dapat digunakan untuk
menentukan berbagai kelas input dan interaksi yang sesuai. Kegunaan program
kemudian ditelusuri pada seluruh dokumen
:
a. Apakah dokumen tersebut secara akurat menggambarkan
bagimana menyelesaikan masingmasing mode penggunaan ?
b. Apakah deskripsi dari masing-masing urutan interaksi
akurat ?
c. Apakah contoh-contoh akurat ?
2.7.4.
Pengujian Sistem
Real-Time
Sifat asinkron dan
tergantung waktu yang ada pada banyak aplikasi real time menambahkan elemen
baru yang sulit dan potensial untuk bauran pengujian-waktu. Tidak hanya
desainer teset case yang harus memeprtimbangkan test case balck box dan white
box tetapi juga penanganan kejadian (yaitu pemrosesan interupsi), timing data
dan paralelisme tugas-tugas (proses) yang menangani data. Pada banyak situasi,
data pengujian yang diberikan pada saat sebuah sistem real
time ada dalam satu keadaan akan menghasilkan
pemrosesan yang baik, sementara data yang sama yang diberikan pada saat sistem
berada dalam keadaan yang berbeda dapat menyebabkan kesalahan.
Hubungan erat perangkat
lunak real time dan lingkungan perangkat kerasnya dapat juga menyebabkan
pengaruh kegagalan perangkat keras pada pemrosesasn perangkat lunak. Kesalahan semacam
itu dapat sangat sulit untuk bersimulasi secara realistis. Metode desain test
case yang komprehensif untuks istem real time harus berkembang. Tetapi strategi
emapat langkah berikut dapat diusulkan :
a.
Pengujian tugas. Langkah pertama dalam pengujian perangkat lunak
real time adalah menguji masing-masing tugas secara independen, yaitu pengujian
white box dan black box yang didesain dan dieksekusi secara independen bagi
masing-masing tugas. Masing-masing tugas dieksekusi secara independen selama
pengujian ni. Pengujian tugas mengungkap kesalahan di dalam logika dan fungsi,
tetapi tidak akan mengungkap timing atau kesalahan tingkah laku.
b.
Pengujian
tingkah laku. Dengan menggunakan
model yang idciptakan dengan peranti CASE, dimungkinkan untuk mensimulasi
tingkah laku sistem real time dan menguji tingkah lakunya sebagai konsekuensi
dari event eksternal. Aktivitas analisis ini dapat berfungsi sebgai dasar bagi
desain test case yang dilakukan pada saat perangkat lunak real time dibangun
c.
Pengujian antar
tugas. Setelah
kesalahan-keaslahan pada tugas individual dan pada perilaku sistem diisolasi,
maka pengujian beralih kepada kesalahan yang berkaitan dengan waktu.
Tugas-tugas asinkronous yang dikenali untuk saling berkomunikasi diuji dnegna
tingkat data yang berbeda dan pemrosesan dipanggil untuk menentukan apakah
kesalahan sinkronisasi antar tugas akan terjadi. Sebagai tambahan, tugas-tugas
yang berkomuniaksi melalui antrian pesan atau penyimpanan data, diuji untuk
menemukan kesalahan dalam ukuran area penyimpanan data tersebut.
d.
Pengujian sistem. Perangkat lunak dan perangkat keras diintegrasi
dan suatu rentang penuh dari pengujian sistem dilakukan di dalam usahan
mengungkap keslahan pada interface perangkat lunak/perangkat keras.
Sebagian besar sitem real time memproses interupsi,
karena itu pengujian penanganan
terhadap kejadian-kejadian. Boolean merupakan hal
yang penting. Dengan menggunakan diagram keadaan transisi dan spesifikasi
kontrol, penguji mengembangkan daftar semua interupsi yang mungkin dan
pemroesan yang terjadi sebagai konsekuensi dari interupsi. Kemudain pengujian
didesain untuk menilai karakteristik sistem berikut ini :
a.
Apakah priortias interupsi ditetapkan dan
ditangani secara tepat ?
b.
Apakah pemrosesan untuk masing-masing
interupsi ditangani dengan tepat ?
c.
Apakah kinerja (misal waktu pemrosesasn) dari
masing-masing prosedur penangan interupsi sesuai dengan persyaratan ) ?
d.
Apakah volume
interupsi yang tinggi yang terjadi pada waktu kritis menimbulkan masalah di
dalam fungsi atau kinerja ?
3.
JENIS-JENIS PENGUJIAN PERANGKAT LUNAK
3.1.Pengujian manual
Jenis ini termasuk pengujian Software secara manual yaitu tanpa menggunakan
alat otomatis atau script apapun. Dalam jenis ini tester mengambil alih peran
pengguna akhir dan menguji Software untuk mengidentifikasi perilaku un-yang
diharapkan atau bug. Ada tahapan yang berbeda untuk pengujian manual seperti
unit testing, pengujian Integrasi, pengujian sistem dan User Acceptance
testing.
Penguji menggunakan tes rencana, uji kasus atau skenario tes untuk
menguji Software untuk memastikan kelengkapan pengujian. Pengujian manual juga
mencakup pengujian eksplorasi sebagai penguji, dan mengeksplorasi perangkat
lunak untuk mengidentifikasi kesalahan di dalamnya.
3.2.Pengujian
otomatisasi
Proses ini melibatkan otomatisasi dari proses manual. Otomasi Pengujian
digunakan untuk menjalankan kembali skenario pengujian yang dilakukan secara
manual, dengan cepat dan berulang-ulang.
Terlepas dari pengujian regresi, pengujian Otomasi juga digunakan untuk
menguji aplikasi dari beban, kinerja dan titik tekanan pandang. Hal ini
meningkatkan cakupan tes; meningkatkan akurasi, menghemat waktu dan uang
dibandingkan dengan pengujian manual.
4. TINGKATAN
PENGUJIAN PERANGKAT LUNAK
4.1.Pengujian Fungsional
Aplikasi
ini adalah jenis pengujian black box
yang didasarkan pada spesifikasi perangkat lunak yang akan diuji. Aplikasi ini
diuji dengan memberikan masukan dan kemudian hasilnya diperiksa dengan fungsi
yang dimaksud. Pengujian fungsional perangkat lunak yang dilakukan pada sistem,
lengkap terpadu dan digunakan untuk mengevaluasi kepatuhan sistem dengan
persyaratan yang ditentukan.
Pada pengujian fungsional
terdapat beberapa jenis pengujian yaitu :
4.1.1.
Pengujian Satuan
(Unit Testing)
Jenis
pengujian dilakukan oleh para pengembang sebelum setup diserahkan kepada tim
pengujian secara resmi pada saat melaksanakan uji kasus. Unit pengujian
dilakukan oleh para pengembang masing-masing unit individu dari kode sumber
tempat yang ditentukan. Para pengembang menggunakan data uji yang terpisah dari
data uji tim kualitas jaminan.
4.1.2.
Pengujian
Integrasi/Gabungan (Intregation Testing)
Pengujian
gabungan merupakan bagian dari aplikasi untuk menentukan apakah mereka
berfungsi dengan benar secara bersamaan. Ada dua metode dalam melakukan
Pengujian Integrasi yaitu pengujian Integrasi bottom-up dan pengujian Integrasi
Top Down.
4.1.3.
Pengujian Sistem
(System Testing)
Ini
adalah tingkat pengujian berikutnya dan tes sistem secara keseluruhan. Setelah
semua komponen yang terintegrasi, aplikasi secara keseluruhan diuji ketat untuk
dilihat apakah dapat memenuhi Standar Mutu atau tidak. Jenis pengujian
dilakukan oleh tim pengujian khusus.
4.1.4.
Pengujian Regresi
Tujuan
dari pengujian regresi adalah untuk memastikan bahwa perubahan, seperti
memperbaiki bug tidak menimbulkan kesalahan lain yang sering ditemukan dalam
aplikasi.
4.1.5. Pengujian Penerimaan (Accepance Testing)
Hal
ini bisa dibilang tipe yangterpenting karena sebagian besar pengujian dilakukan
oleh Tim Jaminan Kualitas yang akan mengukur apakah aplikasi memenuhi
spesifikasi yang diinginkan dan memenuhi kebutuhan klien. Tim QA akan memiliki
satu set skenario dan Uji Kasus yang akan digunakan untuk menguji aplikasi.
4.2.PENGUJIAN NON
FUNGSIONAL
Bagian
ini didasarkan pada pengujian aplikasi dari atribut non-fungsional. Pengujian non-fungsional
melibatkan pengujian Perangkat Lunak dari persyaratan yang non-fungsional baik
seperti kinerja, keamanan, user interface, dll.
Ada beberapa jenis pengujian pada pengujian non
fungsional :
4.2.1. Pengujian Kinerja
Hal
ini sebagian besar digunakan untuk mengidentifikasi adanya kemacetan atau
masalah kinerja pada saat menemukan bug dalam perangkat lunak.
4.2.2.
Pengujian Usability
Bagian
ini mencakup konsep yang berbeda. Ini adalah teknik black box dan digunakan
untuk mengidentifikasi kesalahan dan perbaikan dalam Perangkat Lunak dengan
memperhatikan pengguna melalui penggunaan dan operasi mereka.
4.2.3.
Pengujian keamanan
Pengujian
Keamanan melibatkan pengujian Software untuk mengidentifikasi setiap kelemahan
kesenjangan iklan dari keamanan dan kerentanan sudut pandang.
4.2.4.
Pengujian Portabilitas
Pengujian
ini meliputi pengujian Software yang harus kembali dan bisa digunakan dan
dipindahkan dari Software lain.
5. PENGUJIAN DOKUMENTASI
(DOCUMENTATION TESTING)
Pengujian dokumentasi melibatkan dokumentasi artefak
yang harus dikembangkan sebelum atau selama pengujian Software. Pengujian ini membantu
software dalam memperkirakan upaya pengujian yang diperlukan, cakupan tes,
pelacakan persyaratantracing dll.
Bagian
ini mencakup deskripsi beberapa artefak yang umum digunakan yang berkaitan
dengan pengujian Software seperti:
a.
Rencana Uji
b.
Uji Skenario
c.
Kasus Uji
d.
Matrix Laca
BAB 111
KESIMPULAN
Pengujian
perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan
kajian pokok dari spesifikasi, desain dan pengkodean.metode dalam pengujian
perangkat lunak menggunkan 2 metode yaitu: metode white box dan mmetode black
box.
Jenis pengujian perangkat lunak ada 2 cara yaitu:
pengujian manual dan pengujian otomatisasi.
DAFTAR
PUSTAKA
file.upi.edu/Direktori/FPMIPA/PRODI._ILMU_KOMPUTER/196603252001121-MUNIR/Software_Testing/BAB_1_Pengujian_Perangkat_Lunak.pdf
