Pengujian Cacat Defect Testing l Pengujian program untuk

Pengujian Cacat (Defect Testing) l Pengujian program untuk mengungkap adanya cacat pada sistem Perangkat Lunak ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 1

Tujuan l l Untuk memahami sejumlah teknik pengujian yang digunakan untuk menemukan kesalahan program Mengetahui panduan yang mendukung pengujian interface komponen Memahami pendekatan spesifik bagi pengujian komponen dan pengujian ntegrasi untuk sistem berorientasi objek Memahami prinsip kerja pendukung alat bantu CASE untuk pengujian ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 2

Pembahasan l l Defect testing (Pengujian cacat) Integration testing (Pengujian integrasi) Object-oriented testing (Pengujian berbasis objek) Testing workbenches (meja kerja pengujian) ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 3

Proses Pengujian l Pengujian Komponen • • • l Berhubungan dengan pengujian berfungsinya komponen Biasanya merupakan tanggung jawab programmer Tes dilakukan berdasarkan pengalaman programer Pengujian Integrasi • • • Menguji sekumpulan komponen yang terintegrasi sehingga membentuk sebuah sistem atau sub sistem Merupakan tanggung jawab team penguji independent Tes dilakukan berdasarkan spesifikasi sistem ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 4

Testing phases ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 5

Pengujian Cacat l l Tujuannya adalah untuk mengungkap cacat pada program Pengujian yg berhasil adalah pengujian yang menyebabkan sistem berprilaku tidak benar shg dapat diungkapkan bahwa adanya cacat pada program tersebut Pengujian ini menunjukkan keberadaan bukan tidak adanya kesalahan program Berlawanan dengan pengujian validasi yang menuntut sistem berlaku benar ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 6

Testing priorities l l Only exhaustive testing can show a program is free from defects. However, exhaustive testing is impossible Tests should exercise a system's capabilities rather than its components Testing old capabilities is more important than testing new capabilities Testing typical situations is more important than boundary value cases ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 7

Test data and test cases l l Test data Inputs which have been devised to test the system Test cases Inputs to test the system and the predicted outputs from these inputs if the system operates according to its specification ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 8

The defect testing process Kasus Uji Rancang kasus uji ©Ian Sommerville 2000 Tdata uji Siapkan data uji Hasil uji Jalankan prog dgn data uji Software Engineering, 6 th edition. Chapter 20 s Laporan uji Bandingkan hasil dgn kasus uji Slide 9

Pengujian cacat terdiri dari : l l Black-box testing Partisi equivalensi Pengujian struktural Pengujian jalur ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 10

Black-box testing l l Pengujian berdasarkan pada spesifikasi sistem program dianggap sebagai sebuah ‘black-box’ yg prilakunya hanya dapat ditentukan dgn mempelajari input dan output yg berkaitan Perencanaan uji dapat dilakukan di awal Disebut juga pengujian fungsionalitas (bukan implementasi PL) ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 11

Black-box testing Jika output bukan merupakan yang diramalkan, berarti uji tsb telah berhasil mendeteksi masalah dgn PL tsb I e Input test data Input yg menyebabkan prilaku menyimpang System Outputtest results ©Ian Sommerville 2000 Oe Output yg mengungkap adanya cacat Software Engineering, 6 th edition. Chapter 20 Slide 12

Partisi Equivalensi l l l Data Input dan hasil output biasanya masuk dalam sejumlah kelas yang berbeda namun memiliki karakteristik yang sama. Mis : bil positif, bil negatif, string tanpa blank, dll Program biasanya berlaku dengan cara yg dapat dibandingkan untuk semua anggota kelas Bagitu satu himpunan partisi telah diidentifikasikan, kemudian dipilihlah kasus uji dari setiap partisi ini ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 13

Partisi Equivalesi ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 14

Partisi Equivalesi l Identifikasikan Himpunan Partisi input dan output ke dalam sebuat bentuk equivalensi • l Mis : Spesifikasi program menyatakan bahwa program menerima 4 sampai 10 input yang 5 digit bilangan bulat antara 10. 000 dan 99. 999 Partisi equivalensinya adalah <10. 000, 10. 000 -99. 999 dan > 99. 999 Pilih kasus uji pada batasan dari himpunan tersebut • 00000, 09999, 10000, 99999, 10001 ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 15

Equivalence partitions ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 16

Search routine specification mencari sederet elemen untuk elemen tertentu (kunci) procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Pre-condition -- the array has at least one element T’FIRST <= T’LAST Post-condition -- the element is found and is referenced by L kondisi pra menyatakan ( Found and T (L) = Key) or rutin search dirancang utk -- the element is not in the array bekerja dengan deret ( not Found and not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key )) kosong Kondisi pasca menyatakan variavel Found diset jika elemen kunci ada pd deret ©Ian Sommerville 2000 Posisi elemen kunci ditunjukkan oleh indeks L dan tidak didefenisikan jika elemen tidak berada dalam deret Software Engineering, 6 th edition. Chapter 20 Slide 17

Partisi input - Search routine l l Input yg cocok dengan kondisi pra Input yg tidak cocok dengan kondisi pra Input yg key elemennya merupakan anggota array Input yg key elemennya bukan anggota array ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 18

Testing guidelines (sequences) l l l Uji PL dengan deret yang hanya memiliki 1 nilai Gunakan deret yang berbeda dengan ukuran yang berbeda pada uji yang berbeda Turunkan uji sehingga elemen deret yang pertama, tengah dan terakhir diakses ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 19

Search routine - input partitions ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 20

Structural testing l l Disebut juga “white-box testing” Diturunkan dari pengetahuan struktur dan implementasi PL Biasa diterapkan utk unit program yg relatif kecil Penguji dpt menganalisis kode dan menggunakan pengetahuan mengenai struktur komponen utk menurunkan data uji ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 21

White-box testing ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 22

Binary search (Java)

l Berdasarkan kode utk search rutin, binary search melibatkan pembagian ruang searching menjadi 3 • • • l elem. Array[mid]==key elem. Array[mid]<key elem. Array>key Selanjutnya pengujian dilakukan berdasarkan pengetahuan mengenai algorithma binary search ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 24

Binary search - equiv. partitions l l l l Pre-conditions satisfied, key element in array Pre-conditions satisfied, key element not in array Pre-conditions unsatisfied, key element not in array Input array has a single value Input array has an even number of values Input array has an odd number of values ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 25

Binary search equiv. partitions ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 26

Binary search - test cases ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 27

Pengujian Jalur l l Bertujuan untuk menguji setiap jalur eksekusi independent melalui komponen atau program paling tidak 1 kali eksekusi Titik awal pengujian jalur merupakan graph alir yang terdiri dari node yg akan mewakili keputusan dan edge (tanda panah) yang menunjukkan aliran kontrol ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 28

Graf alir program l l l Menggambarkan aliran kontrol program. Setiap percabangan pada statement kondisional (if -then-else/case) ditunjukkan sebagai jalur yang terpisah Loop ditunjukkan dgn tanda panah yang kembali ke node kondisi loop Digunakan sebagai dasar perhitungan “the cyclomatic complexity” (CC) CC = Jumlah tanda panah – jumlah node +2 ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 29

Edge = 11 Node = 9 CC = 11 -9+2 =4 Binary search flow graph

Independent paths l l l 1, 2, 3, 8, 9 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 3, 4, 6, 7, 2, 8, 9 Test cases should be derived so that all of these paths are executed A dynamic program analyser may be used to check that paths have been executed ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 31

Pengujian Integrasi l l Pengujian terhadap sistem yang telah lengkap ( terintegrasi dari beberapa komponen) Pengujian integrasi menjadi black-box testing dengan menurunkan uji dari spesifikasi sistem Kesulitan utama adalah lokalisasi error yang ditemukan Solusi Pengujian inkremental ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 32

l l Yaitu dgn mengintegrasi konfigurasi sistem minimal dan menguji sistem ini Kemudian tambahkan komponen pada konfigurasi minimal dan mengujinya setelah inkremen ditambahkan ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 33

Incremental integration testing ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 34

Pendekatan pengujian integrasi l Top-down testing (Pengujian top-down) • l Bottom-up testing (Pengujian bottom-up) • l Dimulai dr komponen sistem tingkat tinggi, diintegrasikan diuji sebelum perancangan dan implementasinya selesai Komponen tingkat rendah diintegrasikan diuji sebelum komponen tingkat yang lebih tinggi dikembangkan Dalam prakteknya, kedua strategi ini sering dikombinasikan ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 35

Top-down testing ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 36

Bottom-up testing ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 37

Perbandingan metode top-down dan bottom-up l Validasi Arsitektural • l Demonstrasi sistem • l Dgn Top-down sistem yg dapat dipakai dan terbatas tersedia pada tahap awal pengembangan Implementasi uji • l Top-down lebih memungkinkan menemukan error pada arsitektur sistem Lebih mudah diimplementasikan dengan bottom-up Pengamatan uji • Bermasalah utk keduanya. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 38

Biasanya sistem dikembangkan diuji dgn metode campuran, krn jadwal pengembangan yang berbeda, berarti tim harus bekerja dgn komponen apapun yg tersedia ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 39

Pengujian Interface l l l Dilakukan saat sub sistem diintegrasi utk membuat sistem yang lebih besar Tujuannya utk mendeteksi kesalahan yg mungkin telah masuk ke dalam sistem karena error interface atau asumsi valid mengenai interface Sangat penting untuk pengembangan berorientasi objek terutama saat objek dan kelas dipakai ulang ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 40

Interface testing Pengujian bukan terhadap komponen, tetapi terhadap subsistem yg terbuat dari gabungan komponen ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 41

Jenis Interface l Parameter interfaces (interface parameter) • l Shared memory interfaces (interface memory bagi pemakai) • l Interface dgn satu blok memory dipakai bersama antar sub sistem Procedural interfaces (Interface procedural) • l Interface tempat data yg dikirim dari procedure (komponen) ke komponen lain Interface dgn satu sub sistem mengencapsulasi satu set prosedur yg dapat dipanggil oleh sub sistem lain Message passing interfaces • Interface tempat satu sub sistem meminta layanan dari satu sub sistem lain dengan mengirimkan message kepadanya ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 42

Error Interface Salah satu bentuk error paling umum pd sistem komplek. l Penyalahgunaan Interface • l Kesalahpahaman Interface • l Komponen pemanggil memanggil komponen lain dan melakukan error dalam penggunaan interfacenya. Mis urutan dan jml pengiriman yg salah Komponen pemanggil salah memahami spesifikasi interface komponen yg dipanggil. Mis rutin search biner dipanggil dgn aaray yg tidak urut, shg search akan gagal Timing errors • Terjadi pada sistem waktu nyata (sistem yg memberikan respons langsung saat diakses. Cth : ATM, pemesanan tiket online) yg menggunakan memory ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 43

Panduan Umum Pengujian Interface l l l Rancang satu set uji dengan nilai parameter ke komponen eksternal. Selalu uji interface dgn parameter pointer null Rancang uji yg akan mengakibatkan komponen gagal Gunakan pengujian stress dlm sistem message passing Dalam sharing memory rancang uji yg mengubah urutan aktivasi komponen ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 44

Pengujian Stress l l l Melanjutkan pengujian utk melewati beban rancangan maksimum sistem sampai sistem gagal. Pengujian stres menguji prilaku kegagalan sistem. Sangat penting bahwa kegagalan sistem tidak menyebabkan kerusakan data atau kerugian yg tidak diharapkan dari layanan user ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 45

l l Relevan bagi sistem terdistribusi yg berdasarkan jaringan prosesor Misalnya : • • sistem pengolahan transaksi dpt dirancang utk memproses sampai 100 transaksi per detik. Kemudian dilakukan uji stress sampai melewati angka tsb sampai sistem gagal OS dirancang utk menangani sampai 200 terminal yg terpisah ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 46

Pengujian berorientasi object l l Komponen yg akan diuji adalah class object yang telah diinisialisasikan sebagai objek Objek sbg komponen individu seringkali lebih besar dari fungsi tunggal ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 47

Tingkat pengujian pada PBO l l Pengujian operasi individual yg berhubungan dgn objek fungsi atau procedure (dgn blck-box atau white-box testing) Pengujian kelas objek individu Pengujian kelompok objek Pengujian sistem berorientasi objek ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 48

Pengujian Kelas Object l Saat menguji objek liputan uji yg lengkap harus mencakup • • • l l Engujian semua operasi yg berhubungan dgn objek tsb Setting dan integrasi semua attribut yg berhub dgn objek tsb Melatih objek dgn semua status yg mungkin Penggunaan konsep inheriten mengakibatkan perancangan uji kelas objek menjadi lebih sulit Karena semua sub class harus diuji dgn semua operasi yg diwarisi. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 49

Object integration l l l Levels of integration are less distinct in objectoriented systems Cluster testing is concerned with integrating and testing clusters of cooperating objects Identify clusters using knowledge of the operation of objects and the system features that are implemented by these clusters ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 50

Approaches to cluster testing l Use-case or scenario testing • • l Thread testing • l Testing is based on a user interactions with the system Has the advantage that it tests system features as experienced by users Tests the systems response to events as processing threads through the system Object interaction testing • Tests sequences of object interactions that stop when an object operation does not call on services from another object ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 51

Scenario-based testing l l Identify scenarios from use-cases and supplement these with interaction diagrams that show the objects involved in the scenario Consider the scenario in the weather station system where a report is generated ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 52

Collect weather data ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 53

Weather station testing l Thread of methods executed • l Comms. Controller: request ® Weather. Station: report ® Weather. Data: summarise Inputs and outputs • Input of report request with associated acknowledge and a final output of a report • Can be tested by creating raw data and ensuring that it is summarised properly • Use the same raw data to test the Weather. Data object ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 54

Testing workbenches l l l Testing is an expensive process phase. Testing workbenches provide a range of tools to reduce the time required and total testing costs Most testing workbenches are open systems because testing needs are organisation-specific Difficult to integrate with closed design and analysis workbenches ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 55

A testing workbench ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 56

Tetsing workbench adaptation l l l Scripts may be developed for user interface simulators and patterns for test data generators Test outputs may have to be prepared manually for comparison Special-purpose file comparators may be developed ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 57

Key points l l Test parts of a system which are commonly used rather than those which are rarely executed Equivalence partitions are sets of test cases where the program should behave in an equivalent way Black-box testing is based on the system specification Structural testing identifies test cases which cause all paths through the program to be executed ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 58

Key points l l Test coverage measures ensure that all statements have been executed at least once. Interface defects arise because of specification misreading, misunderstanding, errors or invalid timing assumptions To test object classes, test all operations, attributes and states Integrate object-oriented systems around clusters of objects ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 20 Slide 59