P. 1
3. Pengujian Perangkat Lunak

3. Pengujian Perangkat Lunak

|Views: 103|Likes:
Dipublikasikan oleh Tommy Gunawan

More info:

Published by: Tommy Gunawan on Jun 08, 2012
Hak Cipta:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

02/12/2015

pdf

text

original

PENGUJIAN PERANGKAT LUNAK

Oleh Cipta Wahyudi

TUJUAN
• Mengerti apa yang dimaksud dengan Pengujian Perangkat Lunak. • Mengetahui jenis-jenis pengujian perangkat lunak

OUTLINE
• Terminologi • Keandalan PL • Tujuan Pengujian PL • Strategi Pengujian PL • Metoda Pengujian PL • Aktivitas Pengujian PL

• Error: Keadaan di mana sistem berada pada suatu keadaan. . jika sistem terus melakukan proses akan dapat mengakibatkan terjadinya failure. • Failure: Penyimpangan perilaku yang diamati dengan perilaku yang kehendaki.TERMINOLOGI • Reliability: Ukuran kesuksesan yang digunakan untuk mengukur kesesuaian antara perilaku yang terjadi dengan perilaku yang diinginkan. Kesalahan desain atau koding .. Manifestasi dari fault • Fault (bug/defect) penyebab (mekanis atau algoritmis) dari suatu error.

TERMINOLOGI Failure? Error ? Fault ? .

TERMINOLOGI -.ERROR .

ALGORITHMIC FAULT .

MECHANICAL FAULT .

TERMINOLOGI Software Reliability – Keandalan PL • Probablilitas sistem PL yang tidak menyebabkan failure pada sistem pada suatu waktu tertentu dengan kondisi tertentu (IEEE) .

KEANDALAN PL Upaya meningkatkan …. • Fault Avoidance • Pencegahan/Penghindaran • Fault Detection • Deteksi/Penemuan • Fault Tolerance • Dapat diterima .

KEANDALAN PL Fault Handling Fault Avoidance Fault Detection Fault Tolerance Design Methodology Verification Reviews Configuration Management Testing Atomic Transactions Modular Redundancy Debugging Unit Testing Integration Testing System Testing Correctness Debugging Performance Debugging .

DEFINISI (1) Pressman (2005) Pengujian adalah proses eksekusi program dengan tujuan khusus untuk menemukan kesalahan sebelum pengiriman kepada user .

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 .DEFINISI (2) IEEE 1) Proses pengoperasian sistem atau komponen dalam kondisi tertentu.

TUJUAN PENGUJIAN PL • Menemukan kesalahan (fault) sebanyak mungkin dari PL yang diuji • Membuat PL yang diuji. menjadi PL yang berkualitas • Melakukan pengujian secara efektif dan efisien • Mengumpulkan kesalahan yang terjadi dan menggunakannya untuk tindakan preventif . setelah perbaikan dilakukan.

TUJUAN PENGUJIAN PL errors requirements conformance performance an indication of quality [Adapted from Software Engineering A Practitioner’s Approach 5th Edition. McGraw-Hill. by Pressman. 2000] .

PENGUJIAN PL white-box methods black-box methods Methods Strategies Sumber : Software Engineering: A Practitioner’s Approach.S. Pressman 2005 . 5/e R.

but. will test "gently" and. 5/e R. Pressman 2005 .S. is driven by "delivery" independent tester Must learn about the system. will attempt to break it and.PELAKU developer Understands the system but.PENGUJIAN PL -. is driven by quality Sumber : Software Engineering: A Practitioner’s Approach.

setelah seluruh komponen PL selesai dibuat • Incremental • Pengujian Secara bertahap .STRATEGI PENGUJIAN PL • Big Bang • Pengujian PL secara keseluruhan.

INCREMENTAL Requirements Specification System Testing Preliminary Design Integration Testing Detailed Design Unit Testing Coding .

METODA PENGUJIAN PL • 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 .

FUNCTIONAL (BLACK BOX) requirements output input events Sumber : Pressmann (2005) .

.... our goal is to ensure that all statements and conditions have been executed at least once .STRUCTURAL (WHITE BOX) • Menguji dengan memperhatikan mekanisme internal sistem • Menguji untuk memastikan operasi internal berjalan sesuai spesifikasi • Semua komponen diuji Sumber : Pressmann (2005) . .

AKTIVITAS PENGUJIAN PL (1) Subsystem Code Subsystem Code Unit Test Tested Subsystem System Design Document Requirements Analysis Document Unit Test Tested Subsystem User Manual Integration Test Integrated Subsystems Functional Test Functioning System Tested Subsystem Subsystem Code Unit Test All tests by developer All tests by developer .

AKTIVITAS PENGUJIAN PL (2) Global Requirements Validated System Client’s Understanding of Requirements Accepted System User Environment 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 .

UNIT TESTING .

• Mengetahui jenis-jenis unit testing .TUJUAN • Mengetahui pengujian perangkat lunak unit (Unit Testing).

OUTLINE • Pengertian Unit Testing • Pengujian Statis • Pengujian Black Box • Pengujian White Box .

AKTIVITAS PENGUJIAN PL (1) Subsystem Code Subsystem Code Unit Test Tested Subsystem System Design Document Requirements Analysis Document Unit Test Tested Subsystem User Manual Integration Test Integrated Subsystems Functional Test Functioning System Tested Subsystem Subsystem Code Unit Test Sumber : Bruege (2004) All tests by developer All tests by developer .

AKTIVITAS PENGUJIAN PL (2) Global Requirements Validated System Client’s Understanding of Requirements Accepted System User Environment Functioning System Performance Test Acceptance Test Installation Test Usable System Tests by client Tests by client Tests by developer Tests by developer Sumber : Bruege (2004) User’s understanding System in Use Tests (?) by user Tests (?) by user .

. object class.UNIT TESTING • Pengujian unit (komponen) secara terisolir menguji di luar program yang menggunakan unit ini. • Memeriksa apakah suatu individual program unit (subprogram. 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 .

STATIC 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 Inspection
1. 2. Tim reviewer bertemu untuk melakukan review awal overview kode dan tujuan Masing-masing anggota tim bekerja secara individu melakukan inspeksi program dan dokumentasi mencatat fault yang ditemukan Tim reviewer bertemu untuk melakukan diskusi terhadap temuan masig-masing

3.

BLACK BOX TESTING
requirements

output

input

events

Sumber : Pressmann (2005)

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 valid -2 < X < 1 invalid X >= 1 valid • Test cases di pilih dari kelas masukan ini .

1. 0. -2. 1. 231-1 .9.9 X >= 1 1. -1. •Misal: X < = -2 -231.1. -100. 0. •Digunakan bersama dan saling melengkapi dengan equivalence partitioning.BOUNDARY VALUE •Test cases dirancang untuk menguji batas domain input. -2 -2 < X < 1 -1.100.

WHITE BOX TESTING • Menguji dengan memperhatikan mekanisme internal sistem • Menguji untuk memastikan operasi internal berjalan sesuai spesifikasi • Semua komponen diuji Sumber : Pressmann (2005) ... . our goal is to ensure that all statements and conditions have been executed at least once ...

• Memeriksa struktur data internal .BASIS PATH TESTING • Seluruh independent path diuji • Menguji semua pernyataan untuk nilai ‘true’ dan ‘false’ • Mengesekusi semua kalang (loop) untuk kondisi-kondisi batas.

BASIS PATH TESTING • Menganalisa rancangan prosedural • Mendefinisikan basis set dari execution paths • Test cases untuk basis set mengeksekusi setiap statemen program minimal satu kali. .

. 2.BASIS PATH TESTING Langkah-Langkah 1. Menentukan execution paths. Mengubah unit menjadi “flow graph” • flow graph : graph berarah dengan sebuah “node awal" dan sebuah “node akhir“. Test Case ditentukan berdasarkan execution paths. Menghitung ukuran kompleksitas logik unit 3.

BASIS PATH TESTING Langkah-Langkah 1. Test Case ditentukan berdasarkan execution paths. . Menghitung ukuran kompleksitas logik unit 3. 2. Mengubah unit menjadi “flow graph” • flow graph : graph berarah dengan sebuah “node awal" dan sebuah “node akhir“. Menentukan execution paths.

BASIS PATH TESTING Flow Graph: penyajian komponen pemrograman terstruktur .

begin 1. else 9. B := A . else 6. if A > 15 then 3. 2. end if. 7. A := B + 5. if B < 10 then 4. 1 2 3 9 4 6 7 10 .5.B.FLOW GRAPH procedure XYZ is A.C: INTEGER. B := A + 5. 5. GET(B). 10. GET(A). end XYZ. end if 8.

Test Case ditentukan berdasarkan execution paths.BASIS PATH TESTING Langkah-Langkah 1. . 2. Menentukan execution paths. Mengubah unit menjadi “flow graph” • flow graph : graph berarah dengan sebuah “node awal" dan sebuah “node akhir“. Menghitung ukuran kompleksitas logik unit 3.

N + 2 • E = jumlah edge dalam graph G • N = jumlah node dalam G 2. V(G) = P + 1 • P = jumlah predikat . G. yang menggambarkan kompleksitas sebuah flow graph. V(G). V(G) = E . V(G) dihitung dengan menggunakan salah satu formula: 1.CYCLOMATIC COMPLEXITY • • Suatu metric. V(G) = R • R = jumlah bounded regions dalam G 3.

CYCLOMATIC COMPLEXITY V(G)=E-N+2 = 4 [sumber: Pressman] .

? 1 2 3 9 4 6 7 10 .CYCLOMATIC COMPLEXITY • Berapa Kompleksitas ….

Menentukan execution paths. . Test Case ditentukan berdasarkan execution paths. Mengubah unit menjadi “flow graph” • flow graph : graph berarah dengan sebuah “node awal" dan sebuah “node akhir“. Menghitung ukuran kompleksitas logik unit 3.BASIS PATH TESTING Langkah-Langkah 1. 2.

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

• V(G) memberikan batas atas (upper bound) jumlah independent paths yang dibutuhkan. .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.

6.8.11 2: 1.1.5.3.CYCLOMATIC COMPLEXITY V(G)=E-N+2 = 4 Independent Paths 1: 1.10.6.3.7.2.1.11 4: 1.4.11 [From SEPA 5/e] V(G): upper bound on number of tests to ensure all code has been executed .3.1.10.10.11 3: 1.9.9.2.2.

2.6.4.7.4.2.7.2...5.7.3.BASIS PATH SET independent paths: 1 Since V(G) = 4.2..8 1.8 1.8 7 8 .8 1.4.7.3.2. 2 3 4 5 6 Path 1: Path 2: Path 3: Path 4: 1.7.

0) = 13 GCD(0.13) = 1 GCD(-12.GCD • Menentukan kelipatan persekutuan terbesar atau “greatest common divisor” (GCD) dari sepasang bilangan (kedua bilangan tdk nol). 0) tidak terdefinisi . 27) = 9 GCD (7.b) = c c bilangan positif integer c pembagi bersama a dan b (c membagi a dan c membagi b) • For example GCD(45. 15) = 3 GCD(13.CONTOH -. • GCD(a.

4. 3. Merancang algoritma 2. and data pada dan dekat batas. Menentukan batas equivalence classes. Memilih tests cases mencakup basic path set. Menganalisa algoritma dengan menggunakan analisis basic.GCD TEST PLAN 1. 5. . Menentukan kelas masukan data (equivalence classes) . data dari setiap equivalence class.

end gcd Sumber : Swenet 1 5 7 9 6 10 17 18 . value := a. int b) { 2. temp := b. b := abs(b). value. until (b = 0) 15. 17. 14. else 10. 16. 12. 3. end if. value := b. // b is the GCD 7. int temp. b := a mod b. 18.ALGORITMA GCD note: Based on Euclid’s algorithm 1. a := temp. return value. if (a = 0) then 6. loop 11. else if (b = 0) then 8. 9. raise exception. 5. function gcd (int a. a := abs(a). 4. 13.

5.18). (1.17.5.CONTOH -.17.10.18).17.7.18) .GCD • Basic Path Set V(G) = 4 (1.9.9.18).5.5.10.9.7. (1.7.6.10. (1.

a = 0 dan b = 0 • Nilai Batas • a = -231. 1. a = 0 dan b > 0 • a > 0 dan b = 0. integer positif dan integer negatif dapat dianggap sebagai batas khusus didapat: • a < 0 dan b < 0.CONTOH -. a < 0 dan b > 0. a > 0 dan b < 0 • a > 0 dan b > 0. 1. a = 0 dan b < 0. 231-1 . 231-1 dan b = -231.GCD • Equivalence Classes • Algoritma GCD menerima nilai integer sebagai masukan input. Maka 0. 0. -1. -1. 0. a > 0 dan b = 0.

15) 15 path (1.5. 0) 1 (0 . 0) 1 (-1 . 252) 28 a = 0 and b < 0 (0. 45) 45 a > 0 and b = 0 (-27. 1) 1 (-1. 0) 27 a > 0 and b = 0 (27. 0) 15 path (1. 15) 15 path (1. 100) 4 a > 0 and b < 0 (121.GCD Test Plan Test Description / Data Expected Results Basic Path Set path (1.18) (30. 1) 1 (0 .17. 0) 27 a = 0 and b = 0 (0 . 0) exception raised Boundary Points (1 .18) (0.18) (15.18) (15.17.5.5.10. -1) 1 (-1. -1) 1 (0 .5. -45) 45 a = 0 and b > 0 (0 .7.7. -45) 1 a > 0 and b > 0 (420. -45) 9 a < 0 and b > 0 (-72.9.10.10.6.17. 0) (redundant) exception raised (1.9. 1) 1 (1. 30) 15 Equivalence Classes a < 0 and b < 0 (-27. -1) 1 Test Experience / Actual Results Anything missing? .7.9.

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 lebih sulit dalam melakukan pengujian secara terisolasi. .

Apabila unit yang diuji merujuk unit lain. 4.IMPLEMENTASI PENGUJIAN Langkah-langkah Pengujian 1. 2. Buat test driver untuk unit: • test case data (from the test plan) • Eksekusi unit. Setlah rancangan unit selesai lakukan pengujian statis unit. Membuat test plan untuk unit. dan belum selesai. buat stubs untuk unit ini. menggunakan test case data • Hasil ekseksui test case . 3.

INTEGRATION dan SYSTEM TESTING .

• Mengetahui jenis-jenis System testing .TUJUAN • Mengetahui pengujian perangkat lunak unit • Integration • System.

OUTLINE • Pengujian Integrasi • Pengujian Sistem • Functional Testing • Performance Testing • Acceptance Testing • Installation Testing .

AKTIVITAS PENGUJIAN PL (1) Subsystem Code Subsystem Code Unit Test Tested Subsystem System Design Document Requirements Analysis Document Unit Test Tested Subsystem User Manual Integration Test Integrated Subsystems Functional Test Functioning System Tested Subsystem Subsystem Code Unit Test All tests by developer All tests by developer .

maka komponen lain ditambahkan dan diuji. kelas. • Dua atau lebih komponen diintegrasikan dan diuji.integration testing INTEGRATED TESTING • Fokus deteksi fault pada sekelompok komponen/unit. . • Jika tidak ada. seperti fungsi. packages.

INTEGRATED TESTING Pendekatan • Bottom-up testing • Top-down testing • Sandwich Testing .

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

• Butuh Test Driver: • Rutin yang memanggil sub sistem yang diuji dan memberikan test case .BOTTOM UP INTEGRATION (2/3) • Dilakukan secara berulang sampai semua sub sistem di uji.

C. G Test D. E.G Test G . B.BOTTOM UP INTEGRATION (3/3) A Layer I Test E Test B. E. F Test F Test C B C D Layer II E F G Layer III Test A. D. F.

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.

• 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) • Dilakukan secara berulang sampai semua sub sistem di uji. .

D Test A. D. B.TOP DOWN INTEGRATION (3/3) A Layer I B C D Layer II E F G Layer III Test A Test A. F. C. E. B. C. G Layer I Layer I + II .

• 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 • Kombinasi pendekatan top-down strategy dan bottom-up.

D.B. F Test F Test A. C.SANDWICH TESTING A B C D Layer I Layer II Test E E F G Layer III Bottom Layer Tests Test B.C. E. D Top Layer Tests Test A .G Test G Test A. E. F. G Test D. B.

MODIFIED 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 Double Double Test II Test D A Test B B C Layer I Layer II Test E Triple Triple Test II Test Test F Test D Double Double Test II Test II Test D. E. E. C. F Triple Triple Test II Test E F G Layer III Double Double Test II Test II .C Test A Test C Double Double Test II Test Test A. B. D. F.G Test G Test A. G Test B.

Lakukan akan diuji. Lakukan functional testing: Definisikan test cases yang Definisikan test cases yang menguji semua komponen menguji semua komponen yang di uji.LANGKAH INTEGRATION TESTING 1. Lakukan persiapan untuk 2. pilih komponen yang dipilih. Berdasarkan strategi yang 1. activitas pengujian. ada. pengujian unit untuk semua pengujian unit untuk semua komponen. Lakukan persiapan untuk pengujian (pembuatan pengujian (pembuatan drivers. 5. 2. keseluruhan sistem diuji. 4. Lakukan structural testing: Lakukan structural testing: Definisikan test cases yang Definisikan test cases yang menguji semua komponen menguji semua komponen yang di uji. Tujuan integration testing adalah Tujuan integration testing adalah mengidentifikasi errors dalam mengidentifikasi errors dalam konfigurasi komponen yang konfigurasi komponen yang ada. 7. stubs) drivers. . Lakukan performance tests Lakukan performance tests Simpan record test cases dan Simpan record test cases dan activitas pengujian. yang di uji. 6. Lakukan . pilih komponen yang akan diuji. 5. stubs) 3. komponen. Ulangi langkah 1 to 6 sampai Ulangi langkah 1 to 6 sampai keseluruhan sistem diuji. Berdasarkan strategi yang dipilih. 4. 7. yang di uji. Lakukan functional testing: 3. 6.

. •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) •Dilakukan setelah komponen-komponen diintegrasikan.

SYSTEM TESTING (2/2) • Functional Testing • Performance Testing • Acceptance Testing • Installation Testing .

• 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) .FUNCTIONAL TESTING (1/2) • requirements testing menguji fungsionalitas sistem.

.FUNCTIONAL TESTING (2/2) • Pengujian dilakukan dengan memiliki test yang relevan pada pengguna dan memiliki peluang yang besar untuk menemukan failure.

.PERFORMANCE TESTING (1/3) • Menemukan perbedaan antara goal (kebutuhan non fungsional) yang ditentukan pada saat pengembangan sistem dengaan yang diimplementasikan dalam sistem.

• Security testing – menguji keamanan sistem (menemukan security faults).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. Menggunakan hacker untuk menguji sistem. .

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. gerak • Quality testing – pengujian keandalan. maintain. kelembaban.ability dan availabilitas sistem • Recovery testing – pengujian terhadap tanggapan sistem terhadap adanya kesalahan atau ketiadaan data. .

bukan developer.ACCEPTANCE TESTING • Tujuan :: menunjukkan bahwa sistem sudah siap • Tujuan menunjukkan bahwa sistem sudah siap untuk pemakaian operasional. bukan developer. bukan oleh developer atau testers test tambahan (Pilot Test atau Field Test) test tambahan (Pilot Test atau Field Test) . • Kebanyakan bug dalam perangkat lunak • Kebanyakan bug dalam perangkat lunak biasanya ditemukan oleh client setelah sistem biasanya ditemukan oleh client setelah sistem digunakan. bukan oleh developer atau testers digunakan. untuk pemakaian operasional. • Dilakukan oleh client. • Pilihan test dibuat oleh client/sponsor • Pilihan test dibuat oleh client/sponsor • Banyak test dapat diambil dari integration testing • Banyak test dapat diambil dari integration testing • Dilakukan oleh client.

• Perangkat lunak digunakan dalam setting terkendali. • Pengembang tidak ada • Pengembang tidak ada • Perangkat lunak digunakan dalam lingkungan yang • Perangkat lunak digunakan dalam lingkungan yang sebenarnya (target environment).PILOT TESTING • Alpha test: • Alpha test: • Client menggunakan perangkat lunak di tempat • Client menggunakan perangkat lunak di tempat pengembang (development environment). . • Beta test: • Beta test: • Dilakukan tempat pengguna (lingkungan yang • Dilakukan tempat pengguna (lingkungan yang sebenarnya). yang terjadi. sebenarnya). pengembang selalu siap untuk memperbaiki kesalahan pengembang selalu siap untuk memperbaiki kesalahan yang terjadi. sebenarnya (target environment). pengembang (development environment). • Perangkat lunak digunakan dalam setting terkendali.

Beberapa kebutuhan mungkin tidak bisa diuji dalam development environment sehingga perlu dibuat test cases yang baru.INSTALLATION TESTING • • Sistem di install pada target environment dan dievalusi. • . Mengulangi test cases yang dieksekusi selama functional dan performance testing dalam target environment.

You're Reading a Free Preview

Mengunduh
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->