Transcript Testing dan Implementasi STMIK RAHARJA Six Delivered by : Oleh Sholeh, SKom., MMSi.

Testing dan Implementasi
STMIK RAHARJA
Six
2008
Delivered by : Oleh Sholeh, SKom., MMSi.
1
Seberapa baik sistem yang
sudah dibangun ?

Dua Aspek yang dipertimbangkan:
• Apakah implementasi sudah sesuai dengan spesifikasi ?
• Apakah spesifikasi sesuai dengan kebutuhan user ?

Validasi
• “Apakah sistem yang dikembangkan sudah benar?”
• Pengujian dimana sistem ketika diimplementasikan sesuai
dengan yang iharapkan

Verifikasi
• “Apakah sistem dikembangkan dengan cara yang benar ?”
• Pengujian apakah sistem sudah sesuai dengan spesifikasi
2
Proses Testing
Unit testing

Pengujian masing-masing unit komponen program
untuk meyakinkan bhw sudah beroperasi secara
benar
Module Testing

Pengujian terhadap koleksi unit-unit komponen
yang saling berhubungan.
Sub-system Testing

Pengujian terhadap koleksi module-module yang
membentuk suatu sub-system (aplikasi)
3
Proses Testing
System Testing

Pengujian terhadap integrasi sub-system, yaitu
keterhubungan antar sub-system
Acceptance Testing



Pengujian terakhirs 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)
4
Proses Testing
Unit
Testing
Module
Testing
Component Testing
Sub-system
Testing
Integration Testing
System
Testing
Acceptance
Testing
User
Testing
5
The testing process
Component testing


Pengujian komponen-komponen program
Biasanya dilakukan oleh component developer
(kecuali untuk system kritis)
Integration testing



Pengujian kelompok komponen-komponen yang
terintegrasi untuk membentuk sub-system
ataupun system
Dialakukan oleh tim penguji yang independent
Pengujian berdasarkan spesifikasi sistem
6
Rencana Pengujian
Proses testing

Deskripsi fase-fase utama dalam pengujian
Pelacakan Kebutuhan

Semua kebutuhan user diuji secara individu
Item yg diuji

Menspesifikasi komponen sistem yang diuji
Jadual Testing
Prosedur Pencatatan Hasil dan Prosedur
Kebutuhan akan Hardware dan Software
Kendala-kendala

Mis: kekuranga staff, alat, waktu dll.
7
Hubungan antara rencana pengujian dan
proses pengembangan system
Spesifikasi
Kebutuhan
Acceptance
Test plan
Service
Spesifikasi
System
System
Integration
Test plan
Acceptance
test
Perancangan
System
Sub-System
Integration
Test plan
System
Integration
test
Detail
Perancangan
Module and
Unit code and
test
Sub-System
Integration
test
8
Failures, Faults
Failure: 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
9
Contoh: Faults, Errors, and
Failures
1: input A,B

Suppose node 6 should be
X:= C*(A+2*B)
•
2: A>0?
3: C :=0
» executing path (1,2,4,5,7,8)
will not reveal this fault
because 6 is not executed
» nor will executing path
(1,2,3,5,6,8) because C = 0
4: C := A*B

5: B>0?
Need to make sure proper
test cases are selected
•
6: X := C*(A+2*A)
7: X := A+B
Failure-less fault:
the definitions of C at
nodes 3 and 4 both affect
the use of C at node 6
» executing path (1,2,4,5,6,8)
will reveal the failure,
but only if B /= 0
8: output X
10
Prioritas Testing
Hanya test yang lengkap yg dapat
meyakinkan sistem terbebas dari kesalahan,
tetapi hal ini sangat sulit dilakukan.
Prioritas dilakukan terhadap pengujian
kemampuan sistem, bukan masing-masing
komponennya.
Pengujian untuk situasi yg tipikal lebih
penting dibandingkan pengujian terhadap
nilai batas.
11
Test data dan kasus test
Test data: Input yang yang
direncankan digunakan oleh sistem.
Test cases: Input yang digunakan
untuk menguji sistem dan memprediksi
output dari input jika sistem beroperasi
sesuai dengan spesifikasi.
12
Proses defect testing
Test
cases
Design test
cases
Test
data
Prepare test
data
Test
results
Run program
with test data
Test
reports
Compare results
to test cases
13
Black-box testing
Pendekatan pengujian dimana program
dianggap sebagai suatu ‘black-box’
(‘kotak hitam’)
Program test case berbasiskan
spesifikasi
Test planning dapat dimulai sejak awal
proses pengembangan sistem
14
Black-box testing
Input test data
I
Inputs causing
anomalous
behaviour
e
System
Output test results
Oe
Outputs which reveal
the presence of
defects
15
Equivalence partitioning
Input data dan output hasil terdapat di klas
yang berbeda yang sesuai dengan klas
inputnya
Masing-masing klas equivalensi partition
diprosres dimana program akan memproses
anggota klas-klas tersebut secara equivale.
Test cases dipilih dari masing-masing partisi
16
Equivalence partitioning
Invalid inputs
Valid inputs
System
Outputs
17
Equivalence partitioning
Partition system inputs and outputs into
‘equivalence sets’

If input is a 5-digit integer between 10000 and
99999,
equivalence partitions are <10000, 10000-99999
and > 100000
Choose test cases at the boundary of these
sets

00000, 9999, 10000, 99999, 100001
18
Equivalence partitions
3
4
Less than 4
7
11
10
Between 4 and 10
More than 10
Number of input values
9999
10000
Less than 10000
50000
100000
99999
Between 10000 and 99999
More than 99999
Input values
19
Search routine specification
procedure Search (Key : ELEM ; T: ELEM_ARRAY;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition
-- the array has at least one element
T’FIRST <= T’LAST
Post-condition
-- the element is found and is referenced by L
( Found and T (L) = Key)
or
-- the element is not in the array
( not Found and
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
20
Search routine - input
partitions
Inputs yang sesuai dg pre-conditions
Inputs yang tidak sesuai pre-condition
Inputs dimana key element ada di
dalam array
Inputs dimana key element tidak
terdapat di dalam array
21
Search routine - input
partitions
Array
Single value
Single value
More than 1 value
More than 1 value
More than 1 value
More than 1 value
Input sequence (T)
17
17
17, 29, 21, 23
41, 18, 9, 31, 30, 16, 45
17, 18, 21, 23, 29, 41, 38
21, 23, 29, 33, 38
Element
In sequence
Not in sequence
First element in sequence
Last element in sequence
Middle eleme nt in sequence
Not in sequence
Key (Key)
17
0
17
45
23
25
Output (Found, L)
true, 1
false, ? ?
true, 1
true, 7
true, 4
false, ? ?
22
Structural testing
Disebut juga white-box testing
Penentuan test case disesuaikan
dengan struktur sistem. Knowledge
program digunakan untuk
mengidentifikasi test case tambahan.
Tujuannya untuk menguji semua
statement program (debug).
23
White-box testing
Test data
Tests
Derives
Component
code
Test
outputs
24
Path testing
Tujuannya meyakinkan bahwa himpunan test
case akan menguji setiap path pada suatu
program paling sedikit satu kali.
Titik awal untuk path testing adalah suatu
program flow graph yang menunjukkan nodenode yang menyatakan program decisions
(mis.: if-then-else condition) dan busur
menyatakan alur kontrol
Statements dengan conditions adalah nodenode dalam flow graf.
25
Program flow graphs
Menggambarkan alur kontrol. Setiap cabang
ditunjukkan oleh path yg terpisah dan loop
ditunjukkan oleh arrows looping kembali ke
loop kondisi node.
Digunakan sebagai basis untuk menghitung
cyclomatic complexity
Cyclomatic complexity = Jumlah edges –
Jumlah Node +2
Cyclomatic complexity menyatakan jumlah
test untuk menguji control statements
26
1
bottom > top
while bottom < = top
2
3
if (elemArray [mid] == key
4
8
5
(if (elemArray [mid]< key
6
9
7
Binary search flow
graph
Independent paths
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.
28
Integration testing
Pengujian keseluruhan system atau subsystem yang terdiri dr komponen yg
terintegrasi.
Test integrasi menggunakan black-box
dengan test case ditentukan dari spesifikasi.
Kesulitannya adalah menemukan/melokasikan
Penggunaan Incremental integration testing
dapat mengurangi masalah tersebut.
29
Incremental integration
testing
T1
A
T1
A
T2
T1
A
T2
T2
B
T3
B
T3
B
C
T4
T3
C
T4
T5
D
Test sequence
1
Test sequence
2
Test sequence
3
30
Pendekatan integration testing
Top-down testing

Berawal dari level-atas system dan terintegrasi
dengan mengganti masing-masing komponen
secara top-down dengan suatu stub (program
pendek yg mengenerate input ke sub-system yg
diuji).
Bottom-up testing

Integrasi components di level hingga sistem
lengkap sudah teruji.
Pada prakteknya, kebanyakan test integrasi
menggunakan kombinasi kedua strategi
pengujian tsb.
31
Top-down testing
Level 1
Testing
sequence
Level 2
Level 1
Level 2
Le vel 2
. ..
Level 2
Le vel 2
stubs
Le vel 3
stubs
32
Bottom-up testing
Test
drivers
Level N
Test
drivers
Level N
Level N–1
Le vel N
Level N–1
Level N
Level N
Testing
sequence
Level N–1
33
Pendekatan Testing
Architectural validation

Top-down integration testing lebih baik digunakan
dalam menemukan error dalam sistem arsitektur.
System demonstration

Top-down integration testing hanya membatasi
pengujian pada awal tahap pengembangan system.
Test implementation

Seringkali lebih mudah dengan menggunakan
bottom-up integration testing
34
Interface testing
Dilakukan kalau module-module dan subsystem terintegrasi dan membentuk sistem
yang lebih besar
Tujuannya untuk medeteksi fault terhadap
kesalahan interface atau asumsi yg tidak valid
terntang interface tsb.
Sangat penting untuk pengujian terhadap
pengembangan sistem dgn menggunakan
pendekatan object-oriented yg didefinisikan
oleh object-objectnya
35
Interface testing
Test
cases
B
A
C
36
Interfaces types
Parameter interfaces

Data dikirim dari satu procedure ke procedure
lainnya.
Shared memory interfaces

Block of memory dishare diantara procedureprocedure
Procedural interfaces

Sub-system mengencapsulasi sekumpulan
procedure-procedure yang akan dipanggil oleh
sub-system lainnya
Message passing interfaces

Sub-systems meminta services dari sub-systems
lainnya
37
Interface errors
Interface misuse

componen pemanggil memanggil component lainnya
dan membuat suatu kesalahan dalam penggunaan
interfacenya (mis.: parameter dg urutan yg tidak
sesuai).
Interface misunderstanding

component pemanggil salah dalam mengasumsikan
behaviour component yg dipanggil.
Timing errors

Component yg memanggil dan yg dipanggil beroperasi
pada kecepatan yg berbeda sehingga dimungkinkan
mengakses informasi yg tidak uptodate
(synchronization problem).
38
Petunjuk melakukan Interface
testing
Merancang test dimana parameter ke
procedure yg dipanggil berada pada nilai
batas extrim
Test Menggunakan null pointer
Perancangan tests sehingga component yg di
test akan fail.
Menggunakan stress testing pada message
passing
Pada shared memory systems, variasikan
urutan dimana komponen diaktifkan.
39
Stress testing
Menguji sistem dengan nilai yg melebihi
maksimum load. Stressing suatu system
menyebabkan tidak mudah kerusakan.
Stressing suatu system test failure behaviour.
Systems seharusnya tidak gagal total. Stress
testing mencek kehilangan service yg tidak
diduga ataupun data yg hilang.
Khusus untuk sistem terdistribusi dapat
menyebabkan degradasi jaringan sehingga
overload.
40