Materi Perkuliahan Menjalankan test Menganalisa hasil

Presentasi berjudul: "Materi Perkuliahan Menjalankan test Menganalisa hasil"— Transcript presentasi:

1 Materi Perkuliahan Menjalankan test Menganalisa hasil
Melaporkan hasil ke developer dan manager (overview)

2 Tahap-tahap Pengujian :
Tentukan apa yang akan diukur melalui pengujian Bagaimana pengujian akan dilaksanakan Membangun suatu kasus uji (test case), yaitu sekumpulan data atau situasi yang akan digunakan dalam pengujian. Tentukan hasil yang diharapkan atau hasil sebenarnya Jalankan kasus pengujian bandingkan hasil pengujian dan hasil yang diharapkan.

3 Menjalankan test Testing aplikasi desktop Testing aplikasi server
Testing aplikasi web

4 Testing aplikasi desktop
Jenis : Functionality Configuration Compatibility

5 Testing aplikasi server
Jenis : Volume Testing Stress Testing Performance Testing Recovery Testing.

6 Volume Testing Menemukan kelemahan di sistem terkait dengan bagaimana “handling” dari sistem jika diberikan data yang besar dalam kurun waktu yang singkat

7 Stress Testing Untuk memastikan bahwa sistem memiliki kapasitas untuk menghandle pemrosesan transaksi dalam jumlah besar selama “peak period”

8 Performance Testing Dapat dilakukan secara paralel dengan volume dan stress testing karena yang ingin diketahui adalah bagaimana kinerja sistem pada semua kondisi load, baik itu jam-jam sibuk atau sebaliknya Biasanya terkait dengan response time dan rata-rata proses yang dapat diselesaikan dalam berbagai macam konfigurasi dan kondisi pemrosesan Harus mencakup semua konfigurasi hardware dan sistem (laptop VS desktop, LAN vs WAN, dll)

9 Recovery testing Data recovery Server recovery

10 Data Recovery Testing Kemampuan data recovery dan system restart dapat menghemat waktu dan uang ketika terjadi kegagalan pada sistem produksi Ada bermacam-macam level teknologi RAID (Redundant Array of Inexpensive Disks) yang merupakan framework untuk menyebarkan data di beberapa database atau file server dan memastikan data dapat direcovery jika terjadi kegagalan pada salah satu server. Yang perlu dites adalah recovery options untuk sistem RAID kita ketika memonitor performa sistem tersebut

11 Server Recovery Server recovery testing harus mencakup testing recovery dari jenis error : GPPE errors  ketika terjadi operasi prosesor yang invalid IOPE errors  ketika server mengeksekusi path yang invalid NMI errors (hardware generated errors)  ketika terjadi kegagalan RAM atau fluktuasi power Break Points  ketika suatu stack corrupted yang mengakibatkan invalid return point atau ketika pointer merefer ke lokasi yang invalid

12 Data Security Testing Menguji akses kontrol untuk tool yang dipergunakan pihak ketiga Menguji prosedur untuk kontrol akses ke tabel database tertentu Menguji pemakaian password yang terenkripsi / transmisi data Menguji pemakaian user name bayangan (shadow user name) untuk user yang memiliki akses write dan read.

13 Automated Server Testing Tools.
Stored procedures dan data base triggers sebaiknya diuji dengan driver modules yang mengakses langsung ke database layer Salah satu contoh automated testing tool adalah LoadRunner/XL yang menguji sisi server dari aplikasi multi-user Client-Server untuk perencanaan kapasitas dan menentukan konfigurasi server yang mendukung kinerja database

14 Automated Server Testing Tools.
Blue Lagoon Software yang menyediakan tool untuk menguji link antara client dan server Mercury/Blue Lagoon Software juga menyediakan SQL Profiler yang menyimpan dan memperlihatkan statistik tentang SQL command yang ter-embed dalam aplikasi C-S

15 Network Security Testing
Menguji parameter dan konfigurasi jaringan (firewall, web server, mail server dll) Menguji transmisi media jaringan Menguji koneksi WAN/MAN/LAN Menguji kinerja network provider

16 NEXT TIME

17 Testing aplikasi web Testing untuk aplikasi web memiliki banyak kesamaan dengan testing untuk aplikasi client server, tetapi aplikasi web lebih sulit karena tingkat kompleksitasnya lebih tinggi  interaksi komponen (teknologi) yang dipergunakan tidak terbatas Browser OS Aplikasi plugin, dll

18 Cont’d Idealnya semua komponen dan fungsi yg ada pada sisi client dan server harus dites (tapi sgt jarang bisa dilakukan)  pendekatan terbaik agar tetap sesuai dengan batasan waktu dan budget : Mengecek requirement project Mensetting prioritas sesuai hasil risk analysis Tentukan fokus testing yg dilakukan

19 Risk analysis Risk analysis yang dilakukan harus mempertimbangkan :
seberapa mirip lingkungan test dengan lingkungan produksi (idealnya akan mirip) fungsionalitas mana yang sangat kritikal terhadap tujuan pembuatan website area mana yang memerlukan interaksi DB yang lebih banyak

20 Cont’d tipe permasalahan seperti apa yang akan lebih sering dikomplain
area mana dari suatu situs yang akan lebih sering dibuka aspek mana yang memiliki resiko keamanan lebih tinggi

21 faktor faktor seperti project requirement, risk analysis, budget dan schedule menentukan kategori testing yang mana yang sesuai dengan project web yang dilaksanakan

22 Kategori testing web Load testing Security testing Link testing
HTML validation dll

23 Penjelasan Load testing
Testing dengan load yang sudah diatur rangenya untuk menentukan pada poin mana respons time sistem turun atau bahkan gagal sama skali. Server yang dipakai, seting konfigurasi yang dipergunakan, script CGI, desain database dan faktor-faktor lain bisa juga memberikan pengaruh Testing bisa dilakukan dengan 2 cara Testing keseluruhan komponen dibawah kondisi yang bermacam-macam Testing masing-masing komponen

24 Security testing Menguji semua fungsi yg berhubungan dengan firewall, enkripsi, autentikasi, transaksi, akses database Menguji perlindungan yang diberikan Selain permasalahan kontrol akses di sisi client (password dan enkripsi) juga ada permasalahan di sisi server spt siapa yg berhak mempublish dan memodifikasi file html, siapa yang memiliki wewenang untuk melakukan publikasi final, yang meng-approve suatu file graphics, file sound dan halaman layout

25 Link testing HTML validation
Untuk menentukan apakah link dari suatu situs baik itu ke internal dan external web pages bekerja Web yg memiliki banyak link ke situs luar perlu link testing yg dijadwal secara teratur  kenapa ? HTML validation Ditentukan oleh audience yg dituju, jenis browser yang kemungkinan akan dipakai dan seberapa sesuai dengan standar html, microsoft atau ekstensi lainnya

26 NEXT TIME

27 Tool yang dipergunakan
Load testing Curl-Loader, StressTester, Proxy Sniffer, Funkload, Loadea, LoadManager, webStress, WAPT, FORECAST, dll Security testing Hailstorm, OWASP Security testing tools, GamaSec, Wikto, add-ons di firefox  SQL Inject Me 0.4.0

28 Link testing HTML validation WebLight, HTML PowerTools, Broken Link
Preventer, W3C Link Checker HTML validation WebLight, HTML PowerTools, W3C CSS Validation Service, W3C HTML Validation Service

29 NEXT TIME

30 Menganalisa hasil

31 Melaporkan hasil ke developer dan manager
Pelaporan hasil ke developer dan manager  melalui dokumentasi  agar lebih mudah dimengerti, dibuatlah standar yang mengatur dokumentasi testing (standar tersebut bersifat universal) Pendokumentasian testing Standar dokumentasi testing

32 Outline Pendokumentasian testing Standar dokumentasi testing
Bug tracking

33 Testing yang dilakukan harus didokumentasikan
Tujuan pendokumentasian testing : Menyediakan data terkait dengan kesiapan peluncuran sistem Menyediakan data terkait dengan long term detection dari permasalahan suatu fungsi

34 Isi dari dokumentasi testing
Functional testing status Berapa persen : Selesai ditest Ditest dengan status defect masih open Tidak ditest Expected vs actual defect detected hasil analisa antara jumlah defect yang diharapkan akan muncul (pada fase planning) dan jumlah defect yang benar-benar muncul

35 Defect detected vs corrected
hasil analisa antara jumlah defect yang sudah dideteksi (dan belum terselesaikan) dengan jumlah defect yang sudah diperbaiki Defect distribution menjelaskan lokasi defect ditemukan (modul atau fungsi)

36 Testing action menjelaskan tentang ringkasan kegiatan testing yang sudah dilakukan. Ex : apakah ada testing yang molor dari jadwal yang telah ditentukan, testing bagian apa, karena apa

37 Standar dokumentasi testing
Standar IEEE 829 Mengatur dokumentasi standar untuk : Testplan Test design specification Test case specification Test procedure specification Test item transmittal report Test log Test incident report Test summary report

38 Bug tracking/defect tracking
Tujuan dari testing adalah menemukan sebanyak mungkin defect/bug Penyebabnya: Berbeda dengan spesifikasi produk Berbeda dengan keinginan user Setelah ditemukan, defect tersebut harus disampaikan ke developer – dilaporkan atau direkam

39 Tujuan utama dari merekam/melaporkan bug/defect
Untuk memperbaiki defect Untuk melaporkan status dari aplikasi Untuk memperoleh statistik yang dipergunakan untuk mengembangkan ekspektasi defect untuk pengembangan aplikasi mendatang Untuk meng-improve proses pengembangan software

40 Item yang harus dilaporkan dalam defect tracking :
Nama defect Sumber Defect severity Defect priority Status Detil deskripsi PIC untuk memperbaiki defect

41 Setelah dilakukan perbaikan oleh developer, harus dilakukan retest terhadap perbaikan tersebut
untuk memastikan bahwa perbaikan yang dilakukan tidak bermasalah di tempat lain Diperlukan mekanisme problem tracking

42 Informasi yang diperlukan pada problem tracking
Bug identifier Status terbaru Test case identifier Nama tester Tanggal testing Tanggal pelaporan bug

43 PIC untuk perbaikan Deskripsi penyebab bug Deskripsi perbaikan Tanggal perbaikan Tester untuk retest Tanggal retest Hasil retest

44