Mkpl Pertemuan5

32
Pengujian, Validasi dan Verifikasi Perangkat Lunak Pertemuan 5

description

 

Transcript of Mkpl Pertemuan5

Page 1: Mkpl Pertemuan5

Pengujian, Validasi dan Verifikasi Perangkat Lunak

Pertemuan 5

Page 2: Mkpl Pertemuan5

Definisi Pengujian Perangkat Lunak

Myers’1979 Proses menjalankan program dengan maksud

menemukan kesalahan IEEE’1990

Proses sistem operasi atau komponen menurut kondisi tertentu, pengamatan atau pencatatan hasil dan mengevaluasi beberapa aspek sistem atau komponen

Proses analisa item perangkat lunak untuk mendeteksi perbedaan antara kondisi yang ada dengan yang diinginkan dan mengevaluasi fiture item perangkat lunak

Page 3: Mkpl Pertemuan5

Definisi Pengujian Perangkat Lunak

Proses formal yang ditentukan oleh tim pengujian yang meliputi unit perangkat lunak, beberapa unit terintegrasi atau seluruh paket yang ditentukan oleh program yang berjalan dikomputer. Seluruh test saling terkait dan adanya prosedur pengujian dan kasus pengujian

Page 4: Mkpl Pertemuan5

Tujuan Pengujian PL

Tujuan Langsung Untuk identifikasi dan menemukan beberapa

kesalahan yang mungkin ada dalam perangkat lunak yang diuji

Setelah perangkat lunak dibetulkan, diidentifikasi lagi kesalahan dan ditest ulang untuk menjamin kualitas level penerimaan

Membentuk test yang efisien dan efektif dengan anggaran dan jadwal yang terbatas

Tujuan tidak langsung Mengumpulkan daftar kesalahan untuk digunakan

dalam daftar pencegahan kesalahan (tindakan corrective dan preventive)

Page 5: Mkpl Pertemuan5

Apa yang bisa ditunjukkan oleh pengujian ?

errorserrors

requirements conformancerequirements conformance

performanceperformance

an indicationan indicationof qualityof quality

Page 6: Mkpl Pertemuan5

Kategori Test

Unit unit testing dipakai pada modul single standalone module

atau unit dari code Integration

Testing pada group dari modul System

memeriksa/memvalidasi apakah sistem memenuhi persyaratan

Acceptance testing untuk memastikan bahwa sistem cocok dengan

kebutuhan dari organisasi dan end user Regression

testing setelah perubahan telah dibuat untuk memastikan bahwa tidak ada perubahan yang tidak diinginkan itu ada

Page 7: Mkpl Pertemuan5

Strategi Pengujian Perangkat Lunak

Meskipun metodologi pengujian mungkin berubah, ada dua dasar strategi pengujian Menguji perangkat lunak secara keseluruhan,

sekali untuk semua package yang ada, “big bang testing”

Menguji perangkat lunak per bagian dalam modul (unit testing), dilanjutkan dengan menguji integrasi setiap modul (integration test), selanjutnya seluruh package di uji (system test) Strategi “Incremental Testing”

Page 8: Mkpl Pertemuan5

Incremental Testing

Dibentuk dari dua dasar strategi Bottom-up Top-down

Kedua strategi incremental testing ini menganggap bahwa package perangkat lunak dibangun berdasarkan hirarki modul perangkat lunak

Page 9: Mkpl Pertemuan5

Incremental Testing

Pengujian Top-down Modul pertama yang diuji adalah modul utama Level

modul tertinggi dalam struktur perangkat lunak Modul terakhir yang diuji adalah modul yang berada

pada level paling rendah Pengujian Bottom-up

Kebalikan dari Top-down Yang diuji pertama adalah modul yang terletak pada

level paling rendah Modul terakhir yang diuji adalah modul utama

Page 10: Mkpl Pertemuan5

Bottom Up versus Top down strategies

Bottom Up Keuntungan

Relatif mendorong performance Kerugian

Menghambat program sebagai sebuah keseluruhan modul (yang diamati pertama modul dilevel paling rendah)

Top-down Keuntungan

Memperlihatkan keseluruhan fungsi program semua modul lengkap

Kerugian Sulit menyiapkan potongan program Sulit untuk menganalisa hasil test

Page 11: Mkpl Pertemuan5

Langkah-lagkah membangun taktik pengujian

1. Memperoleh dan mempelajari strategi pengujian

2. Menentukan tipe proyek yang dibangun

3. Menentukan tipe dari sistem perangkat lunak

4. Menentukan ruang lingkup proyek

5. Mengidentifikasi resiko taktik

6. Menentukan kapan testing dilakukan

7. Membangun rencana sistem

8. Membangun rencana test unit

Page 12: Mkpl Pertemuan5

1: Memperoleh dan mempelajari strategi pengujian Dala hal ini, tim harus menanyakan :

Apa hubungan dari kepentingan diantara faktor-faktor test ?

Mana resio level tinggi yang paling signifikan ? Kerusakan apa yang dapat terjadi pada bisnis

apabila perangkat lunak gagal untuk menampilkan dengan benar ataupun tidak lengkap pada waktunya?

Siapa orang yang paling tahu dalam memahami dampak dari resiko bisnis yag telah diidentifikasi?

Page 13: Mkpl Pertemuan5

2: Menentukan tipe proyek yang dibangun

Pembangunan sistem tradisional Prototyping System Maintenance Pembelian atau penyewaan perangkat

lunak

Page 14: Mkpl Pertemuan5

3. Menentukan tipe dari sistem perangkat lunak

Batch Even control Process control Procedure control Advanced mathematical

model Message processing Diagnostic software Sensor and signal

processing Simulation

Database management Data acquisition Data presentation Decision and planning aids Pattern and image

processing Computer system software Software development tools

Page 15: Mkpl Pertemuan5

4. Menentukan ruang lingkup proyek

Pembangunan sistem baru Proses bisnis otomatis

atau manual ? Proses bisnis dan area

yang mana yang akan atau tidak akan terpengaruh ?

interfacing pada sistem yang ada ?

Sistem yang sudah ada akan atau tidak akan terpengaruh ?

Merubah yang sudah ada Hanya mengkoreksi ? Standar perawatan

rekayasa ulang ? Koreksi pada kerusakan

yang tersembunyi untuk ditambahkan pada perbaikan ?

Apakah sistem yang lain terpengaruh ?

Resiko atau regresi ?

Page 16: Mkpl Pertemuan5

5. Mengidentifikasi resiko taktik

Ada tiga kategori dari resiko taktik Structural risks: berhubungan dengan aplikasi dan

metode yang digunakan untuk membangun aplikasi Technical risks: berhubungan dengan teknologi yang

digunakan dalam membangun dan mengoperasikan apikasi

Size risks: berhubungan dengan besarnya dalam segala aspek dari perangkat lunak

Page 17: Mkpl Pertemuan5

6. Menentukan kapan testing dilakukan

Tahap persyaratan Menentukan strategi test Menentukan ketercukupan persyaratan Menjalankan kondisi test fungsional

Tahap Desain Menentukan konsistensi dari desain yang disyaratkan Menentukan ketercukupan desain Menjalankan konsistensi test struktural dan fungsional

Tahap coding Menentukan konsistensi dengan desain Menentukan ketercukupan dari implementasi Menjalankan kondisi test struktural dan fungsional Generate structural

dan functional test untuk program atau unit

Page 18: Mkpl Pertemuan5

7. Membangun rencana sistem

Menetapkan background informasi Software yang di test Objektivitas Test and resiko Fungsi bisnis yang akan dit test Spesifik tests yang akan dilakukan

Page 19: Mkpl Pertemuan5

8. Membangun rencana test unit

Setiap unit harus mempunyai testnya masing-masing

Page 20: Mkpl Pertemuan5

Pengelompokkan berdasarkan konsep pengujian Black box (functionality) testing

Mengidentifikasi kesalahan yang berhubungan dengan kesalahan fungsionalitas perangkat lunak yang tampak dalam kesalahan output.

White box (structural) testing Memeriksa kalkulasi internal path untuk

mengidentifikasi kesalahan disebut juga glass box testing

Page 21: Mkpl Pertemuan5

Definisi Black box dan white box IEEE Black box testing

Pengujian yang mengabaikan mekanisme internal sistem atau komponen dan fokus semata-mata pada output yang dihasilkan yang merespon input yang dipilih dan kondisi eksekusi

Pengujian dilakukan untuk mengevaluasi pemenuhan sistem atau komponen dengan kebutuhan fungsional tertentu

White box testing Pengujian yang memegang perhitungan mekanisme

internal sistem atau komponen

Page 22: Mkpl Pertemuan5

Klasifikasi sesuai kebutuhan

Software Quality Assurance (Daniel Galin) Lihat Tabel 9.1

Mapping antara software quality factor, sub factor dengan klasifikasi test

Lihat Tabel 9.2 Mapping klasifikasi test dengan kategori

pengujian (white box dan black box)

Page 23: Mkpl Pertemuan5

Black Box

Berusaha untuk menemukan Kesalahan atau hilangnya fungsi Kesalahan interface Kesalahan dalam struktur data atau akses eksternal basis data Kesalahan performance Kesalahan inisialisasi dan terminasi

Tes dirancang untuk menjawab pertanyaan berikut ini: Bagaimana validitas fungsi diuji? Kelas input apa yang membuat kasus uji berjalan dengan baik? Apakah sistem tertentu sensitif terhadap beberapa nilai input? Bagaimana batas kelas data dipisahkan? Apakah laju data dan volume data dapat dihadapi sistem? Apa ada dampak khusus jika data digabungkan dengan operasi

sistem?

Page 24: Mkpl Pertemuan5

White box Testing

Ada 4 Kategori test pada white box testing Data processing dan calculations correctness

test Software qualification test Maintainability test Reusability test

Page 25: Mkpl Pertemuan5

Data processing dan calculations correctness Test Melakukan pengecekan data processing

untuk setiap kasus test. Ada 2 pendekatan yang dilakukan:

Path Coverage Rencana test yang mencakup semua

kemungkinan path, dimana coverage diukur dengan berapa % path dicover

Line Coverage Rencana test yang mencakup semua baris kode

program, dimana coverage diukur dengan berapa % line dicover

Page 26: Mkpl Pertemuan5

Correctness tests dan path coverage

Path yang berbeda dalam modul software akan dibentuk oleh pilihan kondisional statement seperti IF-THEN-ELSE atau DO WHILE atau DO UNTIL atau REPEAT-UNTIL

Page 27: Mkpl Pertemuan5

Correctness tests dan line coverage

Untuk full line coverage maka setiap line sedikitnya dieksekusi minimal satu kali selama proses pengujian

Page 28: Mkpl Pertemuan5

McCabe’s cyclomatic complexity metric Dikembangkan oleh McCabe (1976) untuk mengukur

kompleksitas program atau modul pada waktu yang sama sebagai jumlah maksimum independent path yang dibutuhkan untuk mencapai full line coverage pada program.

Dasar ukuran adalah teori graf dan dihitung berdasarkan kesesuaian ke sifat program yang dicapture oleh program flow graph

Independent path adalah setiap path pada program flow graph sedikitnya satu baris yang tidak dibentuk oleh independent path lain.

Page 29: Mkpl Pertemuan5

Example

20 times

A

B

How many test cases ?

Page 30: Mkpl Pertemuan5

Structural test - Control graph(Static point of view)

011123333444445677891011121213141415161617181819

void main (void) { int a, b, c; int min, med, max; if (a>b) { max=a; min=b; } else { max=b; min=a; } if (c>max) {max=c;} else if (c<min) {min=c;} med=a+b+c-min-max; if (max>min+med) {printf("impossible triangle \n");} else if (max==min) {printf("equilateral triangle \n");} else if (max==med || med==min) {printf("isoceles triangle \n");} else if ( max *max == min*min+med*med) {printf("rightangled triangle\n");} else {printf("any triangle\n");} }

v(G) = 25 - 19 + 2 = 8

1

10

1112

1314

3 4

5

6 7

8

9

17

1516

18

19

2

Example :if ( a > b and b > c) then

max=a;else

max = 100;end if ;

Page 31: Mkpl Pertemuan5

RUMUS

V(G) = R V(G) = E – N +2 V(G) = P + 1

Keterangan V(G) = cyclometic complexity metric R = jumlah region dalam program flow graph

Setiap area yang melingkungi graph disebut sebuah region

E = Jumlah Edge (garis) N = Jumlah node P= Jumlah decision

Page 32: Mkpl Pertemuan5

Sekian