strategi testing system

STIKOM - Romeo, S.T. © 2006

Strategi Testing (Unit Testing)

Testing & Implementasi Sistem (2 sks)


Strategi Testing

• Strategi testing software mengintegrasikan metode-metode disain test cases software ke dalam suatu rangkaian tahapan yang terencana dengan baik sehingga pengembangan software dapat berhasil.

• Strategi menyediakan peta yang menjelaskan tahap-tahap yang harus dilakukan sebagai bagian dari testing, dan membutuhkan usaha, waktu, dan sumber daya bilamana tahap-tahap ini direncanakan dan dilaksanakan.

• Strategi testing harus menjadi satu kesatuan dengan perencanaan tes, disain test case, ekesekusi tes, dan pengumpulan serta evaluasi data hasil testing.

• Strategi testing software harus cukup fleksibel untuk dapat mengakomodasi kustomisasi pendekatan testing. Pada saat yang bersamaan, harus juga cukup konsisten dan tegas agar dapat melakukan perencanaan yang masuk akal dan dapat melakukan manajemen perkembangan kinerja proyek.


Pendekatan Strategi Testing

• Sejumlah strategi testing software diadakan untuk menyediakan kerangka testing bagi pengembang software dengan karekteristik umum sebagai berikut:– Testing dimulai dari tingkat komponen terkecil sampai

pada integrasi antar komponen pada keseluruhan sistem komputer tercapai.

– Teknik testing berbeda-beda sesuai dengan waktu penggunaannya.

– Testing dilakukan oleh pengembang software dan (untuk proyek besar) dilakukan oleh suatu grup tes yang independen.

– Testing dan debugging adalah aktifitas yang berlainan, tapi debugging harus diakomodasi disetiap strategi testing.


Verifikasi & Validasi

• Testing software sering dikaitkan dengan verifikasi dan validasi (V & V). Dimana verifikasi merupakan sekumpulan aktifitas yang memastikan software telah melakukan fungsi tertentu dengan benar. Sedangkan validasi merupakan sekumpulan aktifitas berbeda dari verifikasi yang memastikan bahwa software yang dibangun dapat dilacak terhadap kebutuhan / permintaan pelanggan.

• Menurut Boehm [BOE81]:– Verifikasi “Are we building the product right?”– Validasi “Are we building the right product?”

• V&V meliputi kebanyakan aktifitas SQA, yaitu: formal technical review, audit konfigurasi dan kualitas, pemonitoran kinerja, simulasi, studi fisibilitas, review dokumentasi, review database, analisa algoritma, testing pengembangan, testing kualifikasi, dan testing instalasi [WAL89]. Walaupun testing memainkan peran yang sangat penting dalam V & V, namun masih diperlukan aktifitas-aktifitas yang lainnya.


• Testing merupakan basis terakhir dimana kualitas dapat dinilai dan error dapat diidentifikasi.

• Tapi testing tidak boleh dipandang sebagai jaring pengamanan.

• “Anda tidak dapat melakukan tes terhadap kualitas. Jika kualitas tidak ada sebelum Anda memulai testing, maka kualitas juga tidak akan ada saat Anda selesai melakukan testing.”

• Kualitas dibangun ke dalam software sepanjang proses rekayasa software.

• Penerapan dari metode-metode dan alat-alat bantu, formal technical review yang efektif, menejemen dan pengukuran yang solid mengarahkan pada kualitas yang dikonfirmasikan pada saat pelaksanaan testing berlangsung.

• Miller [MIL77] menghubungkan testing software terhadap jaminan kualitas dengan menyatakan bahwa “ motivasi yang patut digaris bawahi dari testing adalah untuk memberikan dukungan kualitas software dengan metode-metode yang dapat diaplikasikan secara ekonomis dan efektif baik pada sistem berskala besar atau sistem berskala kecil.”


Pengorganisasian testing software

• Mengurangi resiko terjadinya konflik, dan mempersiapkan diri bilamana konflik tetap terjadi.

• Ada sejumlah konsepsi salah, yang akan mempengaruhi diskusi sebelumnya menjadi salah jalan, yaitu:– Pengembang software tidak perlu melakukan testing

sama sekali.– Software diberikan pada orang lain (tak dikenal

kredibilitasnya), yang akan melakukan tes pada software tersebut tanpa pemahaman dan salah arah.

– Tester baru bekerja atau ikut serta ke dalam proyek, hanya bilamana tahap testing pada proyek tersebut dimulai.


Strategi Testing


Tahapan Testing


Kriteria pemenuhan testing

• “Kapan kita dapat menyelesaikan testing – bagaimana kita dapat mengetahui apa yang dites telah cukup?”

• Musa dan Ackerman [MUS89] mengembangkan suatu model berdasarkan pada pemodelan statistik dan teori reliabilitas. Model ini disebut sebagai logarithmic Poisson execution-time model, dengan bentuk:f(t) = (1 / p) ln (l0 p t + 1)dimana f(t) = Jumlah error kumulatif yang diharapkan terjadi saat software di tes untuk suatu waktu eksekusi, t.l0 = Inisial dari intensitas error dari software (error per unit waktu) saat awal testing.P = Pengurangan secara eksponensial intesitas error saat error telah diperbaiki.Intensitas error, l(t) dapat diturunkan dengan menurunkan derivasi dari f(t): l(t) = l0 / (l0 p t + 1)

• Dengan manggunakan persamaan l(t) di atas, tester dapat memprediksi turunnya errors dari hasil kinerja proses testing.


Isu-Isu Strategi Testing

• Betapapun bagusnya strategi testing akan gagal jika serangkaian isu-isu strategi testing berikut ini tidak dipertimbangkan dengan baik.

• Tom Gilb [GIL95] memberikan argumentasinya terhadap isu-isu tersebut, agar strategi testing software dapat diimplementasikan dengan sukses.


• Spesifikasi kebutuhan produk agar dapat dikuantisasi, harus ditetapkan jauh sebelum testing dimulai. Walau obyektifitas testing adalah untuk menemukan errors, suatu strategi yang bagus juga menilai karakteristik kualitas, seperti portabilitas, maintainabilitas, dan usabilitas. Dimana hal ini seharusnya dispesifikasikan dengan suatu cara tertentu yang dapat diukur, sehingga hasil testing tidak membingungkan.

• Nyatakan obyektifitas testing secara eksplisit. Obyektifitas testing tertentu harus dinyatakan dalam bentuk yang dapat diukur. Contoh, efektifitas tes, cakupan tes, waktu error rata-rata, biaya untuk menemukan dan memperbaiki error, frekuensi terjadinya error, dan jam kerja tes per tes regresi, yang kesemuanya harus dinyatakan di dalam rencana tes [GIL95].


• Memahami pengguna software dan mengembangkan profil untuk tiap kategori pengguna. Use-cases yang menjelaskan skenario interaksi untuk tiap kelas pengguna dapat mengurangi usaha testing keseluruhan dengan fokus pada penggunaan aktual dari produk.

• Mengembangkan rencana testing yang berdasar pada “rapid cycle testing”. Gilb [GIL95] merekomendasikan tim perekayasa software untuk belajar melakukan tes pada siklus yang ketat (2 persen dari usaha proyek) dari penggunaan pelanggan. Umpan balik yang dihasilkan dapat digunakan untuk mengendalikan tingkat kualitas dan strategi tes yang bersangkutan.


• Membuat software yang tegar (robust), yang didisain untuk melakukan tes dirinya sendiri. Software seharusnya didisain dengan menggunakan teknik antibugging. Sehingga software dapat mendiagnosa klas-klas error tertentu. Sebagai tambahan, disain seharusnya mengakomodasi otomatisasi testing dan regression testing.

• Gunakan Formal Technical Review (FTR) yang efektif sebagai filter testing tertentu. FTR dapat seefektif testing dalam mencakup error. Dengan alasan ini, review dapat mengurangi sejumlah usaha testing, yang dibutuhkan untuk menghasilkan software berkualitas tinggi.


• Lakukan Formal Technical Review untuk menilai strategi tes dan test cases itu sendiri. FTR dapat mencakup ketidakkonsistenan, penyimpangan dan error dari pendekatan testing. Hal ini akan menghemat waktu dan mengembangkan kualitas produk.

• Kembangkan pendekatan pengembangan yang berkelanjutan untuk proses testing. Strategi tes harus diukur. Pengukuran yang dikumpulkan selama testing harus digunakan sebagai bagian dari pendekatan kendali proses secara statistik untuk testing software.


Unit Testing

• Unit testing berfokus pad usaha verifikasi pada unit terkecil dari disain software – komponen atau modul software.

• Penggunaan diskripsi disain tingkat komponen sebagai tuntunan, jalur kendali yang penting dites untuk menemukan errors, terbatas pada modul tersebut.

• Kompleksitas relatif terhadap tes dan errors yang dicakup dibatasi oleh batasan-batasan dari cakupan yang telah ditetapkan pada unit testing.

• Unit testing berorientasi white box, dan tahapan dapat dilakukan secara paralel pada banyak komponen.


Hal-hal yang perlu diperhatikan pada unit testing

• Tes yang terdapat pada unit testing:– Modul antar muka dites untuk memastikan aliran

informasi telah berjalan seperti yang diharapkan (masuk dan keluar dari unit program yang dites).

– Struktur data lokal diperiksa untuk memastikan penyimpanan data telah merawat integritasnya secara temporal selama tahap eksekusi algoritma.

– Batasan kondisi dites untuk memastikan modul beroperasi dengan benar pada batasan yang telah ditetapkan untuk limitasi atau batasan pemrosesan.

– Semua jalur independen (basis paths) pada struktur kendali diperiksa untuk memastikan semua pernyataan dalam modul telah dieksekusi minimal sekali.

– Semua jalur penanganan kesalahan dites.


• Tes aliran data antar modul dibutuhkan sebelum inisialisasi tes lainnya. Jika data tidak masuk dan keluar dengan benar, semua tes lainnya disangsikan. Sebagai tambahan, struktur data lokal harus diperiksa dan akibat pada data global ditentukan (jika memungkinkan) selama unit testing.

• Pemilihan jalur eksekusi testing adalah tugas yang esensial selama unit test. Test cases harus didisain untuk mencakup kesalahan dari komputasi yang salah, komparasi yang tak benar atau alur kendali yang tak tepat. Basis path dan loop testing adalah teknik yang efektif untuk hal ini.


• Kesalahan komputasi yang umum terjadi:– Kesalahan prioritas aritmetik.– Mode operasi campuran.– Inisialisasi tak benar.– Ketidakakuratan presisi.– Ketidakbenaran representasi simbolik

dari ekspresi.

• Komparasi dan alur kendali merupakan satu kesatuan. Biasanya perubahan alur kendali terjadi setelah komparasi.


• Test case harus mencakup kesalahan:– Komparasi tipe data berbeda– Operator logika dan prioritas yang tak benar– Kemungkinan persamaan jika kesalahan

presisi, menjadikan hasil dari persamaan tidak sebagaimana yang diharapkan.

– Kesalahan komparasi antar variabel.– Terminasi loop yang tidak konsisten atau

tidak semestinya.– Kegagalan keluar bilamana konflik iterasi

terjadi.– Modifikasi variabel loop yang tidak

semestinya.


• Disain yang baik meliputi kondisi kesalahan yang diantisipasi dan jalur penanganan kesalahan diset untuk dapat digunakan kembali atau proses pembersihan pada terminasi saat kesalahan terjadi. Pendekatan ini disebut sebagai antibugging oleh Yourdon [YOU75].

• Kesalahan potensial yang harus dites saat evaluasi penanganan kesalahan:– Diskripsi kesalahan tidak jelas.– Catatan kesalahan tidak berfungsi untuk menghitung

kesalahan.– Kondisi kesalahan menyebabkan interfensi sistem terhadap

penangan kesalahan tertentu.– Pemrosesan kondisi perkecualian tidak benar.– Diskripsi kesalahan tidak menyediakan informasi yang cukup

untuk mengarahkan penyebab kesalahan.• Batasan testing adalah tugas terakhir dari unit testing.

Software kadang gagal terhadap batasannya. Kesalahan kadang terjadi ketika elemen ke n dari dimensi array ke n diproses, ketika repetisi ke i dari loop dilakukan, ketika nilai maksimum dan minimum dihitung.


Prosedur-prosedur unit test

• 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 menggantikan modul-modul yang merupakan subordinat (dipanggil oleh) komponen yang dites. Stub atau “dummy subprogram” menggunakan antar muka modul subordinat, mungkin melakukan manipulasi data minimal, mencetak masukan verifikasi, dan mengembalikan kendali ke modul yang sedang dites.


• Drivers dan stubs menimbulkan biaya overhead. Karena software harus ada penambahan kode (biasanya tidak berdasarkan disain formal), yang tidak diikutsertakan saat produk software dirilis.

• Bila drivers dan stubs cukup sederhana, overhead yang sebenarnya menjadi relatif rendah.

• Namun pada kenyataannya, kebanyakan komponen tidaklah cukup bila hanya dilakukan tes dengan overhead yang rendah (sederhana).

• Pada kasus-kasus tertentu, testing dapat ditunda penyelesaiannya (kondisi komplit) sampai tahap integration test (dimana 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.

• Untuk itu perlu melakukan pemilihan modul-modul yang kritis dan yang mempunyai cyclomatic complexity tinggi, untuk unit testing.


Terimakasih

strategi testing system

Education