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

Presentasi berjudul: "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Pengujian Cacat (Defect Testing) l Pengujian program untuk mengungkap adanya."— Transcript presentasi:

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

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

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

4 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 4 Proses Pengujian l Pengujian Komponen Berhubungan dengan pengujian berfungsinya komponen Biasanya merupakan tanggung jawab programmer Tes dilakukan berdasarkan pengalaman programer l 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

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

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

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

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

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

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

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

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

13 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 13 Partisi Equivalensi 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 l Program biasanya berlaku dengan cara yg dapat dibandingkan untuk semua anggota kelas l Bagitu satu himpunan partisi telah diidentifikasikan, kemudian dipilihlah kasus uji dari setiap partisi ini

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

15 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 15 l Identifikasikan Himpunan Partisi input dan output ke dalam sebuat bentuk equivalensi 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 99.999 l Pilih kasus uji pada batasan dari himpunan tersebut 00000, 09999, 10000, 99999, 10001 Partisi Equivalesi

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

17 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 17 Search routine specification 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 ( Found and T (L) = Key) or -- the element is not in the array ( not Found and not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))  mencari sederet elemen untuk elemen tertentu (kunci)  kondisi pra menyatakan rutin search dirancang utk bekerja dengan deret kosong  Kondisi pasca menyatakan variavel Found diset jika elemen kunci ada pd deret  Posisi elemen kunci ditunjukkan oleh indeks L dan tidak didefenisikan jika elemen tidak berada dalam deret

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

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

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

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

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

23 Binary search (Java)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

46 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 46 l Relevan bagi sistem terdistribusi yg berdasarkan jaringan prosesor l 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

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

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

49 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 49 Pengujian Kelas Object l Saat menguji objek liputan uji yg lengkap harus mencakup 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 l Penggunaan konsep inheriten mengakibatkan perancangan uji kelas objek menjadi lebih sulit l Karena semua sub class harus diuji dgn semua operasi yg diwarisi.

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

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

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

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

54 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 54 Weather station testing l Thread of methods executed CommsController:request  WeatherStation:report  WeatherData:summarise l 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 WeatherData object

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

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

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

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

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