PENGUJIAN PERANGKAT LUNAK. Oleh Cipta Wahyudi

(1)

PENGUJIAN PERANGKAT

LUNAK

Oleh

(2)

• Mengerti apa yang dimaksud dengan

Pengujian Perangkat Lunak.

• Mengetahui jenis-jenis pengujian perangkat

lunak

(3)

• Terminologi

• Keandalan PL

• Tujuan Pengujian PL

• Strategi Pengujian PL

• Metoda Pengujian PL

• Aktivitas Pengujian PL

OUTLINE

(4)

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

Failure?

Error ?

Fault ?

(6)

(7)

ALGORITHMIC

FAULT

(8)

MECHANICAL

FAULT

(9)

Software Reliability – Keandalan PL

• Probablilitas sistem PL yang tidak

menyebabkan failure pada sistem

pada suatu waktu tertentu dengan

kondisi tertentu (IEEE)

(10)

Upaya meningkatkan ….

• Fault Avoidance

• Pencegahan/Penghindaran

• Fault Detection

• Deteksi/Penemuan

• Fault Tolerance

• Dapat diterima

KEANDALAN PL

(11)

KEANDALAN PL

Testing

Fault Handling

Fault Avoidance Fault Detection Fault Tolerance

Debugging Unit Testing Integration Testing System Testing Verification Configuration Management Atomic Transactions Modular Redundancy Correctness Debugging Performance Debugging Reviews Design Methodology

(12)

Pressman (2005)

DEFINISI (1)

Pengujian adalah proses eksekusi

program dengan tujuan khusus untuk menemukan kesalahan sebelum

(13)

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)

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

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

Methods Strategies white-box methods black-box methods

(17)

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

(18)

• Big Bang

• Pengujian PL secara keseluruhan, setelah seluruh komponen PL selesai dibuat

• Incremental

• Pengujian Secara bertahap

STRATEGI PENGUJIAN

PL

(19)

INCREMENTAL

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

(20)

• Functional (Black Box)

• Structural (White Box)

(21)

• 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 requirements events events input input output output Sumber : Pressmann (2005)

(23)

• Menguji dengan memperhatikan mekanisme internal sistem • Menguji untuk memastikan operasi internal berjalan sesuai spesifikasi

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

(24)

AKTIVITAS PENGUJIAN PL (1)

Tested Subsystem Subsystem Code Functional Integration Unit Tested Subsystem Requirements Analysis Document System Design Document Tested Subsystem Test _Test Test Unit Test Unit Test User Manual Requirements Analysis Document Subsystem Code Subsystem Code

All tests by developer All tests by developer

Functioning System Integrated

(25)

Global Requirements User’s understanding Tests by developer Tests by developer Performance Acceptance Client’s Understanding of Requirements Test Functioning System Test Installation User Environment Test System in Use Usable System Validated System Accepted System Tests (?) by user Tests (?) by user Tests by client Tests by client

AKTIVITAS PENGUJIAN PL (2)

(26)

(27)

• Mengetahui pengujian perangkat lunak unit

(Unit Testing).

• Mengetahui jenis-jenis unit testing

(28)

• Pengertian Unit Testing

• Pengujian Statis

• Pengujian

Black Box

• Pengujian White Box

(29)

AKTIVITAS PENGUJIAN PL (1)

Subsystems

(30)

Global Requirements User’s understanding Tests by developer Tests by developer Performance Acceptance Client’s Understanding of Requirements Test Functioning System Test Installation User Environment Test System in Use Usable System Validated System Accepted System Tests (?) by user Tests (?) by user Tests by client Tests by client

AKTIVITAS PENGUJIAN PL (2)

Sumber : Bruege (2004)

(31)

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

(32)

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)

TIPE PENGUJIAN

• Code Walktrough

• Code Inspection

(34)

Code Walktrough

• Kode program dan dokumentasi di-review oleh tim

• Fokus ada pada kode program • Informal

• Dipimpin oleh programmer

(35)

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

(36)

Langkah-langkah Code Inspection

1. Tim reviewer bertemu untuk melakukan review awal overview kode dan tujuan

2. Masing-masing anggota tim bekerja secara individu melakukan inspeksi program dan

dokumentasi mencatat fault yang ditemukan

3. Tim reviewer bertemu untuk melakukan diskusi terhadap temuan masig-masing

(37)

requirements requirements events events input input output output Sumber : Pressmann (2005)

(38)

• Membagi domain input menjadi

kelompok/kelas data di mana test case akan diambil.

• Contoh: Program menghitung fungsi

• 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

) 2 ( ) 1 (X − ∗ X +

EQUIVALENCE

PARTITIONING

(39)

•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

(40)

• Menguji dengan memperhatikan mekanisme internal sistem • Menguji untuk memastikan operasi internal berjalan sesuai spesifikasi

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

(41)

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

• Menganalisa rancangan prosedural

• Mendefinisikan basis set dari execution paths

• Test cases untuk basis set mengeksekusi

setiap statemen program minimal satu kali.

(43)

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.

(44)

Langkah-Langkah

(45)

Flow Graph: penyajian komponen pemrograman terstruktur

(46)

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

(47)

Langkah-Langkah

(48)

• 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

(49)

V(G)=E-N+2 = 4

[sumber: Pressman]

CYCLOMATIC

COMPLEXITY

(50)

• Berapa Kompleksitas …. ?

CYCLOMATIC

COMPLEXITY

1 3 9 10 4 6 2 7

(51)

Langkah-Langkah

(52)

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

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

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

V(G): upper bound on number of tests to ensure all code has been executed

[From SEPA 5/e]

CYCLOMATIC

COMPLEXITY

(55)

independent paths: independent paths: Since V(G) = 4, Since V(G) = 4, Path 1: 1,2,3,6,7,8 Path 1: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 2: 1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4,...7,8 Path 4: 1,2,4,7,2,4,...7,8 1 1 2 2 3 3 4 4 5 5 66 7 7 8 8

(56)

• 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

CONTOH -- GCD

(57)

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.

(58)

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 1 5 10 9 17 7 6 18

ALGORITMA GCD

Sumber : Swenet

(59)

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

• 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, 2}31_{-1 dan b = -2}31_{, -1, 0, 1, 2}31_-1

(61)

GCD Test Plan

Test 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

Equiv alence 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

(62)

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

(63)

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

IMPLEMENTASI

PENGUJIAN

(64)

INTEGRATION dan SYSTEM

TESTING

(65)

• Mengetahui pengujian perangkat

lunak unit

• Integration • System.

• Mengetahui jenis-jenis System testing

(66)

• Pengujian Integrasi

• Pengujian Sistem

• Functional Testing • Performance Testing • Acceptance Testing • Installation Testing

OUTLINE

(67)

AKTIVITAS PENGUJIAN PL (1)

(68)

• 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

(69)

Pendekatan

• Bottom-up testing

• Top-down testing

• Sandwich Testing

(70)

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

(71)

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

(72)

A B C D G F E 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)

(73)

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

(74)

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

(75)

A B C D G F E 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)

(76)

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

A B C D G F E Layer I Layer II Layer III Test E Test D,G Test B, E, F Test F Test G Test A Bottom Layer Tests Top Layer Tests Test A,B,C, D Test A, B, C, D, E, F, G

SANDWICH TESTING

(78)

• 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

(79)

A B C D G F E Layer I Layer II Layer III Test F Test E Test B Test G Test D Test A Test C Test B, E, F Triple Test I Triple Test I Triple Test I Triple Test I Test D,G Double Test II Double Test II Double Test II Double Test II Double Test I Double Test I Double Test I Double Test I Test A,C Test A, B, C, D, E, F, G

MODIFIED SANDWICH TESTING

(80)

.

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

(81)

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

• Functional Testing

• Performance Testing

• Acceptance Testing

• Installation Testing

(83)

• _{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

(1/2)

(84)

• Pengujian dilakukan dengan memiliki test yang relevan pada pengguna dan memiliki peluang yang besar untuk menemukan failure.

FUNCTIONAL TESTING

(2/2)

(85)

• Menemukan perbedaan antara goal (kebutuhan non fungsional) yang

ditentukan pada saat pengembangan sistem dengaan yang diimplementasikan dalam sistem.

PERFORMANCE TESTING

(1/3)

(86)

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

(2/3)

(87)

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.

PERFORMANCE TESTING

(3/3)

(88)

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

(89)

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

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