Download Testing Dan Implementasi Sistem PDF

TitleTesting Dan Implementasi Sistem
File Size4.6 MB
Total Pages239
Table of Contents
                            Kata Pengantar
Daftar Isi
Pengenalan
	Definisi Testing
	Definisi Sederhana Kualitas
	Hubungan Testing dan Kualitas
	Faktor Kualitas secara Umum
	Kualitas Software Penting bagi Organisasi Software
Dasar-Dasar Testing
	Obyektifitas Testing
	Misi dari Tim Testing
	Psikologi Testing
	Prinsip-Prinsip Testing
		Testing yang komplit tidak mungkin.
		Testing merupakan pekerjaan yang kreatif dan sulit.
		Alasan yang penting diadakannya testing adalah untuk mencega
		Testing berbasis pada resiko.
		Testing harus direncanakan.
		Testing butuh kebebasan.
	Moto Testing
	Isu-Isu Seputar Testing
		Sistem itu “Buggy“
		Testing ditampilkan dengan gambaran yang menakutkan
		Batas waktu menjadi hambatan bagi testing
		Testing bukan organisasi dan ilmu
		Manajemen pendukung untuk testing kurang dari ideal
		Testing tidak ditampilkan sebagai suatu karir  yang menjanji
		Teknologi baru ataupun lama menyulitkan situasi
	Testabilitas
		Operability
		Observability
		Controllability
		Decomposability
		Simplicity
		Stability
		Understandability
	Kemampuan Tester yang Diharapkan
	Personalitas Tester
	Pengertian Defect dari Software
	Biaya-Biaya yang Berkaitan dengan Testing dan Defects
		Biaya-biaya testing
		Biaya-biaya defects
		Penyeimbangan Biaya
	Siklus Hidup Software secara Umum
	Siklus Hidup Testing secara Umum
	Aktifitas Testing secara Umum
	Tiga Tingkatan Testing secara Umum
		Praktik unit testing secara umum
		Praktik system testing secara umum
		Praktik acceptance testing secara umum
Disain Test Case
	Definisi Test Case
	White Box Testing
		Cakupan pernyataan, cabang dan jalur
			Cakupan pernyataan
			Cakupan cabang
			Cakupan jalur
			Perbedaan antara cakupan pernyataan, cabang dan jalur
			Disain cakupan tes
		Basis Path Testing
		Cyclomatic Complexity
		Graph Matrix
		Control Structure Testing
			Testing Kondisi (Condition Testing)
				Branch Testing
				Domain Testing [WHI80]
				BRO (Branch and Relational Operator) Testing [TAI89]
		Data Flow Testing
		Loop Testing
		Lines of Code
		Halstead’s Metrics
	Black Box Testing
		Dekomposisi kebutuhan untuk dites secara sistematis
			Spesifikasi sebagai tuntunan testing
			Dekomposisi obyektifitas tes
		Metode Graph Based Testing
			Contoh ilustrasi
		Equivalence Partitioning
			Contoh ilustrasi
			Analisa partisi
			Pendisainan test cases
			Partisi one-to-one test cases
			Test cases minimal untuk multi partisi
			Perbandingan pendekatan one-to-one dengan minimalisasi
		Boundary Value Analysis
			Contoh ilustrasi
		Cause-Effect Graphing Techniques
			Contoh ilustrasi
		State Transition Testing
			Contoh ilustrasi
			Test cases untuk transisi yang valid
			Test cases untuk transisi yang tidak valid
		Orthogonal Array Testing
			Contoh ilustrasi
		Functional Analysis
			Contoh ilustrasi
			Dekomposisi sistem terhadap fungsi-fungsinya
			Mendefinisikan fungsi-fungsi
			Disain tes menggunakan  functional analysis
				Kriteria fungsi
				Keluaran-keluaran fungsi
				Masukan-masukan fungsi
				Kondisi-kondisi internal fungsi
				Status-status internal fungsi
		Use Cases
			Definisi use cases
			Contoh ilustrasi
			Test cases negatif
	Teknik Lainnya
		Comparison Testing
		Test Factor Analysis
		Risk Based Testing
		Syntax Testing
		Cross-Functional Testing
		Operational Profiling
		Table & Array Testing
	Penggunaan Metode Tes
Strategi Testing
	Pendekatan  Strategi Testing
		Verifikasi dan validasi
		Pengorganisasian testing software
		Strategi testing software
		Kriteria pemenuhan testing
	Isu-Isu Strategi Testing
	Unit Testing
		Hal-hal yang perlu diperhatikan pada unit testing
		Prosedur-prosedur unit test
	Integration Testing
		Top-down integration
		Bottom-up testing
		Regression testing
		Smoke testing
		Komentar untuk integration testing
		Dokumentasi integration testing
	Validation Testing
		Kriteria validation testing
		Review konfigurasi
		Alpha dan beta testing
	System Testing
		Recovery testing
		Security testing
		Stress testing
		Performance testing
	Seni Debugging
		Proses debugging
		Pertimbangan psikologi
		Pendekatan debugging
Perencanaan Testing
	Obyektifitas Rencana Testing
	Rencana Tes Berdasarkan pada Standar IEEE
	Hal-Hal yang Berhubungan dengan Rencana Tes
	Kerangka Rencana Tes Sederhana
	Testing Terstruktur vs Testing Tidak Terstruktur
	Spesifikasi Tes Tingkat Tinggi vs Spesifikasi Tes Detil
	Berapa Banyak Tes Dinyatakan Cukup?
	Sekuensialisasi Tes
	Teknik Estimasi Usaha Tes
		Bottom-Up atau Micro-Estimating
		Top-Down or Global-Estimating
		Formulae atau Models
		Parkinson’s Law
		Pricing to Win
		Cost Averaging
		Consensus of Experts
		SWAG (Scientific Wild-Ass Guess)
		Re-Estimating by Phase
			Re-Testing
	Faktor-Faktor Estimasi
	Estimasi Usaha Tes
		Perencanaan tes
			Jumlah test cases yang dibutuhkan untuk testing
				Estimasi jumlah test cases untuk testing software baru
				Estimasi jumlah test cases untuk regression testing
			Waktu rata-rata per test case untuk persiapan test cases
		Eksekusi tes
			Estimasi testing ulang setelah perbaikan
		Debugging dan Perbaikan
			Jumlah defects/bugs yang diperbaiki
			Waktu yang dibutuhkan untuk memperbaiki defect/bug
		Pendekatan Rasio
		Alokasi Sumber Daya
			Testing manual
			Testing yang diotomatisasi
		Testing Tipe Khusus
			Regression test
				Usability test
	Penjadualan Tes
Proses Testing
	Definisi Proses Pengembangan Software
	Definisi “Umbrella Frameworks”
	Pentingnya Standarisasi Proses
	Hubungan Antar Standarisasi Proses
	Metodologi Software dan Testing
		Siklus hidup pengembangan software
		Siklus hidup testing tradisional
		Siklus hidup testing paralel
	Aktifitas dan Produk Testing
		Metodologi STEP
		Metodologi Rasional Rose
	Integrasi Testing ke Dalam Siklus Hidup Software
	Testing Dengan Review
	Testing Kebutuhan
		Testing kebutuhan dengan menggunakan disain test cases berba
		Matrik validasi kebutuhan
		Testing kebutuhan dengan melakukan tes protipe atau model
		Teknik testing kebutuhan lainnya
	Testing Disain Sistem
		Testing disain menggunakan analisa alternatif
		Memaksa analisa alternatif dengan kompetisi disain
		Testing disain dengan melakukan tes  model
		Testing disain menggunakan disain test case berbasis disain
		Pengukuran testing disain
		Alat bantu testing disain
	Otomatisasi Testing
		Definisi otomatisasi testing
		Alasan dibutuhkannya otomatisasi testing
		Pemisahan kelompok tes
		Efisiensi otomatisasi testing
		Otomatisasi testing vs testing manual
		Kelebihan dan kekurangan otomatisasi testing
		Kesiapan otomatisasi testing
Manajemen Fungsi Testing
	Tugas Manajemen
		5 M
		Evolusi spesialisasi testing
		5 C
	Pengorganisasian Testing
		Pengorganisasian melalui kebijakan
		Organisasi tes
		Manajer testing
		Pengorganisasian melalui standar dan prosedur
		Justifikasi organisasi testing
	Pengendalian Fungsi Testing
		Pelacakan error, fault dan failure
		Analisa masalah
		Pelacakan biaya error, fault dan failure
		Pelacakan status testing
		Dokumentasi tes sebagai alat bantu kendali
Konsep Baru Sekitar Testing
	Testing dengan Spesifikasi yang Berevolusi
	Testing Berorientasi Obyek
		Perluasan Pandang Testing
		Model testing OOA dan OOD
			Kebenaran Model OOA dan OOD
			Konsistensi Model OOA dan OOD
		Strategi testing berorientasi obyek
			Unit testing dalam konteks OO
			Integration testing dalam konteks OO
			Validation Testing dalam Konteks OO
		Disain Test Case untuk Software OO
			Implikasi disain test case dari konsep OO
			Kemampuan aplikasi metode disain test case konvensional
			Fault-based testing
			Pengaruh pemrograman OO terhadap testing
			Test case dan hirarki kelas
			Disain scenario-based testing
			Testing  struktur dalam dan struktur permukaan
		Metode testing yang dapat diaplikasikan pada tingkat kelas
			Random testing untuk kelas-kelas OO
			Partition testing dan tingkat kelas
		Disain Test Case Inter-kelas
			Testing kelas bertingkat
			Testing yang ditarik dari model tingkah laku
	Cleanroom Testing
		Testing menggunakan statistik
		Sertifikasi
Testing Lingkungan, Arsitektur dan Aplikasi Khusus
	Testing GUI
	Testing Arsitektur Client/Server
		Strategi testing C/S keseluruhan
		Taktik testing C/S
	Testing Dokumentasi dan Fasilitas Help
	Testing Sistem Real-Time
	Testing Aplikasi Berbasis Web
Daftar Pustaka
                        
Document Text Contents
Page 1

Buku Materi Kuliah STIKOM Surabaya
















TTEESSTTIINNGG DDAANN
IIMMPPLLEEMMEENNTTAASSII

SSIISSTTEEMM


Edisi Pertama





Oleh:
Romeo, S.T.











Surabaya, Juli 2003

Page 2

Untuk istriku Evy Oetomo dan adikku Betty Yulistiowati:



“Testing merupakan cara untuk dapat lebih mengerti dan memahami proses pengembangan,
termasuk pengembangan diri pribadi, untuk mencapai hidup yang lebih dan lebih berarti.
Karena kesuksesan bukanlah posisi dimana berada saat ini, namun merupakan tingkat
kuantitas dan kualitas makna dari pengalaman hidup yang telah dicapai hingga saat ini.”



“Biarkan mereka katakan ‘mengapa’ terhadap setiap hal sepanjang hidupnya. Setiap
‘mengapa’ akan selalu menambah pengetahuan dan membuka wawasannya. Pengetahuan,

wawasan, dan pengalaman akan menjadikannya bijak.”



STIKOM Testing dan Implementasi Sistem Romeo, S.T.

Page 119

Bab IV Strategi Testing Halaman 109

kasus lain kesalahan sistem harus dibenahi alam kurun waktu tertentu atau kerugian

ekonomis akan terjadi.

Recovery testing adalah system test yang memaksa software gagal dalam berbagai cara dan

baik. Bila recovery otomatis dilakukan oleh

kebenaran dari re-inisialisasi, mekanisme

n restart. Bila recovery membutuhkan intervensi manusia,

d

verifikasi bahwa recovery sistem berjalan dengan

sistem itu sendiri, maka perlu dievaluasi

checkpointing, data recovery, da

mean-time-to-repair (MTTR), waktu rata-rata perbaikan, dievaluasi untuk menentukan apakah

masih dalam batasan yang dapat diterima.

4.6.2 Security testing

Tiap sistem berbasis komputer yang memanajemeni informasi bersifat sensitif atau

menyebabkan aksi-aksi yang dapat merugikan individu sebagai target dari penetrasi yang

atau tidak legal, membutuhkan sistem manajemen keamanan dari sistem tidak sehat

tersebut.

Sec

dalam si kan.

Keaman ak langsung

(jalan bela

melakukan p

Den k akan

melakukan p

adala

urity testing digunakan untuk melakukan verifikasi mekanisme proteksi, yang dibangun ke

k diinginstem akan melindungi sistem tersebut dari penetrasi yang tida

rontal) maupun tan sistem harus dites terhadap serangan langsung (f

kang). Selama security testing, tester memerankan tugas sebagai orang yang ingin

enetrasi pada sistem.

gan waktu dan sumber daya yang cukup memadai, security testing yang bai

enetrasi terhadap suatu sistem dengan sangat hebat. Tugas perancang sistem

h untuk membuat biaya penetrasi lebih dari nilai informasi yang diobservasi.

4.6.3 Stress testing

Selama tahap-tahap awal dari testing software, teknik white-box dan black-box dihasilkan

melalui evaluasi dari fungsi-fungsi dan kinerja normal program. Stress tests didisain untuk

menghadapkan program kepada situasi yang tidak normal.

Stress Testing mengeksekusi sistem dalam suatu kondisi dimana kebutuhan sumber daya

tidak normal dalam kuantitas, frekuensi atau volume, contoh :

Tes khusus didisain untuk membuat sepuluh interupsi/detik dimana satu atau dua intrupsi

merupakan nilai rata-rata.

Test cases membutuhkan memori maksimum atau sumber-sumber lain dieksekusi.

Intinya, tester harus berusaha untuk menghentikan jalannya sistem.

Variasi stress testing adalah sensitivity testing. Pada beberapa situasi (kebanyakan terjadi

pada algoritma matematika), interval data yang sangat kecil akan menyebabkan kondisi

ekstrim bahkan kesalahan proses atau degradasi kinerja.

Sensitivity testing digunakan untuk mencakup kombinasi data dalam kelas – kelas masukan

yang valid yang mungkin dapat menyebabkan ketidakstabilan atau pemrosesan yang tidak

dikehendaki.

STIKOM Testing dan Implementasi Sistem Romeo, S.T.

Page 120

Bab IV Strategi Testing Halaman 110

4.6.4 Performance testing

Unt

fung

mak

Per

yan

pad cara bersamaan pada saat tes

diin

Per

inst

utili mentasi eksternal

mes

situ

keg

4.

uk sistem yang real-time dan embedded, walaupun software telah menyediakan fungsi-

si yang dibutuhkan, namun tidak memiliki kinerja yang sesuai dengan apa yang diminta,

a software tersebut tetap tidak dapat diterima.

fomance testing dilakukan untuk tes kinerja software secara runtime dalam kontek sistem

g terintegrasi. Performance testing terjadi di semua tahap pada proses testing. Bahkan

a tingkat unit, kinerja dari modul individual akan dinilai se

white-box yang dilakukan. Bagaimanapun juga, tidak semua elemen dapat sepenuhnya

tegrasikan, sehingga kinerja sistem yang sebenarnya dapat di pastikan.

formance testing biasa digabung dengan stress testing dan biasanya membutuhkan

rumentasi software dan hardware. Oleh karena itu, seringkali membutuhkan pengukuran

tas dari sumber daya (seperti siklus prosesor) secara eksak. Instru

dapat memonitor interval eksekusi, log kejadian (seperti interupts) saat terjadi, dan status

in pada basis reguler. Dengan menginstrumentasikan sistem, tester dapat melingkupi

asi-situasi yang mungkin mempunyai kecenderungan untuk mengarah ke degradasi dan

agalan sistem.

7 Seni Debugging
Tes

sist u strategi dapat didefinisikan, dan hasil

s yang berurutan,

deb

tes,

bers

4.7

ting software adalah suatu proses yang dapat direncanakan dan dispesifikasikan secara

ematis. Disain test case dapat dilakukan, suat

dapat dievaluasi terhadap harapan yang telah dituliskan sebelumnya.

Debugging terjadi sebagai konsekuensi testing yang berhasil. Yaitu bilamana test case

menemukan error, debugging adalah proses menghilangkan error.

Walaupun debugging dapat dan seharusnya merupakan suatu prose

ugging masih merupakan suatu seni. Teknisi software dalam mengevaluasi hasil suatu

kadang dihadapkan pada masalah indikasi dari gejala penyebab masalah dari software

angkutan. Yaitu, manifestasi eksternal dari error dan penyebab internal dari error yang

mungkin tidak mempunyai hubungan langsung antara satu dengan yang lainnya.

.1 Proses debugging

Deb

Ber bar 4.6, proses debugging dimulai dari eksekusi test case. Hasil-hasil

kan dengan kinerja

seb

indi

men n inidikasi dengan penyebab sehingga dapat mengarahkan pembenahan

kesalahan.

ugging bukan testing tapi selalu terjadi sebagai konsekuensi testing.

dasarkan pada gam

dinilai dan kurangnya korespondensi antara kinerja yang diharap

enarnya dihitung. Pada banyak kasus, data yang tidak berkorespondensi merupakan

kasi dari suatu penyebab yang tersembunyi. Proses debugging adalah proses untuk

cocokka

STIKOM Testing dan Implementasi Sistem Romeo, S.T.

Page 238

STIKOM Testing dan Implementasi Sistem Romeo, S.T.

[GIL95] Gilb, T., “What We Fail to Do in Our Current Testing Culture,” Testing Techniques

Newsletter, (on-line edition, [email protected]), Software Research, January 1995.

[HAY93] Hayes, L.G., “Automated Testing For Everyone,” OS/2 Profesional, November

1993, p. 51.

[HOW82] Howden, W.E., “Weak Mutation Testing and the Completeness of Test Cases,”

IEEE Trans. Software Engineering, vol. SE-8, no. 4, July 1982, pp. 371-379.

[HUM94] Humphrey, Watt S. Managing the Software Process. Addison-Wesley: Reading.

MA. 1994.

[IEEE83A] IEEE Standard, “Standard for Software Test Documentation”, ANSI/IEEE Std

829-1983, August 1983

[JON81] Jones, T.C., Programming Productivity: Issues for the 80s, IEEE Computer

Press, 1981.

[KAN93] Kaner, C., J. Falk, and H.Q. Nguyen, Testing Computer Software, 2PndP ed., Van

Nostrand-Reinhold, 1993.

[KIR94] Kirani, S. and W.T. Tsai, “Specification and Verification of Object-Oriented

Programs,” Technical Report TR 94-64, Computer Science Department, University of

Minnesota, December 1994.

[LIN94] Lindland, O.I., et al., “Understanding Quality in Conceptual Modeling,” IEEE

Software, vol. 11, no. 4, July 1994, pp. 42-49.

[LIN94A] Linger, R., “Cleanroom Process Model,” IEEE Software, vol. 11, no. 2, March

1994, pp. 50-58.

[LIP82A] M. Lipow, Number of Faults per Line of Code, IEEE Transactions on Software

Engineering, Vol 8, pgs 437 – 439, June, 1982.

[MCG94] McGregor, J.D., and T.D. Korson, “Integrated Object-Oriented Testing and

Development Processes,” Communications of the ACM, Vol. 37, No. 9, September 1994,

p. 59-77.

[MCO96] McConnell, S., “Best Practices:Daily Build and Smoke Test”, IEEE Software,

vol. 13, no. 4, July 1996, 143-144.

[MIL77] Miller, E., “The Philosophy of Testing,” in Program Testing Techniques, IEEE

Computer Society Press, 1977, p.1-3.

[MUS87] Musa, J.D., A. Iannino, and K., Okumoto, Engineering and Managing Software

with Reliability Measures, Mc-Graw-Hill, 1987.

[MUS89] Musa, J.D. and Ackerman, A.F., “Quantifying Software Validation: When to Stop

Testing?” IEEE Software, May 1989, pp. 19-27.

[MUS93] Musa, J., “Operational Profiles in Software Reliability Engineering,” IEEE

Software, Maret 1993, p. 14-32.

[MYE79] Myers, G., The Art of Software Testing, Wiley, 1979.

[PHA97] Phadke, M.S., “Planning Efficient Software Tests,” Crosstalk, vol. 10, no. 10,

October 1997, pp. 11-15.

Page 239

STIKOM Testing dan Implementasi Sistem Romeo, S.T.

[POO93] Poore, J.H., H.D. Mills, and D. Mutchler, “Planning and Certifying Software

System Reliability,” IEEE Software, vol. 10, no. 1, January 1993, pp. 88-89.

[QAQ95A] QA Quest, Newsletter of the Quality Assurance Institute, Nov, 1995.

[QUI93] Quinn, S.R., J.C. Ware, and J. Spragens, “Tireless Tesers; Automated Tools Can

Help Iron Out the Kinks in Your Custom GUI Applications,” Infoworld, September 1993, p.

78-79, 82-83, 85.

[SHN80] Shneiderman, B., Software Psychology, Winthrop Publishers, 1980, p. 28.

[TAI89] Tai, K.C., “What to Do Beyond Branch Testing,” ACM Software Engineering

Notes, vol. 14, no. 2, April 1989, pp. 58-61.

[VAN89] Van Vleck, T., ”Three Questions About Each Bug You Find,” ACM Software

Engineering Notes, vol. 14, no. 5, July 1989, pp.62-63.

[VAS93] Vaskevitch, D., Client/Server Strategies, IDG Books, 1993.

[WAL89] Wallace, D.R. and R.U. Fujii, “Software Verification and Validation: An

Overview,” IEEE Software, May 1989, pp. 10-17.

[WHI80] White, L.J. and E.I. Cohen, “A Domain Strategy for Program Testing,” IEEE

Trans. Software Engineering, vol. SE-6, no.5, May 1980, pp.247-257.

[WOH94] Wohlin, C. and P. Runeson, “Certification of Software Components,” IEEE

Trans. Software Engineering, vol. SE-20, no. 6, June 1994, pp. 494-499.

[YOU75] Yourdon, E., Techniques of Program Structure and Design, Prentice-Hall, 1975.

Similer Documents