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


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


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


Tested Subsystem

SubsystemCode


Unit

TestedSubsystem


Document

SystemDesign

Document

Tested Subsystem

Test Test

Test

Unit Test

Unit Test

User Manual


Document

SubsystemCode

SubsystemCode


FunctioningSystem


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


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

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







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]


• Berapa Kompleksitas …. ?


1

3 9

10

4 6

2

7

Langkah-Langkah







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]


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


Tested Subsystem

SubsystemCode


Unit

TestedSubsystem


Document

SystemDesign

Document

Tested Subsystem

Test Test

Test

Unit Test

Unit Test

User Manual


Document

SubsystemCode

SubsystemCode


FunctioningSystem


• 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


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


• 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.


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


• 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:



yang di uji.

4. Lakukan structural testing:



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:



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.


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.


• 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

3. pengujian perangkat lunak

Documents