Tujuan Pengujian Perangkat Lunak

36 

Loading.... (view fulltext now)

Loading....

Loading....

Loading....

Loading....

Teks penuh

(1)

IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing

Page 1

IF2036 Software Engineering

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

(3)

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.

(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

(5)

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

(6)

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

(7)

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

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

(9)

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

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

 .

(11)

IF-ITB/YW/Revisi: Oktober 2008 IF2036 Software Testing

(12)
(13)

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

(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

(15)

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

(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

(17)

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.

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

(19)

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

(20)

Debugging

Debugging (menghilangkan cacat) terjadi sebagai konsekuensi dari pengujian yang berhasil.

Debugging dilakukan jika pengujian berhasil menemukan kesalahan

Pendekatan umum:

Brute forceBacktracking

Cause elimination

(21)

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

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

(23)

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?

(24)
(25)

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

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

(27)

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

(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

(29)

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)

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

(31)

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

(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

(33)

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

(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

(35)

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

(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

Figur

Memperbarui...

Referensi

Memperbarui...