PENGUJIAN PERANGKAT LUNAK. Oleh Cipta Wahyudi

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

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

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

Design Methodology Verification

Fault Detection

Fault Tolerance

Atomic Transactions

Reviews

Modular Redundancy

Configuration Management Debugging

Testing

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

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

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

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]

PENGUJIAN PL black-box methods

white-box methods

Methods Strategies Sumber : Software Engineering: A Practitioner’s Approach, 5/e R.S. Pressman 2005

PENGUJIAN PL -- PELAKU

developer 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

STRATEGI PENGUJIAN PL • Big Bang • Pengujian PL secara keseluruhan, setelah seluruh komponen PL selesai dibuat

• Incremental • Pengujian Secara bertahap

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)

STRUCTURAL (WHITE BOX) • 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 ...

AKTIVITAS PENGUJIAN PL (1) Subsystem Code Subsystem Code

Unit Test Tested Subsystem

System Design Document

Requirements Analysis Document


Integration Test

Functional Test Integrated Subsystems

Tested Subsystem

Subsystem Code

Unit Test All Alltests testsby bydeveloper developer

User Manual

Functioning System

AKTIVITAS PENGUJIAN PL (2) Client’s Understanding of Requirements

Global Requirements

Functioning System

Performance Test

Validated System

Acceptance Test

Accepted System

User Environment

Installation Test Usable System

Tests Testsby byclient client Tests Testsby bydeveloper developer

User’s understanding

System in Use Tests Tests(?) (?) by byuser user

UNIT TESTING

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

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






Integration Test


Tested Subsystem

Subsystem Code

Unit Test Sumber : Bruege (2004)

All Alltests testsby bydeveloper developer

User Manual

Functioning System

AKTIVITAS PENGUJIAN PL (2) Client’s Understanding of Requirements

Global Requirements

Functioning System

Performance Test

Validated System

Acceptance Test

Accepted System

User Environment

Installation Test Usable System

Tests Testsby byclient client Tests Testsby bydeveloper developer

User’s understanding

System in Use

Sumber : Bruege (2004)

Tests Tests(?) (?) by byuser user

UNIT TESTING • 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

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.

3.

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

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

BOUNDARY VALUE •Test cases dirancang untuk menguji batas domain input. •Digunakan bersama dan saling melengkapi dengan 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

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

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

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 pemrograman terstruktur

FLOW GRAPH 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 2

9

3

4

6

7

10




CYCLOMATIC COMPLEXITY • •

Suatu metric, V(G), yang menggambarkan kompleksitas sebuah flow graph, G. V(G) dihitung dengan menggunakan salah satu formula:

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 …. ? 1 2

9

3

4

6

7

10




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.

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.

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

BASIS PATH SET independent paths: 1

Since V(G) = 4, 2

3 4 5

7

8

6

Path 1: Path 2: Path 3: Path 4:

1,2,3,6,7,8 1,2,3,5,7,8 1,2,4,7,8 1,2,4,7,2,4,...7,8

CONTOH -- GCD • 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

GCD TEST PLAN 1. Merancang algoritma 2. Menganalisa algoritma dengan menggunakan 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.

ALGORITMA GCD note: Based on Euclid’s algorithm 1. function gcd (int a, int b) { 2. int temp, value; 3. a := abs(a); 4. b := abs(b); 5. if (a = 0) then 6. value := b; // b is the GCD 7. else if (b = 0) then 8. 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 Sumber : Swenet

1

5 7 9

6

10 17

18

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)

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

GCD Test Plan Test Description / Data Expected Results Basic Path Set path (1,5,6,17,18) 15 (0, 15) path (1,5,7,18) (15, 0) 15 path (1,5,7,9,10,17,18) 15 (30, 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?

Test Experience / Actual Results

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.

IMPLEMENTASI PENGUJIAN Langkah-langkah Pengujian 1. Setlah rancangan unit selesai lakukan pengujian statis unit. 2. Membuat test plan untuk unit. 3. Apabila unit yang diuji merujuk unit lain, dan belum selesai, 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

INTEGRATION dan SYSTEM TESTING

TUJUAN • Mengetahui pengujian perangkat lunak unit • Integration • System.

• Mengetahui jenis-jenis System testing

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






Integration Test


Tested Subsystem

Subsystem Code

Unit Test All Alltests testsby bydeveloper developer

User Manual

Functioning System

integration testing

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

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.

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

BOTTOM UP INTEGRATION (3/3) A Layer I

Test E

C

B

Test B, E, F

E

F

Test F Test A, B, C, D, E, F, G

Test C

Test D,G Test G

D

G

Layer II

Layer III

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.

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.

TOP DOWN INTEGRATION (3/3) A Layer I

C

B

E

Test A

Test A, B, C, D

Layer I Layer I + II

D

G

F

Test A, B, C, D, E, F, G

Layer II

Layer III

SANDWICH TESTING • 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

C

B

Layer I D

Layer II

Test E E

Bottom Layer Tests

G

Test B, E, F Test F

Test D,G Test G Test A,B,C, D Top Layer Tests

F

Test A


Layer III

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 TestII

A Layer I

Test B C

B

D

Layer II

Test E Triple Triple Test TestII

Triple Triple Test TestII

Test B, E, F

E

F

Test D Test D,G Test G Test A,C Test A Test C

Double Double Test TestII

Layer III

Double Double Test TestIIII

Test F

Double Double Test TestIIII

G


LANGKAH INTEGRATION TESTING 1. 1. Berdasarkan Berdasarkanstrategi strategiyang yang dipilih, dipilih,pilih pilihkomponen komponenyang yang akan akandiuji. diuji.Lakukan Lakukan . pengujian pengujianunit unituntuk untuksemua semua komponen. komponen. 2. 2. Lakukan Lakukanpersiapan persiapanuntuk untuk pengujian pengujian(pembuatan (pembuatan drivers, drivers,stubs) stubs) 3. 3. Lakukan Lakukanfunctional functionaltesting: testing: Definisikan Definisikantest testcases casesyang yang menguji mengujisemua semuakomponen komponen yang yangdi diuji. uji.

4. 4.

Lakukan Lakukanstructural structuraltesting: testing:

5. 5. 6.6.

Lakukan Lakukanperformance performancetests tests Simpan Simpanrecord recordtest testcases casesdan dan activitas activitaspengujian. pengujian. Ulangi Ulangilangkah langkah11 to to66sampai sampai keseluruhan keseluruhansistem sistemdiuji. diuji.

7. 7.

Definisikan Definisikantest testcases casesyang yang menguji mengujisemua semuakomponen komponen yang yangdi diuji. uji.

Tujuan Tujuanintegration integrationtesting testingadalah adalah mengidentifikasi mengidentifikasierrors errorsdalam dalam konfigurasi konfigurasikomponen komponenyang yang ada. ada.

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.

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

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

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.

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.

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.

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

PILOT TESTING •• Alpha Alphatest: test:

••Client Clientmenggunakan menggunakanperangkat perangkatlunak lunakdi ditempat tempat pengembang pengembang(development (developmentenvironment). environment). ••Perangkat Perangkatlunak lunakdigunakan digunakandalam dalamsetting settingterkendali, terkendali, pengembang pengembangselalu selalusiap siapuntuk untukmemperbaiki memperbaikikesalahan kesalahan yang yangterjadi. terjadi. •• Beta Betatest: test:

••Dilakukan Dilakukantempat tempatpengguna pengguna(lingkungan (lingkunganyang yang sebenarnya). sebenarnya). ••Pengembang Pengembangtidak tidakada ada ••Perangkat Perangkatlunak lunakdigunakan digunakandalam dalamlingkungan lingkunganyang yang sebenarnya sebenarnya(target (targetenvironment). environment).

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.

PENGUJIAN PERANGKAT LUNAK. Oleh Cipta Wahyudi

Recommend Documents