2 Isu-Isu Strategi Testing
4.3 Unit Testing
4.3.2 Prosedur-prosedur unit test
Unit testing seca p
ra umum dipandang sebagai proses kelanjutan dari tahapan coding, dengan rosedur sebagai berikut:
Setelah kode dikembangkan, dan diverifikasi terhadap tingkat disain komponen bersangkutan, disain test case dari unit test dimulai.
Review informasi disain menyediakan tuntunan untuk menetapkan test cases agar dapat mendekati keseluruhan cakupan kesalahan di tiap kategori sebagaimana didiskusikan sebelumnya.
Tiap test case harus dihubungkan dengan hasil yang diharapkan.
Karena komponen bukan program yang berdiri sendiri, drivers dan atau stubs software harus dikembangkan untuk tiap unit test.
Pada kebanyakan aplikasi drivers tidak lebih dari “program utama” yang menerima data test case, memasukkan data ke komponen yang dites, dan mencetak hasil yang bersangkutan.
Stubs berlaku untuk pakan subordinat
(dipanggil oleh) kompone subprogram” menggunakan
bordinat, mungkin melakukan manipulasi data minimal,
kod sarkan disain formal), yang tidak diikutsertakan saat produk
t a, overhead yang sebenarnya menjadi
ntu, testing n test (dimana
tuk itu perlu melakukan pemilihan modul-modul yang kritis dan yang menggantikan modul-modul yang meru
n yang dites. Stub atau “dummy antar muka modul su
mencetak masukan verifikasi, dan mengembalikan kendali ke modul yang sedang dites.
Drivers dan stubs menimbulkan biaya overhead. Karena software harus ada penambahan e (biasanya tidak berda
sof ware dirilis. Bila drivers dan stubs cukup sederhan
relatif rendah. Namun pada kenyataannya, kebanyakan komponen tidaklah cukup bila hanya dilakukan tes dengan overhead yang rendah (sederhana). Pada kasus-kasus terte
dapat ditunda penyelesaiannya (kondisi komplit) sampai tahap integratio drivers atau stubs juga digunakan).
Unit testing disederhanakan bila suatu komponen didisain dengan kohesi tinggi. Bilamana hanya satu fungsi yang dialamatkan oleh suatu komponen, jumlah test cases dapat dikurangi dan errors dapat lebih mudah untuk diprediksi dan dicakup.
Ada beberapa situasi dimana sumber daya tidak mencukupi untuk melakukan unit testing secara komplit. Un
mempunyai cyclomatic complexity tinggi, untuk unit testing.
Bab IV Strategi Testing Halaman 100
4.4 Integration Testing
Bila mun indi
seb u kesatuan?” Permasalahan tentunya terdapat pada antar-muka. Data akan dapat
kes
dap lahan hasil perhitungan yang tidak dapat diterima (di luar
mun ari antar-muka penggabungan antar modul ini akan terus bertambah banyak modul-modul yang akan diintegrasikan ke dalam suatu
mponen- sting dan membangun suatu struktur program sesuai
Ter an integrasi yang tidak secara bertahap, yaitu
tan ini menggabungkan nen secara bersamaan hingga terbentuk suatu program. Testing
g
tegrasi yang dilakukan secara bertahap merupakan lawan dari penggunaan strategi “Big ang”. Program dikonstruksi dan dites dalam secara bertahap, meningkat sedikit demi edikit, dimana bila terjadi errors dapat dengan mudah untuk diisolasi dan diperbaiki, antar-
uka dapat dites secara komplit atau paling tidak mendekati komplit, serta pendekatan tes ang sistematis dapat digunakan.
integration
tiap modul di dalam suatu software secara keseluruhan telah lolos dari unit testing, akan cul pertanyaan: “Jika semua modul-modul software telah bekerja dengan baik secara vidual, mengapa harus ada keraguan apakah modul-modul tersebut dapat bekerja sama agai sat
hilang pada suatu antar-muka, suatu modul mungkin masih terdapat penyimpangan atau alahan yang mempengaruhi modul yang lainnya, kurangnya kepresisian mungkin akan
at mempertinggi tingkat kesa
batas toleransi), demikian seterusnya, daftar-daftar kemungkinan permasalahan yang gkin terjadi d
seiring dengan makin banyaknya software.
Integration testing adalah suatu teknik yang sistematis untuk pembangunan struktur program, dimana pada saat yang bersamaan melakukan testing untuk mendapatkan errors yang diasosiasikan dengan antar-muka. Obyektifitasnya adalah untuk menindaklanjuti ko
komponen yang telah melalui unit te
dengan disain yang telah dituliskan sebelumnya. dapat kecenderungan untuk melakuk
dengan menggunakan suatu pendekatan “Big Bang”. Pendeka koomponen-kompo
dilakukan pada keseluruhan program secara bersamaan. Dan kekacauan adalah hasil yan biasa didapatkan. Sekumpulan errors akan diperoleh, dan perbaikan sulit dilakukan, karena terjadi komplikasi saat melakukan isolasi terhadap penyebab masalah. Ditambah lagi dengan munculnya errors baru saat errors sebelumnya dibenahi, sehingga menciptakan suatu siklus yang tak ada hentinya.
In B s m y
4.4.1 Top-down
Adalah pendekatan bertahap untuk menyusun struktur program. Modul-modul diintegrasikan ari atas ke bawah dalam suatu hirarki kendali, dimulai dari modul kendali utama (program tama). Modul sub-ordinat dari modul kendali utama dihubungkan ke struktur yang paling alam (depth-first integration) atau yang paling luas (breadth-first integration) dahulu.
erdasarkan pada gambar 4.4, depth-first integration, akan mengintegrasikan semua omponen-komponen pada struktur jalur kendali mayor. Misal dipilih sisi kiri terlebih dahulu, d u d B k
By Hendranet
Bab IV Strategi Testing Halaman 101 maka komponen M1, M2, M5 akan diintegrasikan dahulu, baru kemudian M8 atau M6 akan diintegrasikan
Breadth-first integration, akan mengintegrasikan semua komponen secara langsung ke tiap tingkat, bergerak secara horisontal. Contoh komponen M2, M3 dan M4 akan diintegrasikan
n seterusnya.
a pendekatan integrasi yang dipilih, stubs sub-ordinat digantikan dengan
5. si dilakukan untuk memastikan kesalahan baru tidak terjadi lagi. ram dilalui.
u fungsi komplit dari software akan diimplementasikan dan
komplek, namun pada kenyataannya, masalah logistik akan
yang mengalir ke atas dari struktur program. dahulu, kemudian baru M5 dan M6 da
Gambar 4.4 Top-down integration.
Lima langkah proses integrasi:
1. Modul kendali utama digunakan sebagai driver tes dan stubs tes disubtitusikan bagi semua komponen yang secara langsung menjadi sub-ordinat modul kendali utama. 2. Tergantung pad
komponen sebenarnya.
3. Tes dilakukan saat tiap komponen diintegrasikan.
4. Saat pemenuhan tiap tes, stubs lainnya digantikan dengan komponen sebenarnya. Testing regre
Proses berlanjut dari langkah 2 sampai keseluruhan struktur prog
Strategi top-down integration melakukan verifikasi kendali mayor atau titik-titik keputusan di awal proses testing. Pada suatu struktur program yang difaktorkan dengan baik, pengambilan keputusan terjadi di tingkat atas dalam hirarki dan oleh sebab itu diperhitungkan terlebih dahulu. Jika kendali mayor bermasalah, dibutuhkan pengenalan awal. Jika depth-first integration dipilih, suat
didemonstrasikan.
Pendekatan ini terlihat tidak
timbul, karena proses level bawah dari hirarki dibutuhkan untuk tes level di atasnya. Stubs menggantikan modul level bawah saat dimulainya top-down testing; karenanya tidak ada data
Bab IV Strategi Testing Halaman 102 Tester hanya mempunyai 3 pilihan:
Tunda kebanyakan tes sampai stubs digantikan dengan modul sebenarnya, hal ini rtentu dan
bawah ke atas dalam hirarki, disebut sebagai bottom-up
4.4.2 Bottom-up
menyebabkan hilangnya beberapa kendali yang berhubungan antar tes te
modul tertentu. Tentunya akan menyulitkan untuk menentukan penyebab errors dan kecenderungan terjadi pelanggaran terhadap batasan-batasan dari pendekatan top- down.
Kembangkan stubs yang mempunyai fungsi terbatas untuk mensimulasikan modul sebenarnya, mungkin dapat dilakukan, namun akan menambah biaya overhead dengan semakin kompleknya stubs.
Integrasikan software dari integration.
testing
Sesuai namanya, integrasi ini dimulai dari modul terkecil. Karena komponen-komponen diintegrasikan dari bawah ke atas, sub-ordinat untuk tingkat bersangkutan dari komponen selalu diperlukan untuk diproses, dan kebutuhan terhadap stubs dapat dihilangkan.
dinasi masukan dan keluaran test case.
nakan
dan
Langkah-langkah strategi ini adalah:
1.
Komponen level bawah dikombinasikan dalam clusters (kadang disebut builds) yang mewakili sub-fungsi software tertentu.2. Driver ditulis untuk koor 3. Cluster dites.
4. Driver dihapus dan cluster dikombinasikan, bergerak ke atas di dalam struktur program. Integrasi mengikuti pola sebagaimana diilustrasikan pada gambar 4.5. Komponen dikombinasi untuk membentuk cluster 1, 2 dan 3. Tiap cluster dites dengan menggu
driver. Komponen pada cluster 1 dan 2 adalah sub ordinat Ma. Driver D1 dan D2 dihilangkan cluster dihubungkan langsung ke Ma, demikian seterusnya.
Bab IV Strategi Testing Halaman 103 Saat integrasi semakin bergerak ke atas, kebutuhan akan test drivers yang terpisah juga akan semakin sedikit. Pada kenyataannya, jika dua level atas dari struktur program diintegrasikan dari atas ke bawah, jumlah drivers akan banyak dikurangi, dan integrasi dari clusters akan sangat disederhanakan.