TEKNIK PENGUJIAN

SOFTWARE
 Software Testing Strategies
2

 Suatu strategi untuk pengujian Software yang

mengintegrasikan teknik perancangan kasus untuk
pengujian Software untuk barisan langkah
pembentukan Software.
 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 S/W 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.

STMIK AMIKOM Yogyakarta

 Pengukuran Kualitas Software
3

l Dua Aspek yang dipertimbangkan:

• Apakah implementasi sudah sesuai dengan spesifikasi ?
• Apakah spesifikasi sesuai dengan kebutuhan user ?
l Validasi  “Validation are we building the product right”
• “Apakah sistem yang dikembangkan sudah benar?”
• Pengujian dimana sistem ketika diimplementasikan sesuai dengan yang
iharapkan
l Verifikasi  “Verification are we building the right product”
• “Apakah sistem dikembangkan dengan cara yang benar ?”
• Pengujian apakah sistem sudah sesuai dengan spesifikasi

STMIK AMIKOM Yogyakarta

 Testing dari low-level ke high level
4
(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.
STMIK AMIKOM Yogyakarta
 Testing Technique
5

Unit Testing Verification White Box

Component
(Process Testing
testing Oriented) Techniques
Module (Tests that are derived
Testing from knowledge of the
program’s structure
and implementation)

Sub-System
Integrated Testing
testing System
Testing

STMIK AMIKOM
Acceptance Yogyakarta
Validation Black Box Testing
User testing
 Proses Testing
6

 Unit testing
 Pengujian masing-masing unit komponen program untuk
meyakinkan bhw sudah beroperasi secara benar
 Module Testing
 Pengujian terhadap koleksi unit-unit komponen yang saling
berhubungan.
 Sub-system Testing
 Pengujian terhadap koleksi module-module yang
membentuk suatu sub-system (aplikasi)

STMIK AMIKOM Yogyakarta

 Proses Testing
7

 System Testing
 Pengujian terhadap integrasi sub-system, yaitu
keterhubungan antar sub-system
 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)

STMIK AMIKOM Yogyakarta

 Proses Testing
8

Unit Module Sub-system System Acceptance

Testing Testing Testing Testing Testing

User
Component Testing Integration Testing Testing

STMIK AMIKOM Yogyakarta

 Proses Testing (pengelompokan)
9

 Component testing
 Pengujian komponen-komponen program
 Biasanya dilakukan oleh component developer (kecuali
untuk system kritis)
 Integration testing
 Pengujian kelompok komponen-komponen yang
terintegrasi untuk membentuk sub-system ataupun system
 Dialakukan oleh tim penguji yang independent
 Pengujian berdasarkan spesifikasi sistem

STMIK AMIKOM Yogyakarta

 Rencana Pengujian
10
 Proses testing
 Deskripsi fase-fase utama dalam pengujian
 Pelacakan Kebutuhan
 Semua kebutuhan user diuji secara individu
 Item yg diuji
 Menspesifikasi komponen sistem yang diuji
 Jadual Testing
 Prosedur Pencatatan Hasil dan Prosedur
 Kebutuhan akan Hardware dan Software
 Kendala-kendala
 Mis: kekuranga staff, alat, waktu dll.
STMIK AMIKOM Yogyakarta
 Prioritas Testing
11

 Hanya test yang lengkap yg dapat meyakinkan sistem

terbebas dari kesalahan, tetapi hal ini sangat sulit
dilakukan.
 Prioritas dilakukan terhadap pengujian kemampuan
sistem, bukan masing-masing komponennya.
 Pengujian untuk situasi yg tipikal lebih penting
dibandingkan pengujian terhadap nilai batas.

STMIK AMIKOM Yogyakarta

 Test data dan kasus test
12

 Test data: Input yang yang direncankan digunakan

oleh sistem.
 Test cases: Input yang digunakan untuk menguji
sistem dan memprediksi output dari input jika
sistem beroperasi sesuai dengan spesifikasi.

STMIK AMIKOM Yogyakarta

 Black-box testing
13

 Pendekatan pengujian dimana program dianggap

sebagai suatu ‘black-box’ (‘kotak hitam’)
 Program test case berbasiskan spesifikasi
 Test planning dapat dimulai sejak awal proses
pengembangan sistem

STMIK AMIKOM Yogyakarta

 Black-box testing
14

Inputs causing
anomalous
Input test data I behaviour
e

System

Outputs which reveal

the presence of
Output test results Oe defects

STMIK AMIKOM Yogyakarta

 Equivalence partitioning
15

 Input data dan output hasil terdapat di klas yang

berbeda yang sesuai dengan klas inputnya
 Masing-masing klas equivalensi partition diprosres
dimana program akan memproses anggota klas-klas
tersebut secara equivale.
 Test cases dipilih dari masing-masing partisi

STMIK AMIKOM Yogyakarta

 Equivalence partitioning
16

Invalid inputs Valid inputs

System

Outputs

STMIK AMIKOM Yogyakarta

 Equivalence partitions
17

3 11
4 7 10

Less than 4 Between 4 and 10 More than 10

Number of input values

9999 100000
10000 50000 99999

Less than 10000 Between 10000 and 99999 More than 99999

Input values
STMIK AMIKOM Yogyakarta
 Search routine - input partitions
18

 Inputs yang sesuai dengan pre-conditions

 Inputs yang tidak sesuai pre-condition
 Inputs dimana key element ada di dalam array
 Inputs dimana key element tidak terdapat di dalam
array

STMIK AMIKOM Yogyakarta

 Structural testing
19

 Disebut juga white-box testing

 Penentuan test case disesuaikan dengan struktur
sistem. Knowledge program digunakan untuk
mengidentifikasi test case tambahan.
 Tujuannya untuk menguji semua statement
program (debug).

STMIK AMIKOM Yogyakarta

 White-box testing
20

Test data

Tests Derives

Component Test
code outputs

STMIK AMIKOM Yogyakarta

 Interface testing
21

 Dilakukan kalau module-module dan sub-system

terintegrasi dan membentuk sistem yang lebih besar
 Tujuannya untuk medeteksi fault terhadap kesalahan
interface atau asumsi yg tidak valid terntang interface
tsb.
 Sangat penting untuk pengujian terhadap
pengembangan sistem dgn menggunakan pendekatan
object-oriented yg didefinisikan oleh object-
objectnya

STMIK AMIKOM Yogyakarta

22

Pengujian Aplikasi Server

STMIK AMIKOM Yogyakarta

 Pengujian Aplikasi Server
23

 Volume Testing
 Stress Testing
 Performance Testing
 Data Recovery Testing
 Data Backup and Restore Testing
 Data Security Testing

STMIK AMIKOM Yogyakarta

 Volume Testing
24

 Menemukan kelemahan sistem selama melakukan

pemrosesan data dalam jumlah yang besar dalam
periode waktu yang singkat.
 Tujuan: meyakinkan bahwa sistem tetap melakukan
pemrosesan data anatar batasan fisik dan batasan
logik.
 Contoh:
 Mengujikan proses antar server dan antar partisi hardisik
pd satu server.

STMIK AMIKOM Yogyakarta

 Stress Testing
25

 Tujuan: mengetahui kemampuan sistem dalam

melakukan transaksi selama periode waktu puncak
proses. Contoh periode puncak: ketika penolakan
proses login on-line setelah sistem down atau pada
kasus batch, pengiriman batch proses dalam jumlah
yg besar dilakukan setelah sistem down.
 Contoh: Melakukan login ke server ketika sejumlah
besar workstation melakukan proses menjalankan
perintah sql database.

STMIK AMIKOM Yogyakarta

 Performance Testing
26

 Dilakukan secara paralel dengan Volume dan Stress testing

untuk mengetahui unjuk kerja sistem (waktu respon,
throughput rate) pada beberapa kondisi proses dan
konfigurasi.
 Dilakukan pada semua konfigurasi sistem perangkat keras
dan lunak.
 Mis.: pd aplikasi Client-Server diujikan pd kondisi korporate
ataupun lingkungan sendiri (LAN vs. WAN, Laptop vs. Desktop)
 Menguji sistem dengan hubungannya sistem ke lain pada server yg
sama.
 Load Balancing Monitor
 Network Monitor

STMIK AMIKOM Yogyakarta

 Data Recovery Testing
27

 Investigasi dampak kehilangan data melalui proses

recovery ketika terjadi kegagalan proses.
 Penting dilakukan karena data yg disimpan di server
dapat dikonfigurasi dengan berbagai cara.
 Kehilangan Data terjadi akibat kegagalan sistem,
hardisk rusak, peghapusan yg tidak sengaja,
kecelakaan, virus dan pencuri.

STMIK AMIKOM Yogyakarta

 Data Backup and Restore Testing
28

 Dilakukan untuk melihat prosedur back-up dan recovery.

 Diakukan dengan mensimulasikan beberapa kesalahan untuk
menguji proses backup dan recovery.
 Pengujian dilakukan terhadap strategi backup: frekuensi ,
medium, waktu, mekanisme backup (manual/ otomatis),
personal, ? Berapa lama backup akan disimpan.
 Switching antara live dan backup server ketika terjadi
kerusakan (load log transaction pada back-up kemudian
melaku recovery).

STMIK AMIKOM Yogyakarta

 Data Security Testing
29

 Privilege access terhadap database diujikan pada

beberapa user yang tidak memiliki privilege access
ke database.
 Shutdown database engine melalui operating
system (dengan beberapa perintah OS) yg dapat
mematikan aplikasi database.

STMIK AMIKOM Yogyakarta

 Test Case
30

 Untuk White-box testing

 Pengujian struktur logik internal
 Perintah spesifik yang diujikan:
 SELECT,
 OPEN/CLOSE,
 COPY-REPLACE
 IF statement
 REPEAT UNTIL – DO-WHILE LOOP
 CALL

STMIK AMIKOM Yogyakarta

 Test Case
31

 Untuk Black-box testing

 Pengujian fungsional sistem berdasarkan input –
output
 Membagi input – output ke dalam beberapa kelas
(kelas ekuivalensi pada boundary input).
 Menggunakan input yang tidak sesuai spesifikasi
(negatif, di luar range)

STMIK AMIKOM Yogyakarta

Contoh Test Case
Test Case ID: CUST.01
Function: Menambah satu pelanggan baru
32Data Assumptions: Customer database sudah di-restore
Deskripsi: Menambah satu pelanggan, melalui Form Tambah Pelanggan, dan
menampilkan validasi pelanggan baru tersebut pada Tampilan Pelanggan
Aksi State Awal atau Data Hasil yg diharapkan
Tampilan (Response)
1. Aplikasi Penjualan dijalankan Program Tidak Ada Menu utama Aplikasi
melalui Icon di windows Manager Penjualan
2. Pilih Pelanggan pada Menu Tampilan Utama Tidak Ada Pelanggan menampilkan
Tampilan. Penjualan Tampilan..
3. Click pilihan All Customers Tampilan Tidak Ada Window Pelanggan
Pelanggan ditampilkan dengan judul
“Pelanggan”.
4. Click pada Button Tambah Customer - All Tidak Ada Tampilan Tambah
Customer Pelanggan ditampilkan

5. Masukkan data untuk Tambah Nama: Foo Data ditampilkan pada field-
menambah satu pelanggan baru Pelanggan Alamat: Jl. Xxxx field yg sesuai (atau seperti
dan click satu kali button tambah. yg ditampilkan oleh data
Kota: Jakarta
sheet).

STMIK AMIKOM Yogyakarta

 Matrik test case
33

Hasil yang diharapkan

Tujuan Test Penolakan Pesan Kesalah yg Rancangan Test Hasil yang
ditampilkan Case sebenarnya

Menguji perhitungan X X Input nomor Pesan

digit input rekening (yang kesalahan
sudah diubah penolakan dan
urutannya) ditampilkan
Menentukan nomor- X X Input nomor Pesan
nomor departemen departemen yang kesalahan
dicek salah penolakan dan
ditampilkan

Keakuratan Pembayaran Pembayaran

perhitungan lembur untuk lembur sebesar
pekerja jam- 1.5 kali
jaman selama 15 pembayaran
jam normal
STMIK AMIKOM Yogyakarta
 Penilaian Acceptance Test terhadap Faktor
Usabilitas
34

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 Ringkat Kepercayaan 1 2 3 4 5
E Tingkat kesesuaian dengan yg 1 2 3 4 5
dibutuhkan
F Waktu Respons 1 2 3 4 5
G Tingkat komfortabel 1 2 3 4 5

STMIK AMIKOM Yogyakarta

Contoh Laporan Hasil Test
Nomor Kesalahan :
Nama Program:
35 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
5. Kesalah tidak dapat dihasilkan lagi
6. Tidak setuju dengan usulan
-----------
Sertifikasi Resolusi
Dibuat oleh:
Programmer, STMIK AMIKOM Yogyakarta Tanggal:
Tester:
Project Manager: