Teknik Informatika S1

Transkripsi

1 Teknik Informatika S1 SOFTWARE QUALITY AND TESTING Strategi Pengujian Disusun Oleh: Egia Rosi Subhiyakto, M.Kom, M.CS Teknik Informatika UDINUS

2 SILABUS MATA KULIAH 1. Pendahuluan 2. Gambaran Umum Pengujian (Definisi Pengujian, proses pengujian, Hubungan pengujian dan kualitas, dasar-dasar pengujian) 3. Konsep Dasar Pengujian 4. Strategi Pengujian (V&V, Unit Testing, Integration) 5. Teknik Pengujian (White Box, Black Box, Grey Box) 6. Black Box 7. Black Box

3 Pendekatan Strategi Testing Testing adalah suatu kumpulan aktifitas yang dapat direncanakan lebih lanjut dan dilakukan secara sistematis. Karena alasan ini suatu kerangka testing software, yaitu suatu kumpulan tahapan yang terbentuk dari teknik desain test caes dan metode testing tertentu, harus didefinisikan untuk proses dari software.

4 Pendekatan Strategi Testing Testing dimulai dari tingkat komponen terkecil sampai pada integrasi antar komponen pada keseluruhan sistem komputer tercapai. Teknik testing berbeda-beda sesuai dengan waktu penggunaanya.

5 Pendekatan Strategi Testing Testing dilakukan pengembang software dan (untuk proyek besar) dilakukan oleh suatu grup tes yang independen Testing dan debugging adalah aktifitas yang berlainan, tapi debugging harus diakomodasi disetiap strategi testing.

6 Verifikasi dan Validasi Testing software sering dikaitkan dengan verifikasi dan validasi (V&V). Verifikasi merupakan sekumpulan aktifitas yang memastikan software telah melakukan fungsi tertentu dengan benar. Validasi merupakan sekumpulan aktifitas berbeda dari verifikasi yang memastikan bahwa software yang dibangun dapat dilacak terhadap kebutuhan/ permintaan pelanggan.

7 Verifikasi dan Validasi [BOEHM 81] Verifikasi Are we building the product right? Apakah kita telah membuat produk dengan benar? Validasi Are we building the right product? Apakah kita telah membuat produk yang benar?

8 Verifikasi dan Validasi V&V meliputi kebanyakan aktifitas SQA, yaitu: Formal technical review, audit konfigurasi dan kualitas, pemonitoran kinerja, simulasi, studi fisibiltas, review dokumentasi, review database, analisa algoritma, testing pengembangan, testing kualifikasi, dan testing instalasi.

9 Verifikasi dan Validasi Testing merupakan basis terakhir dimana kualitas dapat dinilai error dan dapat diidentifikasi Kualitas dibangun ke dalam software sepanjang proses rekayasa software

10 Strategi Testing Software

11 Tahapan Testing Software

12 Isu-Isu Strategi Testing Spesifikasi kebutuhan produk agar dapat dikuantisasi, harus ditetapkan jauh sebelum testing dimulai Nyatakan obyektifitas testing secara eksplisit Memahami pengguna software dan mengembangkan profil untuk tiap kategori pengguna.

13 Isu-Isu Strategi Testing Mengembangkan rencana testing berdasar pada rapid cycle testing. Membuat software yang tegar (robust), yang didesain untuk melakukan tes dirinya sendiri. Gunakan Formal Technical Review (FTR) yang efektif sebagai filter testing tertentu.

14 Isu-Isu Strategi Testing Lakukan Formal Technical Review unuk menilai strategi tes dan test cases itu sendiri Kembangkan pendekatan pengembangan yang berkelanjutan untuk proses testing.

15 Unit Testing Unit testing berfokus pada usaha verifikasi pada unit terkecil dari desain software komponen atau modul software. Penggunaan deskripsi desain tingkat komponen sebagai tuntunan, jalur kendali yang penting dites untuk menemukan errors, terbatas pada modul tersebut.

16 Hal-hal yang perlu diperhatikan pada unit testing Tes yang terdapat pada unit testing: Modul antar muka dites untuk memastikan aliran informasi telah berjalan seperti yang diharapkan. Struktur data lokal diperiksa untuk memastikan penyimpanan data telah merawat integritasnya secara temporal selama tahap eksekusi algoritma. Batasan kondisi dites memastikan modul beroperasi dengan benar Semua jalur independen (basis path) pada struktur kendali diperiksa Semua jalur penanganan kesalahan dites.

17 Hal-hal yang perlu diperhatikan pada unit testing Tes aliran data antar modul dibutuhkan sebelum inisialisasi tes lainnya. Pemilihan jalur eksekusi testing adalah tugas esensial selama unit test. Kesalahan komputasi yang umum terjadi Kesalahan prioritas aritmetik Mode operasi campuran Inisialisasi tak benar

18 Hal-hal yang perlu diperhatikan pada unit testing Komparasi dan alur kendali merupakan satu kesatuan. Desain yang baik meliputi kondisi kesalahan yang diantisipasi dan jalur penanganan kesalahan diset untuk dapat digunakan kembali atau proses pembersihan pada terminasi saat kesalahan terjadi Batasan testing adalah tugas terakhir dari unit testing

19 Prosedur-prosedur unit test Unit testing secara umum dipandang sebagai proses kelanjutan dari tahapan coding, dengan prosedur sebagai berikut: Setelah kode dikembangkan, dan diverifikasi terhadap tingkat desain komponen bersangkutan, desain test case dari unit test dimulai. Review informasi desain menyediakan tuntunan untuk menetapkan test cases Tiap test cae harus dihubungkan dengan hasil yang diharapkan Karena komponen bukan program yang beridiri sendiri, drivers dan atau stubs software harus dikembangkan untuk tiap unit test.

20 Integration Testing Integration testing adalah suatu teknik yang sistematis untuk pembangunan struktur program, dimana pada saat yang bersamaan melakukan testing untuk mendapatkan errors yang diasosiasikan dengan antar-muka.

21 Obyektifitas Integration Testing Obyektifitas Integration testing adalah untuk menindaklanjuti komonen-komponen yang telah melalui unit testing dan membangun suatu struktur program sesuai dengan desain yang telah dituliskan sebelumnya.

22 Top-down Integration Top down adalah pendekatan bertahap untuk menyusun struktur program. Modul-modul diintegrasikan dari atas ke bawah dalam suatu hirarki kendali, dimulai dari modul kendali utama (program utama). Modul sub-ordinat dari modul kendali utama dihubungkan ke struktur yang paling dalam (depth-first integration) atau yang paling luas (breadth-first integration) dahulu.

23 Top-down Integration Depth-first integration, akan mengintegrasikan semua komponen-komponen pada struktur jalur kendali mayor. Misal dipilih sisi kiri terlebih dahulu, maka komponen M1, M2, M5 akan diintegrasikan dahulu, baru kemudian M8 atau M6 akan diintegrasikan.

24 Top-down Integration Breadth-first integration, akan mengintegrasikan semua komponen secara langsung ke tiap tingkat, bergerak secara horisontal. Contoh komponen M2, M3 dan M4 akan diintegrasikan dahulu, kemudian baru M5 dan M6 dan seterusnya

25 Top-down Integration Lima langkah proses integrasi: 1. Modul kendali utama digunakan sebagai driver tes dan stubs tes disubstitusikan bagi semua komponen yang secara langsung menjadi sub-ordinat modul kendali utama. 2. Tergantung pada pendekatan integrasi yang dipilih, stubs sub-ordinat digantikan dengan komponen sebenarnya. 3. Tes dilakukan saat tiap komponen diintegrasikan. 4. Saat pemenuhan tiap tes, stubs lainnya digantikan dengan komponen sebenarnya. 5. Testing regresi dilakukan untuk memastikan kesalahan baru tidak terjadi lagi.

26 Bottom-up Testing Sesuai namanya, integrasi ini dimulai dari modul terkecil. Karena komponen-komponen diintegrasikan dari bawah ke atas, sub-ordinat untuk tingkat bersangkutan dari komponen selalu diperlukan untuk diproses, dan kebutuhan terhadap stubs dapat dihilangkan.

27 Bottom-up Testing Langkah-langkah strategi ini adalah: 1. Komponen level bawah dikombinasikan dalam clusters (kadang disebut builds) yang mewakili sub-fungsi software tertentu. 2. Driver ditulis untuk koordinasi masukan dan keluaran test case. 3. Cluster dites 4. Driver dihapus dan cluster dikombinasikan, bergerak ke atas di dalam struktur program.

28 Bottom-up Testing Komponen dikombinasi untuk membentuk cluster 1, 2 dan 3. Tiap cluster dites dengan menggunakan driver. Komponen pada cluster 1 dan 2 adalah sub ordinat Ma. Driver D1 dan D2 dihilangkan dan cluster dihubungkan langsung ke Ma, demikian seterusnya.

29 Regression Testing Regression Testing adalah eksekusi kembali dari subset dari tes yang telah dilakukan untuk memastikan apakah perubahanperubahan yang dilakukan telah benar dan tidak menimbulkan efek samping yang tidak diharapkan.

30 Regression Testing Regression Testing dapat dilakukan secara manual, dengan mengeksekusi kembali suatu subset dari keseluruhan test cases atau menggunakan alat bantu otomasi capture/ playback. Alat bantu capture/ playback memungkinkan teknisi software untuk merekan test cases dan hasil-hasilnya untuk keperluan dipakai kembali dan dibandingkan pada sub sekuaen tertentu atau keseluruhan.

31 Regression Testing Sub set tes yang dieksekusi terdiri dari 3 kelas test case yang berbeda: Representasi dari contoh tes yang akan memeriksa semua fungsi software Tes tambahan yang berfokus pada fungsi software yang mungkin dipengaruhi oleh perubahan. Test yang berfokus pada komponen software yang diubah.

32 Smoke Testing Smoke Testing adalah pendekatan integration testing yang sering digunakan ketika produk software kecil terbatas dibuat. Didesain sebagai mekanisme untuk menghadapi kritisnya waktu dari suatu proyek, memungkinkan tim software untuk menjalankan proyeknya dengan suatu basis frekuensi.

33 Smoke Testing Secara mendasar, pendekatan smoke testing terdiri dari aktivitasaktivitas berikut: Komponen software yang telah ditanslasikan ke kode, diintegrasikan ke build, yang terdiri dari semua file data, pustaka, modul yang digunakan lagi, dan komponen yang dikembangkan untuk diterapkan pada satu atau lebih fungsi produk. Serangkaian tes di desain untuk menghasilkan kesalahan yang akan membuat build tetap berfungsi sebagaimana mestinya. Build diintegrasikan dengan build lainnya dan keseluruhan produk yang dilakukan smoke tes harian.

34 Validation Testing Setelah integration testing telah mencapai titik kulminasi, Software telah dirakit menjadi suatu paket komplit, kesalahan antar-muka telah dicakup dan dibenahi, dan suatu rangkaian tes akhir dari software, yaitu Validation Testing. Validasi sukses apabila fungsi-fungsi software dapat memenuhi harapan pelanggan dan dapat dipertanggungjawabkan.

35 Kriteria Validation Testing Rencana dan prosedur didesain untuk memastikan bahwa permintaan fungsional telah dipuaskan, semua karakteristik tingkah laku telah dicapai, semua permintaan kinerja dipenuhi, dokumentasi benar dan rancangan serta permintaan yang lain telah dipenuhi (transportability, compatibility, error recovery, maintainability).

36 Kriteria Validation Testing Tiap validasi Test Case dilakukan, akan terjadi satu atau dua kemungkinan kondisi: 1. Karakteristik fungsi atau kinerja memenuhi spesifikasi dan diterima atau 2. Suatu deviasi dari spesifikasi telah dicakup dan suatu daftar defisiensi dibuat.

37 Review Konfigurasi Elemen yang penting dalam proses validasi adalah review konfigurasi. Tujuannya: Memastikan semua konfigurasi software telah dikembangkan dengan benar, telah dikatalogkan dengan benar dan cukup detail untuk meningkatkan dukungan terhadap fase-fase siklus hidup software. Review Konfigurasi = Audit

38 Alpha Testing Alpha Test dilakukan pada lingkungan pengembang. Software digunakan dalam setting natural pengguna dipandang dari sisi pengembang. Dan menyimpan errors dan masalah penggunaan. Alpha Test dilakukan dalam lingkungan terkontrol

39 Beta Testing Beta Test dilakukan pada satu atau lebih lingkungan pelanggan oleh pengguna software. Beta Test adalah penerapan software pada lingkungan nyata yang tidak dapat dikendalikan oleh pengembang Pemakai menyimpan semua masalah yang terjadi selama beta testing dan melaporkannya pada pengembang dalam kurun waktu tertentu.

40 System Testing System testing adalah serangkaian tes yang berbeda dari tujuan utama untuk memeriksa sistem berbasis komputer secara penuh. Walaupun tiap tes mempunyai tujuan yang berbeda, semuanya bekerja untuk melakukan verifikasi bahwa elemen-elemen sistem telah diintegrasikan dengan benar dan melakukan fungsi-fungsi yang telah ditentukan.

41 Recovery Testing Recovery testing adalah system test yang memaksa software gagal dalam berbagai cara dan verifikasi bahwa recovery sistem berjalan dengan baik. Bila recovery otomatis dilakukan oleh sistem itu sendiri, maka perlu dievaluasi kebenaran dari re-inisialisasi, mekanisme checkpointing, data recovery, dan restart. Bila recovery membutuhkan intervensi manusia, mean-time-to-repair (MTTR), waktu rata-rata perbaikan, dievaluasi untuk menentukan apakah masih dalam batasan yang dapat diterima.

42 Security Testing Security testing digunakan untuk melakukan verifikasi mekanisme proteksi, yang dibangun ke dalam sistem akan melindungi sistem tersebut dari penetrasi yang tidak diinginkan. Selama security tester, tester memerankan tugas sebagai orang yang ingin melakukan penetrasi pada sistem. Tugas perancang sistem adalah untuk membuat biaya penetrasi lebih dari nilai informasi yang diobservasi.

43 Stress Testing Stress testing didesain untuk menghadapkan program kepada situasi yang tidak normal. Stress Testing mengeksekusi sistem dalam suatu kondisi dimana kebutuhan sumber daya tidak normal dalam kuantitas, frekuensi atau volume. Contoh: Tes khusus didesain untuk membuat sepuluh interupsi/ detik dimana satu atau dua interupsi merupakan nilai rata-rata. Test cases membutuhkan memori maksimum atau sumber-sumber lain dieksekusi

44 Stress Testing Variasi Stress testing adalah sensitivity testing. Pada beberapa situasi (kebanyakan terjadi pada algoritma matematika), interval data yang sangat kecil akan menyebabkan kondisi ekstrim bahkan kesalahan proses atau degradasi kinerja. Sensitivity testing digunakan untuk mencakup kombinasi data dalam kelas-kelas masukan yang valid yang mungkin dapat menyebabkan ketidakstabilan atau pemrosesan yang tidak dikehendaki.

45 Performance Testing Performance Testing dilakukan untuk tes kinerja software secara runtime dalam kontek sistem yang terintegrasi Performance testing terjadi di semua tahap pada proses testing. Bahkan pada tingkat unit, kinerja dari modul individual akan dinilai secara bersamaan pada saat tes white-box dilakukan Performance testing biasa digabung dengan Stress Testing dan biasanya membutuhkan instrumentasi software dan hardware.

46 Proses Debugging Debugging bukan testing tapi selalu terjadi sebagai konsekuensi testing. Proses debugging selalu mempunyai 2 hasil: 1. Penyebab ditemukan dan dibenahi. 2. Penyebab tidak ditemukan.

47 Proses Debugging

48 TERIMA KASIH