Materi 4OK1

Fakultas Ilmu Komputer dan Teknologi Informasi
Jurusan Sistem Informasi

Univesitas Gunadarma
1
Shafira Adrizayani ST., MMSI -
Testing & Implementasi Sistem
• Memahami langkah awal untuk melakukan
pengujian terhadap perangkat lunak.
2
• Dasar-dasar pengujian perangkat lunak
• Pengujian white box
• Pengujian path basis
• Pengujian struktur kendali
3
4
• Bukan seorang programmer yg cukup baik.
• Lupa menggunakan pemrograman terstruktur secara penuh,
perancangan atas-bawah untuk mendapatkan solusi.
• Seharusnya dapat membedakan apa yang dikatakan programmer
lain atau pelanggan dan apa yang sebenarnya mereka pikirkan.
• Merasa bersalah apabila seseorang harus menguji koding yang
kita buat.
• Pengujian merupakan suatu perizinan terhadap kesalahan.
5
Isu-Isu Seputar Testing
1. Sistem itu “Buggy“
2. Testing ditampilkan dengan gambaran yang menakutkan
3. Batas waktu menjadi hambatan bagi testing
4. Testing bukan organisasi dan ilmu
5. Manajemen pendukung untuk testing kurang dari ideal
6. Testing tidak ditampilkan sebagai suatu karir yang
menjanjikan
7. Teknologi baru ataupun lama menyulitkan situasi
Shafira Adrizayani ST., MMSI - 6

• Pengujian adalah proses eksekusi suatu program
dengan maksud menemukan kesalahan
• Test case yang baik adalah test case yang memiliki
probabilitas tinggi untuk menemukan kesalahan yang
belum pernah ditemukan sebelumnya
• Pengujian yang sukses adalah pengujian yang
mengungkap semua kesalahan yang belum pernah
ditemukan sebelumnya.
7
• Semua pengujian harus dapat ditelusuri sampai ke
persyaratan pelanggan.
– cacat yang menyebabkan program gagal
memenuhi persyaratan
• Pengujian harus direncanakan lama sebelum
pengujian itu mulai.
– Perencanaan pengujian dapat dimulai segera
setelah model pernyaratan dilengkapi. Definisi
detail mengeani test case dapat dimulai segera
setelah model desain diteguhkan.
8
• Prinsip Pareto berlaku untuk pengujian perangkat lunak.
– Prinsip Pareto mengimplikasikan bahwa 80 persen dari semua
kesalahan yang ditemukan selama pengujian sepertinya akan
dapat ditelusuri sampai 20 persen dari semua modul program.
• 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.
9
• Pengujian yang mendalam tidak mungkin.
– Jumlah jalur permutasi untuk program yang berukuran
menengah-pun sangat besar. Karena itulah tidak mungkin
untuk mengeksekusi setiap kombinasi jalus skema pengujian.
• Untuk menjadi paling efektif, pengujian harus dilakukan oleh
pihak ketiga yang independent.
– 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.
10
• Testabilitas PL adalah seberapa mudah
program komputer dapat diuji.
• Karakteristik pengujian testabilitas PL :
1. Operabilitas / Operability
2. Observabilitas / Observability
3. Kontrolabilitas / Controlability
4. Dekomposabilitas / Decomposability
5. Kesederhanaan / Simplicity
6. Stabilitas / Stability
7. Kemampuan untuk dipahami / Understandbility
12
• 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)
13
• 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)
– Semua faktor yang mempengaruhi output dapat dilihat
– Kesalahan internal dideteksi secara otomatis melalui mekanisme
selftesting
– Kesalahan internal dilaporkan secara otomatis
– Kode sumber (source code ) dapat diakses
14
• Kontrolabilitas. “Semakin baik kita dapat mengontrol
perangkat lunak, semakin banyak pengujian yang dapat
diotomatisasi dan dioptimalkan”
– Semua output yang mungkin dapat dimunculkan melalui beberapa
kombinasi input
– Semua kode dapat dieksekusi melalui berbagai kombinasi input
– Keadaan dan variable perangkat lunak dan perangkat keras dapat
dikontrol secara langsung oleh perekayasa pengujian
– Format input dan output konsisten dan terstruktur
– Pengujian dapat dispesifikasi, dioptimasi dan direproduksi dengan
baik
15
• Dekomposabilitas. “Dengan mengontrol ruang lingkup
pengujian, kita dapat dengan lebih cepat mengisolasi
masalah dan melakukan pengujian kembali secara lebih
halus”
– Sistem perangkat lunak dibangun dari modul-modul
independen
– Modul-modul perangkat lunak dapat diuji secara independen
16
• Kesederhanaan. “Semakin sedikit yang diuji, semakin cepat kita
dapat mengujinya”
– Kesederhanaan fungsional (seperti, kumpulan fitur adalah
kebutuhan minimum untuk memenuhi persyaratan).
– Kesederhanaan struktural (seperti, arsitektur dimodularisasi
untuk membatasi penyebaran kesalahan)
– Kesederhanaan kode (seperti, standar pengkodean diadopsi
demi kemudahan inspeksi dan pemeliharaan).
17
• Stabilitas. “Semakin sedikit perubahan, semakin sedikit gangguan dalam
pengujian”
– Perubahan 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
18
• 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 desain dikomunikasikan
– Dokumentasi teknik dapat diakses dengan cepat
– Dokumentasi teknis diorganisasikan dengan baik
– Dokumentasi teknis spesifik dan detail
– Dokumentasi teknis akurat
19
1. Pengujian yang baik memiliki probabilitas yang tinggi
untuk menemukan kesalahan.
2. Pengujian yang baik tidak redudan. Waktu pengujian
dan sumber daya terbatas.
3. Pengujian yang baik seharusnya “jenis terbaik”.
4. Pengujian yang baik tidak boleh terlalu sederhana atau
terlalu kompleks.
20
Kemampuan Tester yang Diharapkan
• Kemampuan secara umum
– Mempunyai kemampuan analisa yang kuat dan terfokus
– Mempunyai kemampuan komunikasi yang baik
– Mempunyai latar belakang QA
• Pemahaman terhadap metodologi
– Pengembangan rencana tes
– Pembuatan dan perawatan lingkungan tes
– Standar tes
– Dokumentasi tes (seperti test cases dan procedure test)

• Pengetahuan akan pendekatan testing
– Integration testing
– Acceptance Testing
– Stress / Volume Testing
– Regression testing
– Functional testing
– End-To-End Testing
– GUI Testing
• Pengetahuan tentang sistem (berhubungan dengan pasar dari
organisasi bersangkutan)
– Perbankan/Keuangan
– Produk Komersial
– Telecom
– Internet
– Y2K
• Pengetahuan dan pengalaman akan penggunaan alat bantu testing
– Alat bantu capture atau playback (seperti WinRunner)
– Alat bantu Load testing (seperti LoadRunner, RoboTest)
• Kemampuan terhadap lingkungan testing
– Mainframe (seperti MVS, JCL).
– Client – Server (seperti WinNT, UNIX)
• Kemampuan terhadap aplikasi
– Dokumentasi (seperti office, excel, word, Lotus Notes)
– Database (seperti oracle, access, 3GL, 4GL, SQL, RDBMS)
– Pemrograman (seperti C++, VB, OO)

Personalitas Tester
• Atribut positif yang patut dikembangkan
– Terencana, sistematis, dan berhati-hati (tidak sembrono) –
pendekatan logis terhadap testing.
– Bermental juara – seperti penerapan standar kualitas yang tinggi
dalam bekerja dalam suatu proyek.
– Berpendirian teguh - tidak mudah menyerah
– Praktikal – menyadari terhadap apa yang dapat dicapai terhadap
batasan waktu dan anggaran tertentu.
– Analitikal – memiliki intiusi dalam mengambil suatu pendekatan
untuk menggali error.
– Bermoral baik – berjuang untuk kualitas dan sukses, mengerti dan
menyadari akan biaya-biaya yang terjadi terhadap suatu kualitas
yang rendah.
Personalitas Tester
• Atribut negatif yang patut dihindari
– Sedikit empati terhadap pengembang (developers) – mudah
terpengaruh secara emosional yang kekanak-kanakan dalam
hubungannya dengan pengembang (developers).
– Kurang berdiplomasi – menciptakan konflik dengan pengembang
(developers) dengan menunjukan wajah yang tak bersahabat.
Seorang tester akan tersenyum bila bertatap muka dengan
pengembang (developers) saat menemukan defect, dan
memberikan laporan defect yang disertai perhitungan statistik
terjadinya defect dan bug.
– Skeptis – meminta informasi dari pengembang (developers)
dengan penuh kecurigaan (tidak percaya).
– Keras kepala – tidak dapat fleksibel dalam mendiskusikan suatu
proposal. Shafira Adrizayani ST., MMSI - 25
Pengertian Defect dari Software
• Menurut Kaner, Falk, dan Nguyen [KAN93], ada 13 kategori
utama defect dari software, yaitu:
– User interface errors - sistem memberikan suatu tampilan yang berbeda dari
spesifikasi.
– Error handling – pengenalan dan perlakuan terhadap error bila terjadi.
– Boundary – related errors - perlakuan terhadap nilai batasan dari jangkauan
mereka yang mungkin tidak benar.
– Calculation errors - perhitungan arimatika dan logika yang mungkin tidak benar.
– Initial and later states - fungsi gagal pada saat pertama digunakan atau
sesudah itu.
– Control flow errors - pilihan terhadap apa yang akan dilakukan berikutnya tidak
sesuai untuk status saat ini.
– Errors in handling or interpreting data - melewatkan dan mengkonversi data
antar sistem (dan mungkin komponen yang terpisah dari sistem) dapat
menimbulkan error.
– Race conditions - bila dua event diproses akan maka salah satu akan diterima
berdasarkan prioritas sampai pekerjaan selesai dengan baik, baru pekerjaan
berikutnya. Bagaimanapun juga kadang-kadang event lain akan diproses
terlebih dahulu dan dapat menghasilkan sesuatu yang tidak diharapkan atau
tidak benar.
– Load conditions - saat sistem dipaksa pada batas maksimum, masalah akan
mulai muncul, seperti arrays, overflow, diskfull.
– Hardware - antar muka dengan suatu device mungkin tidak dapat beroperasi
dengan benar pada suatu kondisi tertentu seperti device unavailable.
– Source and Version Control - program yang telah kadaluwarsa mungkin akan
dapat digunakan lagi bila ada revisi untuk memperbaikinya.

– Documentation - pengguna tak dapat melihat operasi yang telah
dideskripsikan dalam dokumen panduan.
– Testing errors - tester membuat kesalahan selama testing dan
berpikir bahwa sistem berkelakuan tak benar.

Biaya-Biaya yang Berkaitan dengan Testing dan
Defects
Biaya-biaya testing

Defects
• Biaya-biaya defects
– Kesiapan dukungan teknisi.
– Persiapan buku panduan FAQ.
– Investigasi komplain pelanggan.
– Ganti rugi dan mengambil kembali produk.
– Coding atau testing dari pembenahan bugs.
– Pengiriman dari produk yang telah diperbaiki.
– Penambahan biaya terhadap dukungan berbagai versi dari produk
yang telah di release.
– Tugas Public Relation untuk menjelaskan review dari defects.
– Hilangnya pangsa jual.

Defects
• Biaya-biaya defects
– Hilangnya kepercayaan pelanggan.
– Pemberian potongan harga pada penjual agar
mereka tetap menjual produk.
– Garansi.
– Kewajiban.
– Investigasi pemerintah.
– Pinalti.
– Dan biaya lain yang berkaitan dengan hukum.
Defects
Biaya-biaya defects

Siklus Hidup Testing secara Umum
• Tahapan untuk testing merupakan suatu
komponen dari keseluruhan metodologi. Pada
prakteknya, testing sangat kurang
didiskripsikan dan telah dengan cepat
bergerak ke titik dimana kebanyakan prosedur
testing organisasi sudah ketinggalan jaman
dan tidak efektif.
• Pada awalnya testing merupakan salah satu
sub-fase dari fase pengembangan
(development), setelah fase coding. Sistem
didisain, dibangun dan kemudian dites
dandidebug.
• Sejalan dengan kemapanan testing secara
praktis, secara bertahap kita berpendapat
bahwa sudut pandang testing yang tepat
adalah dengan menyediakan suatu siklus
hidup testing secara lengkap, yang
merupakan suatu bagian dan menjadi satu
kesatuan di dalam siklus hidup software
secara keseluruhan. Shafira Adrizayani ST., MMSI - 33
Aktifitas Testing secara Umum
• Perencanaan
– Rencana pendekatan umum
– Menentukan obyektivitas testing
– Memperjelas rencana umum
• Akusisi
– Disain tes
– Menerapkan tes
• Pengukuran
– Eksekusi tes
– Cek terminasi
– Evaluasi hasil

Tiga Tingkatan Testing secara Umum
• Unit testing
– Testing penulisan kode-kode program dalam satuan unit terkecil
secara individual.
• System Testing
– Proses testing pada sistem terintegrasi untuk melakukan verifikasi
bahwa sistem telah sesuai spesifikasi.
• Acceptance Testing
– Testing formal yang dilakukan untuk menentukan apakah sistem
telah memenuhi kriteria penerimaan dan memberdayakan
pelanggan untuk menentukan apakah sistem dapat diterima atau
tidak.

Praktik unit testing secara umum
• Tujuan
– Konfirmasi bahwa modul telah dikode dengan benar.
• Pelaku
– Biasanya programer.
• Apa yang dites
– Fungsi (Black Box).
– Kode (White Box).
– Kondisi ekstrim dan batasan-batasan.
• Kapan selesai
– Biasanya saat programer telah merasa puas dan tidak diketahui lagi kesalahan.
• Alat bantu
– Tidak biasa digunakan.
• Data
– Biasanya tidak didata.
Praktik system testing secara umum
• Tujuan
– Merakit modul menjadi suatu sistem yang bekerja. Dan menentukan kesiapan untuk
melakukan Acceptance Test.
• Pelaku
– Pemimpin tim atau grup tes.
• Apa yang dites
– Kebutuhan dan fungsi sistem.
– Antarmuka sistem.
• Kapan selesai
– Biasanya bila mayoritas kebutuhan telah sesuai dan tidak ada kesalahan mayor yang
ditemukan.
• Alat bantu
– Sistem pustaka dan pustaka test case.
– Generator, komparator dan simulator data testing.
• Data
– Data kesalahan yang ditemukan.
– Test case. Shafira Adrizayani ST., MMSI - 37
Praktik acceptance testing secara umum
• Tujuan
– Mengevaluasi kesiapan untuk digunakan.
• Pelaku
– Pengguna akhir atau agen.
• Apa yang dites
– Fungsi mayor.
– Dokumentasi.
– Prosedur.
• Kapan selesai
– Biasanya bila pengguna telah merasa puas atau tes berjalan dengan lancar /
sukses.
• Alat bantu
– Komparator.
• Data
– Formalitas dokumen.
• Dua kelas input yang disediakan untuk proses
uji perangkat lunak adalah :
1. Konfigurasi software, termasuk Software
Requirement Specification, Design Specification
dan Source code.
2. Konfigurasi uji, termasuk Test Plan & Procedure,
perangkat testing yang akan digunakan, test
case dan hasil yang diharapkan.
39
• Pengujian perangkat lunak adalah elemen kritis dari jaminan
kualitas perangkat lunak dan merepresentasikan spesifikasi,
desain dan pengkodean.
• Tujuan pengujian perangkat lunak adalah mendesain serangkaian
tes yang secara sistematis mengungkap beberapa jenis kesalahan
yang berbeda dan melakukannya dalam waktu dan usaha yang
minimum.
• Manfaat pengujian perangkat lunak adalah untuk menunjukkan
bahwa fungsi perangkat lunak bekerja sesuai dengan spesifikasi
dan kebutuhan fungsi tercapai.
40
• Objektifitas Pengujian
1. Test case yang baik adalah yang mempunyai
probabilitas yg tinggi untuk menemukan error
yang tak ditemukan.
2. Pengujian merupakan suatu proses eksekusi
program yang ditujukan untuk menemukan error.
3. Uji yang sukses adalah yang dapat membuka
error yang tak ditemukan.
41
• Pendekatan pengujian blackbox dan whitebox.
• Pengujian Blackbox :
1. Berkaitan dengan pengujian pada interface PL.
2. Blackbox testing menyinggung ujicoba yang dilakukan pada interface
software.
3. Blackbox testing didesain untuk menemukan kesalahan.
4. Blackbox testing digunakan untuk mendemonstrasikan fungsi software
yang dioperasikan.
5. Blackbox testing sedikit memeriksa struktur logika internal software
42
• Test case yang dirancang harus mempunyai probabilitas yang
tinggi untuk menemukan sebuah error dalam waktu & effort yang
minimum.
• Dua metode pendekatan perancangan test case :
1. White Box Testing, berfokus pada struktur kontrol program. Semua
independen path dijalankan satu kali, melakukan semua loop, melakukan
struktur data internal untuk validitas.
2. Black Box Testing, berfokus pada kebutuhan fungsional software
dan memungkinkan perancang untuk memperoleh kondisi input
yang secara penuh menguji semua kebutuhan fungsional suatu
program.
43
• Pengujian Whitebox :
1. Didasarkan pada pemeriksaan detail prosedural.
2. Whitebox testing akan menghasilkan program yang 100%
benar.
3. Whitebox testing dilakukan pada alur logika yang penting.
4. Alur logika software di ujicoba dengan menyediakan kasus
ujicoba dengan melakukan sekumpulan kondisi atau
perulangan.
45
Unit Module Sub-system System Acceptance
Testing Testing Testing Testing Testing
User
Component Testing Integration Testing Testing

• System Testing
– Pengujian terhadap integrasi sub-system, yaitu
keterhubungan antar sub-system
– Pengujian terakhir sebelum sistem dipakai oleh user.

– Melibatkan pengujian dengan data dari pengguna sistem.
– Biasa dikenal sebagai “alpha test” (“beta test” untuk
software komersial, dimana pengujian dilakukan oleh
potensial customer)

Component testing
n Pengujian komponen-komponen program
n Biasanya dilakukan oleh component developer

(kecuali untuk system kritis)
Integration testing
n Pengujian kelompok komponen-komponen yang
terintegrasi untuk membentuk sub-system
ataupun system
n Dilakukan oleh tim penguji yang independent
n Pengujian berdasarkan spesifikasi sistem

Proses testing
n Deskripsi fase-fase utama dalam pengujian
Pelacakan Kebutuhan
n Semua kebutuhan user diuji secara individu
Item yg diuji
n Menspesifikasi komponen sistem yang diuji
Jadual Testing
Prosedur Pencatatan Hasil dan Prosedur
Kebutuhan akan Hardware dan Software
Kendala-kendala
n Mis: kekurangan staff, alat, waktu, biaya dll.

Spesifikasi Spesifikasi Perancangan Detail
Kebutuhan System System Perancangan
System
Acceptance Sub-System Module and
Integration
Test plan Integration Unit code and
Test plan
Test plan test
Acceptance System Sub-System

Service test Integration Integration
test test
Failures, Faults
: output yang tidak benar/tidak sesuai
ketika sistem dijalankan
Fault: kesalahan dalam source code yang
mungkin menimbulkan failure ketika code yg
fault tsb dijalankan
Failure Class Deskripsi
Transient Muncul untuk input tertentu
Permanent Muncul untuk semua input
Recoverable Sistem dapat memperbaiki secara otomatis
Unrecoverable Sistem tidak dapat memperbaiki secara otomatis
Non-corrupting Failure tidak merusak data
Corrupting Failure yang merusak sistem data
51
Shafira Adrizayani ST., MMSI - Testing
Contoh: Faults, Errors, and Failures
l Suppose node 6 should be
1: input A,B
X:= C*(A+2*B)
• Failure-less fault:
» executing path (1,2,4,5,7,8) will
2: A>0?
not reveal this fault because 6 is
not executed
» nor will executing path
3: C :=0 4: C := A*B (1,2,3,5,6,8) because C = 0
l Need to make sure proper test cases
are selected
5: B>0? • the definitions of C at nodes 3 and
4 both affect the use of C at node
6
6: X := C*(A+2*A) 7: X := A+B » executing path (1,2,4,5,6,8) will
reveal the failure,
but only if B = 0
8: output X
• Validasi (Product Oriented)
Apakah sistem yang dikembangkan sudah benar ?
Pengujian dimana sistem ketika diimplementasikan sesuai
dengan yang diharapkan atau tidak ?
• Verifikasi (Process Oriented)
Apakah sistem dikembangkan dengan cara yang benar ?
Pengujian apakah sistem sudah sesuai dengan spesifikasi ?
53
• Pengujian white box disebut pengujian glass box, structural, clear
box atau open box testing .
• Ujicoba whitebox adalah metode desain uji kasus menggunakan
struktur kontrol dari desain prosedural untuk memperoleh test case.
• Kasus uji yang dihasilkan pengembangan PL dengan
menggunakan metode pengujian whitebox adalah :
1. Menjamin seluruh independen paths dalam modul dilakukan
sebanyak satu kali.
2. Melakukan seluruh keputusan logika baik dari sisi true atau false.
3. Melakukan seluruh pengulangan sesuai batasannya
4. Menguji struktur data internal untuk validasinya.
54
• White Box Testing menggunakan 3 macam
tahapan testing
1. Unit Testing
2. Integration testing
3. Regression Testing

• Pembuatan testcase didasarkan pada alur logika
• Alur logika : cara dimana suatu bagian dari program
tertentu dieksekusi saat menjalankan program.
• Alur logika dapat direpresentasikan dengan
menggunakan flowgraph

1. Menguji setiap jalur independent
2. Menguji keputusan logic (true atau falsa)
3. Menguji Loops dan batasannya
4. Menguji Data Struktur internalnya

• Kesalahan logika, digunakan pada sintaks if dan pengulangan
dimana white box testing akan mendeteksi kondisi-kondisi
yang tidak sesuai dan mendeteksi kapan proses pengulangan
akan berhenti.
• Ketidaksesuaian asumsi, menampilkan asumsi yang tidak
sesuai dengan kenyataan untuk dianalisis dan diperbaiki
• Kesalahan ketik, mendeteksi bahasa pemrograman yang
bersifat case sensitive.

• Untuk perangkat lunak yang tergolong besar,
white box testing dianggap sebagai strategi
yang tergolong boros karena akan melibatkan
sumberdaya yang besar untuk melakukannya.

Contoh flow graph dari suatu kode program.
• Nodes (titik), mewakili pernyataan (atau

sub program) yang akan ditinjau saat
eksekusi program.
• Edges (anak panah), mewakili jalur alur
logika program untuk menghubungkan
satu pernyataan (atau sub program)
dengan yang lainnya.
• Branch nodes (titik cabang), titik-titik yang
mempunyai lebih dari satu anak panah
keluaran.
• Branch edges (anak panah cabang), anak
panah yang keluar dari suatu cabang
• Paths (jalur), jalur yang mungkin untuk
bergerak dari satu titik ke lainnya sejalan
dengan keberadaan arah anak panah.

Contoh cakupan pernyataan
• Pada contoh gambar flow graph di atas

terdapat 10 titik. Misal suatu jalur eksekusi
program melewati titik-titik A, B, D, H, K.
• Berarti ada 5 titik dari 10 titik yang
dikunjungi, maka cakupan pernyataan
sebesar 50 %.
• Karena satu titik pada flow graph dapat
merupakan kelompok dari beberapa
pernyataan, oleh karena itu tingkat
cakupan pernyataan yang sebenarnya
berbeda dengan tingkat cakupan titik
(nodes), tergantung dari cara
pendefinisian flow graph.

Contoh cakupan cabang
• Berdasarkan pada contoh gambar

flow graph di atas, terdapat 6
anak panah cabang. Misal suatu
jalur eksekusi program melawati
titik-titik A, B, D, H, K, maka jalur
tersebut meninjau 2
• dari 6 anak panah cabang yang
ada, jadi cakupannya sebesar 33
%.

Contoh cakupan jalur
• Berdasarkan contoh flow

graph, terdapat 4 jalur.
• Bila suatu eksekusi jalur
pada program melalui titik-
titik A, B, D, H, K, maka
eksekusi tersebut meninjau
1 dari 4 jalur yang ada, jadi
cakupannya sebesar 25 %.

Perbedaan antara cakupan pernyataan dan cakupan
jalur
Contoh program:
• If A then B
C
Dapat pula membuat cakupan
cabang 100 %, dengan
meninjau seluruh anak panah
cabang
tanpa harus meninjau semua
jalur yang ada (cakupan jalur
100 %).

Contoh anak panah cabang 100 % namun cakupan jalur tidak 100 %.
Contoh program:
If A then B else C
If D then E else F
• Dapat dilihat bahwa hanya

dibutuhkan 2 jalur untuk
mengunjungi semua anak
panah cabang, dari 4 jalur
yang ada pada flow graph.

• Pengujian basis path adalah teknik pengujian whitebox pertama
yang diusulkan Tom McCabe (1976).
• Basis path memungkinkan desainer test case mengukur
kompleksitas logis dari desain prosedural dan pengukuran ini
dijadikan pedoman dalam pendefinisian sekumpulan basis dari
jalur eksekusi.
• Yang termasuk basis path test :
1. Notasi Diagram Alir (Path Graph Notation)
2. Kompleksitas Siklomatik
3. Test Case
4. Matriks Grafik (Graph Matrices)
67
• Diagram alir
menggambarkan aliran
kontrol logika.
• Lingkaran (node), menggambarkan

satu atau lebih perintah prosedural.
• Tanda panah (edge),
menggambarkan aliran kontrol.
• Region, (R) daerah yang dibatasi
oleh edge dan node termasuk
daerah diluar grafik alir.
68
• Struktur kontrol program/Flowchart (Gambar 3)
69
Source Code dan FlowChart

Flow Graph

• Flowgraph Node (gambar 4)

73
• If a or b
Then procedure x
Else procedure y
Endif
• If a and b
Then procedure x
Then procedure y
Endif 74
• Simpul predikat (P) adalah simpul yang memiliki
lebih dari satu edges atau links (node yang memiliki
cabang)
75
• Kompleksitas siklomatis (Cyclomatic Complexity)
adalah metriks PL yang memberikan pengukuran
kuantitatif terhadap kompleksitas logis suatu
program.
• Nilai cyclomatic complexity mendefinisikan jumlah
independen path pada basis program.
• Jalur independen adalah jalur yang melalui program
yang mengintroduksi sedikitnya satu rangkaian
statement proses baru atau suatu kondisi baru.
76
• Jalur 1 : 1-11
• Jalur 2 : 1-2-3-4-5-10-1-11
• Jalur 3 : 1-2-3-6-8-9-10-1-11
• Jalur 4 : 1-2-3-6-7-9-10-1-11
– jalur independen = 4
• Jalur 5 : 1-2-3-4-5-10-1-2-3-
6-8-9-10-1-11 (tidak
termasuk dalam
independent path karena
merupakan kombinasi dari
path di atas)
• Edge = 11 P = 3
• Node = 9 R = 4 Testing & Implementasi Sistem
• Cara menghitung kompleksitas
– Jumlah region grafik alir sesuai dengan kompleksitas siklomatis.
– Kompleksitas siklomatis V(G) untuk grafik alir G ditentukan
sebagai V(G)= E-N+2
– Kompleksitas siklomatis V(G) untuk grafik alir G ditentukan
sebagai V(G)=P+1
• Dimana :
– E = Jumlah edge grafik alir
– N=Jumlah simpul (node) grafik alir
– P=Jumlah simpul predikat
• Simpul predikat adalah penggambaran suatu node yang memiliki satu
atau lebih inputan dan lebih dari satu output (node yang memiliki cabang)
78
Kompleksitas Siklomatis
• Pada gambar 3, kompleksitas siklomatis dapat

dihitung dengan menggunakan masing-
masing algoritma di atas :
1. Grafik alir mempunyai 4 region (R = 4)
2. V(G) = 11 edge – 9 simpul + 2 = 4
3. V(G) = 3 node yang diperkirakan + 1 = 4
4. Kompleksitas siklomatis dari grafik alir
adalah 4.

3. Test Case
• Metode pengujian jalur-jalur dasar dapat diterapkan untuk
perancangan prosedural atau kode program.
• Langkah - langkahnya :
1. Menggunakan perancangan atau atau kode sebagai sebuah
dasar, buatlah gambar grafik alir
2. Tentukan kompleksitas siklomatik dari aliran grafik yang
dihasilkan
3. Tentukan sebuah basis set dari jalur independen linier
4. Menyiapkan test case yang akan memaksa pelaksanaan setiap
jalur di basis basis set.

Do while records remain read record;
Calculate process;
If record field 1 = 0
Then process record;
Store in buffer; Increment counter;
Else if record field 2 = 0
Then reset counter;
Else process record; Store in file;
End if;
End if;
End do;
End
81
• PDL for test design
82
• Pertanyaan :
1. Region?
2. Edge dan node?
3. Simpul predikatnya?
4. Independent Path?
5. Cyclomatic
Complexity?
6. Matriks Graph?
84
Test Case untuk contoh di atas
Test case jalur 1 :
Harga (k)= input valid, dimana k< i yang dtetapkan di bawah
Harga (i) = -999 dimana 2 ≤ i ≤ 100
Hasil yang diharapkan : rata‐ rata yang benar berdasarkan nilai k dan total yang tepat.
Catatan : jalur 1 tidak dapat diuji sendirian karena harus diuji sebagai bagian dari pengujian jalur
4,5 dan 6
Test case jalur 2 :

Harga (i)=‐ 999
Hasil yang diharapakan : rata‐ rata ‐ 999, total yang lain pada nilai awal
Test case jalur3 :

Usahakan untuk memproses 101 nilai atau lebih
100 nilai pertama harus valid
Hasil yang diharapkan :sama seperti test case 1

Test case jalur 4 :
Nilai (i)= input valid dimana i < 100
Nilai (k)< minimum, dimana k< i
Hasil yang diharapkan : rata-rata yang benar berdasarkan nila-nilai k dan total yang sesuai
Test case jalur 5 :

Nilai (i) = input valid dimana i< 100
Nilai (k) > maksimum, dimana k ≤ i
Hasil yang diharapkan : rata-rata yang benar berdasarkan nilai-nilai n dan total yang tepat
Test case jalur 6 :

Nilai (i) = input valid dimana i < 100
Hasil yang diharapkan : rata-rata yang benar berdasarkan nilai-nilai n dan total yang tepat.

• Independent Path
1, 2, 3, 8, 9
1, 2, 3, 4, 6, 7, 2
1, 2, 3, 4, 5, 7, 2
1, 2, 3, 4, 6, 7, 2, 8, 9
Test cases harus ditentukan
sehingga semua path tsb
tereksekusi.
Carilah Region, Jumlah
Edge,Nodes dan Kompleksitas
Siklomatis, Simpul Predikat?
Buat Matriks Graph.?

88
1. Berapa jumlah cyclomatic complexity-nya ?
2. Jalur yang menyatakan bahwa properti tersedia, calon pengguna

memiliki cukup uang dan bermaksud untuk membeli properti
tersebut, ditunjukkan pada independen path yang mana ?
3. Jalur yang menyatakan bahwa properti tersedia tetapi calon

pengguna tidak memiliki cukup uang, ditunjukkan pada
independen path yang mana ?
89
• Nama file : Tugas K(n)(NamaKelompok)(Kelas).doc /.ppt
• Subjek email : Tugas K(n) (NamaKelompok)(Kelas)
• kirim : shafira_77@staff.gunadarma.ac.id
• Paling lambat : Jumat, 27 Oktober 2023 jam 24:00

• Matriks grafik (Graph Matrix) adalah matriks bujur sangkar yang ukurannya sama
dengan jumlah simpul/node pada grafik alir.
• Graph matrix otomatis menggenerasi flowgraph dan mendeterminasi aliran dasar proses.
• Graph matrix :
1. Bujursangkar dengan sisi merepresentasikan simpul.
2. Baris dan kolom merepresentasikan simpul.
3. Nilai 1 merepresentasikan hubungan antar simpul.

• Flowgraph 1

Flowgraph 1
• Dengan menambahkan sebuah link weight pada masing‐ masing entri
matriks, maka matriks grafis dapat menjadi alat yang sangat kuat untuk
mengevaluasi struktur kontrol program selama pengujian
• Link weight memberikan informasi tambahan mengenai aliran kontrol
• Dalam bentuk sederhana, link weight adalah 1 (ada hubungan), atau 0
(tidak ada hubungan).

Contoh Soal 2
Flowgraph 2 Connection Matrix

1. Condition Testing bertujuan untuk mengeksekusi semua kondisi
logik dari sebuah modul program.
– Pengujian kondisi (Condition Testing) adalah sebuah metode desain
test case yang menggunakan kondisi logis yang ada pada suatu modul
program.
– Metode pengujian kondisi berfokus pada pengujian setiap kondisi yang
ada pada program.
– Keuntungan :
1. Memperkirakan pengujian berdasarkan kondisi adalah hal yang simpel.
2. Cakupan pengujian dapat mengarahkan pada penambahan kasus uji
untuk semua program.

• Mendefinisikan :
1. Relational Expression (E1 op E2) : E1 dan E2
adalah arithmetic expression
2. Simple Condition : Variabel boolean atau relation
expression dan diawali dengan operator NOT
3. Compound Condition : Dua atau lebih simple
conditions, operator boolean dan tanda kurung
4. Boolean Expression : Kondisi tanpa relational
expression
• Strategi yang termasuk condition testing :
1. Branch Testing
2. Domain Testing
3. Branch dan Relational Operator Testing
• Kegunaan uji coba kondisi adalah untuk mendeteksi, baik
kesalahan kondisi dalam suatu program tetapi juga
kesalahan lain dalam program.
• Tujuan pengujian kondisi adalah mendeteksi tidak hanya
kesalahan di dalam program tetapi juga kesalahan lain
dari program.
• Data Flow Testing adalah metode yang
menyeleksi jalur test program menurut lokasi
pendefinisian dan menggunakan variabel
program.
• Data flow Testing, setiap statement dalam
program diasumsikan diisi dengan angka yang
unik dan tidak ada fungsi yang mengubahnya.

• Loop adalah dasar dari banyak algoritma.
• Pengujian Loop merupakan teknik pengujian white box
yang secara ekslusif berfokus pada validitas konstruksi
loop.

Pengujian Perulangan
• Loop sederhana.
– Himpunan berikut harus diaplikasikan pada loop
sederhana, dimann adalahjumlah maksimum yang
diijinkan melewati loop tersebut.
1. Abaikan keselurhan loop.
2. Hanya satu yang melewati loop
3. Dua yang melewati loop
4. m melewati loop dimana m<n
5. n – 1,n, n +1 melewati melewati loop.

• Loop tersarang.
– Bila kita ingin memperluas pendekatan pengujian bagi loop sederhana
ke loop tersarang, jumlah pengujian mungkin akan berkembang secara
geometris sesuai tingkat pertambahan persarangan sehingga sejumlah
pengujian menjadi tidak praktis. Beizer mengusulkan suatu
pendekatan yang membantu mengurangi jumlah pengujian :
1. Mulai pada loop yang paling dalam. Atur sema loop ke nilai minimum.
2. Lakukan pengujian loop sederhana untuk loop yang paling dalam
sementara menjaga loop yang paling luar pada nilai parameter iterasi
minimumnya (misal pencacah loop). Tambahkan pengujian yang lain
untuk nilai out of range atau nilaiyang tidak diperbolehkan
3. Bekerja menuju ke luar, dengan melakukan pengujian untuk loop
selanjutnya, tetapi menjaga semua loop bagian luar yang lain pada nilai
minimumnya dan loop tersarang lainnya pada harga “tertentu”
4. Lanjutkan sampai semua loop telah teruji.

• Loop terangkai.
• Loop terangkai dapat diuji dengan menggunakan
pendekatan yang ditentukan untuk loop sederhana bila
masing‐ masing dari loop itu independen terhadap yang
lain. Tetapi bila dua loop dirangkai dan pencacah loop
untuk loop1 digunakan sebagai harga awal untuk loop 2
kemudian loop tersebut menjadi tidak independen, maka
pendekatan diaplikasikan ke loop tersarang
direkomendasi

Loop tidak terstruktur. Kapan saja
memungkinkan kelas loop ini harus didesain lagi
untuk mencerminkan penggunaan konsepsi
pemrograman terstruktur


Materi 4OK1

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Materi 4OK1

Diunggah oleh

Hak Cipta:

Format Tersedia

Fakultas Ilmu Komputer dan Teknologi Informasi

Jurusan Sistem Informasi

Shafira Adrizayani ST., MMSI - 6

Shafira Adrizayani ST., MMSI - 21

Shafira Adrizayani ST., MMSI - 23

Shafira Adrizayani ST., MMSI - 27

Shafira Adrizayani ST., MMSI - 28

Shafira Adrizayani ST., MMSI - 29

Shafira Adrizayani ST., MMSI - 30

Shafira Adrizayani ST., MMSI - 32

Shafira Adrizayani ST., MMSI - 34

Shafira Adrizayani ST., MMSI - 35

Shafira Adrizayani ST., MMSI - 46

– Pengujian terakhir sebelum sistem dipakai oleh user.

Shafira Adrizayani ST., MMSI - 47

n Biasanya dilakukan oleh component developer

n Pengujian berdasarkan spesifikasi sistem

Shafira Adrizayani ST., MMSI - 48

Shafira Adrizayani ST., MMSI - 49

Acceptance System Sub-System

Shafira Adrizayani ST., MMSI - 55

Shafira Adrizayani ST., MMSI - 56

Shafira Adrizayani ST., MMSI - 57

Shafira Adrizayani ST., MMSI - 58

Shafira Adrizayani ST., MMSI - 59

• Nodes (titik), mewakili pernyataan (atau

Shafira Adrizayani ST., MMSI - 61

• Pada contoh gambar flow graph di atas

Shafira Adrizayani ST., MMSI - 62

• Berdasarkan pada contoh gambar

Shafira Adrizayani ST., MMSI - 63

• Berdasarkan contoh flow

Shafira Adrizayani ST., MMSI - 64

Shafira Adrizayani ST., MMSI - 65

• Dapat dilihat bahwa hanya

Shafira Adrizayani ST., MMSI - 66

• Lingkaran (node), menggambarkan

Shafira Adrizayani ST., MMSI - 70

Shafira Adrizayani ST., MMSI - 71

Shafira Adrizayani ST., MMSI - 72

• Pada gambar 3, kompleksitas siklomatis dapat

Shafira Adrizayani ST., MMSI - 79

Shafira Adrizayani ST., MMSI - 80

Test case jalur 2 :

Test case jalur3 :

Shafira Adrizayani ST., MMSI - 85

Test case jalur 5 :

Test case jalur 6 :

Shafira Adrizayani ST., MMSI - 86

Shafira Adrizayani ST., MMSI - 87

2. Jalur yang menyatakan bahwa properti tersedia, calon pengguna

3. Jalur yang menyatakan bahwa properti tersedia tetapi calon

Shafira Adrizayani ST., MMSI - 90

Shafira Adrizayani ST., MMSI - 91

Shafira Adrizayani ST., MMSI - 92

Shafira Adrizayani ST., MMSI - 93

Flowgraph 2 Connection Matrix

Shafira Adrizayani ST., MMSI - 94

Shafira Adrizayani ST., MMSI - 95

Shafira Adrizayani ST., MMSI - 98

Shafira Adrizayani ST., MMSI - 99

Shafira Adrizayani ST., MMSI - 100

Shafira Adrizayani ST., MMSI - 101

Shafira Adrizayani ST., MMSI - 102