IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 1
IF2036 Software Engineering
Tujuan Pengujian Perangkat Lunak
Pengujian adalah proses eksekusi program
dengan maksud menemukan kesalahan.
Sebuah kasus uji yang baik adalah salah satu
dengan probabilitas tinggi untuk menemukan
kesalahan yang belum ditemukan.
Sebuah tes yang sukses adalah salah satu
yang menemukan kesalahan yang belum
ditemukan.
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 3
Pendekatan strategis untuk Pengujian
Perangkat Lunak
Pengujian dimulai pada tingkat komponen dan
bekerja menuju integrasi seluruh sistem berbasis
komputer.
Teknik pengujian yang berbeda sesuai pada titik
waktu yang berbeda..
Pengembang perangkat lunak melakukan pengujian
dan dapat dibantu oleh independent test groups
(ITG) untuk proyek-proyek besar.
Pengujian dan debugging merupakan aktivitas yang
berbeda.
Debugging harus diakomodasi dalam strategi pengujian.
Verification and Validation
Membedakan antara
Verifikasi (kita membangun produk yang benar?) Dan Validasi (kita membangun produk yang tepat?)
pengujian perangkat lunak adalah satu-satunya unsur Software Quality Assurance (SQA)
Kualitas harus dibangun untuk proses pembangunan, Anda tidak dapat menggunakan pengujian untuk menambah kualitas setelah fakta
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 5
Organizing for Software Testing
Peran Independent Test Group (ITG) adalah untuk menghilangkan konflik kepentingan yang melekat ketika pembangun menguji produk nya sendiri..
Kesalahpahaman tentang penggunaan tim pengujian independen yang
The developer should do no testing at all
Software is tossed "over the wall" to people to test it mercilessly
Testers are not involved with the project until it is time for it to be tested Pengembang dan ITGC harus bekerja sama di seluruh proyek software untuk memastikan bahwa tes menyeluruh akan dilakukan
Software Testing Strategy for
Traditional Software Architectures
Unit Testing
Siap menggunakan teknik pengujian yang menggunakan Jalur kontrol
khusus untuk mendeteksi kesalahan dalam setiap komponen perangkat lunak satu per satu
Integration Testing
berfokus pada isu-isu yang terkait dengan verifikasi dan konstruksi
program sebagai komponen mulai berinteraksi satu dengan lainnya
Validation Testing
Memberikan jaminan bahwa kriteria validasi perangkat lunak
(ditetapkan pada analisis kebutuhan) memenuhi semua fungsional, perilaku, dan persyaratan kinerja
System Testing
Memverifikasi bahwa semua elemen sistem jalur benar dan bahwa
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 7
Software Testing Strategy
for Object-Oriented Architectures
Unit Testing
Komponen yang diuji adalah kelas bukan modul
Integration Testing
Sebagai kelas diintegrasikan ke dalam arsitektur, tes
regresi dijalankan untuk mengungkap komunikasi dan kolaborasi kesalahan antara obyek
Validation Testing
Hampir sama untuk kedua perangkat lunak konvensional
dan berorientasi objek
Systems Testing
Sistem secara keseluruhan diuji untuk mengungkap
kesalahan persyaratan
Strategic Testing Issues
Menentukan persyaratan produk secara kuantitatif sebelum pengujian dimulai.
Tentukan tujuan pengujian secara eksplisit.
Mengidentifikasi kategori pengguna untuk perangkat lunak dan mengembangkan profil untuk masing-masing.
Mengembangkan rencana uji yang menekankan pengujian siklus cepat.
Membangun perangkat lunak yang kuat yang dirancang untuk menguji dirinya sendiri.
Gunakan secara formil yang efektif sebagai filter sebelum pengujian..
Melakukan tinjauan teknis formal untuk menilai strategi dan uji kasus.
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 9
Unit Testing
Interface modul diuji untuk aliran informasi yang tepat. Data lokal diperiksa untuk memastikan bahwa integritas dipertahankan.
Kondisi batas diuji.
Dasar (independen) jalan diuji.
Semua Jalur penanganan kesalahan harus diuji.
Driver dan / atau bertopik perlu dikembangkan untuk menguji perangkat lunak tidak lengkap..
Integration Testing
Top-down integration testing
Berawal dari level-atas system dan terintegrasi dengan
mengganti masing-masing komponen secara top-down dengan suatu stub (program pendek yg mengenerate input ke sub-system yg diuji).
Bottom-up integration testing
Adalah pendekatan integrasi untuk membangun struktur
program, dimana modul-2 diintegrasikan dimulai dari modul-modul atomik yg ada di level bawah menuju keatas.
.
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 13
Integration Testing (2)
Pengujian Regresi - digunakan untuk memeriksa cacat disebarkan ke modul lain dengan perubahan yang dibuat untuk program yang ada
Sampel yang representatif dari kasus uji yang ada digunakan untuk
menjalankan semua fungsi perangkat lunak.
Uji kasus tambahan berfokus fungsi software mungkin akan
terpengaruh oleh perubahan.
Tes kasus yang fokus pada komponen software yang diubah. Smoke testing
Komponen Perangkat lunak yang sudah diterjemahkan ke dalam kode
diintegrasikan ke dalam kembangkan.
Serangkaian tes yang dirancang untuk mengekspos kesalahan yang
akan membuat membangun dari melakukan fungsinya diciptakan.
Membangun terintegrasi dengan lainnya membangun dan seluruh
General Software Test Criteria
Interface integrity
internal dan eksternal interface modul diuji karena setiap
modul atau cluster ditambahkan ke perangkat lunak
Functional validity
Tes untuk mengungkap cacat fungsional dalam perangkat
lunak
Information content
test for errors in local or global data structures
Performance
Batasan kinerja tertentu diuji
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 15
Object-Oriented Unit Testing
Terkecil unit diuji adalah class dienkapsulasi
atau objek
Mirip
dengan
unit
testing
software
konvensional
Tidak menguji operasi dalam isolasi dari
satu sama lain
Didorong oleh operasi kelas dan perilaku
state, rinci bukan algoritmik dan aliran data
di modul antarmuka
Object-Oriented Integration Testing
Berfokus pada kelompok kelas yang berkolaborasi atau berkomunikasi dalam beberapa cara
Integrasi operasi satu per satu ke dalam kelas seringkali berarti
Pendekatan:
thread-based testing - menguji semua kelas yang dibutuhkan untuk
merespon satu input sistem atau event
use-based testing - Dimulai dengan menguji kelas independen (kelas
yang menggunakan sangat sedikit kelas server) pertama dan tergantung kelas yang menggunakan tersebut
Cluster testing - kelompok berkolaborasi kelas diuji untuk kesalahan interaksi
Pengujian regresi adalah penting karena setiap thread, cluster, atau subsistem ditambahkan ke sistem
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 17
Validation Testing
Berfokus pada tindakan pengguna terlihat dan pengguna dikenali output dari sistem
Tes validasi didasarkan pada skenario Use-Case, behavior model, dan diagram alir event dibuat dalam model analisis
Harus memastikan bahwa setiap fungsi atau kinerja karakteristik
sesuai dengan spesifikasinya.
Penyimpangan (kekurangan) harus dirundingkan dengan pelanggan
untuk membangun sarana untuk menyelesaikan kesalahan.
Ulasan konfigurasi atau audit digunakan untuk memastikan bahwa semua elemen dari konfigurasi perangkat lunak telah dikembangkan dengan baik, katalog, dan didokumentasikan untuk memungkinkan dukungan selama fase pemeliharaan.
Acceptance Testing
Memastikan perangkat lunak tersebut bekerja dengan benar untuk penggunaan yang dimaksudkan di lingkungan kerja yang normal nya.
Alpha test :
Dilakukan pada sisi pengembang oleh user yang potensial.
PL digunakan pada setting yang natural (sebenarnya), sehingga bila terjadi error, user dapat merekam masalah yang ada.
Dilakukan pada sebuah lingkungan yang terkontrol oleh pengembang
Beta test :
Dilakukan oleh satu atau lebih user.
Biasanya dilakukan oleh selain pengembang / pihak ketiga.
Pengujian dilakukan diluar kontrol pengembang sistem.
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 19
System Testing
Bertujuan untuk memastikan bahwa semua elemen/komponen sistem (SI) saling berhubungan dengan tepat dan keseluruhan fungsi/kinerja sistem dapat tercapai. Bentuk Tes Sistem :
Recovery testing / Pengujian Perbaikan
Memeriksa kemampuan sistem untuk memulihkan kegagalan Security testing / Pengujian Keamanan
Memverifikasi bahwa mekanisme perlindungan sistem mencegah yang
tidak benar penetrasi atau perubahan data
Stress testing / Pengujiaan Stress
Program diperiksa untuk melihat seberapa baik berkaitan dengan
tuntutan sumber daya yang abnormal (misalnya, kuantitas, frekuensi, atau volume)
Performance testing / Pengujian Kinerja
Pengujian untuk menguji kinerja run-time (saat berjalan) dari PL
didalam konteks sistem yang terintegrasi
Debugging
Debugging (menghilangkan cacat) terjadi sebagai konsekuensi dari pengujian yang berhasil.
Debugging dilakukan jika pengujian berhasil menemukan kesalahan
Pendekatan umum:
Brute force Backtracking
Cause elimination
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 21
Terdapat 3 Jenis Pendekatan Debugging
antar lain:
Brute Force
Merupakan teknik yg paling sering dgunakan dan paling tidak efisien dalam mengisolasi penyebab kesalahan. Dengan prinsi “biarkan komputer menemukan kesalahan”, maka seluruh sumber daya komputer digunakan dengan tujuan untuk menemukan penyebab kesalahan.
Backtracking
Cause elimination
Dimanifestassikan oleh induksi / deduksi dan menggunakan konsep partisi bines. Data yang berhubungan dengan kesalahan yang muncul dikumpulkan untuk mengisolasi penyebab. Kemudian dibuat sebuah hipotesis dan data digunakan untuk membuktikan hipotesis tersebut.
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 23
Pertimbangan Bug Dihilangkan
Sekali bug ditemukan, bug harus diperbaiki. Namun,
perbaikan pada bug dapat memunculkan kesalahan
lain, maka ada beberapa pertimbangan sebelum bug
dihilanghkan antara lain :
• Apakah penyebab bug ada pada bagian lain dari program?
• Apakah “bug yang lain” mungkin terjadi pada saat perbaikan dilakukan?
• Apakah yang telah dilakukan untuk mencegah bug pada termpat pertama?
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 25
Software Testability Checklist
Operability
Semakin baik dia bekerja, semakin efisien dia dapat diuji Observabilty
Apa yang anda lihat adalah apa yang anda uji
Controllability
Semakin baik kita dapat mengontrol perangkat lunak semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan
Decomposability
Dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih halus
Simplicity
Semakin sedikit yang diuji, semakin cepat kita dapat mengujinya Stability
Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian
Understandability (Kemampuan untuk dapat dipahami )
Semakin banyak informasi yang kita miliki, semakin halus pengujian yang akan di lakukan
Pendapat Kaner, Falk, dan Nguyen tentang pengujian mereka mengusulkan atribut-atribut dari pengujian yang baik sebagai
berikut
(Good Test Attributes)
Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.
Pengujian yang baik tidak redundan.
Pengujian yang baik seharusnya “jenis terbaik”
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 27
Test Case Design Strategies
Black-box or behavioral testing
Mengetahui fungsi tertentu produk adalah untuk
melakukan dan mendemonstrasikan operasi yang
benar
hanya
berdasarkan
spesifikasi
tanpa
memperhatikan logika internal
White-box or glass-box testing
Mengetahui kerja internal dari produk, pengujian
akan dilakukan untuk memeriksa kerja dari semua
kemungkinan jalur logika
White-Box Testing
White-Box Testing Questions
Anda dapat menjamin bahwa semua jalur independen dalam sebuah modul akan dijalankan minimal sekali?
Anda dapat melaksanakan semua keputusan logis pada cabang-cabang mereka benar dan yang salah?
Akan semua loop mengeksekusi pada batas mereka dan dalam batas-batas operasional mereka?
Dapat Anda memanipulasi struktur data internal untuk memastikan validitas mereka?
Basis Path Testing
Teknik White-box biasanya didasarkan pada grafik aliran program
Kompleksitas cyclomatic program dihitung dari grafik aliran dengan menggunakan rumus V (G) = E - N + 2 atau dengan menghitung pernyataan bersyarat dalam bahasa rancangan program (PDL) representasi dan menambahkan 1
Tentukan basis set dari jalur independen linear
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 29
White-Box Testing (2)
Control Structure Testing
White-box technique focusing on control structures present in the
software
Condition testing (e.g., branch testing)
focuses on testing each decision statement in a software module, it is important to ensure coverage of all logical combinations of data that may be processed by the module (a truth table may be helpful)
Data flow testing
selects test paths based according to the locations of variable definitions and uses in the program (e.g., definition use chains)
Loop testing
focuses on the validity of the program loop constructs (i.e., simple loops, concatenated loops, nested loops, unstructured loops), involves checking to ensure loops start and stop when they are supposed to (unstructured loops should be redesigned whenever possible)
Black-Box Testing
Black-Box Testing Questions
How is functional validity tested?
How is system behavior and performance tested?
What classes of input will make good test cases?
Is the system particularly sensitive to certain input values?
How are the boundaries of a data class isolated?
What data rates and data volume can the system tolerate?
What effect will specific combinations of data have on
system operation?
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 31
Black-Box Testing (2)
Graph-based Testing Methods
Black-box methods based on the nature of the relationships (links) among the program objects (nodes), test cases are designed to traverse the entire graph
Transaction flow testing - nodes represent steps in some transaction
and links represent logical connections between steps that need to be validated
Finite state modeling - nodes represent user observable states of the
software and links represent transitions between states
Data flow modeling - nodes are data objects and links are
transformations from one data object to another
Timing modeling - nodes are program objects and links are sequential
connections between these objects, link weights are required execution times
Black-Box Testing (3)
Equivalence Partitioning
Black-box technique that divides the input domain into classes of data
from which test cases can be derived
An ideal test case uncovers a class of errors that might require many
arbitrary test cases to be executed before a general error is observed
Equivalence class guidelines:
If input condition specifies a range, one valid and two invalid equivalence classes are defined
If an input condition requires a specific value, one valid and two invalid equivalence classes are defined
If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined
If an input condition is Boolean, one valid and one invalid equivalence class is defined
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 33
Black-Box Testing (4)
Boundary Value Analysis
Black-box technique that focuses on the boundaries of the
input domain rather than its center
BVA guidelines:
If input condition specifies a range bounded by values a and b, test cases should include a and b, values just above and just below a and b
If an input condition specifies and number of values, test cases should be exercise the minimum and maximum numbers, as well as values just above and just below the minimum and maximum values
Apply guidelines 1 and 2 to output conditions, test cases should be designed to produce the minimum and maxim output reports
If internal program data structures have boundaries (e.g., size limitations), be certain to test the boundaries
Black-Box Testing (5)
Comparison Testing
Black-box testing for safety critical systems in which independently
developed implementations of redundant systems are tested for conformance to specifications
Often equivalence class partitioning is used to develop a common set
of test cases for each implementation
Orthogonal Array Testing
Black-box technique that enables the design of a reasonably small set
of test cases that provide maximum test coverage
Focus is on categories of faulty logic likely to be present in the
software component (without examining the code)
Priorities for assessing tests using an orthogonal array
Detect and isolate all single mode faults Detect all double mode faults
Multimode faults
IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing
Page 35
Verification:
“
Apakah kita membangun produk dengan benar
?”
Software seharusnya sesuai dengan
spesifikasinya. Gunakan proses software yang
bagus.
Validation:
“
Apakah kita membangun produk yang benar
?”
Software seharusnya melakukan apa yang
pengguna benar-benar butuhkan
Unit Test…
DRIVER
Adalah : tidak lebih dari sebuah “program utama” yg fungsinya menerima data test case, melewatkan data tsb ke modul yg diuji, dan mencetak/menampilkan hasil yg relevan.
STUB