Strategi Testing. Rudi Susanto. module to be tested. results. software engineer test cases

(1)

Strategi Testing

Rudi Susanto

module to be tested test cases results software engineer

(2)

Testing Strategy

• Strategi testing software mengintegrasikan metode metode

disain test cases software ke dalam suatu rangkaian tahapan

yang terencana dengan baik, sehingga pengembangan software dapat berhasil.

• Strategi menyediakan peta yang menjelaskan tahap-tahap yang

harus dilakukan sebagai bagian dari testing, dan membutuhkan

usaha, waktu, dan sumber daya bilamana tahap-tahap ini direncanakan dan dilaksanakan.

• Strategi testing harus menjadi satu kesatuan dengan

perencanaan tes, disain test case, ekesekusi tes, dan pengumpulan serta evaluasi data hasil testing.

(3)

Karakteristik Umum Strategi

Pengujian software

• Pengujian dimulai pada level modul dan dilanjutkan

terus hingga integrasi dari keseluruhan sistem.

• Setiap saat pengujian mengimplementasikan teknik

pengujian yang berbeda.

• Pengujian dikelola oleh pengembang Software dan

untuk yang berukuran besar dikelola oleh group penguji

yang tidak terikat.

• Pengujian and debugging merupakan aktifitas yang

berbeda, tetapi debugging selalu digunakan di setiap

strategi pengujian.

(4)

Testing dari low-level ke high level

(Tahapan Testing)

• Sistem tidak diujikan sebagai suatu unit

tunggal, kecuali untuk program yang kecil.

• Systems yang Besar terdiri dari sub-systems,

dimana masing2 sub-system terdiri dari

modules yang dibentuk oleh procedures and

functions.

• Proses testing dilakukan dalam beberapa

langkah sehingga diproses secara

incrementally dalam proses implementasi

sistem.

(5)

Testing Technique

Component

testing

Unit Testing Verification

(Process Oriented)

White Box Testing Techniques

(Tests that are derived from knowledge of the

program’s structure and implementation) Module Testing

Integrated

testing

Sub-System Testing System Testing

User testing

Acceptance

Testing

Validation

(Product Oriented)

Black Box Testing Techniques

(Tests are derived from the program

specification)

(6)

Pendekatan Strategis

ke pengujian

perangkat lunak

• Pengujian Unit

• Pengujian Integrasi

• Pengujian Validasi

• Pengujian Sistem

unit test integration_test

validation test system

(7)

(8)

Pengujian Unit

• Berfokus pada inti terkecil dari

desain perangkat lunak yaitu modul

• Biasanya berorientasi pada white

box

• Interface modul diuji untuk

memastikan bahwa informasi secara

tepat mengalir masuk dan keluar

(9)

Bagaimana mengujinya?

MODUL _Interface

Struktur data lokal Kondisi Batas Jalur independen

Jalur penanganan kesalahan

(10)

Test case harus didesain untuk

mengungkap kesalahan dalam kategori

• Pengetikan yang tidak teratur dan tidak konsisten

• Inisialisasi yang salah atau nilai-nilai default

• Nama variabel yang tidak benar

• Tipe data yang tidak konsisten

(11)

(12)

Integration Test

• “Jika semua modul-modul software telah bekerja dengan baik secara individual, mengapa harus ada keraguan apakah

modul-modul tersebut dapat bekerja sama sebagai satu kesatuan?”

• Integration testing adalah suatu teknik yang sistematis untuk

pembangunan struktur program, dimana pada saat yang bersamaan melakukan testing untuk mendapatkan errors yang diasosiasikan dengan antar-muka.

• Obyektifitasnya adalah untuk menindaklanjuti komponen-komponen yang telah melalui unit testing dan membangun suatu struktur program sesuai dengan disain yang telah

(13)

Integration Test



Pengujian keseluruhan system atau sub-system

yang terdiri dr komponen yg terintegrasi.



Test integrasi menggunakan black-box dengan

test case ditentukan dari spesifikasi.



Kesulitannya adalah menemukan/melokasikan



Penggunaan Incremental integration testing

dapat mengurangi masalah tersebut.

(14)

Integration Test

Integrasi test ada 2 cara :

1)

Integrasi non-inkremental/ big bang

Integrasi ini dilakukan dg cara semua modul digabung

seluruhnya. Setelah itu barulah dilakukan pengujian.

2) Integrasi inkremental

Integrasi ini dilakukan untuk membangun dan menguji

interface program dlm segmen-segmen kecil, sehingga

kesalahan lebih mudah diisolasi dan dibetulkan. Interface

lebih mungkin untuk diuji dg lengkap.

(15)

Incremental integration test

T3 T2 T1 T4 T5 A B C D T2 T1 T3 T4 A B C T1 T2 T3 A B Test sequence 1 Test sequence 2 Test sequence 3

(16)

Pendekatan integration test



Top-down testing

 Berawal dari level-atas system dan terintegrasi dengan

mengganti masing-masing komponen secara top-down dengan suatu stub (program pendek yg mengenerate input ke sub-system yg diuji).



Bottom-up testing

 Integrasi components ini dimulai dari modul terkecil.

hingga sistem lengkap.



Pada prakteknya, kebanyakan test

integrasi menggunakan kombinasi kedua

strategi pengujian tsb.

(17)

Top-down testing

Level 2 Le vel 2

Level 2 Level 2

Level 1 Testing Level 1 sequence Le vel 2 stubs Le vel 3 stubs . . .

(18)

Bottom-up testing

Level N Level N Le vel N Level N Level N Level N–1 Level N–1 Level N–1 Testing sequence Test drivers Test drivers

(19)

Catatan

 Pemilihan strategi integrasi (top-down atau bottom-up) tergantung pada karakteristik program dan juga jadwal

proyek.

 Secara umum pendekatan gabungan (disebut Sandwitch

testing) dapat dilakukan.

 Strategi gabungan yg terbaik adalah : strategi top-down untuk level-level atas dari struktur program, dan strategi bottom-up untuk level-level bawah.

(20)

(21)

Pengujian Validasi

 Bertujuan untuk memastikan apakah

semua elemen konfigurasi software telah

dikembangkan dengan tepat.

 Validasi berhasil bila software berfungsi

sesuai harapan pengguna.

 Validasi dicapai melalui sederetan

pengujian Black-Box yang memperlihatkan

(22)

Bentuk Validasi Test

1. Tes Penerimaan ( Acceptance Test )

2. Tes Alpha

(23)

Validation Test

1. Acceptance Test

 Apabila software dibangun untuk satu pelanggan maka sederetan pengujian penerimaan dapat dilakukan untuk memungkinkan pelanggan me-validasi semua persyaratan

(pengujian dilakukan oleh pelanggan)

 Pengujian terakhir sebelum sistem dipakai oleh user.

 Melibatkan pengujian dengan data dari pengguna sistem.

2. Test Alpha & Beta

 Apabila software dibangun sebagai sebuah produk untuk

digunakan oleh banyak pelanggan, maka dilakukan test Alpha dan Beta.

(24)

Acceptance Test

| Penilaian Terhadap

Faktor Usabilitas

A Mudah digunakan 1 2 3 4 5 B User Friendly 1 2 3 4 5 C Mudah dimengerti 1 2 3 4 5 D Tingkat Kepercayaan 1 2 3 4 5 E Tingkat kesesuaian dengan yg

dibutuhkan

1 2 3 4 5

F Waktu Respons 1 2 3 4 5

(25)

Alpha Test

 Dilakukan pada sisi pengembang oleh user yang

potensial.

 Software digunakan pada setting yang natural

(sebenarnya), sehingga bila terjadi error, user

dapat merekam masalah yang ada.

 Dilakukan pada sebuah lingkungan yang

terkontrol oleh pengembang.

(26)

Beta Test

 Dilakukan oleh satu atau lebih user.

 Biasanya dilakukan oleh selain pengembang / pihak

ketiga.

 Pengujian dilakukan diluar kontrol pengembang

sistem.

 User merekam semua masalah yang mereka temukan

dan melaporkan ke pengembang. Kemudian

pengembang melakukan modifikasi dan akhirnya

mempersiapkan pelepasan produk ke seluruh

pelanggan.

(27)

(28)

Sistem Test

 Bertujuan untuk memastikan bahwa semua

elemen/komponen sistem saling berhubungan

dengan tepat dan keseluruhan fungsi/kinerja sistem

dapat tercapai.

 Bentuk tes sistem :

1.Tes / pengujian Perbaikan

2.Tes / pengujian Keamanan

3.Tes / pengujian Stress

4.Tes / pengujian Kinerja

(29)

Sistem Test

1. Tes Perbaikan



Pengujian yang memaksa sistem untuk gagal

(dirusakkan) dengan berbagai cara dan

memeriksa apakah perbaikan dapat dilakukan

dengan tepat.

2. Tes Keamanan



Pengujian yang dilakukan untuk membuktikan

apakah perlindungan (keamanan) yang ada

pada sistem benar-benar dapat melindungi

sistem dari gangguan.

(30)

Sistem Test

3. Tes Stress

 Pengujian yang dilakukan untuk melihat bagaimana sistem

dalam keadaan abnormal.

 Menguji sistem dengan nilai yg melebihi maksimum load. Stressing suatu system menyebabkan tidak mudah

kerusakan.

 Contoh : melakukan login ke server ketika sejumlah besar

workstation melakukan proses menjalankan perintah sql database

(31)

Sistem Test

4. Tes Kinerja

 Pengujian untuk menguji kinerja run-time (saat

berjalan) dari software didalam konteks sistem yang

terintegrasi

Catatan :

Tes kinerja sering digunakan bersamaan dengan tes stress, dimana kita bisa melihat bagaimana kinerja sistem dalam keadaan abnormal.

(32)

(33)

Testing

aplikasi web

• Testing untuk aplikasi web memiliki banyak

kesamaan dengan testing untuk aplikasi client

server, tetapi aplikasi web lebih sulit karena

tingkat kompleksitasnya lebih tinggi 

interaksi komponen (teknologi) yang

dipergunakan tidak terbatas

– Browser

– OS

(34)

Cont’d

• Idealnya semua komponen dan fungsi yg ada

pada sisi client dan server harus dites (tapi sgt

jarang bisa dilakukan)  pendekatan terbaik

agar tetap sesuai dengan batasan waktu dan

budget :

– Mengecek

requirement project

– Mensetting prioritas sesuai hasil

risk analysis

(35)

Risk analysis

• Risk analysis yang dilakukan harus

mempertimbangkan :

– seberapa mirip lingkungan test dengan

lingkungan produksi (idealnya akan mirip)

– fungsionalitas mana yang sangat kritikal

terhadap

tujuan pembuatan website

– area mana yang memerlukan

interaksi Data

Base yang lebih banyak

(36)

Cont’d

– tipe permasalahan seperti apa yang akan

lebih

sering dikomplain

– area mana dari suatu situs yang akan lebih

sering dibuka

– aspek mana yang memiliki

resiko keamanan

(37)

faktor faktor seperti

project requirement, risk

analysis, budget dan schedule

menentukan

kategori testing yang mana yang sesuai

dengan project web yang dilaksanakan

(38)

Kategori

testing web

• Load testing

• Security testing

• Link testing

• HTML validation

• dll

(39)

Load testing

– Testing dengan load yang sudah diatur rangenya untuk

menentukan pada poin mana respons time sistem turun atau bahkan gagal sama skali.

– Server yang dipakai, seting konfigurasi yang dipergunakan, script

CGI ( Common Gateway Interface) , desain database dan

faktor-faktor lain bisa juga memberikan pengaruh – Testing bisa dilakukan dengan 2 cara

• Testing keseluruhan komponen dibawah kondisi yang bermacam-macam

(40)

Security testing

– Menguji semua fungsi yg berhubungan dengan firewall,

enkripsi, autentikasi, transaksi, akses database

– Menguji perlindungan yang diberikan

– Selain permasalahan kontrol akses di sisi client (password dan enkripsi) juga ada permasalahan di sisi server spt siapa yg berhak mempublish dan memodifikasi file html, siapa yang memiliki wewenang untuk melakukan publikasi final, yang meng-approve suatu file graphics, file sound dan halaman layout

(41)

Link testing

– Untuk menentukan apakah link dari suatu

situs baik itu ke internal dan external web

pages bekerja

– Web yg memiliki banyak link ke situs luar

perlu link testing yg dijadwal secara teratur

(42)

HTML validation

– Ditentukan oleh audience yg dituju, jenis

browser yang kemungkinan akan dipakai

dan seberapa sesuai dengan standar html

(43)

Contoh Laporan Hasil Test

Nomor Kesalahan : Nama Program:

Tipe Laporan: (1. Usulan, 2.Salah Perancangan, 3. Salah program, 4. Salah dokumentasi, 5. Query)

Severity: 1. Minor, 2. Serius, 3. Fatal Attachment (Y/N)

Adakah kesalahan (Y/T)

Bagaimana bentuk kesalahan: Bagaimana kesalahan dapat terjadi: Usulan Perbaikan:

Nama Penguji: Tanggal Uji:

---Diisi oleh programmer:

Ditujukan kepada: Tanggal: Resolusi:

1. Dapat diperbaiki 2. Tidak dapat diperbaiki 3. Pengujian ditarik kembali 4. Bekerja sesuai spesifikasi