Transcript Pertemuan 7 pada materi testing

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 Testing
Validation Testing
Integration Testing
Unit Testing
Code
Design
Requirements
System Engineering
Tahapan Testing
Requirements
Higt-Order
Test
Integration
Test
Design
Code
Testing
“Direction”
Unit
Test
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.