ed Testing 3.3.2 Metode Graph Bas
3.3.8 Functional Analysis
Teknik yang paling banyak dipakai untuk mengidentifikasi test cases.
Dasar utama pemikirannya adalah melakukan analisa terhadap fungsi-fungsi yang terdapat pada suatu sistem , apakah fungsi-fungsi tersebut mempunyai kinerja sebagaimana yang diharapkan atau dispesifikasikan.
Bab III Disain Test Case Halaman 73 Teknik ini membutuhkan jawaban atas pertanyaan sebagai berikut:
Fungsi utama apa saja yang harus ada pada sistem?
Berdasarkan fungsi-fungsi yang ada, keluaran apa saja yang harus dihasilkan untuk membuktikan bahwa fungsi tersebut telah dipenuhi?
Apa saja masukan dan inisialisasi yang dibutuhkan sistem untuk menghasilkan keluaran pada tiap fungsi yang bersangkutan?
Karena itu, pendekatan pertama adalah mendapatkan informasi spesifikasi dari fungsi yang diharapkan dapat disediakan oleh sistem. Informasi ini umumnya terdapat pada dokumentasi spesifikasi fungsional sistem.
Bagaimana bila tidak ada dokumentasi spesifikasi fungsional sistem? Pengguna harus membuat spesifikasi fungsional. Proses pembuatan dapat dimulai dari struktur menu m atau buku panduan un
progra tuk pengguna (misal Help File atau User Manual).
C o n t o h i l u s t r a s i
Sebagai contoh ilustrasi diberikan suatu aplikasi mainframe dari shire council, yang mempunya
data.
kumentasi sistem yang mutakhir.
u n g s i n y a
i fungsi utama sebagai berikut: Finansial, akuntansi dan anggaran. Manajemen inventori.
Pembelian. Jasa. Manajemen
Dan sebagaimana biasanya, tidak ada do
D e k o m p o s i s i s i s t e m t e r h a d a p f u n g s i - f
Dimulai dengan membagi sistem ke grup-grup fungsi untuk kategori fungsional utama. Contoh:
Fungsi operator.
Fungsi administrasi sistem. Fungsi instalasi.
Fungsi keamanan. Fungsi recovery / backup. Fungsi antarmuka
Dan lain-lain.
Selanjutnya untuk tiap kategori fungsional, dikembangkan hirarki dari grup fungsi yang mendefinisikan tipe-tipe dari fungsi yang ada untuk kategori tersebut.
Terdapat tuntunan tertentu pada tahap ini, dalam menetapkan grup-grup yang tergantung pada tipe sistem. Hal-hal berikut dapat menjadi titik mulai yang baik untuk membang n hirarki grup fungsi:
uku panduan pengguna. l untuk fungsi operator:
u Menu dari sistem.
Daftar isi atau kepala judul seksi dari b Menu utama menyediakan grup fungsi awa
Bab III Disain Test Case Halaman 74
Gambar 3.25 Menu utama dari sistem shire council.
Sub-menu akan mendefinisikan hirarki dari grup menu selanjutnya:
Gambar 3.26 Sub-menu pembelian (purchasing) dari sistem shire council.
Untuk tiap grup fungsi, identifikasikan sekumpulan fungsi yang merupakan bagian dari grup bersangkutan. Jika fungsi dapat dikomposisikan lebih lanjut ke sub-fungsi, maka fungsi tersebut akan menjadi grup fungsi.
Dalam membuat hirarki kelanjutan dari tiap grup fungsi, hal-hal berikut dapat menjadi titik awal yang baik:
Tingkat menu-menu yang terbawah.
Paragraf bagian dari buku panduan pengguna.
Suatu menu akan rup fungsi.
ganalisa, tester dapat membangun suatu hirarki grup fungsi dan fungsi: menghubungkan pada fungsi-fungsi tertentu daripada grup-g Setelah men
Bab III Disain Test Case Halaman 75
e n d e f i n i s i k a n f u n g s i - f u n g s i
Gambar 3.27 Hirarki fungsi dari sistem shire council.
M
Untuk tiap fungsi, menyediakan diskripsi: Apa yang har
Bagaimana fungsi seharusnya bekerja. us dilakukan oleh fungsi.
Gambar 3.28 Deskripsi dari fungsi masukan pesanan pembelian (puchase order entry).
Detil diskripsi tergantung pada model fungsi pengguna, terkadang suatu grup fungsi membutuhkan diskripsi yang lebih detil.
Bab III Disain Test Case Halaman 76
Gambar 3.29 Layar 1 dari penggunaan fungsi purchase order.
r 3.30 Layar 2 dari penggunaan fungsi purchase order. Gamba
bar 3.31 Layar 3 dari penggunaan fungsi purchase order. Gam
Bab III Disain Test Case Halaman 77
i nggunaan fungsi purchase order. Gambar 3.32 Layar 4 dar pe
5 dari penggunaan fungsi purchase order. Gambar 3.33 Layar
Bab III Disain Test Case Halaman 78 Masukan-masukan dan keluaran-keluaran dari layar-layar purchase order entry, adalah
: sebagai berikut
Tampilan masukan Tampilan keluaran
Suplier Number Pur hase Order Numbec r
U ntu
order
ntuk identifikasi produk-produk suplier. Kode unik yang dibuat u entry.
k purchase
Responsibility Default Purchasing Officer
Kod Kode elian yang diambil
i l
e alokasi anggaran. petugas pemb
og-in. dar
Location Default Location
Inte na Kode nan yang diambil
dari l
nsi lokasi penyimpa n produk. lokasi penyimpa og-in.
Order Date Def ult Delivery Site Dea tails
T
lokas
anggal pesanan dilakukan. Lokasi pengiriman yang did i.
apat dari
Reference Order Total
Tek
digus untuk kode referensi yang nakan. Penjumladipesan. han subtotal produk yang
Delivery Code
Untuk identifikasi alamat pengiriman. Untuk tiap p oduk yang dipesan r
Delivery Details Default Product Price
Detil dari alamat pengiriman. Harga per unit produk yang diambil dari data produk suplier.
Carrier Default Product Description
Met Diskr ambil dari data
produk suplier.
ode pengiriman. ipsi produk yang di
Deliver
Instruksi khusus untuk p giriman. en
Contact
Ora
penng yang bertanggung janganan pesanan. awab terhadap
Purchasing Officer O
mraenng yang bertanggungerbitkan pesanan pemjawab dalam belian.
Payment Terms
Waktu pembayaran.
Sales Tax
K n yan
pes
ode pajak penjuala anan pembelian.
g dipakai pada
Print Order Option Y/N untuk mencetak pesanan.
Confirmation Order Option
???
Print Order Prices Option
Y ga
yang dicetak. /N untuk mencetak har pada pesanan
Batch Print Option Y/N untuk mencetak batch di akhir hari
atau sekarang.
Bab III Disain Test Case Halaman 79 Sambungan …
Tampilan masukan Tampilan keluaran
Untuk tiap produk yang dipesan
Product Code Untuk identifikasi produk yang dipesan.
Description Diskripsi produk yang dipesan.
Quantity Jumlah unit produk yang dipesan.
Price
Harga per unit.
Unit
Ukuran dari produk.
Due Date Batas tanggal penerimaan
dipesan.
produk yang
Tax Class Kode untuk pajak yang dip
produk yang dipesan. akai pada
D i s a i n t e s m e n g g u n a k a n f u n c t i o n a l a n a l y s i s
Menganalisa tiap fungsi se endefinisikan sekumpulan kriteria tes
uk menentukan apa yang
Keluaran-keluaran fungsi. disi internal fungsi.
r i t e r i a f u n g s i
ar. cara terpisah untuk m
Analisa tiap pemrosesan fungsi masukan dan keluaran unt dibutuhkan tes.
Fokus pada tiap fungsi untuk menganalisa: Kriteria fungsi.
Masukan-masukan fu Kondisi-kon
ngsi. Status-status internal fungsi.
K
Mendefinisikan kriteria yang menentukan apakah fungsi telah bekerja dengan ben
No. Kriteria Test case
1
tit Pesanan pembelian d suplier terhadap prod dipilih dengan kuan
isimpan berdasarkan uk-produk yang as berbeda.
PUR-POE-01-001
2 pembelian yang ditambahkan produk-produk yang menung Produk-produk disimp
gu pengiriman dalam stok inventori.
PUR-POE-01-002 an dalam pesanan
untuk
K e l u a r a n - k e l u a r a n f u n g s i
Mengidentifikasi keluaran-keluaran yang harus dihasilkan oleh sistem dalam rangka untuk menunjang fungsi.
Identifikasi bagaimana nilai didapat.
Bab III Disain Test Case Halaman 80
No. Keluaran Kemampuan akses Kebenaran Test case
1 n iobservasi r purchase order e yang ditambahkan tanpa menumpuk n PUR-POE-02-001 Nomor pesanan pembelian yang unik
dibuat saat memulai Dapat ddari laya
Cek pesanan baru masukan pesana pembelian. ntry. pesana lainnya. pembelian 2
Harga satuan produk yang didapat dari daftar harga produk suplier (supplier’s product price list).
Dapa dari la order t y e s an satuan d produk s P diobservasi ar purchase ntry. Harga deng esuai harga alam data uplier. PUR- OE-02-002
3 yang didapat dari daftar harga produk Diskripsi produk
suplier. bersangkutan.
Dapat diobservasi dari layar purchase order entry.
Sama dengan yang disimpan di daftar harga produk suplier
untuk kode produk PUR-POE-02-003
4
Jumlah total pesanan pembelian yang didapat dari
penjumlahan subtotal pesanan produk.
Dapat diobservasi dari layar purchase order entry. Penjumlahan dari subtotal pesanan produk. PUR-POE-02-004 5 dengan produk tertentu dan kuantitas yang ada dalam data pesanan pembel
Dapat diobservasi dari purchase order records
menggunakan query.
Detil data pesanan pembelian menurut yang dimasukan. PUR-POE-01-001 Pesanan baru ian. 6 Kuantitas pesanan produk yang ada dalam stok inventori setelah pemenuh
Cek tingkat stok untuk produk yang dipesan sebelum
Tingkat stok naik sesuai dengan
jumlah yang PUR-POE-01-002 an. dan sesudah pemesanan. dipesan.
7 yang didapat dari kode alamat Alamat pengiriman
pengiriman. order entry. bersangkutan. Dapat diobservasi
dari layar purchase
Sama dengan data lokasi pengiriman
untuk kode PUR-POE-02-005
8 sejumlah pesanan
pembelian. Data anggaran
departemen yang telah di-update dalam debit pesanan
Dapat diobservasi dari department budget records menggunakan
Anggaran
departemen didebit PUR-POE-02-006 pembelian. query.
9 Petugas pembelian yang didapat dari log-in.
Dapat diobservasi dari layar purchase order entry.
Tergantung pada lokasi dan pengguna yang log-in.
PUR-POE-02-006 PUR-POE-02-007 10 Kode toko yang didapat dari log-in. Dapat diobservasi dari layar purchase Tergantung pada lokasi saat log-in PUR-POE-02-008
Bab III Disain Test Case Halaman 81
M a s u k a n - m a s u k a n f u n g s i
Identifikasi masukan-masukan yang dibutuhkan untuk menghasilkan keluaran dari tiap fungsi.
No. Masukan Kebutuhan Test case
1 Supplier Number pembelian. Pesanan pembelian Nomor suplier digunakan untuk menghasilkan suatu pesanan disimpan berdasarkan pada suplier yang bersangkutan.
PUR-POE-01-001 PUR-POE-03-001 Masukan yang belum dicakup: semua kecuali nomor suplier.
Identifikasi bagaimana masukan-masukan yang tidak valid diperlakukan.
No. Masukan Perlakuan Test case
1 Supplier Number
Jika nomor suplier tidak ada dalam data detil suplier, kemudian pesan error dicetak, dan membatalkan
penambahan pesanan pembelian.
PUR-POE-03-002
2 Suplier Number akan muncul pesan error yang dicetak, dan membatalkan penambahan pesanan pembelian.
PUR-POE-03-003 Jika nomor suplier tidak dimasukan
Masukan yang belum dicakup: semua kecuali nomor suplier.
K o n d i s i - k o n d i s i i n t e r n a l f u n g s i
Identifikasi kondisi internal dimana keluaran yang diharapkan akan dihasilkan.
No. Kondisi Internal Efek Test case
1 Pesanan pembelian berada dalam batas
anggaran. Pesanan pembelian dapat diselesaikan. PUR-POE-04-001 Hanya ada satu kondisi internal.
Identifikasi apa yang terjadi bilamana kondisi yang dibutuhkan tidak terpuaskan.
No. Kondisi Perlakuan Test case
1
Pesanan pembelian tidak dalam batas anggaran.
Pesanan pembelian tidak dapat disetujui dan pesan error akan muncul. Pengguna akan dibawa kembali ke purchase order entry agar dapat mengubah atau membatalkan.
PUR-POE-04-002
Bab III Disain Test Case Halaman 82
S t a t u s - s t
a status internal dapat diobservasi secara eksternal untuk melakukan cek kebenaran perubahan status.
a t u s i n t e r n a l f u n g s i
Identifikasi bagaimana status internal berubah setelah menerima tiap masukan. Bagaiman
No. Status internal Kemampuan akses Kebenaran Test case
1
Pesanan pembelian yang telah komplit dengan opsi batch print dipilih,
diindikasikan sebagai data yang belum dicetak.
Dapat diakses dari data pesanan pemebelian. Tanda belum dicetak akan mengindikasikan untuk menunggu dicetak. PUR-POE-05-001
Belum komplit: hanya ada satu status internal.
3.3.9 Use Cases
Collard memberikan artikel yang berguna dalam membuat tes dari use cases [COL99A]. Suatu use case adalah suatu sekuensial aksi yang dilakukan oleh sistem, yang akan secara
be s
sepanjang sistem berbasis pada kegunaan sebagaimana yang
use ca
Use ca raksi atau fitur-fitur dan fungsi-fungsi yang berbeda dari sistem. Karena alasan ini, tes yang dibuat dari use cases akan membantu dalam menemukan errors dari integras
rsama-sama memproduksi hasil yang dibutuhkan pengguna sistem. Use case mendefinisikan alur proses
biasa dilakukan (secara manual).
Tes yang dibuat dari use cases akan membantu dalam mencakup defects dari alur proses selama penggunaan sistem yang aktual. Merupakan suatu hal yang tidak mungkin untuk melakukan transisi ke bagian lain dari sistem bila penggunaan sistem didefinisikan dengan
ses.
ses juga memasukan inte i.
D e f i n i s i u s e c a s e s
Tiap
kan kondisi-kondisi dimana use cases berakhir. sil yang dapat diobservasi dan status akhir dari
rhadap aksi merupakan kompresi dari skenario normal, yang
n yang dipakai bersama. use cases memiliki:
Preconditions, yang harus dipertemukan agar use cases dapat bekerja dengan sukses.
Postconditions, mendefinisi
Postconditions juga mengidentifikasi ha sistem setelah use case telah komplit.
Flow of events, yang mendefinisikan aksi pengguna dan respon sistem te yang dilakukan. Flow of events
mendefinisikan tingkah laku umum dari sistem untuk use case, dan cabang-cabang alternatif, dimana bagian lain yang telah tersedia dapat digunakan oleh use case.
Bab III Disain Test Case Halaman 83 Use cases dan test cases akan bekerja dengan baik dalam dua cara, yaitu:
Jika use cases dari sistem kompit, akurat dan jelas, maka pembuatan test cases dapat test cases akan dilakukan secara langsung.
Jika use cases tidak dalam kondisi yang baik, maka pembuatan membantu dalam melakukan debug terhadap test cases.
Berikut contoh dari pembuatan test cases dari suatu use cases.
C o n t o h i l u s t r a s i
Pembuatan test cases dari use cases relatif langsung, dan terdiri dari pemilihan jalur-jalur yang ada pada use case. Keberadaan jalur-jalur tidak hanya untuk jalur-jalur normal, namun juga untuk cabang-cabang alternatif.
a harus diidentifikasi dahulu, baru kemudian masukan
an hkan penilaian untuk mencegah suatu ledakan jumlah test cases. Sebagaimana
erdasarkan pada resiko yang berhubungan, salahan, kebiasaan ditemukannya errors, frekuensi penggunaan, dan Untuk tiap test case, jalur yang diperiks
dan keluaran yang diharapkan dapat didefinisikan. Suatu jalur tunggal dapat menghasilkan banyak test cases yang berlainan, dan juga teknik disain black box testing lainnya, seperti equivalence partitioning dan boundary value analysis, harus digunakan untuk mendapatkan kondisi-kondisi tes lebih lanjut.
Sejumlah besar test cases dapat dibuat dengan menggunakan pendekatan ini, d membutu
biasanya, pemilihan kandidat test cases harus b seperti akibat dari ke
kompleksitas use case.
ilihan produk pada pesanan pembelian. Gambar 3.35 Use case untuk pem
Bab III Disain Test Case Halaman 84
Gambar 3.36 Use case untuk pemilihan produk pada pesanan pembelian.
Suatu contoh test case, yang berdasarkan pada use case di atas, seperti terlhat pada gambar 3.37.
ambar 3.37 Test case untuk skenario normal pemilihan produk pada pesanan pembelian. G
T e s t c a s e s n e g a t i f
Test cases negatif digunakan untuk menangani data yang tidak valid, juga untuk
skenario-guna yang tidak valid, seperti skenario dimana kondisi awal (preconditions) tidak terpuaskan. Ada beberapa jenis test cases negatif yang dapat dibuat, yaitu:
Cabang-cabang alternatif menggunakan aksi-aksi peng terlihat pada gambar 3.38.
Bab III Disain Test Case Halaman 85
Gambar 3.38 Test case negatif pada pesanan pembelian.
daftar dari test case. Termasuk kukan langgaran kondisi awal, seperti mencoba use case pesanan pembelian g tidak mpuny tus “in gress”, seperti penambahan item baru pada pesanan
belian ng telah ditutup.