Anda di halaman 1dari 159

JAMINAN MUTU SISTEM INFORMASI

POLITEKNIK TELKOM
BANDUNG
2009



Penyusun
ADE HENDRAPUTRA
AGUS PRATONDO
DEDY RAHMAN WIJAYA
EKO DARWIYANTO
EDY PRASETYO NUGROHO
GUNTUR PRABAWA KUSUMA

Editor
GUNTUR PRABAWA KUSUMA














Dilarang menerbitkan kembali, menyebarluaskan atau menyimpan baik
sebagian maupun seluruh isi buku dalam bentuk dan dengan cara apapun
tanpa izin tertulis dari Politeknik Telkom.

Hak cipta dilindungi undang-undang @ Politeknik Telkom 2009


No part of this document may be copied, reproduced, printed, distributed, modified,
removed and amended in any form by any means without prior written
authorization of Telkom Polytechnic.

Copyright @ 2009 Telkom Polytechnic. All rights reserved

Politeknik Telkom Jaminan Mutu Sistem Informasi


iii
PAGE 10
Kata Pengantar


Assalamualaikum Wr. Wb

Segala puji bagi Allah SWT karena dengan karunia-Nya courseware ini
dapat diselesaikan.

Atas nama Politeknik Telkom, kami sangat menghargai dan ingin
menyampaikan terima kasih kepada penulis, penerjemah dan
penyunting yang telah memberikan tenaga, pikiran, dan waktu sehingga
courseware ini dapat tersusun.

Tak ada gading yang tak retak, di dunia ini tidak ada yang sempurna,
oleh karena itu kami harapkan para pengguna buku ini dapat
memberikan masukan perbaikan demi pengembangan selanjutnya.

Semoga courseware ini dapat memberikan manfaat dan membantu
seluruh Sivitas Akademika Politeknik Telkom dalam memahami dan
mengikuti materi perkuliahan di Politeknik Telkom.
Amin.

Wassalamualaikum Wr. Wb.

Bandung, Oktober 2009




Christanto Triwibisono
Wakil Direktur I
Bidang Akademik & Pengembangan
Telkom Polytechnic Jaminan Mutu Sistem Informasi


iv
PAGE 10

Daftar Isi
Kata Pengantar................................................................................iii
Daftar Isi .......................................................................................... iv
Daftar Gambar ................................................................................ vi
1 Testing in Software Development Life Cycle ........................... 1
1.1 Perjalanan Software Engineering .................................................................. 2
1.2 SDLC pada Waterfall Model ......................................................................... 4
1.3 Quality Assurance pada Information System .............................................. 8
1.4 Jenis-jenis Pengujian Perangkat Lunak ..................................................... 18
2 Black box Testing ...................................................................30
2.1 Definisi ............................................................................................................ 31
2.2 Equivalence class Testing ............................................................................... 33
2.3 Boundary value Testing .................................................................................. 42
2.4 Use Case Testing .......................................................................................... 46
3 White Box Testing ..................................................................56
3.1 Definisi ............................................................................................................ 57
3.2 Basis Path Testing ........................................................................................... 60
3.3 Flow Graph Notation ...................................................................................... 61
3.4 Cyclomatic complexity .................................................................................... 66
3.5 Kasus Uji (Test Case) ..................................................................................... 68
4 Acceptance Testing (Functional & User Acceptance Test) .....76
4.1 Testing Process................................................................................................ 77
4.2 Test Planning ................................................................................................... 78
4.3 Testing Strategis ............................................................................................ 79
4.4 Failure & Faults ............................................................................................... 80
4.5 Acceptance Testing ......................................................................................... 81
4.6 System Acceptance Test ............................................................................... 82
4.7 Best Practice Testing ...................................................................................... 85
4.8 Foundational .................................................................................................... 86
1. Instructions for the User Acceptance Tester ..............................87
1.1 New System and Regression Testing Instructions ............................................. 87
1.2 Form-Based Testing Procedures.......................................................................... 87
1.3 Business Process Testing Procedures.................................................................. 88
1.4 Report Testing Procedures .................................................................................. 88
1.5 Defect Reporting .................................................................................................. 89
2. Form-Based Testing ....................................................................90
2.1 List of Modules to be Reviewed for Form-Based Testing ................................. 90
Politeknik Telkom Jaminan Mutu Sistem Informasi


v
PAGE 10
2.2 Form-Based Test Script ....................................................................................... 90
3. User Security Matrix ....................................................................92
4. User Acceptance Business Process Test Scripts ...........................92
4.1 Sample- Main Menu ............................................................................................ 92
4.2 Sample: CRS1050 Update Exam Scenario ................................................. 93
5. Report Test Script .......................................................................94
5.1 Sample- Detailed Information Report .....................................94
6. Defect Tracking Form ...............................................................96
7. Defect Tracking Log...................................................................97
5 Uji Integrasi ..........................................................................98
5.1 Uji Integrasi ................................................................................................... 99
5.2 Pendekatan Big bang .................................................................................... 99
5.3 Pendekatan Incremental ............................................................................ 100
5.4 Uji integrasi dalam Konteks OO ........................................................... 106
5.5 Uji Arsitektur Client/Server ...................................................................... 107
5.6 Uji Navigasi, uji integrasi untuk aplikasi Web ..................................... 108
6 CVS .....................................................................................114
6.1 Overview ....................................................................................................... 115
6.2 Repository ..................................................................................................... 116
6.3 Men-Setup File ............................................................................................ 122
6.4 Mendefinisikan modul ............................................................................. 124
6.5 Revision ......................................................................................................... 124
6.6 Add, remove, dan renaming file dan direktori ....................................... 126
6.7 Multiple Developers .................................................................................... 134
6.8 Revision Management ................................................................................. 134
7 Robot Data Entry ...............................................................139
7.1 Pendahuluan ............................................................................................... 140
7.2 Pengenalan iMacros .................................................................................. 140
7.3 Kegunaan iMacros ..................................................................................... 142
7.4 Contoh penggunaan iMacros untuk browser automation. .................. 146
Daftar Pustaka ..............................................................................153



Telkom Polytechnic Jaminan Mutu Sistem Informasi


vi
PAGE 10

Daftar Gambar

Gambar 1-1 Roket Ariane 5 Meledak ........................................................................ 3
Gambar 1-2 Model Waterfall ....................................................................................... 5
Gambar 2-1Continuous equivalence classes ............................................................... 38
Gambar 2-2 Discrete equivalence classes ................................................................... 38
Gambar 2-3 Single selection equivalence classes ....................................................... 39
Gambar 2-4 Multiple selection equivalence class....................................................... 40
Gambar 2-5 Boundary values for a continuous range of inputs. ............................ 44
Gambar 2-6 Boundary values for a discrete range of inputs................................... 45
Gambar 3-1 Ilustrasi alur logika ................................................................................... 59
Gambar 3-2 Lingkaran/Node ........................................................................................ 61
Gambar 3-3 Panah/Edge/Link ....................................................................................... 61
Gambar 3-4 ..................................................................................................................... 62
Gambar 3-5 ..................................................................................................................... 62
Gambar 3-6 ..................................................................................................................... 62
Gambar 3-7 Predicate node .......................................................................................... 63
Gambar 3-8 ..................................................................................................................... 63
Gambar 3-9 Flow graph bonus_count .......................................................................... 64
Gambar 3-10 While ....................................................................................................... 65
Gambar 3-11 Until ......................................................................................................... 65
Gambar 3-12 Region ...................................................................................................... 65
Gambar 3-13 Contoh independent paths .................................................................... 67
Gambar 4-1 Proses Testing ......................................................................................... 77
Gambar 4-2 Tahapan Testing dalam Model Proses -V .......................................... 79
Gambar 4-3 Acceptance Process ................................................................................. 81
Gambar 5-1Integrasi Top down pola Depth First .................................................. 100
Gambar 5-2 Integrasi Top down pola Breadth First .............................................. 101
Gambar 5-3 Integrasi Bottom up ............................................................................. 103
Gambar 5-4 Diagram kolaborasi class perlu untuk Uji Integrasi OO ............ 107




Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 1
PAGE 10
1 Testing in Software Development Life Cycle








Overview

Testing atau pengujian merupakan bagian dari tahapan Software Development
Life Cycle (SDLC). SDLC merupakan siklus yang menggambarkan bagaimana
perangkat lunak dibangun. Berbagai macam perangkat lunak termasuk
didalamnya Sistem Informasi yang berbasis komputer(Computer Based
Information System) dibangun dengan pendekatan metodologi yang sudah
terdefinisi di SDLC yang kemdian menjadi model pengembangan perangkat
lunak. Waterfall model merupakan model yang paling awal dan mengilhami
berbagai model lain. Pada model ini, pengujian menjadi tahapan yang harus
dilakukan setelah sebuah perangkat lunak selesai dibangun. Namun demikian,
untuk membangun perangkat luank yang berkualitas, pengujian harus
dilakukan di semua tahapan.

Pada buku ini konsentrasi pengujian perangkat lunak akan dilakukan pada
tahapan Testing dengan berbagai macam pendekatan yang sering digunakan
dalam industri pengembangan perangkat lunak khususnya di berbagai software
house. Pengujian pada tahapan testing masih menjadi isu khusus bagi para
pengembang perangkat lunak khususnya dalam proyek pengadaan perangkat
lunak di Indonesia.


Tujuan

1. Mahasiswa memahami pentingnya Software Engineering.
2. Mahasiswa memahami tahapan SDLC waterfall model.
3. Mahasiswa memahami posisi Quality Assurance dalam SDLC.
4. Mahasiswa mengetahui Softrware Testing secara umum.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


2 Testing in SDLC
1.1 Perjalanan Software Engineering
Rekayasa perangkat lunak telah berkembang sejak pertama kali diperkenalkan
pada tahun 1940-an. Fokus utamanya adalah mengembangkan praktik dan
teknologi untuk meningkatkan produktivitas para praktisi pengembang
perangkat lunak serta kualitas aplikasi yang digunakan oleh pemakai.

Istilah rekayasa perangkat lunak (software engineering) digunakan pertama kali
pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat perdebatan
tajammengenai aspek engineering dari pengembangan perangkat lunak. Pada
tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi
tentang rekayasa perangkat lunak yang memberikan dampak kuat terhadap
perkembangan rekayasa perangkat lunak. Banyak yang menganggap bahwa dua
konferensi inilah yang menandai secara resmi awal berkembangnya rekayasa
perangkat lunak.

Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan oleh
para praktisi pengembangan perangkat lunak. Banyak proyek yang mengalami
kegagalan sehingga masa ini disebut sebagai krisis perangkat lunak. Kasus
kegagalan pengembangan perangkat lunak yang terjadi bermacam-macam
bentuknya sehingga banyak terjadi kasus proyek yang melebihi anggaran dan
mundurnya waktu dari kesepakatan antara pengembang dan pemesan
perangkat lunak. Dimensi anggaran (budget) dan waku pengerjaan proyek
(duration time) merupakan dimensi yang sangat fundamental pada proyek
apapun.

Selain kegagalan yang menyangkut biaya dan waktu, terjadi pula kegagakan
yang berefek pada kerusakan fisik dan kematian. Salah satu kasus yang
terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat
lunak.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 3
PAGE 10


Gambar 1-1 Roket Ariane 5 Meledak
Roket Ariane 5 meledak diidentifikasi sebagai akibat kegagalan perangkat
lunak. Kegagalan terjadi saat dilakukan konversi dari bilangan floating point 64-
bit ke bilangan integer 16-bit. Bilangan floating point memiliki nilai yang sangat
besar melebihi nilai yang dapat direpresentasikan oleh bilangan integer
bertanda (signed integer) 16-bit. Akibatnya terjadi overflow software exeption.

Pesan penting dari kejadian itu adalah : Pengujian, pengujian, pengujian!
Video selengkapnya lihat di:
http://www.youtube.com/watch?v=kYUrqdUyEpI
atau gunakan keyword ariane 5 explosion
Sumber selengkapnya baca di :
http://www.niwotridge.com/Resources/Ariane5Resources/ariane5.pdf
http://www.niwotridge.com/Resources/Ariane5Resources/78890339.pdf
http://www.niwotridge.com/Resources/Ariane5Resources/esa-x-1819eng.pdf
link-link tersebut dapat dilihat di:
http://www.niwotridge.com/Resources/DomainLinks/Ariane5Failure.htm



Telkom Polytechnic Jaminan Mutu Sistem Informasi


4 Testing in SDLC
1.2 SDLC pada Waterfall Model
Pada saat ini terdapat banyak sekali metodologi dalam pembangunan
perangkat lunak. Salah satu yang sudah lama dikenal adalah model waterfall.
Model ini menggambarkan pembangunan perangkat lunak seperti aliran air
terjun, mulai analysis requirement sebagai awal proses sampai dengan
deployment dan maintenance di akhir proses. Model waterfall dalam
perkembangannya telah mengalami perubahan dan mengilhami model-model
baru lain.

Model Waterfall berisi rangkaian aktivitas proses seperti pada gambar. Setiap
tahapan disajikan dalam proses yang terpisah secara ketat, seperti spesifikasi
kebutuhan, desain, implementasi perangkat lunak, uji coba, dan seterusnya.
Walaupun langkah mundur ke tahapan sebelumnya masih dimungkinkan,
namun pada dasarnya tahapan ini tidak menghendaki adanya langkah mundur.
Setelah sebuah langkah didefinisikan, langkah tersebut di sign off dan
pengembangan dilanjutkan pada langkah berikutnya.

Model ini adalah model klasik yang bersifat sistematis dan berurutan dalam
membangun perangkat lunak. Sifat yang sistematis dan berurutan ini terilhami
dari proses manufaktur yang semua prosesnya sudah deterministik. Proses
dalam manufaktur tidak selamanya cocok digunakan pada rekayasa perangkat
lunak. Oleh karena itu, modifikasi terhadap model ini perlu dilakukan untuk
mendapatkan model yang optimal.

Secara umum dalam pembangunan perangkat lunak pada waterfall model
terdapat tahapan-tahapan sebagai berikut:

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 5
PAGE 10

























Gambar 1-2 Model Waterfall

1.2.1 Analisis Kebutuhan
Pada tahapan ini dilakukan pengumpulan semua kebutuhan user yang
berkaitan dengan perangkat lunak yang dibangun. Peran analis pada tahapan
ini sangat besar karena ia menjadi penjembatan antara keinginan user yang
dinyatakan dalam bahasa praktis dengan programmer yang cenderung
menggunakan bahasa teknis. Analis harus mampu melihat konsekuensi dari
suatu kebutuhan user yang akan menjadi kebutuhan turunanannya. Semua
kebutuhan tersebut, baik yang utama maupun yang turunan, harus dinyatakan
secara eksplisit dalam dokumen tertulis yang kemudian menjadi dokumen
kesepakatan antara kedua belah pihak.

Analisis
Kebutuhan
Desain
Pembuatan
Kode
Pengujian
Implemen-
tasi
Perawatan
Telkom Polytechnic Jaminan Mutu Sistem Informasi


6 Testing in SDLC
1.2.2 Desain
Desain perangkat lunak merupakan tahapan untuk menterjemahkan
keinginan user menjadi desain teknis yang siap diimplementasikan oleh
programmer. Desainer perangkat lunak harus mampu membuat dokumen
teknis yang mengandung empat atribut sebuah program yaitu struktur data,
arsitektur perangkat lunak, representasi antar muka, dan algoritma.

1.2.3 Pembuatan Kode Program (Coding)
Desain perangkat lunak harus diterjemahkan ke dalam aplikasi yang
siap digunakan oleh user. Untuk menterjemahkan desain menjadi program
aplikasi, diperlukan compiler atau interpreter melalui bahasa pemrograman
tertentu.
Pada tahapan Coding, programmer bekerja berdasarkan dokumen
desain yang telah dibuat oleh desainer pada tahapan sebelumnya dan
menterjemahkan kedalam bahasa pemrograman.
Setiap bahasa pemrograman memiliki kelebihan dan kekurangan
masing-masing. Kekurangan bahasa pemrograman sering digunakan sebagai
sarana untuk dijadikan sebagai lubang keamanan. Oleh karena itu, pemilihan
bahasa pemrograman merupakan salah satu fokus dalam membuatan
perangkat lunak yang aman.

1.2.4 Pengujian
Pengujian terhadap program dilaksanakan setelah sebuah program
aplikasi selesai dibuat. Proses pengujian dimulai dari kebenaran logika
perangkat lunak, kemudian dipastikan bahwa di setiap aktivitas perangkat
lunak terdapat skenario pengujiannya. Testing harus diarahakan untuk
menemukan kesalahan-kesalahan dan memastikan bahwa input yang
dimasukkan akan memberikan hasil yang sesuai, sebagaimana yang
direncanakan di dalam dokumentasi desain.

1.2.5 Implementasi
Perangkat lunak yang telah lolos uji diimplementasi ditempat
pemesan dengan disertai perangkat pendukungknya. Perangkat pendukung ini
tidak hanya hardware komputer, namun juga dukungan kebijakan, prosedur,
pelatihan penggunaan, dan sebagainya.

1.2.6 Perawatan
Perangkat lunak yang telah diimplementasi diharapkan dapat dipakai
terus menerus dan tidak berhenti di tengah jalan. Agar dapat dipergunakan
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 7
PAGE 10
terus meneruh perangkat lunak harus dipelihara dengan memperhatikan
beberapa aspek di antaranya:
1. Mampu mengangani perkembangan data karena seiring berjalannya
waktu.
Data transaksional akan bertambah seiring berjalannya waktu.
Sebuah aplikasi harus dapat menangani pertumbuhan data ini dengan
beberapa cara baik dengan pengarsipan maupun penambahan media
penyimpan. Apabila aplikasi tidak dapat menangani hal ini, maka pada
titik tertentu aplikasi akan tidak dapat dipergunakan lagi.

Kasus nyata:

Sebuah Klien dari perusahaan BUMN mengkomplain sebuah aplikasi
portal yang telah dipesannya dari sebuah perusahaan pengembang
perangkat lunak. Isi komplain dari perushaan BUMN tersebut adalah
adanya kejadian dimana semua user portal tidak bisa login. Perusahaan
pengembang portal kemudian memeriksa kembali source code login dan
mengklaim bahwa tidak ada yang salah dengan source code tersebut.
Setelah diinvestigasi ternyata kejadian tersebut adalah akibat dari space
hardisk server portal yang sudah penuh. Setiap login, aplikasi protal
mengupdate log file dan mencatat aktifitas user. Karena space hard disk
penuh, proses pembukaan file log gagal, dan berakibat user tidak dapat
login


2. Mampu menangani ancaman kerusakan oleh virus atau program
penyusup lainya.
Agar aplikasi yang diimplementasikan berjalan normal, harus
dilindungi dari serangan virus yang akan merusak maupun
memperlambat kerja aplikasi.
3. Mampu menangani perbaikan apabila ditemukan error atau bug pada
aplikasi yang sedang dijalankan.
Seringkali bug baru ditemukan setelah pengunaan aplikasi beberapa
saat lamanya, misalnya kegagalan upload file dikarenakan kapaistas
penyimpan telah penuh. Bug bug ini mungkin tidak ditemukan saat
pengujian. Bug kegagalan upload file tidak terdeteksi oleh penguji
perangkat lunak dikarenakan komputer testing yang digunakan
memilki space yang besar saat pengujian dilakukan.
4. Mampu menangani penambahan fitur baru.
Seiring berjalannya waktu, sangat mungkin dibuthkan fitur-fitur baru
yang sebelumnya tidak terfikirkan. Misalnya fitur pengarsipan, fitur
Telkom Polytechnic Jaminan Mutu Sistem Informasi


8 Testing in SDLC
searching, paging, categorizing, baru terasa diperlukan pada saat data
yang disimpan telah mencapai jumlah yang banyak. Fitur-fitur baru ini
harus dapat diakomodir agar perangkat lunak yang ada tetap dapat
digunakan dengan baik. Kemampuan penambahan fitur ini sangat
ditentukan oleh desain arsitektur perangkat lunak yang dibangun.
5. Mampu menangani perkembangan dan kemajuan teknologi.
Perangakat lunak yang dibangun harus mampu beradaptasi dengan
perkembagan teknologi. Perubahan dan perkembangan sistem antar
muka, prosesor, struktur dan arsitektur dari aplikasi lain yang
berhubungan, harus dapat diakomodasi agar pernagkat lunak yang
lama dapat berkembang.

1.3 Quality Assurance pada Information System
Information System pada pembahasan buku adalah Computer Based
Information System (CBIS). Pada CBIS Software menjadi bagian yang penting
dan menjadi ciri khas dari CBIS itu sendiri. Oleh karenanya pembahasan pada
buku ini dibatasi pada Software Quality Assurance.
Pada software quality assurance, setiap tahapan pada SDLC memiliki
mekanisme untuk memastikan bahwa setiap tahapan dilalui dengan benar.
Artinya, Software Qualtiy assurance berada pada pada semua tahapan SDLC.


Software Assurance: The planned and systematic set of activities that ensures
that software life cycle processes and products conform to requirements, standards,
and procedures. For NASA, this includes the disciplines of: software quality
(comprised of the functions of software quality engineering, software quality
assurance and software quality control); software safety; software reliability;
software verification and validation; and software independent verification and
validation.

Software Quality: The discipline of software quality is a planned and systematic
set of activities to ensure quality is built into the software. It consists of software
quality assurance, software quality control, and software quality engineering. As an
attribute, software quality is:
(1) the degree to which a system, component, or process meets specified
requirements.
(2) The degree to which a system, component, or process meets customer or user
needs or expectations
[IEEE 610.12 IEEE Standard Glossary of Software Engineering Terminology].
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 9
PAGE 10

Software Quality Assurance: The function of software quality that assures that
the standards, processes, and procedures are appropriate for the project and are
correctly implemented.

Software Quality Control: The function of software quality that checks that the
project follows its standards, processes, and procedures, and that the project
produces the required internal and external (deliverable) products.

Source: http://www.hq.nasa.gov/office/codeq/software/umbrella_defs.htm


Pada setiap tahapan SDLC ada suatu pengendalian kualitas yang apabila
secara integral dilakukan akan menjadi kesatuan jaminan kualitas dari software
yang dibangun.
1.3.1 Pada Tahap Analisis Kebutuhan
- Apakah Client sudah memahami dengan baik apa yang dia butuhkan.
- Apakah desain yang dibuat oleh System Analist sudah mengkover semua
yang diinginkan?

Sebuah unit kerja di lembaga pendidikan meminta dibuatkan sistem informasi
penjadwalan kerja praktek berbasis web pada pihak pengembang perangkat
lunak. Pada dokumen spesifikasi kebutuhan perangkat lunak tertera hal-hal
berikut ini:
Admin kerja praktek dapat melakukan:
1. input lokasi lokasi kerja praktek untuk setiap permintaan kerja praktek
dari mahasiswa.
2. Mengubah lokasi kerja praktek dari permintaan setiap mahasiswa jika
diperlukan
3. Menghapus data permohonan kerja praktek

Implementasi dari permintaan tersebut adalah:
http://akademik/kerjapraktek/admin/index.php

berisi menu login untuk admin. Apabila login berhasil maka akan masuk ke
halaman web dengan URL:

http://akademik/kerjapraktek/admin/admin.php

Telkom Polytechnic Jaminan Mutu Sistem Informasi


10 Testing in SDLC
pada halalaman ini semua pekerjaan admin dapat dilakukan sesuai dengan
permintaan. Karena pendeknya waktu pengerjaan, dan diperparah dengan
keahlian dari programmer yang masih kurang, maka URL tersebut tidak
dilindungi dengan session, hanya perupa file php biasa. Seorang mahasiswa
sempat melihat URL tersebut saat melakukan komplain mengenai lokasi kerja
prakteknya. Mahasiswa tersebut mencoba memasukkan URL dari tempat lain
langsung ke halaman tersebut. Akibatnya, mahasiswa tersebut dapat
mengubah sendiri lokasi kerja prakteknya dan tidak perlu repot-repot
komplain ke bagian adminstrator. Informasi hal tersebut berkembang dengan
cepat ke seluruh mahasiswa. Banyak mahasiswa langsung mengubah lokasi
kerja praktek sendiri tanpa melalui admin.

Setelah berjalan sekian lama, hampir satu semester, akhirnya hal tersebut
diketahui oleh wakil rektor bidang kemahasiswaan. Komplain pun dilayangkan
kepada pihak pengembang perangkat lunak. Namun pihak pengembang
berkelit bahwa yang dilalukan tidak melanggar dokumen permintaan.
Beberapa hal disampaiakan oleh pihak pengembang diantaranya:
- Tidak ada penjelasan mengenai larangan mahasiwa tidak boleh login
sebagai admin
- tidak ada kesepakatan untuk dilakukannya perbaikan terhadap error
dikemudian hari
- dan yang paling jelas adalah:

Admin tetap dapat melakukan pekerjaanya!


Pada kasus di atas, client gagal medeskripsikan keinginannya, demikian
juga system analist juga gagal memahami kebutuhan client-nya. Desainer harus
mampu menerjemahkan keinginan yang tidak tereksplisitkan. Implementasi
login dengan session sudah menjadi hal yang sangat lumrah dan seharusnya
menjadi sense bagi desainer aplikasi tersebut.

1.3.2 Pada Tahap Desain
- Apakah Desainer sudah benar menggambarakan seluruh kebutuhan
Client?
- Apakah Desain yang dibuat cukup jelas dan detil untuk
diimplementasikan dalam source code dam basis data secara tepat tanpa
multi tafsir?

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 11
PAGE 10
Sebuah desain yang sama sangat mungkin menghasilkan implementasi yang
berbeda, apabila desain tersebut masih terlalu global. Sebagai contoh, desain
halaman login. Apabila hanya dideskripsikan desain sebuah halaman login
untuk masuk ke aplikasi, maka akan banyak pertanyaan dan selanjutnya akan
menjadi asusmsi bagi programmer untuk mengimplementasikannya, sebagai
contoh:
- Perlukah image pendukung pada halaman login? Jika diperlukan image
yang seperti apa?
- Perlukan video flash pada halaman login? Jika diperlukan apa isi dari
video flash tersebut?
- Perlukah pengecekan dilakukan dengan teknologi tertentu, misalnya
Ajax?

1.3.3 Pada Tahap Pembuatan Kode Program
- Apakah programmer sudah mengimplemtnasikan desain secara benar?
- Apakah implementasi yang digunakan sudah menggunkan tool yang
optimal?
- Apakah dalam implementasi desain ke sumber kode program,
programmer sudah mengindahkan kaidah-kaidah yang benar?
Pada pembuatan kode sumber program ada beberapa hal yang dapat
dievaluasi untuk menentukan kualitasnya:
1. Readable
2. Bugfree
3. Modular
4. Sesuai dengan waktu dan budget
5. Dapat dikembangkan lebih lanjut
6. Dapat di pelihar perkembangannya
7. Diimplementasikan berdasarkan desain yang jelas
Penjelasan dari ketujuh dimensi tersebut adalah:
Readable artinya orang lain dapat membaca dan memahami dengan
mudah kode yang dibuat. Kemudahan ini dapat dilihat dari:
1. Tersedia cukup komentar
2. Mengikuti konvensi yang digunakan, berkaitan dengan penamaan
variabel
3. Indentasi yang sama untuk kode yang memiliki derajat yang sama.

Readability bermanfaat untuk masa yang akan datang, bukan pada saat
pembuatan kode.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


12 Testing in SDLC
Bug Free artinya aplikasi bebas dari kesalahan (dalam batasan tertentu),
dan menangani keterbatasan dan kesalahan proses pada level aplikasi,
bukan oleh sistem. Pesan kesalahan tidak boleh dari sistem (yang biasanya
sulit dimengerti oleh user)
Modular berarti fungsi, prosedur, (atau sebutan lain yang memiliki
karakteristik fungsi/prosedur) dan kumpulan keduanya berkumpul
berdasar kategori tertentu.
Delivered on time and within budget berarti ketepatan waktu dan
biaya dalam mengimplementasikan program. Dimensi paling mendasar
pada sebuah proyek adalah batasan waktu dan biaya. Batasan yang lain
merupakan turunan dari dua batasan tersebut.
Expandable artinya source code dapat dikembangkan lebih lanjut untuk
ditambahkan fitur-fitur baru tanpa melakukan perombakan besar-besaran.
Program yang terlalu spesifik dan tidak dapat menangani perkembangan
kebutuhan akan menyebabka keusangan yang pada akhirnya tidak
digunakan lagi.
Maintanable Artinya source code dapat dirawat dan dipantau
perkembagannya. Selain source code dapat dikembangkan lebih lanjut,
perkembangan source code harus dapat dipantau perkembangannya dari
waktu ke waktu.
Ketujuh dimensi di atas akan sangat menentukan kualitas kode yang telah
dibuat oleh programmer.

1.3.4 Pada Tahap Pengujian Program
Pengujian dilakukan untuk mendapatkan error dari program yang sudah dibuat.
Pada pengujian terdapat beberapa kaidah untuk mendapatkan pengujian yang
baik [Roger Pressman]

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 13
PAGE 10
1. Pengujian yang baik memiliki peluang yang besar untuk mendapatkan
error.
Seorang dosen meminta para mahasiswanya untuk menguji sebuah
program dengan 5 data uji untuk bilangan yang akan ditampilkan
deret fibbonaci-nya. Program tersebut akan menampilkan output
berikut:

Seorang mahasiswa kemudian membuat data uji untuk bilangan yang
dimasukkan berturut turut adalah : 1,2,4,6,7

Bagaimana pendapat Anda mengenai data uji yang diberikan oleh
mahasiswa tersebut?


Telkom Polytechnic Jaminan Mutu Sistem Informasi


14 Testing in SDLC
2. Pengujian yang baik tidak dilakukan secara redundan.

Lihat kembali kasus pada no 1. Seorang mahasiswa yang lain
mencoba membuat data uji sebagai berikut: -2,-1,0,1,2

- Bagaimana pendapat Anda mengenai data uji tersebut?
- Adakah nilai bilangan yang redundan?
- Jika bilangan dikelompokkan berdasar himpunan berikut:
Z
+
: Himpunan integer positif
Z
-
: Himpunan integer negatif
0 : Himpunan bilangan nol
Adakah kategori bilangan yang rendundan pada data uji
tersebut? Jelaskan!

Catatan: Redundansi dalam nilai relatif jarang terjadi, tetapi
redundansi dalam kategori lebih sering terjadi.

3. Pengujian yang baik akan memilih data terbaik

Lihat kembali kasus pada no 1. Seorang mahasiswa yang lainnya
membuat data uji dengan alasan pemilihannya berturut turut sebagai
berikut:
-32769 : Out of range dari batas bawah integer 16 bit
-32768 : Nilai terkecil integer 16 bit
0 : batas nilai dilekeluarkan exeption
32.767 : Batas atas integer 16 bit
32.768 : Lewat dari batas atas integer 16 bit
Mahasiswa tersebut menggunakan ilustrasi range integer 16 bit
sebagai berikut:




-32768 0 32.767

Bagaimana pendapat Anda mengenai data uji yang diberikan oleh
mahasiswa tersebut? Bagaimana bila dikaitkan dengan redundansi
kategori?

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 15
PAGE 10
4. Pengujian yang baik tidak terlalu sederhana dan tidak terlalu
kompleks
Lihat kembali kasus no 1. Dosen pun akhirnya memberikan contoh
data uji agar pengujian tidak terlalu banyak, namun mengkover
semaksimal mungkin area pengujian:
Bilangan bulat (integer), output mungkin bisa menghasilkan
error atau exception
-32769 : Out of range dari batas bawah integer
16 bit
-32768 : Nilai terkecil integer 16 bit
0 : batas nilai dilekeluarkan exception
1 : Batas bawah integer dapat dieksekusi
32.767 : Batas atas integer 16 bit
32.768 : Lewat dari batas atas integer 16 bit

Data uji normal untuk bilangan integer yang biasa diujikan
untuk mengamati proses menuju titik error yang mungkin
disebabkan penjumlahan yang mencapai overflow, dapat
dilakukan dengan step dinamis sebagai berikut:
10
20
40
80
Dan seterusnya.
Pada kenyataanya, bilangan fibbonaci akan berkembang
sangat pesat, sehingga batas yang diberikan mahasiswa
tentang bilangan fibonaci sangat tidak realisits.


1 1
2 1
3 2
4 3
... ...
19 4.181
20 6.765
Telkom Polytechnic Jaminan Mutu Sistem Informasi


16 Testing in SDLC
21 10.946
22 17.711
23 28.657
24 46.368
25 75.025

Dengan demikian pendekatan step dinamis lebih
menguntungkan, karena error sudah muncul untuk bilangan
24. Suatu bilangan yang sangat jauh dari 32.767!

Error ini disebabkan karena bilangan fibbonaci yang
terbentuk untuk bilangan 24 sudah melebih kapasitas
integer 16 bit.

Bilangan real, output pasti menghasilkan error atau exception
0.75 : Bilangan real dari nilai pecahan
2.00 : Bilangan bulat dalam notasi real

String, Bilangan real, output pasti menghasilkan error atau
exception
Satu : string murni
3/4 : penulisan bilangan pecahan yang dianggap
String oleh komputer
1o : gabungan antara angka dan karakter
alfabet o



1.3.5 Pada Tahap Implementasi
Seringkali komputer tempat pembuatan aplikasi (sering disebut sebaga
komputer development / devel) berbeda lingkungannya dengan komputer
implementasi. Perbedaan hardware maupun software akan berpengaruh kepada
jalannya aplikasi yang dijalankannya.


Sebuah aplikasi desktop baru saja diinstal disebuah komputer user. Anehnya
aplikasi tersebut berhasil saat intalasi dan tidak ada alert kegagalan apapun,
namun saat aplikasi dijalankan, muncul pesan error dari system.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 17
PAGE 10

User tersebut kemudian komplain ke vendor software tersebut. Akhirnya
diketahui bahwa file mpr.dll yang berada direktori
C:\windows\system32 dikomputer user berbeda dengan file mpr.dll di
komputer tempat pengembangan. Solusinya dengan mengganti file mpr.dll
tersebut dengan file dengan nama yang sama dari komputer pengembang.

Beberapa hari kemudian diketahui ada aplikasi di komputer user yang tidak
jalan. Ternyata aplikasi tersebut memerlukan file mpr.dll yang orsinil dari
komputer user yang telah ada sebelumnya. Kedua belah pihak sama sama
bingung tentang hal ini


1.3.6 Pada Tahap Perawatan
Untuk mempertahan kinerja perangkat lunak diperlukan perawatan terhadap
perangka lunak tersebut. Dengan pemeliharaan, perangkat lunak dapat
dipertahankan penggunaanya, dan dipertahakankan atau bahkan ditingkatkan
performansinya.

Studi Kasus

Pada tahun 1998 hingga 1999 berbagai produk perangkat lunak yang telah
diimplementasikan di berbagai bidang (transportasi, perbankan, kesehatan,
pertahanan, penyiaran, dan sebagainya diuji kehandalannya untuk dapat
bertahan dengan isu yang berkembang pada waktu itu yaitu Y2K (Year 2 Kilo,
tahun 2000).

Isu Y2K berangkat dari pembangunan perangkat lunak yang digunakan
diberbagai bidang tersebut.

Kebanyakan perangkat lunak dibangun dari tahun 60-an. Berbagai macam
program menggunakan representasi data tanggal dengan menyimpan data
tahun sebagai dua digit. Misalnya:
20 Januari 1987 disimpan sebagai 20 01 87
13 Desember 1967 disimpan sebagai 13 12 67

Permasalahan timbul ketika memasuki tahun 2000 dimana penanggalan yang
sebelumnya menunjukkan tanggal 31 Desemeber 1999 (31 12 99) akan
dilanjutkan dengan tanggal 1 Januari 1900 (01 01 00).

Telkom Polytechnic Jaminan Mutu Sistem Informasi


18 Testing in SDLC
Banyak pihak akan meramalkan terjadi bencana besar yang akan memakan
korban jiwa apabila instalasi perangkatlunak tidak dapat bekerja dengan baik
mengahadapi perubahan tahun tersebut. Instalasi perangkat lunak pada sektor
publik seperti penerbangan, kereta listrik berkecepatan tinggi, kesehatan,
PLTN, dan sebagainya diperkirakan akan mengalami gangguan.

1.3.7 Konsentrasi Perkuliahan ISQA
Dari pembahasan pasal 1.3.1 hingga pasal 1.3.6 dapat diketahui bahwa Quality
Assurance melibatkan semua tahapan di SDLC. Pembahasan Quality Assurance
ini sangat luas, sehingga tidak mungkin diselesaikan hanya dalam satu
semester. Oleh karenanya pembahasa pada kuliah ISQA akan
dikonsentrasikan kepada satu diantara sekian tahapan SDLC yaitu pada
tahapan testing.
1.4 Jenis-jenis Pengujian Perangkat Lunak
Pada pengujian perangkat lunak terdapat berbagai macan pengujian.
Berikut ini akan dibahas beberapa jenis pengujian yang penting yang wajib
diketahui:
1.4.1 Black Box Vs. White Box
Black box testing adalah pengujian yang dilakukan dengan cara mengamati hasil
eksekusi melalui data uji dan memeriksa fungsional dari perangkat lunak.








Sebuah black box. Anda tahu ukurannya, bentuknya, tapi tidak pernah tahu apa
yang ada di dalamnya! Analogi ini mirip dengan pengujian secara black box.
Pengujian black box mengevaluasi perangkat lunak hanya dari tampilan luarnya
saja (interface), fungsionalitasnya, tanpa mengetahui apa yang sesungguhnya
terjadi dalam proses detil yang ada dibalik itu.



Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 19
PAGE 10
Pada whitebox testing, pengujian dilakukan sampai pada level detil dari suatu
perangkat lunak, yaitu source code.






Sebuah kota putih yang jernih. Anda tahu apa saja yang ada di dalamnya dan
melihat dengan jelas bagaimana pengolahan masukan diproses hingga
menghasilkan keluaran.
1.4.2 Factory Acceptance Test vs. User Acceptance Test
Perangkat lunak sebelum diimplementasikan di client /pemesan, harus terlebih
dahulu dilakukan pengujian setelah aplikasi tersebut diselesaikan. Pengujian
dilakukan dengan memeriksa seluruh kebutuhan client dan ditentukan apakah
perangkat lunak yang dibangun layak untuk di implementasi. Pengujian ini
melibatkan pihak pengembang dan pihak client. Pengujian yang melibatkan dua
belah pihak ini sering disebut sebagai uji terima.



Uji terima perangkat lunak yang dilakukan di tempat pengembangan perangkat
lunak disebut Factory Acceptance Test (FAT).



Telkom Polytechnic Jaminan Mutu Sistem Informasi


20 Testing in SDLC
Perangkat lunak yang telah lolos tahap FAT selanjutnya diimplementasikan di
client. Sebelum digunakan perangkat lunak tersebut dilakukan uji terima
kembali di lokasi client.



Uji terima perangkat lunak yang dilakukan di tempat pengguna (User) perangkat
lunak disebut User Acceptance Test (UAT).

1.4.3 Alpha Test Vs. Betha Test
Perangkat lunak yang telah selesai dan siap untuk dilempar ke pasaran harus
diuji terlebih dahulu. Pengujian yang paling baik dilakukan oleh user karena
lebih fair. Namun pada tahap awal user mungkin belum mengerti benar
bagaimana aplikasi yang dibangun dijalankan.


test


Pengujian terhadap perangkat lunak
yang siap untuk dipasarkan dibawah
kendali programmer maupun developer
disebut Apha Test. Perangkat lunak
yang sedang diuji pada tahap ini sering
disebut sebagai Release Alpha


Pada pengujian alpha test, kendali utama berada di developer. Pelaku testernya
sendiri dapat berasal dari user maupun tester khusus.

Apabila hasil pengujian Alpha test dirasa belum memenuhi kebutuhan
spesifikasi perangkat lunak, maka perangkat lunak tersebut dihatan agar tidak
beredar di pasaran. Langkah perbaikan harus ditempuh untuk kasus yang
demikian.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 21
PAGE 10
Setelah pengujian Alpha dirasa cukup meyakinkan maka langkah selanjutnya
adalah mengedarkan perangkat lunak tersebut dipasaran ke calon pengguna
untuk dilakukan pengujian oleh pengguna yang sesungguhnya.

test

Pengujian terhadap perangkat lunak
yang siap untuk dipasarkan dan
dilakukan oleh sebagian user di pasar
tersebut tanpa pengawasan developer
disebut Betha Test. Perangkat lunak
yang sedang diuji pada tahap ini sering
disebut sebagai Release Betha


Stress Test
Stress test merupakan jenis pengujian yang unik. Pengujian uni dilakukan
dengan memberi beban pada perangkat lunak untuk dapat diketahui titik
maksimum performansi perangkat lunak. Stress test sering dilakukan pada
aplikasi yang membutuhkan konkurensi maupun akses acak yang bersamaan
dalam jumlah yang sangat banyak. Aplikasi dengan berbasis web dengan
request yang sangat banyak menjadi contoh yang baik dalam hal ini. Misalkan
server memproses sebuah request dalam waktu 1 detik, suatu waktu yang
sangat tidak mengganggu. Pada percobaan akses tunggal mungkin hal ini tidak
terasa. Namun apabila percobaan dilakukan dengan akses ganda dalam satu
waktu, misalnya 100 request, maka akan dibutuhkan 100 detik, dan ini menjadi
delay kurang dapat diterima. Kejadian delay semakin besar apabila data jumlah
request semakin besar.


Kasus nyata:
Sebuah lembaga pelatihan hendak mengadakan ujian secara online dengan
aplikasi ujian berbasis web. Setiap siswa disediakan sebuah PC untuk
mengakses server (intranet) mellalui browser. Soal ujian akan ditampilkan
dengan terlebih dahulu diberikan verifikasi dan validasi peserta ujian.
Diharapkan dengan pelaksanaan ujian ini, siswa dapat mengetahui hasil ujian
secara real time begitu selesai ujian. Jumlah siswa di lembaga pelatihan ini
totalnya adalah 400 siswa.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


22 Testing in SDLC
Ujian dijadwalkan dari pagi pukul 08.00 hingga pukul 10.00. Ternyata soal yang
diujikan cukup sulit sehingga 90% peserta masih mengerjakan soal hingga
waktu habis. Pada waktu habis, aplikasi secara otomatis men-submit jawaban
dari peserta ujian.

Pada pukul 10.00, terdapat ratusan submit hasil ujian siswa ke server. Diluar
dugaan dan perencanaan ternyata server menghasilkan data anomali yang tidak
masuk akal. Nama dan nomor induk peserta ujian menjadi tidak konsisten
saat ditampilkan di hasil ujian, sehingga sangat mungkin hasil ujian pun juga
tertukar.


Stress menjadi isu pengujian yang sering muncul pada aplikasi web mengingat
aplikasi ini memunkinkan adanya aksi request yang bersamaan.

Untuk melakukan pengujian stress test menjadi ilmu yang unik. Jika kita hendak
melakukan pengujian dengan 400 request bersamaan, terlalu berlebihan
kiranya jika kita harus menyediakan 400 komputer, kemudian kita bersepakat
dengan 400 oran guntuk mengklik suatu request secara bersama. Pada
keadaan tersebut tidak ada jaminan bahwa 400 orang tersebut akan
melakukan request secara bersamaan.

Untuk menjembatani pengujian stresss test tersebut saat ini telah berkembang
berbagai tool untuk mendukung pengujian ini. Melalui tool simulasi ini
dimungkinkan dibuat request 400 oleh sebuah mesin komputer saja. Salah satu
tool yang digunakan dalam stress test ini adalah Web Stress Test Tool yang
dikeluarkan oleh Paessler. Detil tentang tools ini dapat dibaca di
http://www.paessler.com/webstress/download.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 23
PAGE 10

Web Stress Test Tool memungkinkan kita melakukan simulasi stess test melalui
parameter-parameter tertentu
Telkom Polytechnic Jaminan Mutu Sistem Informasi


24 Testing in SDLC


Tools mampu memvisualisasi request mana yang sedang dilakukan beserta
hasilnya apakah berhasil atau gagal

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 25
PAGE 10



Rangkuman



1. SDLC terdiri dari tahapan-tahapan : Analisis kebutuhan, Desain, Coding,
Testing, Implementasi, Maintenance
2. Quality Assurance berada pada semua tahapan SDLC, bukan hanya pada
tahapan testing saja
3. Pengujian black box mengevaluasi perangkat lunak hanya dari tampilan
luarnya saja (interface), fungsionalitasnya, tanpa mengetahui apa yang
sesungguhnya terjadi dalam proses detil yang ada dibalik itu.
4. Pada whitebox testing, pengujian dilakukan sampai pada level detil dari
suatu perangkat lunak, yaitu source code.
5. Uji terima perangkat lunak yang dilakukan di tempat pengembangan
perangkat lunak disebut Factory Acceptance Test (FAT).
6. Uji terima perangkat lunak yang dilakukan di tempat pengguna (User)
perangkat lunak disebut User Acceptance Test (UAT).
7. Pengujian terhadap perangkat lunak yang siap untuk dipasarkan dibawah
kendali programmer maupun developer disebut Apha Test
8. Pengujian terhadap perangkat lunak yang siap untuk dipasarkan dan
dilakukan oleh sebagian user di pasar tersebut tanpa pengawasan
developer disebut Betha Test.
9. Stress test merupakan pengujian dengan memberi beban pada perangkat
lunak untuk dapat diketahui titik maksimum performansi perangkat lunak.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


26 Testing in SDLC




Pilihan Ganda



Petunjuk: Pilihlah jawaban yang paling tepat!

1.

Tahapan paling awal pada Software Development Life Cycle adalah
_____________
A. Testing D. Analisis Kebutuhan
B. Desain E. Analisis Pengujian
C. Implementasi

2.

Tahapan setelah Coding pada Software Development Life Cycle adalah
_____________
A. Maintenance D. Testing
B. Implementasi E. Design
C. Redesign

3.

Pendefinisian field-filed tabel yang diperlukan, menentukan field fiel
primary, berada pada tahapan ___________
A. Testing D. Analisis Kebutuhan
B. Desain E. Analisis Pengujian
C. Implementasi

4.

Pembuatan gambaran umum bisnis proses pada program melalui tampilan
antar muka, berada pada tahaman ________
A. Testing D. Analisis Kebutuhan
B. Desain E. Analisis Pengujian
C. Implementasi

5. Class Diagram berada pada tahapan ________
A. Testing D. Analisis Kebutuhan
B. Desain E. Maintenance
C. Implementasi
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 27
PAGE 10

6

Pengujian terhadap produk yang siap dipasarkan dengan kontrol oleh pihak
pengembang disebut ______
A. Alpha Testing D. UAT
B. Betha Testing E. Stress Test
C. Unit Testing

7

Pengujian terhadap produk yang siap dipasarkan oleh user yang akan
menjadi pengguna secara nyata dikemudian hari disebut ______
A Alpha Testing D. Regression Testing
B Betha Testing E. Stress Test
C FAT

8

Pengujian perangkat lunak oleh pengguna melalui mekanisme uji terima
proyek perangkat lunak disebut ________
A Black box Testing D. UAT
B White box Testing E. Stress Test
C FAT

9 Pengujian perangkat lunak melalui mekanisme uji terima proyek perangkat
lunak disebut yang diselenggarakan sesaat setelah perangkat lunak selesai
dikembangkan di pihak pengembang disebut ________
A Alpha Testing D. UAT
B Betha Testing E. Stress Test
C FAT

10


Pengujian dengan cara melakukan request ke web server dalam jumlah
besar pada saat bersamaan, merupakan pengujian perwujudan dari
________
A Alpha Testing D. Integration Testing
B Betha Testing E. Stress Test
C Unit Testing

10



Sebuah Analisis Pengujian dilakukan dengan cara mengamati hasil eksekusi
suatu script di browser dengan memasukkan input data kedalam aplikasi
tersebut. Hasil pemrosesan data akan ditampilkan setelah button SUBMIT
di klik. Jenis testing yang paling dekat dengan hal ini adalah ________
Telkom Polytechnic Jaminan Mutu Sistem Informasi


28 Testing in SDLC
A Stress Testing D. Alpha Testing
B White box Testing E. Betha Test
C Black box Testing

11



Sebuah Analisis Pengujian dilakukan dengan cara mengevaluasi source code
sehingga tampak analisis source code dengan membentuk lintasan source
code. Jenis testing yang paling dekat dengan cara pengujian ini adalah
________
A Stress Testing D. Alpha Testing
B White box Testing E. Betha Test
C Black box Testing

12


Hardianti baru saja menginstall windows 7 versi Betha resmi dikeluarkan
oleh Microsoft. Pernyataan beriktu ini yang benar tentang informasi ini
adalah ________
A Hardianti telah menginstall windows 7 yang sudah bug free
B Hardianti telah membeli windows 7
C Beberapa bulan lagi Hardianti akan mendapatkan windows 7 versi Alpha
D

Hardianti melakukan pengujian windows 7 langsung dipandu oleh pihak
Microsoft
E

Hardianti diminta Micorsoft untuk memberi masukan tentang penggunaan
windows 7

13





Dari pernyataan berikut ini:
1. Versi Alpha cenderung lebih baik dari versi Betha
2. Versi Alpha beredar bebas di pasaran.
3. Versi Betha dijual secara komersial
4. Versi Betha beredar bebas di pasaran
Pernyataan yang benar adalah ________
A 1,2,3 D. 4 saja
B 1,3 E. 1,2,3,4
C 2,4

14




Dari pernyataan berikut ini:
1. UAT dilaksanakan setelah FAT
2. UAT merupakan uji terima perangkat lunak
3. FAT diselenggarakan di tempat pengembangan perangkat lunak
4. FAT termasuk uji terima perangkat lunak
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Testing in SDLC 29
PAGE 10
Pernyataan yang benar adalah ________
A 1,2,3 D. 4 saja
B 1,3 E. 1,2,3,4
C 2,4
15






Dari pernyataan berikut ini:
1. Black box testing memperhatikan source code baris demi baris
2. Black box testing mengevaluasi hasil eksekusi program
3. White box testing mengevaluasi hasil eksekusi program melalui
tampilah interfacenya
4. White box juga memperhatikan source code program
Pernyataan yang benar adalah ________
A 1,2,3 D. 4 saja
B 1,3 E. 1,2,3,4
C 2,4




Latihan


1. Sebutkan tahapan SDLC waterfall model!
2. Ditahap manakah ISQA berada?
3. Apa yang dimaksud dengan SQA?
4. Apa perbedaan utama antara Black box dengan White box testing?
5. Apa perbedaan utama antara Alpha Testing dan Betha Testing?
6. Apa perbedaan utama antara UAT dan FAT?
7. Apa yang dimaksud dengan stress test?
8. Cobalah membuat data test yang sederhana dari tampilan berikut ini.











e-mail Address

Mobile Phone Number

Telkom Polytechnic Jaminan Mutu Sistem Informasi


30 Black Box Testing

2 Black box Testing
















Overview

Pada bab ini akan dibahas mengenai metode pengujian yaitu black box testing.
Berbeda dengan white box testing, Black box testing merupakan stategi testing
dimana hanya memperhatikan/memfokuskan kepada faktor fungsionalitas
dan spesifikasi perangkat lunak. Terdapat beberapa metode black box testing
antara lain adalah Equivalence class Testing, Boundary value Testing, dan Use
Case Testing.



Tujuan

1. Mahasiswa mengerti definisi black box testing.
2. Mahasiswa mengerti dan memahami kelebihan dan kelemahan black box
testing.
3. Mahasiswa mengerti, memahami, dan mengimplementasikan teknik-
teknik black box testing.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 31
PAGE 10
2.1 Definisi

Black box testing merupakan stategi testing dimana hanya
memperhatikan/memfokuskan kepada faktor fungsionalitas dan spesifikasi
perangkat lunak. Berbeda dengan white box, black box testing tidak
membutuhkan pengetahuan mengenai, alur internal (internal path), struktur
atau implementasi dari software under test (SUT). Tidak seperti white box
testing yang dilakukan pada awal proses pengujian, black box testing dilakukan
dibeberapa tahapan berikutnya. Karena black box testing memang ditujukan
untuk mengabaikan struktur kontrol tetapi lebih terfokus terhadap
information domain. Pengujian dirancang untuk menjawab beberapa pertanyaan
sebagai berikut:

1. Bagaimana validitas fungsionalnya diuji?
2. Bagaimana perilaku sistem dan performansi diuji?
3. Jenis input seperti apa yang akan menghasilkan kasus uji yang baik ?
4. Apakah sistem secara khusus sensitif terhadap nilai input tertentu ?
5. Bagaimana batasan-batasan kelas data diisolasi?
6. Berapa rasio data dan jumlah data yang dapat ditoleransi oleh
sistem?
7. Apa akibat yang akan timbul dari kombinasi spesifik data pada
operasi sistem?

Secara umum proses-proses yang ada pada black box testing adalah sebagai
berikut:
Menganalisis kebutuhan dan spesifikasi dari perangkat lunak.
Pemilihan jenis input yang memungkinkan menghasilkan output benar
serta jenis input yang memungkinkan output salah pada perangkat
lunak yang sedang diuji.
Menentukan output untuk suatu jenis input.
Pengujian dilakukan dengan input-input yang telah benar-benar
diseleksi.
Melakukan pengujian.
Pembandingan output yang dihasilkan dengan output yang diharapkan.
Menentukan fungsionalitas yang seharusnya ada pada perangkat lunak
yang sedang diuji.


Telkom Polytechnic Jaminan Mutu Sistem Informasi


32 Black Box Testing
Black box testing dapat dilakukan pada setiap level pembangunan sistem. Mulai
dari unit, integration, system, dan acceptance.

Sebagaimana terlihat pada gambar diatas bahwa ketika kita berpindah dari
modul menjadi subsistem atau subsistem menjadi sistem, dan lain sebagainya
maka input dan output akan menjadi semakin kompleks. Meskipun demikian
pendekatan yang sama dapat dilakukan yaitu dengan melakukan pendekatan
pengujian black box.

Keunggulan Black box Testing
Meskipun dalam pelaksanaan testing kita dapat menguji keseluruhan
fungsionalitas perangkat lunak namun formal black box testing yang sebenarnya
kita dapat memilih subset test yang secara efektif dan efisien dapat
menemukan cacat. Dengan cara ini black box testing dapat membantu
memaksimalkan testing investment.

Kelemahan Black box Testing
Ketika tester melakukan black box testing, tester tidak akan pernah yakin
apakah perangkat lunak yang diuji telah benar-benar lolos pengujian. Hal ini
terjadi karena kemungkinan masih ada beberapa jalur eksekusi yang belum
pernah diuji oleh tester. Untuk menemukan cacat perangkat lunak
menggunakan black box testing, tester seharusnya membuat setiap
kemungkinan kombinasi data input baik yang valid maupun tidak valid.
Sebenarnya kita juga dapat hanya mengambil himpunan (subset) dari suatu
kombinasi data input untuk pengujian. Hal ini dilakukan untuk memingkatkan
efektifitas dan efisiensi pengujian perangkat lunak. Glenford Myers dalam
bukunya The Art of Software Testing memberikan contoh pengujian yang gagal.
Dia memberikan contoh mengenai pengujian terhadap compiler dengan
melakukan penulisan setiap kemungkinan program yang ditulis tersebut benar
atau salah. Masalah yang sangat substansial disini adalah sistem harus
mengingat/ menyimpan apa yang telah terjadi sebelumnya (mengingat state
yang telah dilalui oleh sistem tersebut). Dalam sistem ini tester tidak hanya
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 33
PAGE 10
menguji setiap input yang mungkin tatapi tester juga harus menguji setiap
sekuen/ urutan dari setiap input yang mungkin.
2.2 Equivalence class Testing

Merupakan teknik yang digunakan untuk mengurangi jumlah test case yang
ada pada saat pengujian. Kebanyakan tester menggunakan teknik yang
simpel ini meskipun secara formal tester tersebut tidak mengetahui
mengenai metode desain formal dalam pengujian perangkat lunak.
Kasus uji yang didesain untuk Equivalence class testing berdasarkan pada
evaluasi dari ekuivalensi jenis/class untuk kondisi input. Class-class yang
ekuivalen merepresentasikan sekumpulan keadaan valid dan invalid untuk
kondisi input. Biasanya kondisi input dapat berupa spesifikasi nilai
numerik, kisaran nilai, kumpulan nilai yang berhubungan atau kondisi
boolean.
Sebagai contoh misalkan kita diberikan kasus mengenai sebuah modul
untuk sistem Human Resource Development (HRD) untuk penerimaan
pegawai baru berdasarkan usia. Dengan rule/ aturan sebagai berikut:
016 Don't hire
1618 Can hire on a part-time basis only
1855 Can hire as a full-time employee
5599 Don't hire[*]

Berdasarkan kasus yang diberikan ini seharusnya kita menguji modul tersebut
dengan data uji usia dengan nilai 0, 1, 2, 3, 4, 5, 6, 7, 8, ..., 90, 91, 92, 93, 94,
95, 96, 97, 98, 99. Hal ini mungkin dilakukan jika kita memiliki banyak waktu
luang dan memiliki sisa energi yang cukup. Contoh berikut ini adalah contoh
yang simple untuk mengimplementasikan rule diatas.
If (applicantAge == 0) hireStatus="NO";
If (applicantAge == 1) hireStatus="NO";

If (applicantAge == 14) hireStatus="NO";
If (applicantAge == 15) hireStatus="NO";
If (applicantAge == 16) hireStatus="PART";
If (applicantAge == 17) hireStatus="PART";
If (applicantAge == 18) hireStatus="FULL";
Telkom Polytechnic Jaminan Mutu Sistem Informasi


34 Black Box Testing
If (applicantAge == 19) hireStatus="FULL";

If (applicantAge == 53) hireStatus="FULL";
If (applicantAge == 54) hireStatus="FULL";
If (applicantAge == 55) hireStatus="NO";
If (applicantAge == 56) hireStatus="NO";

If (applicantAge == 98) hireStatus="NO";
If (applicantAge == 99) hireStatus="NO";
Dengan melihat contoh tersebut maka pengujian yang seharusnya dilakukan
adalah dengan menguji semua kondisi yang ada pada modul tersebut. Namun
demikian implementasi rule tersebut tidak dilakukan dengan cara diatas,
namun dengan cara seperti ini:
If (applicantAge >= 0 && applicantAge <=16)
hireStatus="NO";
If (applicantAge >= 16 && applicantAge <=18)
hireStatus="PART";
If (applicantAge >= 18 && applicantAge <=55)
hireStatus="FULL";
If (applicantAge >= 55 && applicantAge <=99)
hireStatus="NO";
Dengan melakukan implementasi dengan cara tersebut maka dalam pengujian
kita tidak perlu untuk menguji nilai-nilai , misalkan 0, 1, 2, ... 14, 15, dan 16
tetapi kita hanya membutuhkan satu nilai untuk melakukan pengujian.
Masalahnya nilai mana yang dapat mewakili semua nilai yang ada dalam suatu
range? Range nilai yang diwakili oleh suatu nilai tertentu yang dijelaskan disini
disebut sebagai equivalence classes. Equivalence class terdiri dari kumpulan
data yang diperlakukan sama oleh sistem atau menghasilkan output yang sama.
Setiap nilai data dalam sebuah class adalah equivalent, secara spesifik kita
berharap bahwa:
Jika satu test case dalam equivalence class mendeteksi cacat, semua
test case yang lain dalam equivalence class yang sama kemungkinan
akan mendeteksi cacat yang sama.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 35
PAGE 10
Jaka satu test case dalam equivalence class tidak mendeteksi adanya
cacat, maka test case yang lain dalam equivalence class yang sama
masih ada kemungkinan untuk mendeteksi cacat.
Dari penjelasan tadi mungkin kita bertanya apakah berarti pendekatan ini
menggunakan asumsi? Jawabannya tentu saja adalah iya. Selain itu kita tentu
saja juga berasumsi bahwa programmer tidak melakukan hal-hal aneh seperti
contoh berikut ini:
If (applicantAge >= 0 && applicantAge <=16)
hireStatus="NO";
If (applicantAge >= 16 && applicantAge <=18)
hireStatus="PART";
If (applicantAge >= 18 && applicantAge <=41)
hireStatus="FULL";
// strange statements follow
If (applicantAge == 42 && applicantName == "Lee")
hireStatus="HIRE NOW AT HUGE SALARY";
If (applicantAge == 42 && applicantName <> "Lee")
hireStatus="FULL";
// end of strange statements

If (applicantAge >= 43 && applicantAge <=55)
hireStatus="FULL";
If (applicantAge >= 55 && applicantAge <=99)
hireStatus="NO";
Dengan menggunakan pendekatan equivalence class, kita dapat mengurangi
jumlah test case pada studi kasus diatas dari 100 test case (menguji tiap-tiap
usia yang mungkin) menjadi empat test case saja (testing) hal ini merupakan
penghematan yang sangat signifikan.
Sekarang kita akan mencoba untuk melakukan pengujian. Bagaimana jika nilai
inputnya adalah 969, 142, FRED, dan, &$#!@ ? dari inputan tersebut
seharusnya itu adalah test case untuk invalid input. Tetapi jawabannya adalah
tergantung. Untuk memahami jawaban tersebut maka kita perlu untuk
mengetahui suatu istilah dalam dunia object oriented yang disebut dengan
design-by-contract. Istilah contract dalam bidang hukum adalah ikatan yang
bersifat legal antara dua atau lebih pihak yang dideskripsikan dalam janji-janji
yang berasal dari pihak-pihak terkait untuk melakukan atau tidak melakukan
Telkom Polytechnic Jaminan Mutu Sistem Informasi


36 Black Box Testing
sesuatu. Setiap janji tersebut tentu saja memberikan benefit bagi masing-
masing pihak.
Dalam pendekatan design-by-contract, modul (dalam paradigma object
oriented disebut dengan method) mendefinisikan istilah pre-condition dan post-
condition. Post-condition mendefinisikan hal-hal apa saja yang akan dilakukan
oleh suatu modul seperti melakukan komputasi terhadap sebuah nilai,
membuka file, mencetak laporan, meng-update record database, mengubah
state sistem, dan lain-lain. Pre-condition mendefinisikan apa yang dibutuhkan
oleh suatu modul untuk dapat mencapai post-condition. Sebagai contoh sebuah
modul yang bertujuan untuk membuka file. Pertanyaannya hal-hal apa yang
menjadi pre-condition untuk membuka file. Yang pertama tentu saja file yang
akan dibuka harus ada, yang kedua kita harus mendefiniskan nama file yang
akan kita buka, ketiga file tersebut harus dapat dibuka, keempat kita harus
memiliki hak akses yang mencukupi untuk membuka file tersebut. Pre-condition
dan post-condition membentuk kontrak antara suatu modul dengan modul
yang lain yang memanggil modul tersebut.
Testing-by-contract didasarkan pada design-by-contract. Pendekatan itu
membuat test case hanya untuk situasi dimana pre-condition telah benar-benar
terpenuhi. Sebagai contoh kita tidak akan melakukan pengujian terhadap
modul openFile ketika file tidak ada. Alasannya sangat mudah, jika file yang
akan dibuka tidak ada, modul openFile tidak akan pernah bisa
bekerja/berfungsi. Jika tidak ada pernyataan bahwa modul tersebut dapat
bekerja dalam kondisi yang spesifik maka tidak diperlukan adanya pengujian
untuk kondisi tersebut. Pada poin ini tentu saja tester akan melakukan protes
bahwa tester setuju bahwa modul tersebut tidak akan bekerja dalam kasus
tersebut tetapi bagaimana jika pre-condition tersebut dilanggar? Apa yang
dilakukan oleh sistem?
Pendetakan yang berbeda dalam desain adalah defensive-design. Dalam kasus
ini modul didesain untuk menerima suatu input. Jika pre-condition yang normal
telah tepenuhi maka modul akan mencapai post-conditon yang normal pula.
Namun jika pre-condition yang normal tidak terpenuhi maka modul tersebut
akan memberi tahu dengan mengembalikan suatu error code atau melempar
suatu eksepsi (tergantung kepada bahasa pemrograman yang digunakan).
Pemberitahuan ini merupakan salah satu jenis post-condition yang lain dari
suatu modul. Berdasarkan kepada pendekatan ini kita dapat mendefinisikan
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 37
PAGE 10
defensive testing adalah pendekatan yang menguji pre-condition yang normal
maupun yang tidak normal.
Bagaimana jika hal ini diterapkan pada equivalence class testing? Kita telah
memiliki data input -42, FRED, and &$#!@. Jika kita menggunakan pendekatan
design-by-contract dan testing-by-contract maka inputan tersebut dapat dianggap
tidak valid, namun jika kita menggunakan defensive design dan defensive
testing maka inputan tersebut dapat dianggap valid.
Teknik
1. Identifikasi kelas-kelas yang ekuivalen (equivalence class).
2. Buat test case untuk tiap-tiap equivalence class.
3. Jika memungkinkan buat test case tambahan yang acak yang
memungkinkan ditemukannya cacat pada perangkat lunak.
Perbedaan jenis input membutuhkan jenis equivalence class yang berbeda pula.
Disini kita akan mengambil asumsi bahwa pendekatan yang digunakan adalah
defensive testing yang memperhitungkan baik input yang valid mapupun invalid.
Pengujian terhadap input yang invalid biasanya merupakan sumber dari
ditemukannya cacat pada perangkat lunak.
Jika input yang digunakan adalah range kontinu, maka secara umum terdapat
satu kelas untuk nilai yang valid dan dua kelas untuk nilai yang invalid, yang
satu berada dibawah nilai valid dan yang satu diatas nilai valid.
Misalkan terdapat sebuah sistem untuk perusahaan yang bergerak dalam
bidang hipotik hanya akan menerima orang yang memiliki penghasilan antara
$1,000/month and $83,333/month. Jika penghasilan $1,000/month maka
orang tersebut tidak masuk kualifikasi dan jika penghasilannya diatas
$83,333/month maka seharusnya orang tersebut dapat melakukan
pembayaran secara tunai. Untuk input valid kita dapat memilih $1,342/month.
Untuk invalid input $123/month dan $90,000/month.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


38 Black Box Testing

Gambar 2-1Continuous equivalence classes
Jika kondisi input merupakan nilai diskrit dengan range nilai tertentu yang
diperbolehkan. Misalkan perusahan hipotik tersebut dengan pertimbangan
tertentu hanya akan menerima satu sampai dengan lima rumah yang
dihipotekkan. Inputan yang bernilai nol , enam atau lebih merupakan inputan
yang invalid. Begitupun dengan nilai-nilai pecahan seperti 2 1/2 atau 3.14159.


Gambar 2-2 Discrete equivalence classes
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 39
PAGE 10
Misalkan perusahaan tersebut hanya akan menerima hipotik dari personal
bukan dari perusahaan, partnership, perserikatan, ataupun bentuk lain dari
entitas legal yang ada.

Gambar 2-3 Single selection equivalence classes
Untuk memilih input yang valid maka pilihannya hanya ada satu yaitu person.
Sedangkan untuk input yang invalid kita dapat menggunakan "corporation" atau
"trust" ataupun string lain yang kita pilih secara acak.
Misalkan perusahan hipotek tersebut hanya menerima jenis-jenis tempat
tinggal berupa Condominiums, Townhouse, dan Single Family. Mereka tidak akan
menerima jenis-jenis tempat tinggal berupa duplexes, mobile homes,
treehouses,dll.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


40 Black Box Testing

Gambar 2-4 Multiple selection equivalence class
Sangat jarang tester untuk melakukan pengujian secara parsial untuk setiap
equivalence class untuk setiap nilai input yang dimasukkan kedalam sistem.
Tester lebih sering membuat test case yang menguji beberapa inputan secara
simultan/ sekaligus. Sebagai contoh kita membuat single test case dengan
kombinasi input:
Tabel 1. Test case untuk data input valid
Pendapatan
Perbulan
J umlah
tempat
tinggal
Pengaju J enis tempat
tinggal
Hasil
$5,000 2 Person Condominimum Valid
Masing-masing nilai data berada dalam range yang valid, sehingga diharapkan
sistem akan merespon dengan hal yang benar. Untuk data input yang invalid
kita dapat menggunakan kombinasi data input berikut ini:


Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 41
PAGE 10
Pendapatan
Perbulan
Perbulan
Jumlah
tempat
tinggal
Pengaju Jenis tempat
tinggal
Hasil
$100 8 Partnership Treehouse Invalid
Jika sistem menerima inputan atau menyatakan bahwa inputan tersebut benar
maka dapat dinyatakan sistem tidak melakukan validasi terhadap inputan
secara benar. Namun jika sistem menolak inputan tersebut dan menyatakan
inputan tersebut invalid maka muncul masalah yang lain, kemungkinan tester
tidak dapat mengetahui data mana yang salah karena mungkin sistem hanya
menampilkan pesan sebagai berikut:
ERROR: 653X-2.7 INVALID INPUT
Dalam banyak kasus, error dalam satu field input kemungkinan dapat
membatalkan atau menganggap error field yang lain. Pendekatan yang lebih
baik adalah menguji nilai-nilai invalid pada satu waktu secara berurutan untuk
memverifikasi apakah sistem mendeteksi inputan tersebut secara benar.
Pendapatan
Perbulan
Jumlah
tempat
tinggal
Pengaju Jenis tempat
tinggal
Hasil
$100 1 Person Single Family Invalid
$1,342 0 Person Condominium Invalid
$5,432 3 Corporation Townhouse Invalid
$10,000 2 Person Treehouse Invalid
Pendekatan yang lain dalam menggunakan equivalence classes untuk memeriksa
output dari pada memeriksa input. Bagilah output kedalam equivalence classes,
kemudian tentukan nilai input yang akan menghasilkan output tersebut.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


42 Black Box Testing
2.3 Boundary value Testing
Equivalence class testing merupakan teknik desain testing yang paling dasar. Itu
membantu tester untuk memilih subset yang kecil untuk membuat test case
yang mungkin. Equivalence class testing juga memiliki keuntungan yaitu
memandu kita untuk membuat boundary value testing yang akan kita pelajari
pada bab ini. Pada bahasan yang lalu rule/ aturan usia yang diberikan adalah
sebagai berikut:
016 Don't hire
1618 Can hire on a part-time basis only
1855 Can hire as a full-time employee
5599 Don't hire
Sebagai catatan masalah dalam suatu boundary/ batas adalah edge untuk tiap-
tiap kelas. Usia 16 tahun masuk kedalam dua equivalent class yang berbeda.
Rule yang pertama mengatakan bahwa jangan menerima calon pegawai yang
masih berumur 16 taun. Rule yang kedua mengatakan bahwa calon pegawai
yang berumur 16 tahun dapat diterima sebagai tenaga kerja paruh waktu.
Boundary value testing focus terhadap batasan-batasan yang simple karena
disitulah kebanyakan cacat pada perangkat lunak tersembunyi. Tester yang
berpengalaman telah mempertimbangkan situasi ini sejak lama. Sedangkan
tester yang kurang berpengalaman mungkin juga memiliki intuisi untuk
mengetahui masalah cacat yang tersembunyi pada boundary. Cacat ini bisa
terdapat dalam requirement yang ditunjukkan diatas maupun pada code yang
ditunjukkan sebagai berikut:
If (applicantAge >= 0 && applicantAge <=16)
hireStatus="NO";
If (applicantAge >= 16 && applicantAge <=18)
hireStatus="PART";
If (applicantAge >= 18 && applicantAge <=55)
hireStatus="FULL";
If (applicantAge >= 55 && applicantAge <=99)
hireStatus="NO";
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 43
PAGE 10
dapat terlihat bahwa kesalahan dilakukan oleh programmer ketika membuat
program tersebut menimbulkan masalah dengan menuliskan > (lebih besar)
serta (lebih besar sama dengan) pada contoh diatas.
Mungkin saja maksud dari organisasi tersebut adalah:
015 Don't hire
1617 Can hire on a part-time basis only
1854 Can hire as full-time employees
5599 Don't hire
Bagaimana jika nilai usia adalah -3 dan 101? Harus diperhatikan bahwa
requirement tidak menspesifikasikan nilai-nilai tersebut. Kita dapat menebak
(menebak requirement) tidak mengkondisikan nilai tersebut. Code yang
mengimplementasikan rule tersebut adalah:
If (applicantAge >= 0 && applicantAge <=15)
hireStatus="NO";
If (applicantAge >= 16 && applicantAge <=17)
hireStatus="PART";
If (applicantAge >= 18 && applicantAge <=54)
hireStatus="FULL";
If (applicantAge >= 55 && applicantAge <=99)
hireStatus="NO";

nilai-nilai yang menarik pada kasus ini adalah nilai-nilai yang ada pada boundary
sebagai contoh {-1, 0, 1}, {15, 16, 17}, {17, 18, 19}, {54, 55, 56}, and {98, 99,
100}. Nilai yang lain seperti {-42, 1001, FRED, %$#@} mungkin disertakan
juga pada pre-condition modul tersebut.
Boundary value testing mengarahkan pada pemilihan kasus uji yang melatih
nilai-nilai batas. boundary value testing merupakan desain teknik kasus uji yang
melengkapi Equivalence class testing. Dari pada memfokuskan hanya pada
kondisi input, boundary value testing juga menghasilkan kasus uji dari domain
output.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


44 Black Box Testing
Langkah-langkah boundary value testing adalah
1. Identifikasi kelas-kelas yang ekuivalen (equivalence class).
2. Identifikasi batasan untuk tiap equivalence class.
3. Buat test case untuk tiap batasan suatu nilai dengan memilih titik pada
batasan, satu titik pada nilai bawah batasan dan satu titik pada nilai atas
batasan.
Sebagai contoh boundary value pada nilai kontinu:

Gambar 2-5 Boundary values for a continuous range of inputs.
Tes data input untuk batas bawah adalah {$999, $1,000, $1,001} dan untuk
batas atas {$83,332, $83,333, $83,334}.
Sebagai contoh boundary value pada nilai diskrit:

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 45
PAGE 10

Gambar 2-6 Boundary values for a discrete range of inputs.

Tes data input untuk batas bawah adalah {0, 1, 2} dan untuk batas atas {4, 5,
6}.

Dalam melakukan pengujian pendekatan yang baik adalah melakukan
kombinasi nilai data uji baik data uji yang valid maupun invalid:
Pendapatan Perbulan Jumlah
Hasil Deskripsi
$1,000 1 Valid Min income, min dwellings
$83,333 1 Valid Max income, min dwellings
$1,000 5 Valid Min income, max dwellings
$83,333 5 Valid Max income, max dwellings
$1,000 0 Invalid Min income, below min dwellings
$1,000 6 Invalid Min income, above max dwellings
$83,333 0 Invalid Max income, below min dwellings
$83,333 6 Invalid Max income, above max dwellings
$999 1 Invalid Below min income, min dwellings
$83,334 1 Invalid Above max income, min dwellings
$999 5 Invalid Below min income, max dwellings
$83,334 5 Invalid Above max income, max dwellings


Telkom Polytechnic Jaminan Mutu Sistem Informasi


46 Black Box Testing
2.4 Use Case Testing
Mendefinisikan transaksi pada proses-proses yang ada pada suatu sistem
adalah hal yang sangat penting untuk dilakukan pada proses pendefinisian
kebutuhan sistem (requirements definition).
Terdapat banyak pendekatan untuk mendokumentasikan transaksi-transaksi
tersebut seperti flowchart, HIPO diagram, dan teks. Sekarang pendekatan
yang paling populer dilakukan adalah dengan menggunakan use case diagram.
Use case biasanya dibuat oleh developer dan untuk developer, namun demikian
dalam pengujian perangkat lunak, informasi yang ada pada use case sangat
berguna bagi tester. Contoh use case:

Pada use biasanya terdapat symbol yang menggambarkan actor, bentuk elips
mendefinisikan use case, dan tanda panah menunjukkan actor menginisiasi
suatu use case. Dalam pengembangan berbasis object oriented use case
merupakan elemen yang sangat penting dalam mendefinisikan kebutuhan
fungsional, lebih dari itu use case juga dapat digunakan dalam paradigma yang
lain secara baik.
Fungsi dari use case
Menggambarkan functional requirement dari sebuah sistem dari
perspektif pengguna bukan dari perspektif teknik dan mengabaikan
paradigma pengembangan yang digunakan.
Dapat digunakan untuk proses identifikasi kebutuhan pengguna.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 47
PAGE 10
Menyediakan dasar untuk komponen internal sistem, struktur,
database, dan keterhubungan.
Menyediakan dasar dalam membangun test case dalam sistem dan
acceptance level.

Contoh deskripsi use case:
Example use case.
Use Case Component Description
Use Case Number or
Identifier
SIM153
Use Case Name Registrasi
Goal in Context
Scope System
Level Primary task
Primary Actor Mahasiswa
Preconditions None
Success End
Conditions
Mahasiswa terdaftar dalam kelas untuk
matakuliah(kelas diajar oleh dosen)
Failed End Conditions Daftar matakuliah mahasiswa yang diambil
oleh mahasiswa tidak bisa berubah
Trigger Mahasiswa memilih matakuliah dan
mengambil matakuliah tersebut.
Main Success Scenario
A: Actor
Step Action
1 S: menampilkan daftar kelas yang
Telkom Polytechnic Jaminan Mutu Sistem Informasi


48 Black Box Testing
S: System dibuka
2 A: Memilih kelas dan menambahkan
kelas
3 S: melakukan filter terhadap SKS dan
Kuota
4
Extensions 2a Mahasiswa telah selesai melakukan
semua proses registrasi
S: Mencegah mahasiswa mengulang
registrasi dan menampilkan pesan
4a Matakuliah yang diambil memiliki
pre-requisite
S: Mencegah mahasiswa mengambil
matakuliah tersebut jika belum
mengambil matakuliah pre-requisite
dan menampilkan pesan
4b Kelas yang diambil penuh
S: Mencegah mahasiswa mengambil
kelas tersebut.

Dengan syarat tiap-tiap use case telah benar-benar dipastikan sebelum
implementasi. Untuk menguji suatu use case aturan dasar yang harus
diperhatikan adalah membuat minimal satu test case untuk main success
scenario dan setidaknya satu test case extension pada use case.
Karena use case tidak menspesifikasikan data input, maka tester harus
menentukan data input tersebut. Secara umum teknik-teknik yang telah
dijelaskan sebelumnya seperti the equivalence class and boundary value
techniques.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 49
PAGE 10
Langkah-langkah use case testing:
Sangat penting untuk mempertimbangkan resiko dari transaksi dan
jenis-jenisnya pada saat pengujian. Transaksi-transaksi yang memiliki
resiko rendah diuji dengan intensitas rendah sebaliknya transaksi-
transaksi yang resikonya tinggi harus diuji dengan intensitas yang
tinggi.
Untuk membuat test case, mulailah dengan data yang normal dan
sering digunakan dalam transaksi. Kemudian pilih transaksi-transaksi
yang jarang dilakukan tapi merupakan transaksi yang vital bagi sistem,
misalkan transaksi mematikan sistem,dll.
Pastikan setiap extension pada use case telah diuji. Ujilah dengan
kondisi-kondisi dan sesuatu yang ekstrim serta langgarlah ketentuan-
ketentuan yang diberikanoleh sistem. Jika suatu transaksi memiliki
suatu perulangan/loop, teliti dan cobalah perulangan tersebut
berulang-ulang dan jika terdapat alur yang rumit dalam suatu
transaksi ujilah transaksi tersebut dengan cara yang ekstrim misalkan
uji dengan alur yang tidak seharusnya dilakukan.

Komponen utama dari pengujian suatu transaksi adalah data testing. Boris
Beizer dalam bukunya menyarankan bahwa 30 s/d 40 persen dari pengujian
suatu transaksi adalah generating, capturing, or extracting test data. Dan
jangan dilupakan bahwa kegiatan tersebut juga membutuhkan resouce waktu
dan personel dalam suatu project.

Menguji exceptional condition
Pengujian mengenai alur dari suatu transaksi relatif mudah dilakukan karena
sebagian besar hanya memperhitungkan valid atau tidak validnya data yang
dimasukkan.

Hal yang lebih sulit dilakukan adalah menguji exceptional condition seperti low
memory, disk full, connection lost, driver not loaded, dll. Tester membutuhkan
waktu yang sangat banyak untuk melakukan simulasi tersebut jika dilakukan
secara manual. Untuk itu telah tersedia sebuah tool yang bernama holodeck
yang dibuat oleh James Whittaker dan timnya dari Florida Institute of
Technology. Holodeck melakukan monitor terhadap interaksi antara aplikasi
dan sistem operasi. Holodeck melakukan pencatatan terhadap aktifitas sistem
dan memungkinkan tester untuk melakukan simulasi seperti low memory, disk
full, connection lost, driver not loaded, dll.


Telkom Polytechnic Jaminan Mutu Sistem Informasi


50 Black Box Testing



Rangkuman



1. Black box testing merupakan stategi testing dimana hanya
memperhatikan/memfokuskan kepada faktor fungsionalitas dan spesifikasi
perangkat lunak. Berbeda dengan white box, black box testing tidak
membutuhkan pengetahuan mengenai, alur internal (internal path),
struktur atau implementasi dari software under test (SUT).
2. Black box testing dapat dilakukan pada setiap level pembangunan sistem.
Mulai dari unit, integration, system, dan acceptance.
3. Kasus uji yang didesain untuk Equivalence class testing berdasarkan pada
evaluasi dari ekuivalensi jenis/class untuk kondisi input. Class-class yang
ekuivalen merepresentasikan sekumpulan keadaan valid dan invalid untuk
kondisi input. Biasanya kondisi input dapat berupa spesifikasi nilai
numerik, kisaran nilai, kumpulan nilai yang berhubungan atau kondisi
boolean.
4. BVT mengarahkan pada pemilihan kasus uji yang melatih nilai-nilai batas.
BVT merupakan desain teknik kasus uji yang melengkapi Equivalence class
testing. Dari pada memfokuskan hanya pada kondisi input, BVT juga
menghasilkan kasus uji dari domain output.
5. Mendefinisikan transaksi pada proses-proses yang ada pada suatu sistem
adalah hal yang sangat penting untuk dilakukan pada proses pendefinisian
kebutuhan sistem (requirements definition).








Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 51
PAGE 10



Kuis Benar Salah



1. Black box testing merupakan teknik pengujian yang memeriksa alur logika
dari suatu aplikasi
2. Proses penentuan output untuk suatu jenis input merupakan proses dari
black box testing.
3. Black box testing tidak dapat dilakukan pada setiap level integrasi
perangkat lunak.
4. Kita dapat memilih test case yang bertujuan untuk melakukan testing
dengan lebih efisien.
5. Ketika tester melakukan black box testing, tester tidak akan pernah yakin
apakah perangkat lunak yang diuji telah benar-benar lolos pengujian.







Pilihan Ganda



Petunjuk: Pilihlah jawaban yang paling tepat!

1.

Black box testing tidak membutuhkan hal-hal berikut ini kecuali
_____________
A. internal path D. data input
B. struktur E. benar semua
C. implementasi

2.

Kategori kesalahan yang dapat diuji oleh black box testing adalah
_____________
A.
Fungsi-fungsi yang salah atau
hilang. D. Kesalahan interface.
B. Kesalahan performa. E. benar semua
Telkom Polytechnic Jaminan Mutu Sistem Informasi


52 Black Box Testing
C.
Kesalahan inisialisasi dan
terminasi

3.

Berikut ini adalah proses dari black box testing kecuali
_____________
A.
Pengujian dilakukan dengan
input-input yang telah benar-
benar diseleksi. D.
Menentukan output untuk suatu
jenis input.
B.
Menentukan fungsionalitas
yang seharusnya ada pada
perangkat lunak yang sedang
diuji. E. salah semua
C.
Kesalahan inisialisasi dan
terminasi

4.

Berikut ini adalah ruang lingkup dari black box testing kecuali
_____________
A. unit D. acceptance
B. integration E. salah semua
C. system

5.

Berikut ini adalah ruang lingkup dari black box testing kecuali
_____________
A. unit D. acceptance
B. integration E. salah semua
C. system

6.

Berikut ini adalah langkah-langkah dari equivalence class testing kecuali
_____________
A.
Identifikasi kelas-kelas yang
ekuivalen (equivalence class). D. benar semua
B.
Buat test case untuk tiap-tiap
equivalence class. E. salah semua
C.
Jika memungkinkan buat test
case tambahan yang acak yang
memungkinkan ditemukannya
cacat pada perangkat lunak.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 53
PAGE 10
7.

Berikut ini adalah langkah-langkah dari boundary value testing kecuali
_____________
A.
Identifikasi kelas-kelas yang
ekuivalen (equivalence class). D. benar semua
B.
Identifikasi batasan untuk tiap
equivalence class. E. salah semua
C.
Buat test case untuk tiap
batasan suatu nilai dengan
memilih titik pada batasan,
satu titik pada nilai bawah
batasan dan satu titik pada
nilai atas batasan.

8.
Berikut ini fungsi dari use case kecuali _____________
A.
Menggambarkan functional
requirement dari sebuah
sistem dari perspektif
pengguna bukan dari
perspektif teknik dan
mengabaikan paradigma
pengembangan yang
digunakan. D.
Menyediakan dasar dalam
membangun test case dalam
sistem dan acceptance level.
B.
Dapat digunakan untuk
proses identifikasi kebutuhan
pengguna. E. salah semua
C.
Menyediakan dasar untuk
komponen internal sistem,
struktur, database, dan
keterhubungan.








Telkom Polytechnic Jaminan Mutu Sistem Informasi


54 Black Box Testing


Latihan

1. The following exercises refer to the Stateless University Registration
System Web site. Define the equivalence classes and suitable test cases
for the following:
a. ZIP Codefive numeric digits.
b. Statethe standard Post Office two-character abbreviation for
the states, districts, territories, etc. of the United States.
c. Last Nameone through fifteen characters (including
alphabetic characters, periods, hyphens, apostrophes, spaces,
and numbers).
d. User IDeight characters at least two of which are not
alphabetic (numeric, special, nonprinting).
e. Student IDeight characters. The first two represent the
student's home campus while the last six are a unique six-digit
number. Valid home campus abbreviations are: AN, Annandale;
LC, Las Cruces; RW, Riverside West; SM, San Mateo; TA,
Talbot; WE, Weber; and WN, Wenatchee.
2. The following exercises refer to the Stateless University Registration
System Web. Define the boundaries, and suitable boundary value test
cases for the following:
a. ZIP Codefive numeric digits.
b. First consider ZIP Code just in terms of digits. Then, determine
the lowest and highest legitimate ZIP Codes in the United
States. For extra credit
[1]
, determine the format of postal codes
for Canada and the lowest and highest valid values.
c. Last Nameone through fifteen characters (including
alphabetic characters, periods, hyphens, apostrophes, spaces,
and numbers). For extra credit
[2]
create a few very complex
Last Names. Can you determine the "rules" for legitimate Last
Names? For additional extra credit
[3]
use a phonebook from
another countrytry Finland or Thailand.
d. User IDeight characters at least two of which are not
alphabetic (numeric, special, nonprinting).
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Black Box Testing 55
PAGE 10
e. Course IDthree alpha characters representing the department
followed by a six-digit integer which is the unique course
identification number. The possible departments are:
1. PHY - Physics
2. EGR - Engineering
3. ENG - English
4. LAN - Foreign languages
5. CHM - Chemistry
6. MAT - Mathematics
7. PED - Physical education
8. SOC - Sociology
[1]
There actually is no extra credit, so do it for fun.
[2]
There actually is no extra credit, so do it for fun.
[3]
There actually is no extra credit, so do it for fun.
3. Given the "Register For A Course" use case for the Stateless University
Registration System described previously, create a set of test cases so that the
main success scenario and each of the extensions are tested at least once.
Choose "interesting" test data using the equivalence class and boundary value
techniques.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


56 White Box Testing
PAGE 10
3 White Box Testing














Overview

Perangkat lunak sebagai suatu produk, tentunya harus mengalami uji kualitas
untuk memastikan bahwa produk perangkat lunak tersebut dapat digunakan
dengan baik. Pengujian berdasarkan fungsionalitas saja ternyata belum cukup,
masih perlu ditambahkan pengujian yang lebih teliti dengan meninjau source
code program. Strategi ini disebut sebagai White Box Testing, dengan strategi
ini, dapat dijamin bahwa program yang dibangun memiliki alur logika yang
sempurna.



Tujuan

1. Mahasiswa mengerti definisi white box testing.
2. Mahasiswa mengerti dan memahami kelebihan dan kelemahan white box
testing.
3. Mahasiswa mengerti, memahami, dan mengimplementasikan metoda
white box testing, yaitu basis path testing.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 57
PAGE 10
3.1 Definisi
White box testing merupakan strategi pengujian (testing) yang diterapkan pada
mekanisme internal suatu sistem atau komponen (IEEE, 1990). Strategi ini
digunakan untuk melihat mekanisme internal dari suatu produk perangkat
lunak, khususnya untuk mengamati struktur dan logika kode-kode program
yang ditulis.
Oleh karena strategi ini diterapkan pada bagian dalam suatu sistem atau
komponen, maka strategi ini dijuluki pula sebagai structural testing, logic-driven
testing, atau glass box testing. Strategi ini dapat dilakukan dengan cara meninjau
langsung kode program (source code) yang ditulis dalam membangun
perangkat lunak. Termasuk di dalamnya komponen-komponen berupa fungsi
(function), prosedur (procedure) ataupun modul-modul eksternal yang
digunakan.
Kode-kode program yang dituliskan berfungsi untuk menggambarkan struktur
dan alur logika (logical path) untuk suatu operasi tertentu, sehingga perlu
dilakukan pengujian untuk memastikan bahwa struktur dan alur logika yang
telah dibuat akan menghasilkan suatu nilai yang benar atau valid. Struktur dan
alur logika yang akan diuji menggunakan strategi ini meliputi (Pressman,
2001):
Alur independen yang terdapat pada suatu komponen program,
Keputusan-keputusan logika baik dari sisi yang bernilai benar (true)
maupun salah (false),
Alur pengulangan,
Struktur data internal untuk memastikan kebenaran nilai-nilainya.
Keputusan-keputusan logika dihasilkan dari suatu pengujian kondisi
(conditional testing) yang melibatkan variasi dari sintaks algoritma If Then
seperti:
If Then Else
If Then Else if Then
Case Of
Alur pengulangan digunakan untuk membentuk suatu struktur operasi yang
akan dieksekusi secara berkali-kali dengan jumlah ekseskusi terbatas. Struktur
pengulangan (loop) ini dituliskan dengan variasi sintaks algoritma sebagai
berikut:
While Do
Repeat Until
For To Do
Telkom Polytechnic Jaminan Mutu Sistem Informasi


58 White Box Testing
PAGE 10
3.1.1 Keunggulan White box Testing
White box testing ini digunakan untuk menguji seluruh alur logika, sehingga
kesalahan-kesalahan logika dapat terdeteksi.
Seringkali programmer melakukan kesalahan-kesalahan umum pada saat
membangun perangkat lunak. Keunggulan dari white box testing adalah
kemampuannya untuk mendeteksi kesalahan umum tersebut, yaitu:
Kesalahan logika (logic errors)
Penggunaan struktur logika tidak hanya digunakan pada sintaks pengujian
kondisi if namun juga digunakan pada sintaks pengulangan.
Pada struktur pengulangan, terdapat pengujian kondisi untuk menentukan
kapan proses pengulangan akan berhenti dan menuju ke proses
selanjutnya. Kesalahan yang sering terjadi pada operasi pengulangan
adalah kesalahan dalam menentukan kondisi berhenti, sehingga hasil
operasi akan memberikan nilai yang tidak tepat, mungkin karena kurang
satu kali proses pengulangan atau justru terjadi pengulangan yang terus
menerus (endless loop), sehingga program akan membuat komputer tidak
dapat merespon aksi apapun dari pengguna, atau dengan kata lain
komputer mengalami hang.
Ketidaksesuaian asumsi (incorrect assumptions)
Pada tahap awal pembuatan perangkat lunak, biasanya terlebih dahulu
ditentukan asumsi-asumsi sebagai rambu-rambu untuk menjaga agar alur
logika dan data yang digunakan dapat berjalan dengan baik. Pada
kenyataannya, seringkali kurang tepat dalam menentukan asumsi,
sehingga hasil operasi perangkat lunak akan memberikan nilai yang tidak
tepat pula. Sebagai contoh, dalam satu bulan terdapat 30 (tigapuluh) hari.
Jika asumsi ini digunakan untuk menghitung honor atau gaji karyawan
secara harian, maka jika dilakukan rekap per tahun akan menghasilkan
nilai yang tidak sesuai karena tidak semua bulan memiliki jumlah hari
sebanyak 30.
Kesalahan lain yang juga sering terjadi adalah kesalahan dalam menuliskan
kode program atau sering disebut sebagai salah ketik (typographical
errors). Pada beberapa bahasa pemrograman menganut case-sensitive yaitu
membedakan penulisan antara huruf capital (A,B,C,) dengan huruf
biasa (a,b,c,). Hal ini seringkali menimbulkan masalah pada saat harus
mendeklarasikan struktur data. Dengan white box testing, kesalahan-
kesalahan semacam ini dapat dideteksi, sehingga apabila strategi ini
dijalankan secara penuh atau dengan kata lain dilakukan pada seluruh
source code suatu perangkat lunak, maka akan dihasilkan suatu perangkat
lunak yang sempurna dan benar 100%.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 59
PAGE 10
Syarat yang diperlukan untuk menjalankan strategi white box testing adalah:
Mendefinisikan semua alur logika (logical path)
Membangun kasus untuk digunakan dalam pengujian
Mengevaluasi semua hasil pengujian
Melakukan pengujian secara menyeluruh
3.1.2 Kelemahan White box Testing
Telah disampaikan bahwa white box testing dapat memberikan hasil berupa
perangkat yang sempurna 100%. Hal ini dapat tercapai apabila perangkat lunak
hanya dibangun dengan beberapa baris program saja. Untuk perangkat lunak
yang berskala besar, tentunya tidak dibangun dengan 10 atau 20 baris
program, melainkan dibangun dengan ratusan, ribuan atau bahkan jutaan baris
program. Hal inilah yang membuat white box testing dianggap sebagai strategi
pengujian yang boros, bahkan dianggap tidak mungkin untuk dilakukan karena
akan melibatkan sumber daya yang besar.
Sebagai ilustrasi, jika terdapat sebuah program kecil yang didalamnya terdapat
satu buah loop yang berulang sebanyak 20 kali. Dalam loop tersebut terdapat
sintaks if yang bersarang (nested-if) sebanyak empat tingkat (Gambar 2.1
adalah ilustrasi dari struktur program tersebut).


Gambar 3-1 Ilustrasi alur logika
Telkom Polytechnic Jaminan Mutu Sistem Informasi


60 White Box Testing
PAGE 10
Alur logika yang terdapat pada gambar 2-1 dapat dilihat dengan cara
menghitung banyaknya jalur dari titik a menuju ke titik b. Pada gambar
tersebut terdapat 5 (lima) alur logika, dengan 20 (dua puluh) kali pengulangan,
maka dapat dihitung banyaknya alur logika adalah 5
20
+5
19
+5
18
++5
1
, yaitu
10
14
atau 100 triliun.
Pertanyaan berikutnya adalah, berapa waktu yang dibutuhkan untuk menguji
alur logika sebanyak itu? White box testing mengharuskan pengujian secara
manual yang terdiri dari 3 (tiga) kegiatan untuk setiap alur logika, yakni:
Menulis contoh data uji
Mengeksekusi alur logika dengan data uji yang telah dituliskan
Melakukan verifikasi data hasil eksekusi.
Anggap saja ketiga hal tersebut dapat dilakukan setiap 5 (lima) menit sekali,
maka untuk 100 triliun alur logika dibutuhkan 100 miliar tahun. Jika ketiga hal
tersebut dapat dilakukan dalam waktu 1 detik (300 kali lebih cepat), maka
membutuhkan waktu 3,2 juta tahun, jadi sangat tidak mungkin dilakukan
secara menyeluruh. Oleh karena white box testing memiliki kualitas pengujian
yang baik, maka strategi ini tetap digunakan, namun tidak dilakukan secara
menyeluruh atau hanya dilakukan pada alur-alur logika yang penting saja. Cara
lainnya adalah dengan mengkombinasikannya dengan strategi black box testing.
3.2 Basis Path Testing
Basis path testing merupakan suatu metoda yang digunakan dalam teknik white
box testing. Metoda ini pertama kali diusulkan oleh Tom McCabe [MCC76].
Metoda basis path ini sangat bermanfaat bagi seorang penguji perangkat lunak
dalam menentukan:
Ukuran kompleksitas logika dari suatu struktur program, procedure
atau function.
Menggunakan nilai kompleksitas untuk menentukan basis set
(himpunan dasar) alur logika yang akan dieksekusi.
Dengan metode ini, penguji perangkat lunak dapat menentukan kasus uji yang
diterapkan pada basis set dan menjamin bahwa setiap baris program akan
dieksekusi minimal satu kali.
Metoda basis path testing ini memerlukan masukan berupa source code atau
algoritma dari suatu perangkat lunak. Setelah source code atau algoritma ini
didapatkan, maka langkah-langkah yang dilakukan dalam menjalankan metoda
ini adalah sebagai berikut:
Menggambarkan alur logika menggunakan notasi yang telah
ditentukan. Gambar alur logika ini disebut sebagai flow graph.
Menentukan cyclomatic complexity.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 61
PAGE 10
Menentukan basis set dari alur-alur yang independen.
Membuat data uji untuk kemudian dieksekusi pada setiap alur.
3.3 Flow Graph Notation
Langkah pertama pada metoda basis path adalah menggambarkan alur logika
atau disebut dengan flow graph. Untuk menggambar flow graph terdapat
notasi standar yang terdiri dari 2 (dua) buah notasi, yaitu lingkaran dan panah.
Lingkaran atau flow graph node, digunakan untuk menyatakan satu atau
beberapa statement prosedural yang ada dalam source code atau algoritma.
Panah atau disebut sebagai edge atau link, digunakan untuk menyatakan aliran
kendali atau alur perjalanan logika. Tanda panah pada flow graph ini memiliki
fungsi yang sama dengan tanda panah pada flow chart.


Gambar 3-2 Lingkaran/Node

Gambar 3-3 Panah/Edge/Link
Sebuah node dapat digunakan untuk menggambarkan beberapa baris program
sekaligus selama baris-baris program itu berada pada satu kelompok. Yang
dimaksud dengan satu kelompok adalah baris-baris program dapat dieksekusi
secara berurutan (sekuensial) dan di dalamnya tidak terdapat perubahan
struktur kendali program, misalnya terdapat sintaks kondisional atau
pengulangan. Edge mulai digambarkan apabila terdapat perubahan struktur
kendali program.
3.3.1 Flow graph untuk sintaks kondisional
Dalam sintaks if terdapat suatu pengujian kondisional yang akan
menghasilkan dua buah nilai bertipe boolean, yaitu true atau false. Pada bagian
pengujian kondisional yang diawali dengan if, banyaknya lingkaran yang
digambar tergantung dari banyaknya peubah (variable) yang diuji. Pada
pengujian dengan 2 (dua) variable atau lebih, biasanya menggunakan operator
logika AND atau OR dan disebut sebagai kondisi majemuk (compound).






Telkom Polytechnic Jaminan Mutu Sistem Informasi


62 White Box Testing
PAGE 10
Pengujian satu variable
Public void contoh_1 (int a, int x) {
Baris-1; (1)
Baris-2; (1)
If (a >= 1000) { (2)
Baris-a; (3)
Baris-b; (3)
Baris-...; (3)
} (4)
Baris-3; (4)
Baris-; (4)
}
1
2 3
4

Gambar 3-4

Pengujian dua variable menggunakan AND
Public void contoh_2 (int a, int b) {
Baris-1; (1)
Baris-2; (1)
If (a AND b) { (a=2, b=3)
Baris-3; (4)
Baris-4; (4)
Baris-...; (4)
} (5)
Baris-5; (5)
Baris-; (5)
}
1
2
3
5
4

Gambar 3-5


Pengujian dua variable menggunakan OR

Public void contoh_3 (int a, int b) {
Baris-1; (1)
Baris-2; (1)
If (a OR b) { (a=2, b=3)
Baris-3; (4)
Baris-4; (4)
Baris-...; (4)
} (5)
Baris-5; (5)
Baris-; (5)
}
1
2
4 3
5

Gambar 3-6

Pada kedua contoh di atas, variable yang terlibat dalam kondisi majemuk
(variable a dan b) disebut sebagai predicate node.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 63
PAGE 10

1
2
3
5
4
1
2
4 3
5
Predicate node

Gambar 3-7 Predicate node
Pada sintaks algoritma case atau pada bahasa pemrograman C/C++ disebut
sebagai switch, penggambaran banyaknya lingkaran tergantung dari banyaknya
jumlah kondisi yang diuji. Pada setiap kondisi terdapat kode yang akan
dijalankan jika kondisi tersebut terpenuhi (kode aksi), dalam flow graph setiap
kondisi dan kode aksi dapat digambarkan dalam satu lingkaran, seperti contoh
berikut:

Baris-1; (a)
Switch (a = 1){ (1)
Case cond-1: action-1; (2)
Case cond-2: action-2; (3)

Case cond-n: action-n; (n)
Default: action-default; (n+1)
} (b)
Baris-2; (b)
}
1
2 n 3
b
n+1
a

Gambar 3-8


Telkom Polytechnic Jaminan Mutu Sistem Informasi


64 White Box Testing
PAGE 10
Di bawah ini adalah contoh penggambaran flow graph untuk potongan source
code untuk menghitung bonus karyawan, sebagai berikut:

Public void bonus_count (int a, int b, int x) {
tax = 0;
royalty = 0.01*a;
If (a >= 1000) { //pengujian 1 variable
x = a + (0.75*a);
tax = 0.05 * x;
x = x tax;
}
Else {
x = a + (0.25*a);
tax = 0.05 * x;
x = x tax;
}
x = x royalty;
return x;
}

1
1
2
3
3
3
3
4
4
4
4
5
5
5

1
2 3
4
5

Gambar 3-9 Flow graph bonus_count
3.3.2 Flow graph untuk sintaks pengulangan
Dalam struktur kendali pengulangan (loop) terdapat dua sintaks yang dapat
digunakan, yaitu sintaks while atau until. Pada sintaks algoritma, sintaks while
dipasangkan dengan do, sehingga membentuk whiledo, sedangkan
sintaks until berpasangan dengan sintaks repeat sehingga membentuk
repatuntil. Namun pada bahasa pemrograman Java tidak terdapat sintaks
until, melainkan diganti dengan sintaks dowhile.
Untuk sintaks pengulangan for dapat digambarkan menggunakan notasi flow
graph dengan sintaks while, karena secara umum memiliki struktur logika
yang hampir sama.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 65
PAGE 10
Berikut adalah notasi penggambaran kedua sintaks tersebut dalam flow graph:

2
3
4
1

Gambar 3-10 While
2
3
4
1

Gambar 3-11 Until

3.3.3 Regions
Dalam suatu flow graph, terdapat suatu area yang dibatasi oleh panah-panah
(edges) dan lingkaran (nodes), area itu disebut sebagai region. Banyaknya
region tergantung dari tingkat kompleksitas dari struktur program.
Pada saat menghitung region, area yang berada di luar flow graph termasuk
area yang dihitung sebagai region. Contoh berikut merupakan flow graph
dengan 4 (empat) buah region: R
1
, R
2
, R
3
, R
4
.


Gambar 3-12 Region
Telkom Polytechnic Jaminan Mutu Sistem Informasi


66 White Box Testing
PAGE 10
3.4 Cyclomatic complexity
Cyclomatic complexity merupakan suatu sistem pengukuran untuk perangkat
lunak yang menyediakan ukuran kuantitatif dari kompleksitas logika suatu
program. Pada metode basis path testing, hasil dari penghitungan cyclomatic
complexity digunakan untuk menentukan banyaknya independent paths (alur
bebas).
Independent path adalah jalur yang melintasi minimal satu kumpulan statement
program atau sebuah kondisi pada program dan menghubungkan node awal
(start) dengan node akhir (end). Sebuah independent path minimal melewati
sebuah edge baru (belum pernah dilewati) dan alur tersebut belum pernah
ditemukan (unik).
Cyclomatic complexity pada sebuah dipengaruhi oleh 3 (tiga) hal, yaitu:
Banyaknya edge (panah)
Banyaknya node (lingkaran)
Banyaknya predicate node
Terdapat 2 (dua) persamaan yang digunakan, yaitu:

V(G) = E N + 2 atau V(G) = P + 1

Keterangan:
V(G) : Cyclomatic complexity untuk flow graph G
E : Jumlah edge (panah)
N : Jumlah node (lingkaran)
P : Jumlah predicate node

Independent path yang ditemukan dalam flow graph merupakan basis path
yang mewakili seluruh alur logika. Basis path inilah yang nantinya akan diuji.

Contoh:
Public void tes_cyclomatic(int a, int b, int c){
int total,a;

While a <= 10 { (1)
Count++; (2)
If (b < 10) { (3)
cut = b/100 * c; (4)
cut = cut * -1; (5)
} (6)
Else if (b > 10) { (6)
Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 67
PAGE 10
cut = b/100 * c; (7)
} (8)
Else { (8)
cut = 0; (8)
} (9)
a++; (10)
total = 1000 + cut; (10)
} (11)
}

Program di atas terdapat struktur pengulangan while dan di dalamnya
terdapat struktur kondisional if. Flow graph yang akan dihasilkan tidak akan
terdapat predicate node karena tidak terdapat kondisi majemuk (compound).

Penggambaran flow graph-nya sebagai berikut:



Gambar 3-13 Contoh independent paths

Pada contoh di atas, yang menjadi node awal adalah node nomor 1 dan node
akhir/tujuan adalah node nomor 11. Untuk menentukan banyaknya basis path
yang terdapat dalam flow graph tersebut, terlebih dahulu ditentukan nilai
cyclomatic complexity-nya.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


68 White Box Testing
PAGE 10
Dari gambar 2-13 dapat diketahui, sebagai berikut:
Flow graph tidak terdapat predicate node, maka digunakan persamaan 1 (satu)
dengan parameter:
E = 11 dan N = 9
V(G) = E N + 2
V(G) = 11 9 + 2
V(G) = 4
Maka banyaknya independent path yang harus dicari adalah 4 (empat).

Independent paths yang terbentuk:
Path-1: 1-11
Path-2: 1-2-3-4-5-10-1-11
Path-3: 1-2-3-6-8-9-10-1-11
Path-4: 1-2-3-6-7-9-10-1-11

3.5 Kasus Uji (Test Case)
Langkah terakhir dalam melakukan pengujian menggunakan metoda basis path
testing adalah menyiapkan kasus-kasus uji untuk mengeksekusi semua alur
logika yang telah dibuat pada langkah sebelumnya.
Kasus uji yang dimaksud disini adalah dengan cara memberikan nilai pada
variable yang terlibat. Nilai yang dimasukkan haruslah nilai yang mungkin
muncul dan sesuai dengan tipe data yang telah didefinisikan.
Test case dibuat dalam bentuk tabel yang tujuannya untuk mempermudah
eksekusi setiap basis path, karena nilai-nilai yang dimasukkan dan yang
dihasilkan akan lebih mudah diamati. Tabel ini diberi nama basis path
worksheet.
Langkah-langkah dalam menyiapkan basis path worksheet adalah sebagai
berikut:
Kolom pertama diberi nama Nomor Path karena akan diisi nomor
urut basis path yang ditemukan.
Kolom kedua dan seterusnya diberi nama sesuai dengan nama
variable yang terlibat pada program tersebut.
Kolom terakhir merupakan kolom untuk menuliskan hasil eksekusi
setiap basis path. Penamaan kolom ini disesuaikan dengan nama
variable yang digunakan untuk menampung hasil akhir.
Banyaknya baris sesuai dengan jumlah basis path.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 69
PAGE 10
Setelah basis path worksheet dipersiapkan, maka langkah berikutnya adalah
mengisi worksheet tersebut dengan nilai-nilai yang sesuai dengan kondisi setiap
basis path.
Dari basis path yang didapatkan dari gambar 2-13, basis path worksheet yang
dipersiapkan adalah sebagai berikut:
Kolom pertama Nomor_path
Kolom kedua a
Kolom ketiga b
Kolom keempat c
Kolom kelima Total
Setelah diketahui kolom-kolom pada basis path worksheet, maka langkah
selanjutnya adalah mengisi worksheet tersebut dengan nilai yang sesuai dengan
alur basis path yang telah ditemukan.
Contoh eksekusi path-1 : 1-11
Node 1 berisi statement: while a < 10, supaya alur logika ini
langsung menuju ke node 11, maka pengujian a < 10 harus bernlai
false (salah). Oleh karena itu nilai untuk variable a supaya
menghasilkan false adalah angka di atas 10 (11, 12, 100, 1000,),
nilai ini kemudian dituliskan dalam worksheet. Tujuannya adalah untuk
memastikan bahwa alur logika tersebut memang langsung menuju ke
node 11.
Contoh eksekusi path-2: 1-2-3-4-5-10-1-11
Pada path ini, supaya dari node-1 dapat menuju ke node-2, maka nilai
variable a harus dapat menghasilkan nilai true pada pengujian a < 10,
yakni nilai di bawah 10 (0, 1, 2, 3, , 9), nilai ini kemudian dituliskan
dalam worksheet. Node-2 hanya berisi statement yang bukan
merupakan pengujian kondisi, oleh karena itu dapat langsung
diteruskan ke node-3.
Pada node-3 terdapat statement If (b < 10), supaya dari node-3
ini menuju ke node-4, maka nilai variable b harus dapat menghasilkan
nilai true untuk pengujian b<10. Nilai variable b yang digunakan adalah
bilangan kurang dari 10 (0, 1, 2, 3, , 9), nilai ini juga kemudian
dituliskan dalam worksheet.
Pada node-4 terdapat statement untuk menghitung nilai variable cut,
setelah dilakukan penghitungan, maka langsung dilanjutkan menuju ke
node-5 yang juga berisi statement penghitungan nilai variable cut.
Setelah node-5 selesai dieksekusi, maka nilai yang dihasilkan pada
variable cut dituliskan pada worksheet. Node-5 merupakan statement
terakhir yang berada pada kolom then dari statement if, oleh
Telkom Polytechnic Jaminan Mutu Sistem Informasi


70 White Box Testing
PAGE 10
karena itu node berikutnya yang akan dituju adalah node-10.
Pada node-10 berisi statement yang berfungsi untuk menambah nilai
variable a dengan angka 1, dan statement untuk menghitung nilai
variable total. Hasil dari penghitungan variable total dituliskan ke
dalam worksheet.

Di bawah ini adalah tabel hasil eksekusi untuk setiap basis path:

Tabel 3-1 Basis path worksheet untuk flow graph gambar 2-13.
No_Path a b c cut Total
Path-1 11 - 1000 - -
Path-2 10 1 1000 -10 990
Path-3 10 0 1000 0 1000
Path-4 10 11 1000 110 1110

Pada program yang memiliki kesalahan, pengisian kolom-kolom pada basis
path worksheet tidak akan sempurna atau terdapat ketidaksesuaian nilai
dengan yang diharapkan oleh penguji.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 71
PAGE 10




Rangkuman



1. White box testing dijuluki pula sebagai structural testing, logic-driven
testing, atau glass box testing, karena meninjau source code suatu
sistem atau komponen program.
2. Source code yang dituliskan berfungsi untuk menggambarkan struktur
dan alur logika (logical path).
3. Logical path yang akan diuji:
a. Independent paths
b. Keputusan-keputusan logika
c. Alur pengulangan
d. Struktur data internal
4. Jika white box testing dijalankan secara penuh, maka akan dihasilkan
suatu perangkat lunak yang sempurna dan benar 100%.
5. White box testing dianggap sebagai strategi pengujian yang boros,
bahkan dianggap tidak mungkin untuk dilakukan karena akan
melibatkan sumber daya yang besar.
6. Basis path testing merupakan suatu metoda yang digunakan dalam
teknik white box testing.
7. Langkah-langkah yang dilakukan dalam menjalankan metoda basis
path testing:
a. Menggambarkan alur logika ke dalam flow graph.
b. Menentukan cyclomatic complexity.
c. Menentukan basis set.
d. Membuat data uji


Telkom Polytechnic Jaminan Mutu Sistem Informasi


72 White Box Testing
PAGE 10




Kuis Benar Salah



1. White box testing membutuhkan source code untuk dilakukan
pengujian.
2. Salah satu kemampuan white box testing adalah untuk mendeteksi
kesalahan ketik kode program.
3. White box testing merupakan strategi pengujian perangkat lunak yang
paling efisien.
4. Source code terdapat penggambaran alur logika dalam menyelesaikan
masalah.
5. Pengujian kondisi tidak dapat digambarkan menggunakan notasi flow
graph.
6. Banyaknya independent path yang terdapat dalam suatu flow graph
ditentukan dari banyaknya predicate node.
7. Salah satu aspek yang mempengaruhi cyclomatic complexity suatu
perangkat lunak adalah banyaknya independent path.
8. Cyclomatic complexity dapat dihitung dengan cara menghitung
banyaknya predicate node.
9. White box testing lebih baik tetap dilakukan namun hanya untuk alur
logika yang dianggap penting saja dan tetap dikombinasikan dengan
strategi pengujian yang lainnya.
10. Test case yang dipersiapkan harus dapat menguji kondisi benar dan
salah di suatu sintaks if.


Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 73
PAGE 10





Pilihan Ganda



Petunjuk: Pilihlah jawaban yang paling tepat!

1. Yang dibutuhkan untuk dapat dilakukan white box testing adalah
A. Desain perangkat lunak D. Use case diagram
B. Source code E. Dokumen kontrak proyek
C. Data flow diagram

2. Berikut ini yang termasuk dalam kesalahan umum programmer,
kecuali
A. Kesalahan tipografi D. Kesalahan desain
B. Kesalahan asumsi E. Salah ketik
C. Kesalahan logika

3. Syarat yang diperlukan untuk menjalankan strategi white box testing
adalah:
A. Mengevaluasi semua hasil pengujian
B. Membangun kasus untuk digunakan dalam pengujian
C. Melakukan pengujian secara menyeluruh
D. Mendefinisikan semua alur logika (logical path)
E. Semua benar

4. Berikut ini yang bukan merupakan kegiatan pengujian alur logika
adalah
A. Mengeksekusi alur logika dengan data uji yang telah dituliskan
B. Memperbaiki baris program yang salah
C. Menulis contoh data uji
D. Melakukan verifikasi data hasil eksekusi
E. Tidak ada jawaban

Telkom Polytechnic Jaminan Mutu Sistem Informasi


74 White Box Testing
PAGE 10

5. Langkah-langkah yang tidak termasuk dalam basis path testing
adalah
A. Menentukan cyclomatic complexity
B. Membuat data uji
C. Menggambarkan alur logika
D. Menentukan basis set dari independent path
E. Semua benar


Telkom Polytechnic Jaminan Mutu Sistem Informasi


White Box Testing 75
PAGE 10



Latihan

1. Buatlah flow graph dari potongan program berikut ini:
Public void Foo (int a, int b, int x) {
if (a>1 && b==0) {
x=x/a;
}
if (a==2 || x>1) {
x=x+1;
}
}

2. Lakukan basis path testing pada potongan program di bawah ini:
public double calculate (int amount) {
double rushCharge = 0;
if (nextday.equals("yes")) {
rushCharge = 14.50;
}
double tax = amount * .0725;
if (amount >= 1000) {
shipcharge = amount * .06 + rushCharge;
}
else if (amount >= 100) {
shipcharge = amount * .08 + rushCharge;
}
else if (amount >= 50) {
shipcharge = 13.25 + rushCharge;
}
else {
shipcharge = 5.25 + rushCharge;
}
total = amount + tax + shipcharge;
return total;
} //end calculate

Telkom Polytechnic Jaminan Mutu Sistem Informasi


76 AcceptanceTesting
PAGE 10
4 Acceptance Testing (Functional & User
Acceptance Test)







Overview


Dalam Bab Acceptance Test ini, menjelaskan bahwa Terdapat Proses Testing
yang merupakan bagian tahapan model Proses Pengembangan V- System.
Dalam Proses Pengujian perlu adanya Perencanaan Pengujian (Test Planning)
dengan dokumentasi-dokumentasi yang dibutuhkan. Hal ini juga perlu dengan
Strategi Pengujian yang mendasari tahapan Pengujian P/L ini.
Dalam Acceptance Test ini ditujukan agar Verifikasi dan validasi terhadap P/L
apakah diterima atau tidak sebelum direlease kepada pengguna.
Perlu kiranya adanya dokumen templete untuk Accptance Test Plan untuk
kebutuhan Pengujian.




Tujuan

1. Mahasiswa mengerti akan Proses Pengujian terhadap tahapan-tahapannya
yang merupakan bagian dari Model Proses Pengembangan Perangkat
Lunak
2. Mahasiswa juga mengerti akan Perencanaan Pengujian
3. Mahasiswa mengerti tentang Strategi Pengujian dengan jenis-jenisnya
4. Mahasiswa mengetahui dan mengimplementasikan Acceptance Testing dan
Prosesnya
5. Mahasiswa mempelajari implementasikan Dokumentasi templete
pengujian
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 77
PAGE 10
4.1 Testing Process

Gambar 4-1 Proses Testing

Proses Pengujian (Testing Process), Secara umu urutan dari aktifitas
Pengujian adalah sbb:
1. Component Testing
1 Pengujian komponen-komponen program
2 Biasanya dilakukan oleh component developer (kecuali untuk
system kritis)
2. Integration Testing
1 Pengujian kelompok komponen-komponen yang terintegrasi
untuk membentuk sub-system ataupun system
2 Dilakukan oleh tim penguji yang independent
3 Pengujian berdasarkan spesifikasi sistem

3. User Testing
1 Pengujian terhadap keseluruhan fungsional sistem dan
difokuskan atas validasi sistem sesuai dengan spesifikasi sebelum
dipakai user.
2 Dilakukan oleh tim Pengembang dan dinilai oleh Pengguna
3 Pengujian berdasarkan spesifikasi sistem

Ketiga Aktifitas Pengujian tsb terbagi dalam 5 tahap proses Pengujian
yaitu sbb:
1. Unit Testing,
Pengujian thd unit-unit komponen untuk menjamin beroperasi
dengan benar.
2. Module Testing,
Pengujian atas enkapsulasi modul yang terkait dengan komponen
secara independen.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


78 AcceptanceTesting
PAGE 10
Sebuah modul merupakan kumpulan komponen-komponen yang
saling bergantung satu sama lain spt object class, abstract data type
dan function
3. Sub-system Testing
Tahapan ini melibatkan pengujian kumpulan modul-modul yang telah
diintegrasikan kedalam subsistem.
Subsistem ini dapat didesain dan diimplementasikan secara
independen.
Pengujian dapat dilakukan terhadap interface-interface yang
terbentuk
4. System Testing
Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar
sub-system
5. Acceptance Testing
Pengujian terakhirs sebelum sistem dipakai oleh user.
Melibatkan pengujian dengan data dari pengguna sistem. Biasa dikenal
sebagai alpha test (beta test untuk software komersial, dimana
pengujian dilakukan oleh potensial customer)

4.2 Test Planning
Test Planning difokuskan dengan pembentukan standar selama proses
pengujian daripada uji produk.
Test Plan bukan hanya berkaitan dengan dokumen manajemen tetapi juga
melibatkan engineer mendesain jalannya pengujian sistem dan menyediakan
informasi atas ketersediaan kebutuhan hardware dan software
4.2.1 Test Plan Content
1. Testing Process
Gambaran tahapan-tahapan utama proses pengujian.
2. Requirement Traceability
Permintaan kebutuhan dari user yang ada pada sistem. Sehingga
semua permintaan direncanakan untuk diuji
3. Tested Item
Perincian Produk-produk proses software yang diujikan
4. Testing Schedule
Penjadwalan keseluruhan Testing dan alokasi smber daya, dimana
dihubungkan dengan penjadwalan pengembangan proyek
5. Test Recording Procedure
Hasil-hasil Proses Pengujian harus secara sistematik disimpan. Untuk
memudahkan pengecekan kembali saat audit

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 79
PAGE 10
6. Hardware & Software Requirements
Estimasi Kebutuhan Penggunaan hardware dan alat bantu software
yang diminta
7. Constraint
Batasan-batasan yang berpengaruh pada Proses Softwre yang dapat
diantisipasi.
Tahapan Testing dalam Model Proses PengembanganV System sebagai
berikut:

Gambar 4-2 Tahapan Testing dalam Model Proses -V
4.3 Testing Strategis
Sebuah Strategi Pengujian merupakan suatu pendekatan umum thd proses
pengujian daripada sebuah metode Perencanaan sistem utama atau uji
komponen.
Perbedaan strategi Pengujian dapat diadopsi tergantung dari tipe sistem yang
diuji dan proses pengembangan yang dilakukan.
Jenis-jenis Strategi Testing:
1. Top-down Testing, Testing dimulai dgn komponen yang abstrak dan
turunan kerja
2. Bottom-up Testing, Testing dimulai dari komponen dasar dan
pekerjaan dijabarkan ke atas
3. Thread Testing, Testing yang digunakan pada sistem dengan proses yang
banyak dimana jalannya proses suatu transaksi beriringan dengan proses
yang lain
4. Stress Testing,Testing yang diandalkan dengan sistem yang dibuat untuk
menguji setiap kondisi yang ada
5. Back-to-back Testing, digunakan ketika versi suatu sistem tersedia.
Sistem diuji bersamaan dengan keluarannya lalu dibandingkan
Telkom Polytechnic Jaminan Mutu Sistem Informasi


80 AcceptanceTesting
PAGE 10
4.4 Failure & Faults
Failure merupakan output yang tidak benar/tidak sesuaiketika sistem dijalankan.
Fault merupakan kesalahan dalam source code yang mungkin menimbulkan
failure ketika code yg fault tsb dijalankan
Failure Class Deskripsi
Transient Muncul untuk input tertentu
Permanent Muncul untuk semua input
Recoverable Sistem dapat memperbaiki secara otomatis
Unrecoverable Sistem tidak dapat memperbaiki secara otomatis
Non-corrupting Failure tidak merusak data
Corrupting Failure yang merusak sistem data

Contoh Failure, Faults adalah sbb:


Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 81
PAGE 10
4.5 Acceptance Testing
Terdapat beberapa istilah berkaitan dengan Acceptance Testing Process yaitu:
1 Acceptance Decision, Keputusan terhadap penerimaan terhadap
perangkat lunak yang telah dibangun atau dikembangkan berdasarkan
Acceptance Criteria
2 Acceptance Testing, Proses Pengujian dengan melibatkan sekumpulan
data untuk seseorng membuat Acceptance Decision sebagai
keputusan terhadap penerimaan perangkat lunak
3 Readiness Decision, Keputusan terhadap suatu produk perangkat
lunak, apakah siap untuk dibaca, dilihat atau digunakan orang yang
terlibat dalam Acceptance Decision atau Acceptance Testing

Gambar 4-3 Acceptance Process

1 Proses diawali dengan Construction dari Produk P/L, yang
memungkinkan terdapat banyak bug, maka perlu di uji sebelum
diterima oleh konsumen/pengguna
2 Untuk meminimalisir jumlah konsumen menanyakan produk ini
untuk diterima, maka suplier, yang akan me-release produk, maka
melakukan self-assesment dengan aktifitas verifikasi P/L terhadap
kebutuhan,hal ini disebut readiness Assesment
3 Keputusan melibatkan readiness Assesment pada produk P/L tsb
disebut readiness Decision

Telkom Polytechnic Jaminan Mutu Sistem Informasi


82 AcceptanceTesting
PAGE 10
4 Pengujian dilakukan untuk diterima sebagai kandidat release
pengguna, hal ini melakukan Acceptance Testing
5 Keputusan untuk menerima produk P/L. Kondisi ini disebut
Acceptance Decision
6 Keputusan tiap pengguna membuat produk diterima atau tidak
secara aktual digunakan. Hal ini disebut Usage Decision
7 Tiap keputusan bisa menghasilkan keluaran negatif atau positif

4.6 System Acceptance Test
Proses ini bertujuan untuk menguji apakah sistem sudah sesuai dengan apa
yang tertuang dalam spesifikasi fungisonal sistem (validation),
Test akan dilakukan oleh pengembang dan hasil akan dinilai oleh pengguna,
terdiri dari dua tahapan: Sebelum pengiriman dan setelah instalasi, melibatkan
semua aspek sistem: hardware, software aplikasi, environment software,
tempat, dan operators

4.6.1 Test Dokumentasi
Test Dokumentasi terdiri dari :
Test Filosofi
Untuk meyakinkan bahwa sistem sudah memiliki:
a. Keamanan dan keselamatan dalam operasional
b. Kehandalan,
c. Dapat dirawat secara cost-effective,
d. Dapat dimodifikasi untuk menyesuaikan dengan
perubahan kebutuhan operasional
Test Plan
Merupakan dokumentasi yang menjelaskan jadwal untuk pre-
delivery dan site acceptance test.
Jadwal test:
a. Urutan Test yang menyatakan kaitan antara test satu
dengan yang lainnya dan masing-masing test tersebut
sesuai dengan salah satu kebutuhan user
b. Test Method spesifikasi test
c. Resource provision: mendefinisikan pembagian
tanggung jawab dan waktu untuk setiap resource test
Prosedur umum pengujian: menspesifikasikan keseluruhan
prosedur untuk melakukan pengaturan dan set-up
pengoperasian acceptance test.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 83
PAGE 10
Prosedur mencakup:
a. Supervisi dan inviligator-> konfirmasi terhadap
prosedur pengetesan yg dilakukan oleh supervisi dan
approver
b. Jadwal dan Lokasi: prosedur dan tanggung jawab untuk
mengatur jadwal dan tempat pengujian
c. Perubahan perencanaan: prosedur ketika terjadi
perubahan jadwal
d. Kegagalan test: prosedur yg hrs dilakukan ketika
terjadi kesalahan spt: jumlah pengulangan ,
penyesuaian kapan dilakukan test setelah modifikasi
e. Hasil test: prosedur utk mendokumentasi,
menyimpulkan dan mereview hasil pengujian
f. Kriteria kelengkapan test: mendefinisikan kriteria
sukses kelengkapan test untuk pre-delivery dan site
acceptance test.
Test specifications
Setiap test yg akan dilakukan harus dispesifikasikan secara
detail oleh pengembang dan disetujui oleh user. Spesfikasi tsb
terdiri dari:
a. Judul dan referensi tunggal
b. Tujuan yang secara spesifik sesuai dengan Functional
Requirement
c. Lokasi pengujian
d. Syarat Pengujian: mis.: nilai marginal input, supplies,
dan lingkungan yang digunakan
e. Konfiguasi Test: versi dan isu hardware, software, test
dan bantuan simulasi
f. Spesifikasi input dan output
g. Detail prosedur operasional pengujian
h. Hasil yang dinginkan dan batasan utk penerimaan (dlm
model data numerik / check list event, informasi sec.
Garfis)
i. Format untuk merekam hasil, details kesalahan dan
instruksi utk melakukan test ulang, perekaman
terhadap retensi dan analisis.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


84 AcceptanceTesting
PAGE 10
Pre-Delivery Test
Dilakukan melalui simulasi terhadap tempat yang implementasi
sistem. Hal penting yang dilakukan dlm melakukan pre-delivery
test:
a. Syarat utk memulai pengujian: konfiramsi terhadap
kebenaran data, dokumen, software aplikasi dan test khusus
atau software simulasi, dan ketersediaan lingkungan yg
sesuai, pelayanan dan personal yg cocok,
b. Hardware dan software: pembuatan standard atau issue
level HW dan SW yg akan digunakan dlm pengujian
c. Preliminary HW test: melakukan pengujian performance-
acceptance HW
d. Test Plan
e. Prosedur Test
f. Test Log: Log semua operasi dan kejadian selama test (yg
terencana maupun tidak) termasuk full detail insiden,
error, failure, retest, restart.
g. System diagnostic: pendeteksian dan diagnosis fault yg
digunakan hrs tervalidasi (variasi fault dan kondisi out-of-
range)
h. Functional Testing: functional testing yg menggunakan sistem
software hrs comprehensive. Simulasi inputs dan respon
hrs serealistik mungkin sesuai dg kondisi tempat.
i. Test Summary: lsiting semua kegagalan test (termasuk
pengulangan), kejadian yg tidak dapat dijelaskan dan non-
conformances thd Functional test
j. Test Failure: aksi utk meresolve failure dan masalah yg
mucul selama pengujian,
k. Kejelasan pengiriman
Test logs
Test summary
Commissioning Report
Certificate of Acceptance

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 85
PAGE 10
4.6.2 Site Acceptance Test
Semua pengujian pada pre-delivery sudah dilakukan dan diterima. Hal
tambahan yang dilakukan :
Delivery check: pengecekan terhadap kerusakan HW, SW dan
dokumnetasi selama pengiriman,
Test Hardware: tidak terdapat kerusakan selama pengimpanan dan
pengiriman, sudah instal dg baik, beroperasi dg baik di lingkungan
tempat yg akan diinstal (listrik, ruangan, dll)
Modifikasi pre-delivery test: semua modifikasi sebagai konsekuensi dr
masalah yg akan muncul selama pre-delivery test hrs dijadikan
sebagai test tambahan
Pengujian terhadap semua peralatan
Pendukung kebutuhan thd jadual pengujian di site:
a. Test validasi HW
b. Test HW dengan hubungan ke site
c. Fault validation testing: respon out-ot limit input
d. Functional testing: pengujian functional system yg
komprehensif
e. Extended running
Aspek lain yg hrs diperhatikan:
a. Training staf yg akan mengoperasikan sistem
b. Training staf yg akan merawat sistem
c. Kebutuhan lainnya untuk tuning system, mis.: max
throughput, max. efisiensi, minimum cost
d. Pembuktian lainnya spt sistem alarm, keselematan,
keamanan, dan back-up
4.6.3 TakeOver dan Acceptance
Pengambil alihan (takeover) user setuju bahwa peralatan sudah sesuai dengan
kebutuhan yang ditambahkan dengan garansi utk periode tertentu terbebas
dari kesalahan.
Penerimaan (acceptance) adalah user setuju bahwa software/aplikasi sudah
sesuai dengan kebutuhan
4.7 Best Practice Testing
Pengujian ini mengandung Basic Practice yaitu sbb:
Functional Specifications menggambarkan fungsi keseluruhan sistem
shg keuntungannya adalah aktifitas pengujian dapat dilakukan secara
paralel dengan proses pengembangan code.
Reviews dan Inspection: melakukan Reviews dan inspeksi
(debugging) terhadap kode sumber.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


86 AcceptanceTesting
PAGE 10
Kriteria formal entry dan exit setiap proses pengembangan sistem
dilakukan insoeksi terhadap parameter entry dan exit.
Functional test variations: jumlah test cases yg dibuat biasanya
bervariasi. Variasi adalah kombinasi kondisi input tertentu untuk
menghasilkan konidisi output yg spesifik.
Multi-platform testing: pengujian pada semua platform mesin.
Internal Betas: pengujian yg dilakukan oleh sejumlah user tertentu
sebelum dilakukan pengiriman.
Automated test execution: meminimalkan jumlah kerja manual pada
saat pengujiaan sehingga memperoleh nilai coverage yang lebih tinggi.
Test tool (oracle) yg digunakan memverifikasi operasi dan log
kesalahan,
4.8 Foundational
Skenario User: membuat skenario user yang menguji fungisonalitas
aplikasi,
Pengujian Usabilitas: tidak saja melakukan pengujian usabilitas, tetapi
juga menyediakan suatu metode feetback untuk meningkatkan user
experience shg terbentuk image kualitas yg baik.
Requirements dalam perencanaan test. Kebutuhan(user requirements)
adalah parameter yg digunakan dalam pengetesan, dimana sistem yg
dikembangkan hrs sesuai dengan kebutuhan user tsb, Sehingga dlm
merancang test, kebutuhan user harus sudah diketahui dg jelas.
Automated test generation: Almost 30% of the testing task can be
the writing of test cases -> need a automatically test tools.

Template : User Acceptance Test Plan

Table of Contents
1. Instructions for the User Acceptance Tester .................................. 2
1.1 New System and Regression Testing Instructions ............................................ 2
1.2 Form-Based Testing Procedures ............................................................................. 2
1.3 Business Process Testing Procedures ...................................................................... 2
1.4 Report Testing Procedures ....................................................................................... 3
1.5 Defect Reporting ..................................................................................................... 3
1.5.1 Defect Tracking Guidelines................................................................................ 3
1.5.2 Defect Tracking Log Instructions ..................................................................... 4
2. Form-Based Testing ........................................................................ 5
2.1 List of Modules to be Reviewed for Form-Based Testing ............................... 5
2.2 Form-Based Test Script ........................................................................................... 6
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 87
PAGE 10
3. User Security Matrix ........................................................................ 7
4. User Acceptance Business Process Test Scripts ............................... 8
4.1 Sample- Main Menu ................................................................................................. 8
4.2 Sample: CRS1050 Update Exam Scenario ....................................................... 9
5. Report Test Script ..........................................................................10
5.1 Sample- Detailed Information Report ............................................................... 10
6. Defect Tracking Form ...................................................................11
7. Defect Tracking Log ......................................................................12

1. Instructions for the User Acceptance Tester
1.1 New System and Regression Testing Instructions
The purpose of regression testing and new system testing is to assure that the
entire application is functioning correctly. This test plan is designed to ensure
that all components of the application are tested. Complete all test scripts
included within this test plan for all applicable user levels and modules as
listed.

The specific instructions for following the test scripts, and executing the tests
are listed under each test type heading below.
1.2 Form-Based Testing Procedures
The purpose of testing the individual forms and the user interface is to assure
that all of the Menus and Graphical Interface buttons, pulldown lists, scrolling
lists, and check boxes are performing correctly. It is important to perform
each interface for each module/screen as not all modules have the same
buttons or menus.

The procedures for testing the User Interface are as follows:
1. Copy the User Interface Acceptance Test Script included in this
document. Make a copy for each module screen listed in the List of
Modules spreadsheet.
2. Mark at the top of each form-based test script which module/screen
you are testing.
3. Complete the test environment section at the top of each test script.
4. Login as System Administrator (the highest security level in order to
have access to all screens).
5. For each step in the test script initial and date the successful tests.
6. If the test results are not as you expect, or a comment or clarification
on a screen or process is required, please complete a defect form for
that test step. (Do not initial and date unsuccessful test cases).
Telkom Polytechnic Jaminan Mutu Sistem Informasi


88 AcceptanceTesting
PAGE 10
7. Please return a copy of all completed Test Scripts and Defect Forms as
per the rules and timeframes described under Section 1.5.1 of this
document.

1.3 Business Process Testing Procedures
The purpose of testing the Business Processes is to ensure that all of the
functional requirements for the application are performing correctly. It is
important to complete all test cases for each User Security level (eg. System
Administrator, Processing Clerk etc.) This will assure that each Security Level
has access to the appropriate functions.

The procedures for testing the Business Processes are as follows:

1. Copy the Business Process Test Scripts included in this document. Make
a copy for each user Security level listed in the User Security Matrix.
2. Mark at the top of each Business Process Test Script which Security level
you are testing.
3. Complete the test environment information as required at the top of
each Business Process test script.
4. Login as the appropriate user Security level.
5. For each step in the test script initial and date the successful tests.
6. If the test results are not as you expect please complete a defect form
for that test step. (Do not initial and date unsuccessful test cases).
7. Please return a copy of all completed Test Scripts and Defect Forms as
per the rules and timeframes described under Section 1.5.1 of this
document.
1.4 Report Testing Procedures
This Application allows users to specify which data they would like to report
on by queuing different data to a report. It is important that this process is
tested for each module. It is also important that the Ministrys Print Utility is
tested by having the report print to paper for a number of different cases. If
the result of printing is not as expected be sure to fill out a defect report
form for that test.

It is important to repeat each test script for the different user Security levels
listed in the User Security Matrix to ensure that report security rules are
functioning correctly.


Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 89
PAGE 10
The procedures for testing the Reports are as follows:

1. Copy the Report Test Scripts included in this document. Make a copy
for each user Security level you are testing.
2. Be sure to mark at the top of each Report Test Script which Security
level you are testing.
3. Complete the test environment information at the top of each test
script.
4. Login the appropriate User Security level.
5. For each step in the test script initial and date the successful tests.
6. If the test results are not as you expect please complete a defect form
for that test step. (Do not initial and date unsuccessful test cases).
7. Please return a copy of all completed Test Scripts and Defect Forms as
per the rules and timeframes described under Section 1.5.1 if this
document.
1.5 Defect Reporting
A defect report form has been included at the end of this document.
1.5.1 Defect Tracking Guidelines

1. It is critical to complete all fields on this form in order to assist
Developers in tracking and correcting the problem.
2. A Defect Tracking Form must be completed at the time that a
problem is found in order to assure that all details are documented
correctly.
3. Attach any available screen shots or report examples to the
Defect Tracking form.
4. Defect Tracking forms will be submitted <insert how often forms
should be submitted> to <Insert Application Manager info here>, in
order to implement fixes as quickly as possible.
5. A service affecting Defect (a problem, which inhibits further
testing,) must be reported immediately to <Insert Application
Manager info here>, in addition to completing a Defect Tracking
Form.
6. A Defect Number will be assigned to each defect by the <Vendor
or Application Manager> for tracking purposes.
1.5.2 Defect Tracking Log Instructions
1. Defect Tracking forms will be submitted <insert how often forms
should be submitted> to <Insert Application Manager info here>, in
order to implement fixes as quickly as possible.
2. A service affecting Defect (a problem, which inhibits further
Telkom Polytechnic Jaminan Mutu Sistem Informasi


90 AcceptanceTesting
PAGE 10
testing,) must be reported immediately to <Insert Application
Manager info here>, in addition to completing a Defect Tracking
Form.
3. Insert all summary information from the defect tracking form or
service affecting defect report (may be by phone or email) at the
time that the defect is submitted.
4. Assign a defect number and label the defect tracking form with
the same number.
5. Be sure to match the new defect number with the defect tracking
forms for service affecting defects reported by phone or email.

2. Form-Based Testing
Listed below are the modules to be tested. Each Screen should be reviewed
for correctness as per the Form-Based Test Script in Section 2.2.
2.1 List of Modules to be Reviewed for Form-Based Testing

Module ID Module name




2.2 Form-Based Test Script
This checklist must be completed for ALL modules as listed
above in section 2.1. Please photocopy this page for each online
module and fill in the module identifier in the space provided.
Complete the test environment information. Attach a Defect
Report if necessary to describe any anomalies.

MODULE: _________________ SCREEN: ____________________
TEST ENVIRONMENT:
Operating System:
Network:
Workstation Memory:

Form Based Testing Component Pass/
Fail
Date Initial
s
1. Are all fonts, colors, shading and toolbars
consistent with standards and project
guidelines?

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 91
PAGE 10
2. Is the online help module available?
3. Are all date formats correct (DD-MON-
YYYY) Are the date edits being correctly
applied? Are dates greater than 2000 accepted?

4. Does all text wrap when displayed in the text
editor?

5. Is there a scroll bar on every applicable block?
6. Is the Toolbar List button enabled only when a
list of values is available for an item?

7. Do the window titles correctly identify each
module?

8. Is there hint text available for all applicable
items?

9. Do all of the initial 'window display' sizes fit
entirely on the screen (assuming an SVGA
800x600 resolution)?

10. Are the correct items case sensitive? (i.e. Do
fields allow lower case text if they should only
accept upper case?)

11. Are error, warning and information messages
accurate and understandable?

12. Do all DELETE operations display a Delete
Confirmation alert?

13. Is the field tab order correct
14. Are the appropriate edits done on all fields
(range of values, valid values etc.)

15. Are defaults appropriate?
16. Are the correct fields mandatory?
17. Is the tool bar present and appropriate buttons
enabled?

18. Are screen & field labels appropriate?
19. Are fields & buttons ordered appropriately?
20. Are all codes valid?
21. Are all field labels are consistent across the
application



Telkom Polytechnic Jaminan Mutu Sistem Informasi


92 AcceptanceTesting
PAGE 10
3. User Security Matrix
List all userids available for testing:
Example:
SYS_ADMIN System Administrator access to all
CLERK Processing Clerk limited access
REPORT Reporting Clerk Access reports only


List all security access availability for each user level in the
spreadsheet below.

User Security/Access Level Matrix

USER ROLE Module
Label
Module
Description
Details Module
Type







4. User Acceptance Business Process Test Scripts
4.1 Sample- Main Menu
Using module the <insert module ID>, complete the following
checklist. Complete the User Security Level information and Test
Environment information at the top of each form. Attach a
Defect Report if necessary to describe any anomalies.

USER SECURITY LEVEL: _____________________
TEST ENVIRONMENT:
Operating System:
Network:
Workstation Memory: __________

Acceptance Testing Action Pass
/Fail
Date Initial
s
1. Does each button navigate to the correct
module?

2. Is the correct module name/date/version
# displayed at the top of the window?

3. Are the appropriate buttons available,
(based on the security matrix)?

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 93
PAGE 10
4. Are the appropriate menu options
available, (based on the security matrix)?

5. Access to application not allowed unless
user is set up in Staffs and as an active
application user (as defined in user detail
maintenance)

6. Does the message/text box display text
correctly?

7. Do the graphics appear clearly and display
correctly?

8. Does the menu bar appear at the top of the
page?

4.2 Sample: CRS1050 Update Exam Scenario
Using module <insert the module ID>, complete the following
checklist. Complete the User Security Level information and Test
Environment information at the top of each form. Attach a
Defect Report if necessary to describe any anomalies.

USER SECURITY LEVEL: _____________________
TEST ENVIRONMENT:
Operating System:
Network:
Workstation Memory: __________

Acceptance Testing Action Pass
/Fail
Date Initial
s
1.Does the Menu Option Certificates - Edit
Exam take you to the Query Mode of the
Certificates Screen?

2. Does the vertical button bar display correctly?
3. Does each vertical button bar navigate to the
correct screen?

4. Does the top tool bar display correctly?
5. Can you search for each of the criteria on the
screen (each field)?

6. Does the search bring up the expected results?
7. Do the search results sort and display
correctly?

Telkom Polytechnic Jaminan Mutu Sistem Informasi


94 AcceptanceTesting
PAGE 10
8. When you select all records do the appropriate
records queue to print?

9. Does the Queue Label queue correctly?
10. Does Queue Document queue correctly?
11. Does Queue Record button queue correctly?
12. Do all fields clear for a new query when new
query selected?

13. Can you update each of the fields on the
screen?

14. Does each field update and display correctly?
15. When you save changes can you retrieve your
changes in a new query?

16. Does the List values button display the list
windows for each appropriate field?

17. Do all prompts/ messages display correctly at
bottom of the form?

5. Report Test Script
5.1 Sample- Detailed Information Report
Using report <insert report ID>, complete the following checklist.
Complete the User Security Level information and Test
Environment information at the top of each form. Attach a
Defect Report if necessary to describe any anomalies.

USER SECURITY LEVEL: _____________________
TEST ENVIRONMENT:
Operating System:
Network: ____________
Workstation Memory: __________

Acceptance Testing Action Pass
/Fail
Date Initial
s
1. Can you access the Report module from
the main menu?

2. Are all appropriate reports listed based on
the Security of the user being tested?

3. Can you access the Detailed Information
Report from the list of available reports?

4. Is the correct report name/date/version #
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 95
PAGE 10
displayed at the top of the window?
5. Are the appropriate buttons available
(based on the security matrix)?

6. Are the appropriate menu options
available (based on the security matrix)?

7. Can you pull up the report to view on
screen?

8. Does all appropriate information list
correctly?

9. Does all information sort correctly?
10. Do all dates display correctly DD-MM-
YYYY?

11. Are the fields available appropriate to the
data displaying?

12. Does the report display with adequate
room for each column (no overlapping test
or columns running into other columns)

13. Is all formatting correct (bold, italics,
underline)?

14. Can you print to the printer?
15. Does all appropriate information list
correctly?

16. Does all information sort correctly?
17. Do all dates display correctly DD-MM-
YYYY?

18. Are the fields available appropriate to the
data displaying?

19. Does the report display with adequate
room for each column (no overlapping test
or columns running into other columns)

20. Is all formatting correct (bold, italics,
underline)?





Telkom Polytechnic Jaminan Mutu Sistem Informasi


96 AcceptanceTesting
PAGE 10
6. Defect Tracking Form

User Acceptance Testing DEFECT #

MELP Application Defect Tracking Form Test case
Step #:
Tester Name:
Module ID:
Date:
User Security Level tested:
APPMAN CRS_APPLICATION_MANAGER Access available to all functions
CLERK1 CRS_PROCESSING_CLERK Data Entry Functionality
CLERK2 CRS_PROCESSING_CLERK Data Entry Functionality
CLERK3 CRS_PROCESSING_CLERK Data Entry Functionality

Problem Severity (Check One):
1. System Crash (Data Loss)
2. System Crash (No Data Loss)
3. Incorrect Functionality (No Work Around)
4. Incorrect Functionality (Workaround)
5. Cosmetic

Can be Reproduced (Check One):
(E) Every Time
(S) Sometimes
(O) Occasionally
(1x) Happened Once

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Acceptance Testing 97
PAGE 10
Defect Summary Description (One sentence description of
problem):


Defect Description: (please print)
Screen Print/Error Message Attached





Steps to Reproduce:








7. Defect Tracking Log
Fill in the table as follows:




Telkom Polytechnic Jaminan Mutu Sistem Informasi


98 Uji Integrasi
5 Uji Integrasi









Overview


Setelah setiap modul diuji validitasnya, modul-modul perlu diintegrasikan
sebelum pada saatnya nanti diuji dalam lingkungan aslinya. Integrasi dapat
dilakukan dari atas ke bawah, top down, atau dari bawah ke atas, bottom up.
Uji regresi dilakukan untuk memastikan tambahan modul baru yang
diintegrasikan tidak menimbulkan efek samping yang tidak diharapkan. Uji
smoke perlu dilakukan untuk proyek-proyek yang waktu pengerjaannya
terbatas. Uji integrasi untuk lingkungan berorientasi objek, untuk aplikasi
client/server dan untuk aplikasi web memiliki karakteristik khusus untuk dikaji.




Tujuan

Setelah membaca bab ini, diharapkan Anda mengetahui:
1. apakah perbedaan pendekatan big bang dan incremental dalam uji
integrasi?
2. apakah perbedaan integrasi top down dan bottom up
3. apakah uji regresi dan uji smoke itu
4. bagaimana membuat dokumen pengujian
5. bagaimana melakukan uji integrasi dalam OO
6. bagaimana melakukan pengujian arsitektur client/server
7. bagaimana melakukan pengujian navigasi
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Uji Integrasi 99
PAGE 10
5.1 Uji Integrasi

Begitu setiap unit sudah diuji, mungkin ada yang bertanya: Jika setiap modul
bekerja secara individual, mengapa Anda meragukan kerja mereka sebagai
satu kesatuan? Ya, justru sebagai satu kesatuannya itu yang masih diragukan.
Uji integrasi penting dilakukan karena : data dapat hilang ketika melewati
antarmuka. Satu modul dapat memberikan pengaruh tak terduga pada modul
lain, subfungsi ketika dikombinasi boleh jadi tidak memproduksi fungsi utama
yang diinginkan, ketidakakuratan hasil kecil yang diterima secara individual
boleh jadi membesar hingga tingkat yang tak dapat diterima, struktur data
global dapat memunculkan masalah.

Uji integrasi, menurut wikipedia, adalah aktivitas pengujian software dalam
mana modul-modul software dikombinasikan dan diuji sebagai satu kesatuan.
Sedangkan menurut Roger S. Pressman adalah teknik sistematis untuk
membangun arsitektur software sambil pada saat yang sama menjalankan
pengujian untuk menemukan error terkait dengan interfacing, komunikasi
antar modul. Uji integrasi setelah uji unit sebelum uji sistem.

Tujuan uji integrasi adalah pemeriksaan fungsional, kinerja dan kehandalan
dari struktur program yang telah dirancang. Kelompok-kelompok modul, data
bersama, komunikasi antar proses diperiksa melalui antarmukanya
menggunakan uji black box. Sukses atau gagal disimulasikan melalui uji
parameter dan masukan data. Kasus-kasus pengujian dibangun untuk menguji
interaksi di antara seluruh komponen dalam kumpulan modul, melalui
pemanggilan prosedur atau aktivasi proses.
5.2 Pendekatan Big bang
Ada kecenderungan orang untuk melakukan uji integrasi ini dengan cara tidak
bertahap, pendekatan big bang. Seluruh komponen dikombinasikan
bertahap. Keseluruhan program diuji sebagai satu kesatuan. Dan biasanya
dihasilkan chaos. Sekumpulan error ditemukan. Koreksi sulit dilakukan karena
sulitnya mengisolasi penyebab kesalahan. Satu kesalahan dapat diatasi,
kesalahan yang lain muncul dan proses berlanjut seolah tanpa henti.

Salah satu tipe pendekatan big bang adalah pengujian model penggunaan,
usage model testing. Pengujian dilakukan dengan mengambil kasus-kasus beban
kerja mirip pengguna dalam lingkungan kerja akhir yang terintegrasi.
Lingkungan diuji, komponen individu diuji secara tidak langsung melalui
Telkom Polytechnic Jaminan Mutu Sistem Informasi


100 Uji Integrasi
penggunaan mereka. Beban kerja mirip pengguna perlu didefinisikan dengan
hati-hati untuk membuat skenario yang realistis dalam memeriksa lingkungan.
5.3 Pendekatan Incremental
Berlawanan dengan pendekatan big bang, program dibangun dan diuji
bertahap sedikit demi sedikit. Kesalahan akan mudah diisolasi dan diperbaiki,
antarmuka dapat diuji lengkap, dan pendekatan pengujian sistematis dapat
diterapkan. Pengujian dilakukan mungkin secara top down, bottom up,
regression testing atau smoke testing.
5.3.1 Integrasi Top down
Dalam metode ini, modul-modul diintegrasikan dengan perjalanan turun
melalui hirarki kendali, mulai dari modul utama kemudian ke modul-modul
subordinat. Modul-modul subordinat dapat digabungkan ke dalam struktur
program dengan pola depth-first atau breadth-first.

Dalam pola depth-first, modul diintegrasikan satu demi satu melalui struktur
kendali utama program. Diawali dari struktur kendali paling kritis, dilanjutkan
pada kendali lain. Lihat gambar 7.1.



Gambar 5-1Integrasi Top down pola Depth First

M1
M2 M3 M4
M5 M6 M7
M8
Sequence of modules that will be incorporated :
M1, M2, M5, M8, M6, M3, M7, M4
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Uji Integrasi 101
PAGE 10
Dalam pola breadth-first, seluruh komponen subordinat langsung di setiap
level, menelusuri struktur secara horisontal. Lihat gambar 7.2.



Gambar 5-2 Integrasi Top down pola Breadth First

Proses integrasi dijalankan dalam lima tahap berikut:
1. Modul kendali utama digunakan sebagai test driver, dan seluruh
komponen subordinat langsung di bawah modul kendali utama
diganti modul stub.
2. Modul-modul stub satu per satu diganti dengan komponen aktual.
3. Pengujian dilakukan pada setiap komponen yang diintegrasikan.
4. Setiap kali sekumpulan pengujian lengkap, stub lain diganti dengan
komponen yang sesungguhnya.
5. Pengujian regresi (dibahas di bawah) mungkin diperlukan untuk
meyakinkan bahwa kesalahan baru tidak muncul.
Proses pengujian diulangi dari tahap 2 hingga selesai.

Strategi integrasi top down memeriksa kendali utama atau modul keputusan
sedini mungkin. Dalam struktur program yang distrukturkan dengan baik,
modul keputusan biasanya ditempatkan di level atasnya. Jika masalah kendali
utama ada, pengenalan kesalahan sejak awal adalah penting. Jika pola depth-
first dipilih, fungsi lengkap software mungkin diimplementasikan dan
didemonstrasikan. Demonstrasi kemampuan fungsional sejak awal adalah
M1
M2 M3 M4
M5 M6 M7
M8
Sequence of modules that will be incorporated :
M1, M2, M3, M4, M5, M6, M7, M8
Telkom Polytechnic Jaminan Mutu Sistem Informasi


102 Uji Integrasi
pembangun kepercayaan diri bagi developer dan customer bahwa software
dapat dibuat dengan baik.
Meskipun kedengarannya sederhana, namun dalam praktek masalah logistik
dapat muncul. Modul-modul di level bawahnya belum tersedia saat
dibutuhkan, hanya diganti stub, dan itu tidak mewakili data aslinya. Banyak
pengujian boleh jadi tertunda akibat modul aktual belum tersedia. Pembangun
software akan kehilangan banyak kesempatan untuk melihat kasus-kasus
pengujian.

5.3.2 Integrasi Bottom up

Dalam metode ini komponen level paling bawah diuji pertama kali. Pengujian
ini tidak memerlukan modul stub. Proses diulang sampai komponen puncak
hirarki diuji. Pendekatan ini sangat membantu ketika seluruh atau kebanyakan
modul dari level pengeembangan yang sama sudah siap. Metode ini juga
membantu menentukan level pengembangan software yang memudahkan
pelaporan kemajuan pembuatan software dalam bentuk persentase.

Tahap-tahap untuk melakukan integrasi bottom up adalah sebagai berikut:
1. Komponen-komponen level bawah dikombinasikan ke dalam cluster
yang menjalankan subfungsi software khusus,
2. Driver ditulis untuk mengkoordinasikan kasus pengujian masukan dan
keluaran,
3. Cluster diuji,
4. Driver dihapus dan cluster dikombinasikan ke atas menelusuri
struktur program.
Contoh lihat Gambar 7.3.

Oleh karena integrasi dilakukan dalam arah ke atas, kebutuhan test driver yang
berbeda muncul. Dalam praktek, jika dua level puncak struktur program
diintegrasikan top down, jumlah driver dapat dikurangi, integrasi cluster dapat
disederhanakan. Menggabungkan pengujian bottom up dengan top down ini
sebagian orang menyebutnya pengujian sandwich.
5.3.3 Pengujian Regressi
Pengujian regressi adalah menjalankan kembali beberapa subset pengujian yang
telah dilakukan untuk meyakinkan bahwa perubahan tidak punya efek samping
yang tidak diharapkan. Perlu dilakukan mengingat setiap kali modul baru
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Uji Integrasi 103
PAGE 10
diintegrasikan, software berubah. Ada aliran data yang baru, atau I/O baru,
atau logika kendali yang baru. Perubahan ini boleh jadi punya efek samping
yang tidak diharapkan.



Gambar 5-3 Integrasi Bottom up
Kesalahan harus diperbaiki. Ketika dikoreksi, data atau program atau
dokumentasi berubah. Dengan pengujian regressi diharapkan perubahan ini
tidak menimbulkan kesalahan lain.

Menguji kembali setiap modul pada setiap kali modul baru ditambahkan adalah
tidak praktis dan tidak efisien. Seiring berlangsungnya uji integrasi, jumlah uji
regresi dapat meningkat dalam jumlah besar. Sekumpulan uji yang perlu
diulang perlu dirancang untuk menyertakan hanya modul berikut :
sampel uji representatif yang memeriksa seluruh fungsi software.
uji tambahan yang fokus pada fungsi-fungsi software yang
kemungkinan besar dipengaruhi perubahan.
pengujian yang fokus pada komponen-komponen software yang telah
berubah.

Modul kritis, critical module, adalah modul yang memiliki karakterisitik:
memenuhi beberapa kebutuhan software
memiliki level kendali yang tinggi
kompleks atau mudah salah
memiliki kebutuhan kinerja yang definitif.
Mc
Ma Mb
D1 D2 D3
Cluster
1
Cluster
2
Cluster
3
Components are combined to form clusters 1, 2, and 3;
Each clusters is tested using a driver;
D1, D2 are removed, cluster 1 and 2 are interfaced
directly to Ma;
also cluster 3 are interafced to Mb.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


104 Uji Integrasi
Modul kritis sebaiknya diuji seawal mungkin. Uji regresi sebaiknya fokus pada
fungsi modul kritis.

Pengujian regresi dapat dijalankan secara manual atau menggunakan tool
capture/playback otomatis. Tool ini memungkinkan capture kasus-kasus
pengujian dan urutan hasil-hasil playback sebagai bahan perbandingan.

5.3.4 Pengujian Smoke

McConnel mendefinisikan smoke test, uji asap, sebagai pemeriksaan
keseluruhan sistem dari status terakhir ke status terakhir berikutnya. Tidak
perlu uji menyeluruh, tetapi sanggup menunjukkan masalah penting. Uji
menyeluruh harus cukup menyeluruh sedemikian hingga jika suatu modul
sudah jadi, ia cukup stabil untuk uji-uji berikutnya.

Software perlu diuji setiap hari. Untuk ini, aktivitas berikut perlu dilakukan :
- komponen-komponen software diintegrasikan ke dalam build,
modul jadi;
- pengujian beruntun dirancang untuk menemukan kesalahan yang
dapat membuat deliveri software terlambat.
- Modul jadi diintegrasikan dengan modul jadi lain,
- keseluruhan produk diuji asap setiap hari.

Mungkin ada batas waktu pembuatan software yang ketat, yang kritis.
Pengujian setiap hari akan menunjukkan perkembangan uji integrasi pada
manajer dan praktisi dengan seksama. Pengujian ini menguntungkan dari sisi :
- resiko integrasi diminimalkan : kesalahan ditemukan sejak dini,
perbaikan dapat segera dilakukan, deliveri software dapat tepat
waktu.
- kualitas produk akhir diperbaiki : kesalahan coding, design, analsysis
dapat segera ditemukan, perbaikan rancangan dapat segera
dilakukan, kualitas produk akhir dapat lebih baik.
- diagnosa kesalahan dan perbaikan disederhanakan : biasanya kesalahan
integrasi ditemukan pada saat modul baru diintegrasikan, perbaikan
kesalahan dapat fokus pada modul baru tersebut dan modul lain yang
terkait.
- kemajuan lebih mudah diperiksa : setiap hari ada modul baru
diintegrasikan dan sudah diuji bekerja. Ini dapat meningkatkan moral
Telkom Polytechnic Jaminan Mutu Sistem Informasi


Uji Integrasi 105
PAGE 10
tim dan memberi indikasi bagus pada manajer bahwa kemajuan sudah
dibuat.

5.3.5 Dokumentasi Tes Integrasi
Seluruh rencana integrasi software dan gambaran uji khusus didokumentasi
dalam Test Specification, spesifikasi pengujian. Dokumen ini berisi rencana dan
prosedur pengujian. Ia merupakan produk kerja proses software, dan menjadi
bagian konfigurasi software.

Rencana pengujian berisi satu atau beberapa hal berikut:
- kapan dan bagaimana pengujian akan dilakukan
- daftar hal-hal yang akan diuji
- siapa yang menguji dan apa tanggung jawabnya
- apa yang diperlukan untuk pengujian
- lingkungan pengujian
- asumsi-asumsi
- apa yang perlu dilakukan ketika kesalahan ditemukan
- apa yang perlu dilakukan ketika kesalahan tidak ditemukan
- daftar istilah.

Kriteria berikut diterapkan di setiap tahap pengujian:
Interface integrity : integritas antarmuka setiap modul diuji, internal
(pemanggilan prosedur anak) atau eksternal (pemanggilan prosedur lain).
Functional validity : apakah modul dan integrasinya telah memberikan hasil
yang valid
Information content : apakah data lokal, global, file, basis data tetap
konsisten akibat eksekusi modul atau integrasinya.
Performance : apakah kinerja software sesuai dengan yang direncanakan.
Rencana pengujian perlu disiapkan untuk masing-masing kriteria.

Faktor-faktor yang sering berpengaruh dalam tes integrasi adalah:
manajemen konfigurasi software: gunakan versi komponen yang benar
untuk pengujian.
otomatiskan proses kompilasi jika diperlukan
dokumentasi: membantu tidak kehilangan error yang harus diatasi.
pelacakan kesalahan : uji integrasi akan kehilangan maknanya jika
kesalahan tidak dilacak dengan benar.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


106 Uji Integrasi
Riwayat hasil uji aktual, masalah atau keanehan yang muncul disampaikan
dalam Test Report, Laporan pengujian. Laporan ini ditambahkan dalam
Spesifikasi Test. Informasi di laporan pengujian ini penting untuk perawatan
software.

Nasehat Cem Kner dan kawan-kawan perlu direnungkan, Penguji terbaik
bukan siapa yang menemukan bug terbanyak...., penguji terbaik adalah siapa
yang mendapatkan sebanyak-banyaknya bug diatasi.
5.4 Uji integrasi dalam Konteks OO

Software berorientasi objek tidak memiliki struktur kendali hirarki, sehingga
integrasi top-down atau bottom-up kurang berarti. Integrasi boleh jadi dalam
dua bentuk : thread-based testing dan use-based testing.

Dalam thread-based testing, integrasi dilakukan terhadap sekumpulan class yang
dibutuhkan untuk menjawab satu input atau event untuk sistem. Setiap thread
diintegrasikan dan diuji individual. Uji regresi dilakukan untuk meyakinkan
bahwa tidak terjadi efek samping.

Dalam use-based testing, konstruksi sistem dimulai dengan menguji class-class
yang menggunakan class server paling sedikit. Class ini disebut class
independent. Setelah class independent diuji, class yang menggunakannya (class
dependent) diuji. Pengujian class dependent dilakukan berturut-turut, lapis demi
lapis, hingga keseluruhan sistem dibangun.

Driver dapat digunakan untuk menguji operasi-operasi di level terendah dan
untuk menguji sekumpulan class. Driver juga dapat digunakan untuk mengganti
antarmuka untuk menguji fungsionalitas sistem. Stub diperlukan untuk
mengganti class yang belum jadi ketika dibutuhkan kolaborasi antar class.

Ada yang menyebut class-class yang berkolaborasi dengan istilah cluster.
Cluster testing, pengujian cluster, memeriksa kolaborasi antar class dengan
beragam kasus. Perhatikan kasus kolaborasi di Gambar 7.4. Class yang
dipanggil dipersiapkan terlebih dahulu sebelum class yang memanggil, class
Validation Info disiapkan terlebih dahulu sebelum class Bank.



Telkom Polytechnic Jaminan Mutu Sistem Informasi


Uji Integrasi 107
PAGE 10


Gambar 5-4 Diagram kolaborasi class perlu untuk Uji Integrasi OO

5.5 Uji Arsitektur Client/Server

Arsitektur client/server menantang para penguji software. Sifat tersebarnya, isu
kinerjanya terkait dengan pemrosesan transaksi, kemungkinan penggunaan
sejumlah hardware yang berbeda, kompleksitas komunikasi jaringan,
kebutuhan melayani banyak client dari basis data terpusat atau tersebar,
koordinasi ragam aplikasi di server membuat pengujian arsitektur client/server
lebih sulit daripada aplikasi standalone.

Pada umumnya pengujian software client/server terjadi dalam tiga level yang
berbeda :
(1) aplikasi client individual diuji dalam mode disconnected dengan
server, operasi server dan jaringan belum diperhatikan,
(2) software client dan aplikasi server yang terkait diuji, tetapi operasi
jaringan belum diperhatikan,
(3) arsitektur client/server yang lengkap, termasuk operasi jaringan dan
kinerjanya diuji.




ATM
User Interface
ATM Bank
Cashier Account
Validation
Info
cardInserted
password
deposit
withdraw
accntStatus
terminate
verifyStatus
depositStatus
dispenseCash
printAccntStat
readCardInfo
getCashAmnt
verifyAcct
verifyPIN
verifyPolicy
withdrawReq
depositReq
acctInfo
openAcct
initialDeposit
authorizedCard
deauthorize
closeAcct
creditLimit
accntType
balance
withdraw
deposit
close
validPIN
validAcct
Telkom Polytechnic Jaminan Mutu Sistem Informasi


108 Uji Integrasi
Pendekatan pengujian berikut umum dilakukan pada aplikasi client/server:
application function tests : fungsionalitas aplikasi client diuji dalam tampilan
standalone.
server tests : koordinasi dan fungsi manajemen data dari server diuji.
Kinerja server juga diperiksa.
database tests : keakuratan dan integritas data yang disimpan di server
diuji. Transaksi yang dikirim aplikasi client diteliti untuk meyakinkan
bahwa data disimpan, dicari, diupdate dengan benar. Pengarsipan data
kadaluwarsa juga perlu diperiksa.
transaction tests : uji beruntun dibuat untuk meyakinkan bahwa setiap
jenis transaksi diproses sesuai kebutuhan. Uji berfokus pada kebenaran
pemrosesan dan isu kinerja (waktu pemrosesan dan volume transaksi).
network communication tests : uji ini memeriksa komunikasi di antara
node-node jaringan : pengiriman pesan, transaksi, dan lalu lintas jaringan
terkait tidak terjadi kesalahan. Keamanan jaringan menjadi bagian dari uji
ini.

Mungkin operational profile bermanfaat untuk merancang prioritas pengujian,
siapa melakukan apa dan seberapa sering.
5.6 Uji Navigasi, uji integrasi untuk aplikasi Web

Pengguna Web menelusuri aplikasi Web dalam cara yang sangat mirip dengan
pengunjung toko atau museum. Banyak alternatif lintasan dapat diambil
pengunjung, banyak perhentian dapat dibuat, banyak benda diamati dan
dipelajari, aktivitas pendaftaran anggota dimulai, atau ragam keputusan dibuat
di tengah jalan. Proses navigasi dapat diprediksi, dalam arti setiap kategori
pengunjung biasanya memiliki sejumlah tujuan tertentu. Proses navigasi dapat
juga tak dapat diprediksi, dalam arti pengunjung dapat melakukan hal tak
terduga terkait dengan tujuan semula setelah melihat dan mempelajari apa
yang ia lihat. Tugas uji navigasi adalah : (1) untuk meyakinkan bahwa
mekanisme penelusuran Web untuk setiap kategori pengguna Web
seluruhnya berfungsi dengan baik, (2) untuk memvalidasi bahwa setiap
navigation semantic unit (NSU) dapat dicapai oleh setiap kategori pengguna.





Telkom Polytechnic Jaminan Mutu Sistem Informasi


Uji Integrasi 109
PAGE 10
5.6.1 Uji sintaks navigasi

Tahap pertama uji navigasi bermula ketika menguji antarmuka. Mekanisme
navigasi diuji untuk meyakinkan bahwa masing-masing menjalankan fungsi yang
diharapkan. Splaine dan Jaskiel menyarankan mekanisme navigasi berikut diuji:
Navigation links : link internal, eksternal atau bagian halaman diuji.
Redirects : boleh jadi resource yang diminta pengguna tidak ada, dihapus,
atau namanya diubah, sehingga permintaan dialihkan ke halaman lain.
Apakah redirect sudah berfungsi?
Bookmarks : ketika bookmark dibuat, apakah judul halaman dapat diambil.
Frame and framesets : setiap frame berisi halaman Web khusus, framesets
berisi banyak frame yang dapat muncul dalam saat yang sama. Hal itu
yang perlu diuji, apakah benar isinya, benar layout dan ukurannya,
bagaimana kinerja downloadnya, dan kompatibilitas browsernya.
Site maps : link-link yang dipilih oleh pengguna apakah isi dan fungsinya
sudah sesuai dengan yang diharapkan.
internal search engines : bila ada ratusan dan ribuan halaman Web, apakah
fasilitas pencarian internal sudah berfungsi.
Beberapa jenis pengujian dapat dilakukan secara otomatis sementara yang lain
harus dirancang dan dijalankan manual. Pengujian dilakukan untuk memastikan
tidak ada kesalahan dalam mekanisme navigasi sebelum aplikasi Web online.

5.6.2 Uji Semantik Navigasi

Cachero mendefinisikan Navigation Semantic Unit (NSU) sebagai sekumpulan
informasi dan struktur navigasi terkait yang bekerja sama memenuhi sejumlah
kebutuhan pengguna terkait. Setiap NSU didefinisikan dengan sejumlah
lintasan navigasi yang menghubungkan node-node navigasi (e.g., halaman-
halaman Web, objek-objek isi, atau fungsionalitas). Setiap NSU mengijinkan
seorang pengguna mencapai kebutuhan mereka yang didefinisikan dalam satu
atau lebih use-case untuk setiap kategori pengguna. Uji Navigasi memeriksa
setiap NSU untuk meyakinkan bahwa kebutuhan-kebutuhan ini dapat dicapai.

Tim rekayasa Web perlu menjawab pertanyaan-pertanyaan berikut terkait
dengan setiap NSU:
- apakah NSU dapat dicapai keseluruhan tanpa kesalahan?
- apakah setiap node dalam NSU dapat dicapai?
- jika ada banyak lintasan, apakah setiap lintasan berfungsi?
Telkom Polytechnic Jaminan Mutu Sistem Informasi


110 Uji Integrasi
- apakah petunjuk navigasi benar?
- adakah mekanisme ke halaman sebelumnya atau homepage?
- jika node navigasi sangat besar, apakah semua berfungsi?
- jika sebuah node menjalankan suatu fungsi, namun pengguna tidak
memberi masukan yang lengkap, atau ada kesalahan lain apakah NSU
yang tersisa dapat dilengkapi?
- jika navigasi ditengah jalan, pengguna memilih NSU lain, apakah
pengguna dapat kembali ke tempat perhentian tadi dan memulai dari
sana?
- apakah setiap node dapat dicapai dari site map, apakah nama-nama
node dapat dipahami pengguna?
- jika sebuah node dapat diakses dari luar, apakah pengguna luar dapat
ke halaman sebelum atau sesudahnya?
- apakah pengguna tahu sekarang ada di posisi mana?

Uji navigasi sebaiknya dilakukan oleh sebanyak mungkin peserta yang berbeda.
Di tahap awal pengujian dilakukan oleh perekayasa Web, tahap berikutnya
dilakukan oleh project stakeholder, dan tim penguji independent, dan terakhir
pengguna nonteknik. Setiap orang perlu memeriksa navigasi aplikasi Web.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


Uji Integrasi 111
PAGE 10



Rangkuman



1. Uji integrasi dilakukan setelah uji unit sebelum uji sistem.
2. Pendekatan incremental lebih baik daripada pendekatan big bang.
3. Dalam aplikasi tradisional, integrasi dapat dilakukan top down atau bottom
up.
4. Integrasi top down menggabungkan modul dari atas ke bawah sepanjang
struktur kendali program.
5. Dalam konteks object oriented, integrasi dapat dilakukan thread-based atau
use-based.
6. Dalam arsitekur client/server, pengujian dilakukan terhadap aplikasi client,
aplikasi server terkait dan arsitektur client/server keseluruhan.
7. Dalam aplikasi Web, uji integrasi memeriksa setiap Navigation Semantic
Unit untuk meyakinkan setiap kebutuhan setiap kategori pengguna dapat
dicapai.






Kuis Benar Salah



1. Dalam uji integrasi, pendekatan big bang lebih baik daripada
pendekatan incremental.
2. Pada integrasi bottom up tidak diperlukan modul stub.
3. Pada integrasi top down pola depth-first diperlukan modul driver.
4. Modul critical diperlukan pada uji regresi.
5. Uji smoke diperlukan jika proyek dibatasi waktu.





Telkom Polytechnic Jaminan Mutu Sistem Informasi


112 Uji Integrasi




Pilihan Ganda



Petunjuk: Pilihlah jawaban yang paling tepat!


1.

Uji integrasi dilakukan setelah uji . sebelum uji .
A. sistem, unit D. design, coding
B. unit, sistem E. design, analysis
C. coding, design

2. Modul stub digunakan dalam uji integrasi :
A. Big bang D. Regressi
B. Top down E. Smoke
C. Bottom up

3. Uji integrasi dalam konteks orientasi objek akan melibatkan konsep
berikut, kecuali
A. top down integration D. cluster
B. thread-based integration E. collaboration classes
C. use-based integration

4. Yang perlu diuji dalam arsitektur client/server adalah hal-hal berikut, kecuali:
A. application function tests D. GUI tests
B. server tests E. network communication tests
C. database tests

5. Yang termasuk sintaks navigasi adalah berikut ini, kecuali:
A. Redirect D. Frame dan frameset
B. Navigation link E. Petunjuk navigasi
C. Bookmarks



Telkom Polytechnic Jaminan Mutu Sistem Informasi


Uji Integrasi 113
PAGE 10



Latihan


1. Apakah selalu perlu untuk membuat rencana pengujian tertulis
formal? Jelaskan.
2. Apakah pola depth-first atau breadth first dapat diterapkan dalam
integrasi bottom up? Jelaskan.
3. Mungkinkah menguji software orientasi objek menggunakan state
chart diagram? Jelaskan.
4. Apakah perbedaan utama database tests dan transaction tests dalam
aristektur client/server?
5. Apakah perbedaan pengujian sintaks navigasi dan semantik navigasi?

Telkom Polytechnic Jaminan Mutu Sistem Informasi


114 CVS
6 CVS




















Overview

Pada bagian ini kita akan memperlajari bersama mengenai apa itu CVS. Dan
bagaimana mengimplementasikannya dalam pengerjaan project aplikasi. Akan
dijelaskan fitur-fitur utama dari software CVS.




Tujuan

1. Mahasiswa memahami cara kerja CVS
2. Mahasiswa memahami bagaimana mengelola pembuatan software
menggunakan CVS

Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 115
PAGE 10
6.1 Overview
CVS adalah kependekan dari control version system. Kita dapat
menggunakannya untuk pencatat kontrol perubahan dari file source code yang
kita miliki dalam mengembangkan suatu sistem atau aplikasi tertentu.
Mengapa kita perlu menerapkan pencatatan control, saat bugs terjadi
pada aplikasi sehingga membutuhkan modifikasi dan mungkin kita baru dapat
mendeteksinya saat sudah jauh kita melakukan perubahan aplikasi. Namun,
dengan CVS, kita dapat dengan mudah membuka kembali versi-versi yang
lama dari source aplikasi kita sehingga dapat kita lakukan perubahan bagian
yang menyebabkan adanya bugs tersebut. Mungkin hal ini merupakan hal yang
besar, ketika managemen file pada managemen aplikasinya kurang baik.
Tentunya juga kita dapat menyimpan semua versi file yang sudah dibuat.
Namun jika kita simpan semua, dapat menghabiskan banyak disk space.
Sedangkan CVS akan menyimpan semua versi dari file kedalam sebuah file
dengan cara yang pintar, yaitu hanya menyimpan perubahan antar versinya.
CVS juga membantu kita, ketika kita menjadi bagian dari grup
(sekelompok orang)yang bekerja dalam project yang sama. Sehingga mudah
untuk dirubah antar satu dengan yang lain walaupun kita orang yang sangat
berhati-hati. Beberapa aplikasi editor source code lain yang ada diLinux seperti
Emacs, memiliki fitur yang tidak memungkinkan dua orang untuk memodifikasi
file yang sama dalam waktu yang bersamaan. Namun, jika orang lain mengedit
file tersebut menggunakan editor lain maka tidak ada lagi yang dapat
mengamankannya. CVS memproteksi masalah ini dengan memisahkannya
dengan direktori yang berbeda antar sesame editor source code. Setiap editor
akan bekerja didirektorinya sendiri dan biarkan CVS yang akan menyatukan
pekerjaannya setelah editor selesai mengerjakan code yang diharapkan.
CVS sendiri pertama kali dikembangkan oleh Dick Grune dengan
menggunakan shell scripts. Dan dipublikasikan pada newsgroup
comp.source.unix pada Juli 1986, namun masih banyak terdapat bugs
didalamnya. Baru pada April 1989, Brain Berliner mendesain ulang dan
mengkodekan CVS serta selanjutnya Jeff Polk membantu Brain dengan desain
modul CVS dan vendor branch support.
Anda dapat mendapatkan CVS melalui beberapa cara bahkan melalui free
download dari Internet. Untuk informasi lebih lanjut dan menunduh CVS serta
penjelasan CVS lainnya pada:
http://cvs.nongnu.org/
Telkom Polytechnic Jaminan Mutu Sistem Informasi


116 CVS
CVS dapat melakukan banyak hal untuk anda tetapi tidak semua yang
berkaitan dengan pengembangan software dapat dilakukan disini, berikut
penjelasannya.
- CVS bukan merupakan Compiler untuk menjalankan sistem
Walaupun repository dan file modul pengembangan aplikasinya dapat
berinteraksi dengan compiler (seperti makefile) tetapi keduanya
merupakan hal yang berbeda dan independent. Disini CVS lebih
kepada bagaimana menyimpan source tersebut dalam struktur yang
anda inginkan, dan bukan bagaimana meng-compile-nya. Sehingga jika
dalam melakukan compile source code membutuhkan file tambahan
lain, anda harus menambahkannya sendiri dan tidak masuk ke dalam
bagian yang ditangani oleh CVS
- CVS tidak dapat menggantikan peran management project.
Seorang Project Leader atau perwakilan management tetap harus
melakukan pengecekan secara berkala mengenai apa yang sudah
dikerjakan oleh pengembang software-nya dengan melakukan
pengecekan jadwal pengerjaan, merger point, branch names dan waktu
rilisnya.
- CVS tidak dapat membantu komunikasi antar developer
Jika terjadi perbedaan antar developer pengembang aplikasi pada
sebuah file sehingga program menjadi konflik, hal ini tidak dapat
dibantu oleh CVS. Konflik biasanya terjadi karena perbedaan cara
pandang atau lojik dari alur algoritma suatu aplikasi.
- CVS bukan alat testing program yang otomatis
- CVS tidak memiliki program built in untuk pemodelan proses dalam
aplikasi
6.2 Repository
Repositori CVS adalah tempat penyimpanan dari kopian seluruh file dan
direktori tempat anda bekerja pada control versi aplikasi anda. Secara umum,
anda tidak dapat langsung mengakses file repository. Anda dapat menggunakan
command dari CVS untuk mendapatkan kopian dari file yang anda ingin rubah
dari direktori kerja kita, lalu kita dapat bekerja menggunakan kopian tadi.
Setelah commit dan mengembalikannya ke repository. Didalam repository
tersimpan perubahan-perubahan yang sudah kita buat. Didalamnya juga
dicatat pada bagian mana anda buat, lalu kapan dirubahnya serta informasi lain
yang berguna.
Andapun dapat mengakses repository dengan beberapa skenario. Tidak
hanya ada yang dilokal computer kita tetapi dapat komputer lain disekitar
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 117
PAGE 10
kita, bahkan ke seluruh dunia selama masih memiliki jaringan. Untuk bisa
menjalankan pengaksesan ini, nama repositorinya dapat dimulai dengan access
method yang diinginkan. Contoh jika menggunakan access method :local: maka
anda akan mengakses direktori root dari repository kita
:local:/usr/local/cvsroot berarti kita mengakses repository di
/usr/local/cvsroot didalam komputer yang menjalankan CVS.
Sedangkan untuk skenario lainnya jika mengakses menggunakan / maka
berarti mengakses repositori lokal menggunakan :local: . Tetapi jika tanpa /
maka dapat memilih skenario :ext: atau :server: untuk mengakses repositori
anda.
Repositori file pada CVS terbagi pada 2 bagian. $CVSROOT/CVSROOT
berisi file administrasi untuk CVS dan lainnya untuk modul yang buat oleh
user.

6.2.1 Bagaimana Data disimpan di Repositori
Untuk anda sebenarnya tidaklah penting untuk mengetahui bagaimana
CVS menyimpan informasi didalam repositori. Faktanya bahwa format yang
anda akan selalu berubah dari masa lalu dan akan terus berubah menuju masa
depan. Semenjak semua user dengan berbagai metode mengakses repositori
menggunakan CVS command, Sehingga membuat pencatatan perubahan yang
terjadi menjadi penting.
Walaupun begitu, dalam beberapa skenario kitapun penting untuk
mengetahui bagaimana CVS menyimpan data pada repositori, sebagai contoh
untuk mengetahui bagaimana CVS mengkunci file yang anda akan akses atau
bagaimana file perimissions dari file yang ada direpositori.
6.2.2 Dimana file disimpan didalam repositori
Secara umum struktur dari repositori adalah directory tree yang
berkorespondensi kepada direktori kerja anda. Contohnya, misal anda
menggunakan repositori kerja di
/usr/local/cvsroot
Berikut tree dari repostori kerja tadi

/usr
|
+--local
| |
Telkom Polytechnic Jaminan Mutu Sistem Informasi


118 CVS
| +--cvsroot
| | |
| | +--CVSROOT
| (administrative files)
+--gnu
| |
| +--diff
| | (source code to GNU diff)
| +--rcs
| | (source code to RCS)
| +--cvs
| | (source code to CVS)
+--poltekproject
|
+--tc
| |
| +--man
| |
| +--testing
+--(poltekproject aplikasi lainnya)
Penulisan setiap file dalam direktori memiliki pencatatan history
menggunakan version control. Dan namanya akan berkorespondensi dengan
nama file yang ada dengan ditambahkan akhiran,v. Misalnya pada repositori
terdapat direktori poltekproject/tc akan berbentuk sebagai berikut:

$CVSROOT
|
+--poltekproject
| |
| +--tc
| | |
+--Makefile,v
+--backend.c,v
+--driver.c,v
+--frontend.c,v
+--parser.c,v
+--man
| |
| +--tc.1,v
|
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 119
PAGE 10
+--testing
|
+--testpgm.t,v
+--test2.t,v
File history berisi berbagai macam hal, bahkan informasi yang cukup ketika
melakukan revisi dari suatu file, log dari pesan commit dan username dari
orang yang melakukan commit. File history ini dikenal sebagai file RCS, sehingga
file ini juga kita kenal sebagai version control system.

6.2.3 File permissions
Semua file ,v dibuat dalam bentuk read-only dan anda diharapkan tidak
merubah permission dari file tersebut. Sedangkan directory yang ada didalam
repositori hanya bisa ditulis atau dirubah oleh orang yang memiliki
kewenangan untuk memodifikasi setiap file yang ada didalam directory
tersebut. Sehingga secara normal, anda harus membuat UNIX group yang
berisi orang uang boleh mengrubah file didalam project dan
mengkonfigurasikan repository bahwa merekalah pemilik direktori tersebut.
Artinya hanya anda yang dapat mengontrol akses dari file yang ada
berdasarkan direktorinya.
6.2.4 Attic
Suatu saat anda akan mendapat notifikasi dari CVS bahwa akan
menyimpankan file RCS ke dalam Attic. Misalnya didalam folder poltekproject
ada file backend.c, yang seharusnya berada di
/usr/local/cvsroot/poltekproject/tc/backend.c ,v
Tetapi berubah kedalam attic sehingga menjadi
/usr/local/cvsroot/poltekproject/tc/Attic/backend.c ,v
Itu sebenarnya tidak apa, sebab dari sisi user walaupun filenya berada didalam
folder attic, CVS tetap membantu anda tetap dalam trek dan membantu anda
untuk melihat ke dalam attic ketika dibutuhkan. Ketentuannya adalah, ketika
RCS file disipan didalam attic dan didalam statusnya memiliki status dead.
Maka state dead berarti filenya telah dipindahkan atau tidak pernah
ditambahkan untuk revisi.
6.2.5 Multiple Repositori
Pada waktu tertentu kita akan mendapati kondisi ketika anda memiliki
dua atau lebih development groups yang bekerja untuk beberapa proyek yang
Telkom Polytechnic Jaminan Mutu Sistem Informasi


120 CVS
berbeda dengan atau tidak menggunakan sharing source code, sehingga kita bisa
saja menggunakan lebih dari satu repositori.
Yang anda perlu lakukan adalah menghubungkan beberapa repositori
tersebut dengan repositori yang kita miliki dengan menggunakan variabel
CVSROOT environment, opsi -d pada CVS anda atau memberi kemudahan
kepada CVS untuk menggunakan repositori yang telah digunakan untuk
melakukan check out terhadap working directori.
Manfaat besar yang dapat kita dapatkan dari memiliki beberapa repositori
adalah anda dapat bekerja dibeberapa server yang ada. PadaCVS versi 1.10,
pengguna tidak dapat menjalankan perintah untuk merubah isi direktori dari
beberapa direktori, tetapi dengan menggunakan versi development dari CVS
anda dapat melakukan check out code dari beberapa sever kedalam direktori
kerja kita. CVS yang akan merubah dan mengurusi semua detail untuk
membuat koneksi ke beberapa server yang ada untuk menjalankan perintah
yang diinginkan. Berikut adalah contoh untuk mengeset direktori kerja:
cvs d server1:/cvs co dir1
cd dir1
cvs d server2:/root co sdir
cvs update
cvs co adalah perintah untuk mengeset direktori kerja dan cvs update
adalah perintah untuk mengontak server2 untuk mengupdate direktori
dir1/sdir dan server1 untuk mengupdate yang lainnya.
6.2.6 Membuat Repository
Kali ini kita akan coba membahas bagaimana membuat Repostori CVS
menggunakan berbagai metode yang ada baik akses lokal maupun akses
remote.
Untuk men-setup repositori CVS, pertama pilih mesin dan disk yang anda
mau untuk menyimpan histori dari revisi source file. Tentu saja anda dapat
memilih mesin yang memenuni persyaratan minimum dari CVS. Selanjutnya
anda juga persiapkan disk space yang cukup untuk menyimpan source dan
historinya. Tentunya dipertimbangkan berapa banyak developer yang akan
menggunakannya bersama-sama, disarankan menyiapkan 3 kali disk space dari
kebutuhan minimum project yang sedang dikerjakan.
Repositorinya juga harus dapat diakases (secara langsung maupun melalui
sistem jaringan berkas) dari semua mesin yang akan menggunakan service
CVS maupun mode lokal serta melalui protocol CVS.
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 121
PAGE 10
Untuk membuat repostori anda perlu menjalankan perintah cvs init.
Hal ini akan membuat repositori kosong pada CVS root tertentu menjadi ter-
setup untuk menjadi repositori CVS. Contoh:
cvs d /usr/local/cvsroot init
Penggunaan cvs init harus sendiri tidak dapat meng-overwrite file existing
yang ada didalam repositori, sehingga tidak berbahaya jika menjalankan cvs
init didalam repositori yang sudah ada.
6.2.7 Mem-backup repositori
Sebenarnya bukan merupakan hal yang aneh dalam pengelolaan file
didalam repositori, semua atau sebagian file dapat saja di recovery dari
kerusakan seperti file lain. Namun, dengan menggunakan CVS anda dapat
dengan mudah melakukan backup data project yang sedang dikerjakan. Anda
pun dapat melakukan penguncian CVS dengan menggunakan perintah cvs rf
1 untuk mengunci direktori repositori kerja kita.
Intinya adalah setiap pekerjaan yang anda lakukan selalu lakukan backup
menggunakan perintah cvs update dan anda dapat mengecek perubahan
yang terjadi menggunakan perintah cvs diff untuk melihat perubahan yang
terjadi. Sehingga suatu saat anda ingin melakukan rollback dapat dilakukan
dengan mudah.
6.2.8 Memindahkan Repository
Sama seperti membuat backup file dalam repositori sangat banyak seperti
membackup file lain. Jika Anda perlu untuk memindahkan repositori dari satu
tempat ke tempat lain dalam jumlah yang cukup banyak seperti hanya
memindahkan direktori anda.
Hal utama yang perlu dipertimbangkan adalah bahwa direktori kerja
menunjuk ke repositori. Cara paling mudah untuk berurusan dengan
pemindahan repositori adalah selalu menyesuaikan direktori kerja setiap
memindahkan repositori. Tentu saja, Anda akan ingin memastikan bahwa
direktori kerja lama telah diperiksa di sebelum dipindahkan, atau Anda
menemukan cara lain untuk memastikan bahwa Anda tidak akan kehilangan
perubahan apapun. Jika Anda benar-benar ingin menggunakan kembali
direktori kerja yang ada, itu harus dilakukan dengan operasi manual pada
CVS / Repositori file., untuk informasi tentang CVS / Repositori dan CVS /
Root file, tetapi kecuali Anda yakin tidak terganggunya sistem.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


122 CVS
6.2.9 Remote Repositories
Copy resource pekerjaan Anda dapat berada pada mesin yang berbeda
dari repositori sekarang. Menggunakan cvs dengan cara ini dikenal sebagai
operasi client/server. Anda menjalankan cvs pada sebuah mesin yang dapat me-
mount direktori pekerjaan Anda, yang dikenal sebagai client, dan memberitahu
untuk berkomunikasi dengan sebuah mesin yang dapat me-mount repositori,
yang dikenal sebagai server. Umumnya, menggunakan remote repositori
adalah seperti menggunakan metode lokal, kecuali format nama repositorinya
menggunakan:
[: Method:] [[user] [: password] @]hostname [: [port]] /path/to/repository
Password yang ada dalam nama repositori tidak dianjurkan selama proses
checkout, karena ini akan menyebabkan cvs untuk menyimpan kopian clear-text
pada setiap direktori harus dibuat cvs login terlebih dahulu.
Rincian detail apa yang perlu dibentuk tergantung pada bagaimana Anda
terhubung ke server.
Jika metode tidak ditentukan, dan nama repositori berisi ':', maka default
adalah ext atau server, tergantung pada platform anda.
6.3 Men-Setup File
Langkah pertama adalah membuat file dalam repositori. Hal ini dapat
dilakukan dalam beberapa cara yang berbeda.
6.3.1 Membuat direktori tree dari beberapa file
Ketika Anda mulai menggunakan cvs, Anda mungkin sudah memiliki
beberapa proyek yang terletak di bawah kontrol cvs. Dalam kasus ini cara
termudah adalah dengan menggunakan perintah impor. Sebuah contoh
mungkin adalah cara termudah untuk menjelaskan cara menggunakannya. Jika
file yang ingin Anda instal di cvs berada di 'wdir', dan Anda ingin mereka untuk
tampil dalam repositori sebagai '$ CVSROOT/poltekproject/rdir', Anda
dapat melakukan hal ini:

$ cd wdir
$ cvs import-m "Imported source" poltekproject/rdir poltek start

Kecuali jika Anda menyediakan pesan log dengan '-m' flag, cvs mulai
menjalankan editor dan meminta pesan. String 'poltek' adalah vendor tag, dan
'start' adalah release tag. Hal tadi mungkin tidak menegaskan tujuan dalam
konteks ini, tapi karena cvs memerlukan mereka, mereka harus ada.
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 123
PAGE 10
Anda sekarang dapat memverifikasi bahwa hal itu bekerja, dan
menghapus direktori source asli Anda.

$ cd ..
$ cvs checkout poltekproject/rdir # Penjelasan di bawah ini
$ Diff-r wdir poltekproject/rdir
$ Rm-r wdir
Menghapus original resource adalah ide yang baik, untuk memastikan
bahwa Anda tidak sengaja mengeditnya di wdir, melalui cvs. Tentu saja, akan
bijaksana untuk memastikan bahwa Anda memiliki backup dari resource
sebelum Anda menghapusnya.
Perintah checkout dapat mengambil nama modul sebagai argumen (seperti
yang telah dilakukan dalam semua contoh sebelumnya) atau nama path relatif
ke $ CVSROOT, seperti yang ada pada contoh di atas.
Anda juga dapat menggunakan hal ini untuk memeriksa bahwa permission
ter-setup kedalam direktori $ CVSROOT yang memang benar dan termasuk
kedalam grups yang sebenarnya.
Jika beberapa file yang ingin di impor adalah biner, Anda dapat
menggunakan menggunakan fitur wrappers untuk menentukan file mana yang
biner dan mana yang tidak.
6.3.2 Membuat directory tree dari awal

Untuk proyek baru, hal yang paling mudah yang dapat dilakukan adalah
dengan membuat struktur direktori yang kosong, seperti contoh berikut:
$ Mkdir tc
$ Mkdir tc/man
$ Mkdir tc/pengujian

Setelah itu, Anda dapat menggunakan perintah impor untuk membuat
korespondeksi struktur direktori (kosong) tadi yang ada di dalam repositori:
$ Cd tc
$ Cvs import-m "Created directory structure" poltekproject/dir poltek
start

Ini akan menambah poltekproject/dir sebagai direktori di bawah $
CVSROOT.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


124 CVS

Lalu gunakan checkout untuk membuat proyek baru. Kemudian, gunakan add
untuk menambahkan file (dan direktori baru) yang diperlukan.
$ Cd ..
$ Cvs co poltekproject/dir

Jangan lupa periksa apakah permission dari CVS di dalam direktori $
CVSROOT adalah dapat digunakan.
6.4 Mendefinisikan modul

Langkah berikutnya adalah untuk mendefinisikan module ke dalam file
'module'. Langkah ini sebenarnya tidak benar-benar diperlukan, tetapi modul
anda bisa menjadi lebih baik dalam pengelompokan bersama file dan direktori
yang terkait.

Dalam kasus sederhana langkah-langkah ini cukup untuk mendefinisikan untuk
digunakan pada sebuah modul.
1. Dapatkan copy dari file modul.
$ cvs checkout CVSROOT / modules
$ cd CVSROOT
2. Edit file dan menyisipkan sebuah baris yang mendefinisikan modul.
Anda dapat menggunakan baris berikut untuk menentukan modul
'Tc':
tc poltekproject/tc
3. Lakukan commit perubahan Anda ke file modul.
$ cvs commit-m "Added the tc module." modules
4. Lepaskan modules-nya dari modul.
$ cd ..
$ cvs release d CVSROOT

6.5 Revision
Untuk banyak penggunaan cvs, seseorang tidak perlu terlalu khawatir
tentang revision number; cvs akan memberikan nomor-nomor seperti 1.1, 1.2,
dan seterusnya, dan anda perlu tahu tenang itu. Namun, jika anda memilih
untuk lebih memanfaatkan pengetahuan dan control, anda dapat mempelajari
penjelasan berikut tentang bagaimana cvs memberikan nomor revisi.
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 125
PAGE 10
Jika seseorang ingin melacak serangkaian revisi yang melibatkan lebih dari
satu file, seperti yang revisi masuk ke rilis tertentu, satu menggunakan tag,
yang merupakan revisi simbolis yang dapat ditetapkan ke angka revisi dalam
setiap file.
6.5.1 Revision Number
Setiap versi file yang memiliki nomor revisi yang unik. Nomor revisi
seperti '1 ', '1 ,2', '1 .3.2.2 'atau bahkan '1 .3.2.2.4.5'. Sebuah angka revisi
bahkan selalu mempunyai jumlah periode-bilangan desimal yang terpisah.
Secara default revisi 1,1 adalah revisi pertama dari sebuah file. Setiap revisi
berturut-turut diberi nomor baru dengan meningkatkan jumlah paling kanan
demi satu. Gambar berikut menampilkan beberapa revisi, dengan revisi yang
lebih baru ke kanan.
! 1.1 ! ----! 1.2 ! ----! 1.3 ! ----! 1.4 ! ----! 1.5 !

Hal ini juga dapat diakhiri dengan angka yang mengandung lebih dari satu
periode, misalnya '1 .3.2.2 ', Mewakili revisi revisi seperti pada cabang.
6.5.2 Version, revisions and release
Sebuah file dapat memiliki beberapa versi, seperti dijelaskan di atas.
Demikian pula, produk perangkat lunak dapat memiliki beberapa versi.
Sebuah produk perangkat lunak sering diberi nomor versi seperti '4 .1.1 '.
Versi dalam pengertian pertama disebut revisi dalam dokumen ini, dan versi
dalam pengertian kedua disebut rilis. Untuk menghindari kebingungan, kata
versi ini hampir tidak pernah digunakan dalam dokumen ini.

6.5.3 Assigning revisions

Secara default, cvs akan memberikan angka revisi dengan membiarkan angka
pertama sama dan penambahan pada angka kedua. Sebagai contoh, 1.1, 1 ,2, 1
.3, dll
Ketika menambahkan file baru, angka kedua akan selalu menjadi satu dan
angka pertama akan sama dengan angka pertama tertinggi dari setiap file
dalam direktori tersebut. Sebagai contoh, direktori saat ini file yang berisi
nomor revisi tertinggi 1.7, 3.1, dan 4,12, maka file tambahan akan diberikan
Telkom Polytechnic Jaminan Mutu Sistem Informasi


126 CVS
angka revisi 4.1. (Bila menggunakan fungsi client/server cvs, hanya file yang
benar-benar dikirim ke server-lah yang dianggap.)
Memang tidak ada alasan untuk terlalu peduli terhadap angka-revisi
sebab dapat lebih mudah untuk memperlakukan penomoran revisi dengan
menggunakan penomoran internal cvs, dan tag menyediakan cara yang lebih
baik untuk membedakan antara hal-hal seperti rilis 1 versus rilis 2 dari
produk Anda. Namun, jika Anda ingin mengatur angka revisi, anda dapat
menggunakan opsi '-r' untuk melakukan perintah cvs commit untuk
melakukannya. Opsi '-r' mengimplikasikan opsi '-f', dalam arti bahwa hal itu
menyebabkan file yang akan di-commit bahkan ketika tidak dilakukan
perubahan.
Sebagai contoh, untuk membawa semua file Anda ke revisi 3.0 (termasuk
yang belum berubah), Anda dapat menggunakan:
$ cvs commit-r 3.0
Perhatikan bahwa nomor yang sudah Anda tentukan dengan '-r' harus
lebih besar daripada angka revisi yang ada. Artinya, jika revisi 3,0 ada, Anda
tidak dapat melakukan 'cvs commit -r 1.3'. Jika Anda ingin mempertahankan
beberapa rilis secara paralel, Anda perlu menggunakan Branching.
6.6 Add, remove, dan renaming file dan direktori
Dalam perjalanan pengerjaan proyek, tentu akan sering menambahkan file
baru. Demikian juga dengan melakukan penghapusan atau pengubahan nama,
atau direktori. Kegiatan tadi akan sering dilakukan dan anda ingin cvs untuk
mencatat perubahan yang terjadi, tetapi mekanisme yang sebenarnya sangat
bergantung kepada situasi yang terjadi.
6.6.1 Menambahkan file kedalam directory

Untuk menambahkan file baru ke direktori, anda dapat mengikuti langkah-
langkah berikut ini.
Anda harus memiliki copy file karja dari direktori.
Buat file baru di dalam copy file kerja Anda dari direktori.
Gunakan 'cvs add filename' untuk memberitahu cvs untuk mengontrol
versi file. Jika file berisi data biner, tentukan spesifik '-kb'.
Gunakan 'cvs commit filename' untuk memeriksa file didalam repositori.
Pengembang lain tidak dapat melihat file kerja tadi sampai Anda melakukan
langkah ini.
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 127
PAGE 10
Anda juga dapat menggunakan perintah add untuk menambahkan
direktori baru.
Tidak seperti kebanyakan perintah lain, maka perintah add adalah tidak
rekursif. Anda harus secara eksplisit menamai file dan direktori yang Anda
ingin ditambahkan ke repositori. Namun, setiap direktori perlu ditambahkan
secara terpisah sebelum Anda dapat menambahkan file baru ke direktori
tersebut. Contoh:
$ mkdir -p foo/bar
$ cp ~/myfile foo/bar/myfile
$ cvs add foo foo/bar
$ Cvs add foo/bar/myfile
cvs add [-k kflag] [-m message] files. . . [Command]
Urutan kerja file yang akan ditambahkan ke repositori. File atau direktori
yang telah ditentukan dengan add harus sudah ada di direktori kerja saat ini.
Untuk menambahkan keseluruhan hirarki direktori baru ke source repositori
(misalnya, file yang diterima dari vendor pihak ketiga), gunakan perintah
import saja.
File tambahan tidak akan ditempatkan ke dalam source repositori sampai
Anda menggunakan commit untuk membuat perubahan permanen.
Melakukan perintah add pada file yang telah dihapus dengan perintah remove
akan membatalkan efek dari perintah remove, kecuali perintah commit ikut
campur.
Opsi '-k' digunakan untuk menentukan pilihan cara yang secara default
sehingga file ini akan dilakukan check out.
Opsi '-m' digunakan untuk menetapkan description (keterangan) untuk file.
Deskripsi ini akan muncul dalam history log. Hal ini juga akan disimpan ke
dalam version history dalam repositori ketika file tersebut sedang di commit.
Perintah log digunakan untuk menampilkan deskripsi tadi. Deskripsi dapat
diubah dengan menggunakan 'admin-t'. Jika Anda menghilangkan flag '-m
description', string kosong dapat anda gunakan karena tidak akan lagi diminta
untuk deskripsi.
Sebagai contoh, perintah berikut menambahkan file 'backend.c' ke
repositori:
$ cvs add backend.c
$ cvs commit-m "Early version. Not yet compilable." backend.c
Telkom Polytechnic Jaminan Mutu Sistem Informasi


128 CVS
Ketika Anda menambahkan file tersebut makan akan ditambahkan hanya
pada cabang tempat Anda bekerja saat ini. Kemudian anda dapat
menggabungkan penambahan cabang lain jika anda ingin.
6.6.2 Menghapus file
Direktori telah berubah. File baru ditambahkan, dan file lama telah
menghilang. Namun suatu saat, Anda ingin dapat mengambil kemabli salinan
rilis file yang lama.
Berikut adalah beberapa yang dapat Anda lakukan untuk menghapus salah
satu file, tapi tetap masih bisa mengambil file lama itu:
Pastikan bahwa Anda belum membuat modifikasi yang tidak terikat ke
file. Anda juga dapat menggunakan perintah status atau update. Jika Anda
menghapus file tanpa melakukan perubahan, Anda tentu saja tidak dapat
mengambil berkas ini sebelum Anda menghapusnya.
Hapus file dari copy pekerjaan Anda dari direktori. Anda dapat
menggunakan perintah rm misalnya.
Gunakan 'cvs remove filename' untuk memberitahu cvs bahwa Anda
benar-benar ingin menghapus file.
Gunakan 'cvs commit filename' untuk secara benar-benar telah
melakukan penghapusan berkas dari repositori.
Ketika Anda melakukan penghapusan file, cvs mencatat fakta bahwa file
tidak ada lagi. Hal ini dimungkinkan untuk file hanya ada di beberapa cabang
dan bukan pada yang lain, atau untuk kembali menambah file lain dengan nama
yang sama nanti. cvs akan secara tepat membuat atau tidak membuat file, yang
didasarkan pada opsi '-r' dan '-D' ditetapkan kepada checkout atau update.
cvs remove [options] files. . . [Command]
Lalu file anda akan dihapuskan dari repositori (file-file yang belum dihapus
dari direktori kerja tidak diproses). Perintah ini tidak secara benar-benar
menghapus file dari repositori sampai Anda melakukan penghapusan.
Berikut adalah contoh menghapus beberapa file:
$ cd test
$ rm *. c
$ cvs remove
cvs remove: Removing
cvs remove: scheduling a.c for removal
cvs remove: scheduling b.c for removal
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 129
PAGE 10
cvs remove: gunakan 'cvs commit' untuk menghapus file-file ini secara
permanen
$ cvs ci -m "removed unneeded files"
cvs commit: Examining
cvs commit: committing
Untuk kenyamanan Anda dapat menghapus file dan menggunakan cvs remove
dalam satu langkah, dengan menggunakan opsi '-f'. Misalnya, contoh di atas
juga dapat dilakukan seperti ini:
$ cd test
$ cvs remove -f *.c
cvs remove: scheduling a.c for removal
cvs remove: scheduling b.c for removal
cvs remove: gunakan 'cvs commit' untuk menghapus file-file ini secara
permanen
$ cvs ci-m "Hapus file yang tidak dibutuhkan"
cvs commit: Examining
cvs commit: Committing

Jika Anda mengeksekusi remove file, dan kemudian berubah pikiran sebelum
melakukan commit, Anda dapat membatalkan penghapusan dengan perintah
tambahan.
$ ls
CVS ja.h oj.c
$ rm oj.c
$ Cvs remove oj. C
cvs remove: scheduling oj.c for removal
cvs remove: gunakan 'cvs commit' untuk menghapus file ini secara
permanen
$ cvs add oj.c
U oj.c
cvs add: oj.c, version 1.1.1.1, resurrected

Jika Anda menyadari kesalahan Anda sebelum Anda menjalankan perintah
remove dapat Anda gunakan update untuk menghidupkan kembali file:
$ rm oj.c
Telkom Polytechnic Jaminan Mutu Sistem Informasi


130 CVS
$ cvs update oj. C
cvs update: warning: oj.c was lost
U oj.c

Bila Anda menghapus file tersebut maka akan dihapus hanya pada cabang
tempat Anda bekerja. Anda kemudian dapat menggabungkan kepindahan ke
cabang lain jika anda inginkan.
6.6.3 Menghapus direktori
Dalam konsep, menghapus direktori ini agak mirip dengan menghapus file
seperti Anda ingin direktori untuk tidak ada dalam direktori kerja saat ini,
tetapi Anda juga ingin dapat mengambil rilis lama di mana direktori ada.
Cara lain yang dapat Anda pakai untuk menghapus sebuah direktori
adalah dengan menghapus semua file di dalamnya. Anda tidak menghapus
direktori itu sendiri, tidak ada cara untuk melakukan itu. Sebaliknya Anda
dapat menggunakan opsi '-P' pada perintah cvs update atau cvs checkout,
yang akan menyebabkan cvs untuk membuang direktori kosong dari direktori
kerja. (Perhatikan bahwa cvs export selalu menghapus direktori kosong.)
Mungkin cara terbaik untuk melakukan ini adalah dengan selalu menentukan
opsi '-P' secara spesifik, jika anda ingin direktori kosong diletakkan ke sebuah
file dummy (misalnya '. keepme') di dalamnya untuk mencegah opsi '-P'
menghilangkannya.
Perhatikan bahwa '-P' tersirat dalam '-r' atau '-D' pilihan checkout.
Dengan cara ini, cvs akan dapat menciptakan direktori benar atau tidak
tergantung pada apakah versi tertentu Anda memeriksa mengandung file
dalam direktori tersebut.
6.6.4 Memindahkan dan mengubah nama file
Memindahkan file ke direktori lain atau mengubah nama file tidaklah sulit,
tapi beberapa metode tambahan pada aplikasi ini mungkin akan sulit contoh :
Memindahkan atau mengubah nama direktori bahkan lebih keras.
Contoh di bawah ini menganggap bahwa file lama yang berganti nama menjadi
baru.
a. Cara biasa untuk melakukan rename
Seperti biasa untuk memindahkan file adalah dengan menyalin file lama ke
yang baru, dan kemudian mengeluarkan perintah cvs biasa untuk menghapus
file lama dari repositori, dan menambahkan file baru itu.
$ mv old new
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 131
PAGE 10
$ cvs remove old
$ cvs add new
$ cvs commit-m "rename old to new" old new
Ini adalah cara paling sederhana untuk memindahkan file, dan tidak rawan
kesalahan, dan akan melakukan pencatatan history dari apa yang telah
dilakukan. Perhatikan bahwa untuk mengakses history dari file Anda harus
menentukan nama yang lama atau baru, tergantung pada bagian mana dari
sejarah yang akanAnda mengakses. Sebagai contoh, cvs log old akan
memberikan log sampai saat anda melakukan pengubahan nama.
Ketika file baru anda lakukan commit maka nomor revisi akan mulai lagi,
biasanya di 1.1, namun jika dirasa mengganggu Anda, gunakan opsi '-r rev'
untuk commit.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


132 CVS
b. Memindahkan history file
Metode ini lebih berbahaya, karena melibatkan memindahkan file di
dalam repositori. Baca seluruh bagian ini sebelum mencoba!
$ cd $ CVSROOT/dir
$ mv old, v new, v

Keuntungan:
Log perubahan utuh dijaga.
Nomor revisi tidak terpengaruh.
Kekurangan:
Rilis file lama tidak dapat dengan mudah diambil dari repositori. (File akan
ditampilkan sebagai baru bahkan dalam revisi dari waktu sebelum berganti
nama).
Tidak ada informasi log ketika file diubah namanya.
Hindari hal-hal yang mungkin terjadi jika seseorang mengakses file sejarah
saat Anda pindah itu. Pastikan tidak ada orang lain menjalankan salah satu dari
perintah cvs saat Anda memindahkannya.
c. Menyalin file history
Dengan cara ini juga melibatkan modifikasi langsung ke repositori.
Metode ini aman, tetapi bukan tanpa kekurangan.
# Salin RCS file dalam repositori
$ cd $CVSROOT/dir
$ cp lama, v baru, v
# Hapus file lama
$ cd ~/dir
$ rm old
$ Cvs remove old
$ cvs commit old
# Hapus semua tag dari baru
$ cvs update new
$ cvs log new # Ingat non branch tag names
$ cvs tag -d tag1 new
$ cvs tag -d tag2 new
...

Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 133
PAGE 10
Dengan menghapus tag anda akan dapat memeriksa revisi versi lama.
Keuntungan:
Memeriksa file kerja revisi versi lama dengan benar, selama Anda
menggunakan opsi '-rtag' dan bukan '-Ddate' untuk mengambil revisi.
Log perubahan utuh dijaga.
Penomoran revisi tidak terpengaruh.
Kekurangan:
Anda tidak dapat dengan mudah melihat history file setelah dilakukan rename.
6.6.5 Memindahkan dan mengubah nama direktori
Seperti biasa untuk mengubah nama atau memindahkan suatu direktori
adalah untuk mengubah nama atau memindahkan setiap file di dalamnya
seperti yang dijelaskan pada bagian atas. Kemudian anda dapat memeriksa
dengan menggunakan opsi -P.
Jika Anda benar-benar ingin merubah repositori dengan melakukan
pengubahan nama atau penghapusan sebuah direktori di repositori, Anda
dapat melakukannya hal-hal seperti ini:
1. Menginformasikan setiap orang yang memiliki salinan atau mengakses
direktori yang akan diubah namanya. Mereka harus melakukan commit semua
perubahan yang mereka lakukan dalam semua salinan dari proyek yang ada
didalam direktori yang akan dihapus, dan menghapus semua catatan pekerjaan
dalam file kerja pada proyek, sebelum Anda mengambil langkah-langkah
seterusnya ini.
2. Ubah nama direktori di dalam repositori.
$ cd $ CVSROOT/parent-dir
$ mv old-dir new-dir
3. Memperbaiki administrasi cvs file, jika diperlukan (misalnya jika Anda
mengganti nama seluruh modul).
4. Memberitahu semua orang bahwa mereka dapat melihat lagi
perubahan dan dapat melanjutkan pekerjaan.
Jika seseorang punya copy pekerjaan dalam perintah cvs akan
menghentikan pekerjaannya, sampai ia menghapus direktori yang menghilang
di dalam repositori.
Saran untuk anda, lebih baik untuk memindahkan file dalam direktori
daripada memindahkan seluruh direktorinya. Jika Anda memindahkan
direktori Anda sehingga justru tidak dapat mengambil kembali versi lama
Telkom Polytechnic Jaminan Mutu Sistem Informasi


134 CVS
dengan benar, karena mereka mungkin tergantung pada nama direktori
asalnya.
6.7 Multiple Developers
Bila lebih dari satu orang bekerja pada sebuah proyek perangkat lunak
sehingga semuanya menjadi lebih rumit. Contoh, dua orang mencoba untuk
mengedit file yang sama secara bersamaan. Satu solusi, yang dikenal sebagai
penguncian file atau reserved checkout, adalah untuk hanya mengijinkan satu
orang untuk mengedit setiap file pada suatu waktu. Ini adalah satu-satunya
solusi dengan sistem kontrol versi, termasuk Rcs dan sccs. Saat ini cara yang
biasa untuk mendapatkan reserved checkout dengan cvs menggunakan perintah
cvs admin -1. Ini tidak semudah mengintegrasikan cvs sebagai fitur
pengecekan, seperti dijelaskan dibawah ini, sehingga saat anda mau
menggunakan fungsi reserved checkout sebagai salah satu solusi. Hal ini juga
dapat digunakan untuk memakai fitur pengecekan yang diuraikan dibawah ini,
bersama-sama dengan prosedur yang sesuai (tidak dijalan oleh perangkat
lunak), untuk menghindari memiliki dua orang mengedit pada saat yang sama.
Model default menggunakan cvs dikenal sebagai Unreserved checkout.
Dalam model ini, pengembang dapat mengedit copy pekerjaan mereka sendiri
dari sebuah file secara bersamaan. Orang pertama yang melakukan
perubahan-nya otomatis tidak memiliki cara untuk mengetahui bahwa orang
lain telah mulai mengeditnya. Sedangkan yang lain akan mendapatkan pesan
kesalahan ketika mereka mencoba untuk melakukan file. Mereka harus
kemudian gunakan perintah cvs untuk membawa copy pekerjaan mereka
menjadi up to date dengan revisi pada repositori. Proses ini dijalankan secara
otomatis.
cvs juga mendukung mekanisme yang memfasilitasi berbagai jenis
komunikasi, tanpa secara benar-benar menegakkan aturan seperti checkout
reserved lakukan.
6.8 Revision Management
Seteah Anda telah membaca sejauh ini, Anda mungkin memiliki
pemahaman yang cukup bagus di cvs apa yang bisa lakukan untuk Anda. Bab
ini berbicara sedikit tentang hal-hal yang masih harus anda putuskan.
Jika Anda melakukan pengerjaan pekerjaan sendirian dengan
menggunakan cvs anda bisa saja melewatkan bab ini. Pertanyaannya bab ini
menjadi lebih penting ketika lebih dari satu orang yang bekerja di sebuah
repositori.
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 135
PAGE 10
Kapan melakukan commit?
Grup Anda harus menentukan kebijakan untuk penggunaan commit.
Beberapa kebijakan yang mungkin, dan mungkin sesuai dengan pengalaman
Anda bersama cvs mungkin akan dengan mudah menemukan apa yang sesuai
untuk Anda.
Jika Anda melakukan commit file terlalu cepat Anda mungkin melakukan
committ file yang bahkan saat belum dikompilasi. Jika pasangan Anda meng-
update source kerjanya untuk menyertakan file kerja bersama, dia tidak akan
mampu untuk mengkompilasi kode. Di sisi lain, orang lain tidak akan dapat
memperoleh manfaat dari perbaikan yang Anda lakukan pada kode jika Anda
pun melakukan commit dengan jarang, dan konflik mungkin akan lebih terjadi
jika sudah begini.
Hal ini umum untuk hanya komit file setelah memastikan bahwa file telah
dapat dikompilasi. Beberapa referensi lain bahkan mengharuskan file lulus test
suite. Kebijakan seperti ini dapat dilaksanakan menggunakan file commitinfo
Anda harus berpikir dua kali sebelum Anda menerapkan seperti konvensi
bersama. Dengan membuat lingkungan pengembangan terlalu dikontrol
mungkin menjadi terlalu diatur dan dengan demikian bisa terjadi hal-hal
kontra-produktif terhadap tujuan sebenarnya, yaitu adalah untuk
mendapatkan perangkat lunak yang dideskripsikan bersama.


Telkom Polytechnic Jaminan Mutu Sistem Informasi


136 CVS



Rangkuman



CVS adalah kependekan dari version control system. Kita dapat
menggunakannya untuk pencatat kontrol perubahan dari file source code yang
kita miliki dalam mengembangkan suatu sistem atau aplikasi tertentu.

CVS dapat melakukan banyak hal untuk anda tetapi tidak semua yang
berkaitan dengan pengembangan software dapat dilakukan disini, berikut
penjelasannya.
- CVS bukan merupakan Compiler untuk menjalankan sistem
- CVS tidak dapat menggantikan peran management project.
- CVS tidak dapat membantu komunikasi antar developer
- CVS bukan alat testing program yang otomatis
- CVS tidak memiliki program built in untuk pemodelan proses dalam aplikasi

Repositori CVS adalah tempat penyimpanan dari kopian seluruh file dan
direktori tempat anda bekerja pada control versi aplikasi anda. Secara umum,
anda tidak dapat langsung mengakses file repository. Anda dapat menggunakan
command dari CVS untuk mendapatkan kopian dari file yang anda ingin rubah
dari direktori kerja kita, lalu kita dapat bekerja menggunakan kopian tadi.
Setelah commit dan mengembalikannya ke repository. Didalam repository
tersimpan perubahan-perubahan yang sudah kita buat. Didalamnya juga
dicatat pada bagian mana anda buat, lalu kapan dirubahnya serta informasi lain
yang berguna.



Langkah pertama adalah membuat file dalam repositori. Hal ini dapat
dilakukan dalam beberapa cara yang berbeda.
- Membuat direktori tree dari beberapa file
- Membuat directory tree dari awal

Untuk banyak penggunaan cvs, seseorang tidak perlu terlalu khawatir tentang
revision number; cvs akan memberikan nomor-nomor seperti 1.1, 1.2, dan
seterusnya, dan anda perlu tahu tenang itu. Namun, jika anda memilih untuk
Telkom Polytechnic Jaminan Mutu Sistem Informasi



CVS 137
PAGE 10
lebih memanfaatkan pengetahuan dan control, anda dapat mempelajari
penjelasan berikut tentang bagaimana cvs memberikan nomor revisi.

Bila lebih dari satu orang bekerja pada sebuah proyek perangkat lunak
sehingga semuanya menjadi lebih rumit. Contoh, dua orang mencoba untuk
mengedit file yang sama secara bersamaan. Satu solusi, yang dikenal sebagai
penguncian file atau reserved checkout, adalah untuk hanya mengijinkan satu
orang untuk mengedit setiap file pada suatu waktu. Ini adalah satu-satunya
solusi dengan sistem kontrol versi, termasuk Rcs dan sccs. Saat ini cara yang
biasa untuk mendapatkan reserved checkout dengan cvs menggunakan
perintah cvs admin -1. Ini tidak semudah mengintegrasikan cvs sebagai fitur
pengecekan, seperti dijelaskan dibawah ini, sehingga saat anda mau
menggunakan fungsi reserved checkout sebagai salah satu solusi.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


138 CVS


Latihan


Buatlah sebuah program kecil bersama teman sekelompok anda dengan
ketentuan programnya memiliki modul sebanyak anggota kelompok anda
sehingga setiap anggota kelompok akan memiliki tanggung jawab masing-
masing. Lalu buat 1 repositori disalah satu laptop/computer di tim anda dan
mulailah mengerjakan project menggunakan CVS

Telkom Polytechnic Jaminan Mutu Sistem Informasi



Robot Data Entry 139
PAGE 10
7 Robot Data Entry


















Overview

Pada bab ini akan dibahas mengenai sebuah tool yang bernama iMacros yang
dapat berfungsi untuk melakukan pengisian form web site secara otomatis
dan berulang ulang. Sebenarnya masih banyak kegunaan iMacros yang lain
diantaranya adalah Browser Automation, Data Extraction, Image Recognition
dan lain-lain.



Tujuan

1. Mahasiswa mengerti tools robot data entry
2. Mahasiswa mengerti dan memahami cara menggunakan tools robot
data entry.

Telkom Polytechnic Jaminan Mutu Sistem Informasi


140 Robot Data Entry
7.1 Pendahuluan

Dalam melakukan pengujian kita diharuskan untuk menginputkan data uji yang
jumlahnya cukup banyak. Hal ini tentu saja akan membutuhkan waktu dan
tenaga lebih untuk melakukan pengujian. Salah satu cara untuk mengurangi
beban dalam melakukan pekerjaan ini adalah dengan menggunakan tool/ alat
bantu untuk penginputan data (robot data entry). Salah satu tool tersebut adalah
iMacros yang merupakan Macro recorder berbasis web pertama di dunia.
7.2 Pengenalan iMacros
iMacros merupakan macro recorder berbasis web pertama di dunia yang
memungkinkan kita untuk melakukan surfing pada web dan mengulanginya.
Web browser sekarang ini mungkin merupakan perangkat lunak yang paling
banyak digunakan. Tetapi banyak pekerjaan yang dilakukan berulang-ulang
menggunakan web browser misalkan memeriksa web site yang sama secara
berulang-ulang, mengingat password, melakukan pencarian menggunakan
search engine, melakukan pengujian terhadap web site, dan lain-lain. Dengan
menggunakan iMacros kita dapat merekam pekerjaan-pekerjaan tersebut dan
dapat mengeksekusinya kembali pada saat kita membutuhkannya.
Kegiatan-kegiatan browsing, pengisian form pengklikan, dan pencarian
informasi dapat direkam kedalam sebuah makro.

iMacros merupakan web automation tool yang digunakan oleh lebih dari 1juta
pengguna pada 78 negara didunia (termasuk untuk versi freeware).

Telkom Polytechnic Jaminan Mutu Sistem Informasi



Robot Data Entry 141
PAGE 10


Image: The iMacros Scripting Edition includes a powerful web scripting
component (API) with an eight-year-ongoing process of refinement and new
features.

System Requirements
Windows Vista, Windows XP, Windows 7, Windows Server
2000/2003/2008.
Telkom Polytechnic Jaminan Mutu Sistem Informasi


142 Robot Data Entry
Windows 32-bit and 64-bit systems supported (Native 64-bit Scripting
Interface).
Microsoft Internet Explorer 6, 7 or 8.
Mozilla Firefox Version 2 or 3 (optional, only for iMacros Firefox Add-
On).
256MB of RAM (512MB recommended).
At least 10 MB of available hard-disk space.

Alasan menggunakan iMacros
Software yang paling sering dibuka saat ini adalah web browser.
Banyak terjadi pengulangan, seperti mengecek situs yang sama setiap
hari, mengingat password, perintah dijalankan pada saat browsing
seperti mengisi form, klik tombol dan pengambilan informasi ,dsb.

7.3 Kegunaan iMacros
Basic Function
1. Browser Automation
iMacros memungkinkan kita untuk merekam dan me-replay kegiatan-
kegiatan yang kita lakukan menggunakan web browser. iMacros secara
terprogram berinteraksi dengan semua web site. iMacros dapat
melakukan pengisian form, serta dapat mengautomatiskan proses download
dan upload teks, gambar, file, dan halaman web. Kita dapat melakukan
import atau eksport data dari atau menjadi file CSV dan XML, database
atau sumber yang lain dari aplikasi berbasis web. iMacros juga
menyediakan fitur untuk penanganan file PDF, pengambilan screenshot,
mensimulasikan user agent dan koneksi ke proxy server. Antarmuka
scripting yang dimiliki oleh iMacros memberikan kita program kontrol
secara penuh pada web browser sehingga hampir semua pekerjaan-
pekerjaan yang rumit dapat di kelola dengan menggunakan skrip. iMacros
dapat digunakan dengan semua bahasa skripting atau bahasa
pemrograman.

2. Data Extraction
iMacros dapat melakukan pekerjaan yang merupakan kebalikan dari proses
form filling (pengisian form) yaitu menemukan dan melakukan ekstraksi
teks dari web site seperti harga, deskripsi produk, stok, dll, selain itu juga
Telkom Polytechnic Jaminan Mutu Sistem Informasi



Robot Data Entry 143
PAGE 10
dapat digunakan untuk melakukan ekstraksi gambar/ image. iMacros
mendukung Unicode secara penuh dan dapat bekerja dalam berbagai
bahasa termasuk multy-byte language seperti bahasa china. Ada beberapa
alasan mengapa iMacros begitu populer untuk melakukan proses web
scraping atau data extraction:
- iMacros dapat bekerja pada hampir semua website. Seperti pada
kebanyakan website yang kompleks yang menggunakan kotak
dialog, frame, javascript, dan AJAX dapat diotomatiskan juga.
- Dapat melakukan ekstraksi data dengan cepat. Pada komputer
yang standar kita dapat menjalankan 20-50 pekerjaan sekaligus
(multi-threading).
- iMacros memiliki mekanisme scheduling.
- iMacros memungkinkan kita untuk melakukan pengubahan alamat
IP secara terprogram dengan dukungan penuh proxy.
- Setelah kita mendapatkan data dari web, kita dapat melakukan
tugas yang lain seperti melakukan transfer data tersebut ke
aplikasi yang lain atau menggunakan data tersebut ke proses
bisnis yang lain. iMacros terintegrasi dengan setiap bahasa
scripting atau bahasa pemrograman berbasis windows sehingga
kita tidak perlu untuk belajar bahasa pemrograman yang baru
untuk menggunakan iMacros.
- iMacros dapat terkoneksi dengan database atau aplikasi yang lain.
- iMacros memiliki fitur visual recording dari semua aktifitas web
dan ekstraksi makro.
- iMacros mendukung secara penuh Unicode sehingga dapat
melakukan ekstraksi semua bahasa seperti cina, jepang, dan
korea.

3. Image Recognition
Image recognition (pencocokan gambar) merupakan salah satu plug-in dari
iMacros business edition. Penggunaan fitur image recognition disarankan
jika kita memerlukan pengujian web yang fersifat non-html based function
seperti macromedia flash (shockwave) atau java applets.

4. Flash, Java, Silverlight applets
Teknologi DirectScreen (DS) merupakan solusi yang tepat jika semua hal
yang telah dilakukan mengalami kegagalan. DS mensimulasikan standard
native mouse clicks dalam jendela browser. DS diaktifkan selama proses
recording dengan melakukan klik pada tombol ClickMode dan memilih
Telkom Polytechnic Jaminan Mutu Sistem Informasi


144 Robot Data Entry
DirectScreen Commands dari dialog. Pada dasarnya teknologi
DirectScreen digunakan untuk melakukan otomatisasi terhadap halaman
web yang tidak mengandung HTML seperti java applets, Adobe Flash,
Adobe Flex, Microsoft Silverlight atau ActiveX controls. DS juga dapat
melakukan otomatisasi terhadap website berbasis AJAX.

5. Form Filling
Jika pada suatu ketika kita lelah mengisi form pada suatu web site maka
iMacros dapat membantu kita untuk melakukannya secara otomatis.
iMacros dapat mengambil semua data yang ada pada suatu file teks dan
men-submit data-data tersebut kedalam web site secara komplit dan
otomatis tanpa interaksi dari user. Data source dapat berupa dua format
yang berbeda yaitu file teks dengan list variabel dan nilai-nilai variabel
tersebut dengan bentuk key=value ataupun berupa file comma separated
text file (CSV format) yang dapat di-generated menggunakan MS exell
ataupun aplikasi yang lain. Penggunaan list of variable format disarankan
jika kita memiliki banyak variabel yang berbeda tetapi memiliki hanya satu
atau sedikit nilai untuk setiap variabel sebagai contoh untuk melakukan
pengisian data alamat dalam formulir online. Sedangkan format CSV lebih
cocok untuk digunakan dengan jumlah variabel yang sedikit dengan
perbedaan nilai yang besar. Pengguna yang lebih ahli dapat menggunakan
iMacros dengan menghubungkannya secara langsung ke database untuk
melakukan akses data.


Advance Function

1. Web testing
iMacros sebenarnya juga dapat digunakan untuk pengujian fungsional,
performansi, dan regresi dari aplikasi berbasis web. iMacros merupakan
satu-satunya tool yang dapat melakukan otomatisasi pengujian dalam web
browser menggunakan internet explorer maupun firefox. iMacros juga
merupakan satu-satunya tool yang dapat melakukan pengujian terhadap
elemen-elemen java, flash, flex atau silverlight applets dan AJAX. Dalam
iMacros terdapat perintah STOPWATCH built-in yang dapat secara tepat
mengukur response time dari setiap proses. Ada beberapa alasan
menggunakan iMacros untuk melakukan pengujian web:

Telkom Polytechnic Jaminan Mutu Sistem Informasi



Robot Data Entry 145
PAGE 10
- iMacros dapat bekerja pada hampir semua website. Seperti pada
kebanyakan website yang kompleks yang menggunakan kotak
dialog, frame, javascript, dan AJAX dapat diotomatiskan juga.
- Mendukung browser/ cross-platform: iMacros
meripakan testing software yang dapat bekerja pada firefox dan
internet explorer.
- iMacros merupakan solusi untuk melakukan pengujian terhadap
flash, flex, silverlight, ActiveX dan java applet didalam browser
tanpa membutuhkan pengubahan settingan proxy.
- Kebanyakan macro test software yang lain hanya dapat
melakukan otomatisasi pada satu window browser pada satu
waktu tetapi iMacros tidak terdapat keterbatasan tersebut kita
dapat menjalankan banyak proses pada iMacros pada saat yang
sama (multi-threading).
- iMacros dabat dijadwalkan untuk menjalankan pekerjaan tertentu.
- iMacros terintegrasi dengan semua alat testing, aplikasi
monitoring, windows scripting dan bahasa pemrograman sehingga
kita tidak membutuhkan untuk mempelajari bahasa baru untuk
mempelajari iMacros.
- iMacros memungkinkan melakukan visual recording terhadap
semua kegiatan yang dilakukan pada web.

2. Web Scripting
iMacros Scripting Edition secara otomatis melakukan instalasi scripting
interface. Dengan menggunakan perintah-perintah tertentu kita dapat
melakukan kontrol terhadap iMacros yang mendukung COM object.
Hampir semua bahasa pemrograman berbasis windows dapat mendukung
teknologi ini, contoh-contoh bahasa pemrograman tersebut adalah Visual
Basic 6, Visual Basic .NET, C#, Java, Perl, Python, C++, ASP, PHP,
ASP.NET.

3. Distributing iMacros
Kita dapat mendistribusikan installer iMacros yang bisa kita dapatkan dari
http://www.iopus.com/download/. Ketika melakukan instalasi aplikasi pada
komputer klien kita dapat dengan mudah melakukan pemanggilan setup
iMacros dan menginstal iMacros. Kita kemudian dapat menulis Player key
dalam iim.ini dari setup, serial number dapat dimasukkan secara manual
pada tiap-tiap komputer klien atau bisa juga dijadikan parameter dalam
Telkom Polytechnic Jaminan Mutu Sistem Informasi


146 Robot Data Entry
iimInit(). Komputer klien akan dapat melakukan play terhadap macro yang
kita buat sebelumnya.


7.4 Contoh penggunaan iMacros untuk browser automation.
Pada kasus ini kita akan melakukan pengecekan email secara otomatis,
langkah-langkahnya adalah sebagai berikut:
1. Klik icon iMacros yang ada pada tool bar browser anda.


2. Pilih tab rec kemudian tekan tombol record.



Icon iMacros
Telkom Polytechnic Jaminan Mutu Sistem Informasi



Robot Data Entry 147
PAGE 10
3. Masukkan alamat email, misalkan: mail.yahoo.com

4. Masukkan email ID dan password, kemudian tekan tombol Sign In




Telkom Polytechnic Jaminan Mutu Sistem Informasi


148 Robot Data Entry
5. Setelah berhasil login tekan tombol stop kemudian tekan save


6. Muncul kotak dialog untuk menginputkan nama file iim kemudian
tekan OK.



Telkom Polytechnic Jaminan Mutu Sistem Informasi



Robot Data Entry 149
PAGE 10

7. Untuk memutar kembali kegiatan yang kita lakukan lagi pastikan
keadaan kembali ke semula (sign out dari mail). Pilih nama file iim,
pilih tab play kemudian tekan play.




Telkom Polytechnic Jaminan Mutu Sistem Informasi


150 Robot Data Entry



Rangkuman



1. Salah satu cara untuk mengurangi beban dalam melakukan pekerjaan
penginputan data pada saat pengujian adalah dengan menggunakan
tool/ alat bantu untuk penginputan data (robot data entry).
2. iMacros merupakan macro recorder berbasis web pertama di dunia
yang memungkinkan kita untuk melakukan surfing pada web dan
mengulanginya.
3. Beberapa kegunaan iMacros antara lain adalah Form Filling, Browser
Automation, Data Extraction, Flash, Java, Silverlight applets, Image
Recognition, Web Testing, Web Scripting, Distributing iMacros.







Kuis Benar Salah



1. iMacros yang merupakan Macro recorder berbasis web pertama di
dunia.
2. Kita tidak dapat melakukan import atau eksport data dari atau
menjadi file CSV dan XML, database atau sumber yang lain dari
aplikasi berbasis web menggunakan iMacros
3. iMacros dapat melakukan multi-threading.
4. iMacros dapat bekerja pada hampir semua website.
5. Untuk mempelajari iMacros kita harus mempelajari bahasa
pemrograman yang baru.



Telkom Polytechnic Jaminan Mutu Sistem Informasi



Robot Data Entry 151
PAGE 10




Pilihan Ganda



Petunjuk: Pilihlah jawaban yang paling tepat!

1.
Berikut ini adalah kegunaan iMacros kecuali _____________
A. Browser Automation D. Scheduling
B. Data Extraction E. benar semua
C. Image Recognition

2.

Berikut ini adalah pernyataan yang benar mengenai iMacros kecuali
_____________
A.
iMacros memiliki mekanisme
scheduling. D.
iMacros tidak mendukung
Unicode
B.
iMacros dapat terkoneksi
dengan database atau aplikasi
yang lain. E.
iMacros memiliki fitur visual
recording dari semua aktifitas
web dan ekstraksi makro.
C.
Kesalahan inisialisasi dan
terminasi

3.

Berikut ini adalah format data yang dapat digunakan pada proses
form filling adalah _____________
A. File teks dengan list variabel D. benar semua
B. Comma Separated Value E. salah semua
C. CSV

4.

Bahasa pemrograman yang didukung oleh iMacros kecuali
_____________
A. Visual Basic 6 D. HTML
B. Visual Basic .NET E. salah semua
C. C#

Telkom Polytechnic Jaminan Mutu Sistem Informasi


152 Robot Data Entry
5.

Berikut ini adalah hal yang benar mengenai Teknologi DirectScreen
(DS) kecuali _____________
A.
Mensimulasikan standard
native mouse clicks dalam
jendela browser D. benar semua
B.
Melakukan otomatisasi
terhadap halaman web yang
tidak mengandung HTML E. salah semua
C.
Berguna untuk menangani
web yang hanya mengandung
java applets





Latihan

Eksplorasi tools iMacros untuk melakukan pengujian robot data entry
menggunakan fitur form filling kemudian presentasikan didepan kelas.


Telkom Polytechnic Jaminan Mutu Sistem Informasi



153
PAGE 10

Daftar Pustaka


1. www.cvs.org