Pertemuan 4 OOP Febriyanno Suryana, S.Kom, MM 0852 7474 1981 SI -2011.

Presentasi berjudul: "Pertemuan 4 OOP Febriyanno Suryana, S.Kom, MM 0852 7474 1981 SI -2011."— Transcript presentasi:

1 Pertemuan 4 OOP Febriyanno Suryana, S.Kom, MM surya_gsc04@yahoo.com 0852 7474 1981 SI -2011

2  OOP merupakan metodologi dalam pemrograman yang di ciptakan untuk memodelkan kasus-kasus nyata ke dalam suatu objek.  Objek merupakan kombinasi antara struktur data dan perilaku dalam satu entitas/objek.  Merupakan strategi perancangan dimana perancang sistem memikirkan ‘benda’ dan bukan operasi atau fungsi. 2

3  Secara spesifik objek adalah sesuatu paket yang merupakan kumpulan data dan method (perilaku)  Data  Sesuatu yg menentukan karakteristik sebuah objek  Method  Aksi terhadap data (cara suatu objek melakukan sesuatu).  Sebagai contoh, objek manusia memiliki data-data seperti: tinggi badan, berat badan, warna kulit dsb. Sedangkan perilaku/method yang dimiliki manusia misalnya cara berjalan, cara bicara dan sebagainya 3

4  Dalam pemrograman, data-data di dalam objek akan direpresentasikan dengan variabel atau konstanta, sedangkan perilaku akan direpresentasikan dengan prosedur atau fungsi, yang kemudian disebut dengan method.  Ilustrasi tersebut digambarkan sebagai berikut: 4 objek data method Berupa variabel atau konstanta Berupa prosedur atau fungsi

5 5

6  Istilah yg masih berkaitan erat dgn objek adalah kelas. Kelas merupakan struktur umum dari objek2 tertentu.  Misal saya, anda dan yg lainnya adalah objek, yg termasuk dlm kelas manusia. 6

7  Class adalah suatu template yang digunakan sebagai pola desain suatu objek. Class : rancangan mobil Objek : mobil nyata  Class harus di instansiasikan (dibuat objeknya) terlebih dahulu. 7

8 8 Class  Objek 

9 9 Data  Method 

10 10

11  Dlm bahasa pemrograman, sering dikatakan bahwa objek merupakan instansiasi dari sebuah kelas.  Instansiasi merupakan wujud nyata dari suatu objek.  Sebagai contoh: jika terdpt objek manusia, maka udin, amir dan ali adalah instance dari objek manusia.  dianalogikan juga bahwa tipe data adalah kelas, sedangkan var yg didefinisikan berdasarkan tipe data tersbt adalah objek. contoh jika: x : integer ; berarti objek x adalah instance dari kelas integer. 11

12  <php /* procedural.php */  print "Hello, world.";  ?> 12

13  <php /* objek.php */  class HelloWorld  {  function myPrint()  {  print "Hello, world.";  }  $myHelloWorld = new HelloWorld  $myHelloWorld->myPrint();  ?> 13

14  Kelas  Objek  Atribut/Data  Metoda/Servis/Operator/Perilaku  Message  Event  State  Skenario 14

15 15

16 16

17 17

18 18

19 19 Objek  : Furniture

20  Encapsulation  Inheritance  Polymorphism 20

21 21

22 22

23 23

24 Pertemuan 4 Dasar – dasar pengujian perangkat lunak Febriyanno Suryana, S.Kom, MM surya_gsc04@yahoo.com 0852 7474 1981 SI -2011

25  Adalah proses eksekusi suatu program dengan tujuan untuk menemukan error (Berard, 1994).  Elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean.  Pengujian sebaiknya menemukan kesalahan yang tidak disengaja dan pengujian dinyatakan sukses jika berhasil memperbaiki kesalahan tersebut.  Pengujian bertujuan untuk menunjukkan kesesuaian fungsi- fungsi perangkat lunak dengan spesifikasinya. 25

26  Test data: Input yang yang direncanakan digunakan oleh sistem.  Test cases: Input yang digunakan untuk menguji sistem dan memprediksi output dari input jika sistem beroperasi sesuai dengan spesifikasi. 26

27 27

28  Misi dari testing. ◦ Mengapa anda melakukan testing ? Apa yang ingin anda pelajari ?  Pemilihan strategi ◦ Bagaimana anda mengorganisasikan pekerjaan anda untuk meraih misi anda?  Oracle/sematic. ◦ Bagaimana anda mengetahui bahwa program itu lolos testing atau gagal?  Adanya kemungkinan testing tidak sempurna ◦ Apa yang harus dilakukan untuk menyelesaikan testing secara lengkap?  Mengukur permasalahan ◦ Sejauh mana testing dianggap cukup? 28

29  Semua pengujian harus ditelusuri sampai ke persyaratan pelanggan.  Pengujian harus direncanakan jauh sebelum pengujian itu dilakukan.  Prinsip pareto berlaku untuk pengujian perangkat lunak, maksudnya 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program  Pengujian harus dimulai “dari yang kecil” dan berkembang menjadi pengujian “yang besar”  Agar lebih efektif, pengujian harus dilakukan oleh pihak ketiga yang independen 29

30  Tentukan sasaran pengujian  Tentukan karakteristik pengujian  Testabilitas software 30

31  Test case yang baik adalah test case yang memiliki profitabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya.  Pengujian yang sukses adalah pengujian yang mengungkapkan semua kesalahan yang belum pernah ditemukan sebelumnya 31

32  Testing dimulai dari level modul dan bekerja keluar ke arah integrasi pada sistem berbasiskan komputer.  Teknik testing yang berbeda sesuai dengan poin-poin yang berbeda pada waktunya.  Testing dilakukan oleh software developer dan untuk proyek yang besar oleh group testing yang independen  Testing dan debugging adalah aktivitas yang berbeda tetapi debugging harus diakomodasikan pada setiap strategi testing. 32

33  Seberapa mudah sebuah program komputer dapat diuji.  Karena pengujian sangat sulit, perlu diketahui apa yang dapat dilakukan untuk dapat membuatnya lebih mudah. 33

34 1. Operability Semakin baik sw itu bekerja, semakin efisien ia dapat diuji. 2. Observability Apa yang anda lihat adalah apa yang anda uji. 3. Controllability Semakin baik kita mengontrol sw, semakin banyak pengujian yang dapat di otomatisasi dan dioptimalkan. 4. Decomposability Dengan mengontrol ruang lingkup pengujian, kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih detail. 34

35 5. Simplicity Semakin sedikit yang diuji, semakin cepat pengujian. 6. Stability Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian. 7. Kemampuan dapat dipahami Semakin banyak informasi yang dimiliki semakin detail pengujiannya. 35

36 1. Memiliki probabilitas yang tinggi untuk menemukan error. o Tester harus memahami software yang diuji dan memikirkan bagaimana software itu bisa gagal. 2. Pengujian yang baik tidak redundant/ganda. o Setiap pengujian harus mempunyai tujuan yang berbeda. 3. Pengujian yang baik tidak terlalu sederhana namun juga tidak terlalu kompleks. o Tidak mengkombinasikan beberapa test case ke dalam sebuah test case. o Test case dilakukan secara terpisah. 36

37 1. Pengetahuan fungsi yang spesifik dari produk yang telah dirancang untuk diperlihatkan, test dapat dilakukan dengan menilai masing-masing fungsi apakah telah berjalan sebagaimana yang diharapkan. 2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan dengan memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya. 37

38 38

39 39

40 40

41 41

42  Full Testing ◦ Dimulai dari awal pegembangan sampai produk diterima user  Partial Testing ◦ Dimulai dari waktu setelah fase desain  Endgame Testing ◦ Berorientasi pada validasi  Audit Level Testing ◦ Untuk memenuhi standar dan berorientasi pada proses audit 42

43 43

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

45 4. System Testing Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system 5. Acceptance Testing Pengujian terakhir 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) 45

46  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 Dilakukan oleh tim penguji yang independen Pengujian berdasarkan spesifikasi sistem 46

47 47

48  Verifikasi adalah proses evaluasi sebuah sistem atau komponen untuk mendefenisikan bahwa produk memiliki fase pengembangan yang benar dimulai dari awal fase. verifikasi berbasis proses Are we building the product right ? [Boehm,1984]  validasi adalah proses evaluasi sebuah sistem atau komponen selama atau pada akhir pengembangan untuk mendefenisikan bahwa produk sesuai dengan spesifikasi kebutuhan. validasi berbasis produk Are we building the right product ? [Boehm,1984] 48

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

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

51 51

52  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 52 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

53 53 Test Case ID: CUST.01 Function: Menambah satu pelanggan baru Data Assumptions: Customer database sudah di-restore Deskripsi: Menambah satu pelanggan, melalui Form Tambah Pelanggan, dan menampilkan validasi pelanggan baru tersebut pada Tampilan Pelanggan AksiState Awal atau Tampilan DataHasil yg diharapkan (Response) 1. Aplikasi Penjualan dijalankan melalui Icon di windows Program Manager Tidak AdaMenu utama Aplikasi Penjualan 2. Pilih Pelanggan pada Menu Tampilan. Tampilan Utama Penjualan Tidak AdaPelanggan menampilkan Tampilan.. 3. Click pilihan All CustomersTampilan Pelanggan Tidak AdaWindow Pelanggan ditampilkan dengan judul “Pelanggan”. 4. Click pada Button TambahCustomer - All Customer Tidak AdaTampilan Tambah Pelanggan ditampilkan 5. Masukkan data untuk menambah satu pelanggan baru dan click satu kali button tambah. Tambah Pelanggan Nama: Andi Noor Alamat: Jl. Xxxx Kota: Jakarta Data ditampilkan pada field- field yg sesuai (atau seperti yg ditampilkan oleh data sheet).

54  Laporan Hasil  Matrik test case  Berdasarkan faktor penggunaan 54

55 55 Nomor Kesalahan : Nama Program: Tipe Laporan: (1. Usulan, 2.Salah Perancangan, 3. Salah program, 4. Salah dokumentasi, 5. Query) Severity: 1. Minor, 2. Serius, 3. Fatal Attachment (Y/N) Adakah kesalahan (Y/T) Bagaimana bentuk kesalahan: Bagaimana kesalahan dapat terjadi: Usulan Perbaikan: Nama Penguji: Tanggal Uji: --------------------------------- Diisi oleh programmer: Ditujukan kepada:Tanggal: Resolusi: 1.Dapat diperbaiki 2.Tidak dapat diperbaiki 3.Pengujian ditarik kembali 4.Bekerja sesuai spesifikasi 5.Kesalahan tidak dapat dihasilkan lagi 6.Tidak setuju dengan usulan ----------- Sertifikasi Resolusi Dibuat oleh: Programmer,Tester:Tanggal: Project Manager:

56 56 Hasil yang diharapkan Tujuan TestPenolakanPesan Kesalahan yg ditampilkan Rancangan Test Case Hasil yang sebenarnya Menguji perhitungan digit input XXInput nomor rekening (yang sudah diubah urutannya) Pesan kesalahan penolakan dan ditampilkan Menentukan nomor- nomor departemen dicek XXInput nomor departemen yang salah Pesan kesalahan penolakan dan ditampilkan Keakuratan perhitungan Pembayaran lembur untuk pekerja jam- jaman selama 15 jam Pembayaran lembur sebesar 1.5 kali pembayaran normal

57 57 Faktor Usabilitas AMudah digunakan12345 BUser Friendly12345 CMudah dimengerti12345 DTingkat Kepercayaan12345 ETingkat kesesuaian dengan yg dibutuhkan 12345 FWaktu Respons12345 GTingkat comfortable12345

58 End Session 58