Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

1 Testing dan Implementasi. 2 l Dua Aspek yang dipertimbangkan: Apakah implementasi sudah sesuai dengan spesifikasi ? Apakah spesifikasi sesuai dengan.

Presentasi serupa


Presentasi berjudul: "1 Testing dan Implementasi. 2 l Dua Aspek yang dipertimbangkan: Apakah implementasi sudah sesuai dengan spesifikasi ? Apakah spesifikasi sesuai dengan."— Transcript presentasi:

1 1 Testing dan Implementasi

2 2 l Dua Aspek yang dipertimbangkan: Apakah implementasi sudah sesuai dengan spesifikasi ? Apakah spesifikasi sesuai dengan kebutuhan user ? l Validasi “Apakah sistem yang dikembangkan sudah benar?” Pengujian dimana sistem ketika diimplementasikan sesuai dengan yang iharapkan l Verifikasi “Apakah sistem dikembangkan dengan cara yang benar ?” Pengujian apakah sistem sudah sesuai dengan spesifikasi Seberapa baik sistem yang sudah dibangun ?

3 3 Proses Testing Unit testing Pengujian masing-masing unit komponen program untuk meyakinkan bhw sudah beroperasi secara benar Module Testing Pengujian terhadap koleksi unit-unit komponen yang saling berhubungan. Sub-system Testing Pengujian terhadap koleksi module-module yang membentuk suatu sub-system (aplikasi)

4 4 Proses Testing System Testing Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system Acceptance Testing Pengujian terakhirs sebelum sistem dipakai oleh user. Melibatkan pengujian dengan data dari pengguna sistem. Biasa dikenal sebagai “alpha test” (“beta test” untuk software komersial, dimana pengujian dilakukan oleh potensial customer)

5 5 Proses Testing Unit Testing Module Testing Sub-system Testing System Testing Acceptance Testing Component Testing Integration Testing User Testing

6 6 The testing process Component testing Pengujian komponen-komponen program Biasanya dilakukan oleh component developer (kecuali untuk system kritis) Integration testing Pengujian kelompok komponen-komponen yang terintegrasi untuk membentuk sub-system ataupun system Dialakukan oleh tim penguji yang independent Pengujian berdasarkan spesifikasi sistem

7 7 Rencana Pengujian Proses testing Deskripsi fase-fase utama dalam pengujian Pelacakan Kebutuhan Semua kebutuhan user diuji secara individu Item yg diuji Menspesifikasi komponen sistem yang diuji Jadual Testing Prosedur Pencatatan Hasil dan Prosedur Kebutuhan akan Hardware dan Software Kendala-kendala Mis: kekuranga staff, alat, waktu dll.

8 8 Hubungan antara rencana pengujian dan proses pengembangan system Spesifikasi Kebutuhan Spesifikasi System Perancangan System Detail Perancangan Acceptance Test plan System Integration Test plan Sub-System Integration Test plan Module and Unit code and test Acceptance test System Integration test Sub-System Integration test Service

9 9 Failures, Faults Failure: output yang tidak benar/tidak sesuai ketika sistem dijalankan Fault: kesalahan dalam source code yang mungkin menimbulkan failure ketika code yg fault tsb dijalankan Failure ClassDeskripsi TransientMuncul untuk input tertentu PermanentMuncul untuk semua input RecoverableSistem dapat memperbaiki secara otomatis UnrecoverableSistem tidak dapat memperbaiki secara otomatis Non-corruptingFailure tidak merusak data CorruptingFailure yang merusak sistem data

10 10 Contoh: Faults, Errors, and Failures l Suppose node 6 should be X:= C*(A+2*B) Failure-less fault: »executing path (1,2,4,5,7,8) will not reveal this fault because 6 is not executed »nor will executing path (1,2,3,5,6,8) because C = 0 l Need to make sure proper test cases are selected the definitions of C at nodes 3 and 4 both affect the use of C at node 6 »executing path (1,2,4,5,6,8) will reveal the failure, but only if B /= 0

11 11 Hanya test yang lengkap yg dapat meyakinkan sistem terbebas dari kesalahan, tetapi hal ini sangat sulit dilakukan. Prioritas dilakukan terhadap pengujian kemampuan sistem, bukan masing-masing komponennya. Pengujian untuk situasi yg tipikal lebih penting dibandingkan pengujian terhadap nilai batas. Prioritas Testing

12 12 Test data: Input yang yang direncankan digunakan oleh sistem. Test cases: Input yang digunakan untuk menguji sistem dan memprediksi output dari input jika sistem beroperasi sesuai dengan spesifikasi. Test data dan kasus test

13 13 Proses defect testing

14 14 Black-box testing Pendekatan pengujian dimana program dianggap sebagai suatu ‘black-box’ (‘kotak hitam’) Program test case berbasiskan spesifikasi Test planning dapat dimulai sejak awal proses pengembangan sistem

15 15 Black-box testing

16 16 Equivalence partitioning Input data dan output hasil terdapat di klas yang berbeda yang sesuai dengan klas inputnya Masing-masing klas equivalensi partition diprosres dimana program akan memproses anggota klas-klas tersebut secara equivale. Test cases dipilih dari masing-masing partisi

17 17 Equivalence partitioning

18 18 Partition system inputs and outputs into ‘equivalence sets’ If input is a 5-digit integer between and 99999, equivalence partitions are Choose test cases at the boundary of these sets 00000, 9999, 10000, 99999, Equivalence partitioning

19 19 Equivalence partitions

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

21 21 Inputs yang sesuai dg pre-conditions Inputs yang tidak sesuai pre-condition Inputs dimana key element ada di dalam array Inputs dimana key element tidak terdapat di dalam array Search routine - input partitions

22 22 Search routine - input partitions

23 23 Disebut juga white-box testing Penentuan test case disesuaikan dengan struktur sistem. Knowledge program digunakan untuk mengidentifikasi test case tambahan. Tujuannya untuk menguji semua statement program (debug). Structural testing

24 24 White-box testing

25 25 Path testing Tujuannya meyakinkan bahwa himpunan test case akan menguji setiap path pada suatu program paling sedikit satu kali. Titik awal untuk path testing adalah suatu program flow graph yang menunjukkan node- node yang menyatakan program decisions (mis.: if-then-else condition) dan busur menyatakan alur kontrol Statements dengan conditions adalah node- node dalam flow graf.

26 26 Menggambarkan alur kontrol. Setiap cabang ditunjukkan oleh path yg terpisah dan loop ditunjukkan oleh arrows looping kembali ke loop kondisi node. Digunakan sebagai basis untuk menghitung cyclomatic complexity Cyclomatic complexity = Jumlah edges – Jumlah Node +2 Cyclomatic complexity menyatakan jumlah test untuk menguji control statements Program flow graphs

27 Binary search flow graph

28 28 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 harus ditentukan sehingga semua path tsb tereksekusi. Independent paths

29 29 Integration testing Pengujian keseluruhan system atau sub- system yang terdiri dr komponen yg terintegrasi. Test integrasi menggunakan black-box dengan test case ditentukan dari spesifikasi. Kesulitannya adalah menemukan/melokasikan Penggunaan Incremental integration testing dapat mengurangi masalah tersebut.

30 30 Incremental integration testing

31 31 Pendekatan integration testing Top-down testing Berawal dari level-atas system dan terintegrasi dengan mengganti masing-masing komponen secara top-down dengan suatu stub (program pendek yg mengenerate input ke sub-system yg diuji). Bottom-up testing Integrasi components di level hingga sistem lengkap sudah teruji. Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi kedua strategi pengujian tsb.

32 32 Top-down testing

33 33 Bottom-up testing

34 34 Pendekatan Testing Architectural validation Top-down integration testing lebih baik digunakan dalam menemukan error dalam sistem arsitektur. System demonstration Top-down integration testing hanya membatasi pengujian pada awal tahap pengembangan system. Test implementation Seringkali lebih mudah dengan menggunakan bottom-up integration testing

35 35 Dilakukan kalau module-module dan sub- system terintegrasi dan membentuk sistem yang lebih besar Tujuannya untuk medeteksi fault terhadap kesalahan interface atau asumsi yg tidak valid terntang interface tsb. Sangat penting untuk pengujian terhadap pengembangan sistem dgn menggunakan pendekatan object-oriented yg didefinisikan oleh object-objectnya Interface testing

36 36 Interface testing

37 37 Interfaces types Parameter interfaces Data dikirim dari satu procedure ke procedure lainnya. Shared memory interfaces Block of memory dishare diantara procedure- procedure Procedural interfaces Sub-system mengencapsulasi sekumpulan procedure-procedure yang akan dipanggil oleh sub-system lainnya Message passing interfaces Sub-systems meminta services dari sub-systems lainnya

38 38 Interface errors Interface misuse componen pemanggil memanggil component lainnya dan membuat suatu kesalahan dalam penggunaan interfacenya (mis.: parameter dg urutan yg tidak sesuai). Interface misunderstanding component pemanggil salah dalam mengasumsikan behaviour component yg dipanggil. Timing errors Component yg memanggil dan yg dipanggil beroperasi pada kecepatan yg berbeda sehingga dimungkinkan mengakses informasi yg tidak uptodate (synchronization problem).

39 39 Petunjuk melakukan Interface testing Merancang test dimana parameter ke procedure yg dipanggil berada pada nilai batas extrim Test Menggunakan null pointer Perancangan tests sehingga component yg di test akan fail. Menggunakan stress testing pada message passing Pada shared memory systems, variasikan urutan dimana komponen diaktifkan.

40 40 Stress testing Menguji sistem dengan nilai yg melebihi maksimum load. Stressing suatu system menyebabkan tidak mudah kerusakan. Stressing suatu system test failure behaviour. Systems seharusnya tidak gagal total. Stress testing mencek kehilangan service yg tidak diduga ataupun data yg hilang. Khusus untuk sistem terdistribusi dapat menyebabkan degradasi jaringan sehingga overload.

41 41 Components yang diuji adalah class object yang diinstantiate ke object. Lebih besar dibandingkan pengujian sebuah function sehingga pendekatan white-box testing perlu diperluas. Tidak jelasnya ‘top’ suatu system untuk top-down integration dan testing Object-oriented testing

42 42 Testing levels Testing operations pada objects Testing object classes Testing clusters cooperating objects Testing OO system secara lengkap

43 43 Object class testing Complete test yang menguji class melibatkan Testing semua operations suatu object Setting dan interrogating semua attribute object Menguji object untuk semua state(keadaan) yg mungkin Inheritance akan mengakibatkan sulitnya perancangan object class tests seperti information yg diuji sulit dilokalisasi.

44 44 Contoh: Weather station object interface Test cases dibutuhkan untuk semua operations Menggunakan state model untuk mengidentifikasi state transitions testing Contoh testing sequences Shutdown  Waiting  Shutdown Waiting  Calibrating  Testing  Transmitting  Waiting Waiting  Collecting  Waiting  Summarising  Transmitting  Waiting

45 45 Integrasi Object Levels integrasi sedikit berbeda untuk sistem yang berorientasi object. Cluster testing digunakan untuk test integrasi and testing clusters terhadap cooperating objects Identifikasi clusters menggunakan knowledge dari operation objects dan system features yang diimplementasikan oleh cluster tersebut.

46 46 Approaches cluster testing Use-case atau scenario testing Testing berdasarkan pada interaksi user dengan sistem. Keuntungannya diujikan oleh user yg berpengalaman. Object interaction testing Tests barisan interaksi object yang berhenti ketika suatu operation object tidak memanggil service dari object lain.

47 47 Scenario-based testing Identifikasi scenarios dari use-cases dan menambahkannya dengan diagram interaksi yang menunjukkan object- object yang terlibat dalam scenario Lihat contoh scenario berikut ini pada sistem weather station ketika suatu report dibuat

48 48 Collect weather data

49 49 Weather station testing Thread pengeksekusian methode CommsController:request  WeatherStation:report  WeatherData:summarise Inputs dan outputs Input report request dengan acknowledge yg sesuai serta output report akhir Dapat diujikan dengan membuat raw data dan meyakinkan bahwa dapat menghasilkan kesimpulan (summarize) yg sesuai. Gunakan raw data yg sama untuk menguji object WeatherData

50 50 Testing workbenches Testing merupakan suatu proses yg cukup mahal. Testing workbenches menyediakan tool-tool untuk mereduksi waktu yg dibutuhkan dan total cost pengujian Kebanyakan testing workbenches merupakan open systems karena kebutuhan testing membutuhkan tergantung dr spesifikasi organisasi Sulit diintegrasikan dengan closed design dan analysis workbenches

51 51 A testing workbench

52 52 Tetsing workbench adaptation Scripts dibuat untuk user interface simulator dan model test data generator Test outputs harus disiapkan secara manual sebagai pembanding. Special-purpose file comparators harus dibuat


Download ppt "1 Testing dan Implementasi. 2 l Dua Aspek yang dipertimbangkan: Apakah implementasi sudah sesuai dengan spesifikasi ? Apakah spesifikasi sesuai dengan."

Presentasi serupa


Iklan oleh Google