Pengujian, Validasi dan Verifikasi Perangkat Lunak

Pertemuan 5

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

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

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)

Apa yang bisa ditunjukkan oleh pengujian ?

errorserrors

requirements conformancerequirements conformance

performanceperformance

an indicationan indicationof qualityof quality

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

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”

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

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

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

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

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?

2: Menentukan tipe proyek yang dibangun

Pembangunan sistem tradisional Prototyping System Maintenance Pembelian atau penyewaan perangkat

lunak

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

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 ?

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

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

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

8. Membangun rencana test unit

Setiap unit harus mempunyai testnya masing-masing

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

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

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)

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?

White box Testing

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

test Software qualification test Maintainability test Reusability test

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

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

Correctness tests dan line coverage

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

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.

Example

20 times

A

B

How many test cases ?

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 ;

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

Sekian