Pendahuluan
Istilah pemeliharaan perangkat lunak digunakan untuk menjabarkan aktivitas dari analis sistem (software engineering) yang terjadi pada saat hasil produk perangkat lunak sudah dipergunakan oleh pemakai (user).
Biasanya pengembangan produk perangkat lunak memerlukan waktu antara 1 sampai dengan 2 tahun, tetapi pada pase pemeliharaan perangkat lunak menghabiskan 5 sampai dengan 10 tahun
Aktivitas yang terjadi pada pase pemeliharaan antara lain:
Penambahan atau peningkatan atau juga perbaikan untuk produk perangkat lunak
Adaptasi produk dengan lingkungan mesin yang baru
Pembetulan permasalahan yang timbul
Aktivitas pada penambahan atau perbaikan produk perangkat lunak :
Penambahan fungsi-fungsi baru
Perbaikan tampilan dan modus interaktif
Perbaharui dokumen ekstemal
Perbaharui dokumentasi internal
Perbaharui karakteristik perfomansi dari system
Adaptasi terhadap lingkungan yang baru mencakup aktivitas:
Pemindahan perangkat lunak ke mesin yang berlainan
Modifikasi untuk dapat mempergunakan protokol atau disk drive tambahan
Sedangkan pada pembetulan mencakup aktivitas:
Pembenaran kesalahan yang timbul setelah produk perangkat lunak dipergunakan oleh user (pemakai)
Aktivitas pemeliharaan
Pemeliharaan PL menghabiskan biaya terbesar dari seluruh anggaran pengembangan atau pembuatan perangkat lunak.
Pemeliharaan menghabiskan 70% dari seluruh biaya pengembangan perangkat lunak.
Pase pemeliharaan sekitar 60% digunakan untuk anggaran penambahan atau perhaikan perangkat lunak, sisanya untuk adaptasi atau pembetulan.
Atribut utama dari perangkat lunak yang mudah dalam pemeliharaan
Perangkat lunak dikerjakan per modul
Perangkat lunak mempunyai kejelasan
Dokumentasi internal yang baik dan jelas
Dokumen-dokumen pendukung lainnya
Pemeliharaan perangkat lunak dapat dibedakan menjadi:
Corrective Maintenance
Corrective maintenance terjadi pada saat produk dipakai dan hasil yang didapat oleh pamakai baik berupa kesalahan yang timbul maupun kesalahan dalam bentuk keluaran yang tidak sesuai.
Adaptive maintenance
Aktivitas yang kedua ini terjadi karena pertumbuhan atau perkembangan perangkat lunak atau perangkat keras sehingga memerlukan modifikasi dari perangkat lunak yang telah dibuat.
Perfective maintenance
Aktivitas ini terjadi pada saat perangkat lunak yang telah dibuat dan dilakukan uji cobs kemudian dipergunakan oleh user. Setelah dipergunakan oleh user mungkin timbul permintaan tambahan fungsi sesuai dengan keinginan pemakai.
Preventive maintenance
Pemeliharaan yang terakhir dilakukan untuk menghadapi kemajuan perangkat lunak atau perangkat keras di masa mendatang, umpamanya penambahan fungsifungsi atau melengkapi fungsi-fungsi yang telah ada.
Karakteristik Pemeliharaan
Pemeliharaan terstruktur dan tidak terstruktur
Biaya pemeliharaan
Aliran tindakan permintaan pemeliharaan
1.a. Pemeliharaan terstruktur
Pada gambar di atas terlihat pemeliharaan terstruktur dimulai dari permintaan akan pemeliharaan dan menentukan konfigurasi dari perangkat lunak yang akan diadakan pemeliharaan. Jika merupakan seluruh perangkat lunak maka tindakan yang diambil adalah evaluasi perancangan dan menentukan rencana pendekatan yang akan digunakan untuk melakukan pemeliharaan. Kemudian dilanjutkan dengan melakukan modifikasi+perancangan dan penulisan ulang program (rekode). Langkah terakhir adalah me-review program yang telah ditulis. Jika diterima maka berarti tugas pemeliharaan telah selesai. Sedangkan jika konfigurasi merupakan program per modul maka kegiatan yang dilakukan adalah evaluasi program. Jika diperlukan modifikasi yang cukup besar maka tindakan yang diambil adalah pembuatan ulang yang dilanjutkan dengan review hasil. Jika hasil akhir memenuhi kriteria maka berarti perangkat lunak siap.
1.b. Pemeliharaan tidak terstruktur
Tidak mempunyai dokumentasi yang baik
Tidak menggunakan metodologi perancangan
Tidak mengikuti langkah-langkah di atas
2. Biaya pemeliharaan
Biaya pemeliharaan perangkat lunak yang dikeluarkan dalam pase pemeliharaan meningkat dengan cepat, hal ini dapat dilihat pada gambar herikut:
Selain biaya yang umum dalam pase pengembangan Bering timbul biaya-biaya tak berwujud (intangible cost). Biaya-biaya ini ditimbulkan karena:
Ketidakpuasan pemakai (user) akibat tidak selesainya perangkat lunak sesuai dengan waktu yang telah ditentukan pada pase pemeliharaan
Pengurangan kualitas perangkat lunak
Penambahan tenaga kerja baru
Maintainability
Maintainability dapat didefinisikan kemudahan dalam mengerti perangkat lunak, pcmbenaran, adaptasi dan atau perbaikan. Faktor-faktor yang mempengaruhi maintanability:
Control
Ukuran kuantitatif
1. Kontrol
Pokok-pokok maintainability dari perangkat lunak dipengaruhi oleh perancangan, pengkodean dan uji coba yang jelas mempunyai pengaruh jelek pada kemampuan pemeliharaan dari perangkat lunak yang dihasilkan, begitu juga konfigurasi perangkat lunak yang jelek menghasilkan pengaruh yang buruk.
Sejumlah fak'tor yang mempunyai hubungan dengan lingkungan pengembangan dan kontrol adalah:
Staf yang memenuhi syarat
Kemudahan dalam mengerti sistem
Mudah dalam menangani sistem
Mudah dalam standarisasi bahasa pemrograman
Mudah dalam standarisasi sistem operasi
Tersedianya test case
Perangkat keras yang tepat untuk pengerjaan pemeliharaan
2. Ukuran kuantitatif
Ukuran kuantitatif dari suatu maintainability perangkat lunak secara tidak langsung berpengaruh pada aktivitas pemeliharaan. Berikut akan dijabarkan sejumlah metrik (ukuran) maintainability yang mempunyai pengaruh dalam aktivitas pemeliharaan:
Waktu pengenalan masalah
Waktu delay (tunda) administrasi
Alat bantu pemeliharaan
Waktu analisis permasalahan
Waktu perubahan spesifikasi
Waktu modifikasi (pembenaran)
Waktu uji coba
Waktu total
Perbaikan Maintainability Selama Pengembangan
• Aktivitas analisis
• Aktivitas perancangan artsitektural
• Aktivitas perancangan terinci
• Aktivitas penerapan
• Aktivitas lainnya
Aktivitas analisis:
Mengembangkan standarisasi petunjuk
Menentukan kendala untuk dokumen pendukung
Menentukan prosedur yang menjamin kualitas
Menentukan perbaikan produk
Menentukan sumber daya yang diperlukan untuk pemeliharaan
Memperkirakan biaya pemeliharaan
Aktivitas perancangan artsitektural:
Menekankan kejelasan dan modularity sebagai kriteria perancangan
Merancang kemudahan-kemudahan dalam perbaikan
Menggunakan notasi standard untuk dokumentasi jari aliran data, fungi, struktur, dan lain-lain
Menggunakan prinsip informasi hiding, data abstraction, dan dekomposisi hirarki top down (atas bawah)
Aktivitas perancangan terinci:
Menggunakan notasi standar untuk algoritma, struktur data, prosedur
Menentukan pengaruh yang ditimbulkan dan penangan hal-hal yang ditimbulkan
Aktivitas penerapan:
Menggunakan prinsip penyusunan sate masukan dan satu keluaran
Menggunakan standar penyusunan
Menggunakan gaya pengkodean yang jelas dan simpel
Menyediakan dokumentasi singkat untuk setiap modul
Mengikuti petunjuk pada dokumentasi standar
Aktivitas lainnya:
Mengembangan petunjuk pemeliharaan
Mengembangkan uji coba yang cocok
Menyediakan dokumentasi uji coba
Tugas Pemeliharaan
Tugas yang ada pada pemeliharaan sebetulnya telah dipersiapkan sebelum terjadinya permintaan pemeliharaan. Tugas ini diawali dengan pembentukan: organisasi pemeliharaan (baik secara informal atau secara formal), prosedur pelaporan dan evaluasi harus dijabarkan dan urutan tindakan ditentukan untuk masing-masing permintaan pemeliharaan. Selain itu sistem pencatatan untuk aktivitas pemeliharaan juga harus ditentukan, review dan kriteria evaluasi didefinisikan.
Bentuk tanggung jawab organisasi pemeliharaan
Pelaporan
Seluruh permintaan akan pemeliharaan seharusnya dibuat dalam satu bentuk formulir standar. Umumnya pembuat atau pengembangan perangkat lunak membuat satu bentuk formulir atau dokumentasi standar untuk permintaan pemeliharaan yang dikenal dengan nama Maintenance Request Form (MRF atau formulir permintaan pemeliharaan) atau Software Problem Request (laporan permasalahan perangkat lunak).
Jika diketemukan kesalahan oleh pemakai pada perangkat lunak, maka deskrip~i dari keadaan yang menimbulkan kesalahan dijabarkan secara lengkap (meliputi pemasukan data, uji coba, dan lain-lain) MRF adalah dokumen yang digunakan sebagai dasar untuk perencanaan tugas pemeliharaan. Biasanya organisasi pembu;at atau pengembangan perangkat lunak mengembangkan Software Change Report (SCR atau laporan perubahan perangkat lunak) yang berisikan:
Usaha yang dilakukan untuk memenuhi MRF
Modifikasi yang diperlukan
Priortitas permintaan
Perkiraan hasil modifikasi
SCR ini nantinya akan diajukan ke hak kontrol perubahan &belum perencanaan pemeliharaan dimulai.
Aliran tindakan
Pencatatan
Pencatatan merupakan aktivitas yang tidak dapat ditinggalkan pada pemeliharaan, karena pada pencatatan akan digunakan untuk mengukur kualitas dari program yang telah dimodifikasi.
Data yang dicatat antara lain:
Identifikas program
Jumlah ban perintah dari program cumber
Jumlah instruksi yang berorientasi ke bahasa mesin
Bahasa pemrograman yang digunakan
Tanggal pemasangan program
Jumlah program yang dapat di-run (dijalankan) semenjak dipasang (diinstall)
Jumlah proses yang gagal digabungkan dengan nomor 6
Tingkat perubahan program dan identifikasi
Jumlah penambahan perintah pada program yang diuhah
Jumlah penghapusan perintah pada program yang diubah
Jumlah jam kerja yang dihabiskan pada perubahan
Tanggal perubahan program
Identifikasi dari software engineering
Identifikasi dari MRF
Tipe pemeliharaan
Tanggal awal dan berakhir pemeliharaan
Jumlah total jam kerja pada aktivitas pemeliharaan
Manfaat yang didapat dari aktivitas pemeliharaan
Evaluasi
Eavluasi biasanya jarang dilakukan karena kurangnya data yang dicatat, apabila pencatatan dilakukan dengan benar, maka dapat dilakukan evaluasi. Evaluasi dilakukan terhadap:
Jumlah rata-rata kegagalan proses per program pada saat dipasang
Jumlah total waktu yang dihabiskan untuk masing-masing kategori pemeliharaan
Jumlah rata-rata perubahan program yang dilakukan per bahasa program atau per tipe pemeliharaan
Jumlah rata-rata yang dilukiskan untuk penambahan atau penghapusan baris perintah dari program yang diubah
Jumlah rata-rata yang dihabiskan per bahasa
Persentase permintaan pemeliharaan per tipe (lihat aliran tindakan)
Any Questions?
End of Session
Minggu, 08 Januari 2012
strategi pengujian perangkat (9)
Strategi Pengujian Perangkat Lunak
By
Kustanto
Pendekatan Strategis ke pengujian perangkat lunak
Pengujian Unit
Pengujian Integrasi
Pengujian Validasi
Pengujian Sistem
Debugging
Pengujian Unit
Berfokus pada inti terkecil dari desain perangkat lunak yaitu modul
Biasanya berorientasi pada white box
Pengujian Unit
Checklist untuk pengujian interface
Apakah jumlah parameter input sama dengan jumlah argumen?
Apakah antara atribut dan parameter argumen sudah cocok?
Apakah antara sistem satuan parameter dan argumen sudah cocok?
Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?
Pengujian Unit
Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?
Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter?
Apakah jumlah atribut dan urutan argumen ke fungsi-fungsi built-in sudah benar?
Adakah referensi ke parameter yang tidak sesuai dengan poin entri yang ada?
Apakah argumen input only diubah?
Pengujian Unit
Apakah definisi variabel global konsisten dengan modul ?
Apakah batasan yang dilalui merupakan argumen?
Debugging
Trace message
Output designed to record the path of execution and display strategic values
Stack trace
Output showing sequence of method calls awaiting return relative to current statement
new Throwable().printStackTrace();
Logger
An object used to control the output of debugging messages
Display messages at strategic locations:
Logger.global.info("message");
Turn logging off and on using the setLevel method
Logger.global.setLevel(Level.OFF);
Debugging
Pernyataan (Assertions)
A condition that will cause an error if false
Often used to verify pre- and post-conditions
Use a debugger
Breakpoints
Single-stepping
Inspection of variables
JGrasp Debugger
Compile with Debug support
Set a breakpoint
Run under debugger
JGrasp Debugger
Execution halts at breakpoint
JGrasp Debugger
Executing next statement instantiates an object
JGrasp Debugger
Step into reveals details of method calls
Summary
Testing is an important part of the software cycle
Unit testing means testing classes in isolation
Test Suites should be developed to make testing readily repeatable
Java provides several language features useful in debugging
A debugger is an essential tool to facilitate debugging tasks
Any Questions
End of Session
By
Kustanto
Pendekatan Strategis ke pengujian perangkat lunak
Pengujian Unit
Pengujian Integrasi
Pengujian Validasi
Pengujian Sistem
Debugging
Pengujian Unit
Berfokus pada inti terkecil dari desain perangkat lunak yaitu modul
Biasanya berorientasi pada white box
Pengujian Unit
Checklist untuk pengujian interface
Apakah jumlah parameter input sama dengan jumlah argumen?
Apakah antara atribut dan parameter argumen sudah cocok?
Apakah antara sistem satuan parameter dan argumen sudah cocok?
Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?
Pengujian Unit
Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?
Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter?
Apakah jumlah atribut dan urutan argumen ke fungsi-fungsi built-in sudah benar?
Adakah referensi ke parameter yang tidak sesuai dengan poin entri yang ada?
Apakah argumen input only diubah?
Pengujian Unit
Apakah definisi variabel global konsisten dengan modul ?
Apakah batasan yang dilalui merupakan argumen?
Debugging
Trace message
Output designed to record the path of execution and display strategic values
Stack trace
Output showing sequence of method calls awaiting return relative to current statement
new Throwable().printStackTrace();
Logger
An object used to control the output of debugging messages
Display messages at strategic locations:
Logger.global.info("message");
Turn logging off and on using the setLevel method
Logger.global.setLevel(Level.OFF);
Debugging
Pernyataan (Assertions)
A condition that will cause an error if false
Often used to verify pre- and post-conditions
Use a debugger
Breakpoints
Single-stepping
Inspection of variables
JGrasp Debugger
Compile with Debug support
Set a breakpoint
Run under debugger
JGrasp Debugger
Execution halts at breakpoint
JGrasp Debugger
Executing next statement instantiates an object
JGrasp Debugger
Step into reveals details of method calls
Summary
Testing is an important part of the software cycle
Unit testing means testing classes in isolation
Test Suites should be developed to make testing readily repeatable
Java provides several language features useful in debugging
A debugger is an essential tool to facilitate debugging tasks
Any Questions
End of Session
Teknik pengujian perangkat
TEKNIK PENGUJIAN PERANGKAT LUNAK
(Software Testing Techniques)
By
Kustanto, S.T.,M.Eng
Overview
Berhubungan dengan berfungsinya
komponen-komponen yang teridentifikasi
dengan jelas.
Komponen-komponen dapat berupa fungsi
atau sekumpulan metode yang digabungkan menjadi modul atau objek
KENAPA HARUS DIUJI ?
Kita bukan seorang programmer yg cukup baik
Kita mungkin tidak dapat cukup berkonsentrasi untuk menghindari kesalahan
Kita kadang2 lupa menggunakan pemrograman terstruktur secara penuh, perancangan atas-bawah utk mendapatkan solusi
Kita kadang buruk dalam mengerjakan sesuatu
Kita seharusnya dapat membedakan apa yg dikatakan programmer lain atau pelanggan dan apa yg sebenarnya mereka pikirkan
Kita seharusnya merasa bersalah apabila seseorang harus menguji koding kita
Pengujian merupakan suatu perizinan terhadap kesalahan
Tujuan Pengujian
Menjalankan program untuk menemukan error.
Test case (uji kasus) yang bagus adalah yang memiliki kemungkinan terbesar untuk menemukan error yang tersembunyi.
Pengujian yang sukses adalah yang berhasil menemukan error yang tersembunyi.
Hasil dari tahap pengujian ini nantinya akan dimanfaatkan untuk fase pengembangan lebih lanjut, yaitu fase perawatan atau maintenance perangkat lunak
Fase Pengujian
Point of Interest
Hal-hal yang perlu diperhatikan sebelum
melakukan pengujian :
Component Testing
Seringkali disebut sebagai pengujian cacat
atau defect testing.
Pengujian cacat yang berhasil adalah perlakuan uji yang menyebabkan sistem berjalan tidak benar
Component Testing
Component Testing
Ada tiga langkah :
– Pengujian Kotak Hitam (Black-Box Testing)
– Pengujian Struktural (Structural Testing)
– Pengujian Jalur (Path Testing)
Black-Box Testing
Pengujian ini diturunkan dari spesifikasi
program atau komponen.
Perilaku yang diperhatikan hanyalah
INPUT dan OUTPUT.
Seringkali disebut juga sebagai pengujian
fungsional, karena penguji hanya berkepentingan dengan fungsionalitas
bukan implementasinya
Black-Box Testing
Structural Testing
Pendekatan yang diturunkan dari
pengetahuan struktur dan implementasi
perangkat lunak.
Seringkali disebut sebagai pengujian kotak
putih atau White-Box Testing.
Pengujian ini biasanya diterapkan untuk
unit program yang relatif kecil.
Penguji dapat melakukan analisis terhadap kode program dan menggunakan pengetahuan mengenai struktur komponen untuk menurunkan data uji.
Structural Testing
Path Testing
Strategi pengujian struktural yang bertujuan untuk melatih setiap jalur eksekusi independen melalui komponen atau program.
Jika setiap jalur independen dieksekusi,
maka semua statement pada komponen
harus dieksekusi minimal satu kali
Path Testing
Pada sistem berorientasi objek, pengujian
jalur ini digunakan pada saat menguji
methods yang terkait dengan objek.
Jika dimodelkan, maka pengujian ini dapat
digambarkan sebagai diagram alir
(flowchart) dari struktur program
Path Testing
Jumlah jalur independen pada program
dapat dihitung dari kompleksitas siklomatik
dari diagram alir program
DASAR2 PENGUJIAN PERANGKAT LUNAK
Objektifitas Pengujian
◦ Test case yg baik adalah yg mempunyai probabilitas yg tinggi untuk menemukan error yg tak diketemukan
◦ Pengujian merupakan suatu proses eksekusi program yang ditujukan untuk menemukan error
◦ Uji yg sukses adalah yg dapat ‘membuka’ error yang tak diketemukan
Dua klas input yg disediakan untuk proses uji
1. konfigurasi software, termasuk Software Requirement Specification, Design Specification dan Source code
2. konfigurasi uji, termasuk Test Plan & Procedure, perangkat testing yg akan digunakan, test case dan hasil yg diharapkan
PERANCANGAN TEST CASE
Test case yg dirancang harus mempunyai probabilitas yg tinggi untuk menemukan sebuah error dalam waktu & effort yg minimum.
Dua metode pendekatan perancangan test case
1. White Box Testing (pada sesuatu yg kecil (modul)) berfokus pada struktur kontrol program.
Dijamin semua independent path (jalur bebas) telah dijalankan setidaknya satu kali
Menjalankan semua keputusan logis pada sisi true & false
Menjalankan semua looping
Melakukan struktur data internal untuk menjamin validitas
PERANCANGAN TEST CASE (lanj.)
2. Black Box Testing (yang besar) berfokus pada kebutuhan fungsional software, memungkinkan perancang untuk memperoleh kondisi2 input yg secara penuh menguji semua kebutuhan fungsional suatu program
Prinsip Pengujian
Harus bisa dilacak hingga sampai ke kebutuhan customer.
Harus direncanakan sejak model dibuat.
Prinsip Pareto: 80% error uncovered.
Dari lingkup kecil menuju yang besar.
Tidak bisa semua kemungkinan diuji.
Dilakukan oleh pihak ketiga yang independen.
Testability
Kemudahan untuk diuji.
Karakteristiknya:
◦ Operability: mudah digunakan.
◦ Observability: mudah diamati.
◦ Controlability: mudah dikendalikan.
◦ Decomposability: mudah diuraikan.
◦ Simplicity: lingkup kecil, semakin mudah diuji.
◦ Stability: jarang berubah.
◦ Understandability: mudah dipahami.
Desain Kasus Pengujian
Black box testing
◦ Memastikan fungsional P/L berjalan.
◦ Kesesuaian input dengan output.
◦ Tidak memperhatikan proses logic internal.
White box testing
◦ Pengamatan detail prosedur.
◦ Mengamati sampai level percabangan kondisi dan perulangan.
WHITE BOX TESTING : Basis Path Testing
Metode pertama yg diusulkan oleh Tom McCabe (1976). Metode ini memungkinkan perancangan memperoleh pengukuran yang kompleksitas dari perancangan prosedural dan menggunakan pengukuran ini sebagai pedoman pendefinisian sekumpulan basis dari jalur eksekusi
Perangkat yang digunakan
1. Notasi Flow Graph atau Program Graph
Contoh :
- sequence - if
- until
White Box Testing
Metode: basis path testing.
Memakai notasi flow graph.
BASIS PATH TESTING
Cyclomatic Complexity, merupakan pengukuran per.lunak yang menyediakan pengukuran kuantitatif dari kompleksitas logis suatu program. Nilai cyclomatic complexity mendefinisikan jumlah jalur bebas pada basis program.
Independent path (jalur bebas) merupakan jalur pada program yg menunjukkan setidaknya satu kumpulan pernyataan pemrosesan baru atau kondisi baru.
Langkah2 Basis Path Testing
- gunakan rancangan atau kode sebagai pondasi, lalu gambarkan flow graph
- tentukan cyclomatic complexity, dinyatakan V(G) dari flow graph
- tentukan sekumpulan basis secara linear jalur bebas
- persiapkan test case yg akan memperkuat eksekusi setiap jalur pada sekumpulan basis program
Kompleksitas Cyclomatic
Menunjukkan jumlah skenario pengujian yang harus dilakukan untuk menjamin cakupan seluruh program.
BLACK BOX TESTING
Merupakan metode pelengkap White Box Testing. Berfokus pada kebutuhan fungsional dari per.lunak.
Memungkinkan perancang untuk memperoleh sekumpulan kondisi2 input yg secara penuh menguji semua kebutuhan fungsional suatu program
Metode ini berusaha menemukan kesalahan yg termasuk kategori di bawah ini
- fungsi2 yg hilang atau tidak benar
- kesalahan pada antarmuka
- kesalahan pada struktur data atau pengaksesan database ekternal
- kesalahan pada performance
- kesalahan pada inisialisasi dan terminasi
Contoh White Box Testing
Black Box Testing – Graph Based
Black Box Testing – Equivalence Partitioning
Contoh: Input NPM dalam SIAMIK
◦ Jika dikosongi?
◦ Jika diisi dengan format yang salah?
◦ Jika diisi dengan NPM yang benar?
Black Box Testing – Analisa Nilai Batas
Menguji untuk input di sekitar batas atas maupun bawah sebuah range nilai yang valid.
Menguji nilai maksimal dan minimal.
Menerapkan (1 & 2) untuk output.
Menguji batas struktur data yang dipakai. Misal ukuran array.
Black Box Testing – Perbandingan
Spesifikasi kebutuhan yang sama dimungkinkan menghasilkan aplikasi/ perangkat lunak yang berbeda.
Skenario pengujian pada aplikasi yang demikian bisa digunakan untuk skenario pengujian aplikasi serupa yang lain.
Skenario Pengujian Khusus
Pengujian GUI.
Pengujian arsitektur client/ server.
Pengujian dokumentasi dan fasilitas bantuan.
Pengujian sistem waktu nyata.
CONTOH LAIN
Contoh lain White Box Testing atau Control Structure Testing adalah
1. Condition Testing, menjalankan kondisi logis yang terdapat pada modul program
2. Data Flow Testing, metode yg menyeleksi jalur test program menurut lokasi pendefinisian & menggunakan variabel2 program
3. Loop Testing, berfokus pada validitas dari bentuk loop (simple loop, concatenated loop, nested loop, unstructured loop)
CONTOH LAIN
Contoh lain Black Box Testing adalah
1. Equivalence Partitioning, membagi domain input dari program ke dalam klas2 data
2. Boundary Value Analysis (BVA) melengkapi Equivalence Partitioning, dengan melakukannya dari domain output
3. Cause-effect Graphing, memvalidasi aksi2 & kondisi yg kompleks
CHAPTER 18
STRATEGI PENGUJIAN P/L
STRATEGI PENGUJIAN P/L
Membahas langkah-langkah yang harus dikerjakan sebagai bagian dari pengujian.
Kapan dilaksanakan? Berapa usaha, waktu dan sumber daya yang digunakan?
Meliputi: perencanaan, desain test case, pelaksanaan, koleksi data dan evaluasi.
Kaidah Umum Pengujian
Dimulai dari pengujian tingkat komponen menuju integrasi.
Titik yang berbeda dimungkinkan memakai teknik pengujian yang berbeda.
Pengujian dilakukan oleh developer dan (untuk proyek yang besar) tim independen.
Testing dan debugging adalah berbeda. Namun debugging pasti berkaitan dengan strategi testing apapun.
Strategi Pengujian
Dimulai dari unit testing terhadap source code hingga system testing terhadap spesifikasi kebutuhan.
Langkah Pengujian
Unit Testing
Integration Testing
Top – down integration
Integration Testing
Bottom – up integration
Integration Testing
Regression testing: dilakukan pengujian setiap kali ada modul baru yang diintegrasikan atau ada modul yang berubah.
Smoke testing: test daily, untuk proyek jenis kritis-waktu.
Validation Testing
Disebut sukses jika fungsi P/L dapat diterima oleh customer (berdasarkan dokumen SKPL).
Alpha test: dilakukan di tempat developer oleh customer pada lingkungan yang terkendali.
Beta test: dilakukan di tempat customer tanpa melibatkan developer pada lingkungan yang tak terkendali.
System Testing
Meguji sistem berbasis komputer secara menyeluruh, termasuk juga hubungannya dengan sistem yang lain.
Diantaranya:
◦ Recovery testing, jika system failure.
◦ Security testing, jika terjadi serangan.
◦ Stress testing, terhadap jumlah, frekuensi dan volume pekerjaan.
◦ Performance testing, untuk mengukur pemakaian sumber daya.
Debugging
Memperbaiki error yang ditemukan pada saat testing (yang sukses).
Kaidah dasar sebelum debug:
◦ Apakah penyebab bug dihasilkan kembali oleh bagian program yang lain?
◦ Apakah bug selanjutnya yang mungkin muncul jika bug diperbaiki?
◦ Apa yang bisa dilakukan untuk mencegah bug terjadi untuk pertama kalinya?
Any Questions?
End of Session
(Software Testing Techniques)
By
Kustanto, S.T.,M.Eng
Overview
Berhubungan dengan berfungsinya
komponen-komponen yang teridentifikasi
dengan jelas.
Komponen-komponen dapat berupa fungsi
atau sekumpulan metode yang digabungkan menjadi modul atau objek
KENAPA HARUS DIUJI ?
Kita bukan seorang programmer yg cukup baik
Kita mungkin tidak dapat cukup berkonsentrasi untuk menghindari kesalahan
Kita kadang2 lupa menggunakan pemrograman terstruktur secara penuh, perancangan atas-bawah utk mendapatkan solusi
Kita kadang buruk dalam mengerjakan sesuatu
Kita seharusnya dapat membedakan apa yg dikatakan programmer lain atau pelanggan dan apa yg sebenarnya mereka pikirkan
Kita seharusnya merasa bersalah apabila seseorang harus menguji koding kita
Pengujian merupakan suatu perizinan terhadap kesalahan
Tujuan Pengujian
Menjalankan program untuk menemukan error.
Test case (uji kasus) yang bagus adalah yang memiliki kemungkinan terbesar untuk menemukan error yang tersembunyi.
Pengujian yang sukses adalah yang berhasil menemukan error yang tersembunyi.
Hasil dari tahap pengujian ini nantinya akan dimanfaatkan untuk fase pengembangan lebih lanjut, yaitu fase perawatan atau maintenance perangkat lunak
Fase Pengujian
Point of Interest
Hal-hal yang perlu diperhatikan sebelum
melakukan pengujian :
Component Testing
Seringkali disebut sebagai pengujian cacat
atau defect testing.
Pengujian cacat yang berhasil adalah perlakuan uji yang menyebabkan sistem berjalan tidak benar
Component Testing
Component Testing
Ada tiga langkah :
– Pengujian Kotak Hitam (Black-Box Testing)
– Pengujian Struktural (Structural Testing)
– Pengujian Jalur (Path Testing)
Black-Box Testing
Pengujian ini diturunkan dari spesifikasi
program atau komponen.
Perilaku yang diperhatikan hanyalah
INPUT dan OUTPUT.
Seringkali disebut juga sebagai pengujian
fungsional, karena penguji hanya berkepentingan dengan fungsionalitas
bukan implementasinya
Black-Box Testing
Structural Testing
Pendekatan yang diturunkan dari
pengetahuan struktur dan implementasi
perangkat lunak.
Seringkali disebut sebagai pengujian kotak
putih atau White-Box Testing.
Pengujian ini biasanya diterapkan untuk
unit program yang relatif kecil.
Penguji dapat melakukan analisis terhadap kode program dan menggunakan pengetahuan mengenai struktur komponen untuk menurunkan data uji.
Structural Testing
Path Testing
Strategi pengujian struktural yang bertujuan untuk melatih setiap jalur eksekusi independen melalui komponen atau program.
Jika setiap jalur independen dieksekusi,
maka semua statement pada komponen
harus dieksekusi minimal satu kali
Path Testing
Pada sistem berorientasi objek, pengujian
jalur ini digunakan pada saat menguji
methods yang terkait dengan objek.
Jika dimodelkan, maka pengujian ini dapat
digambarkan sebagai diagram alir
(flowchart) dari struktur program
Path Testing
Jumlah jalur independen pada program
dapat dihitung dari kompleksitas siklomatik
dari diagram alir program
DASAR2 PENGUJIAN PERANGKAT LUNAK
Objektifitas Pengujian
◦ Test case yg baik adalah yg mempunyai probabilitas yg tinggi untuk menemukan error yg tak diketemukan
◦ Pengujian merupakan suatu proses eksekusi program yang ditujukan untuk menemukan error
◦ Uji yg sukses adalah yg dapat ‘membuka’ error yang tak diketemukan
Dua klas input yg disediakan untuk proses uji
1. konfigurasi software, termasuk Software Requirement Specification, Design Specification dan Source code
2. konfigurasi uji, termasuk Test Plan & Procedure, perangkat testing yg akan digunakan, test case dan hasil yg diharapkan
PERANCANGAN TEST CASE
Test case yg dirancang harus mempunyai probabilitas yg tinggi untuk menemukan sebuah error dalam waktu & effort yg minimum.
Dua metode pendekatan perancangan test case
1. White Box Testing (pada sesuatu yg kecil (modul)) berfokus pada struktur kontrol program.
Dijamin semua independent path (jalur bebas) telah dijalankan setidaknya satu kali
Menjalankan semua keputusan logis pada sisi true & false
Menjalankan semua looping
Melakukan struktur data internal untuk menjamin validitas
PERANCANGAN TEST CASE (lanj.)
2. Black Box Testing (yang besar) berfokus pada kebutuhan fungsional software, memungkinkan perancang untuk memperoleh kondisi2 input yg secara penuh menguji semua kebutuhan fungsional suatu program
Prinsip Pengujian
Harus bisa dilacak hingga sampai ke kebutuhan customer.
Harus direncanakan sejak model dibuat.
Prinsip Pareto: 80% error uncovered.
Dari lingkup kecil menuju yang besar.
Tidak bisa semua kemungkinan diuji.
Dilakukan oleh pihak ketiga yang independen.
Testability
Kemudahan untuk diuji.
Karakteristiknya:
◦ Operability: mudah digunakan.
◦ Observability: mudah diamati.
◦ Controlability: mudah dikendalikan.
◦ Decomposability: mudah diuraikan.
◦ Simplicity: lingkup kecil, semakin mudah diuji.
◦ Stability: jarang berubah.
◦ Understandability: mudah dipahami.
Desain Kasus Pengujian
Black box testing
◦ Memastikan fungsional P/L berjalan.
◦ Kesesuaian input dengan output.
◦ Tidak memperhatikan proses logic internal.
White box testing
◦ Pengamatan detail prosedur.
◦ Mengamati sampai level percabangan kondisi dan perulangan.
WHITE BOX TESTING : Basis Path Testing
Metode pertama yg diusulkan oleh Tom McCabe (1976). Metode ini memungkinkan perancangan memperoleh pengukuran yang kompleksitas dari perancangan prosedural dan menggunakan pengukuran ini sebagai pedoman pendefinisian sekumpulan basis dari jalur eksekusi
Perangkat yang digunakan
1. Notasi Flow Graph atau Program Graph
Contoh :
- sequence - if
- until
White Box Testing
Metode: basis path testing.
Memakai notasi flow graph.
BASIS PATH TESTING
Cyclomatic Complexity, merupakan pengukuran per.lunak yang menyediakan pengukuran kuantitatif dari kompleksitas logis suatu program. Nilai cyclomatic complexity mendefinisikan jumlah jalur bebas pada basis program.
Independent path (jalur bebas) merupakan jalur pada program yg menunjukkan setidaknya satu kumpulan pernyataan pemrosesan baru atau kondisi baru.
Langkah2 Basis Path Testing
- gunakan rancangan atau kode sebagai pondasi, lalu gambarkan flow graph
- tentukan cyclomatic complexity, dinyatakan V(G) dari flow graph
- tentukan sekumpulan basis secara linear jalur bebas
- persiapkan test case yg akan memperkuat eksekusi setiap jalur pada sekumpulan basis program
Kompleksitas Cyclomatic
Menunjukkan jumlah skenario pengujian yang harus dilakukan untuk menjamin cakupan seluruh program.
BLACK BOX TESTING
Merupakan metode pelengkap White Box Testing. Berfokus pada kebutuhan fungsional dari per.lunak.
Memungkinkan perancang untuk memperoleh sekumpulan kondisi2 input yg secara penuh menguji semua kebutuhan fungsional suatu program
Metode ini berusaha menemukan kesalahan yg termasuk kategori di bawah ini
- fungsi2 yg hilang atau tidak benar
- kesalahan pada antarmuka
- kesalahan pada struktur data atau pengaksesan database ekternal
- kesalahan pada performance
- kesalahan pada inisialisasi dan terminasi
Contoh White Box Testing
Black Box Testing – Graph Based
Black Box Testing – Equivalence Partitioning
Contoh: Input NPM dalam SIAMIK
◦ Jika dikosongi?
◦ Jika diisi dengan format yang salah?
◦ Jika diisi dengan NPM yang benar?
Black Box Testing – Analisa Nilai Batas
Menguji untuk input di sekitar batas atas maupun bawah sebuah range nilai yang valid.
Menguji nilai maksimal dan minimal.
Menerapkan (1 & 2) untuk output.
Menguji batas struktur data yang dipakai. Misal ukuran array.
Black Box Testing – Perbandingan
Spesifikasi kebutuhan yang sama dimungkinkan menghasilkan aplikasi/ perangkat lunak yang berbeda.
Skenario pengujian pada aplikasi yang demikian bisa digunakan untuk skenario pengujian aplikasi serupa yang lain.
Skenario Pengujian Khusus
Pengujian GUI.
Pengujian arsitektur client/ server.
Pengujian dokumentasi dan fasilitas bantuan.
Pengujian sistem waktu nyata.
CONTOH LAIN
Contoh lain White Box Testing atau Control Structure Testing adalah
1. Condition Testing, menjalankan kondisi logis yang terdapat pada modul program
2. Data Flow Testing, metode yg menyeleksi jalur test program menurut lokasi pendefinisian & menggunakan variabel2 program
3. Loop Testing, berfokus pada validitas dari bentuk loop (simple loop, concatenated loop, nested loop, unstructured loop)
CONTOH LAIN
Contoh lain Black Box Testing adalah
1. Equivalence Partitioning, membagi domain input dari program ke dalam klas2 data
2. Boundary Value Analysis (BVA) melengkapi Equivalence Partitioning, dengan melakukannya dari domain output
3. Cause-effect Graphing, memvalidasi aksi2 & kondisi yg kompleks
CHAPTER 18
STRATEGI PENGUJIAN P/L
STRATEGI PENGUJIAN P/L
Membahas langkah-langkah yang harus dikerjakan sebagai bagian dari pengujian.
Kapan dilaksanakan? Berapa usaha, waktu dan sumber daya yang digunakan?
Meliputi: perencanaan, desain test case, pelaksanaan, koleksi data dan evaluasi.
Kaidah Umum Pengujian
Dimulai dari pengujian tingkat komponen menuju integrasi.
Titik yang berbeda dimungkinkan memakai teknik pengujian yang berbeda.
Pengujian dilakukan oleh developer dan (untuk proyek yang besar) tim independen.
Testing dan debugging adalah berbeda. Namun debugging pasti berkaitan dengan strategi testing apapun.
Strategi Pengujian
Dimulai dari unit testing terhadap source code hingga system testing terhadap spesifikasi kebutuhan.
Langkah Pengujian
Unit Testing
Integration Testing
Top – down integration
Integration Testing
Bottom – up integration
Integration Testing
Regression testing: dilakukan pengujian setiap kali ada modul baru yang diintegrasikan atau ada modul yang berubah.
Smoke testing: test daily, untuk proyek jenis kritis-waktu.
Validation Testing
Disebut sukses jika fungsi P/L dapat diterima oleh customer (berdasarkan dokumen SKPL).
Alpha test: dilakukan di tempat developer oleh customer pada lingkungan yang terkendali.
Beta test: dilakukan di tempat customer tanpa melibatkan developer pada lingkungan yang tak terkendali.
System Testing
Meguji sistem berbasis komputer secara menyeluruh, termasuk juga hubungannya dengan sistem yang lain.
Diantaranya:
◦ Recovery testing, jika system failure.
◦ Security testing, jika terjadi serangan.
◦ Stress testing, terhadap jumlah, frekuensi dan volume pekerjaan.
◦ Performance testing, untuk mengukur pemakaian sumber daya.
Debugging
Memperbaiki error yang ditemukan pada saat testing (yang sukses).
Kaidah dasar sebelum debug:
◦ Apakah penyebab bug dihasilkan kembali oleh bagian program yang lain?
◦ Apakah bug selanjutnya yang mungkin muncul jika bug diperbaiki?
◦ Apa yang bisa dilakukan untuk mencegah bug terjadi untuk pertama kalinya?
Any Questions?
End of Session
Langganan:
Postingan (Atom)