Strategi Pengujian PL

Testing dan Implementasi Sistem
Kontrak R i
Review Manajemen Strategi &
Strategi & Implementasi
l Suplement
l
Rekayasa
Perkuliahan Perangkat Lunak Kualitas Teknik Testing Sistem
Strategi Testing
Strategi Testing
Dr. Karmilasari
Jurusan : S1 Sistem Informasi 1

Kontrak R i
l Suplement
l
Rekayasa
– Pengujian
Pengujian PL dilakukan untuk tujuan menemukan kesalahan
PL dilakukan untuk tujuan menemukan kesalahan
yang dibuat secara tidak sengaja saat PL tersebut dirancang
dan dibangun
– Strategi pengujian PL menyediakan petunjuk yang menjelaskan
gi Testting
langkah‐langkah yang harus dilaksanakan sebagai bagian dari
pengujian, kapan langkah‐langkah ini direncanakan dan
kemudian dilakukan dan berapa banyak saha, waktu serta
sumber daya yang harus disertakan dalam pengujian tersebut
sumber daya yang harus disertakan dalam pengujian tersebut.
Strate
– Strategi pengujian harus menyertakan : perencanaan
pengujian perancangan kasus pengujian pelakasanaan
pengujian, perancangan kasus pengujian, pelakasanaan
S
pengujian dan evaluasi serta pengumpulan data hasil
pengujian.

Kontrak R i
l Suplement
l
Rekayasa
Pola baku untuk pengujian PL memiliki karakteristik umum :

Pola baku untuk pengujian PL memiliki karakteristik umum :
– Pengujian yang efektif harus dilakukan melalui tinjauan teknis yang efektif
pula, dengan demikian banyak kesalahan akan dihilangkan sebelum
pengujian dilakukan
gi Testting
– Pengujian dimulai pada tingkat komponen dan bekerja ke arah “luar”
menuju integrasi sistem berbasis komputer secara menyeluruh
j g p y
– Teknik pengujian yang berbeda tepat untuk pendekatan rekayawan PL yang
berbeda pula dan waktu yang berbeda
– Pengujian dilakukan oleh pengembang PL (untuk proyek besar) dan
dl k k l h b ( k kb )d
Strate
kelompok penguji independen
– Pengujian dan pelacakan kesalahan (debuging)
g j p ( g g) adalah aktivitas yang
y g
S
berbeda, namun debuging harus terakomodasi dalam setiap strategi
pengujian.

Kontrak R i
l Suplement
l
Rekayasa
– Pengujian
Pengujian PL adalah salah satu elemen dari topik yang lebih
PL adalah salah satu elemen dari topik yang lebih
luas yang dikenal dengan Verifikasi dan Validasi (V & V)
– Verifikasi merujuk pada sekumpulan tugas yang memastikan
j p p g y g
bahwa PL benar menerapkan fungsi yang telah ditentukan
gi Testting
– Validasi merujuk ke sekumpulan tugas yang berbeda yang
memastikan bahwa PL yang telah dibagnun dapat dilacak
berdasar persyarakatan pelanggan.
Strate
– Verifikasi dan validasi meliputi banyak kegiatan jaminan kualitas
PL, yaitu : tinjauan teknis, audit konfigurasi dan kualitas,
S
monitoring kinerja simulasi pengujian pengembangan

monitoring kinerja, simulasi, pengujian pengembangan,
pengujian kegunaan, pengujian kualifikasi, uji penerimaan dan
uji instalasi.
uji instalasi.

Kontrak R i
l Suplement
l
Rekayasa
Apa yang ditunjukan pada saat Pengujian ?

Apa yang ditunjukan pada saat Pengujian ?
Kesalahan
Pemenuhan Kebutuhan
gi Testting
Kinerja
Strate
Indikasi Kualitas
S

Kontrak R i
l Suplement
l
Rekayasa
– Siapa yang melakukan Pengujian PL ?
Siapa yang melakukan Pengujian PL ?
Strategi Testting
Pengembang Penguji Independent

Memahami sistem, namun Harus belajar mengenai sistem,
S
pada saat pengujian harus adil

adil, namun saat ditemukan ketidakbenaran
Karena berpatokan pada penyebaran PL akan menghentikannya, karena
berpatokan pada kualitas

Kontrak R i
l Suplement
l
Rekayasa
Strategi Pengujian
–Strategi Pengujian
unit test integration
test
Strate
S gi Testting
system validation
test test

Kontrak R i
l Suplement
l
Rekayasa
Strategi Pengujian
Strategi Pengujian
– Mulailah dari pengujian dengan lingkup kecil kemudian
bergerak ke lingkup yang lebih besar
bergerak ke lingkup yang lebih besar
– Untuk PL konvensional :
gi Testting
• Fokus awal pada pengujian modu/komponen
Fokus awal pada pengujian modu/komponen
• Dilanjutkan pada pengujian integrasi
– Untuk PL berorientasi objek
Untuk PL berorientasi objek
Strate
• Pengujian lingkup kecil akan berubah dari modul individual (sudut
pandang konvensional) menjadi kelas OO yang meliputi atribut dan
S
operasi yang berimplikasi pada komunikasi dan kolaborasi
i b i lik i d k ik i d k l b i

Kontrak R i
l Suplement
l
Rekayasa
I St t i P
Isu Strategi Pengujian
ji
• Tahapan pengujian harus diungkapkan secara eksplisit
• Memahami user sebagai pengguna PL dan membangun profile
gi Testting
untuk setiap kategori user
• Membuat perencanaan pengujian yang dapat mengakomodir
b d k d
“siklus cepat pengujian”
• Menggunakan tinjauan teknis formal yang efektif sebagai filter
M k ti j t k i f l f ktif b i filt
Strate
awal pengujjian
S
• Mengelola tinjauan teknis formal untuk menilai strategi dan
Mengelola tinjauan teknis formal untuk menilai strategi dan
kasus pengujian
• Membangun pendekatan berkelanjutan untuk pengujian
Membangun pendekatan berkelanjutan untuk pengujian
proses
Kontrak R i
l Suplement
l
Rekayasa
Pengujian Unit/Unit Testing

gi Testting
Modul yang
akan diuji
Hasil
Strate
Rekayasawan PL
Kasus Pengujian
g j
S

Kontrak R i
l Suplement
l
Rekayasa

Modul yang
akan diuji
gi Testting
interface
local data structures
boundaryy conditions
Strate
independent paths
error handling paths
S
Kasu Pengujian/ / Test Case

Kontrak R i
l Suplement
l
Rekayasa
Lingkungan Pengujian Unit

Lingkungan Pengujian Unit
driver
interface
gi Testting
local data structures

Module boundary conditions
independent paths
Strate
error handling paths

stub stub
S
Kasu Pengujian
Hasil
Kontrak R i
l Suplement
l
Rekayasa
St t i P
Strategi Pengujian Integrasi
ji I t i
Opsi : ‐ Pendekatan “big bang”
‐ Strategi pengembangan inkremental
Strate
S gi Testting

Kontrak R i
l Suplement
l
Rekayasa
Integrasi TOP DOWN

Integrasi TOP‐DOWN
A Top modul diuji dengan stub

gi Testting
B F G
Stub diganti
g satu setiap
p waktu,, dengan
g “depth
p first”
Strate
C
Modul baru diintegrasikan, beberapa subset uji
S
dijalankan kembali
D E

Kontrak R i
l Suplement
l
Rekayasa
Integrasi BOTTOM UP
Integrasi BOTTOM‐UP
A
gi Testting
B F G
Driver diganti satu setiap waktu, dengan “depth first”

C
Strate
Modul pekerja dikelompokan untuk dibangun

dan diintegrasikan
S
D E
cluster

Kontrak R i
l Suplement
l
Rekayasa
Pengujian SANDWICH
Pengujian SANDWICH
A
Top modul diujui dengan stub
gi Testting
B F G
Strate
C
S
Modul pekerja dikelompokan untuk

D E dibangun dan diintegrasikan
cluster
Kontrak R i
l Suplement
l
Rekayasa
Pengujian berorientasi Objek

Pengujian berorientasi Objek
• Tujuan pengujian tetap yaitu menemukan kesalahan dalam
selang waktu yang realistik
l kt li tik
gi Testting
• Dimulai dengan mengevaluasi kebenaran dan konsistensi
model OOA dan OOD
model OOA dan OOD
• Melakukan perubahan strategi uji
– Konsep
Konsep ‘unit’
unit setara dengan encapsulasi
setara dengan encapsulasi
Strate
– Fokus integrasi pada kelas dan persilangan eksekusi “thread” atau
dalam konteks penggunaan skenario
S
– Validasi menggunakan metode konvensional black box
• Rancangan kasus uji/test case digambarkan dengan metode
k
konvensional tetapi melingkupi fitur spesial.
i l i li k i fi i l
Kontrak R i
l Suplement
l
Rekayasa
Perluasan Sudut Pandang Pengujian
(Berorientasi Objek)
• Kesalahan pendefinisian atribut kelas yang ditemukan pada tahap analisis
akan menghilangkan pengaruh yang dapat muncul.
gi Testting
• Contoh : Sebuah kelas dengan sejumlah atribut didefinisikan pada tahap
g j p p
analisis. Sebuah atribut yang tidak berhubungan dan dua operasi yang
memanipulasi atribut tersebut terdefinisi.
• – Jika atribut yang tidak berhubungan dihilangkan pada tahap analisis,
Jika atribut yang tidak berhubungan dihilangkan pada tahap analisis
Strate
dapat mengurangi beberapa masalah dan usaha sbb :
Pembuatan subclass yang khusus untuk mengakomodasi atribut tersebut
S
Pembuatan relasi antar kelas yang salah
Kelakuan dari sistem dapat menjadi tidak tepat

Kontrak R i
l Suplement
l
Rekayasa
(Berorientasi Objek)
• Jika kesalahan tidak ditemukan, masalah yang dapat muncul pada tahap
perancangan :
gi Testting
– penempatan kelas yang tidak tepat pada subsistem
– perancangan kerja yang tidak perlu
– model messaging (message connection) yang tidak tepat
• Jika kesalahan tetap ada sampai pada tahap pengkodean
Jika kesalahan tetap ada sampai pada tahap pengkodean akan
akan
Strate
menghabiskan banyak waktu dan usaha untuk
– membuat kode dari atribut dan dua operasi yang tidak diperlukan,
S
– membuat message untuk komunikasi antar objek
membuat message untuk komunikasi antar objek

Kontrak R i
l Suplement
l
Rekayasa
Pengujian Model OOA dan OOD

Pengujian Model OOA dan OOD
Langkah :
• Lakukan pemeriksaan silang antara model CRC dengan model object
relationship untuk memastikan semua kolaborasi yang dinyatakan dalam
gi Testting
OOA direfleksikan dengan tepat dalam kedua model
• Periksa deskripsi dari setiap CRC index card untuk menentukan apakah
Periksa deskripsi dari setiap CRC index card untuk menentukan apakah
suatu tanggung jawab merupakan bagian dari definisi collaborator
• Periksa hubungan balik untuk memastikan bahwa setiap collaborator
menerima permintaan dari sumber yang tepat.
d b
Strate
• Periksa hubungan balik untuk memastikan apakah kelas lain diperlukan
sebagai collaborator
g
S
• Tentukan apakah beberapa tanggung jawab dapat digabungkan menjadi
tanggung jawab
• Ke lima langkah di atas diterapkan untuk setiap kelas dan setiap evolusi
li l k h di di k k i k l d i l i
dari model OOA
Kontrak R i
l Suplement
l
Rekayasa
Strategi Pengujian Berorientasi Objek (OOT)

Strategi Pengujian Berorientasi Objek (OOT)
• Strategi : pengujian semua unit program terkecil, pengujian
integritas dari modul dan pengujian keseluruhan sistem
integritas dari modul, dan pengujian keseluruhan sistem
• Pengujian Unit dalam konteks berorientasi objek
gi Testting
– Unit terkecil
Unit terkecil ‐>> Kelas atau objek
Kelas atau objek
– Setiap operasi yang diturunkan pada kelas turunan harus diperiksa
• Pengujian Integritas dalam konteks berorientasi objek
Strate
– Thread‐based testing , mengintegrasikan sekumpulan kelas suatu input atau
kejadian dalam sistem. Setiap thread diintegrasikan dan diuji secara individual.
• Pengujian regresi diterapkan untuk memastikan tidak ada efek samping yang
S
muncul.

Kontrak R i
l Suplement
l
Rekayasa
Strategi Pengujian Untuk Aplikasi Web

Strategi Pengujian Untuk Aplikasi Web
1. Model isi untuk aplikasi web ditinjau untuk menemukan kesalahan
2. Model antarmuka ditinjau untuk memastikan bahwa semua kasus yang digunakan dapat
j y g g p
diakomodasi
gi Testting
3. Model perancangan untuk aplikasi web ditinjau untuk menemukan kesalahan navigasi
4. Antarmuka pengguna diuji untuk menemmukan kesalahan dalam presentasi dan/atau
mekanik navigasi
5. Setiap komponen fungsional diterapkan pengujian –unit
6. Navigasi seluruh arsitektur diuji
Strate
7. Aplikasi web diimplementasikan dalam berbagai konfigurasi lingkungan yng bereda dan diuji
kompatibilitasnya dengan setiap konfigurasi
8. Uji keamanan dilakukan dalam upaya mengeksploitasi kelemahan‐kelemahan dalam aplikasi
S
web atau dalam lingkungannya
9. Kinerja pengujian dikontrol
10. Aplikasi web diuji oleh populasi yang dikendalikan dan dipantau oleh pengguna akhir . Hasil
i t ki
interaksi mereka dengan sistem dievaluasi, yakni dalam hal kesalahan isi dan navigasi,
k d it di l i k i d l h l k l h i i d i i
kegunaan,kompatibilitas, dan keandalan serta kinerja aplikasi web
Kontrak R i
l Suplement
l
Rekayasa
Pengujian Validasi
Pengujian Validasi
– Pengujian validasi dimulai di titik puncak pengujian integrasi
ketika komponen individu telah dieksekusi PL sudah benar
ketika komponen individu telah dieksekusi, PL sudah benar‐
benar dirakit sebagai sebuah paket dan kesalahan antarmuka
gi Testting
p
telah ditemukan dan diperbaiki.
– Pada level validasi atau sistem, perbedaan antara PL
konvensional, PL berorientasi objek dan aplikasi web
Strate
menghilang
– Fokus pengujian pada tindakan pengguna yang terlihat dan
S
output dari sistem yang dikenali pengguna
– Validasi berhasil jika PL berfungsi dengan cara yang diharapkan
oleh pengguna
l h
Kontrak R i
l Suplement
l
Rekayasa
Kriteria Pengujian Validasi

Kriteria Pengujian Validasi
Rencana pengujian menguraikan :
– Kelas‐kelas pengujian yang akan dilakukan
p g j y g
– Prosedur pengujian yang mendefinisikan kasus pengujian tertentu yang
gi Testting
dirancang untuk memastikan bahwa semua fungsional memenuhi
persyaratan yang diminta karakteristik tercapai pendokumentasian benar
persyaratan yang diminta, karakteristik tercapai, pendokumentasian benar,
dan kegunaan dan persyaratan lainnya dipenuhi (misal : transportability,
kompatibilitas, perbaikan kesalahan, pemeliharaan)
Strate
Setelah setiap kasus pengujian validasi ditemukan, ditemukan salah satu dari
kondisi berikut :
kondisi berikut :
S
– Karakteristik fungsi atau kinerja sesuai dengan spesifikasi dan diterima
– Penyimpangan ditemukan pada tahap ini

Kontrak R i
l Suplement
l
Rekayasa
Pengujian Tingkat Tinggi

– Pengujian Validasi, fokus pada kebutuhan PL, akan dilihat kesesuaian antara
rencana (kelas pengujian dan prosedur) dengan kondisi akhir yang dihasilkan
(sesuai atau menyimpang)
gi Testting
– Pengujian Sistem, fokus pada integrasi sistem, untuk memverifikasi bahwa
semua elemen sistem telah terintegrasi dengan baik dan menjalankan
semua elemen sistem telah terintegrasi dengan baik dan menjalankan
fungsinya.
– Pengujian Alpha/Bheta, fokus pada penggunaan oleh pengguna
Strate
• Pengujian Alpha, dilakukan di sisi pengembang oleh sekelompok perwakilan dari
pengguna akhir. PL digunakan dalam kondisi natural dimana pengembang
“melihat dengan kacamata” pengguna dan mencatat kesalahan dan masalah
S
penggunaan. Pengujian alpha dilakukan dalam lingkungan yang dikendalikan
• Pengujian Bheta, dilakukan oleh satu atau lebih pengguna akhir. Pengujian ini
adalah "aplikasi hidup” dari PL dalam sebuah lingkungan yang tidak dapat
dikendalikan oleh pengembang
Kontrak R i
l Suplement
l
Rekayasa

– Pengujian Pemulihan/Recovery, pengujian yang memaksa PL untuk gagal
dalam berbagai cara dan memverifikasi bahwa pemulihan dilakukan dengan
benar. Jika pemulihan dilakukan dengan otomatis, maka inisialisasi
gi Testting
kembali,mekanisme checkpointing, pemulihan data dan restart dievaluasi
untuk mengethui apakah itu semua berjalan benar. Jika pemulihan
g p j p
membutuhkan intervensi manusia, maka rata‐rata waktu untuk perbaikan
dievaluasi untuk menentukan apakah masih dalam batas yang dapat
diterima
Strate
– Pengujian Keamanan/Security, memverifikasi mekanisme perlindungan
yang dibangun ke dalam sistem untuk melindunginya dari penetrasi yang
S
tidak benar.
d kb

Kontrak R i
l Suplement
l
Rekayasa

– Pengujian Tekanan/Stress, menajlankan sistem dengan cara yang meminta
sumber daya dalam jumlah, frekuensi atau volume abnormal, misal :
• Pengujian khusus yang dirancang untuk menghasilkan sepuluh sela per detik, ketika rata‐
ratanya adalah satu atau dua sela
gi Testting
• Kecepatan indput data dapat ditingkatkan untuk menentukan bagaiman fungsi‐fungsi input
akan menanggapi
• Kasus pengujian yang membutuhkan memori maksimum atau sumberd daya lain untuk
dijalankan
• Kasus pengujian yang dapat menyebabkan tabrakan di dalam sistem operasi virtual yang
d b bk b k d d l l
Strate
dirancang
• Kasus pengujianyang dapat menyebabkan junting yang berlebihan atas data yang ada
S
pada disk yang dapat dibuatnya

pada disk yang dapat dibuatnya.
– Pengujian Kinerja/Performance, dilakukan untuk menguji kinerja run‐time
dari PL dalam konteks sebagai sistem yang terintegrasi. Pengujian dilakukan
di l h l k h d l
di seluruh langkah dalam proses. Sering pula digabungkan dengan pengujian
S i l di b k d ji
stress
Kontrak R i
l Suplement
l
Rekayasa

– Pengujian Deployment, disebut juga pengujian konfigurasi. Untuk menguji
PL dalam berbagai lingkungan dimana PL tersebut dioperasikan. Menguji
pula semua prosedur instalasi (instaler) yang akan digunakan oleh
gi Testting
pelanggan) dan semua dokumentasi yang akan diperkenalkan pada
p gg
pengguna akhir
Strate
S

Kontrak R i
l Suplement
l
Rekayasa
DEBUGGING / Pelacakan Kesalahan

DEBUGGING / Pelacakan Kesalahan
– Debugging terjadi sebagai akibat pengujian yang berhasil (pada saat kasus
p g j
pengujian menangkap kesalahan), dimana debugging merupakan proses
g p ), gg g p p
yang menghasilkan penghapusan kesalahan.
gi Testting
test cases
Strate
new test results

regression cases
S
tests suspected
causes
corrections
Debugging
identified
causes
Kontrak R i
l Suplement
l
Rekayasa
– Upaya Debugging
Upaya Debugging
Mebutuhkan waktu untuk

gi Testting
mendiagnosa gejala dan

menyimpulkan penyebabnya
Membutuhkan waktu untuk
memperbaiki kesalahan dan
melakukan uji regresi
Strate
S

Kontrak R i
l Suplement
l
Rekayasa
– Gejala dan Penyebabnya
Gejala dan Penyebabnya
•Gejala dan penyebabnya mungkin secara geografis
jauh. Gejala dapatmuncul di salah satu bagian
program,tapi penyebabnya mungkin terletak di tempat
jauh
gi Testting
• Gejala mungkin hilang sementara saat kesalahan lain

dikoreksi
•Gejala ini sebenarnya disebabkan oleh non error,
misal ketidakakuratan
• Gejala dapat disebabkanoleh kesalahan manusia
Strate
yang tidak mudah dilacak

• Gejala mungkin akibat masalah waktudaripada
masalah pemrosesan
S
Gejala •Gejala dapat berselang,

berselang terutam untuk sistem
Penyebabtertanam
•Gejala dikarenakan penyebab didistribusikan ke
sejumlah tugas berjalan pada prosesor ang berbeda

Kontrak R i
l Suplement
l
Rekayasa
– Strategi Debugging
Strategi Debugging
1. Brute force, filosofinya “Biarkan komputer menemukan
kesalahan”, maka akan sampah memori diambil, bekas run
kesalahan maka akan sampah memori diambil bekas run
time dipanggi dan program sarat dengan laporan keluaran.
gi Testting
2 Backtracking, umumnya digunakan untuk program kecil. Mulai
2. Backtracking umumnya digunakan untuk program kecil Mulai
dari gejala, kode program dilacak ke belakang/manual sampai
penyebabnya diketahui.
Strate
3. Menyingkirkan penyebab/cause elimination, ditunjukan oleh
induksi atau deduksi dan memperkenalkan konsep partisi
S
biner. Data yang terkait dengan terjadinya kesalahan dikelola
untuk diisolasi penyebab potensial.

Kontrak R i
l Suplement
l
Rekayasa
– Memperbaiki Kesalahan
Memperbaiki Kesalahan
Pertanyaan dasar sebelum membuat koreksi menghilangkan
penyebab kesalahan :
penyebab kesalahan :
1. Apakah penyebab bug dibuat ulang di bagian lain dari
gi Testting
program ini ?
program ini ?
2. Apakah bug selanjutnya apat terjadi akibat perbaikan yang
sedang dibuat ?
sedang dibuat ?
Strate
3. Apakah yang bisa dilakukan untuk mencegah bug ini di tempat
p
pertama ?
S

Kontrak R i
l Suplement
l
Rekayasa
Pertanyaan
Dan
gi Testting
Diskusi
Strate
......
S

Strategi Pengujian PL

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

Strategi Pengujian PL

Diunggah oleh

Hak Cipta:

Format Tersedia

Testing dan Implementasi Sistem

Jurusan : S1 Sistem Informasi 1

Jurusan : S1 Sistem Informasi 2

Pola baku untuk pengujian PL memiliki karakteristik umum :

Jurusan : S1 Sistem Informasi 3

monitoring kinerja simulasi pengujian pengembangan

Jurusan : S1 Sistem Informasi 4

Apa yang ditunjukan pada saat Pengujian ?

Jurusan : S1 Sistem Informasi 5

Pengembang Penguji Independent

pada saat pengujian harus adil

Jurusan : S1 Sistem Informasi 6

Jurusan : S1 Sistem Informasi 7

Jurusan : S1 Sistem Informasi 8

Pengujian Unit/Unit Testing

Jurusan : S1 Sistem Informasi 10

Pengujian Unit/Unit Testing

Kasu Pengujian/ / Test Case

Lingkungan Pengujian Unit

local data structures

error handling paths

Jurusan : S1 Sistem Informasi 13

Integrasi TOP DOWN

A Top modul diuji dengan stub

Jurusan : S1 Sistem Informasi 14

Driver diganti satu setiap waktu, dengan “depth first”

Modul pekerja dikelompokan untuk dibangun

Jurusan : S1 Sistem Informasi 15

Modul pekerja dikelompokan untuk

Pengujian berorientasi Objek

Jurusan : S1 Sistem Informasi 18

Jurusan : S1 Sistem Informasi 19

Pengujian Model OOA dan OOD

Strategi Pengujian Berorientasi Objek (OOT)

Jurusan : S1 Sistem Informasi 21

Strategi Pengujian Untuk Aplikasi Web

Kriteria Pengujian Validasi

Jurusan : S1 Sistem Informasi 24

Pengujian Tingkat Tinggi

Pengujian Tingkat Tinggi

Jurusan : S1 Sistem Informasi 26

Pengujian Tingkat Tinggi

pada disk yang dapat dibuatnya

Pengujian Tingkat Tinggi

Jurusan : S1 Sistem Informasi 28

DEBUGGING / Pelacakan Kesalahan

new test results

Mebutuhkan waktu untuk

mendiagnosa gejala dan

Jurusan : S1 Sistem Informasi 30

• Gejala mungkin hilang sementara saat kesalahan lain

yang tidak mudah dilacak

Gejala •Gejala dapat berselang,

Jurusan : S1 Sistem Informasi 31

Jurusan : S1 Sistem Informasi 32

Jurusan : S1 Sistem Informasi 33

Jurusan : S1 Sistem Informasi 34

Anda mungkin juga menyukai