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/