1. 13.4 Strategi Pengujian Untuk Perangkat Lunak Object-Oriented
13.4.1 Tes Unit dalam Konteks Object-Oriented
Ketika perangkat lunak Object-Oriented dipertimbangkan, konsep dari unit menjadi berubah.
Enkapsulasi merubah definisi class. Ini berarti bahwa setiap class dan setiap objek, data, dan
fungsilah yang memanipulasi data tersebut. Sebuah class yang terenkapsulasi biasanya
merupakan focus dari pengujian unit. Pengujian class perangkat lunak OO adalah sama dengan
pengujian modul untuk perangkat lunak konvensional. Tidak dianjurkan untuk menguji operasi
di dalam isolasi.
13.4.2 Pengujian Integrasi dalam Konteks Object-Oriented
Karena perangkat lunak Object-Oriented tidak memiliki struktur pengendalian hirarki yang jelas,
strategi top-down tradisional dan integrasi bottom-up hanya memiliki sedikit makna. Selain itu,
mengintegrasikan operasi satu per satu ke dalam class sering tidak mungkin karena interaksi
langsung dan tidak langsung dari komponen yang membentuk class. Sebuah strategi penting
untuk pengujian integrasi dari OO software adalah pengujian thread-based. Threads adalah
sejumlah class yang merespon input atau event. Pengujian use-based fokus kepada class yang
tidak berhubungan erat dengan class lainnya.
13.5 Tes Validasi
Pada puncak dari pengujian integrasi, perangkat lunak benar-benar dirakit sebagai sebuah
paket, kesalahan interfaces telah ditemukan dan diperbaiki, dan seri terakhir dari tes perangkat
lunak- tes validasi mungkin dimulai. Validasi dapat didefinisikan dalam banyak cara, tapi definisi
sederhananya, validasi yang berhasil adalah ketika perangkat lunak berfungsi dengan cara
yang diharapkan oleh pelanggan.
18.5.1 Tes Validasi Kriteria
Validasi software dicapai melalui serangkaian tes black-box yang menunjukkan kesesuaian
dengan persyaratan. Sebuah rencana uji menguraikan kelas tes yang harus dilakukan
dan prosedur uji mendefinisikan kasus uji yang spesifik yang akan digunakan untuk
menunjukkan kesesuaian dengan persyaratan. Kedua rencana dan prosedur dirancang untuk
memastikan bahwa semua persyaratan fungsional terpenuhi, semua karakteristik perilaku
tercapai, semua persyaratan kinerja tercapai, dokumentasi yang benar, dan human engineered
dan persyaratan lainnya dipenuhi (misalnya, transportability, kompatibilitas, kesalahan
pemulihan, rawatan).
13.5.2 Review Konfigurasi
Elemen penting dari proses validasi adalah review konfigurasi. Tujuan kajian ini adalah untuk
memastikan bahwa semua elemen dari konfigurasi perangkat lunak telah
benar dikembangkan, dikatalogkan, dan memiliki detail yang diperlukan untuk mendukung

2. mendukung fase siklus hidup perangkat lunak. Tinjauan konfigurasi, kadang-kadang disebut
audit.
13.5.3 Tes Alpha dan Beta
Tidak mungkin bagi sebuah software developer untuk meramalkan bagaimana pelanggan akan
menggunakan sebuah perangkat lunak. Instruksi untuk menggunakan mungkin saja salah
interpretasi, kombinasi asing dari data mungkin saja digunakan, output yang terlihat jelas bagi
penguji mungkin tidak jelas bagi pengguna di lapangan. Ketika pernagkat lunak yang telah
dikostomisasi dibangun untuk seorang pelanggan, sejumlah tes penerimaan dilakukakn untuk
membuat pelanggan bisa memvalidasi semua ketentuan.
Tes Alpha dilakukan di pihak developer oleh end-user. Perangkat lunak digunakan dalam
aturan yang alami dengan developer “melihat di atas bahu” dari pengguna dan merekam eror
dan masalah penggunaan.
Tes Beta dilakukan di pihak end-user tanpa hadirnya developer. Dengan demikian, tes beta
merupakan aplikasi secara “live” dari perangkat lunak dalam lingkungan yang tidak dapat
dikontrol oleh developer. End-user merekam semua eror dan kemudian melaporkannya kepada
developer dalam jangka waktu yang ditentukan.
13.6 Pengujian Sistem
Pengujian sistem sebenarnya merupakan sejumlah tes yang berbeda dimana tujuan utamanya
adalah melatih secara penuh sistem berbasis komputer. Meskipun setiap tes mempunyai
sebuah perbedaan tujuan, semua yang dilakukan adalah untuk memverifikasi bahwa elemen
sistem telah terintegrasi dengan baik. Berikut ini adalah tipe-tipe pengujian sistem yang berguna
untuk sistem berbasis perangkat lunak.
13.6.1 Pengujian Recovery
Beberapa sistem berbasis komputer harus merecover dari kesalahan dan mengulang proses
dalam waktu yang tidak ditentukan. Pengujian recovery adalah sebuah pengujian sistem yang
memaksa perangkat lunak untuk gagal dalam bermacam-macam cara dan memverifikasi
bahwa recovery berjalan dengan baik. Jika recovery membutuhkan campur tangan manusia,
mean-time-to-repair (MTTR) dievaluasi untuk menentukan apakah sudah mencapai batas yang
dapat diterima.
13.6.2 Pengujian Keamanan
Pengujian keamanan memverifikasi bahwa mekanisme proteksi yang dibangun dalam sebuah
sistem, pada kenyataannya, melindungi sistem dari penetrasi yang tidak sepantasnya.
Dengan waktu dan sumber yang cukup, pengujian system yang baik akan benar-benar
memenetrasi sebuah sistem. Peran dari perancang sistem adalah membuat harga penetrasi
melebihi nilai dari informasi yang akan didapat.
13.6.3 Pengujian Tekanan

3. Pengujian tekanan mengeksekusi sebuah sistem dengan cara yang meminta sumber dalam
jumlah, frekuensi, atau volume yang tidak normal.
Variasi dari pengujian tekanan adalah teknik yang disebut dengan pengujian sensitivitas. Dalam
beberapa situasi, sejumlah kecil data terdiri dari sejumlah data valid untuk sebuah program
dapat menyebabkan proses yang ekstrem bahkan eror atau pengurangan performa. Pengujian
sensitivitas mencoba untuk menemukan kombinasi data dengan class input yang valid yang
mungkin menyebabkan ketidakstabilan atau proses yang tidak berjalan baik.
13.6.4 Pengujian Performa
Pengujian performa dirancang untuk mengetes run-time performance dari perangkat lunak
dalam konteks dari sistem yang terintegrasi. Pengujian performa sering berpasangan dengan
pengujian tekanan dan biasanya membutuhkan instrumen baik perangkat keras maupun
pernagkat lunak.