IF2036 Software Engineering. Software Testing Strategy

Transkripsi

1 IF2036 Software Engineering Software Testing Strategy Page 1

2 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. Page 2

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. Page 3

4 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 Page 4

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 Page 5

6 Unit Testing Software Testing Strategy for Traditional Software Architectures 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 Page 6

7 Unit Testing Software Testing Strategy for Object-Oriented Architectures 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 Page 7

8 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 proses pengujian. Page 8

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.. Page 9

10 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.. Page 10

11 Page 11

12 Page 12

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 produk smoke diuji setiap hari (baik top-down atau integrasi bawah dapat digunakan). Page 13

14 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 Page 14

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 Page 15

16 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 Page 16

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. Page 17

18 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 Page 18

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 Page 19

20 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 Page 20

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 Merupakan pendekan yang dimulai dari penemuan gejala kemudian menelusuri balik hingga ke penyebab. Page 21

22 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 penyebabpenyebab tersebut. Jika pengujian menunjukkan kebenaran hipotesis untuk suatu penyebab, maka data diperbaiki untuk mengisolasi bug. Page 22

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? Page 23

24 Page 24

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 Page 25

26 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 Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks. Page 26

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 Page 27

28 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. Page 28

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) Page 29

30 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? Page 30

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 Page 31

32 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 Page 32

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 Page 33

34 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 Page 34

35 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 Page 35

36 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. Page 36 36