View
62
Download
2
Category
Preview:
DESCRIPTION
Strategi Testing Rika Harman, S.Kom.,M.S.I. Strategi Testing Secara Umum. Strategi testing software mengintegrasikan metodemetode disain test cases software ke dalam suatu rangkaian tahapan yang terencana dengan baik sehingga pengembangan software dapat berhasil. - PowerPoint PPT Presentation
Citation preview
Strategi Testing
Rika Harman, S.Kom.,M.S.I
Strategi Testing Secara Umum
• Strategi testing software mengintegrasikan metodemetode 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
1. Sejumlah strategi testing software diadakan untuk menyediakan kerangka
testing bagi pengembang software dengan karekteristik umum sebagai
berikut:
a. Testing dimulai dari tingkat komponen terkecil sampai pada integrasi
antar komponen pada keseluruhan sistem komputer tercapai.
b. Teknik testing berbeda-beda sesuai dengan waktu penggunaannya.
c. Testing dilakukan oleh pengembang software dan (untuk proyek
besar) dilakukan oleh suatu grup tes yang independen.
d. Testing dan debugging adalah aktifitas yang berlainan, tapi
debugging harus diakomodasi disetiap strategi testing.
Verifikasi & Validasi
1. 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.
2. Menurut Boehm [BOE81]:
a. Verifikasi “Are we building the product right?”
“Apakah sistem yang dikembangkan sudah benar = melakukan pengujian
terhadap sistem apakah sudah sesuai dengan yang diharapkan”
b. Validasi “Are we building the right product?”
c. Apakah sistem dikembangkan dengan cara yang
benar=melakukan pengujian apakah sistem sudah sesuai dengan
spesifikasinya
3. 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
aktifitasaktifitas yang lainnya.
a. Testing merupakan basis terakhir dimana kualitas dapat dinilai dan error
dapat diidentifikasi.
b. Tapi testing tidak boleh dipandang sebagai jaring pengamanan.
c. “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.”
d. Kualitas dibangun ke dalam software sepanjang proses rekayasa software.
e. 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.
f. 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
1. Mengurangi resiko terjadinya konflik, dan mempersiapkan diri bilamana
konflik tetap terjadi.
2. Ada sejumlah konsepsi salah, yang akan mempengaruhi diskusi
sebelumnya menjadi salah jalan, yaitu:
a. Pengembang software tidak perlu melakukan testing sama sekali.
b. Software diberikan pada orang lain (tak dikenal kredibilitasnya), yang
akan melakukan tes pada software tersebut tanpa pemahaman dan
salah arah.
c. Tester baru bekerja atau ikut serta ke dalam proyek, hanya bilamana
tahap testing pada proyek tersebut dimulai.
Strategi Testing
System TestingValidation TestingIntegration Testing
Unit Testing
Code
DesignRequirements
System Engineering
Tahapan Testing
UnitTest
IntegrationTest
Higt-OrderTest
Testing“Direction”
Code
Design
Requirements
Kriteria pemenuhan testing
“Kapan kita dapat menyelesaikan testing – bagaimana kita
dapat mengetahui apa yang dites telah cukup?”
Isu-Isu Strategi Testing
a. Betapapun bagusnya strategi testing akan gagal jika serangkaian isu-isu
strategi testing berikut ini tidak dipertimbangkan dengan baik.
b. Tom Gilb [GIL95] memberikan argumentasinya terhadap isu-isu tersebut,
agar strategi testing software dapat diimplementasikan dengan sukses.
a. 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
usabilitas. ini seharusnya dispesifikasikan dengan suatu cara tertentu yang
dapat diukur, sehingga hasil testing tidak membingungkan.
b. 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 danmengembangkan 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 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
a. Unit testing berfokus pad usaha verifikasi pada unit terkecil dari disain
software – komponen atau modul software.
b. Penggunaan diskripsi disain tingkat komponen sebagai tuntunan, jalur
kendali yang penting dites untuk menemukan errors, terbatas pada modul
tersebut.
c. Kompleksitas relatif terhadap tes dan errors yang dicakup dibatasi oleh
batasan-batasan dari cakupan yang telah ditetapkan pada unit testing.
d. Unit testing berorientasi white box, dan tahapan dapat dilakukan secara
paralel pada banyak komponen.
Hal-hal yang perlu diperhatikan pada unit testing
1. Tes yang terdapat pada unit testing:
a. Modul antar muka dites untuk memastikan aliran informasi telah berjalan
seperti yang diharapkan (masuk dan keluar dari unit program yang dites).
b. Struktur data lokal diperiksa untuk memastikan penyimpanan data telah
merawat integritasnya secara temporal selama tahap eksekusi algoritma.
c. Batasan kondisi dites untuk memastikan modul beroperasi dengan benar
pada batasan yang telah ditetapkan untuk limitasi atau batasan pemrosesan.
d. Semua jalur independen (basis paths) pada struktur kendali diperiksa untuk
memastikan semua pernyataan dalam modul telah dieksekusi minimal sekali.
e. Semua jalur penanganan kesalahan dites.
f. 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.
g. 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.
1. Test case harus mencakup kesalahan:
a. Komparasi tipe data berbeda
b. Operator logika dan prioritas yang tak benar
c. Kemungkinan persamaan jika kesalahan presisi menjadikan presisi,
hasil dari persamaan tidak sebagaimana yang diharapkan.
d. Kesalahan komparasi antar variabel.
e. Terminasi loop yang tidak konsisten atau tidak semestinya.
f. Kegagalan keluar bilamana konflik iterasi terjadi.
g. Modifikasi variabel loop yang tidak semestinya.
2. 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].
3. Kesalahan potensial yang harus dites saat evaluasi penanganan kesalahan:
a. Diskripsi kesalahan tidak jelas.
b. Catatan kesalahan tidak berfungsi untuk menghitung kesalahan.
c. Kondisi kesalahan menyebabkan interfensi sistem terhadap penangan kesalahan
tertentu.
d. Pemrosesan kondisi perkecualian tidak benar.
e. Diskripsi kesalahan tidak menyediakan informasi yang cukup untuk mengarahkan
penyebab kesalahan.
4. Batasan testing adalah tugas terakhir dari unit testing. Softwarekadang
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
a. Setelah kode dikembangkan, dan diverifikasi terhadap p tingkat disain
komponen bersangkutan, disain test case dari unit test dimulai
b. Review informasi disain menyediakan tuntunan untuk menetapkan test
cases agar dapat mendekati keseluruhan cakupan kesalahan di tiap
kategori sebagaimana didiskusikan sebelumnya.
c. 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.
a. 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.
b. Stubs berlaku untuk menggantikan modul-modul yangmerupakan
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.
Recommended