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

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

• _{* SEPA 6 ed, Roger S. Pressman} akan dilakukan _th

  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.

   .

• _{* SEPA 6 ed, Roger S. Pressman} th

  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

• _{* SEPA 6 ed, Roger S. Pressman th} dapat digunakan).

  

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 _

• _{* SEPA 6 ed, Roger S. Pressman} Batasan kinerja tertentu diuji _th

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

• _{* SEPA 6 ed, Roger S. Pressman th}

  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

• _{* SEPA 6 ed, Roger S. Pressman th}

  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

• _{* SEPA 6 ed, Roger S. Pressman} th
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.

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 :
• 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}

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

• _{* SEPA 6 ed, Roger S. Pressman th}
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. 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

• _{* SEPA 6 ed, Roger S. Pressman} kemungkinan jalur logika _th

  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)

• _{* SEPA 6 ed, Roger S. Pressman th}

  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?

• _{* SEPA 6 th ed, Roger S. Pressman}

  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
• _{* SEPA 6 ed, Roger S. Pressman th}

  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

• _{* SEPA 6 ed, Roger S. Pressman th}

  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 th}

  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

• _{* SEPA 6 ed, Roger S. Pressman th}

  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.