PEMOGRAMAN TERSTRUKTUR C++

Oleh :Lerby Montung

Program :Mgmt. Informatika

(16) STUBS AND DRIVERS

• Stubs and drivers are very helpful tools for testing and debugging programs that

use functions.

• A stub is a dummy function that is called instead of the actual function it

represents.

• A driver is a program that tests a function by simply calling it.

// Stub for the adult function.

void adult(int months)

{

cout << "The function adult was called with " << months;

cout << " as its argument.\n";

}

// Stub for the child function.

void child(int months)

{

cout << "The function child was called with " << months;

cout << " as its argument.\n";

}

// Stub for the senior function.

void senior(int months)

{

cout << "The function senior was called with " << months;

cout << " as its argument.\n";

}

Penjelasan Singkat

Stubs and Drivers merupakan suatu istilah ini sering digunakan pada pengujian

integrasi software yang secara umum adalah berupa potongan kode dengan meniru

fungsi panggilan.

Selain istilah Stubs And Drivers merupakan suatu peralatan yang sangat membantu

dalam pengujian akan suatu fungsi program.

Contohnya pengujian – pengujian ini secara fisual dapat kita lihat pada saat kita

membuat suatu program pada aplikasi pemograman seperti Microsoft Visual Foxpro,

Visual Basic, ketika kita membuat suatu program dan hendak menguji program tersebut

maka kita meng compile / run program tersebut sehingga terjadi pemanggilan data

dimana data yang muncul adalah gambaran suatu program yang masih sementara.

Dapat kita lihat lagi pada contoh pada halaman sebelumnya Kode pengujian dengan

menggunakan C++ , terdiri dari 3 pemanggilan data istilah dewasa, anak dan senior

dengan menggunakan tipe data interger bulan.

Penjelasan Umum

Prosedur pengujian unit. Pengujian unit pada umumnya merupakan perkembangan dari langkah

pengkodean.

Setelah program sumber dikembangkan, ditinjau kembali dan diverifikasi untuk

sintaknya, maka perancangan test case di mulai.

Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk

menentukan test case.

Karena modul bukan program yang berdiri sendiri, maka driver (pengendali) dan

atau stub perangkat lunak harus dikembangkan untuk tiap-tiap pengujian unit.

MODUL TESTING (pengujian modul) Pengujian interaksi dari semua komponen yang berhubungan terhadap modul.

Pengujian modul yang indpendent.

Modul secara individu diuji secara terpisah.

Modul berupa kumpulan fungsi, prosedure atau program-program.

Tidak secara increment, biasanya dilakukan oleh seorang programmer yang

membuat program tersebut.

Menggunakan stub dan driver.

Pengujian whit-box cocok untuk tingkatan ini.

Pengujian struktur data lokal, kondisi batasan, jalur independen, jalur

penanganan kesalahan.

Formal : rencana pengujian dijelaskan dan tertulis.

Modul bukanlah program yang berdiri sendiri, perangkat lunak driver dan atau

stub harus dikembangkan bagi masing-masing pengujian unit.

Pada sebagian besar aplikasi, driver tidak lebih dari sebuah “program utama”,

yang menerima data test case.

Data sampai ke modul untuk diuji, dan kemudian mencetak hasil yang relevan.

Stub berfungsi untuk menggantikan modul yang merupakan subordinat dari

modul yang akan diuji.

Stub menggunakan interface modul subordinat untuk melakukan manipulasi data

minimal, mencetak , entri dan kembali.

INTEGRATION TESTING (pengujian integrasi)♪      Pengujian integrasi adalah teknik yang sistematis untuk mengkonstruksi susunan

program sambil melakukan pengujian  untuk memeriksa kesalahan yang nantinya

digabungkan dengan interface.

♪      Sasarannya adalah untuk mengambil modul yang dikenai pengujian unit dan

membangun struktur program yang telah ditentukan oleh desain.

♪      Kesulitannya adalah lokalisasi error yang sulit ditemukan pada saat proses.

♪      Terdapat interaksi yang rumit antara komponen sistem dan ketika ditemukan

output yang menyimpang, mungkin sulit untuk menemukan sumber error tersebut.

Integrasi non-inkremental Program diuji sebagai satu kesatuan. Serangkaian kesalahan akan terjadi. Koreksi sulit

dilakukan karena isolasi penyebab diperumit oleh luasnya program keseluruhan. Sekali

kesalahan tersebut dibetulkan, maka akan muncul lagi yang baru dan proses itu terus

berlanjut dalam loop yang kelihatannya tidak akan pernah berhenti.

Integrasi inkremental Program dibangun dan diuji di dalam segmen-segmen kecil, sehingga kesalahan lebih

mudah diisolasi dan dibetulkan, interface lebih mungkin untuk diuji secara lengkap, dan

pendekatan pengujian yang sistematis dapat diaplikasikan.

Top-down Integrasi adalah pendekatan inkremental terhadap struktur program.

Modul diintegrasikan dengan menggerakkan ke bawah melalui hirarki kontrol,

dimulai dengan modul kontrol utama (program utama).

Memverifikasi kontrol utama dan keputusan pada saat awal proses pengujian.

Pada struktur program yang dibuat dengan baik, keputusan akan dikerjakan

pada tingkat atas hirarki.

Stub mengganti modul tingkat rendah pada awal pengujian top-down, sehingga

tidak ada data yang penting yang dapat mengalir ke atas di dalam struktur

program.

Proses integrasi dilakukan dalam 5 (lima) langkah  :

1. Modul kontrol utama digunakan sebagai test driver, dan stub ditambahkan pada

semua modul yang secara langsung subordinat terhadap modul kontrol utama.

2. Stub subordinat diganti pada suatu saat dengan modul aktual.

3. Pengujian dilakukan pada saat masing-masing modul diintegrasi.

4. Pada pelengkapan masing-masing rangkaian pengujian, stub yang lain diganti

dengan modul real.

5. Pengujian regresi dapat dilakukan untuk memastikan bahwa kesalahan baru

belum dimunculkan.

Bottom-up Integrasi Dapat dinyatakan dengan penyusunan yang dimulai dan diuji dengan atomic

modul (modul tingkat paling bawah pada struktur program).

Modul diintegrasikan dari bawah ke atas sehingga pemrosesan yang diperlukan

untuk modul subordinat yang selalu diberikan akan selalu tersedia dan

kebutuhan akan stub dapat dieliminasi.

Strategi bottom-up integration dapat diterapkan dengan urutan langkah-langkah

sebagai berikut  :

1. Modul tingkat bawah digabungkan ke dalam cluster (sering disebut build) yang

malakukan subfungsi perangkat lunak spesifik.

2. Driver (program kontrol untuk pengujian) ditulis untuk mengkoordinasi input dan

output test case.

3. Cluster diuji.

4. Driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di

dalam struktur program.

Regression Testing ( pengujian regresi ) adalah aktivitas yang membantu memastikan bahwa perubahan (karena

pengujian atau alasan lain) tidak menimbulkan tingkah laku yang tidak

diharapkan atau kesalahan tambahan.

Merupakan eksekusi ulang dari beberapa subset yang telah dilakukan untuk

memastikan bahwa perubahan tidak menimbulkan efek samping yang tidak

diharapkan.

Pengujian yang berhasil akan menghasilkan kesalahan, dan setiap kesalahan

harus dikoreksi.

Setiap kali perangkat lunak dikoreksi, maka banyak aspek konfigurasi perangkat

lunak (program, dokumentasi atau data yang mendukung) akan diubah.

Pengujian regresi (subset dari pengujian yang akan dieksekusi) berisi tiga kelas test

case yang berbeda, yaitu  :

Sampel respresentatif dari pengujian yang akan menggunakan semua fungsi

perangkat lunak.

Pengujian tambahan yang berfokus pada fungsi-fungsi perangkat lunak yang

mungkin dipengaruhi oleh perubahan tersebut.

Pengujian yang berfokus pada komponen perangkat lunak yang telah diubah.

Pemilihan strategi integrasi, tergantung pada karakteristik perangkat lunak dan

kadang-kadang juga pada jadwal proyek.

Secara umum, pendekatan yang digabungkan (sandwitch testing), yang

menggunakan strategi top-down untuk tingkat yang lebih tinggi dari struktur

program, dipasangkan dengan strategi bottom-up untuk tingkat subordinat.

Pada saat pengujian integrasi dilakukan, penguji  harus mengidentifikasi modul

kritis. Modul kritis memiliki karakteristik sebagai berikut :

1. menekankan beberapa persyaratan perangkat lunak.

2. memiliki tingkat kontrol yang tinggi.

3. Kompleks (cyclomatic complexity dapat digunakan sebagai indikator).

4. memiliki persyaratan kinerja yang terbatas.

Scope of Testing merangkum fungsi yang spesifik, kinerja dan karakteristik desain

internal yang akan diuji. Pengujian dibatasi ; kriteria perlengkapan dari masing-masing

fase pengujian digambarkan; dan batasan jadwal didokumentasikan.

Test Plan menggambarkan seluruh strategi integrasi. Pengujian dibagi ke dalam phases

dan builds yang menekankan fungsional spesifik dan karakteristik tingkah laku dari

perangkat lunak tersebut. Misalnya pengujian integrasi untuk sebuah sistem komputer

yang berorientasi pada grafik dapat dibagi ke dalam fase-fase pengujian sebagai

berikut  :

Interaksi pemakai (seleksi perintah, representasi tampilan, pemrosesan dan

respresentasi kesalahan).

Manipulasi dan analisis data (pembuatan simbol, penentuan dimensi, rotasi,

komputasi sifat fisis)

Pemrosesan dan pemunculan tampilan (tampilan dua dimensi, tampilan tiga

dimensi, grafik dan bagan)

Manajemen database (akses, update, integritas, kinerja)

Kriteria dan pengujian yang sesuai diaplikasikan untuk semua fase pengujian  :

Integritas interface. Antar muka internal dan eksternal diuji pada saat masing-

masing modul (kluster) ditambahkan ke dalam struktur.

Validitas fungsional. Pengujian yang didesain untuk mengungkap kesalahan

fungsional yang dilakukan.

Isi informasi. Pengujian yang didesain untuk mengungkap kesalahan yang

berhubungan dengan struktur data global atau lokal yang dilakukuan.

Kinerja. Pengujian yang didesain untuk memeriksa batasan kinerja yang

dibangun selama desain perangkat lunak dilakukan.

VALIDATION TESTING (pengujian validasi) Dilakukan setelah integration testing dilakukan serta kesalahan-kesalahan yang

ditemukan telah diperbaiki.

Validasi berhasil jika fungsi-fungsi yang ada pada perangkat lunak telah sesuai

dengan yang diharapkan oleh pemakai.

Merupakan kumpulan pengujian black-box yang memperlihatkan atau

menunjukkan sesuai dengan yang diperlukan.

Garis besar rencana pengujian dikerjakan dan prosedur pengujian didefinisikan

dengan test case yang spesifik untuk menunjukkan sesuai dengan yang

diperlukan.

Rencana dan prosedur dirancang untuk menjamin seluruh keperluan fungsional

telah terpenuhi, seluruh performansi dapat dicapai, dokumentasi dilakukan

dengan benar.

Setelah pengujian dikerjakan, ada satu kemungkinan dari dua kondisi yang ada, yaitu  :

1. Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima.

2. Penyimpangan dari spesifikasi ditemukan dan daftar penyimpangan dibuat.

Kajian Konfigurasi Merupakan elemen penting dari proses validasi.

Tujuannya untuk memastikan apakah semua elemen konfigurasi perangkat lunak

telah dikembangkan dengan tepat, dikatalog, dan memiliki detail yang perlu

untuk mendukung fase pemeliharaan dari siklus hidup perangkat lunak.

Sering disebut audit.

ALPHA & BETA TESTING Sangat tidak mungkin bagi pengembang perangkat lunak untuk meramalkan

bagaimana pelanggan akan benar-benar menggunakan sebuah program.

Instruksi yang digunakan dapat disalah-interprestasikan, kombinasi data yang

aneh dapat dipakai secara reguler, dan output yang kelihatannya sudah jelas

bagi penguji tidak dapat dimengerti oleh pemakai di lapangan.

Bila perangkat lunak biasa dibangun bagi satu pelanggan, maka dapat

acceptance test dapat dilakukan untuk memungkinkan pelanggan memvalidasi

semua persyaratan.

Acceptance test dilakukan karena memungkinkan pelanggan untuk menemukan

kesalahan yang lebih terinci dan membiasakan pelanggan memahami perangkat

lunak yang telah dibuat.

Jika perangkat lunak dikembangkan atau dibuat untuk dipakai oleh banyak

pelanggan, maka tidak praktis untuk melakukan pengujian satu per satu

terhadap perangkat lunak tersebut.

Maka digunakan alpha dan beta testing.

Alpha testing adalah tahap pengembangan, dimana perangkat lunak atau

perangkat keras yang telah dibuat dikirim ke kelompok pemakai atau pembeli

yang potensial kemudian mereka akan menggunakan produk ini untuk

melaporkan jika produk itu gagal ?

Pengujian aplha dilakukan pada sebuah lingkungan yang terkontrol.

Pengujian beta dilakukan oleh pelanggan yang merupakan pemakai akhir

perangkat lunak.

Pengujian beta merupakan sebuah aplikasi “live” dari perangkat lunak dalam

suatu lingkungan yang tidak dapat dikontrol oleh pengembang.

Pelanggan merekam semua masalah yang ditemui selama pengujian beta dan

melaporkannya kepada pengembang.

Pengembang melakukan modifikasi kemudian mempersiapkan pelepasan

produk ke seluruh pelanggan.

SYSTEM   TESTING Perangkat lunak merupakan salah satu elemen dari sistem yang berbasis

komputer yang sangat besar.

Perangkat lunak diintegrasi dengan elemen sistem lainnya (hardware, informasi)

dan serangkaian integrasi sistem dan validasi test dilakukan.

Jika pengujian gagal atau diluar scope dari pengembangan sistem dan tidak

hanya dikerjakan oleh programmer, maka langkah yang diambil selama

perancangan dan pengujian dapat diperbaiki

Peran analis sistem antara lain  :

o Menangani kesalahan yang muncul dari elemen-elemen perangkat lunak

o Mengerjakan serangkaian pengujian

o Mencatat hasil pengujian.

o Berpartisipasi dalam perencanaan dan merangcang pengujian sistem

untuk menjamin kualitas perangkat lunak.

o System testing adalah sederetan pengujian yang berbeda-beda dengan

tujuan utama mengerjakan keseluruhan elemen dalam sistem yang telah

dikembangkan.

Stress Testing ( pengujian stres ) Didesain untuk menghadapi situasi yang tidak normal pada saat program

mengalami pengujian.

Dilakukan oleh sistem untuk kondisi-kondisi seperti volume data yang normal

(melebihi atau kurang dari batasan), frekuensi dll.

Intinya penguji berusaha untuk merusak program.

Recovery Testing ( pengujian perbaikan ) Adalah pengujian sistem yang memaksa perangkat lunak untuk mengalami

kegagalan dalam berbagai cara dan melakukan verifikasi sesuai dengan

performansi yang tepat.

Banyak sistem yang berbasis komputer harus melindungi dari kesalahan dan

melanjutkan prosesnya dalam waktu yang telah ditentukan.

Sistem harus toleran terhadap kesalahan. Kesalahan pemrosesan tidak boleh

menyebabkan keseluruhan fungsi sistem berhenti.

Security Testing ( pengujian keamanan ) Adalah pengujian yang akan melakukan verifikasi dari mekanisme perlindungan

yang akan dibuat oleh sistem, melindungi dari hal-hal yang mungkin terjadi.

Penguji memerankan individu yang akan menembus sistem.

Pengujian untuk mencoba menembus tingkat keamanan sebuah perangkat

lunak.

Strategi Sandwich Compromise, menguji perangkat lunak dengan melakukan

pengujian mulai dari entry-point tertentu kemudian bergerak keatas ataupun

kebawah.

Volume Testing, menguji perangkat lunak dengan memberi data yang

berlebihan.

Configuration Testing, menguji berbagai variasi perangkat lunak diberbagai

lingkungan perangkat lunak.

Compatibility Testing, menguji kesesuaian sebuah perangkat lunak dengan

sistem yang sedang dimanfaatkan.

Timing sistem, melakukan pengujian terhadap perangkat lunak untuk evaluasi

terhadap waktu tanggap dan waktu proses Yng dibutuhkan untuk menyelesaikan

sebuah tugas.

Enviromental Testing, menguji toleransi perangkat lunak terhadap suhu,

kelembaban, gerak dan perpindahan.

Human Factor Testing, menguji antarmuka perangkat lunak bersama-sama

dengan pemakai.

Interface Testing ( pengujian interface ) Dilakukan ketika modul atau subsistem diintegrasi untuk membuat sistem yang

lebih besar.

Setiap modul atau subsistem memiliki interface yang terdifinisi yang dipanggil

oleh komponen program lain.

Tujuannya adalah untuk mendeteksi kesalahan yang mungkin telah masuk ke

dalam sistem karena eror interface atau asumsi invalid mengenai interface.

Penting untuk pengembangan berorientasi objek

OBJECT ORIENTED TESTING (pengujian berorientasi objek) Pengujian operasi individual yang berhubungan dengan objek. Merupakan fungsi

atau prosedur dan dapat digunakan pendekatan black-box dan white-box.

Pengujian kelas objek individu. Prinsip pengujian black-box tidak berubah tetapi

pengertian kelas ekuivalensi harus diperluas untuk mencakup rangkaian operasi

yang berhubungan. Dengan cara yang sama, pengujian struktural membutuhkan

jenis analisis yang berbeda.

Pengujian kelompok objek. Integrasi top-down dan bottom-up yang ketat tidak

sesuai untuk membuat kumpulan objek yang berhubungan. Pengujian berdasar

skenario yang digunakan.

Pengujian sistem berorientasi objek. Verifikasi dan validasi terhadap spesifikasi

persyaratan sistem dilakukan dengan cara yang tepat sama sebagaimana untuk

jenis sistem yang lain.

Object Integration (integrasi objek) Pengujian use-case atau basis skenario. Mendeskripsikan satu model

penggunaan sistem. Pengujian dapat didasarkan atas deskripsi skenario ini dan

kelompok objek yang dibuat untuk mendukung use-case yang berhubungan

dengan model penggunaan tersebut.

Pengujian thread. Berdasar pengujian respon sistem terhadap suatu input atau

set event input tertentu. Sistem berorientasi objek seringkali dikendalikan event

sehingga merupakan bentuk pengujian yang sesuai. Untuk memakai pendekatan

ini, kita harus mengidentifikasi cara pemrosesan event menelusuri jalannya

melalui sistem.

Pengujian interaksi objek.

o Diusulkan oleh Jorgensen dan Erikson.

o Tingkat menengah dari pengujian integrasi dapat didasarkan atas

identifikasi jalur.

o Jalur melalui serangkaian interaksi objek yang berhenti ketika operasi

objek tidak memanggil layanan objek lain.

Tiga hal yang harus dilakukan untuk menguji sistem OO  :

1. Definisi pengujian harus diperluas untuk mencakup teknik penemuan kesalahan

yang diaplikasikan ke model OOA dan OOD.

2. Strategi untuk pengujian unit dan terintegrasi harus berubah secara signifikan.

3. Desain test case harus bertanggung jawab terhadap karakteristik unik perangkat

lunak OO.

Model Pengujian OOA dan OOD Model desain dan analisis tidak dapat diuji dalam arti yang konvensional, karena

model tersebut tidak dapat dieksekusi.

Kajian teknis formal dapat digunakan untuk menguji kebenaran dan konsistensi

model analisis maupun model desain.

Kebenaran Model OOA dan OOD

Notasi dan sintaks digunakan untuk merespresentasikan model analisis dan

desain.

Kebenaran sintaks dinilai pada penggunaan simbol yang teratur.

Masinag-masig model dikaji untuk memastikan apakah konvensi pemodelan

yang tepat telah terjaga.

Konsistensi Model OOA dan OOD

mempertimbangkan hubungan antar entitas di dalam model tersebut.

masing-masing kelas dan koneksinya ke kelas lain harus diuji.

desain sistem dikaji dengan menguji model tingkah laku objek yang

dikembangkan selama OOA.

Metode Pengujian Berorientasi Objek Pengujian sistem berorientasi objek umumnya dilakukan secara bottom-up dalam

empat level  :

1. Pengujian level metode yang menguji metode individu di kelas.

2. Metode-metode dan atribut-atribut yang menyusun kelas. Pengujian level kelas

(intra kelas) adalah pengujian terhadap interaksi-interaksi di antara komponen-

komponen di satu kelas individu.

3. Kelas-kelas yang bekerja sama menyusun tandan kelas (class cluster).

Pengujian tandan kelas menguji interaksi-interaksi di antara kelas-kelas.

4. Tandan-tandan kelas menyusun sistem. Pengujian level sistem berurusan

dengan masukan dan keluaran yang tampak bagi pemakai sistem.

Stratregi pengujian berorientasi objek Strategi klasik pengujian perangkat lunak  :

Dimulai dari pengujian unit, bergerak menuju pengujian integrasi dan berakhir

pada validasi dan pengujian sistem.

Pengujian unit berfokus pada satuan program kecil yang dapat di-compile.

Unit diintegrasikan dengan suatu struktur program.

Pengujian regresi dijalankan untuk mengungkap kesalahan sehubungan dengan

interfacing modul dan efek samping yang disebabkan oleh penambahan unit-unit

baru.

Sistem secara keseluruhan diuji untuk memastikan apakah kesalahan terungkap.

Sumber :http://giyantoaudi.wordpress.com/motivasi/