Upload presentasi
Presentasi sedang didownload. Silahkan tunggu
1
PENGUJIAN PERANGKAT LUNAK
2
TUJUAN Mengerti apa yang dimaksud dengan Pengujian Perangkat Lunak.
Mengetahui jenis-jenis pengujian perangkat lunak
3
OUTLINE Terminologi Keandalan PL Tujuan Pengujian PL
Strategi Pengujian PL Metoda Pengujian PL Aktivitas Pengujian PL
4
TERMINOLOGI Reliability: Ukuran kesuksesan yang digunakan untuk mengukur kesesuaian antara perilaku yang terjadi dengan perilaku yang diinginkan. Failure: Penyimpangan perilaku yang diamati dengan perilaku yang kehendaki. Error: Keadaan di mana sistem berada pada suatu keadaan, jika sistem terus melakukan proses akan dapat mengakibatkan terjadinya failure. Manifestasi dari fault Fault (bug/defect) penyebab (mekanis atau algoritmis) dari suatu error. Kesalahan desain atau koding ..
5
TERMINOLOGI Failure? Error ? Fault ?
6
TERMINOLOGI -- ERROR
7
ALGORITHMIC FAULT
8
MECHANICAL FAULT
9
TERMINOLOGI Software Reliability – Keandalan PL
Probablilitas sistem PL yang tidak menyebabkan failure pada sistem pada suatu waktu tertentu dengan kondisi tertentu (IEEE)
10
KEANDALAN PL Upaya meningkatkan …. Fault Avoidance Fault Detection
Pencegahan/Penghindaran Fault Detection Deteksi/Penemuan Fault Tolerance Dapat diterima
11
KEANDALAN PL Fault Handling Fault Tolerance Fault Avoidance
Fault Detection Design Methodology Atomic Transactions Modular Redundancy Reviews Configuration Management Verification Testing Debugging Unit Testing Integration Testing System Testing Correctness Debugging Performance Debugging
12
DEFINISI (1) Pressman (2005)
Pengujian adalah proses eksekusi program dengan tujuan khusus untuk menemukan kesalahan sebelum pengiriman kepada user
13
DEFINISI (2) IEEE 1) Proses pengoperasian sistem atau komponen dalam kondisi tertentu, mengamati atau merekam hasilnya dalam pengambilan evaluasi 2) Proses menganalisis item software untuk mendeteksi perbedaan antara kondisi yang ada dan yang diinginkan dan mengevaluasi fitur dari item perangkat lunak
14
TUJUAN PENGUJIAN PL 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
15
TUJUAN PENGUJIAN PL errors requirements conformance performance
an indication of quality [Adapted from Software Engineering A Practitioner’s Approach 5th Edition, by Pressman, McGraw-Hill, 2000]
16
PENGUJIAN PL white-box methods black-box methods Methods Strategies
Sumber : Software Engineering: A Practitioner’s Approach, 5/e R.S. Pressman 2005
17
PENGUJIAN PL -- PELAKU developer independent tester
Understands the system but, will test "gently" and, is driven by "delivery" independent tester Must learn about the system, but, will attempt to break it and, is driven by quality Sumber : Software Engineering: A Practitioner’s Approach, 5/e R.S. Pressman 2005
18
STRATEGI PENGUJIAN PL Big Bang Incremental
Pengujian PL secara keseluruhan, setelah seluruh komponen PL selesai dibuat Incremental Pengujian Secara bertahap
19
INCREMENTAL Requirements Specification System Testing
Preliminary Design Integration Testing Detailed Design Unit Testing Coding
20
METODA PENGUJIAN PL Functional (Black Box) Structural (White Box)
21
METODA PENGUJIAN PL Functional (Black Box)
Fokus pada output yang dihasilkan dengan memberikan input dan kondisi eksekusi Membandingkan kesesuaian output dengan spesifikasi kebutuhan fungsional
22
FUNCTIONAL (BLACK BOX)
requirements output input events Sumber : Pressmann (2005)
23
STRUCTURAL (WHITE BOX)
Menguji dengan memperhatikan mekanisme internal sistem Menguji untuk memastikan operasi internal berjalan sesuai spesifikasi ... our goal is to ensure that all Semua komponen diuji Sumber : Pressmann (2005) statements and conditions have been executed at least once ...
24
Requirements Analysis Document System Design Document
AKTIVITAS PENGUJIAN PL (1) Requirements Analysis Document Subsystem Code Unit Test System Design Document Tested Subsystem User Manual Subsystem Code Unit Test Tested Subsystem Integration Test Functional Test Functioning System Integrated Subsystems Tested Subsystem Subsystem Code Unit Test All tests by developer All tests by developer
25
Client’s Understanding of Requirements
AKTIVITAS PENGUJIAN PL (2) Client’s Understanding of Requirements Global Requirements User Environment Validated System Accepted System Functioning System Performance Test Acceptance Test Installation Test Usable System Tests by client Tests by client Tests by developer Tests by developer User’s understanding System in Use Tests (?) by user Tests (?) by user
26
UNIT TESTING
27
TUJUAN Mengetahui pengujian perangkat lunak unit (Unit Testing).
Mengetahui jenis-jenis unit testing
28
OUTLINE Pengertian Unit Testing Pengujian Statis Pengujian Black Box
Pengujian White Box
29
Requirements Analysis Document System Design Document
AKTIVITAS PENGUJIAN PL (1) Requirements Analysis Document Subsystem Code Unit Test System Design Document Tested Subsystem User Manual Subsystem Code Unit Test Tested Subsystem Integration Test Functional Test Functioning System Integrated Subsystems Tested Subsystem Subsystem Code Unit Test All tests by developer All tests by developer
30
Client’s Understanding of Requirements
AKTIVITAS PENGUJIAN PL (2) Client’s Understanding of Requirements Global Requirements User Environment Validated System Accepted System Functioning System Performance Test Acceptance Test Installation Test Usable System Tests by client Tests by client Tests by developer Tests by developer User’s understanding System in Sumber : Bruege (2004) Use Tests (?) by user Tests (?) by user
31
UNIT TESTING Pengujian unit (komponen) secara terisolir -7 menguji di luar program yang menggunakan unit ini. Memeriksa apakah suatu individual program unit (subprogram, object class, package, module) memiliki perilaku yang benar.
32
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
33
STATIC TESTING TIPE PENGUJIAN Code Walktrough Code Inspection
34
STATIC TESTING Code Walktrough
Kode program dan dokumentasi di-review oleh tim Fokus ada pada kode program Informal Dipimpin oleh programmer
35
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 -7 penggunaan memori, kecepatan pengolahan Fokus ada pada kode program Informal Dipimpin oleh moderator BUKAN programmer
36
STATIC TESTING Langkah-langkah Code Inspection
Tim reviewer bertemu untuk melakukan review awal -7 overview kode dan tujuan Masing-masing anggota tim bekerja secara individu melakukan inspeksi program dan dokumentasi -7mencatat fault yang ditemukan Tim reviewer bertemu untuk melakukan diskusi terhadap temuan masig-masing
37
BLACK BOX TESTING requirements output input events
Sumber : Pressmann (2005)
38
EQUIVALENCE PARTITIONING
Membagi domain input menjadi kelompok/kelas data di mana test case akan diambil. Contoh: Program menghitung fungsi ( X 1) ( X 2) Fungsi ini mendefinisikan kelas masukan yang valid dan tidak valid : • X < = -2 • -2 < X < 1 • X >= 1 valid invalid valid Test cases di pilih dari kelas masukan ini
39
BOUNDARY VALUE • X < = -2 • -2 < X < 1 • X >= 1
•Test cases dirancang untuk menguji batas domain input. •Digunakan bersama dan saling melengkapi dengan equivalence partitioning. •Misal: • X < = -2 • -2 < X < 1 • X >= 1 -231, -100, -2.1, -2 -1.9, -1, 0, 0.9 1, 1.1,100, 231-1
40
WHITE BOX TESTING Menguji dengan memperhatikan mekanisme internal sistem Menguji untuk memastikan operasi internal berjalan sesuai spesifikasi ... our goal is to ensure that all Semua komponen diuji Sumber : Pressmann (2005) statements and conditions have been executed at least once ...
41
BASIS PATH 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
42
BASIS PATH TESTING Menganalisa rancangan prosedural
Mendefinisikan basis set dari execution paths Test cases untuk basis set mengeksekusi setiap statemen program minimal satu kali.
43
BASIS PATH TESTING Mengubah unit menjadi “flow graph”
Langkah-Langkah Mengubah unit menjadi “flow graph” flow graph : graph berarah dengan sebuah “node awal" dan sebuah “node akhir“. Menghitung ukuran kompleksitas logik unit Menentukan execution paths. Test Case ditentukan berdasarkan execution paths.
44
BASIS PATH TESTING Mengubah unit menjadi “flow graph”
Langkah-Langkah Mengubah unit menjadi “flow graph” flow graph : graph berarah dengan sebuah “node awal" dan sebuah “node akhir“. Menghitung ukuran kompleksitas logik unit Menentukan execution paths. Test Case ditentukan berdasarkan execution paths.
45
BASIS PATH TESTING Flow Graph: penyajian komponen pemrograman terstruktur
46
FLOW GRAPH A,B,C: INTEGER; begin GET(A); GET(B); if A > 15 then
procedure XYZ is A,B,C: INTEGER; begin 1 2 GET(A); GET(B); if A > 15 then if B < 10 then 4. B := A + 5; 5. 6. 7. 8. 9. 10. 3 9 else 4 6 B := A - 5; end if else A := B + 5; end if; 7 10 end XYZ;
47
BASIS PATH TESTING Mengubah unit menjadi “flow graph”
Langkah-Langkah 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.
48
CYCLOMATIC COMPLEXITY
Suatu metric, V(G), yang menggambarkan kompleksitas sebuah flow graph, G. V(G) dihitung dengan menggunakan salah satu formula: V(G) = E - N + 2 E = jumlah edge dalam graph G N = jumlah node dalam G V(G) = R R = jumlah bounded regions dalam G V(G) = P + 1 P = jumlah predikat
49
CYCLOMATIC COMPLEXITY
V(G)=E-N+2 = 4 [sumber: Pressman]
50
CYCLOMATIC COMPLEXITY
Berapa Kompleksitas …. ? 1 2 3 9 4 6 7 10
51
BASIS PATH TESTING Mengubah unit menjadi “flow graph”
Langkah-Langkah Mengubah unit menjadi “flow graph” flow graph : graph berarah dengan sebuah “node awal" dan sebuah “node akhir“. Menghitung ukuran kompleksitas logik unit 3. Menentukan execution paths. Test Case ditentukan berdasarkan execution paths.
52
BASIS PATH SET 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.
53
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.
54
CYCLOMATIC COMPLEXITY
V(G)=E-N+2 = 4 Independent Paths 1: 1,11 2: 1,2,3,4,5,10,1,11 3: 1,2,3,6,8,9,10,1,11 4: 1,2,3,6,7,9,10,1,11 [From SEPA 5/e] V(G): upper bound on number of tests to ensure all code has been executed
55
BASIS PATH SET independent paths: Since V(G) = 4, Path 1: 1,2,3,6,7,8
1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4,...7,8 3 4 5 6 7 8
56
CONTOH -- GCD GCD(a,b) = c For example
Menentukan kelipatan persekutuan terbesar atau “greatest common divisor” (GCD) dari sepasang 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
57
GCD TEST PLAN Merancang algoritma
Menganalisa algoritma dengan menggunakan analisis basic. Menentukan kelas masukan data (equivalence classes) . Menentukan batas equivalence classes. Memilih tests cases -7mencakup basic path set, data dari setiap equivalence class, and data pada dan dekat batas.
58
ALGORITMA GCD 1 5 7 6 9 10 17 18 note: Based on Euclid’s algorithm 1.
2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. function gcd (int a, int b) { int temp, value; a := abs(a); b := abs(b); if (a = 0) then value := b; // b is the GCD 5 7 else if (b = 0) then raise exception; else loop temp := b; b := a mod b; a := temp; until (b = 0) value := a; end if; return value; end gcd 6 9 10 17 18 Sumber : Swenet
59
CONTOH -- GCD 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)
60
CONTOH -- GCD Equivalence Classes
Algoritma GCD menerima nilai integer sebagai masukan input. Maka 0, integer positif dan integer negatif dapat dianggap sebagai batas khusus -7 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, dan b = -231, -1, 0, 1, 231-1
61
GCD Test Plan Anything missing? T est Description / Data
Expected Results T est Experience / Actual Results Basic Path Set path (1,5,6,17,18) -+ (0, 15) 15 path (1,5,7,18) -+ (15, 0) path (1,5,7,9,10,17,18) -+ (30, 15) path (1,5,7,9,10,9,10,17,18) -+ (15, 30) Equiv alence Classes a < 0 and b < (-27, -45) 9 a < 0 and b > (-72, 100) 4 a > 0 and b < (121, -45) 1 a > 0 and b > (420, 252) 28 a = 0 and b < (0, -45) 45 a = 0 and b > (0 , 45) a > 0 and b = (-27, 0) 27 a > 0 and b = (27, 0) a = 0 and b = (0 , 0) exception raised Boundary Points (1 , 0) (-1 , 0) (0 , 1) (0 , -1) (0 , 0) (redundant) (1, 1) (1, -1) (-1, 1) (-1, -1) Anything missing?
62
IMPLEMENTASI PENGUJIAN
Unit yang diuji unit tunggal (mandiri) yang tidak berinteraksi dengan unit lain (seperti GCD), maka dapat ditulis program yang menjalankan test cases yang ada dalam test plan. unit yang harus berinteraksi dengan unit lain -7 lebih sulit dalam melakukan pengujian secara terisolasi.
63
IMPLEMENTASI PENGUJIAN
Langkah-langkah Pengujian Setlah rancangan unit selesai lakukan pengujian statis unit. Membuat test plan untuk unit. Apabila unit yang diuji merujuk unit lain, dan belum selesai, buat stubs untuk unit ini. Buat test driver untuk unit: test case data (from the test plan) Eksekusi unit, menggunakan test case data Hasil ekseksui test case
64
INTEGRATION dan SYSTEM TESTING
65
TUJUAN Mengetahui pengujian perangkat lunak unit
Integration System. Mengetahui jenis-jenis System testing
66
OUTLINE Pengujian Integrasi Pengujian Sistem Functional Testing
Performance Testing Acceptance Testing Installation Testing
67
Requirements Analysis Document System Design Document
AKTIVITAS PENGUJIAN PL (1) Requirements Analysis Document Subsystem Code Unit Test System Design Document Tested Subsystem User Manual Subsystem Code Unit Test Tested Subsystem Integration Test Functional Test Functioning System Integrated Subsystems Tested Subsystem Subsystem Code Unit Test All tests by developer All tests by developer
68
INTEGRATED TESTING integration testing Fokus deteksi fault pada sekelompok komponen/unit, seperti fungsi, kelas, packages. Dua atau lebih komponen diintegrasikan dan diuji. Jika tidak ada, maka komponen lain ditambahkan dan diuji.
69
INTEGRATED TESTING Pendekatan Bottom-up testing Top-down testing
Sandwich Testing
70
BOTTOM UP INTEGRATION (1/3)
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.
71
BOTTOM UP INTEGRATION (2/3)
Dilakukan secara berulang sampai semua sub sistem di uji. Butuh Test Driver: Rutin yang memanggil sub sistem yang diuji dan memberikan test case
72
BOTTOM UP INTEGRATION (3/3) Test E Test B, E, F Test F Test Test C
Layer I Test E B C D Layer II Test B, E, F E F G Layer III Test F Test A, B, C, D, E, F, G Test C Test D,G Test G
73
TOP DOWN INTEGRATION (1/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.
74
TOP DOWN INTEGRATION (2/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.
75
TOP DOWN INTEGRATION (3/3) Test A, B, C, D, E, F, G Test A
Layer I B C D Layer II E F G Layer III Test A, B, C, D, E, F, G Test A Test A, B, C, D Layer I Layer I + II
76
SANDWICH TESTING •Lapis target •lapis di atas target
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
77
SANDWICH TESTING Test E Test B, E, F Bottom Layer Tests Test F Test
Layer I B C D Layer II Test E E F G Layer III Test B, E, F Bottom Layer Tests Test F Test A, B, C, D, E, F, G Test D,G Test G Test A,B,C, D Top Layer Tests Test A
78
MODIFIED SANDWICH TESTING
Test secara paralel: •Lapisan tengah (middle layer) dengan driver dan stub •Top layer dengan stub •Bottom layer dengan driver •Top layer mengakses middle layer (top layer menggantikan driver) •Bottom diakses oleh middle layer (bottom layer menggantikan stub)
79
MODIFIED SANDWICH TESTING Double
Double Test I Test I A Test B Layer I B C D Layer II Test E Triple Triple Test I E F G Layer III Triple Test I Test I Test B, E, F Double Test II Double Test II Test F Test Double Test II Double Test II Test D,G E, F, G Test A,C Test A Test C Double Test I Double Test I
80
LANGKAH INTEGRATION TESTING
Berdasarkan strategi yang dipilih, pilih komponen yang . akan diuji. Lakukan pengujian unit untuk semua komponen. Lakukan persiapan untuk pengujian (pembuatan drivers, stubs) Lakukan functional testing: Definisikan test cases yang menguji semua komponen yang di uji. Lakukan structural testing: Definisikan test cases yang menguji semua komponen yang di uji. 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. Berdasarkan strategi yang dipilih, pilih komponen yang akan diuji. Lakukan pengujian unit untuk semua komponen. Lakukan persiapan untuk pengujian (pembuatan drivers, stubs) Lakukan functional testing: menguji semua komponen yang di uji. Lakukan structural testing: Definisikan test cases yang menguji semua komponen yang di uji. 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 ada.
81
SYSTEM TESTING (1/2) •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.
82
SYSTEM TESTING (2/2) Functional Testing Performance Testing
Acceptance Testing Installation Testing
83
FUNCTIONAL TESTING (1/2)
requirements testing -7 menguji fungsionalitas sistem. Pada esensinya sama dengan pengujian Blackbox Test cases dirancang dari dokumen analisis kebutuhan (mis. user manual) dan berfokus pada kebutuhan dan fungsi utama (mis. use cases)
84
FUNCTIONAL TESTING (2/2)
Pengujian dilakukan dengan memiliki test yang relevan pada pengguna dan memiliki peluang yang besar untuk menemukan failure.
85
PERFORMANCE TESTING (1/3)
Menemukan perbedaan antara goal (kebutuhan non fungsional) yang ditentukan pada saat pengembangan sistem dengaan yang diimplementasikan dalam sistem.
86
PERFORMANCE TESTING (2/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 sangat besar/banyak. Security testing – menguji keamanan sistem (menemukan security faults). Menggunakan hacker untuk menguji sistem.
87
PERFORMANCE TESTING (3/3)
Jenis test: Timing testing – mengevaluasi waktu tanggap (response times) dan waktu untuk melakukan sebuah fungsi Environmental test – menguji toleransi terhadap lingkungan seperti panas, kelembaban, gerak Quality testing – pengujian keandalan, maintain- ability dan availabilitas sistem Recovery testing – pengujian terhadap tanggapan sistem terhadap adanya kesalahan atau ketiadaan data.
88
ACCEPTANCE TESTING 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 -7 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 -7 test tambahan (Pilot Test atau Field Test)
89
PILOT 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).
90
INSTALLATION 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.
Presentasi serupa
© 2024 SlidePlayer.info Inc.
All rights reserved.