Testing dan Implementasi
Pertemuan 6
Dua Aspek yang dipertimbangkan:
• Apakah implementasi sudah sesuai dengan spesifikasi ?
• Apakah spesifikasi sesuai dengan kebutuhan user ?
Validasi (result)
• “Apakah sistem yang dikembangkan sudah benar?”
• Pengujian dimana sistem ketika diimplementasikan sesuai dengan yang iharapkan
Verifikasi (process)
• “Apakah sistem dikembangkan dengan cara yang benar ?”
• Pengujian apakah sistem sudah sesuai dengan spesifikasi
Seberapa baik sistem yang
sudah dibangun ?
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)
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)
Proses Testing
Unit
Testing Module
Testing Sub-system
Testing System
Testing Acceptance Testing
Component Testing Integration Testing User
Testing
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
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.
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
1: input A,B
2: A>0?
3: C :=0 4: C := A*B
5: B>0?
6: X := C*(A+2*A) 7: X := A+B
8: output X
Contoh: Faults, Errors, and Failures
Suppose node 6 should be X:= C*(A+2*B)
• Failure-less fault:
» 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
Need to make sure proper test cases are selected
• 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
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.
Prioritas Testing
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.
Test data dan kasus test
Proses defect testing
Design test cases
Prepare test data
Run program with test data
Compare r esults to test cases Test
cases
Test data
Test results
Test reports
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
Black-box testing
I e Input test data
Oe Output test results
System
Inputs causing anomalous behaviour
Outputs which reveal the presence of
defects
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
Equivalence partitioning
System
Outputs
Invalid inputs Valid inputs
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
Equivalence partitioning
Equivalence partitions
Between 10000 and 99999
Less than 10000 More than 99999
9999
10000 50000
100000 99999
Input values
Between 4 and 10
Less than 4 More than 10
3
4 7
11 10
Number of input values
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 ))
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
Search routine - input
partitions
Search routine - input partitions
Array Element
Single value In sequence
Single value Not in sequence
More than 1 value First element in sequence More than 1 value Last element in sequence More than 1 value Middle element in sequence More than 1 value Not in sequence
Input sequence (T) Key (Key) Output (Found, L)
17 17 true, 1
17 0 false, ??
17, 29, 21, 23 17 true, 1
41, 18, 9, 31, 30, 16, 45 45 true, 7 17, 18, 21, 23, 29, 41, 38 23 true, 4
21, 23, 29, 33, 38 25 false, ??
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).
Structural testing
White-box testing
Component code
Test outputs Test data
Derives Tests
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 node- node yang menyatakan program decisions
(mis.: if-then-else condition) dan busur menyatakan alur kontrol
Statements dengan conditions adalah node- node dalam flow graf.
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
Program flow graphs
Binary search flow graph
1
2
3
4
6 5
7
while bottom < = top
if (elemArray [mid] == key
(if (elemArray [mid]< key 8
9 bottom > top
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.
Independent paths
Integration testing
Pengujian keseluruhan system atau sub- system 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.
Incremental integration testing
T3 T2 T1
T4
T5 A
B
C
D T2
T1
T3
T4 A
B
C T1
T2
T3 A
B
Test sequence 1
Test sequence 2
Test sequence 3
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.
Top-down testing
Level 2 Le vel 2
Level 2 Level 2
Level 1 Testing Level 1
sequence
Le vel 2 stubs
Le vel 3 stubs
. . .
Bottom-up testing
Level N Level N
Le vel N Level N
Level N
Level N–1 Level N–1
Level N–1
Testing sequence Test
drivers
Test drivers
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
Dilakukan kalau module-module dan sub- system 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
Interface testing
Interface testing
Test cases
B A
C
Interfaces types
Parameter interfaces
Data dikirim dari satu procedure ke procedure lainnya.
Shared memory interfaces
Block of memory dishare diantara procedure- procedure
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
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).
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.
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.
Components yang diuji adalah class object yang diinstantiate ke object.
Lebih besar dibandingkan pengujian sebuah function sehingga pendekatan white-box testing perlu diperluas.
Tidak jelasnya ‘top’ suatu system untuk top-down integration dan testing
Object-oriented testing
Testing levels
Testing operations pada objects Testing object classes
Testing clusters cooperating objects
Testing OO system secara lengkap
Object class testing
Complete test yang menguji class melibatkan
Testing semua operations suatu object
Setting dan interrogating semua attribute object
Menguji object untuk semua state(keadaan) yg mungkin
Inheritance akan mengakibatkan sulitnya perancangan object class tests seperti
information yg diuji sulit dilokalisasi.
Contoh: Weather station object interface
Test cases dibutuhkan untuk semua operations
Menggunakan state model untuk mengidentifikasi state transitions testing
Contoh testing sequences
Shutdown Waiting Shutdown
Waiting Calibrating Testing
Transmitting Waiting
Waiting Collecting Waiting
Summarising Transmitting
Waiting identifier
reportWeather ()
calibrate (instruments) test ()
startup (instruments) shutdown (instruments)
WeatherStation
Integrasi Object
Levels integrasi sedikit berbeda untuk sistem yang berorientasi object.
Cluster testing digunakan untuk test integrasi and testing clusters terhadap cooperating
objects
Identifikasi clusters menggunakan knowledge dari operation objects dan system features
yang diimplementasikan oleh cluster tersebut.
Approaches cluster testing
Use-case atau scenario testing
Testing berdasarkan pada interaksi user dengan sistem.
Keuntungannya diujikan oleh user yg berpengalaman.
Object interaction testing
Tests barisan interaksi object yang
berhenti ketika suatu operation object tidak memanggil service dari object lain.
Scenario-based testing
Identifikasi scenarios dari use-cases
dan menambahkannya dengan diagram interaksi yang menunjukkan object-
object yang terlibat dalam scenario
Lihat contoh scenario berikut ini pada
sistem weather station ketika suatu
report dibuat
Collect weather data
Weather station testing
Thread pengeksekusian methode
CommsController:request WeatherStation:report WeatherData:summarise
Inputs dan outputs
Input report request dengan acknowledge yg sesuai serta output report akhir
Dapat diujikan dengan membuat raw data dan meyakinkan bahwa dapat menghasilkan kesimpulan (summarize) yg sesuai.
Gunakan raw data yg sama untuk menguji object WeatherData
Testing workbenches
Testing merupakan suatu proses yg cukup mahal. Testing workbenches menyediakan tool-tool untuk mereduksi waktu yg
dibutuhkan dan total cost pengujian
Kebanyakan testing workbenches merupakan open systems karena kebutuhan testing
membutuhkan tergantung dr spesifikasi organisasi
Sulit diintegrasikan dengan closed design dan analysis workbenches
A testing workbench
Dynamic analyser
Program being tested
Test results
Test predictions
File comparator Execution
report Simulator
Source code
Test
manager Test data Oracle
Test data
generator Specification
Report generator
Test results report
