16 Testing dan Audit Perangkat Lunak - Universitas Mercu Buana Yogyakarta

Dosen Pengampu: Anief Fauzan Rozi, S.Kom., M.Eng. Phone/WA: 0856 4384 6541 PIN BB: 29543EC4 Email: [email protected] Website: http://anief.mercubuana-‐yogya.ac.id

3/17/16

Testing dan Audit Perangkat Lunak -‐ Universitas Mercu Buana Yogyakarta

1

¡  Mahasiswa mengetahui dan memahami

strategi testing.

3/17/16


2

¡  Sebuah pendekatan strategis untuk

pengujian ¡  Seni pelacakan kesalahan

3/17/16


3

¡  ¡ 

¡  ¡  ¡ 

Agar pengujian efektif, lakukan tinjauan teknis yang efektif Pengujian dimulai pada tingkat komponen, menuju integrasi sistem berbasis komputer secara keseluruhan Teknik pengujian yang berbeda, bagi penguji yang berbeda, pada waktu yang berbeda Pengujian dilakukan oleh pengembang dan kelompok penguji independen Pengujian dan pelacakan kesalahan adalah aktivitas yang berbeda, namun pelacakan kesalahan harus terakomodasi dalam setiap strategi pengujian

3/17/16


4

¡ 

¡ 

Verifikasi dan validasi

Pengujian perangkat lunak adalah salah satu dari suatu topik yang lebih luas yang sering disebut sebagai verifikasi dan validasi (V & V) Verifikasi: ”apakah kita membangun produk dengan benar?” §  Sekumpulan tugas yang memastikan bahwa perangkat

lunak benar-‐benar menerapkan fungsi yang ditentukan.

¡ 

Validasi: “apakah kita membangun produk yang benar?”

§  Sekumpulan tugas yang memastikan bahwa perangkat

lunak yang telah dibangun dapat dilacak berdasar persyaratan pelanggan.

3/17/16


5

Melakukan pengujian PL

Pengujian terkesan bertujuan untuk “merusak” apa yang telah dibangun oleh rekayasawan perangkat lunak. ¡  Sebagian besar kesalahpahaman: ¡ 

§  Pengembang harusnya sama sekali tidak melakukan

pengujian §  Perangkat lunak harus “dilempar dari tembok” kepada orang asing untuk diuji habis-‐habisan §  Penguji hanya terlibat hanya pada saat pengujian hendak dimulai. 3/17/16


6

¡  Peran Independent Test Group (ITG): §  Menghapus masalah yang melekat sehubungan

dengan membiarkan pengembang menguji apa yang telah dikembangkannya §  Menghilangkan konflik kepentingan yang bisa saja ada. §  Bekerja dengan pihak pengembang di seluruh proyek perangkat lunak untuk memastikan bahwa pengujian akan dilakukan secara menyeluruh. 3/17/16


7

Gambaran umum: System Testing Validation Testing Integration Testing Unit Testing Code Design Requirements System Engineering

3/17/16


8

Unit testing

Berfokus pada upaya verifikasi terhadap unit terkecil dari perancangan perangkat lunak (komponen atau modul) ¡  Berfokus pada logika pemorsesan internal dan struktur data di dalam batas-‐batas komponen ¡  Dapat disederhanakan ketika modul didesain dengan kompleks ¡  Berfokus pada modul inti ketika sumber pengujian terbatas ¡ 

3/17/16


9

¡ 

Integration testing

Adalah teknik sistematik untuk membangun arsitektur perangkat lunak, §  sementara pada saat yang sama melakukan pengujian

untuk menemukan kesalahan-‐kesalahan yang terkait dengan antarmuka.

¡ 

¡ 

Tujuannya adalah untuk mengambil komponen yang diuji dan membangun struktur program yang telah ditentukan oleh perancangan. Terdapat dua pendekatan: §  Non-‐incremental Integration Testing §  Incremental Integration Testing

3/17/16


10

¡ 

Validation testing #1

Dimulai di titik puncak pengujian integrasi ketika: §  komponen individu telah dieksekusi, §  Perangkat lunak sudah benar-‐benar dirakit sebagai

sebuah paket, §  Kesalahan antarmuka telah ditemukan dan diperbaiki.

Perbedaan antara perangkat lunak konvensional dan berorientasi objek menghilang. ¡  Fokus pada tindakan pengguna yang terlihat dan output dari sistem yang dikenali pengguna ¡ 

3/17/16


11


¡ 

Dirancang untuk memastikan bahwa:

§  Semua fungsional memenuhi persyaratan yang

diminta, §  Semua karakteristik perilaku tercapai, §  Semua isi disajikan secara akurat dan benar, §  Semua persyaratan kinerja tercapai, §  Pendokumentasian benar, §  Kegunaan dan persyaratan lainnya terpenuhi (transportability, kompabilitas, pemeliharaan). 3/17/16


12


¡ 

Setelah setiap kasus pengujian validasi dilakukan: §  Karakteristik fungsi atau kinerja sesuai dengan

spesifikasi dan diterima, atau §  Penyimpangan dari spesifikasi ditemukan dan daftar kelemahan pun dibuat.

3/17/16


13

System testing #1 ¡  Terbagi menjadi: §  Recovery testing §  Security testing §  Stress testing §  Performance testing

3/17/16


14

System testing #2

¡ 

Recovery testing

§  Pengujian sistem yang memaksa perangkat lunak

untuk gagal dalam berbagai cara dan memverifikasi bahwa pemulihan dilakukan dengan benar.

¡ 

Security testing

§  M e n c o b a u n t u k m e m v e r i fi k a s i m e k a n i s m e

perlindungan yang dibangun ke dalam sistem, yang pada kenyataannya, melindunginya dari penetrasi yang tidak benar

3/17/16


15

¡ 

System testing #3

Stress testing

§  Menjalankan sistem dengan cara yang meminta

sumber daya dalam jumlah, frekuensi, atau volume yang abnormal.

¡ 

Performance testing

§  Dirancang untuk menguji kinerja run-‐time dari

perangkat lunak dalam konteks sebagai sistem yang terintegrasi. §  Terjadi di seluruh langkah dalam pengujian proses. §  Pada level unit, kinerja modul individual dapat dinilai saat pengujian dilakukan. 3/17/16


16

¡  ¡  ¡  ¡ 

¡ 

Pengantar

Pelacakan kesalahan = debugging Debugging ≠ testing Terjadi sebagai akibat pengujian yang berhasil. Saat kasus pengujian mengungkap kesalahan, debugging adalah proses yang menghasilkan penghapusan kesalahan. Tujuan utama debugging à untuk mencari dan memperbaiki penyebab kesalahan atau cacatnya perangkat lunak.

§  Direalisasikan dengan gabungan antara evaluasi yang

sistematis, intuisi, dan keberuntungan.

3/17/16


17

Proses pelacakan kesalahan

Dimulai dengan melakukan test case 2.  Hasilnya dinilai à kinerja yang diharapkan ≠ kinerja sesungguhnya Proses pelacakan kesalahan mencoba untuk mencocokkan gejala dengan penyebabnya à koreksi kesalahan. 1. 

3/17/16


18

¡  ¡  ¡  ¡  ¡ 

Mengapa debugging begitu sulit?

Gejala dan penyebabnya mungkin secara geografis jauh. Gejala mungkin hilang (sementara) saat kesalahan lain dikoreksi Gejala dapat disebabkan oleh human error yang sulit dilacak Gejala mungkin lebih karena akibat masalah waktu daripada akibat masalah pemrosesan Mungkin sulit untuk secara akurat mereproduksi kondisi masukan §  Aplikasi real-‐time di mana urutan masukan adalah tak

tentu.

3/17/16


19

¡  Brute force ¡  Backtracking

Strategi

¡  Cause elimination

3/17/16


20

Strategi #1: Brute force

¡  Yang paling umum dan merupakan metode

paling efisien ¡  Digunakan ketika semuanya (stategi lain) gagal ¡  Melibatkan penggunaan memory, run-‐time, dan output ¡  Banyak upaya dan waktu yang terbuang 3/17/16


21

Strategi #2: Backtracking

¡  Umumnya berhasil digunakan untuk

program-‐program kecil (berbaris sedikit) ¡  Dimulai di tempat di mana gejala telah ditemukan, kode program kemudian dilacak secara manual sampai penyebabnya ditemukan.

3/17/16


22

Strategi #3: Cause elimination

¡  Ditunjukkan oleh induksi atau deduksi dan

memperkenalkan konsep partisi biner. ¡  Data yang terkait dengan terjadinya kesalahan dikelola untuk mengisolasi penyebab potensial. ¡  “Hipotesis penyebab” ditemukan dan data tersebut digunakan untuk membuktikan atau menyingkirkan hipotesis 3/17/16


23

Tiga pertanyaan yang sebaiknya ditanyakan sebelum membuat pelacakan kesalahan: 1.  Apakah penyebab kesalahan dibuat ulang di bagian lain dari program ini? 2.  Apakah kesalahan selanjutnya dapat terjadi akibat perbaikan yang saya sedang buat? 3.  Apa yang bisa kita lakukan untuk mencegah kesalahan ini di tempat pertama? 3/17/16


24

3/17/16


25

16 Testing dan Audit Perangkat Lunak - Universitas Mercu Buana Yogyakarta

Recommend Documents