Tujuan Pengujian Perangkat Lunak
IF2036 Software Engineering Software Testing Strategy
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
- * SEPA 6 ed, Roger S. Pressman ditemukan. th
- * SEPA 6 ed, Roger S. Pressman akan dilakukan th
- * SEPA 6 ed, Roger S. Pressman th
- * SEPA 6 ed, Roger S. Pressman th dapat digunakan).
- * SEPA 6 ed, Roger S. Pressman Batasan kinerja tertentu diuji th
- * SEPA 6 ed, Roger S. Pressman th
- * SEPA 6 ed, Roger S. Pressman th
- * SEPA 6 ed, Roger S. Pressman th Terdapat 3 Jenis Pendekatan Debugging antar lain: Brute Force
- 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 * SEPA 6 ed, Roger S. Pressman
- * SEPA 6 ed, Roger S. Pressman th Pendapat Kaner, Falk, dan Nguyen tentang pengujian mereka mengusulkan atribut-atribut dari pengujian yang baik sebagai berikut
- * SEPA 6 ed, Roger S. Pressman kemungkinan jalur logika th
- * SEPA 6 ed, Roger S. Pressman th
- * SEPA 6 th ed, Roger S. Pressman
- * SEPA 6 ed, Roger S. Pressman th
- * SEPA 6 ed, Roger S. Pressman th
- * SEPA 6 ed, Roger S. Pressman th
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 Kualitas harus dibangun untuk proses pembangunan, Anda tidak dapat menggunakan pengujian untuk menambah kualitas setelah kejadian
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
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 fungsi sistem secara keseluruhan dan kinerja yang telah dicapai
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 th 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.
Mengembangkan pendekatan perbaikan terus-menerus untuk
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.
.
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 produk smoke diuji setiap hari (baik top-down atau integrasi bawah
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
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
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.
User merekam semua masalah yang mereka temukan dan melaporkan ke pengembang. Kemudian pengembang melakukan modifikasi dan akhirnya mempersiapkan pelepasan produk ke seluruh pelanggan
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
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
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
Merupakan pendekan yang dimulai dari penemuan gejala kemudian menelusuri balik hingga ke penyebab.
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. Daftar serangkaian penyebab yang mungkin dibuat dan dilakukan pengujian untuk mengeliminasi penyebab- penyebab tersebut. Jika pengujian menunjukkan kebenaran hipotesis untuk suatu penyebab, maka data diperbaiki untuk mengisolasi bug.
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 :termpat pertama? th
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 mengujinyaStability 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
(Good Test Attributes)
Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.
Pengujian yang baik tidak redundan. Pengujian yang baik seharusnya
“jenis terbaik” Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks. 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
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 Siapkan tes case yang akan memaksa eksekusi setiap jalur di basis set.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?
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 timesBlack-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
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 * SEPA 6 ed, Roger S. Pressman thBlack-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 implementationOrthogonal 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
Verification vs. validation 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
Adalah : sebuah program bantu/dummy yg berfungsi menggantikan modul yg
merupakan subordinat dari modul yg diuji.