3. Pengujian Perangkat Lunak
-
Upload
loughan-thepoe -
Category
Documents
-
view
66 -
download
1
Transcript of 3. Pengujian Perangkat Lunak
PENGUJIAN PERANGKAT LUNAK
OlehCipta Wahyudi
• Mengerti apa yang dimaksud denganPengujian Perangkat Lunak.
• Mengetahui jenis-jenis pengujian perangkatlunak
TUJUAN
• Terminologi
• Keandalan PL
• Tujuan Pengujian PL
• Strategi Pengujian PL
• Metoda Pengujian PL
• Aktivitas Pengujian PL
OUTLINE
• Reliability: Ukuran kesuksesan yang digunakan untukmengukur kesesuaian antara perilaku yang terjadidengan perilaku yang diinginkan.
• Failure: Penyimpangan perilaku yang diamatidengan perilaku yang kehendaki.
• Error: Keadaan di mana sistem berada pada suatukeadaan, jika sistem terus melakukan proses akandapat mengakibatkan terjadinya failure. Manifestasidari fault
• Fault (bug/defect) penyebab (mekanis ataualgoritmis) dari suatu error. Kesalahan desain ataukoding ..
TERMINOLOGI
Failure?
Error ?
Fault ?
TERMINOLOGI
TERMINOLOGI -- ERROR
ALGORITHMIC FAULT
MECHANICAL FAULT
Software Reliability – Keandalan PL
• Probablilitas sistem PL yang tidak
menyebabkan failure pada sistempada suatu waktu tertentu dengan
kondisi tertentu (IEEE)
TERMINOLOGI
Upaya meningkatkan ….
• Fault Avoidance
• Pencegahan/Penghindaran
• Fault Detection
• Deteksi/Penemuan
• Fault Tolerance
• Dapat diterima
KEANDALAN PL
KEANDALAN PL
Testing
Fault Handling
Fault AvoidanceFault Tolerance
Fault Detection
Debugging
UnitTesting
IntegrationTesting
SystemTesting
VerificationConfigurationManagement
AtomicTransactions
ModularRedundancy
CorrectnessDebugging
PerformanceDebugging
ReviewsDesign
Methodology
Pressman (2005)
DEFINISI (1)
Pengujian adalah proses eksekusiprogram dengan tujuan khusus untukmenemukan kesalahan sebelumpengiriman kepada user
IEEE
1) Proses pengoperasian sistem ataukomponen dalam kondisi tertentu, mengamati atau merekam hasilnya dalampengambilan evaluasi
2) Proses menganalisis item software untukmendeteksi perbedaan antara kondisi yang adadan yang diinginkan dan mengevaluasi fitur dariitem perangkat lunak
DEFINISI (2)
• Menemukan kesalahan (fault) sebanyak
mungkin dari PL yang diuji
• Membuat PL yang diuji, setelah perbaikan
dilakukan, menjadi PL yang berkualitas
• Melakukan pengujian secara efektif dan
efisien
• Mengumpulkan kesalahan yang terjadi dan
menggunakannya untuk tindakan preventif
TUJUAN PENGUJIAN PL
errors
requirements conformance
performance
an indicationof quality
[Adapted from Software Engineering A Practitioner’s Approach 5th Edition, by Pressman, McGraw-Hill, 2000]
TUJUAN PENGUJIAN PL
PENGUJIAN PL
Methods
Strategies
white-boxmethods
black-boxmethods
Sumber : Software Engineering: A Practitioner’s Approach, 5/e R.S. Pressman 2005
developer independent tester
Understands the system
but, will test "gently"
and, is driven by "delivery"
Must learn about the system,
but, will attempt to break it
and, is driven by quality
PENGUJIAN PL -- PELAKU
Sumber : Software Engineering: A Practitioner’s Approach, 5/e R.S. Pressman 2005
• Big Bang
• Pengujian PL secara keseluruhan, setelah
seluruh komponen PL selesai dibuat
• Incremental
• Pengujian Secara bertahap
STRATEGI PENGUJIAN PL
INCREMENTAL
RequirementsSpecification
PreliminaryDesign
DetailedDesign
Coding
Unit Testing
IntegrationTesting
SystemTesting
• Functional (Black Box)
• Structural (White Box)
METODA PENGUJIAN PL
• Functional (Black Box)
• Fokus pada output yang dihasilkan
dengan memberikan input dan kondisi
eksekusi
• Membandingkan kesesuaian output
dengan spesifikasi kebutuhan fungsional
METODA PENGUJIAN PL
FUNCTIONAL (BLACK BOX)
requirementsrequirements
eventseventsinputinput
outputoutput
Sumber : Pressmann (2005)
• Menguji dengan
memperhatikanmekanisme internal
sistem
• Menguji untuk
memastikan operasi
internal berjalan sesuaispesifikasi
• Semua komponen diuji
STRUCTURAL (WHITE BOX)
... our goal is to ensure that all ... our goal is to ensure that all statements and conditions have statements and conditions have been executed at least once ...been executed at least once ...Sumber : Pressmann (2005)
AKTIVITAS PENGUJIAN PL (1)
Tested Subsystem
SubsystemCode
FunctionalIntegration
Unit
TestedSubsystem
RequirementsAnalysis
Document
SystemDesign
Document
Tested Subsystem
Test Test
Test
Unit Test
Unit Test
User Manual
RequirementsAnalysis
Document
SubsystemCode
SubsystemCode
All tests by developerAll tests by developer
FunctioningSystem
IntegratedSubsystems
GlobalRequirements
User’s understandingTests by developerTests by developer
Performance Acceptance
Client’s Understanding
of Requirements
Test
FunctioningSystem
TestInstallation
User Environment
Test
System inUse
UsableSystem
ValidatedSystem
AcceptedSystem
Tests (?) by userTests (?) by user
Tests by clientTests by client
AKTIVITAS PENGUJIAN PL (2)
UNIT TESTING
• Mengetahui pengujian perangkat lunak unit (Unit Testing).
• Mengetahui jenis-jenis unit testing
TUJUAN
• Pengertian Unit Testing
• Pengujian Statis
• Pengujian Black Box
• Pengujian White Box
OUTLINE
AKTIVITAS PENGUJIAN PL (1)
Tested Subsystem
SubsystemCode
FunctionalIntegration
Unit
TestedSubsystem
RequirementsAnalysis
Document
SystemDesign
Document
Tested Subsystem
Test Test
Test
Unit Test
Unit Test
User Manual
RequirementsAnalysis
Document
SubsystemCode
SubsystemCode
All tests by developerAll tests by developer
FunctioningSystem
IntegratedSubsystems
Sumber : Bruege (2004)
GlobalRequirements
User’s understandingTests by developerTests by developer
Performance Acceptance
Client’s Understanding
of Requirements
Test
FunctioningSystem
TestInstallation
User Environment
Test
System inUse
UsableSystem
ValidatedSystem
AcceptedSystem
Tests (?) by userTests (?) by user
Tests by clientTests by client
AKTIVITAS PENGUJIAN PL (2)
Sumber : Bruege (2004)
• Pengujian unit (komponen) secara terisolir �
menguji di luar program yang menggunakan
unit ini.
• Memeriksa apakah suatu individual program
unit (subprogram, object class, package,
module) memiliki perilaku yang benar.
UNIT TESTING
TIPE PENGUJIAN
• Pengujian Statis (Static Testing)• Pengujian terhadap satu unit tanpa melakukan
eksekusi terhadap unit tersebut
• Pengujian Dinamis (Dynamic Testing)• Pengujian dengan mengeksekusi unit dengan
menggunakan data uji.
• White Box dan Black Box
UNIT TESTING
TIPE PENGUJIAN
• Code Walktrough
• Code Inspection
STATIC TESTING
Code Walktrough• Kode program dan dokumentasi di-review oleh
tim
• Fokus ada pada kode program
• Informal
• Dipimpin oleh programmer
STATIC TESTING
Code Inspection• Kode program dan dokumentasi di-review oleh
tim dengan suatu daftar rujukan• Definisi dan struktur data
• Algoritma
• Interface antar komponen
• Prakiraan unjuk kerja program � penggunaan
memori, kecepatan pengolahan
• Fokus ada pada kode program
• Informal
• Dipimpin oleh moderator BUKAN programmer
STATIC TESTING
Langkah-langkah Code Inspection1. Tim reviewer bertemu untuk melakukan review
awal � overview kode dan tujuan
2. Masing-masing anggota tim bekerja secaraindividu melakukan inspeksi program dan
dokumentasi �mencatat fault yang ditemukan3. Tim reviewer bertemu untuk melakukan diskusi
terhadap temuan masig-masing
STATIC TESTING
requirementsrequirements
eventseventsinputinput
outputoutput
Sumber : Pressmann (2005)
BLACK BOX TESTING
• Membagi domain input menjadikelompok/kelas data di mana test case akan diambil.
• Contoh: Program menghitung fungsi
• Fungsi ini mendefinisikan kelas masukanyang valid dan tidak valid :
� X < = -2 valid
� -2 < X < 1 invalid
� X >= 1 valid
• Test cases di pilih dari kelas masukan ini
)2()1( +∗− XX
EQUIVALENCE PARTITIONING
•Test cases dirancang untuk menguji batasdomain input.
•Digunakan bersama dan saling melengkapidengan equivalence partitioning.
•Misal:
�X < = -2 -231, -100, -2.1, -2
� -2 < X < 1 -1.9, -1, 0, 0.9
�X >= 1 1, 1.1,100, 231-1
BOUNDARY VALUE
• Menguji dengan
memperhatikanmekanisme internal
sistem
• Menguji untuk
memastikan operasi
internal berjalan sesuaispesifikasi
• Semua komponen diuji ... our goal is to ensure that all ... our goal is to ensure that all statements and conditions have statements and conditions have been executed at least once ...been executed at least once ...Sumber : Pressmann (2005)
WHITE BOX TESTING
• Seluruh independent path diuji
• Menguji semua pernyataan untuk nilai ‘true’
dan ‘false’
• Mengesekusi semua kalang (loop) untuk
kondisi-kondisi batas.
• Memeriksa struktur data internal
BASIS PATH TESTING
• Menganalisa rancangan prosedural
• Mendefinisikan basis set dari execution paths
• Test cases untuk basis set mengeksekusi
setiap statemen program minimal satu kali.
BASIS PATH TESTING
Langkah-Langkah
1. Mengubah unit menjadi “flow graph”
• flow graph : graph berarah dengan sebuah
“node awal" dan sebuah “node akhir“.
2. Menghitung ukuran kompleksitas logik unit
3. Menentukan execution paths. Test Case
ditentukan berdasarkan execution paths.
BASIS PATH TESTING
Langkah-Langkah
1. Mengubah unit menjadi “flow graph”
• flow graph : graph berarah dengan sebuah
“node awal" dan sebuah “node akhir“.
2. Menghitung ukuran kompleksitas logik unit
3. Menentukan execution paths. Test Case
ditentukan berdasarkan execution paths.
BASIS PATH TESTING
Flow Graph: penyajian komponen pemrogramanterstruktur
BASIS PATH TESTING
procedure XYZ is
A,B,C: INTEGER;
begin
1. GET(A); GET(B);
2. if A > 15 then
3. if B < 10 then
4. B := A + 5;
5. else
6. B := A - 5;
7. end if
8. else
9. A := B + 5;
10. end if;
end XYZ;
1
3 9
10
4 6
2
7
FLOW GRAPH
Langkah-Langkah
1. Mengubah unit menjadi “flow graph”
• flow graph : graph berarah dengan sebuah
“node awal" dan sebuah “node akhir“.
2. Menghitung ukuran kompleksitas logik unit
3. Menentukan execution paths. Test Case
ditentukan berdasarkan execution paths.
BASIS PATH TESTING
• Suatu metric, V(G), yang menggambarkankompleksitas sebuah flow graph, G.
• V(G) dihitung dengan menggunakan salah satuformula:
1. V(G) = E - N + 2
• E = jumlah edge dalam graph G
• N = jumlah node dalam G
2. V(G) = R
• R = jumlah bounded regions dalam G
3. V(G) = P + 1
• P = jumlah predikat
CYCLOMATIC COMPLEXITY
V(G)=E-N+2 = 4
[sumber: Pressman]
CYCLOMATIC COMPLEXITY
• Berapa Kompleksitas …. ?
CYCLOMATIC COMPLEXITY
1
3 9
10
4 6
2
7
Langkah-Langkah
1. Mengubah unit menjadi “flow graph”
• flow graph : graph berarah dengan sebuah
“node awal" dan sebuah “node akhir“.
2. Menghitung ukuran kompleksitas logik unit
3. Menentukan execution paths. Test Case
ditentukan berdasarkan execution paths.
BASIS PATH TESTING
• Execution path: sekumpulan node dan
directed edges dalam flow graph yang
menghubungkan node awal dan node
akhir.
• Dua execution path disebut independen jika
keduanya tidak memiliki node dan edge
yang sama.
BASIS PATH SET
• Basic set sebuah execution merupakan
sebuah kumpulan path yang independen di
mana seluruh node dan edge dalam graph
dicakup paling tidak satu kali.
• V(G) memberikan batas atas (upper bound)
jumlah independent paths yang dibutuhkan.
BASIS PATH SET
V(G)=E-N+2 = 4
Independent Paths1: 1,112: 1,2,3,4,5,10,1,113: 1,2,3,6,8,9,10,1,114: 1,2,3,6,7,9,10,1,11
V(G): upper bound on number of teststo ensure all code has been executed
[From SEPA 5/e]
CYCLOMATIC COMPLEXITY
independent paths:independent paths:
Since V(G) = 4,Since V(G) = 4,
Path 1: 1,2,3,6,7,8Path 1: 1,2,3,6,7,8Path 2: 1,2,3,5,7,8Path 2: 1,2,3,5,7,8Path 3: 1,2,4,7,8Path 3: 1,2,4,7,8Path 4: 1,2,4,7,2,4,...7,8Path 4: 1,2,4,7,2,4,...7,8
11
22
3344
55 66
77
88
BASIS PATH SET
• Menentukan kelipatan persekutuan terbesaratau “greatest common divisor” (GCD) darisepasang bilangan (kedua bilangan tdk nol).
• GCD(a,b) = c� c bilangan positif integer
� c pembagi bersama a dan b (c membagi a dan c membagi b)
• For example� GCD(45, 27) = 9
� GCD (7,13) = 1
� GCD(-12, 15) = 3
� GCD(13, 0) = 13
� GCD(0, 0) tidak terdefinisi
CONTOH -- GCD
1. Merancang algoritma
2. Menganalisa algoritma denganmenggunakan analisis basic.
3. Menentukan kelas masukan data (equivalence classes) .
4. Menentukan batas equivalence classes.
5. Memilih tests cases �mencakup basic path set, data dari setiap equivalence class, and data pada dan dekat batas.
GCD TEST PLAN
note: Based on Euclid’s algorithm1. function gcd (int a, int b) {2. int temp, value;3. a := abs(a);4. b := abs(b);5. if (a = 0) then6. value := b; // b is the GCD7. else if (b = 0) then8. raise exception;9. else 10. loop 11. temp := b;12. b := a mod b;13. a := temp;14. until (b = 0) 15. value := a;16. end if;17. return value;18. end gcd
1
5
10
9
17
7
6
18
ALGORITMA GCD
Sumber : Swenet
• Basic Path Set
� V(G) = 4
� (1,5,6,17,18), (1,5,7,18), (1,5,7,9,10,17,18),
(1,5,7,9,10,9,10,17,18)
CONTOH -- GCD
• Equivalence Classes
• Algoritma GCD menerima nilai integer sebagai
masukan input. Maka 0, integer positif dan integer
negatif dapat dianggap sebagai batas khusus �
didapat:
• a < 0 dan b < 0, a < 0 dan b > 0, a > 0 dan b < 0
• a > 0 dan b > 0, a = 0 dan b < 0, a = 0 dan b > 0
• a > 0 dan b = 0, a > 0 dan b = 0, a = 0 dan b = 0
• Nilai Batas
• a = -231, -1, 0, 1, 231-1 dan b = -231, -1, 0, 1, 231-1
CONTOH -- GCD
GCD Test PlanTest Description / Data Expected Results Test Experience / Actual Results
Basic Path Set path (1,5,6,17,18) � (0, 15) 15 path (1,5,7,18) � (15, 0) 15 path (1,5,7,9,10,17,18) � (30, 15) 15 path (1,5,7,9,10,9,10,17,18) � (15, 30) 15
Equivalence Classes a < 0 and b < 0 � (-27, -45) 9 a < 0 and b > 0 � (-72, 100) 4 a > 0 and b < 0 � (121, -45) 1 a > 0 and b > 0 � (420, 252) 28 a = 0 and b < 0 � (0, -45) 45 a = 0 and b > 0 � (0 , 45) 45 a > 0 and b = 0 � (-27, 0) 27 a > 0 and b = 0 � (27, 0) 27 a = 0 and b = 0 � (0 , 0) exception raised
Boundary Points (1 , 0) 1 (-1 , 0) 1 (0 , 1) 1 (0 , -1) 1 (0 , 0) (redundant) exception raised (1, 1) 1 (1, -1) 1 (-1, 1) 1 (-1, -1) 1
Anything missing?
Unit yang diuji
• unit tunggal (mandiri) yang tidak berinteraksidengan unit lain (seperti GCD), maka dapatditulis program yang menjalankan test cases yang ada dalam test plan.
• unit yang harus berinteraksi dengan unit lain �lebih sulit dalam melakukan pengujian secaraterisolasi.
IMPLEMENTASI PENGUJIAN
Langkah-langkah Pengujian1. Setlah rancangan unit selesai lakukan pengujian
statis unit.
2. Membuat test plan untuk unit.
3. Apabila unit yang diuji merujuk unit lain, dan belumselesai, buat stubs untuk unit ini.
4. Buat test driver untuk unit:
• test case data (from the test plan)
• Eksekusi unit, menggunakan test case data
• Hasil ekseksui test case
IMPLEMENTASI PENGUJIAN
INTEGRATION dan SYSTEM
TESTING
• Mengetahui pengujian perangkat
lunak unit
• Integration
• System.
• Mengetahui jenis-jenis System testing
TUJUAN
• Pengujian Integrasi
• Pengujian Sistem• Functional Testing
• Performance Testing
• Acceptance Testing
• Installation Testing
OUTLINE
AKTIVITAS PENGUJIAN PL (1)
Tested Subsystem
SubsystemCode
FunctionalIntegration
Unit
TestedSubsystem
RequirementsAnalysis
Document
SystemDesign
Document
Tested Subsystem
Test Test
Test
Unit Test
Unit Test
User Manual
RequirementsAnalysis
Document
SubsystemCode
SubsystemCode
All tests by developerAll tests by developer
FunctioningSystem
IntegratedSubsystems
• Fokus deteksi fault pada sekelompokkomponen/unit, seperti fungsi, kelas, packages.
• Dua atau lebih komponen diintegrasikandan diuji.
• Jika tidak ada, maka komponen lain ditambahkan dan diuji.
INTEGRATED TESTING
integration testing
Pendekatan
• Bottom-up testing
• Top-down testing
• Sandwich Testing
INTEGRATED TESTING
• Sub sistem pada lapisan terbawah dalam
hirarki pemanggilan diuji secara indivual.
• Kemudian sub sistem yang diuji adalah sub
sistem yang memanggil sub sistem yang diuji
sebelumnya.
BOTTOM UP INTEGRATION (1/3)
• Dilakukan secara berulang sampai semua
sub sistem di uji.
• Butuh Test Driver:
• Rutin yang memanggil sub sistem yang
diuji dan memberikan test case
BOTTOM UP INTEGRATION (2/3)
A
B C D
GFE
Layer I
Layer II
Layer III
Test F
Test E
Test G
Test C
Test D,G
Test B, E, F
Test A, B, C, D,
E, F, G
BOTTOM UP INTEGRATION (3/3)
• Munguji lapisan atas atau sub sistem
pemanggil terlebih dahulu.
• Mengkombinasikan semua sub sistem yang
dipanggil oleh sub sistem yang telah diuji dan
melakukan pengujian terhadap sub sistem
yang hasil kombinasi tadi.
TOP DOWN INTEGRATION (1/3)
• Dilakukan secara berulang sampai semua sub
sistem di uji.
• Butuh Test stub :
•Program atau fungsi yang mensimulasikan
simulates aktivitas sub sistem yang ‘hilang’
dengan merespons panggilan sub sistem
pemanggilan dan mengembalikan data
simulasi.
TOP DOWN INTEGRATION (2/3)
A
B C D
GFE
Layer I
Layer II
Layer III
Test A
Layer I
Test A, B, C, D
Layer I + II
Test A, B, C, D,
E, F, G
TOP DOWN INTEGRATION (3/3)
• Kombinasi pendekatan top-down strategy dan
bottom-up.
• Sistem dipandang memiliki 3 lapis.
•Lapis target
•lapis di atas target
•Lapis di bawah target
• Bagaimana menentukan lapisan target jika ada
lebih 3 lapisan ?
•Heuristic: mencoba meminimalisir jumlah stub
dan drivers
SANDWICH TESTING
A
B C D
GFE
Layer I
Layer II
Layer III
Test E
Test D,G
Test B, E, F
Test F
Test G
Test A
BottomLayerTests
TopLayerTests
Test A,B,C, D
Test A, B, C, D,
E, F, G
SANDWICH TESTING
• Test secara paralel:
•Lapisan tengah (middle layer) dengan driver dan stub
•Top layer dengan stub
•Bottom layer dengan driver
• Test secara paralel:
•Top layer mengakses middle layer (top layer
menggantikan driver)
•Bottom diakses oleh middle layer (bottom
layer menggantikan stub)
MODIFIED SANDWICH TESTING
A
B C D
GFE
Layer I
Layer II
Layer III
Test F
Test E
Test B
Test G
Test D
Test A
Test C
Test B, E, F
TripleTest I
TripleTest ITriple
Test I
TripleTest I
Test D,G
DoubleTest II
DoubleTest II
DoubleTest II
DoubleTest II
DoubleTest I
DoubleTest I
DoubleTest I
DoubleTest I
Test A,C
Test A, B, C, D,
E, F, G
MODIFIED SANDWICH TESTING
.
1. Berdasarkan strategi yang
dipilih, pilih komponen yang
akan diuji. Lakukan
pengujian unit untuk semua
komponen.
2. Lakukan persiapan untuk
pengujian (pembuatan
drivers, stubs)
3. Lakukan functional testing:
Definisikan test cases yang
menguji semua komponen
yang di uji.
1. Berdasarkan strategi yang
dipilih, pilih komponen yang
akan diuji. Lakukan
pengujian unit untuk semua
komponen.
2. Lakukan persiapan untuk
pengujian (pembuatan
drivers, stubs)
3. Lakukan functional testing:
Definisikan test cases yang
menguji semua komponen
yang di uji.
4. Lakukan structural testing:
Definisikan test cases yang
menguji semua komponen
yang di uji.
5. Lakukan performance tests
6. Simpan record test cases dan
activitas pengujian.
7. Ulangi langkah 1 to 6 sampai
keseluruhan sistem diuji.
Tujuan integration testing adalah
mengidentifikasi errors dalam
konfigurasi komponen yang
ada.
4. Lakukan structural testing:
Definisikan test cases yang
menguji semua komponen
yang di uji.
5. Lakukan performance tests
6. Simpan record test cases dan
activitas pengujian.
7. Ulangi langkah 1 to 6 sampai
keseluruhan sistem diuji.
Tujuan integration testing adalah
mengidentifikasi errors dalam
konfigurasi komponen yang
ada.
LANGKAH INTEGRATION TESTING
•Dilakukan setelah komponen-komponen
diintegrasikan.
•Menjamin bahwa sistem yang lengkap sesuai
dengan kebutuhan fungsional dan non
fungsional sistem.
•Pada tahap ini fault yang terjadi pada
komponen telah teridentifikasi dan dikoreksi.
SYSTEM TESTING (1/2)
• Functional Testing
• Performance Testing
• Acceptance Testing
• Installation Testing
SYSTEM TESTING (2/2)
• requirements testing � menguji fungsionalitassistem.
• Pada esensinya sama dengan pengujianBlackbox
• Test cases dirancang dari dokumen analisiskebutuhan (mis. user manual) dan berfokuspada kebutuhan dan fungsi utama (mis. use cases)
FUNCTIONAL TESTING (1/2)
• Pengujian dilakukan dengan memiliki test yang relevan pada pengguna dan memiliki peluangyang besar untuk menemukan failure.
FUNCTIONAL TESTING (2/2)
• Menemukan perbedaan antara goal
(kebutuhan non fungsional) yang
ditentukan pada saat pengembangan
sistem dengaan yang diimplementasikan
dalam sistem.
PERFORMANCE TESTING (1/3)
Jenis test:
• Stress testing – menguji apakah sistem
dapat merespons banyak request yang datang secara bersamaan.
• Volume testing – menguji sistem dengan
memberi data uji yang sangatbesar/banyak.
• Security testing – menguji keamanan
sistem (menemukan security faults). Menggunakan hacker untuk menguji
sistem.
PERFORMANCE TESTING (2/3)
Jenis test:
• Timing testing – mengevaluasi waktutanggap (response times) dan waktu untukmelakukan sebuah fungsi
• Environmental test – menguji toleransiterhadap lingkungan seperti panas, kelembaban, gerak
• Quality testing – pengujian keandalan, maintain- ability dan availabilitas sistem
• Recovery testing – pengujian terhadaptanggapan sistem terhadap adanyakesalahan atau ketiadaan data.
PERFORMANCE TESTING (3/3)
• Tujuan : menunjukkan bahwa sistem sudah siap
untuk pemakaian operasional.
• Pilihan test dibuat oleh client/sponsor
• Banyak test dapat diambil dari integration testing
• Dilakukan oleh client, bukan developer.
• Kebanyakan bug dalam perangkat lunak
biasanya ditemukan oleh client setelah sistem
digunakan, bukan oleh developer atau testers �
test tambahan (Pilot Test atau Field Test)
• Tujuan : menunjukkan bahwa sistem sudah siap
untuk pemakaian operasional.
• Pilihan test dibuat oleh client/sponsor
• Banyak test dapat diambil dari integration testing
• Dilakukan oleh client, bukan developer.
• Kebanyakan bug dalam perangkat lunak
biasanya ditemukan oleh client setelah sistem
digunakan, bukan oleh developer atau testers �
test tambahan (Pilot Test atau Field Test)
ACCEPTANCE TESTING
• Alpha test:
• Client menggunakan perangkat lunak di tempat
pengembang (development environment).
• Perangkat lunak digunakan dalam setting terkendali,
pengembang selalu siap untuk memperbaiki kesalahan
yang terjadi.
• Beta test:
• Dilakukan tempat pengguna (lingkungan yang
sebenarnya).
• Pengembang tidak ada
• Perangkat lunak digunakan dalam lingkungan yang
sebenarnya (target environment).
• Alpha test:
• Client menggunakan perangkat lunak di tempat
pengembang (development environment).
• Perangkat lunak digunakan dalam setting terkendali,
pengembang selalu siap untuk memperbaiki kesalahan
yang terjadi.
• Beta test:
• Dilakukan tempat pengguna (lingkungan yang
sebenarnya).
• Pengembang tidak ada
• Perangkat lunak digunakan dalam lingkungan yang
sebenarnya (target environment).
PILOT TESTING
• Sistem di install pada target environment
dan dievalusi.
• Mengulangi test cases yang dieksekusi
selama functional dan performance testing
dalam target environment.
• Beberapa kebutuhan mungkin tidak bisa
diuji dalam development environment
sehingga perlu dibuat test cases yang
baru.
INSTALLATION TESTING