14 Testing dan Audit Perangkat Lunak - Universitas Mercu Buana Yogyakarta

Dosen Pengampu: Anief Fauzan Rozi, S.Kom., M.Eng. Phone: 0856 4384 6541 PIN BB: 23115EF6 Email: [email protected] Website: http://anief.mercubuana-‐yogya.ac.id

4/18/14

Testing dan Audit Perangkat Lunak -‐ Universitas Mercu Buana Yogyakarta

1

¡  Mahasiswa mengetahui dan memahami

tentang black box testing

4/18/14


2

¡  graph based testing ¡  equivalence partitioning ¡  boundary value analysis

¡  cause effect graphing techniques ¡  state transtion testing ¡  functional analysis ¡  use case & test case

4/18/14


3

¡  Black box testing dilakukan tanpa mengetahui

detil struktur internal dari sistem atau komponen yang dites. ¡  Disebut juga behavioral testing, specification-‐ based testing, input/output testing atau functional testing. ¡  Black box testing bukan alternatif dari white box testing. Tetapi pelengkap dalam rangka proses untuk menemukan error. ¡  Dilakukan pada tahap akhir dari testing 4/18/14


4

¡  Kategori error yang ingin ditemukan melalui

black box testing adalah:

§  Fungsi yang hilang atau tidak benar §  Error di user interface §  Error di struktur data atau akses eksternal

database §  Error dari sisi kinerja dan perilaku sistem §  Error dari inisialisasi dan terminasi 4/18/14


5

¡ 

Pengujian yang didasarkan pada pembuatan grafik yang menggambarka n obyek (node) yang membentuk sebuah software dan hubungan / link antar obyek tersebut.

4/18/14


6

1. 

2.  3.  4. 

Mendefinisikan semua node dan bobot node. (Untuk dapat membuat node akan sangat berguna bila dilakukan pendefinisian input dan output dari node) Tetapkan hubungan dan bobot hubungan. Desain test case harus mencakup semua node. Test case yang dibuat harus mencakup tiap link/hubungan dari grafik diatas. Sehingga test case dapat mendeteksi error dari tiap link

4/18/14


7

¡ 

Pemodelan yang bisa dilakukan untuk metode ini: §  Pemodelan Alur Transaksi

(Node: Langkah Transaksi, Link: Logika koneksi transaksi) §  Pemodelan Finite State (Node: status software yang dapat diobservasi, Link: Transisi Status) §  Pemodelan Alur Data (Node: Obyek Data, Link: Perubahan/Perhitungan data) §  Pemodelan Waktu (Node: Obyek Program, Link: Waktu eksekusi)

4/18/14


8

¡  Metode

Black box testing yang membagi domain masukan dari suatu program ke dalam kelas data. ¡  Kelas-‐kelas data tersebut dapat diturunkan menjadi test case.

4/18/14


9

1.  2.  3.  4. 

4/18/14

Jika masukan (input) mempunyai jenjang tertentu, maka definisikan kategori valid dan tidak valid terhadap jenjang tersebut. Jika masukan (input) membutuhkan nilai tertentu, definisikan kategori valid dan tak valid. Jika masukan (input) membutuhkan himpunan masukan tertentu, definisikan kategorii valid dan tak valid. Jika masukan (input) adalah boolean, definisikan kategori valid dan tak valid. Testing dan Audit Perangkat Lunak -‐ Universitas Mercu Buana Yogyakarta

10

¡ 

Beberapa kombinasi nilai yang mungkin dalam partisi ekuivalensi adalah:

Nilai masukan yang valid atau tidak valid Nilai numerik yang negatif, positif atau nol. String yang kosong atau tidak kosong. Daftar (list) kosong atau tidak kosong. File data yang ada dan tidak/ yang dapat dibaca atau tidak. §  Tanggal setelah tahun 2000 atau sebelum tahun 2000, tahun kabisat atau bukan tahun kabisat (terutama tanggal 29 Februari 2000) §  §  §  §  § 

4/18/14


11

¡  Tanggal yang berada dibulan yang berjumlah

28, 29, 30 atau 31 hari. ¡  Hari pada hari kerja atau liburan akhir pekan. ¡  Waktu jam kerja atau diluar jam kerja ¡  Tipe file data, seperti: teks, grafik, video, suara, dsb ¡  Sumber atau tujuan file, seperti hard drive, floppy drive, CD-‐ROM, jaringan. 4/18/14


12

¡  Dua pendekatan pembuatan test case untuk

menguji partisi, adalah:

1.  Test case dibuat terpisah untuk tiap partisi. 2.  Sekumpulan test case dibuat untuk mencakup

semua partisi. Test case yang sama dapat diulang untuk test case yang lain.

4/18/14


13

¡ 

Sebuah software untuk menentukan kelulusan sebuah matakuliah dari seorang mahasiswa sudah dikembangkan dan memiliki aturan sebagai berikut:

4/18/14

NILAI UJIAN (X)

GRADE

X > 100

Muncul Pesan Error

85 < X ≤ 100

A

75 < X ≤ 85

B

60 < X ≤ 75

C

45 < X ≤ 60

D

0 ≤ X ≤ 45

E

X < 0

Muncul Pesan Error


14

¡ 

Partisi yang dapat dibentuk dari contoh kasus 1 adalah:

  Partisi nilai ujian bertipe real / desimal dan

partisi nilai ujian bertipe alfabet.

4/18/14


15

  Test case yang dihasilkan: Test Case Nilai Ujian Partisi yang dites Keluaran yang diharapkan Test Case Nilai Ujian Partisi yang dites Keluaran yang diharapkan

4/18/14

1

2

3

78

-‐10

102

75 < X ≤ 85

X < 0

X > 100

B

Pesan Error

Pesan Error

4

5

6

48,7

‘q’

null

45 < X ≤ 60

X < 0

null

D

Pesan Error

Pesan Error


16

¡  Metode

membuat test case dengan cara menetapkan nilai yang akan digunakan test case adalah nilai yang berada pada “batas” (“edges”) dari kelas data. ¡  Metode ini adalah komplemen dari teknik equivalence partitioning.

4/18/14


17

¡  Petunjuk penggunaan: 1.  Jika input berupa rentang nilai, dengan batas a

dan b, maka input untuk test case adalah nilai a dan b, diatas nilai dan dibawah nilai a dan b. 2.  Jika struktur data menggunakan array dengan batasan tertentu, maka pastikan disain test cases menggunakan batasan array tersebut.

4/18/14


18

¡  Contoh nilai yang digunakan oleh test case: §  Senin dan Minggu untuk hari. §  Januari dan Desember untuk bulan. §  (-‐32767) dan 32767 untuk 16-‐bit integer. §  Satu karakter dan maksimum panjang untuk

string.

¡  Test cases digunakan untuk menguji nilai

dikedua sisi batasan. ¡  Nilai yang digunakan diusahakan mempunyai selisih sekecil mungkin dengan nilai batas.

4/18/14


19

¡ 

Test case untuk Kasus di Contoh Kasus 1 (menggunakan metode Boundary Value Analysis):

Masukan (Nilai Ujian)

44

45

46

84

85

86

Keluaran yang diharapkan

E

D

D

B

B

A

4/18/14


20

¡  Tehnik disain test case yang menggambarkan

logika dari kondisi yang dipengaruhi oleh aksi yang dilakukan.

4/18/14


21

¡  Ada 4 langkah untuk penggunaan tehnik

Cause Effect Graphing:

1.  Tiap sebab (kondisi input) dan akibat (aksi)

yang ada pada suatu modul didaftarkan. 2.  Gambar sebab-‐akibat (cause-‐effect graph) dibuat. 3.  Gambar di konversikan ke tabel keputusan 4.  Aturan-‐aturan yang ada di tabel keputusan, dikonversikan ke test case. 4/18/14


22

¡  Testing yang menggunakan model sistem

(digambarkan dalam bentuk state transition diagram) yang terdiri dari: §  Status yang terdapat didalam program §  Transisi antar status-‐status tersebut §  Kejadian yang merupakan sebab dari transisi-‐

transisi tersebut. §  Aksi-‐aksi yang akan dihasilkan.

¡  Test case didisain untuk memeriksa validitas

transisi antar status yang mungkin muncul.

4/18/14


23

¡  Sebuah state transition diagram yang

menangani masukan permintaan untuk mode tampilan terhadap waktu dari suatu device adalah:

4/18/14


24

¡  State transition diagram diatas terdiri dari: §  Status, seperti displaying time (S1) §  Transisi, seperti antara S1 dan S3 §  Kejadian yang menyebabkan transisi, seperti

“reset” akan menyebabkan transisi dari S1 ke S3 §  Aksi yang merupakan hasil dari transisi, seperti “display time” yang akan terjadi akibat dari kejadian “reset”. 4/18/14


25

¡  Dalam tiap test case terdapat: §  Status awal §  Masukan / input §  Keluaran yang diharapkan / output §  Status akhir

4/18/14


26

¡  Berdasarkan contoh diatas, terdapat 6 test

case (untuk transisi yang valid):

¡  Untuk transisi yang tidak valid (uji sel yang

bertanda “-‐”):

4/18/14


27

¡  Teknik yang paling banyak dipakai untuk

identifikasi test case. ¡  Melakukan analisa terhadap fungsi yang terdapat dalam sistem.

4/18/14


28

¡  Melakukan analisa untuk menjawab

pertanyaan berikut:

§  Fungsi utama apa saja yang harus ada pada

sistem? §  Berdasarkan fungsi, keluaran apa yang harus dihasilkan untuk membuktikan fungsi terpenuhi? §  Masukan dan inisalisasi yang dibutuhkan sistem untuk menghasilkan keluaran pada tiap fungsi yang bersangkutan? 4/18/14


29

1.  2.  3. 

4. 

Mendekomposisi (membagi) sistem berdasarkan fungsinya Membuat hirarki dalam fungsi tersebut Mendefinisikan fungsi a.  Apa yang harus dilakukan oleh fungsi b.  Bagaimana kerja fungsi tersebut seharusnya, (berbentuk deskripsi, tampilan layar, DFD, daftar input & output) Mendesain test case, berfokus pada: a.  Kriteria fungsi b.  Keluaran fungsi (output) c.  Masukan fungsi (input) d.  Kondisi internal fungsi e.  Status internal fungsi

4/18/14


30

¡  Sebagai contoh suatu aplikasi mempunyai

fungsi utama sebagai berikut:

§  Finansial, akuntansi dan anggaran §  Manajemen Inventori §  Pembelian §  Jasa §  Manajemen data

4/18/14


31

¡  Membagi sistem ke grup fungsi: §  Fungsi operator §  Fungsi administrasi sistem §  Fungsi instalasi §  Fungsi keamanan §  Fungsi recovery / backup §  Fungsi antar muka

4/18/14


32

¡  Membuat hirarki, bisa dimulai dari menu

sistem:

4/18/14


33

¡  Mendefinisikan fungsi:

4/18/14


34

¡  Tampilan Layar & DFD

4/18/14


35

¡  Masukan & Keluaran (Input & Output) dari

layar:

4/18/14


36

¡  Mendesain test case:

4/18/14


37

4/18/14


38

Use case adalah suatu urutan (sekuensial) aksi yang dilakukan oleh sistem, yang akan secara bersama-‐sama memproduksi hasil yang dibutuhkan pengguna sistem. ¡  Tiap use case memiliki: ¡ 

§  Prekondisi: hal-‐hal yang harus ada terlebih dulu agar

use case dapaat bekerja dengan sukses §  Postkondisi: mendefinisikan kondisi dan hasil setelah use case selesai. §  Flow of Event: mendefinisikan aksi user dan respon sistem terhadap aksi tersebut. 4/18/14


39

¡  Use case dan test case akan bekerja dengan

baik dalam dua cara, yaitu:

§  Jika use case dari sistem komplit, akurat dan jelas,

maka pembuatan test case dapat dilakukan secara langsung. §  Jika use case tidak dalam kondisi baik, maka pembuatan test case akan membantu dalam melakukan debug terhadap test case.

4/18/14


40

¡  Pembuatan test case dari use case relatif

langsung, dengan memilih jalur yang ada pada use case. ¡  Tahapan desain test case yang bersumber dari use case: 1.  Identifikasi jalur (di dalam use case) yang akan

ditest. 2.  Satu jalur dapat menghasilkan banyak test case yang berlainan. 4/18/14


41

4/18/14


42

¡  Contoh Use case:

4/18/14


43

¡  Test case yang dihasilkan:

4/18/14


44

¡ 

¡ 

Test case negatif: Test case yang digunakan untuk menangani data yang tidak valid atau untuk skenario dimana kondisi awal tidak terpenuhi. Contoh Test case negatif:

4/18/14


45

4/18/14


46

14 Testing dan Audit Perangkat Lunak - Universitas Mercu Buana Yogyakarta

Recommend Documents